UML Modeling of Static and Dynamic Aspects Vincenzo Grassi °, Andrea Sindico °* ° Università di Roma “Tor Vergata”, Italy * Elettronica S.p.A., Italy [email protected], [email protected]

ABSTRACT The goal of Aspect Oriented Modeling (AOM) is to bring at the design level the ideas of aspect orientation. To support this goal, we propose a UML-based graphical notation for the modeling of aspects that crosscut both the static and dynamic structure of the primary model of an application. Our notation allows us to model these aspects independently of the primary model, and of specific Aspect Oriented languages implementation.

Keywords Aspect Oriented Modeling, UML, static aspect, dynamic aspect.

1. Introduction The Aspect Oriented Programming (AOP) paradigm [10] attempts to aid programmers in achieving the separation of concerns by focusing on the modularization and encapsulation of crosscutting concerns. To create more powerful and elaborate systems, it is inevitable to consider aspects starting from the design phase. For this reason AOP, which provides software mechanisms for encapsulating crosscutting features in system's code, has evolved into Aspect-Oriented Modeling (AOM) [1, 3, 4, 8, 13, 20], where crosscutting features are modeled as aspects and composed with the primary design model to form integrated design-level models. However, while AOP has matured in the past years, proposed AOM approaches are still not completely satisfactory. For example, in some cases they do not fully support the modeling of aspects separately from the primary system model, which is important to bring at the model level the separation of concerns principle. In other cases, they appear too strictly tied to existing AOP implementations. In this position paper we propose a step toward the definition of a graphical notation for AOM, based on UML. Our goal is to contribute to rise the level of abstraction for aspect-oriented software development. To this end, the main features of our notation are the possibility of modeling crosscutting concerns independently of the model of other system component, and the independence from particular AOP language implementations. Moreover, an additional goal is to remain compliant as much as possible with the UML standard [15], to facilitate the integration of our approach into UML based design and development tools. Our proposal consists of three parts. The first one contains constructs which support the modeling of static crosscutting concerns that change the static structure of a system. The second part consists of constructs which support the modeling of dynamic crosscutting concerns that change the dynamic evolution of a system (that is, its execution). The third part consists of a construct called Aspect, which is the container that takes together

the models of logically related static and dynamic crosscutting concerns. For each of these three parts we provide a brief description of its main features and how they are modeled. We also provide examples of how these design-level graphical models can be mapped to implementations in a specific AOP language (AspectJ [11]). However, we point out that, even if we adopt in our presentation the AspectJ terminology, our modeling approach is independent of specific implementations. The examples we provide refer to a security related crosscutting concern whereby, in a software system, only authorized managers are allowed to add or delete users. The approach for expressing the solution to this concern as an aspect is inspired by [8] where an aspect model that describes the general structure and behavior of an authorization solution is defined using UML 2 templates [15]. Classes, methods and parameters used in our examples are similar to those from [8] and will not be described here due to space limitations.

2. Static aspects modeling A static crosscutting concern operates over the static structure of a type hierarchy specifying how it must be changed by the addition of new elements. Analogously to the AspectJ terminology we call this kind of concern inter-type declaration. In our profile an intertype declaration is modeled by an Inter-type declaration diagram (ITDD). An ITDD consists of two parts, as depicted in figure 1 for the security concern example. The left part of an ITDD contains a class diagram, which specifies a pattern to select the classes affected by the inter-type declaration. Names in the left part can be specified using regular expressions, to select multiple classes and to specify constraints concerning classes, attributes, methods and their relationships. Classes in the primary model that match with this pattern are modified as specified in the right part of the ITDD, that describes the elements (e.g. attributes or methods) to be added to the matching classes. An ITDD is characterized by a name which is unique in the scope of the Aspect it belongs to. Figure 1 shows an ITDD that models an inter-type declaration for the security-related crosscutting concern example. Its left part specifies that the matching classes are the classes called Manager and UsrMgmt, whatever attributes and methods they have (as indicated by the '*' in their attributes and operations compartments). The right part specifies that we want to modify them by adding a boolean attribute named isAuthorized to the Manager class and a method whose signature is void checkAuthorization(Manager man) to the UsrMgmt class. The idea behind these introductions is that the

