Business Object Design and Implementation Workshop

Position Paper


Object Business Modelling, Requirements and Approach

Guus Ramackers (gramacke@uk.oracle.com)

Organization

Oracle Corporation, European Development Center
Oracle Park, Bittams Lane, Guildford Road, Chertsey, Surrey KT16 9RG, UK
Tel: +44-(0)1932-872020 (ext. 2291) E-mail: ramackers@acm.org
Fax: +44-(0)1932-873273 Oracle*Mail: gramacke@uk.oracle.com

Date/Place: 16 October 1995/Austin, TX


Disclaimer: the views expressed by the author do not necessarily coincide with those of Oracle Corporation.


Introduction

Object technology holds the promise to bring reuse and flexibility to IT system development. The mechanisms to achieve this are application building by component assembly and rapid adjustment of component definitions. However, the current leverage of objects is primarily a small-town, technology oriented perspective. Reuse of low level components such as windows, widgets, queues and sets is possible, but these are clearly not the elements that users and enterprises expect. To make reuse work for large industrial IS environments, additional enterprise orientation and user involvement is required.

At the same time, enterprises strive to be more flexible and more aware of their business organization. In that context, business modelling forms a reflective and adaptive process in its own right (e.g. "business process re-engineering"). However, "in its own right" is the cause of considerable problems in integrating the results of business modelling with IT development, particularly workflow and application design. Given the dependency of business change on modifications of the supporting IT systems, business modelling should interface directly with system design. The object paradigm provides an excellent basis for achieving this integration.

Thus, business modelling and object oriented design are required in an integrated fashion to achieve industrial strength business and IS improvement on a continuous basis. The combination of model based development and component assembly can leverage the promise of reuse and flexibility at the business level. Only then can IT foster business opportunities rather than a deadly embrace with the past.

It will be clear that delivering such a solution depends heavily on the availability of an object technology infrastructure. Distributed object storage and middleware glue to link things together in a heterogeneous computing environment are essential. However, such technology is becoming available (OLE, COM, DSOM, OpenDoc, ...). It's now up to what we do with that technology in business modelling such that it drives design and run-time environments.

In conclusion, the goal of Object Business Modelling is to bring together BPR, workflow, organization modelling and OO Analysis on the basis of an integrated meta model. Furthermore, to interface the model to an object design and implementation environment such that many complexities are hidden through default design. This must be done in such a way that reuse of integrated system descriptions (fragments and frameworks) and system flexibility are fully enabled from the business level. Finally, tool support should focus on making modelling and communication easier for business domain experts and end-users (particularly through animated multimedia diagrams and extensive what-if experimentation).

This research is part of a project investigating the requirements for an enhanced form of business modelling. The current approach to business modelling supported by Oracle's Designer/2000 CASE product is based on an Information Engineering style of working. This approach is not expected to achieve the goals of reuse and flexibility when combined with an object oriented design and implementation environment.

In this position paper, the requirements and approach taken for Object Business Modelling and anticipated tool support are described globally, without going into detailed solutions. We assume that object-oriented application development and middleware solutions are available. In the following, model requirements are described first, followed by primary tool requirements.

Model Requirements

An essential requirement for a business model is that it uses terminology that is close to the way business domain experts and end-users express themselves when talking about their organization. The primary concepts in our meta model are:

Actors are the responsible agents of action within an organization. Actors (or roles) are assigned as resources to one or more business units. These represent departments, workgroups or projects. Apart from actors, objects are the other resources involved in business processes.

Objects may be either material or informational in nature. Information objects exist in two forms, namely domain objects (a.k.a. entity objects) and business objects (similar to [1, 7]). Domain objects form the underlying architecture describing the information concepts essential to the business in question. However, when actors are involved in business processes, their particular view of that underlying information (which varies per actor and per process step) is modelled through business objects.

Business objects are defined as aggregates of domain objects. In addition, they define a 'filtering' or 'view' mechanism that defines precisely which attributes, relationships, operations and life cycle states are relevant for an actor in the context of a certain business process. In this two-tiered manner, information objects are integrated with the workflow model [2].

Business processes define the chains of organizational activity threading through different business units. A process is defined in terms of a sequence of process steps, each of which may again be a process at a lower level. A process step requires a set of resources (actors, objects) and has a duration, a value addition and satisfies an organizational goal. The trigger for a process to happen is the occurrence of an event.

An event may either be a state change of an object, a condition becoming true, a time event or an external event (e.g. a phone call from a customer). However, the occurrence of an event in itself may not be enough to trigger a process. The precondition rule for the step must also be satisfied. Apart from pre and postconditions, rules may be state rules or integrity rules.

In order to support enhanced animation and simulation of business models, it is important that the meta model defined has an operational basis. This requires an event based model, where triggers and rules are defined as the precise conditions governing process execution. Furthermore, instances of objects and actors must form an integral part of the model. In order to aid the definition of an interpreter for business models, it is beneficial to map the meta model to an underlying formal representation, e.g. state transition systems or Petri nets [4, 5].

