Towards a New Aspect-Oriented Modelling Approach

2 Conference on Theoretical and Applicative Aspects of computer science (ctAAcs’13)

nd

Towards a New Aspect-Oriented Modelling Approach Meriem Chibani1 , Brahim Belattar2 and Abdelhabib Bourouis1 1

Department of Mathematics and Computer Science, University of Oum El Bouaghi, 4000, Algeria {c.meriem, a.bourouis}@univ-oeb.dz 2 Department of Computer Science, University of Batna, 5000, Algeria [email protected]

Abstract. The application of the aspect oriented programming (AOP) paradigm throughout software cycle development as specification, design, and implementation phases, namely aspect oriented software development (AOSD), emerges as a young and dynamic research area in computer programming. It is a rapidly evolving area and one of the most popular topic for dealing with cross-cutting concerns by the realization of the separation of concerns (SOC) principle. In this paper, we propose a new aspect-oriented profile towards a new AO modelling approach based on the Unified Modelling Language (UML) as one of the most prominent protagonists at the design level.

Keywords: Aspect oriented programming, cross-cutting concerns, aspect oriented software development, aspect oriented modelling, separation of concerns, UML profile.

1

Introduction

The distinction between the different categories of concerns will simplify large applications, give better understanding, decrease coupling between concerns (strong cohesion) and more generally increase reuse. The term separation of concerns (SOC) was originally coined by Dijkstra “ Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects [...]. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day [...] But nothing is gained –on the contrary –by tackling these various aspects simultaneously. It is what I sometimes have called ‘ the separation of concerns ’ [...] ” [1]. The object oriented paradigm does not satisfy the separation of concerns principle even using the most advanced design patterns [2]. Whereas it provides a powerful way to separate core concerns, it will leave something to be desired

University 20 Août 1955 of Skikda - November 25- - 26 , 2013

1


nd

when it comes to cross-cutting concerns. To overcome this shortcoming, several methodologies as generative programming, meta-programming, reflective programming, compositional filtering, adaptive programming, subject-oriented programming, aspect-oriented programming (AOP) and intentional programming have emerged as possible approaches to modularize cross-cutting concerns [4]. From a software development point of view, aspect orientation has originally emerged at the programming level with AspectJ, in the late 1990’s. Xerox recently transferred the AspectJ project to the open source community at eclipse.org, which will continue to improve and support the project. AspectJ is based on Java, but there are implementations of AOP for other languages, like AspectC for C and Pythius for Python, that apply the same concepts that are in AspectJ to other languages [4]. Furthermore, there are other Java implementations of AOP than AspectJ, such as Java Aspect Component (JAC), Caesar, Jiazzi, JBossAOP, AspectWerkz and JasCo. These implementations differ in the ways of expressing the cross-cutting concerns by using joinpoints, pointcuts, advices, inter-type declaration, weave-time declaration, and aspects constructs; and in weaving mechanism which includes static and dynamic weaving to form the final system [3]. The use of the aspect-oriented paradigm is not restricted to the programming level but more and more stretches over phases prior to the implementation phase of the software development life cycle such as requirements engineering, analysis, design and recently attention is given to formal verification techniques dealing with aspect interactions and interferences. Capturing aspects at the design phase streamlines the process of AO development and the separation of concerns during this level is no less important than at other stages of development. As stated in the Call for Participation in the Aspect Oriented Design Workshop at the First International Conference on Aspect-Oriented Software Development, “ Without proper attention to concerns during the design of the system, it will be hard to manage complexity, readability, the evolution and composition of the system ”. In this paper, we propose an AOP uml profile for the specification of the cross-cutting concerns at the design level toward a new aspect oriented modelling approach. We follow an aspectual process, i.e., the composition is performed at the code level. Our profile uses the AspectJ terminology which is considered rich, roughly with all constructs that may be used in any AOP system as aspects, pointcuts, advices and so on. The rest of the paper is organized as follows. Section 2 presents the major concepts used in this paper. Section 3 outlines briefly the similar works. Section 4 describes the main criteria for aspect-oriented modelling approaches. Section 5 discusses the proposed profile. Section 6 presents a motivation example with the simulation framework JAPROSIM and finally a conclusion is given in Section 7.

2

Background

AOM approaches provide the separation of system’s concerns and specify their composition at the design level.


2


nd

2.1

The Development Process

There are two alternative ways to follow, if we start from an aspect-oriented design: 1. Aspectual process: It allows the separation of concerns from design level until code level. It includes three steps, as shown in Figure 1, concerns separation and the specification of their composition at the design level (step 1), then code generation, e.g., AspectJ code by using model-to-code transformation tools (step2), and the last one requires the completion of the partially generated AO code. 2. Hybrid process: It starts as an aspectual model with the separation of concerns at design level and the specification of its weaving rules (step 1 as shown in Figure 2). This time, the composition of the modularized concerns is performed at the modelling level (step 2). This composed model is translated to a model-to-code transformation engine that produces OO source code (in our case, Java), finally the code is refined manually [11].