UsrMgmt::checkAuthorization method will check whether a Manager object is allowed to add or delete system's users, setting to true its isAuthorized attribute in the positive case. How this method is implemented does not strictly concern AOM, so we omit its specification. <> authorizationIntroduction

Manager Manager

bool isAuthorized

* *

*

UsrMgmt

UsrMgmt

*

* *

void checkAuthorization(Manager man)

Figure 1: Inter-type declaration diagram (ITDD) for the security concern example

3. Dynamic aspects modeling While static crosscutting concerns affect the static structure of a program, dynamic crosscutting concerns change the way a program executes. Using the AspectJ terminology, we call this kind of concern advice. In our profile an advice is modeled by an advice diagram (AD). Figure 2 depicts the structure of an AD. Similarly to an ITDD, an AD consists of two parts, which play in the dynamic setting analogous roles as the two parts of an ITDD in their static setting. Indeed, the left part of an AD contains the model of what in AspectJ is called a pointcut, that is a specification of the set of “points” in the system execution where new behavior must be added, while the right part models which new behaviors must be added and how they must be added with respect to the original execution flow of the primary system. An AD is characterized by a name which is unique in the scope of the Aspect it belongs to. Both the left and right part of an AD consist of UML-based diagrams: a Pointcut Diagram (PD) for the left part and a Behavioral Diagram (BD) for the right part. In turn, a PD is defined using Join Point Diagrams (JPD). We give in the rest of this section details about all these diagrams.

Join Point Diagram (JPD). A JPD models the occurrence of a specified event in the execution of a program (join point). We represent it by a UML AcceptEventAction. An AcceptEventAction is a UML Action that waits for the occurrence of an event meeting specified conditions [15]. In UML these events are specified as UML Triggers and can corresponds to method calls, attribute changes, signals. As a consequence, we may note that the AcceptEventAction construct provides by itself a good basis to capture the semantics of a join point. For the specification of the Trigger associated with an AcceptEventAction, we adopt a graphical notation that allows us to provide information about the context of the occurring event, which is in general needed to support the modeling of a join point in a AOM framework (for example, which object is the caller, or the target, of a method call). This notation consists of a UML Sequence Diagram fragment. This idea is similar to what proposed in [17,19]. Hence a JPD is graphically represented by the UML icon for an AcceptEventAction, embedding a Sequence Diagram fragment that models its trigger. A JPD must be stereotyped with the label call or execution. The former specifies that the AcceptEventAction will be triggered within the context of the calling object just before the control transfer to the called method, the latter that it will be triggered within the context of the target object upon transfer of control, just before the called method starts its execution. Context information is provided through the elements specified in the sequence diagram fragment embedded in a JPD. The object elements used in a JPD can be the caller or the target of a method call. They must be specified using the syntax objectID:ClassType. Regular expression can be used to specify names, to select multiple objects or methods. When the caller (target) ClassType is specified (that is, it is not specified by a '*') it means that the join point modeled by that JPD actually occurs only if the caller (target) is an instance of that class. In this way it is possible to specify constraints on the join point occurrence. When the caller (target) objectID is specified, then it acts as a parameter and will ultimately hold the reference to the object matching the join point modeled by the JPD. In this way it is possible to pick up the context of a join point when it occurs. call

instancea:*

instanceb:*

doSomething(..) <>

Pointcut

Behavioral

Diagram

Diagram

Figure 2: Structure of an Advice Diagram (AD)

3.1 Pointcut and Join Point Diagrams The PD in the left part of an AD specifies the occurrence of a particular set of events in the execution of a program. Each of these events is specified by a JPD. Hence, we first present the JPD model and then the PD model.

Figure 3: Join Point Diagram (JPD) modeling a method call join point For example, the JPD in Figure 3 captures any call to a method named doSomething, with any parameter, and with no constraint on the type of the calling or target object. This JPD also picks up the reference to the caller object in the instancea parameter, and the reference to the target object in the instanceb parameter. This JPD can be mapped to the following AspectJ implementation:

call(* *.deleteUser(..)) && this(Manager) && this(man) && target(um) && target(UsrMgmt)

