| BUSINESS MODEL
|
 Home
|
Architecture
|
 Next
|
| |
As a comprehensive description of
business requirements, the Business Model is the most
important layer in the OmniBuilder architecture. OmniBuilder's
Business Model is fully object-oriented and supports
complex relationships, inheritance, encapsulation of
methods, and object re-use. More importantly, OmniBuilder
allows the business requirements to be defined in
language that business understands ensuring that end
users are able to validate the accuracy and completeness
of the model.
|
|
 Entities |
Entities are the most
significant element of the Business Model. They are
abstract representations of the data and processes of the
real world business. OmniBuilder provides full support
for the definition of the static and dynamic behavior of
entities. Complex properties, relationships and entity
keys are available while the behavior of entities can be
defined via services, triggers, and events.
Design templates exist so that powerful features can
be added to entities by simply selecting them from a
list, such as:
Entity templates:
- Surrogate key generation
- Hierarchical object behavior
- Automatic date, time and user stamping
Property templates:
- Default values
- Validation by range or pattern
- Sequential generation
|
| |
 |
| Relationships |
OmniBuilder
allows complex relationships between objects to be
modeled. As the following example illustrates,
OmniBuilder not only captures the cardinality of the
relationship but also roles, delete behavior,
super/subtype relationships and whether the relationship
represents a business or system key. OmniBuilder uses
this information to generate the foreign keys,
referential integrity constraints etc., required to
implement and manage the relationship. In addition,
OmniBuilder will automatically generate the code
necessary to navigate between objects based on defined
relationships. |
| |
 |
| Business Terms |
Business often
uses terms such as full time employee, overdue account,
length of service etc., which are the expressions of
complex relationships between business objects.
OmniBuilder transparently manages this complexity and
allows business terms to be treated as simple properties
of the business object. These terms can be used in any
query or view that is required by an application. In the
case of a HR system, a query may include seniority in
addition to other attributes to determine the vacation
pay rate.
|
| |
 |
| Services |
Services are the
actions that can be performed on an entity. For example,
if an employee is re-hired, this will result in actions
such as reassigning the previous Employee ID, and
assigning the employee to a Position. Services are
triggered by pre-defined object or system events. |
| |
 |
| Business Rules |
Business rules
express the constraints that ensure the integrity of
stored data. As the example below illustrates,
OmniBuilder allows business rules to be specified
declaratively in the Business Model rather than in
application interface code or proprietary server-based
procedures. This allows the business to efficiently
manage the rules and have the confidence that they
correctly implemented throughout the application. |
| |
 |
|
Business Functions |
OmniBuilder
documents Business Functions using an intuitive,
hierarchical, Business Function Tree. Once defined,
Business Functions are managed by OmniBuilder and
integrated into the generated application. |
| Features |
Features are a
unique and powerful tool for implementing the complex
behavior or design of Business Objects. Once a Feature
has been defined and assigned to an object, OmniBuilder
will manage the object’s behavior automatically.
Although OmniBuilder provides a comprehensive list of
reusable Features, the development team is free to define
their own to meet specific requirements. In the
following example, a surrogate key is assigned to an
entity. OmniBuilder will automatically create the
surrogate key attribute and generate whatever sequences,
triggers etc. are required to manage it in the database.
|
| |
 |
| |
In an HR
application, the employee entity may require a
validation rule so that the current salary of the
employee is within the range. Other features, which may
be added, include date stamping, audit trails, and
authorizing operations to a particular role. |
| Events
and States |
Events are
actions that cause a noteworthy change in a Business
Object. OmniBuilder allows business events such as
"Order Received" or "Employee Hired"
to be defined by the analysis team. In addition,
OmniBuilder provides a number of pre-defined system
events such as "Pre_Update" and
"Post_Commit" etc. which can be invoked from
OmniBuilder’s script language. Some events
automatically occur as a result of a state change.
OmniBuilder supports states which are defined for any
property using a State domain type. A State
type once defined can be reused by one or more entities.
|
| Queries |
With OmniBuilder
you can create complex views of data without the need for
SQL programming. Using an intuitive interface, the
non-technical user specifies the business objects to
display, the selection criteria, summary functions, sort
order etc. and OmniBuilder will generate 100% of the SQL
code required. Any object or service in the application
including QBE windows can access the generated query. |
| |
 |
| User Documentation |
OmniBuilder
generates complete HTML user documentation that provides
an up-to-date description of the Business Model and its
physical implementation. Users can annotate the model and
their comments will be e-mailed to analysis or support
staff. |
| Object Models |
OmniBuilder
automatically updates Object Model diagrams as changes
are made to the Business Model. OmniBuilder implements
the Unified Modeling Language (UML), however, in keeping
with OmniBuilder’s open architecture, support for
other diagramming tools is available by request. |
| |
 |
| |
Next
|