Fig. 1. Aspectual process [11].

2.2

UML for Aspect Oriented Design

UML is a standard object oriented modelling language for specifying, visualizing, constructing, and documenting the artefacts of a system process. The UML was originally conceived by Rational Software Corporation and three of the most prominent methodologists in the information systems: GradyBooch, James Rumbaugh, and Ivar Jacobson, known as the Three Amigos. The language has gained significant industry support from various organizations via the


3

nd


Fig. 2. Hybrid process [11].

UML Partners Consortium and has been approved by the Object Management Group (OMG) as a standard in November 1997 [8]. UML 2.0 version has been finalized by the OMG in July 2005, which adds new features to UML 1.x version. UML 2.0 uses 13 types of diagrams [12], where it defines semantics and notation for every construct in each one. UML has four-layer architecture. Level 3 defines the meta-meta-model layer, which is defined by the Meta Object Facility (MOF). The UML meta-model specifies the modelling language, it is defined and standardized on top of the MOF in level 2. Level 1 defines the model layer, and the user object layer defines instances of the model at level 0 [9]. There are different aspect oriented design languages used to specify cross-cutting concerns based on UML such as AODM, Theme/UML, SUP, UFA, and AML [13]. Two alternatives are available to represent the AOSD concepts at design level using uml: 1. The General Extension to UML (GEU): It modifies the meta model of UML to include at this level the concepts related to the paradigm. Thus, UML will be able to model all type of aspects in any situation and in any context. The disadvantage of this approach is that in order to be so general, perhaps some concepts related to the aspects may be lost during modelling [10]. 2. The Specific Extension to UML (SEU) or the UML profile: UML profile is one of the main strong points of UML. UML provides extension mechanisms that enable the language to be adapted to different types of aspects. Extension mechanisms are the means for customizing and extending the UML. UML extension mechanisms are based on “ Stereotypes ”, “ Tagged Values ”, and “ Constraints ”. Briefly said stereotypes are means of extending the UML vocabulary. Tagged values are properties for specifying characteristics or


4


nd

attributes for model elements. Constraints are used to detail how a UML element may be treated. They are usually specified informally [8].

3

Related work

There are a considerable number of works related to aspect oriented UML profile in the literature. Initial discussion on UML profile was presented in [16], which proposed the specification of aspects as stereotypes on classes and aspects behavior as association relationship using collaboration diagram. The profile was specific for synchronization aspect and without addressing join points, advice and pointcut concepts. It was later extended to include advice and pointcut specification in [9]. Evermann proposed a complete AspectJ profile without textual specification in [17]. It was developed using the commercially tool MagicDraw with XMI (XML Metadata Interchange) format which allows easy code generation but has inconsistencies compared to what is required by the paradigm and the proof was provided by a process for aspect oriented profile checking in [19]. In [18], Evermann profile was extended to support aspect-oriented frameworks taking into consideration some AspectJ idioms, patterns and also stereotypes from a profile for object-oriented frameworks called UML-F. Recently, the authors in [20] proposed a new AO profile for their cooperative information system approach (AspeCiS). The profile is adaptive to specific domain and it focused on the advice element with lack of the other AOP constructs like static cross-cutting and join points.

4

Evaluation criteria of AOM approaches

There are a considerable amount of AOM approaches. Since aspect-orientation is often considered as an extension to object-orientation, it seems almost natural to use and/or extend the object-oriented modelling standards, e.g., the Unified Modelling Language (UML), for AOM. So, there are only a few AOM proposals that do not base their concepts on UML. In the following, a catalogue of criteria for a structured evaluation of AOM approaches is presented (see Figure 3) [6]. – Concern Composition: covers the different composition mechanisms. It deals first, with the modularization and thus with the separation of a system’s concerns into appropriate units and second, with their interrelationships, and consequently their composition by means of appropriate rules. – Asymmetric Concern Composition: this category subsumes criteria for evaluating approaches following an asymmetric way to concern composition which are categorized into two sub-categories AspectualSubject and AspectualKind. The first one, provides criteria for evaluating concepts used to describe where to augment or constrain other concern modules, e.g., the join point and its sub-concepts. The second, subsumes criteria for evaluating concepts used to describe how to augment or constrain other concern modules, e.g., the advice as well as the abstraction level at which modelling of the advice is possible.


5


nd

