HiLA: High-Level Aspects for UML State Machines - CiteSeerX

HiLA: High-Level Aspects for UML State Machines Gefei Zhang

Matthias Hölzl∗

Ludwig-Maximilians-Universität München

{gefei.zhang, matthias.hoelzl}@pst.ifi.lmu.de

ABSTRACT UML state machines are widely used for modeling software behavior. However state-crosscutting behaviors, such as synchronization or execution history dependence, are hard to model as the model elements that realize them are dispersed throughout the state machine. We present High-Level Aspects (HiLA) for UML state machines to address this problem. HiLA facilitates modeling crosscutting behaviors in one single place and separately from the base machine, and thus improves the modularity of the software design. HiLA provides facilities for specifying multiple history-dependent and concurrent aspects that extend the behavior of a base state machine in a straightforward, mostly declarative style; it therefore allows the designer to build models at a high level of abstraction.

1.

INTRODUCTION

UML state machines are a popular language for modeling software behavior, for example for reactive systems [6]. However, state machines are a low-level modeling construct with poor modularity: even many simple features, such as synchronization of parallel regions and behaviors based on the execution history, cannot be modeled in a localized way. Instead implementation details are scattered over large parts of the state machine, resulting in a model that is hard to read, hard to maintain and prone to errors. This problem has been addressed by several aspect-oriented approaches, see Sect. 4. Most approaches (see [3, 10, 23]) view aspects as model transformations and allow the modeler to define, in separate aspects, transformations of the base machine by introducing new model elements or removing existing ones. However, model transformations are themselves low-level instruments. While some features lend themselves to a concise description as graph transformations, other aspects for seemingly simple features require complex transformations, since the modeler has to specify in detail how to achieve a task instead of simply defining what to do. For example, an aspect modeling mutual exclusion of states in orthogonal regions has to introduce a global

variable as semaphore, select all involved states, extend their entry actions by decreasing the value of the semaphore, extend their exit actions by increasing it, and then select all transitions entering these states and extending their guards to block a transition if necessary. Understanding these aspects amounts to understanding the result of the weaving process. Moreover, handling interference between aspects is still insufficiently supported. It has been proposed (see [10]) to formulate aspects as graph transformations and to perform syntactical conflict detection by confluence checking of the graph grammar. However, syntactical conflicts are not expressive enough for many real-world applications: two aspects that modify the same model elements do not necessarily interfere from a semantic point of view. To give a simple example, if one aspect logs firing of transitions, and another aspect counts how often each transition was taken, these aspects are syntactically in conflict, even though applying them both poses no semantical problems. Mechanisms for resolving syntactical conflicts have been proposed, e.g., by layering aspects (see [3]), but these methods rely on manual resolution by the modeler. We present High-Level Aspects (HiLA) for UML state machines. This approach is based on our previous work described in [24], and allows a mostly declarative specification of concerns such as synchronization of orthogonal regions or history-based behaviors. We minimize aspect interference by weaving them into orthogonal regions and give a conservative criterion for determining semantical interference of aspects. The semantics of aspects in HiLA is defined independently of any concrete base machine; the connection between aspects and base machine is provided by a separate binding. The rest of the paper is organized as follows: in the following Sect. 2 we give an overview of the syntax and informal semantics of UML state machines, and show some of their modularity problems. In Sect. 3 we present our aspect language, HiLA, and briefly discuss its support for applying multiple aspects simultaneously. Related work is discussed in Sect. 4. Finally, we conclude and outline some future work.

∗

This work has been partially sponsored by the DFG project M AEWA II (WI 841/7–2) and the EU project S ENSORIA (IST-2 005-016004).

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$10.00.

2.

UML STATE MACHINES

UML state machines provide a behavioral view of software systems. Figure 1 shows a state machine of a sentinel in a computer game, where it may be idle, patrolling through three rooms, fighting, or, if its power (p) is not greater than 0, dying. Power is changed by fights (this is not explicitly modeled in the state machine), where an increase of p indicates a win and a decrease of p indicates a defeat. The sentinel can also gain power when it is Idle.

2.1

Syntax and Semantics

We briefly review the syntax and semantics of UML state ma-

