A UML Notation for Aspect-Oriented Software Design

A UML Notation for Aspect-Oriented Software Design Renaud Pawlak*, Laurence Duchien**, Gerard Florin*, Fabrice Legond-Aubry***, Lionel Seinturier***, Laurent Martelli****

*Laboratoire CEDRIC-CNAM, 292 rue Saint Martin, 75141 Paris Cedex 03, France ** Laboratoire LIFL, Bâtiment M3, 59655 Villeneuve d'Ascq, France *** Laboratoire LIP6, 4 place Jussieu, 75252 Paris Cedex 05, France **** AOPSYS, 5 rue Brown Séquard, 75015 Paris, France March 4, 2002

By using AOP, programmers thus increase the maintenability and the readability of their programs. However, most of the works are currently focussing at the language level and we lack highlevel means for expressing aspects. A standard UML notation would greatly facilitate the communication on aspects and would avoid the people that are interested in aspects to go into their actual implementation code to understand them. We have been working for several years on programming an Aspect-Oriented framework on Java called Java Aspect Components (JAC) [7, 6, 4]. By working together on aspects, we have naturally begun to draw boxes and arrows so that we can easily understand each other on a board. After some formalization works, we have then dened a notation on UML which can be seen as a rst step towards a standardization on how to dene aspects at the early analysis and design steps of an Aspect-Oriented application development. This platform-independent graphical AO language that comes from the abstraction and fusion of concrete concepts that can be found in existing AO programming languages and paradigms such as AspectJ [1], JAC [7], or Aspectual Components [8], can also be related to several works that can be found in the AOP community [3, 5]. We hope this notation or a similar one to be soon supported by UML tools such as ArgoUML or Rational Rose since it greatly claries AO design and can be a rst support for an AO development processes. Section 2 presents an overview of our notation and of the dierent concepts it involves,

Abstract

This position paper presents a UML notation for designing aspect-oriented applications. It is extracted from our experiences when building the JAC framework and from the concepts dened in the AspectJ language or in Aspectual Components. This notation is a proposal for a rst step towards a high-level designing graphical language that can be used when building aspect-oriented applications. Moreover, it is also suited to design Aspect-Oriented applications in distributed environments. In short, it denes three main additional concepts to UML: groups (that provide classication means for heterogenous and distributed entities), pointcut relations (that allow the programmer to dene crosscuts within the functional program), and aspect-classes (that actually implement the extension of the program on the crosscutting points denoted by the pointcut relations). In this paper, we give some concrete design examples of some aspects to illustrate how it can be used. 1 Introduction

Aspect-Oriented Programming (AOP) [2] is a recent paradigm that provides a set of concepts that allow programmers to modularize their applications in order to provide better Separation of Concerns (SoC). Thanks to AOP, the programmers can implement dierent concerns in well-dened entities called aspects by breaking the inherent dependencies that can exist between the dierent program modules. 1

, , and aspects. Section For these reasons, we most of the time use 3 gives some modeling solutions on sample con- the stereotype group when specifying base cerns. objects in an aspect-oriented context. This allows the design to reect the information that the application of the aspects that come in fur2 The notation ther renements may distribute the class over a set of host and may change the type homogeneity of its instances . 2.1 Groups Figure 1 shows how groups abstract the disA useful notion for programming aspects is the tributed nature of some programs. The upgroup notion. Groups provide two interesting per part of the gure describes a group-level properties. of an abstract application that deFirst, a group represents a set of objects that specication nes a viewer that uses a docuare not necessary instances of the same class ment group-class.group-class Conceptually this or superclass. Thus the group notion allows viewer is able to invoke a search speaking, service on the designer to reason about heterogenous, but document that returns all the locations of the group-typed sets of objects, which is unclear given word within the given document. the with a standard UML notation. By using the Concretely speaking, the implementation of groups, the aspect programmer can easily ex- this application can be very centralized or very press the fact that a set of heterogenous objects distributed. The middle and lower parts of the belongs to the same context-space or support gure show two extreme concrete implementathe same systemic semantics  such as trans- tion samples: actional or real-time semantics. Second, a group may be composed of memWord: the application is able to bers that are localized on dierent hosts or con-  Microsoft work on a document that is located on a tainers. Consequently, groups can be advanwell-dened set of bytes that are located tagely used to abstract the distribution of the on the same centralized disk  the search application at a rst renement step (our noalgorithm is located into tation also intends to provide support for dis- of executable program. one unique piece tribution and for distributed aspects).  Google Internet Search Engine: the application is able to work on a document that is heterogeneously formed of all the pages and documents on the Internet  the search algorithm is extremely complex (use of very powerful indexes and seeking structures, use of caches for optimization, use of robots for prefetching...) and its treatments and data are distributed. Thus, at an abstract specication level, groups allow the designer to express in the same way centralized and distributed program. groups pointcut relations