– Symmetric Concern Composition: contains criteria for evaluating approaches following a symmetric way to concern composition. – Language: this category contains general criteria describing the modelling language and design process. – Maturity Criteria: intend to evaluate the approaches’ maturity in general. It was used to evaluate whether an approach has been used in real world examples, only, whereas in this survey maturity is evaluated with a set of subcriteria (Modelling Examples, Application in Real-World Projects, Topicality and Available Information). – Tool Support Criteria: improves the adoption of an approach as well as ensures syntactical correctness of the model. While the criterion distinguishes between support for modelling, composition and code generation, later are both dependent on modelling support.

Fig. 3. The criteria catalogue of AOM approaches [6].

According to the previous criteria catalogue of AOM approaches, we classify our approach as a symmetric technique that makes a clear distinction between the base-system and the cross-cutting concerns and we focus on code-level weaving instead of model-level weaving.


6


nd

5

The Proposed Profile

Our profile is developed using the commercial tool MagicDraw in an imitation to AspectJ implementation as follows: 5.1

Aspects as Classes

It is intuitively obvious to view aspects as classes because of their representation in AspectJ. They are declared like classes and contain the same kinds of constructs, such as attributes and operations [15]. Thereby, aspects are modelled using the metaclass Aspect which extends the metaclass Class as shown in Figure 4. Despite their similarities, aspects are different from classes and in order to overcome this, additional attributes and constraints on the metaclass Aspect are used. 1. Attributes isPriviliged – a boolean which indicates if the aspect has a special privileged access specifier. If true, the aspect may access to private members of the classes which are cross-cutting. aspectInstance – specifies the aspect instantiation model. Precedence – determines the execution order of aspects with the same join point. 2. Constraints: concrete aspects may not declare generic parameters and they could not inherit from concrete aspects. 5.2

Advices as Operations

Advices alter the behavior of the system at joinpoints selected by pointcuts. They are similar to operations in terms of the behavior, name, and arguments thus, we model advices using the metaclass Advice which extends the metaclass Operation. 1. Attributes AdviceExecutionType: enumeration attribute that determines where the advice is executed: prior, following or surrounding join points (the places in the execution of a program where the cross-cutting concerns take effect). 2. Constraints: in contrast to the method, which applies through an explicit call, the advice applies automatically in crosscutting manner. This is why an advice does not have an access specifier and only the ‘around’ advice includes return type. 5.3

Pointcut

It selects the join points with a structural description.It has not any relation with the dynamic behavior so we model it using the metaclass Property and we add the constraint that the pointcut stereotype may be only applied to classes that are stereotyped Aspect. Furthermore the metaclass Pointcut has additional attributes as follows: – pointcutType: determines if the pointcut has a name or is anonymous. – Each pointcut may be composed from other pointcuts.


7


nd

Fig. 4. The AOP profile.


8


nd

5.4

Static Crosscutting

Although advice alters the behavior of the system, static cross-cutting alters its static structure in a cross cutting manner for instance: inter-type declaration and weave-time declaration. It is modelled using the metaclass Feature. A constraint is added to ensure that the static cross-cutting stereotype is applied only to classes that are stereotyped Aspect.

6

Motivation Example

Java PRocess Oriented SIMulation (JAPROSIM) is an open source and a free software simulation framework distributed under GNU Lesser General Public Licence (LGPLv3) since 2008. It is currently available under 1.4 version. It is used for developing discrete event simulation models using a coroutine mechanism implementation. It is divided into six main packages which are: kernel, random, distributions, statistics, gui, and utilities packages [7]. JAPROSIM structure suffers from the object oriented programming methodology weakness, where different cross-cutting concerns such as the exception handling could not always be cleanly separated from the library functional core. The exception handling concern pollutes several classes for instance: Scheduler, SimProcess, and Entity. Thus, a primarily solution at the implementation level using AspectJ was proposed in [14] by means of ExceptionHandling aspect. As an Extension to our previous work, we apply our profile to JAPROSIM uml model where the metaclasses became stereotypes and their attributes became tags values as shown in figure 5.

7

Conclusion

For an aspect-oriented software development, concern modelling is necessary in principle and in practice to achieve the status of aspect-oriented software engineering. To establish standards for developing aspects during the software development life cycle and for modelling them in the UML, several approaches are proposed according to different criteria such as language criteria, concern composition, asymmetric concern composition, symmetric concern composition, maturity criteria, and tool support criteria. The most used modelling formalism for AOM approaches is UML via heavy or light extension. In this paper, we put the first step toward our contribution which is a novel approach for aspect oriented modelling based on an aspectual process using uml profile. We choose the simulation modelling as our interesting domain application. The use of the aspect oriented paradigm proves its efficiency through the development of large simulation systems with less complexity and improving software simulation quality at different points of view (maintenance, test, and reuse).


