Gerti Kappel
University of Linz

Objective of the meeting:

The meeting took place at Oct. 9, 1998 and was located at RWTH Aachen. It was organized by Klaus Pohl (RWTH Aachen, Germany) and Gerti Kappel (University of Linz, Austria). It had the objective to exchange research results in the area of requirements engineering in general, and in the area of UML based requirements engineering in particular.

Agenda of the meeting:

Gerti Kappel presented their work on using UML for process modeling in general, and for workflow modeling in particular.

The following two topics have been discussed in detail. First, {\bf activity diagrams} in UML are a proper means to describe a "workflow", i.e., the predecessor/successor relationships of activities, and which results are produced in terms of objects in a particular state. Within activity diagrams it is possible to define concurrent execution paths in terms of forking and joining synchronisation states. Unfortunately, with joining synchronisation states it is not possible to define XOR synchronisations and inclusive OR synchronisations. To "simulate" such a behavior, a "dummy" state with several incoming arcs bearing mutual exclusive conditions for the XOR case and overlapping conditions for the inclusive OR case has to be modeled instead. Activity diagrams may consist of activities and actions. Whereas the latter are atomic and not further decomposeable, the former are complex and may be decomposed into further activity diagrams. Since activity diagrams are modeled as subclasses of state diagrams in the metamodel of UML, activities and actions are a special kind of states. In the current version of the metamodel, however, both activities and actions are subclasses of the metaclass "SimpleState", which is not decomposable by nature. This is in contrast to the complex nature of activities.

Second, the {\bf role concept} is necessary to model context dependent behavior of agents acting in some workflow system. Since UML does not explicitly support the role concept, we investigated to which extent interfaces in UML may be used to simulate such a behavior. Referring to the standard specification of UML1.1, it is not possible to model associations to interfaces. But this implies, however, that interfaces may not be used to model various roles an object may play where various client objects are only aware of these roles and have associations to them. This is a major obstacle in using interfaces.