1



Viewer

Document

search(in toFind, out locations)

rtf doc

handles

Microsoft Word

requests

IE5

Google front−end

Netscape Google front−end

requests

Google server

Google server

2.2

An aspect-class is like a regular class (with regular attributes and methods), except that it can contain methods that have particular semantics. These special methods called aspectmethods are meant to extend the semantics

IE4 IE5 Galeon

requests

Google front−end

Aspect-classes

Google server

requests Google server

1 Note that in the most simple cases, the group-class is rened in a simple class that provides the same interface (so that there is always a direct mapping from a group-level model to an object-level model).

Figure 1: Centralized vs distributed implementations. 2

of regular classes (also known as base-classes). The extension is performed on well-dened implementation points so that these points actually use aspect-services in order to integrate new concerns (e.g. a base-class can be made to use a cache interface if the aspect implements some caching concern). The designer can explicit one of the aspectmethod extending semantics by using one of the furnished stereotypes. Here are the possible stereotypes and the simplied meanings of the m aspect-method typed with them.  before m(args): the m method is executed before a given point (to be specied later) of the extended program,  after m(args): the m method is executed after a given point (to be specied later) of the extended program,  around m(args): a part of the m method is executed before and another part is executed after a given point (to be specied later) of the extended program (these two parts are dened within the m implementation and depends on the aspect-oriented language),  replace m(args): the method m modies a given point (to be specied later) of the extended program implementation by replacing it by the m implementation or by modifying the extended objects implementation (if supported by the target aspect-oriented language or system),  role m(args): the m method can be invoked on the objects that are extended by the aspect-class the m method belongs to; moreover, the m method implementation can access the extended class attributes and the aspect-class attributes. Note that the arguments passed to the aspectmethods are contextual arguments since these methods are not invoked directly. The idea of contextual arguments is that their value can be set at a given point of the program and retrieved by the aspect-method at another point of the program (if the aspect-method is allowed to do it, i.e. if the contextual arguments are declared in its prototype). For instance, gure 2 shows the caching aspect-class (with the aspect stereotype) of a caching extension example. It denes a

Cache + getValue(): Object + setValue(Object) + invalidate() 0−1

1

cache

Caching + whenWrite() + whenRead(boolean forceInvalidate)

Figure 2: An aspect-class sample for a caching aspect. after aspect-method that sets the value of the cache (using setValue ) and a whenRead around aspect-method that reads the value from the cache (using getValue ). As any class, an aspect-class can handle an association towards other classes, here the Cache class. whenWrite 

2.3

Pointcut relations

A pointcut relation allows the designer to link some aspect-methods (belonging to aspectclasses) to some points of the base-class. It is an oriented association from an aspect-class towards a classier such as a class (or a group if the aspect works on heterogeneous or distributed objects). The association is stereotyped with pointcut and the roles have special semantics since they are used to tell which methods of the client-class are extended and by which aspect-methods. A c1 r1 p tag c2

r2 C

Figure 3: The pointcut association: relating aspects to classes. 3

Points out Keyword all the methods of C ALL all the constructors instance methods of C CONSTRUCTORS all the methods of C that are setters SETTERS all the methods of C that are getters GETTERS the setter of a given attribute SETTER(attrname) the getter of a given attribute GETTER(attrname) all the methods of C that read some instances states ACCESSORS the methods of C that read the instances elds contained ACCESSORS({attrnames}) all in the {attrnames} list all the methods of C that modify some instances states MODIFIERS the methods of C that modify the instances elds contained MODIFIERS({attrnames}) all in the {attrnames} list Table 1: Allowed keywords within the ! and ? point types Here is the detailed semantics (refer to gure 3):  a pointcut relation p must go from an aspect-class A to a classier C (that can be a group),  role r1 is the name of an aspect-method dened in A (must be an around, before, replace, or after method) that is applied at each base-program point denoted by role