call(* *.doSomething(..)) && this(instancea) && target(instanceb) On the other hand, the JPD in Figure 4 captures any call of Class B constructors with any parameter, made by any object of type A. This JPD does not pick up the references to the caller and target objects. call

*:A B(..)

*:B

Figure 4: Join Point Diagram (JPD) modeling a constructor call join point This JPD can be mapped to the implementation: call(B.new(..)) && this(A)

following

call

a)

um:UsrMgmt

addUser(..)

call

man:Manager

b)

call man:Manager

AspectJ

Referring to the example about the security related crosscutting concern, let us consider the case where we want to define join points that capture the call of any addUser or deleteUser method by an object of type Manager to an object of type UsrMgmt, getting also a reference to the caller and the target object. The JPDs in figure 5 model these join points. In particular, the JPD in figure 5.a captures any call to a method named addUser, taking any parameter. The JPD in figure 5.b captures any call to a method named deleteUser with any parameter. Both JPDs pick up the reference to the caller object in the man parameter, and the reference to the target object in the um parameter.

man:Manager

Pointcut Diagram (PD) A PD consists of a set of JPDs and models the occurrence of a particular set of events in the execution of a program. We represent it by a UML Activity Diagram composed of a set of JPDs (at least one) that end into an activity final node. According to their semantics [15], the AcceptEventActions specified in these JPDs generate a “token” each time they are enabled and the event they capture occurs. We recall that an AcceptEventAction with no incoming edge is always enabled [15]. The token generated in this way by the PD can then be used to start the activities specified in the right part of the Advice Diagram the PD belongs to (as explained below).

um:UsrMgmt

deleteUser(..)

Figure 5: a) JPD for the addUser method call; b) JPD for the deleteUser method call These JPDs can be mapped, respectively, to the two following AspectJ implementations: call(* *.addUser(..)) && this(Manager) && this(man) && target(um) && target(UsrMgmt)

um:UsrMgmt

addUser(..)

call man:Manager

um:UsrMgmt

deleteUser(..)

Figure 6: Pointcut Diagram (PD) for the security concern example Referring to the security concern example, the PD in figure 6 captures the occurrence and the context of both the JPDs modeled in figure 5. As a result, whenever an addUser or a deleteUser method, with any parameter, is invoked from an object of type Manager to an object of type UsrMgmt, then the man and um parameters specified in the PD (more precisely, in its JPDs) hold a reference to the caller and target object, respectively. This PD can be mapped to the following AspectJ implementation: pointcut authorizationPointcut(Manager man, UsrMgmt um) : (call(* *.addUser(..)) &&this(man)&&target(um)) || (call(* *.deleteUser(..)) &&this(man)&&target(um)); The diagram in figure 6 models a simple OR between two different join points. More complex patterns (e.g. Sequence of events, AND among events) can be easily modeled exploiting the Petri-like semantics of the UML 2.0 activity diagrams.

3.2 Behavioral Diagram (BD) The diagrams described above (PD and the JPDs included in it) are used to specify the left part of an Advice Diagram (AD). The right part of the same AD consists of a BD that specifies what happens when some event captured by the PD occurs. “What happens” means which new behavior is added, and how it is executed with respect to the original execution flow of the system

where the triggering event occurred. For this purpose, we specify a BD through a UML Interaction Overview Diagram [15], which models the activities that have to be executed before, around and after the execution of the action corresponding to the triggering event captured by a PD. In this interaction overview diagram, we model by an Interaction element labeled with the stereotype pointcut occurrence the actual occurrence of the action (e.g. a method call) that triggered the join point. Then, we model by other suitable Interaction elements the additional behaviors that must be inserted. These behaviors may refer to attributes and methods declared in the Aspect Diagram that contains the BD (see section 4 below). Finally, we use the control flow structure of the interaction overview diagram to specify how the execution flow is modified by the insertion of these elements. This gives us a great flexibility and expressiveness in modeling how an Advice modifies the behavior of an application. Within the Interaction elements of a BD (right part of an Advice Diagram) we can use the parameters provided by a PD (left part of the same Advice Diagram): in this way we can use the context information captured in the PD by these parameters. Referring to the example about the security concern, the BD in figure 7 represents the right part of an Advice Diagram whose left part consists of the PD in figure 6. This BD models the idea that the action which triggered the pointcut should be performed only if the Manager has a suitable authorization for that User. In the BD of fig. 7 we can note the use of the man and um parameters coming from the PD of fig. 6. um: UsrMgmt

