Using UML and Object-Coordination-Nets for Workflow specification 1 ...

Using UML and Object-Coordination-Nets for Work ow Speci cation Guido Wirtz and Holger Giese AG Verteilte Systeme, Institut f ur Informatik, Westfalische Wilhelms-Universitat Einsteinstrae 62, 48149 M unster, GERMANY http://wwwmath.uni-muenster.de/cs/u/versys/index.html

Abstract The speci cation of intra- and inter-organizational work ows in a manner which scales up to complex work ows across division and company borders is a central issue for nowadays work ow modeling. The approach described in this paper integrates standard object-oriented structure modeling using UML diagrams with Petri-Net techniques for specifying behavior in order to provide an adequate support for modeling all aspects of work ows. The approach puts its emphasis on structuring and abstraction techniques to manage the size and complexity of real-life applications. A contract mechanism is used to ensure the independence of dierent companies and to permit the re-use of partial work ows in a manner which is secure for the oering as well as the using side.

1 Motivation and Requirements The tendency to increase the level of automation in production and oÆce organization as well as the upcoming of E-commerce applications have made work ow management a more and more important topic for nowadays business. Work ow management systems provide the languages and tools to model all important aspects of business processes and to control the execution of their automated parts. In order to provide all information needed to implement a speci c work ow, work ow schemas have to describe dierent work ow aspects [8] in more or less detail: The functional aspect speci es what has to be done within a work ow. The operational aspect determines how it is done, i.e., which techniques and tools are used to perform the work ow. The behavioral aspect de nes when and under which conditions a work ow is executed. The informational aspect speci es the data objects which are being manipulated during work ow executions and the ow of data be-

tween work ow activities. The organizational aspect describes the roles which are involved in work ow executions. When dealing with work ow-in-the-small, concentrating on the dierent aspects in isolation is helpful to reduce complexity. At the end, however, consistency between the dierent parts of a speci cation is more important. Hence, treating the dierent aspects as being independent from each other on the system-wide scale requires a global view of consistency which is hard to achieve without appropriate structuring mechanisms. Moreover, information politics and security issues as well as the size of applications in large organizations and, even more, in business-to-business work ows prevent from assuming global knowledge. Because the process-oriented view found in most work ow approaches fails to adress this problem, dierent techniques have to be developed. However, the problems and requirements are similar to those arising when dealing with the analysis and design of complex sequential and distributed software systems ([12]): complexity has to be managed by means of structuring techniques, knowledge about legacy code is usually restricted, and design for re-use requires the speci cation and implementation of autonomous components with appropriate encapsulation and interface mechanisms. Thus, the use of objectoriented analysis and design techniques for distributed software systems [4] can help in the contex of work ow, too, which also closes the gap between the modeling of work ows and their implementation in modern objectoriented distributed application environments [16]. To be helpful for all people involved in work ow design, especially also for non-programmers, a technique should be based on adequate, scalable visual notations which ease their understanding. This is done best with support for a seamless transition from informal planning to exact operational speci cations which permit evaluation through analysis and simulation.

2 The OCoN Approach The requirements discussed so far lead quite naturally to an approach which tries to use state-of-theart object-oriented techniques combined with a suitable visual language to describe all relevant aspects of business processes. In quest of which languages to use, pragmatics require a well-accepted object-oriented notation which can be found in the UML [11]. Unfortunately, the really essential aspects of system dynamics are not that well-covered in the UML (see [4] for details). Therefore, so-called Object Coordination Nets (OCoNs) [3], an additional, more suitable, visual formalism based on high-level Petri-Nets is used and seamlessly integrated into the UML context [5]. Because most of the details of Object Coordination nets are not of speci c interest here, we introduce only those concepts which are of special importance for work ow modeling. We assume the reader to be familiar with placetransition nets [1]. Transitions in our context are interpreted to be actions which occur through calls to services provided by objects. For places which are called pools, we distinguish between two principle entities: simple data and control ow using untyped tokens and objects typed according to the type system obtained by the informational aspects of work ows are stored in so-called event pools (circles). More permanent objects which are in the object-oriented view the carrier of activity or provider of services are interpreted as resources the system uses to perform its work. Places which hold resources are represented by so-called resource pools (hexagons). The objectoriented view of method invocation is adopted by our nets (see Fig.1). ( a ) enabled

( b ) firing