- points out all the program points where an exception occurs. - ~ points out all the program points where an instance is serialized. - !~ points out all the program points where an instance is deserialized. - ^ points out all the program points where an instance is looked-up within the object repository of the system (if any).  cardinality c1 is the number of aspect instances of A that can be in relation with one instance of C (default is 0-1),  cardinality c2 is the number of instances of C that can be in relation with one instance of A (default is *  see the left part of gure 4),  as any UML model element, the pointcut relation can be tagged (tag ) to express extra semantics that can be used when implementing the model towards a concrete platform.

r2,



role r2 denes a base-program crosscut (a set of points); it is of the form T[expr] where T 2{!, ?, , , , ,, ~, !~, ^} and expr is an optional expression that species (acts like a lter for) the T set of points: - ! denotes the methods invocation points; it can be followed by a regular expression that matches the methods names or by a logical expression containing the keywords dened in table 1. - ? denotes the methods execution points; it can be followed by exactly the same expressions as !. - denotes all the instance creation points. - points out all the program points where an instance is used by a peer object for the rst time. - points out all the program points where an instance is cloned. - points out all the program points where an instance has been remotely instantiated from a remote container or application.

Regarding table 1, if you need to point out methods that are located in other classes, then you can use the notation: className.methods. For instance, !myClass.SETTERS points out all the setters invocations of the class myClass. To better understand the pointcut semantics, gure 4 proposes instance diagrams that illustrate two sample instantiations of a pointcut relation (of dierent cardinalities). When the aspect-class is instantiated, it automatically instantiates a set of pointcut-relations instances Note:

4

The p pointut instantiation when c2 = * (one−to−many relation − the aspect’s state is shared)

The p pointut instantiation when c2 = 1 (one−to−one relation − the aspect’s state is per−object)

AnAspect: A aspectMethod()

AnAspect1: A

AnAspect2: A

AnAspect3: A

AnAspect4: A

aspectMethod()

aspectMethod()

aspectMethod()

aspectMethod()

pointcut relation instances

Figure 4: A pointcut relation instantiation samples. between the base objects instances of C (in the case of a group, the members) and itself. The link points set on the instances forms a crosscut. On all the crosscut line, the aspectmethod of the pointcut is applied to the base objects so that their behavior is extended to implement the aspect's concern.

At the client-side, the needed service is provided by the showInput method of the Display interface. At the server-side, the needed service is provided by the checkAuthInfos method of the Authentication interface. The use of the group stereotypes implies that we abstract the location and the type of the clients and of the server. Indeed, the display and the authentication services may be implemented on other 3 Sample aspects design sites than the clients or the servers that use This section shows how to model two comple- them. mentary aspects related to security. We do not intend to fully explain the aspects because we Authentication Display lack space. However, these examples give some showInput(...) checkAuthInfos(...) indications and guidelines on how to use our notation. For more details about these aspects, authentication you can refer to their actual implementations and detailed design that is available at [7].





Authentication

3.1

+ askAuthInfos(>display,passwd)

A sample authentication aspect

Regarding the authentication concern, the design strategy is up to the designer. A quite classical choice is to dene the authentication as follows:  at client-side, when the user performs an action that triggers an invocation on the Server, the client application opens a login form that allows the user to ll its username and password, then the client application actually proceeds the invocation to the server with the username and the password passed into the invocation by any implementation means  at server-side, the server calls a service that allows it to decide if the invocation is accepted or rejected

askAuthInfos

checkAuthInfos





!Server.ALL

?ALL



Client





Server

Figure 5: Modeling the authentication aspect, step 3. Since we want to provide an AO design, the identied dependencies (that could be modeled with classical use relations for instance) must be dened by an aspect. Deciding which dependency is part of an aspect or 5