Running Room1 * / defer [(inState(Patrolling) || inState(Fighting)) && defeat(2) 0 branch, the new value of p is compared with oldp. If p is less than oldp, which means the fight was lost, the number of losses in the current room is increased by one; finally, the transitions entering Room2 and Room3 must be extended by yet another proposition to usher the sentinel into the right room. The above examples exhibit two inherent weaknesses of UML state machines: 1) individual features can not be modeled separately, but are entangled with each other, and 2) the level of abstraction at which features are modeled is too low.

3.

HILA

The language High-Level Aspects (HiLA), an aspect-oriented extension of UML state machines, is defined in [24] to address these weaknesses. An aspect is a graphical specification of an additional or alternative behavior of a UML state machine (called the base machine), to be executed at certain “interesting” points of time in the base machine’s execution. These points of time are when a transition is being fired with the state machine in certain state configurations, or if firing the transition would lead to certain state configurations. The transitions are specified by the pointcut of the aspect, the behavior to execute by its advice. We say the aspect advises the transitions selected by the pointcut. The concrete syntax of high-level aspects is shown in Fig. 3a, the oblique identifiers being place holders. State* is a set of states. The selector may be either «before» or «after». A pointcut labeled with «after» selects all transitions leaving any state in State* while the state machine is in a state configuration containing all states in State*. Similarly, a pointcut labeled with «before» selects each transition T entering any state contained in State*, but only in active state configurations where after taking T all states in State* will become active. Alternatively, the selector may be empty and a set of states and transitions ST* may be specified. In this case the pointcut matches all transitions in ST* in active state config-

Par1 Par2

«aspect» Name «pointcut» selector State*

ST*

{Constraint} «advice» AdvBody

(a) Aspects

Label 1 Label 2 Label 3

Par1 «history» Par2 Name «history» hs1 = # Pattern1 hs2 = # Pattern2

(b) History properties

Figure 3: Concrete syntax of HiLA aspects

urations in which all states in ST* are active. The pointcut may contain a constraint. In this case, the advice is only executed when the constraint is satisfied. The advice of an aspect is also a state machine, where the final states may be labeled. When a transition advised by an aspect is taken, the advice of that aspect is executed; when the advice state machine finishes, execution of the base machine is resumed with a transition from the advice to the target state of the advised transition. The labels specify additional constraints on this transition: if the final state is labeled 1 this transition is enabled only if after its execution the active state configuration matches the pointcut of the aspect; if the final state is labeled 0 the transition is enabled only if after its execution the active state configuration does not match the pointcut. In both cases the completion event is deferred. In Fig. 3 three resumption strategies are defined. Depending on the execution of AdvBody, one of them will be used at run time. To increase the reusability, aspects are usually defined as UML templates with parameters, which are then bound by the designer of concrete aspects. Fig. 3a shows two parameters: Par1 and Par2. In HiLA, properties of the execution history are specified by history properties. History properties are defined in history aspects, which are identified by the label «history», as shown in Fig. 3b. A history property contains a pattern consisting of active state configurations and guards, and its value is the number of matches of this pattern by the base machine’s execution history where the guards evaluate to true. Fig. 3b shows two history properties, hs1 and hs2. History properties can be used in pointcuts and advices to define history-sensitive behavior. In addition, HiLA also allows the use of low-level aspects, i.e., transformational aspects. We adopt the syntax presented in [23], but other approaches that define aspects by model transformations, such as [22], could also be used. In HiLA, a low-level aspect contains a «transformation pointcut» and a «transformation advice». The transformation pointcut contains a pattern that can match a sub-structure of the base machine. The meaning of the aspect is that the parts of the base machine that match the pattern should be replaced by the advice.

3.1

HiLA Aspects

In the following, we use the previously described sentinel as a running example to explain the syntax and informal semantics of HiLA in more detail. For a formal semantics, see [9]. Figure 2 shows the base machine for an aspect-oriented model of the sentinel. Note that this state machine is “unfinished” in the sense that it only models the very basic behavior of the sentinel; on the other hand it describes these fundamentals much more concisely than Fig. 1 where the basic behavior is intertwined with several extensions. Using HiLA we can model additional behaviors as individual