conditions afterwards in a second step. In Fig.1, the eect of resu = obj1.fun(in) is an object of type ResultType in place resu and a state change for the carrier which is afterwards in state [State2]. However, this level of description is only necessary when specifying the details of a work ow in so-called service nets which are similar to methods of a class and make use of very low-level functionality of their execution environment. Normally, more high-level descriptions are used in order to provide an interface to the functionality which is provided by powerful applications or legacy code. Structuring a system is done by putting the focus on a system design which is ruled by the contract principle [10]. This results in a set of subsystems providing services speci ed in contracts to the outside and possibly using services from other subsystems via their contracts to implement the provided functionality. Scalability is enhanced by also using nested subsystems. A single contract is a traditional ADTlike signature specifying the names and required parameters of all provided services which is extended by a state-machine-like protocol net (PN) to specify externally visible behaviour if not all services are always available. This kind of speci cation enhances the bene ts of interfaces in case of services which obtain nonuniform service availability as it is often found in systems acting according to complex organizational rules. For example, using a le interface based purely on the syntax without knowledge about the important dierence between nishing with or without a save call in case of a modi ed le, i.e., the abstract state of the le, may become a bad experience.

( c ) finished

Figure 2: OCoN architecture and usage of Net types Figure 1: Steps during execution of resu = obj1.fun(in) A transition is interpreted to represent a call to a method-like service. As a precondition for ring, a carrier of activity (here obj1 of type Resource1), i.e., the object which processes the call, is required as well as the parameters (here an object of type InType) and a simple Event (token). Moreover, the carrier has to be not only of type Resource1 but especially a resource in state [State1]. If the call to fun res, it consumes all preconditions in the rst step, performs some durable activity inside the service fun and produces all post-

For decoupling subsystems properly, we distinguish clearly between the external information provided by a contract and its internal implementation. Moreover, we rigorously permit the usage of services by means of provided contracts only. The internals of a subsystem itself may obtain a complex structure as well as complicated rules of handling control and data. This leads in practice to a hierarchical design of such systems. Besides the internal subsystem structure, there are two aspects of special importance inside a single system: the internal details of the implementation of

the provided services and the overall management of resources to acomplish that goal. The concepts needed to model these aspects include an third variant of Petri-nets, so-called resource allocation nets (RAN) for the resource management of an entire class or subsystem. The already mentioned service nets (SN) describe the detailed work ow when performing a single service under the control of the RAN. For the almost simplest case, i.e., an instance of a class which provides a contract to the outside which is implemented by its public services and an instance-local description which resources are needed and how they are coordinated, the principle mechanism is visualized in Fig.2: calling a provided service as described in the corresponding PN, activates the RAN of the instance which provides the call with the needed resources and delegates it to the requested service (SN). If the service uses external services from other contracts, parts of the work are delegated to instances of the used type. The combination of UML diagrams and the three interacting types of Petri-Nets has proven to be suitable for analysis and design of distributed software systems [?]. In this next section, it is described how the approach can be used for work ow modeling.

3 OCoN Work ow Modeling A media store renting books, CDs, videos etc. and its surroundings are used as an example in this work. These include normally the interaction with customers as well as companies producing, advertising and selling new media via external business partners like a transport agency and, of course, a banking service. Omitting cash ow and explicit user modeling, in the simplest scenario there are three principle business partners which interact to produce, store and provide media to customers. Organisational aspects are used to obtain a coarsegrained structure of the context in which work ows are to be modeled. Although real-life organizations are complex, they also tend to be strictly structured, e.g., geographically distributed branches or divisions with distinguished roles, capabilities and permissions to do (parts of) a job. Exactly this organizational information provides a means of structuring work ows which is close to the application domain and hence is highly useful, especially for managing overall complexity as well as scalability of speci cation techniques. UML structure diagrams (Fig.3, Fig.4) are used to describe these organizational structures. This makes the static structure the main criterion how to decompose work-

ows. Besides distinguishing the dierent entities and roles involved in a work ow, inheritance is used to model capabilities like, e.g. writing a letter, which are assigned to dierent subsystems independent of their roles. In our example, the system is decompoesed into three subsystems which are interconnected by providing and importing contracts from each other. «subsystem»

«subsystem»

EnterpriseProd

TransportCmp

MediaOffers

TransService

... «subsystem»

MediaStore StoreMgmt

MediaStore

