On the Pitfalls of UML 2 Activity Modeling Tim Schattkowsky Alexander Förster C-LAB University of Paderborn tim@c-lab.de alfo@uni-paderborn.de Abstract With the introduction of new Petri Net-like semantics for Activities in UML 2.0, these have become a complete language for modeling behavior. Thus, UML Activities are nowadays investigated for application in many areas from embedded systems to business process modeling. However, some issues have been discovered that currently seem to limit the practical applicability of Activities. In this paper, we present an overview of the identified semantic and syntactic problems, and point at possible solutions and directions for future research. 1. Introduction The UML 2.0 [10] essentially provides two different types of behavior models. These include the UML State Machines and the UML Activities. While the first are a derivate of Harel’s State Charts [6], the latter are a flow-oriented behavior model. UML Activities model behavior in terms of computational steps connected by data and control flows. This is actually in contrast to former UML versions, where an Activity was a specialized kind of UML State Machine. Although the concrete syntax of the basic model elements has not been changed, the consequences of this change in semantics are essential. These consequences include the fact that since UML State Machines are synchronous, UML 1.x Activities could only perform distributed computational steps in synchrony while the firing of the steps in a UML 2.0 Activity is not synchronized. Furthermore, in a UML 1.x Activity, only one step per concurrent region can be activated at a time. The new semantics allow for models where essentially all steps could be enabled. These new semantics have opened up a number of new application areas for UML Activities, which range from modeling embedded hardware and software [16] to business process modeling [3]. For some applications, like modeling embedded systems, state-oriented modeling seems to be dominant, even in current UML-based approaches like X T UML [11] and xUML [13]. However, as we pointed out in previous work, UML Activities are often a more convenient alternative, both for hardware [15] and for software systems [14] modeling. The reason is that state-oriented modeling often cannot be efficiently applied, e.g., for modeling complex sequential algorithms or fine grained concurrency. Activities do provide concepts that help capturing such behavior much more naturally. Furthermore, for data flow dominated behavior like in multimedia applications, state-oriented modeling is usually ineffective. Thus, flow-oriented modeling languages like Synchronous Data Flow Graphs (SDFGs) [18] are often applied for such applications. Eventually, most of these flow-oriented languages are based on or closely related to Petri Nets [12]. In business process modeling, flow-based behavior modeling is already widely applied, e.g., in the form of Event-Driven Process Chains [7] or similar notations. Again, these notations are more or less closely related to Petri Nets. Nowadays, the UML has become the de-facto standard for modeling software systems. Thus, UML Activities are increasingly applied for modeling flow- oriented behavior, both as an alternative to state- oriented modeling and as a replacement for flow- oriented modeling, e.g., using Petri Nets. Although the new UML 2.0 semantics for Activities seem to be close to high-level variants of Petri Nets, there are essential differences. These differences lie mainly in the fact that unlike in a Petri Net the activation of computational steps in a UML 2.0 Activity is not completely local, and that some of the model elements have quite complex semantics. The complexity of the new Activity semantics seems to be induced both by the increased abstraction compared to other flow-oriented languages and the urge to maintain a certain syntactic and semantic compatibility with UML 1.x Activities. International Workshop on Modeling in Software Engineering (MISE'07) 0-7695-2953-4/07 $20.00 © 2007 Authorized licensed use limited to: IEEE Xplore. Downloaded on January 8, 2009 at 05:22 from IEEE Xplore. Restrictions apply.