man:Manager

checkAuthorization(man)

[!man.isAuthorized ] [man.isAuthorized]

<>

Figure 7: Behavior Diagram (BD) for the security concern example

3.3 Advice Diagram (AD) As already explained at the beginning of section 3, the PD and BD diagrams described above are used to specify, respectively, the left and right part of an Advice Diagram (AD). The overall semantics of an AD can be summarized as follows. Whenever the join point modeled by a JPD belonging to the PD in the left part occurs, the PD passes the JPD parameters (if any exist) to the BD in the right part, and starts the execution of the BD (through the “token” it generates). Then, once the BD starts, its control flow specifies the activities that must be performed, included (possibly) the action that

triggered the join point (<> element). Figure 8 depicts the overall AD for the security concern example. This diagram embeds the two diagrams already shown in figures 6 and 7. This AD specifies that the method calls for which the authorization check must be performed before their execution are addUser() and deleteUser(). <> authorizationAdvice um: UsrMgmt

man:Manager

call man:Manager

um:UsrMgmt

addUser(..)

checkAuthorization(man )

[!man.isAuthorized] call

[man.isAuthorized]

man:Manager

um:UsrMgmt

deleteUser(..)

<>

Figure 8: Advice Diagram (AD) for the security concern example The AspectJ implementation of the AD in figure 8 could be as follows: pointcut authorizationPointcut(Manager man, UsrMgmt um) : (call(* *.addUser(..)) &&this(man)&&target(um)) || (call(* *.deleteUser(..)) &&this(man)&&target(um)); before(Manager man,UsrMgmt um): authorizationPointcut(man,um) { um.checkAuthorization(man); } void around(Manager man,UsrMgmt um): authorizationPointcut(man,um){ if(!man.isAuthorized){ System.out.println("Not Authorized"); }else{ System.out.println("Authorized"); proceed(man,um); } } This simple example shows the greater expressiveness of our modeling notation with respect to the AspectJ implementation. Indeed, we can note that the AD of figure 8 has been split into two distinct AspectJ advices. The reason is that the AD models activities that must be performed before and around its pointcut: in AspectJ it is not possible to specify this behavior within a unique advice.

4. Putting all together: Aspect Diagram An Aspect Diagram (AsD) is the container for logically related ITDD and AD. We model an AsD by a UML Classifier with different compartments to hold separately all the related diagrams. Analogously to a standard UML Class, an AsD can contain its own attributes and methods to further support object orientation.

The AsD in figure 9 completes the example about the security related aspect we have modeled in this paper: it provides a unique container for the static and dynamic crosscutting concerns we have modeled in the sections above. <> AuthorizationAspect

ITDD: authorizationIntroduction AD: authorizationAdvice

Other attributes and methods declarations