Figure 3: Companies as interacting subsystems The MediaStore provides two dierent contracts. StoreMgmt is used for management issues, e.g., ordering new media, lling the stock etc. via the EnterpriseProd company whereas customers are served by the MediaStore contract. Both contracts are implemented within the subsystem itself using an internal subsystem MediaStoreCoord which coordinates and delegates all work which has to be done to its dierent subsystems for member management, media renting with reservation handling and so on (see Fig.4). MediaOffers TransService «subsystem»





MediaStore Layer 4

Layer 3

Layer 2

Layer 1

AccountMgr «subsystem»

Account

MediaShipment

AccountMgr

«subsystem»

MediaShipment

RentalContract

StoreMgmt «subsystem»

-MediaStoreCoord

«subsystem»

RentalMgr

MediaStore

RentalMgr

MediaStock

«subsystem»

MediaStock

Reservation ReservationMgr Member «subsystem»

MemberMgr

MemberMgr

«subsystem»

ReservationMgr TimerService

«subsystem»

TimerMgr

Figure 4: The re ned MediaStore The subsystem imports two external contracts, namely the MediaOers for ordering new media and the TransService from the TransportCmp subsystem for the shipment of rented media. Besides the dependencies which are made explicit via the usage of local or imported contracts, no other interaction between subsystems is allowed. This means, the structure provides a coarse-grained description of the organizational aspect of all possible work ows which may be performed in

this system. More important, the dierent contracts can be interpreted as a description of the dierent roles a subsystem may play during work ow execution. It speci es all sub-work ow schemas supported by a speci c subsystem which are designed for external use and hence supports encapsulation and re-use. The example shown in Fig. 5 (left) gives an example of a simple contract to deal with an object of type Media like, e.g., a book or CD using the services getout and putback. The PN adds important usage information to the signature. Only if the required entity is in state [Free] is the service getout available. Moreover, the contract requires that a getout which brings the object to state [InUse] has to be followed de nitely by a putback. Hence, the contract speci es restrictions for its users. Finally, a hint that the object may not be available for some ( nite) time due to internal regulations of the implementation is speci ed by introducing a third state [Check] and an anonymous step (shaded transition). However, the protocol guarantees that eventually the object will be in state [Free] again. Using states as pre- and post-conditions for service availability supports the abstract description of behavioural work ow aspects. «contract»

«implementation»

Media

MediaImpl

signatures getout(MediaDescription): (Media),(UsageInfo) putback(Media)() protocol net

signatures + getout(MediaDescription): (Media),(UsageInfo) + putback(Media)() - checkQuality(MediaSpec): (),(MediaDesc) - repair(MediaDescription)() - MediaSpec selfdescription_ - ..... more attribs

a token in the corresponding resource place. Compared to Media, the possible states of MediaImpl are re ned. Where [Free] and [InUse] are used to represent the corresponding states of the PN, [Check] is partitioned into [Check.1] and [Check.2]. This re ects the fact that the work which has to be done inside the implementation is splitted into two parts checkQuality and repair in the case of incoming objects which are in bad shape. However, the only thing w.r.t. these details which is of any interest for the contract, is the existence of some internal work which prevents Media in state [InUse] from becoming [Free] immediately after a putback. MediaImpl ful lls the protocol because either checkQuality decides that everything is ok and the object is put back in state [Free] or the object is put into state [Check.2] and has to undergo a repair after which it is put back in state [Free], too. Because this part of the behaviour depends on the object at hand, the RAN uses a transition checkQuality with two possible alternative outcomes. The usage of shaded transitions indicates that the net (PN or RAN) at hand does not have complete control over the operation or how it is called. As well as the implementation details are out of control of the anonymous transition in the PN, are the number and time of calls to getout and putback from the outside not under control of the implementation. Hence, in contrast to the private operations, both public operations are represented by shaded transitions in the RAN. > MediaImpl::checkQuality

resource allocation net

implements

Figure 6: Call semantics of OCoNs Figure 5: Media contract implementation MediaImpl The implementation MediaImpl (Fig. 5, right) de nes the local attributes needed for the implementation, publishes the services to implement getout and putback but uses additional private services, e.g., checkQuality to control incoming Media whether they are ok to be used again or not. Moreover, the RAN implements the protocol provided by the PN. First of all, the RAN states that two external resources imported from other subsystems (shaded hexagons), namely QualityMgmtUnit and the ReportingUnit, are needed for the implementation of the contract. The initial state of a new instance of MediaImpl is de ned to be [Free] by putting

