Analysing UML Active Classes and Asso ciated State Machines A Lightweight Formal Approach G Reggio E Astesiano C Choppy and H Hussmann DISI Universita di Genova Italy LIPN Institut Galilee Universite Paris XI I I France Department of Computer Science Dresden University of Technology Germany Abstract We consider the problem of precisely dening UML active classes with an asso ciated state chart We are convinced that the rst step to make UML precise is to nd an underlying formal mo del for the systems mo delled by UML We argue that lab elled transition systems are a sensible choice indeed they have worked quite successfully for languages as Ada and Java Moreover we think that this mo delization will help to understand the UML constructs and to improve their use in practice Here we present the lab elled transition system asso ciated with an active class using the algebraic sp ecication language CASL The task of making precise this fragment of UML raises many questions ab out b oth the precise meaning of some constructs and the soundness of some allowed combination of constructs Intro duction The Unied Mo deling Language UML is an industry standard language for sp eci fying software systems This language is unique and imp ortant for several reasons UML is an amalgamation of several in the past comp eting notations for ob ject oriented mo delling For a scientic approach it is an ideal vehicle to discuss funda mental issues in the context of a language used in industry Compared to other pragmatic mo delling notations in Software Engineering UML is very precisely dened and contains large p ortions which are similar to a formal sp ecication language as the OCL language used for the constraints It is an imp ortant issue in Software Engineering to nally close the gap b etween prag matic and formal notations and to apply metho ds and results from formal sp ecication to the more formal parts of UML This pap er presents an approach contributing to this goal and has b een carried out within the Europ ean Common Framework Initiative CoFI for the algebraic sp ecication of software and systems partially supp orted by the EU ESPRIT program Within the CoFI initiative which brings together research institutions from all over Europ e a sp ecication language called Common Algebraic Sp ecication Language CASL was develop ed which intends to set a standard unifying the various approaches to algebraic sp ecication and sp ecication of abstract data typ es It is a goal of the CoFI group to closely integrate its work into the world of practical engineering As far as sp ecication languages are concerned this means an integration with UML which may form the basis for extensions or exp erimental alternatives to the use of OCL That would allow for instance to sp ecify userdened data typ es that just have values but do not b ehave like ob jects to use algebraic axioms as a constraints These new constraints may cover also b ehavioural asp ects b ecause there exist extensions of algebraic languages that are able to cover with them whereas OCL do es not seem to have any supp ort for concurrency The longterm p ersp ective of this work is to build a bridge b etween UML sp ecications and the p owerful animation and verication to ols that are available for algebraic sp ecications To this end we need to precisely understanding formally dening the most relevant UML features In this pap er we present the results of such formalization work which was guided by the following ideas Real UML Our concern is the real UML ie all or b etter almost all its features without simplications and or idealizations We are not going to consider a small OO language with a UML syntax but just what it is presented in the ocial OMG do cu mentation shortly UML from now on Based on an underlying mo del We are convinced that the rst step to make UML precise is to nd an underlying formal mo del for the systems mo delled by UML in the following called UMLsystems Our conviction also comes from a similar exp erience the two rst authors had many years ago when tackling the problem of the full formal denition of Ada within the ocial EU pro ject see There to o an underlying mo del was absolutely needed to clarify the many ambiguities and unanswered questions in the ANSI Manual We argue that lab elled transition systems could b e a sensible mo del choice indeed they were used quite successfully to mo del concurrent languages as Ada but also a large part of Java Lightweight formalization By lightweight we mean made by using the most simple formal to ols and techniques precisely lab elled transition systems algebraically sp ecied using a small subset of the sp ecication language CASL conditional sp ecica tion with initial semantics Integrated with the formalization of the other fragments of UML In contrast to many other pap ers on UML semantics we more or less ignore the issue of class diagram 1 semantics here and concentrate on the state machines However the ultimate goal of this work is to have an approach by which it is easily p ossible to integrate semantically the most relevant diagram typ es For this reason we are using an algebraic approach to the semantics of state machines since it is well known that class diagrams can b e mapp ed relatively easily onto algebraic sp ecications The algebraic semantics describ ed here enables an algebraic access to the semantics also of active not only of passive classes Usually an active class is statically describ ed in the class diagram and dynamically describ ed in an asso ciated statechart diagram The formalization of active classes and state machines has lead to p erform a thor ough analysis of them uncovering many problematic p oints Indeed the ocial informal semantics of UML rep orted in UML is in some p oints either incomplete or ambigu ous or inconsistent or dangerous ie the semantics is clearly formulated but the allowed usages seem problematic from a metho dological p oint of view To stress this asp ect and PROBLEM to highlight them to help the reader we have used the mark pattern In Sect we dene the subset of the active classes with state machines that we con sider Then in Sect and we intro duce the used formal techniques lab elled transition 1 Following UML terminology state machine is the abstract name of the construct whereas state chart is the name of the corresp onding diagram here we always use the former systems and algebraic sp ecications and present step after step how we have built the lts mo delling the ob jects of an active class with an asso ciated state machine Due to lack of ro om part of the denition is rep orted in App endix A while the complete formal mo del rather short and simple is in Intro ducing UML Active Classes and State Machines The UML denes a visual language consisting of several diagram typ es These diagrams are strongly interrelated by a common abstract syntax and are also related in their semantics The semantics of the diagrams is currently dened by informal text only The most imp ortant diagram typ es for the direct description of ob jectoriented soft ware systems are the following Class diagrams dening the static structure of the software system ie essentially the used classes their attributes and op erations p ossible asso ciations relationships b etween them and the inheritance structure among them Classes can b e passive in which case the ob jects are just data containers For this pap er we are interested in active classes where each ob ject has its own threads of control Statechart diagrams state machines dening the dynamic b ehaviour of an individ ual ob ject of a class over its lifetime This diagram typ e is very similar to traditional Statecharts However UML has mo died syntax and semantics according to its over all concepts Interaction diagrams illustrating the interaction among several ob jects when carrying out jointly some use case Interaction diagrams can b e drawn either as sequence diagrams or as collab oration diagrams with almost identical semantics but dierent graphical representation A UML state machine is very similar to a classical nite state machine It depicts states drawn as rounded b oxes carrying a name and transitions b etween the states A transition is decorated by the name of an event p ossibly followed by a sp ecication of some action after a slash symb ol The starting p oint for the state machine is indicated by a solid black circle an end p oint by a solid circle with a surrounding line The complexity of UML state machines compared to traditional nite state machines comes from several origins The states are interpreted in the context of an ob ject state so it is p ossible to make reference eg in action expressions to ob ject attributes There are constructs for structuring state machines in hierarchies and even concur rently executed regions There are many sp ecialized constructs like entry actions which are red whenever a state is entered or state history indicators In order to simplify the semantical consideration in this pap er we assume the follow ing restrictions of dierent kinds Please note that none of these assumptions restricts the basic applicability of our semantics to full UML state machines We do not consider the following UML state machine constructs b ecause they can b e replaced by equivalent combinations of other constructs Submachines We can eliminate submachines by replacing each stub state with the corresp onding submachine as UML p states It is a shorthand that implies a macrolike expansion by another state machine and is semantically