aspects; in many cases this can even be done for properties that are specified using a multitude of elements (vertices and transitions) spread throughout the state machine. This way, the modeling of each behavior is kept in a single, dedicated place, without entangling different properties in the same base machine elements. The overall effect is that a simple and comprehensible base machine can be refined and extended with additional behaviors, where each behavior can be developed and understood (mostly) independently from the concrete base machine to which it is applied. To make full use of this approach it is necessary to apply multiple aspects simultaneously to a single state machine, to detect errors arising from interactions between aspects, and to provide the modeler with possibilities to address these errors. We will address this topic in the next section and concentrate on individual aspects for the remainder of this section. Aspect MutexTrans in Fig. 4 is a simple yet powerful solution for modeling the first feature described on the previous page, not changing rooms while in state Idle. MutexTrans is a general solution that can be instantiated with any transition and any state to prevent execution of the transition while the state is active. The aspect has three formal parameters: A and B specify the transition, C the state. All parameters are used in the A: State B: State pointcut which selects the transi«aspect» C: State MutexTrans tions between A and B while the «pointcut» lower region is in state C. The adA B vice disallows the selected transition (while in state C) by transitionC ing to a final state labeled 0. It is very simple to exclude cer«advice» tain transitions from modification 0 by the aspect: according to the informal specification of the example the aspect should not block selfFigure 4: Aspect for mutransitions from a room to itself. To tual exclusion between achieve this, we bind A and B with transition and state all pairs of different rooms (i.e., all combinations of states in the upper region of the base machine with A 6= B) and C with Idle; this binding of the aspect tells the sentinel to block any transition between different rooms while it is in state Idle, i.e., room change is only enabled when the sentinel if Patrolling or Fighting. To model the second feature on the A: State «aspect» B: State previous page, that the sentinel does MutexState not fight in Room1, we need a slight «pointcut» variation of the MutexTrans aspect. In«before» stead of excluding a specific transiA tion while a particular state is active B in an orthogonal region we want mutual exclusion between two states in «advice» orthogonal regions. Again we define 0 a more general aspect that can describe mutual exclusion between any Figure 5: Aspect for two states in orthogonal regions, see mutual exclusion beFig. 5. The pointcut of this aspect tween two states matches all transitions that would lead to states A and B becoming active at the same time, i.e., all transitions into state A when state B is active, all transitions into B when state A is active, and all compound transition causing A and B to become active simultaneously. The advice is again a simple transition into a final state labeled 0, which inhibits the selected transition. By instantiating A with Room1 and B with Fighting we achieve the desired behavior: the sentinel may not start a fight (transition into state Fighting) while it

is in Room1 and it may not enter Room1 while engaged in a fight. In the last aspect we address the third requirement, always going to the room where the fewest fights were lost so far. This feature obviously depends on the execution history of the state machine; we use a history property to model it. While the desired behavior could be approximated using high-level aspects and a final-state label goto (not introduced in this paper), it is, in this case, more elegant to modify the guards of the base state machine with lowlevel aspects. The history aspect StateIf in Fig. 6a takes two parameters (N and C) and defines a history property N which stores for each state how often the state has been active while constraint C was satisfied, i.e., for each instantiation of StateIf the value of N1 is a function from states to natural numbers. Note that the operator # counts the number of occurrences in which the pattern after # matches during the execution of the base machine.

«history» StateIf N(S) = #

N: String C: Constraint

S {C}

(a) History aspect

S: State T: State C: Constraint

«aspect» IntroduceGuard «transformation pointcut» S

?E[?G] / ?A

«transformation advice» ?E[?G && C] / ?A S

T

T

(b) Transformation aspect

Figure 6: Aspects for introducing history-dependent behavior The pointcut of the template IntroduceGuard (Fig. 6b) selects all transitions from S to T and stores the trigger, guard and action of the selected transition in internal variables ?E, ?G and ?A, respectively. Its advice expands the guard by conjoining another constraint C to the existing constraints; unguarded transitions are treated as guarded by [true]. With these aspect templates, the feature “choose the room where the fewest fights were lost so far” can be modeled by the instantiations shown in Fig. 7. Instantiating aspect template StateIf from Fig. 6a by binding N with a and C with the constraint p@pre > p@post yields a history property named a which stores for each state how often p was decremented, i.e., how often a fight was lost, while the state was active. The history property a is then used to introduce new guards: Figure 7 instantiates template IntroduceGuard twice by binding S with Room1, binding T with Room2 (resp. Room3) and binding C with min(a[Succ(Room1)]) == a(Room2) (resp. min(a[Succ(Room1)]) == a(Room3)). These bindings ensure that each transition from Room1 to either Room2 or Room3 is only enabled when the constraint is satisfied. min(a[Succ(Room1)]) yields the minimum value of a for all successor states of Room1. The 1 More precisely: the value of the name bound to N in this instantiation.