The detailed subwork ows implementing a service provided by a contract are speci ed in a so-called service net (SN). The hierarchical design of the service nets allows for calls to other services during ring inside a transition. Due to the synchronous nature of call and return, this works across hierarchies and can also be used as a wrapper call to services implemented by legacy code. The concept is explained by means of the internal MediaImpl service checkQuality (see Fig. 6). In order to support hierarchical abstraction but keep the essentials also on the abstract call level, calling transitions visualize the signature of the service they call (see Fig. 6, left). The transition here requires a single data parameter and produces an alternative

output to abstract from an internal decision. In conformance with the RAN in gure 5, the operation can only be carried out by instances of the resource MediaImpl in state [Check.1] which is changed either to a MediaImpl of state [Check.2] or [Free]. Because this is speci ed in the RAN, it is not explicitly stated in the textual signature. However, the signature requires an additional parameter of type MediaSpec which is represented by the precondition pool myInfo in the calling net. The result MediaDesc which is expected only in one of the possible decision outcomes is handled in a similar manner. Much like the this in object-oriented programming, the resource which is the carrier of activity is not handled as an explicit parameter. Because both preconditions are ful lled, the action is enabled to re. The unfolded version of the calling transition (see Fig. 6, right) uses two bars to represent the input and output parameters. The gure shows the initial situation after consuming the preconditions. Additional resources are present from the QualityMgmtUnit and the ReportingUnit (cf. the RAN in Fig. 5) in order to carry out the delegated work. For example, the object is inspected, a status record is generated and the QualityControl decides whether the object is ok (event to upper output alternative) or a kind of error report has to be produced. Depending on the decision taken, the nal state of the object will be [Free] or [Check.2]. In the latter case, the error report is also produced as a postcondition. UML structure diagrams are used also to specify the details of the informational aspect, i.e., the data objects which represent entities like users, media, oers, orders, reservations and so on. Specifying the types of such data including their basic functionality in the familiar object-oriented way using attributes, methods, class diagrams and relations among them is quite standard and hence omitted here. As shown in the service net, such descriptions provide the second part of the basis for all remaining aspects because these types are used to type the objects which ow through a system. Whereas this information is not required at the very beginning but may provided step by step when developing work ow schemas, the speci cation of this part of the informational aspect should be done in a manner which is consistent with the usage of subsystems, i.e., de nes classes as local as possible and utilizes the visibility rules to avoid too much global information in the system. For example, a class used to adopt parameters and to wrap the call to a legacy application which is only used in a single subsystem, is put into this subsystem and a change due to using a dierent application with a new wrapper class does not disturb

other subsystems at all.

Figure 7: Customer wants to rent some media It is important for the proposed work ow design strategy that abstraction is supported on dierent levels. Therefore, the mechanisms to describe service nets may be used on dierent levels of detail and completeness. This is demonstrated by considering a speci c partial work ow in the situation where a customer enters the MediaStore and wants to rent some CDs or a book. First of all, it should be checked whether the person is a registered member or not; if so, the member is able to choose some media which he wants to rent. The sketchy description of a use case [11] shown in Fig. 7 is rather incomplete and describes the needed functionality in an informal way as well as the accompanied ow of control and some data aspects.

Figure 8: Assigning resources to subwork ows In Fig. 8, the informational aspect is made more concrete in typing some of the pools. More important is the decision which parts of the system are used to perform the dierent steps by explicitly stating which resources are needed to execute actions. The structure of the system (cf. Fig. 4) has been designed in a manner which provides contracts like, e.g., the RentalMgr, implemented by subsystems for the dierent kinds of functionality. Using these resources when specifying a work ow schema introduces information about the operational aspect and combines it with behavioural aspects. Informal as well as detailed speci cations can be animated to visualize possible work ow executions and the resources involved. If a (partial) model is of suf cient detail and correct w.r.t. type checking, it is possible to simulate it in a real-life environment in order to obtain resource requirements and so on.