Figure 9: Aspect Diagram (AsD ) for the security concern example The AspectJ implementation of the aspect diagram in figure 9 could be as follows: public aspect AuthorizationAspect { //Introductions public boolean Manager.isAuthorized=false; public void UsrMgmt.checkAuthorization (Manager man){//implementation... } pointcut authorizationPointcut(Manager man, UsrMgmt um ): (call(* *.addUser(..))&&this(man)&& target(um))|| (call(* *.deleteUser(..))&&this(man) &&target(um)); before(Manager man,UsrMgmt um): authorizationPointcut(man,um) { um.checkAuthorization(man); } void around(Manager man,UsrMgmt um): authorizationPointcut(man,um){ if(!man.isAuthorized){ System.out.println("Not Authorized"); }else{ System.out.println("Authorized"); proceed(man,um); } } }

5. Related Work Considerable research has been done in the area of Aspect Oriented Modeling to address the problem of defining and composing aspects at an abstraction level higher than the programming language level [2, 3, 4, 7, 8]. Most of these proposals suggest the use of UML for the design-level modeling of aspects. Some proposals (e.g. [4, 7]) require to add notations to the primary system model to specify the relationships with the aspect

model. In our opinion, this is in contrast with the separation of concerns that should be one of the goals of aspect-oriented approaches. Our modeling approach is, to some extent, quite close to the models presented in [17,19]. In particular, [17] proposes different models that appears very expressive to specify join point selections whose conceptual models are based on control flow, data flow or state. In this respect, our approach can be used (at present) only to model the control flow and data flow conceptual models. However, we think that our definition of the join point and pointcut models is closer to the UML 2.0 specification. Moreover, while [17] focuses on the join point specification, our goal is to provide an integrated model for the specification of both the join point occurrence and of the behavior to be added, exploiting for this purpose the Petri-like semantics of the UML activity diagrams. In [5, 9] Aspects are modeled from the code generation point of view. Code generation is a fundamental part of the model driven development (MDD) approach, and it is important to consider it while modeling aspects. Solberg et al. [16] propose a MDD framework that uses aspect oriented software development techniques to facilitate the separation of concerns. In this context, another important issue (concerning in particular dynamic aspects) is when aspect weaving should be performed, namely at the code or model level. Model level weaving can be useful to support model level validation. Model level weaving is considered in [6 ,8, 12, 14] [6] and [8] propose template-based solutions. However, they seems limited to syntax-based weaving [12], where the weaving is basically obtained by binding template parameters to syntactic elements of the primary model. However, apart from model level weaving, template-based solutions are useful to make aspect diagrams independent of specific namespaces. In this respect, we have not considered for the sake of simplicity the use of templates in the specification of our UML-based diagrams, but we are planning the adoption of a similar solution in a future refinement of our notation. Semanticbased model level weaving is considered in [12], where Message Sequence Charts are used to specify both the behavior of the primary model and of the aspect to be woven. Some algorithms are proposed to perform semantic-based weaving of these models, and it is shown that in some case the weaving is intractable. Our join point and pointcut diagrams lends themselves to support semantic-based weaving. In the simple example presented throughout our paper the intractability problem is absent, but we expect that in more complex examples, where the full expressiveness of UML activity diagrams is exploited, this problem could emerge. Hence, we intend to investigate the issues raised in [12] within our modeling framework. [14] investigates on the possibility of ensuring that a design model holds certain required properties, after the weaving with other models. This kind of investigation is an important area of research, to check the consistency of the resulting models. The work in [14] is based on the UML state diagrams. We intend to investigate whether a similar approach can be applied to our Advice Diagram (based on UML activity diagrams).

6. Conclusion and future work The ultimate goal of research in AOM is to provide aspectoriented software developers with general means to express aspects and their crosscutting relationships onto other software

artifacts. In this paper we have proposed a UML-based notation whose goal is to help the modeling of crosscutting concerns in a fully graphical way, independently of the other components of a system and of a specific AOP language implementation. One of our guidelines has been to exploit as much as possible existing UML constructs to capture core AOM characteristics: this is the case of the AcceptEventAction and Interaction Overview Diagram constructs, which appear suitable to express the semantics of join points and advices, respectively. What we have presented is a first step of an ongoing work. Further steps will include the use of UML templates to make our diagrams independent of a specific namespace (as suggested in [8]), thus achieving a full separation between the primary and the aspect model. They will also include improvements of our diagrams specification, to increase their expressiveness. We also intend to investigate whether our Advice Diagram model may help in tackling the problem of combining different dynamic aspects (in our model, combining dynamic aspects basically means merging their Behavioral Diagrams). We may imagine to define precedence rules to drive the merging process, and consistency checks to detect possible inconsistencies. Finally we intend to investigate whether our notation may be integrated in a more complete MDD framework. To this end we intend to define model transformation and code generation rules to support a transformation path from aspect models to executable code.

References [1] Aldawud Omar. “A UML Profile for Aspect Oriented Modeling”. OOSPLA 2001 workshop on Aspect Oriented Programming, 2001. [2] Araújo João, Brito Isabel, Rashid Awais. “Aspect Oriented Requirements with UML”. Workshop on "Aspect-oriented Modeling with UML", UML 2002, Dresden, Germany, October 2002. [3] Baniassad Elisa, Clarke Siobh´an. “Theme: An Approach for Aspect-Oriented Analysis and Design”. Software Engineering, 2004. ICSE 2004. Proceedings. 26th International Conference on, pp. 158- 167 , 23-28 May 2004 [4] Bash Mark, Sanchez Arturo. “Incorporating Aspects into the UML”. In Proc. Workshop on Aspect Oriented Modeling at AOSD 2003, 2003. [5] Beier Georg, Kern Marcus. “Aspects in UML Models from a Code Generation Perspective”. In 2nd Workshop on Aspect Oriented Modeling with UML, UML 2002. Dresden, Germany,September 30, 2002. [6] Clarke Siobhán , Walker Robert J., “Composition patterns: an approach to designing reusable aspects”. Proceedings of the 23rd International Conference on Software Engineering. p.514, May 12-19, 2001, Toronto, Ontario, Canada. [7] Deubler Martin, Meisinger Michael, Rittman Sabine, Kruger Ingolf. “Modeling Crosscutting Services with UML Sequence Diagrams”. In Proc. MoDELS 2005, pages 522--536, 2005

[8] France R., Ray I., Georg G., Gosh S. “Aspect Oriented Approach to early design modeling”. IEE Proceedings Vol. 151, No. 4, August 2004 [9] Jürjens Jan, Houmb Sive. “Dynamic Secure Aspect Oriented Modeling With UML: From Models to Code”. In ACM / IEEE 8th International Conference on Model Driven Engineering Languages and Systems (MoDELS/UML 2005), Springer LNCS, 2005. [10] Kizcales G., et al. “Aspect Oriented Programming”. Proceedings of the 11th European Conference on ObjecOriented Programming,1,1 – June 1997 [11] Kizcales G, et al. “Getting Started with AspectJ”. Communications of the ACM, 44, 10, pp. 59-65, October 2001 [12] Klein Jacques, Hélouët Loïc, Jézéquel Jean-Marc. “Semanticbased Weaving Scenarios”. In Proceedings of the 5th international conference on Aspect-oriented software development. Bonn, Germany.2006. [13] Masahura Hideiko, Kiczales Gregor. “Modelling Crosscutting in Aspect Oriented Mechanisms”. In Proceedings of ECOOP2003, Springer LNCS 2743, pp.2-28, 2003 [14] Nakajima Shin, Tamai Tetsuo. “Aspect Oriented Software Design with a Variant of UML/STD”. Proceedings of the 2006 international workshop on Scenarios and state machines: models, algorithms, and tools,pp. 44-50. May 2006 [15] Object Management Group.United Modeling Language 2.0 Superstructure version 2.0. http://www.omg.org/docs/formal/05-07-04.pdf [16] Solberg Arnor, Simmonds Devon, Reddy Raghu, Ghosh Sudipto, France Robert. “Using Aspect Oriented Techniques to Support Separation of Concerns in Model Driven Development”. Computer Software and Applications Conference, 2005. COMPSAC 2005. 29th Annual International. July 2005. [17] Stein Dominik, Hanenberg Stefan, Unland Rainer. “Expressing Different Conceptual Models of Join Point Selections in Aspect-Oriented Design”.Proceedings of the 5th international conference on Aspect-oriented software development ,2006. [18] Stein Dominik, Hanenberg Stefan, Unland Rainer. “A Graphical Notation to Specify Model Queries for MDA Transformations on UML Models”. In Model Driven Architecture: Foundations and Applications. 2004 [19] Stein Dominik, Hanenberg Stefan, Unland Rainer. “On Representing Join Points in the UML”.Aspect Modeling with UML workshop at the Fifth International Conference on theUnified Modeling Language and its Applications,September 2002 [20] Zakaria A. A., Hosny H., Zeid A. “A UML Extension for Modeling Aspect Oriented Systems”. Aspect Modeling with UML workshop at the Fifth International Conference on the Unified Modeling Language . the Language and its Applications, September 2002