Template

Binding C 7→p@pre > p@post N 7→a IntroduceGuard S 7→Room1 T 7→r ∈ {Room2, Room3} G 7→min(a[Succ(Room1)]) == a(r) StateIf

Figure 7: Aspect instances modeling the feature that the sentinel always chooses the room with the least lost fights so far

transition is thus only enabled when there is no other target room in which the sentinel has lost fewer fights. Note that, even though the transformation itself is described by a low-level aspect, the lucidity of this aspect depends to a large degree on the history property which is a declarative high-level construct.

3.2

Multiple Aspects

As mentioned before, for any state-machine aspect language to be useful it is necessary that multiple, independently developed aspects can be applied to a single base machine and that errors arising from the interaction of the aspects can be detected. The possible interactions between aspects have been classified in various ways; here we use a slightly shortened and adapted version of the one presented in [1]: 1. Applying one aspect can change the places where another aspect is applicable. 2. The result of applying two aspects can be dependent on the order in which the aspects are applied. 3. At run-time, one aspect can modify state affecting the behavior of another aspect; 4. At run-time, one aspect can change the control-flow of the system, causing another aspect to never be applied. When discussing these effects in HiLA we have to distinguish between low-level and high-level aspects. Low-level aspects define model transformations on the base state machine and, like aspects defined by other approaches based on model-transformation, can change the base state machine in arbitrary ways. Therefore they can produce all four kinds of interference. The first two kinds can be eliminated by insisting that the graph transformation system defined by all aspects be confluent, but, as we have argued in the introduction, this condition is often too restrictive. Individual high-level aspects, on the other hand, have a welldefined meaning: whenever a transition is taken that matches the pointcut of the aspect, the advice of the aspect is executed. We use the inherent parallelism of state machines and extend this semantics to the application of multiple aspects: whenever a transition of the base state machine is taken, the advices of all aspects with matching pointcuts are executed in parallel. Therefore, the first two kinds of aspect interference cannot happen for high-level aspects. The modification of shared state is difficult to detect in the general case; in particular, since the event pool is a global resource even performing a transition without side effects may consume an event that would otherwise have been deferred and hence interfere with another aspect. However, it is often possible to eliminate these interferences by defining advice that modifies no globally visible state and where all transitions are triggered either by completion events or by events with private names. A variant of the last kind of interference can appear if one concurrently executing aspect finishes in a final state labeled 0 and another finishes in a final state labeled 1 as then the resulting transition back to the base state machine is never activated. Similar interferences are also possible with final states labeled goto which are not discussed in this paper. Unfortunately, this condition is statically undecidable since choices may make use of arbitrary functions and are therefore Turing complete. But a simple conservative approximation works well in many practical cases: two aspects are potentially in conflict for a base state machine M if the pointcuts of both match some transition T of M and if one aspect contains a final state labeled 0 and the other one a final state labeled 1.

4.

RELATED WORK