Although OO methods in general pay little attention to business modelling as such, e.g. [6], the methods of Odell [4] and recently Jacobson [3] cover at least part of this domain. We are investigating the possibility of mapping the underlying meta models of these approaches (or at least a major part of them) to our own model. If successful, this would enable CASE tools to display alternative notations, based on the user's method preference.

Tool Requirements

In essence, an integrated object toolset poses requirements far beyond paper-based methodologies. The true problem is one of integrating many different, partially overlapping, "views" in a flexible manner. Therefore, a set of integrated, model based development tools can only be constructed effectively on the basis of an underlying active repository. This repository provides the data integration and consistency of the meta model supported by the tools. In addition, it must notify tools of relevant changes (caused by some other tool) through an event mechanism. Furthermore, extensibility (e.g. for mapping existing methods) requires an open repository environment.

The primary goals of an Object Business Modelling toolset must be to make modelling easier to understand for domain experts and end-users and, furthermore, to aid them in the transition to application design. As discussed, a meta model geared towards their (communication) requirements is essential. It also requires that the model information is presented in a graphical fashion by tools, with full support for using icons and multi-media elements as part of a model. The model must also become more meaningful for these kinds of users. Hence support for example instances throughout and business model animation and simulation is a prerequisite. Finally, the tools should make experimentation with alternative models less threatening through support for what-if scenarios.

An Object Business Modelling toolset might consist of the following diagramming tools (some of which may be combined in one tool as different views):

The majority of these tools is concerned with manipulating the meta model elements discussed. The latter two tools offer specific functionality for reuse and design generation.

Fragments are model packages that have been published for reuse in a fragment library. Fragments may be domain specific (e.g. "order entry process") or they may be used generically (e.g. "resource allocation" or even "decision process with iteration"). It must be easy to search for fragments in a library, inspect their contents and include them in a system (e.g. through drag and drop). Fragments may be included with or without specific names for model elements (i.e. the actual model, or just its structure). Furthermore, fragments may be included as a whole (ultimately spanning business model to implementation) or just certain aspects of the fragment.

A framework can be regarded as a special fragment, i.e. one with additional conditions. Firstly, a framework is of moderate to large size, it is model complete (in the sense that all perspectives are present) and it is a fully working solution (i.e. including implementation). A framework may be included as the basis for a (sub) system in two ways: the framework may be frozen (and modifications are made primarily through subtyping) or it may be fully modifiable.

Design generation functionality is aimed at hiding some of the complexities of object system design by generating a default design (possibly preference driven). The structure of business concepts may differ from the classes required for efficient application design. Hence, the translation must be facilitated by automated support, providing a basic design model and the hooks for adding further detail. The process is aimed at generating (i) applications and (ii) workflow functionality across applications. The latter can be derived from the business processes defined at the modelling level. design generation operates in three dimensions.

Firstly, the object type definitions of domain and business objects can be included as basic types that may need further refinement. In addition, many data-structure classes and UI elements will be added to the object model at the design level.

Secondly, the behaviour of object types as defined in business processes and object lifecyles provide initial state transition diagrams for those objects at the design level. There, more detailed events and transitions will be added, without disturbing the original structure.

Thirdly, the business process perspective drives the workflow system design. In addition, each elementary process step can be interpreted as a "use case" that is to be detailed as a "scenario" or "object message diagram" to indicate how the system delivers the desired business functionality. Apart from forward design generation, a reverse engineering or retrofit utility should enable a bottom up process of coupling system functionality to business requirements.

Finally, ideally, some of these tools could also be used at run-time by the end-user to define ad-hoc exceptions or modify the system on a more permanent basis by tailoring selected aspects (in a controlled and auditable manner). This applies particularly to

This would enable not only more flexibility in the development process, but also flexibility of the delivered IS (without complex re-compiling and re-installation). Again, such functionality can only be based on an integrated underlying repository, particularly one that functions both as a design and run-time environment.

References

1. Casanava, C. (ed.): OMG Business Application Architecture, white paper, Business Object Management Special Interest Group, OMG, Framingham, March 1995.

2. Helfrich, P.: Workflow Management Coalition: Architecture Overview, presentation at BOMSIG, San Jose, June 1995.

3. Jacobson, I. et al.: The Object Advantage, Addison-Wesley, 1994.

4. Martin, J. and Odell, J.J.: Object-Oriented Methods, a Foundation, Prentice Hall, 1995.

5. Ramackers, G.J.: Integrated Object Modelling, an executable specification framework for business analysis and system design, Thesis Publishers, Amsterdam, 1994.

6. Rumbaugh, J.M. et al.: Object-Oriented Modelling and Design, Prentice Hall, 1991.

7. Sims, O.: Business objects, Delivering cooperative objects for client-server, McGraw-Hill, 1994.


Business Object Design and Implementation


Page hits since 8/21/95