ERCIM News No.35 - October 1998

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