Our idea of high-level aspects of state machines was inspired by dynamic aspect-oriented programming languages such as JAsCo [20] and Object Teams [8]. Using history properties to quantify over the execution history is reminiscent to the trace aspects of Arachne [5]. In the realm of modeling languages and state machines in particular, Altisen et al. [2] propose aspects for Mealy automata. Pointcuts are also defined as automata. In comparison, the weaving algorithm of our approach is much more elaborate, mainly due to the richer language constructs of the UML. Because of the wider acceptance of the UML, our approach is also more tightly connected to common practice. State-based aspects in reactive systems is also supported by JPDD [18] and Telelogic TAU[25], both of which facilitate specification of high-level pointcuts in flat state machines. In comparison, HiLA was designed to be applicable to parallel and hierarchical UML state machines, where in general concurrent threads are contained, and concerns such as thread synchronization increase the difficulty of correct and modular modeling. We believe that HiLA provides valuable help to address these problems. Addressing the complete UML, Theme/UML [3] models different features in different models (called themes) and uses UML templates to define common behavior of several themes. General composers like GeKo [14] and MATA [21] can be used for weaving. The aspects of these approaches are low-level, which means modeling non-trivial features often necessitates rather complex aspects, and comprehension of the aspects amounts to understanding the weaving result. Aspect interference is an intrinsic problem of aspect-oriented techniques. It has been addressed in a large amount of publications, for an overview, see [1, 12]. Notations of precedence declaration are proposed in, e.g., [11, 15, 17, 25]. Techniques to detect interference proposed so far include detecting shared fields addressed by read and write operations [19], a formal foundation of AOP languages using Conditional Program Transformations [?], and graph transformations [1, 22]. These approaches focus on sequential programming languages. In comparison, HiLA exploits the concurrency of state machines and weaves aspects into parallel regions to solve the problem of join points being changed or the result of weaving depending on the weaving order. Weaving into parallel constructs is also proposed in [4], where an approach to concurrent event-based AOP (CEAOP) is defined. Concurrent aspects can be translated into Finite Sequential Processes and checked with the LTSA model-checker. Many similarities exist between CEAOP and the work presented in this paper; however the two approaches take complementary viewpoints in the sense that our work is primarily concerned with a state-based view of AOP that allows, e.g., the definition of mutual exclusion in state machines, whereas the CEAOP is mostly concerned with aspects over event sequences. CEAOP provides operators to combine aspects, e.g., by executing different aspects in sequence or in parallel; our approach is more restricted since our aspects are always executed in parallel. Furthermore, pointcuts in CEAOP are actually similar to sequences of pointcuts according to the usual definition, and pieces of advice are executed at different points of this sequence. This makes it easy to define stateful aspects. While our history mechanism can also be used to define these kinds of aspects, the definition has to be given in several parts and is more cumbersome than in CEAOP. On the other hand, the history mechanism in our approach can take into account values of context variables which significantly increases the expressive power; it seems that this possibility does currently not exist in CEAOP.

5.

CONCLUSIONS AND FUTURE WORK

We have presented HiLA, an aspect-oriented approach to modeling with state machines. Our aspects can considerably enhance the modularity, and thus the comprehensibility and maintainability, of UML state machines. Compared to other aspect-oriented state machine approaches, HiLA is higher level in that it allows the pointcut to utilize information of the execution history, as well as address the active state configuration as a whole. History-dependent features and synchronization of orthogonal regions can therefore be modeled in HiLA in a highly modular manner. Future work includes a graphical modeling tool, combining HiLA with other aspect-oriented UML diagrams (e.g. [23]) and generation of aspect-oriented programs out of HiLA aspects.

6.

REFERENCES

[1] M. Aksit, A. Rensink, and T. Staijen. A Graph-Transformation-Based Simulation Approach for Analysing Aspect Interference on Shared Join Points. In Proc. 8th Int. Conf. Aspect-Oriented Software Development (AOSD’09), pages 39–50, 2009. [2] K. Altisen, F. Maraninchi, and D. Stauch. Aspect-Oriented Programming for Reactive Systems: Larissa, a Proposal in the Synchronous Framework. Sci. Comp. Prog., 63(3):297–320, 2006. [3] S. Clarke and E. Baniassad. Aspect-Oriented Analysis and Design. Addison-Wesley, 2005. [4] R. Douence, D. L. Botlan, J. Noyé, and M. Südholt. Concurrent Aspects. In Proc. 5st Int. Conf. Generative Programming and Component Engineering (GPCE’06), pages 79–88. ACM, 2006. [5] R. Douence, T. Fritz, N. Loriant, J.-M. Menaud, M. Ségura-Devillechaise, and M. Südholt. An Expressive Aspect Language for System Applications with Arachne. In Mezini and Tarr [13], pages 27–38. [6] D. Drusinsky. Modeling and Verification Using UML Statecharts. Elsevier, 2006. [7] G. Engels, B. Opdyke, D. C. Schmidt, and F. Weil, editors. Proc. 10th Int. Conf. Model Driven Engineering Languages and Systems (MoDELS’07), volume 4735 of Lect. Notes Comp. Sci. Springer, 2007. [8] S. Herrmann. Object Teams: Improving Modularity for Crosscutting Collaborations. In M. Aksit, M. Mezini, and R. Unland, editors, Rev. Papers Int. Conf. NetObjectDays (NODe’02), volume 2591 of Lect. Notes Comp. Sci., pages 248–264. Springer, 2003. [9] M. Hölzl, A. Knapp, and G. Zhang. Semantics of HiLA. Technical Report LMU-IFI-PST 0901, Ludwig-Maximilians-Universität München, 2009. [10] P. K. Jayaraman, J. Whittle, A. M. Elkhodary, and H. Gomaa. Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis. In Engels et al. [7], pages 151–165. [11] J. Kienzle and S. Gélineau. AO Challenge — Implementing the ACID Properties for Transactional Objects. In R. E. Filman, editor, Proc. 5th Int. Conf. Aspect-Oriented Software Development (AOSD’06), pages 202–213. ACM, 2006. [12] G. Kniesel. Detection and Resolution of Weaving Interactions. In A. Rashid and H. Ossher, editors, Trans. Aspect-Oriented Software Development V, number 5490 in Lect. Notes Comp. Sci. Springer, 2009. [13] M. Mezini and P. L. Tarr, editors. Proc. 4th Int. Conf. Aspect-Oriented Software Development (AOSD’05). ACM,

