Markus Podolsky
Institut für Informatik, Technische Universität München
Orleansstr. 34, 81667 München, Germany
email: podolsky@informatik.tu-muenchen.de
June 26th, 1998
A common approach in software development is to model the application domain from different views. Each of these views focuses on specific aspects of the system, which allows to reduce the complexity of the system description. Typically, the views on the application domain can be classified in the data view, the behavioral view and the architectural view.
Many object-oriented methods like for example OOA&D [Boo94], OMT [Rum91], UML [BRJ97] or Martin/Odell [MO94] emphasize the structural aspects of the software system to build. But they do not pay enough attention to the dynamic aspects and especially to the interaction between the objects. These methods start modeling the system by looking for objects in the application domain and the relationships between them. The main effort lies in finding the objects, classes and their structure. They model the behavior of the system by defining scenarios that capture exemplaric interactions between objects or system components. As a consequence, the structural aspects of the system have a strong influence on the behavioral description. That means, the scenarios defining the system behavior are often adapted to classes and objects that were identified in the application domain. In the area of business applications this can lead to objects that represent persons or departments which are not part of the system to build. Due to this, object-oriented approaches exhibit limitations in the context of business process modeling.
How could a suitable approach for object-oriented modeling of business applications look like? First of all, the approach should emphasize the business processes and the activities that take place therein, because these aspects build the backbone of business applications. Additionally, the notation has to provide means to distinguish at early stages of the system development process which of these actions should be performed by the system and which should be performed by the user. This enables us to clearly define the system boundaries and the points where interaction with the user is necessary. We also have to bear in mind that the modeling techniques should provide means to check whether the models satisfy certain properties. It should be possible to simulate or validate the modeled system. Therefore, the modeling techniques should have a formal basis, that means they should have clear semantics. There are interesting approaches which follow these ideas like [JEJ95] but they mostly lack a formal basis and so they do not provide features like simulation or validation.
In this position paper we present a modeling technique that should help to bridge the gap between object-orientation and business process modeling. Our approach is based on a combination of object-oriented models and ideas from workflow modeling, c.f. [Hol94], where the latter play a central role in our development process. It offers five graphical modeling techniques where each of them concentrates on a small set of system aspects.
The basic idea of our approach is to start with the description of business processes by identifiying the activities they consist of and the causal dependencies between them. After this activity-oriented, behavioral view on the application domain we concentrate on objects and their classes. On the one side we have to identify the data objects which are passed from activity to activity and on the other side we have to define which system component is responsible for the execution of an activity. This approach leads to a clearly defined model of the application domain and allows an integration of business process modeling and object-orientation.
All modeling techniques of our approach have a solid formal basis which defines a clear operational semantics for the whole model of the system. This enables interesting features like simulating the system models or generating code from them. Moreover, we are also able to automatically check whether runs of the system model satisfy certain properties which can be formulated using a temporal logic with object-oriented extensions, c.f. [FOP98].
We will now present an integrated set of description techniques which are especially suited for an object-oriented representation of business applications. The constructs of the description techniques and the aspects they cover are adapted to a development process in which both the domain experts and the system specialists are involved which is a typical situation in developing business applications. Therefore, the description techniques have to satisfy various requirements. On the one side they have to be comprehensible and should be expressive enough to cover all relevant aspects of the system. On the other side they should lead to unambiguous interpretations of the system model. To achieve this, we have provided a solid formal basis by mapping the techniques of our approach to a certain kind of high-level petri nets, c.f. [Rei86].
Our approach is based on five graphical modeling techniques (workflow diagram, class diagram, instance diagram, state transition diagram and object behavior charts) which concentrate on different aspects of the system. Although they have different views on the system these techniques refer to informations contained in the other techniques. To achieve consistent models of the whole system there is a set of consistency rules that have to be satisfied by syntactically correct descriptions.
Simulation, testing and code-generation facilities of our approach allow an integrated support of the development process. These facilities provide means for rapid prototyping and validation of the system to build.
We now introduce the workflow diagram that embodies the most significant description technique of our approach. In the analysis phase it is used to create the first model of the application domain by focusing on the structure of the business processes. At this stage the activities of the business processes and their causal dependencies identified in the application domain are modeled.
The workflow diagram originates from petri nets and is used to define a high-level description of the system to build. It offers constructs for modeling the structure of business processes. This task-oriented view concentrates on what happens in the system and leads to an abstract model of the real world. Besides the structural aspects of the business processes we also have to focus on the data objects incorporated in them. We consider the data flow as an integral part of business processes. Therefore, we avoid using a different description technique for specifying the data flow.
The data flow in a business process is characterized by the behavior of the corresponding activities and the causal dependencies between them. We introduce the notion of containers in the workflow diagram which can be compared to places for objects in high-level petri nets. We also regard the interaction between the system and its users as part of the data flow, because, from an activities point of view, it is irrelevant whether data objects originate from another activity or from interaction with the user. Therefore, we have a special kind of containers that contain user input as data objects. Containers are typed, i.e. they can only contain references to data objects of certain types. References to the same data object can be stored in different containers which facilitates concurrent accesses to data objects.
The semantics of the workflow diagram is that activities take certain data objects as input, perform some actions and produce certain data objects as output. That means, each activity takes references of input objects from its input containers and puts references of its output objects to its output containers.
Causal dependencies between activities define the flow of data objects between activities. In the workflow diagram they are expressed by directed arrows between the corresponding activities. To define the data flow we label these arrows with the data objects which are passed between containers and activities.
The execution of an activity corresponds to the execution of an objects method. To each activity we assign a method of a concrete instance that has to be defined in the instance diagram, see section 2.3. Object behavior charts, see section 2.4, are used to describe the actions of methods. The state of an activity (and, if needed, information about its former states) is integrated in its corresponding instance. So, the state of the whole business process (and its history) is distributed among several instances.
The workflow diagram also allows to specify input-, output-, and guard-conditions for activities. To each input connection of an activity we can assign an input-condition. It defines the condition that has to be satisfied by input objects to enable the execution of an activity. Output-conditions can be assigned to output connections of activities. Only if the output-condition is satisfied the activity will put objects to the corresponding output container. Input- and output-conditions focus on data objects, whereas guard-conditions focus on the instance that perfoms the actions of the activity. That means the activity can be executed only if its instance satisfies the guard-condition.
The workflow diagram provides means to express hierarchical aspects of business processes. First of all, activities may be further refined by subworkflows. A refinement of an activity is valid, if the context of the subworkflow is the same as the context of the activity. This means, the input- and output-connections and their conditions have to match. Another possibility of refining activities lies in the fact that the execution of an activity corresponds to the execution of an objects method. An object behavior chart specification for this method can be used to give a detailed description of what happens when the activity is executed.
Figure 1 shows an exemplaric workflow diagram. It consists of activities a1 to a4 and containers cin, cout which denote the input and output container of the whole workflow, u1 which denotes a container for user interaction, and c1 to c4. The dashed rectangle labeled a denotes that this workflow is a refinement of activity a which has connections to the containers cin, u1, and cout. Activity a2 and activity a3 are not causally ordered and so they can be executed in parallel. Activity a2 can be executed, i.e. method1() of object x will be called, only if its input object o1 is not in state B. Additionally, activity a2 will put an object o3 to container c4 only if the state of o3 is A. In the workflow diagram we do not determine where o3 comes from or what happens with o1. This will be done at a lower level of abstraction using object behavior charts.
Using workflow diagrams we have a full integration of business processes and object-orientation. Objects perform the tasks of the activities on their input objects and pass their output objects to certain containers. We consider the workflow model as a framework for the whole business application. The user only has to define what should happen in the activities but he has not to care about how to pass data objects from one activitiy to another. The passing of data objects is part of the framework and at the implementation layer there will be system objects that perform these tasks as it is realized in workflow management systems.
When developing the workflow model several classes and relationships between them are identified. These aspects can be modeled using the class diagram that is similiar to class diagrams of other object-oriented methods. It offers constructs for defining the structural aspects of classes. Each class description consists of a class name, state variables, reference variables and methods. We make a clear distinction between variables containing the state of an object and variables that express which other objects a given object knows. A class description defines the types of each variable as well as a signature for each method.
The class diagram also allows to express relationships between classes like association, aggregation and inheritance. Inheritance is defined by drawing an inheritance arrow from the subclass to the superclass. Aggregation is regarded as a special kind of an association relationship. For both relationships a cardinality has to be defined. Additionally, roles can be assigned to the members of association or aggregation relationships to make the class diagram more comprehensible for both system experts and domain experts.
Besides that, the class diagram offers constructs to describe synchronization properties. Methods can be classified in reading and writing methods which means that for each instance writing methods have to be performed mutually exclusive as well as the execution of writing and reading methods. Guard-conditions for methods provide an additional mechanism to express synchronization.
The instance diagram shows the instances that exist at the system start and of which class they are. Besides that, it also shows which other objects they know. This is achieved by drawing arrows to those objects they refer to and labeling them with the name of the corresponding aggregation or association relationship defined in the class diagram.
When describing the workflow diagram we have already mentioned that to each activity an instance is assigned that performs the tasks of the activity. Of course, each of these instances has to be defined in the instance diagram. Additionally, this diagram allows to define the initial marking of containers, that means to define which data objects they contain at the system start.
Object behavior charts (OBC) provide means to define the interaction of objects as well as their interior behavior [Pod]. They can be seen as a visual programming language and offer graphical high-level constructs that can be used for a detailed description of object methods which is especially important in the design phase.
Their main advantage lies in the fact that they allow to specify which actions take place when an activity resp. its corresponding instance method is executed. Thus, they provide a glass box view on the activities of the workflow diagram.
The programming constructs that object behavior charts offer are object creation, method call, iteration, conditional or nondeterministic branch, state change, assignment, object passing, and return. An explicit construct for passing objects to containers allows a seamless embedding of OBC-descriptions to workflow models. Therefore, OBC-descriptions can be regarded as an additional mechanism to refine workflow activities. Object behavior charts provide a composition mechanism using the call relationship between methods. That means, they allow to specify complex interactions by integrating the object behavior chart of the called methods.
State transition diagrams are used to model the lifecycle of a class by means of a kind of finite state automatons. Many object-oriented methods use one complex automaton that offers constructs like and-states and or-states to express hierarchical aspects of an object lifecycle, c.f. [Rum91]. In our approach we use several simple automatons for modeling the lifecycle of a class. For each state variable defined in the class diagram an automaton can be defined that shows how the values of the state variable change due to method calls. The state of an object is given by the cartesian product over the values of its state variables. Additionally, state transitions can be labeled with guard conditions in order to express dependencies between the state variables of an object. In general, state transition diagrams are useful for describing the lifecycle of data objects because of their passive character. For modeling the behavior of activity objects which are the central points of interactions we use object behavior charts.
[Boo94] G. Booch, Object-Oriented Analysis and Design with Applications,
2. ed. Benjamin/Cummings, Redwood City, Ca., 1994
[BRJ97] G. Booch, J. Rumbaugh and I. Jacobson, The Unified Modeling Language,
Rational Software Coorp., 1997
[FOP98] M. Frey, M.Oberhuber and M.Podolsky, Framework for Testing based
Development of Parallel and Distributed Programs, In Proc. of the
3rd Workshop on Parallel and Distributed Software Engineering,
Kyoto, April 1998, IEEE Computer Society
[Hol94] D. Hollingsworth, The Workflow Reference Model, Workflow Management
Coalition, Document Number TC00-1003, Brussels, 1994
[JEJ95] I. Jacobson, M. Ericsson and A. Jacobson, The Object Advantage: Business
Process Reengineering with Object Technology, Addison-Wesley, 1995
[MO92] J. Martin and J. Odell, Object-Oriented Analysis and Design,
Prentice-Hall, Englewood Cliffs, NJ, 1992
[Pod] M. Podolsky, Visual Programming using Object Behavior Charts,
to appear in Proceedings of the 2nd Workshop on End-User Development,
Barcelona, June 1997
[Rei86] W. Reisig, Petrinetze: Eine Einführung, Springer, Berlin, 1986
[Rum91] J. Rumbaugh, Object-oriented modeling and design, Englewood Cliffs, NJ,
Prentice-Hall, 1991