9


nd

Fig. 5. A snipped class diagram from JAPROSIM uml model after AO profile application.

References 1. S. Katz. Aspect-Oriented Software Development (AOSD). An advanced course at Tampere, Technion -Israel Institute of Technology, 2005. 2. T. GIL. Conception Orientée Aspects 2.0. Manning Publications, PARIS, 2004. 3. R. Laddad. AspectJ in Action: Enterprise AOP with Spring Applications. Second Edition, Manning Publications, Greenwich, USA, 2009. 4. R. Laddad. AspectJ in Action Practical Aspect-Oriented Programming. Manning Publications, 2003. 5. A. Schauerhuber, W. Schwinger, E. Kapsammer, W. Retschitzegger, M. Wimmer, and G. Kappel. A Survey on Aspect-Oriented Modeling Approaches. Publication database administration program of the Vienna University of Technology, 2007. 6. A. Bourouis and B. Belattar. JAPROSIM: A Java Framework for Discrete Event Simulation. In Journal of Object Technology, vol. 7, no. 1, January-February 2008, pp. 103-119, http//www.jot.fm/issues/issue 2008 01/article3/. 7. A. A. Zakaria, H. Hosny, and A. Zeid. A UML Extension for Modeling AspectOriented Systems. 2nd Workshop on Aspect-Oriented Modeling with UML, Dresden, Germany, September 2002. 8. O. Aldawud, T. Elrad, and A. Bader. Profile for aspect-oriented software development. The Third International Workshop on Aspect Oriented Modeling, 2003. 9. F. Asteasuain, B. Contreras, E. Estéevez, and P. R. Fillottrani. Evaluation of UML Extensions for Aspect Oriented Design. The IV JIISIC (Iberoamerican Conference on Software Engineering and Knowledge Engineering), Madrid, Spain, November 2004.


10


nd

10. A. Hovsepyan, R. Scandariato, S. V. Baelen, Y. Berbers, and W. Joosen. From Aspect-Oriented Models to Aspect-Oriented Code? The Maintenance Perspective. AOSD’ 10 Proceedings of the 9th International Conference on Aspect-Oriented Software Development, 2010. 11. F. Y. Villemin, CNAM. Introduction a ` UML 2.0., méthodologie avancée d’informatisation course, 2012 http://deptinfo.cnam.fr/Enseignement/CycleSpecialisation/MAI/index.html. 12. J. Brichau and T. Hondt. Aspect-Oriented Software Development (AOSD) - An Introduction. AOSD-Europe-VUB-02, 30 August 2005. 13. M. Chibani, B. Belattar, and A. Bourouis. Toward an aspect-oriented simulation. International Journal of New Computer Architectures and their Applications (IJNCAA), Vol. 3(1), pp.1-10, 2013. 14. I. Saqib and A. Gary. Aspect-Oriented Modeling: Issues and Misconceptions. In: Proceedings of Software Engineering Advances (ICSEA), 2010 Fifth International Conference. IEEE, Nice, France, pp. 337-340. ISBN 978-1-4244-7788-3. http://eprints.hud.ac.uk/9007/. 15. O. Aldawud, T. Elrad, and A. Bader. A UML profile for aspect oriented modeling. Workshop on Advanced Separation of Concerns in ObjectOriented Systems at OOPSLA2001, 2001, available at http://www.cs.ubc.ca/ kdvolder/Workshops/OOPSLA2 001/submissions/26-aldawud.pdf. 16. J. Evermann. A meta-level specification and profile for AspectJ in UML. In Journal of Object Technology, Volume 6, no. 7, 2007, pp. 27-49, doi: 10.5381/jot.2007.6.7.a2. 17. J. U. J` unior,V. V. Camargo, and C. V. Flach. UML-AOF, A Profile for Modeling Aspect-Oriented Frameworks.In: Proceedings of the 13th workshop on AspectOriented Modeling (AOM’09), Charlottesville, Virginia, USA, 2009, pp. 1-6, doi: 10.1145/1509297.1509299. 18. T. Gottardi, R. Aparecida, and V. V. Camargo. A Process for Aspect-Oriented Platform-Specific Profile Checking. In: Proceedings of the 2011 international workshop on Early aspects (EA?11), Porto de Galinhas, Brazil, March 21-25, 2011, pp. 1-5, doi: 10.1145/1960502.1960504. 19. M. Amroune, N. Zarour, P. J. Charrel, and J. M. Inglebert. An UML profile to model Aspects in AspeCiS approach. IEEE Second International Workshop on Advanced Information Systems for Enterprises, pp.34-39, 2012.


11