2005. [14] B. Morin, J. Klein, O. Barais, and J.-M. Jézéquel. A Generic Weaver for Supporting Product Lines. In Proc. 13th Int. Wsh. Software Architectures and Mobility (EA’08), pages 11–18. ACM, 2008. [15] I. Nagy, L. Bergmans, and M. Aksit. Composing Aspects at Shared Join Points. In R. Hirschfeld, R. Kowalczyk, A. Polze, and M. Weske, editors, Proc. Net.ObjectDays (NODe’05), volume P-69 of Lect. Notes Informatics, pages 19–38. Gesellschaft für Informatik, 2005. [16] Object Management Group. OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.2. OMG Available Specification, OMG, 2009. http://www.omg. org/spec/UML/2.2/Superstructure. [17] Y. R. Reddy, S. Ghosh, R. B. France, G. Straw, J. M. Bieman, N. McEachen, E. Song, and G. Georg. Directives for Composing Aspect-Oriented Design Class Models. In A. Rashid and M. Aksit, editors, Trans. Aspect-Oriented Software Development I, volume 3880 of Lect. Notes Comp. Sci., pages 75–105. Springer, 2006. [18] P. Sánchez, L. Fuentes, D. Stein, S. Hanenberg, and R. Unland. Aspect-Oriented Model Weaving Beyond Model Composition and Model Transformation. In K. Czarnecki, I. Ober, J.-M. Bruel, A. Uhl, and M. Völter, editors, Proc. 11th Int. Conf. Model Driven Engineering Languages and Systems (MoDELS’08), volume 5301 of Lect. Notes Comp. Sci., pages 766–781. Springer, 2008. [19] M. Störzer, F. Forster, and R. Sterr. Detecting Precedence-Related Advice Interference. In Proc. 21st IEEE/ACM Int. Conf. Automated Software Engineering (ASE’06), pages 317–322. IEEE, 2006. [20] W. Vanderperren, D. Suvée, B. Verheecke, M. A. Cibrán, and V. Jonckers. Adaptive Programming in JAsCo. In Mezini and Tarr [13], pages 75–86. [21] J. Whittle and P. K. Jayaraman. MATA: A Tool for Aspect-Oriented Modeling based on Graph Transformation. In Proc. 11th Int. Wsh. Aspect-Oriented Modeling (AOM@MoDELS’07), 2007. [22] J. Whittle, A. Moreira, J. Araújo, P. K. Jayaraman, A. M. Elkhodary, and R. Rabbi. An Expressive Aspect Composition Language for UML State Diagrams. In Engels et al. [7], pages 514–528. [23] G. Zhang. Towards Aspect-Oriented Class Diagrams. In Proc. 12th Asia-Pacific Software Engineering Conf. (APSEC’05), pages 763–768. IEEE, 2005. [24] G. Zhang, M. Hölzl, and A. Knapp. Enhancing UML State Machines with Aspects. In Engels et al. [7], pages 529–543. [25] J. Zhang, T. Cottenier, A. van den Berg, and J. Gray. Aspect Composition in the Motoroal Aspect-Oriented Modeling Weaver. Journal of Object Technology, 6(7):89–108, 2007.