4 Related Work Although there are approaches dealing with a diversity of graphical descriptions, the usage of Petri-net variants in work ow languages is widespread, e.g. FUNSOFT Nets [2], HOON [6] and especially the work of van der Aalst, e.g., [13] and colleguages. However, most of the work and even recent approaches dealing with interorganizational work ows, e.g., [14] put their focus on the process aspect and fail to utilize structure to overcome scalability as well as encapsulation problems. The approach described in [15] tries to combine (by means of a so-called system net) all aspects (called perspectives and described in socalled object nets) but its puristic use of mechanisms based solely on nets and their interaction makes the resulting models for real-life examples rather complex. Moreover, the underlying so-called reference nets [9] use the metaphor of nets owing through nets which seems to be too complicated for a non-expert. In the Mentor project [17], state-charts [7] and activitycharts are used to model work ows. The main focus of that project is distributed work ow execution control based on persistent message queues. Whereas these description techniques are close to some of the UML notations, work ow modeling is not embedded in an object-oriented design at all in the Mentor project.

5 Conclusions The method sketched in this paper as well as the OCoN editor and a simple simulator prototype have been used for two years now by students in classes modeling distributed software systems but recently also to describe work ow systems like an agent-based storage system, a rent-a-car service as well as an international UPS-like transport service in detail. At the moment, case studies of business processes and work ow in companies are performed by diploma students in order to evaluate the approach in a real-life business setting.

References [1] W. Brauer, W. Reisig, and G. Rozenberg [eds]. Petri Nets: Central Models (part I)/Applications (part II), volume 254/255 of LNCS. Springer, Berlin, 1987. [2] W. Deiters and V. Gruhn. The FUNSOFT Net Approach to Software Process Management. Int. Journal on SWE and Knowledge Engineering, 2(4), 1994.

[3] Holger Giese, Jorg Graf, and Guido Wirtz. Modeling Distributed Software Systems with Object Coordination Nets. pages 107{116, July 1998. Proc. Int. Symposium on Software Engineering for Parallel and Distributed Systems (PDSE'98), Kyoto, Japan. [4] Holger Giese, Jorg Graf, and Guido Wirtz. Closing the Gap Between Object-Oriented Modeling of Structure and Behavior. In Robert France and Bernhard Rumpe, editors, UML'99, volume 1723 of LNCS, pages 534{549, October 1999. [5] Holger Giese, Jorg Graf, and Guido Wirtz. Seamless Visual Object-Oriented Behavior Modeling for Distributed Software Systems. In IEEE Symposium On Visual Languages, Tokyo, Japan, September 1999. [6] Y. Han and H. Weber. Adaptive Work ow and Software Architecture Thereof. Journal of Integrated Design and Process Science, 2(2):1{21, 1998. [7] D. Harel. Statecharts: A Visual Formalism for complex systems. Science of Computer Programming, 3(8):231{274, 1987. [8] S. Jablonski and C. Bussler. Work ow Management: Modeling Concepts, Architecture and Implementation. Int. Thomson Computer Press, 1996. [9] O. Kummer and F. Wieberg. Renew homepage. Dept. of CS, University of Hamburg, Germany,URL: http://www.renew.de, 1999. [10] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 1997. 2nd Edition. [11] Object Management Group. OMG UML 1.3, June 1999. OMG doc ad/99-06-08. [12] S.K. Shrivastava. Work ow Management Systems. IEEE Concurrency, 7(3), 1999. [13] W.M.P. van der Aalst. The Application of Petri Nets to Work ow Management. Journal of Circuits, Systems and Computers, 8(1):21{66, 1998. [14] W.M.P. van der Aalst. Interorganizational Work ows: An Approach based on MSCs & Petri Nets. System Analysis{Modelling{Simulation, 34(3):335{367, 1999. [15] W.M.P. van der Aalst, D. Moldt, R. Valk, and F. Wienberg. Enacting Interorganizational Work ows Using Nets in Nets. In Proc. of the 1999 Work ow Management Conference, pages 117{136. University of Muenster, Muenster, Germany, 1999. [16] Guido Wirtz, Mathias Weske, and Holger Giese. Extending UML with Work ow Modeling Capabilities. In Fifth International Conference on Cooperative Information Systems (CoopIS-2000), 6-8 September, Eilat, Israel, September 2000. [17] D. Wodtke, J. Weissenfels, G. Weikum, and K. Dittrich. The Mentor Project: Steps towards EnterpriseWide Work ow Management. In Proceedings of the 12th International Conference on Data Engineering, pages 556{565. IEEE CS, 1996.