not is domain-dependent and it is the designer, helped by a domain expert that decides which set of relationships must be modularized in an aspect. Figure 5 shows a possible modularization of the authentication aspect that we consider to be relevant to our experience. The two before methods of the aspects dene some extra behavior to add before a service invocation or execution. Each one of the pointcut relationships corresponds to an aspect-method and denes the initial program points where they must be applied to. The diagram can then be read as follows.  The askAuthInfos(in display,out user,out password) aspect-method must be applied before each invocation (! ) of ALL the server services from the client group (the pointcut relation ends on the client). It needs a reference on a display (instance of the Display interface, member of the Display group) and returns a user and a password as an output. Since it is a before method, all these parameters are contextual parameters (see section 2.2). This aspect-method then calls the showInput(out user, out password) on the display.  The checkAuthInfos(in user,in password) method must be applied before each execution (? ) of ALL the server services. It needs a user and a password from the context (set by the askAuthInfos aspectmethod) and delegates the authentication task to the Authentication group (modeled as a group since the authentication implementation may be implemented in dierent maners within a distributed world). 3.2

AO design since this concern can be generalized to other issues than authentication (for instance a privacy aspect that works on private/public keys). Figure 6 shows how we design this feature as an aspect. In fact, the sessions can be described as client-side persistence features. The two aspect methods are used to save the sessions related (contextual) informations within a storage (that can be volatile in some cases). The session data are related to the current user context and can be various private informations depending on the other aspects that are woven in the system (for instance, it can be a user, a password, or a crypting private key). Once the session information are saved, they are restored before any other manipulations so that the other aspects do not have to fetch them anymore (by asking to a remote server or by interactively requesting the user to ll the missing data through an input/output device). This is very interesting to design sessions as an aspects since sessions can implement various policies when generating session identiers or when handling the sessions expirations. In a classical design, all these issues related to the session concern would crosscut the clients and servers implementations.

Storage + save(infos)

storage

Session + restoreSessionInfos(infos) infosDescr

Modeling the session aspect

Regarding the authentication aspect, we can notice that the authentication is performed on each client-server interaction. This means that the system asks the client to authenticate each time it accesses a remote service. We could modify it so that the user have to ll his username and password only once (i.e. the system should be able to handle a sequence of interactions (coming from the same client host) as part of the same client's session). But, again regarding our experience, this would be bad

saveSessionInfos

restoreSessionInfos





!Server.ALL

!Server.ALL

Client





Server

Figure 6: Modeling the session aspect. 6

[6] JAC: A Flexible Solution for AspectOriented Programming in Java. Renaud Pawlak, Lionel Seinturier, Laurence Duchien, and Gérard Florin. In Procedings of Reection 2001, LNCS 2192, p. 1 . [7] JAC Home Page. . [8] Programming with Aspectual Components. K. Lieberherr, D. Lorenz, and M. Mezini. NU-CCS-99-01, College of Computer Science, Northeastern University.

4 Conclusion

We have presented our UML notation and showed that it can be used to model real-life aspects. We are aware that this position paper does not cover all the issues that are related to AOSD but it gives a rst proposal for an AO graphical language. The goal of this proposal is to be simple and easy to understand. Hence, we did not focus on dening a prole and maybe several notations we use are not completely tting the UML standard. Furthermore, we tried to bring at a specication level the concepts we use in everyday-life AO developments with a relevant amount of details so that it should be possible to implement an automatic mapping from the design to concrete implementations in existing AO languages that belong to the AspectJ familly. In the future, we will continue to rene this model and will provide a fully Aspect-Oriented model of the JAC framework (that is an excellent test for our notation). We guess that other research teams will also provide UML support for Aspect-Orientation and we hope that all the proposals will be able to converge towards a standard denition very soon and that the CASE tools will provide support for such UML extensions.

http://jac.aopsys.com

References

[1] AspectJ Home Page. . [2] Aspect-Oriented Programming. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C.V. Lopes, J.M. Loingtier, and J. Irwin. Proceedings of the European Conference on Object-Oriented Programming (ECOOP'97). [3] A UML Prole for Aspect Oriented Modeling. O. Aldawud, T. Elrad, and A. Bader. Workshop on AOP, OOPSLA 2001. [4] Dynamic wrappers: handling the composition issue with JAC. R. Pawlak, L. Seinturier, L. Duchien, G. Florin, TOOLS 2001, Santa-Barbara CA, USA. [5] Extending UML with Aspects: Aspect Support in the Design Phase. J.Suzuki and Y. Yamamoto. 3rd AOP Workshop at ECOOP'99. http://aspectj.org

7