An Object-Oriented Database Model for Business Entities and Processes
by Michele Missikoff and Roberto Pizzicannella
An enterprise is a heterogeneous domain where complex entities
take part in business processes of different nature and complexity.
Traditionally, entities are stored in a database and processes
are implemented in the application software. In the ProForm project
(see ERCIM News No. 32) we store and manage both entities and
processes as structured objects, with an internal state. In particular,
processes are seen as static entities when we specify and manage
them; conversely, they are seen as dynamic entities when their
execution is activated. To treat a ‘passive’ object as an executable
component of the application system we envisioned a specific operational
semantics (instantiation semantics) which was used when building
the ProForm engine.
A number of complex object types have been conceived at IASI-CNR
to represent a Business Environment in both its static (actors
and entities) and dynamic (Business Processes: BP) components,
and store them in an Object-Oriented database.
For the static component we use the standard Object-Oriented (OO)
approach, essentially based on the TQL++ model.
The standard OO constructs used in ProForm concern:
- Object, Class, Type, Properties
- Refinement Hierarchies (ISA)
- Associations (Relationships)
- Decomposition Hierarchies (Part-of).
To better represent business environments, to these standard construct
we have added two modeling constructs:
- Constraints
- Business States.
Constraints allows the modeling of notions such as: business rules
and best practises. Business States allows the designer to specify,
for a given Business Entity, those states that determine specific
behavioural patterns of that entity within the enterprise. Therefore,
Business States represents a sort of conceptual bridge between
static and dynamic modeling. We will not give further details
on the static constructs as they are defined according to the
Object-Oriented paradigm, which is assumed to be known.
For the dynamic component, we started by considering typical workflows
in business domains, carefully analysing the structuring and modeling
techniques found in the literature. Here we present a description
of the proposed Business Process database model, which is represented
as a set of predefined templates (essentially, a BP metamodel).
These templates, adopted to model the BPs of an enterprise, are
used to build the schema of an Object-Oriented database, referred
to as Business Process Base (BPB). In our approach, the specification
of a BP is obtained by recursively decomposing it into its components.
The BP is organised as a partially ordered set of Use Cases. A
Use Case (UC), a modeling notion originally proposed by Jacobson,
is a business operation activated by the user. We interpret it
as a user transaction. A UC is then decomposed into actions that
are recursively decomposed into subactions. The final level of
this hierarchical decomposition is represented by the elementary
steps: basic operations that can be directly executed. In our
approach, the steps are specified using SQL, with a few additions
in order to adjust the richer BP metamodel to the underlying database
model.
As stated, a BP is represented as a static entity, following the
OO approach (by applying a mechanism often referred to as reification).
The BP metamodel is thus composed by the following object types:
Business Process Object (BPO), Use Case Object (UCO), and Action
Object (ACO). Each type is structured in two sections: a preamble,
which reports descriptive information, and a body, which contains
the functional decomposition into sub-objects. In particular,
a BPO is composed of UCOs, and a UCO is composed of ACOs. An Action
Object is recursively decomposed into sub-actions or into executable
steps. The latter are not objects, they appear as attributes of
an ACO. The figure shows the relationships between these object
types.
Object Types
Business Process Object - This is the most general description
of a BP; its structure is organised as follows:
- Preamble - contains a synthetic description, in natural language,
of the BP goals and expected effects. Stakeholder: describes the
subject that is responsible for an effective accomplishment of
the business process. Involved entities: a list of business entities
involved in the execution of the BP.
- Body - consists of a list of Use Cases that compose the BP. They
are numbered for identification purpose and indications on the
execution order are given. Each UC can raise an exception, requiring
other UCs to be activated; it may also indicate an external collaboration,
which typically represents an interaction with an external system
or actor. Another information supplied here concerns the Standard
Course of Events (SCE), which allows the set of most commonly
performed UCs to be indicated. Furthermore the Start and End UCs
(which may be more than one) have to be indicated.
Use Case Object - This structure represents a meaningful unit
of interaction between user and system. From a database perspective,
it can be seen as a transaction:
- Preamble - contains the same type of information described in
the BPO preamble, with the property actor instead of stakeholder.
There are input/output attributes, that specify the information
directly exchanged with the user, and a trigger event, that causes
the UC to start.
- Body - consists of a list of actions, with exception and collaboration
information, as described in BPO. There are also optional actions,
each of which is associated with a condition that defines under
what circumstances an optional action should be activated.
Action Object - This is the performing element that can be specified
at different levels of refinement. The first level allows a task
decomposition approach to be adopted, the final level (leaves)
is represented by directly executable steps.
- Preamble - defined as above, except for the trigger event, which
is omitted since actions are activated by internal control mechanisms,
according to the order specified in the UCO body.
- Body - contains essentially a list of subactions, with the associated
information as above. In addition it is necessary to specify whether
a given action is further expanded into subactions or is an executable
step. In the latter case, the step is formally defined by an associated
script.
The BPs defined according to the object types presented above
form the schema of the Business Process database (BPB). A BP schema
can be executed, since it is associated with an operational semantics
(referred to as instantiation semantics). The result of such an
execution is the creation of a BPO instance in the BPB, besides
the obvious side effects that take place in the entity database.
The ProForm system has an engine that interprets a BPO type according
to the instantiation semantics.
Please contact:
Michele Missikoff
or Roberto Pizzicannella - IASI-CNR
Tel: +39 06 77161
E-mail: {missikoff, pizzican}@iasi.rm.cnr.it
