Models and Aspects – Handling Crosscutting Concerns in MDSD Forschungsberichte Der Fakultät IV – Elektrotechnik Und Informa

Forschungsberichte der Fakultät IV – Elektrotechnik und Informatik

Proceedings of the Third Workshop on Models and Aspects – Handling Crosscutting Concerns in MDSD at the 21st European Conference on Object-Oriented Programming (ECOOP) Berlin, Germany

Organizing Committee Christa Schwanninger, Siemens AG, Munich, Germany Markus Voelter, Independent Consultant, Heidenheim, Germany Iris Groher, Siemens AG, Munich, Germany Andrew Jackson, Trinity College Dublin, Ireland Michael Cebulla (Ed.)

Bericht-Nr. 2007 – 6

ISSN 1436-9915 Workshop Papers

A. Beugnard and C. Kaboré Interests and drawbacks of AOSD compared to MDE

Z. Altahat, T. Elrad, and D. Vojtisek Using Aspect Oriented Modeling to localize implementation of executable models

A. Rummler, B. Grammel, and C. Pohl Improving Traceability through AOSD

A. van den Berg, T. Cottenier, and T. Elrad Reducing Aspect-Base Coupling Through Model Refinement

L. Lengyel, T. Levendovszky, and H. Charaf Identification of Crosscutting Concerns in Constraint-Driven Validated Model Transformations

T. Reiter, M. Wimmer, and H. Kargl Towards a runtime model based on colored Petri-nets for the execution of model transformations

B. Morin, O. Barais, J.-M. Jézéquel, and R. Ramos Towards a Generic Aspect-Oriented Modeling Framework

Interests and drawbacks of AOSD compared to MDE

A position paper

A. Beugnard C. Kaboré ENST Bretagne ENST Bretagne CS 83818 CS 83818 F-29238 Brest cedex 3 F-29238 Brest cedex 3 [email protected] [email protected]

Categories and Subject Descriptors poses an other class of concerns: the platform. The platform D.2.10 [Software Engineering]: Design; D.1.5 [Programming describes the target environment with its own features. The techniques]: Object-Oriented Programming principle of the MDA is to merge a platform independent model (PIM) with a platform description model (PDM) in General Terms order to obtain a platform specific model (PSM). Beyond this simple principle, the model driven engineering approach Aspect programming, Model engineering generalizes and suggests to define more models and more models merging operations (called transformations). ABSTRACT This position paper is the result of experiences we made We experienced the MDE approach to automatize the devel- using model driven engineering to define an automatized opment of a special kind of components called communica- design process that injects different concerns during the de- tion components. These components have functional spec- velopment of components. We compare our approach with ification and we identified at least 4 concerns: data type classical aspect oriented programming techniques. We argue implementation, data distribution, data replication, data that the MDE approach is more flexible. representation. The full process is described in [3]. This experimentation leads us to a comparison of the AOSD and 1. INTRODUCTION MDE approaches. The quest for modularity is a long term research activity. Historically, functions were the first natural modules. Good 2. ASPECT ORIENTED PROCESS practices were promulgated to search for low coupling and Aspect oriented approaches rely on a description language high cohesion. But functions are often interleaved and mod- and a weaving mechanism. The language allows to spec- ule boundaries are difficult to identify. Software architec- ify the different concerns. The mechanism offers operations tures, architecture styles are topological abstractions that that are used during the weaving to merge the concern with help reasoning on modules, called components, and their in- the program. The weaving mechanism defines the aspect teractions, called connectors. But, considering functional technology approach; which operators are available, which properties is not enough; a lot of non-functional properties pointcuts can be used, etc. This defines the join point model. are worth trying to be isolated, placed in modules. Knowing this model, designers have to specify their concerns using the aspect language. A few years ago, aspect oriented programming [4] was introduced to separate concerns. Concerns, also called aspects, When many concerns are defined one of the not yet solved are described independently of the functional part of the sys- problem is to select the order of their weaving. This question tem, and are weaved with it during the development process. point out that weaving aspects (or concerns) is included in Concerns (or aspects) are a way to describe another dimen- a process. sion of modularity. But, concerns are, as functions, highly interleaved [2]. To our knowledge, no standard classification The AOP process can be summarized as follows: first, select is agreed today. a programming language; second, define join points and a way to identify them (the join point model), and eventually More recently, the object management group (OMG) has de- defines concerns. For instance: using Java, and AspectJ, TM fined the model driven architecture (MDA ) [1] that pro- the designer defines a logging aspect and weaves it to the program.

3. MODEL DRIVEN PROCESS The way model driven approach is used is less formalized than AOP, and still in construction. We used it with a special interpretation; instead of having only a PIM and a PDM model to merge into a PSM, we keep the PIM (considered as an abstract specification) and define many models, one for each the concerns we were interested in. Each concern gives raise to a meta-model (a specific grammar) that was used par les Modèles, pages 117–131, Toulouse, France, to define variants of the same concern. And for each meta- 29–30 mars 2007. model we defined a tailored transformation that injects this [4] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, concern into the trunk model (program). C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-oriented programming. In European Conference Having many concerns we had to choose their order of appli- on Object-Oriented Programming, volume 1241, pages cation. This is a design choice, that leads to adapted model 220 – 242, 1997. transformations. Transformations are developed knowing the result of the previous concerns merging.

The MDE approach we used can be summarized as follows: ﬁrst select a modelling language, second deﬁne a meta-model that can be used to specify the weaving transformations. 4. DISCUSSION Separation of concern is an essential design process. Two challenges are how to describe a concern and how apply it?

The aspect approach makes the choice to oﬀer an universal, generic, mechanism of weaving and requires that the concern designer adopt it and expresses concerns knowing this universal mechanism. All the ﬂexibility is in the concern description.

On the contrary, the model driven approach offers more flexibility. In fact, the concern designers decides first the way he describes the concern, selecting a concern meta-model, and after, elaborates a transformation that injects concerns into the base model. No universal merging (weaving) transformation is required. Every transformation is tailored.

We argue the MDE approach can be used to separate concerns in a more flexible way that the usual AOP does. Trans- formations implement automatized steps of the design process. Parts of this process are related to the woven concern and, hence, can be implemented thanks to model transformations. Our approach is pragmatic and consists in selecting an order of application of the chosen concerns. Other approaches may attempt to define transformations and (meta) models that are independent of the order of application. At that time, our approach seems more tractable since more constrained; building commutative and associative transformations is difficult. The resulting transformations of our approach depend on the development process.

We also argue that concerns must be selected, analyzed, specified, modeled prior to their weaving process. The concern model influence the weaving transformation, but the implementability of the transformation may also influence the concern model. This is why the flexibility offered by MDE is so important. 5. REFERENCES [1] A. Board. Model driven architecture (mda). Technical report, Object Management Group, July 2001. http://www.omg.org/cgi-bin/doc?ormsc/2001-07-01. [2] L. Chung, B. A. Nixon, and E. Yu. Non-Functional Requirements in Software Engineering. Springer, January 1999. ISBN-10: 0792386663, ISBN-13: 978-0792386667. [3] E. Kabore and A. Beugnard. Conception de composants répartis par transformations de modèle(, antoine beugnard). In Journéesde l’Ingénierie Dirigée Using Aspect Oriented Modeling to localize implementation of executable models Zaid Altahat Tzilla Elrad Didier Vojtisek GE Healthcare Illinois Institute of Technology INRIA Illinois Institute of Technology [email protected] [email protected] [email protected]

ABSTRACT Executable models are essential to define the behavior of models, One way to constrain the behavior of a model element, a Class for such as constraints put on model elements. However their example is to define Invariant condition on the class, and pre and implementation crosscut multiple model elements. Model post conditions on its operations. These three are what is referred semantics will facilitate Model Driven Development, without it, to as DBC, which KerMeta already provides capabilities of; Design and Implementation won’t necessarily represent different however it achieves that individually for each class and operation. abstractions of the same system. This paper introduces a To manually define constraints for each class and operation may mechanism to query executable models and weave constraints in lead to code redundancy and reduction in modularity. The added order to localize their implementation, which improves code constraints crosscut [3] multiple classes and operations. Aspect- redundancy and modularity. Oriented Modeling (AOM) can help in obviating this problem. AOM provides separation of crosscutting concerns at the models Keywords level. Most popular among these models are behavioral models, Executable Models, Aspect-Oriented Modeling (AOM), Model which are used in software development, not just for design and Driven Development (MDD), Model Driven Architecture (MDA), documentation but for code generation as well. To set foundations Aspect-Oriented Software Development (AOSD). for the code generation and model transformation, new standards are being defined as part of Model Driven Architecture (MDA) 1. INTRODUCTION group. MDA standards are being set in parallel to AOM. MDA transforms a model from high abstract level to platform specific Models have been limited in use to design and documentation. level then to code. AOM also help in keeping crosscutting models Designs are lost by interpretation when moved from system separate, as well as transforming Platform Independent Models architects (Design) to software engineers (Implementation). The (PIM) to Platform Specific Models (PSM) by weaving in platform design doesn’t dictate the models semantics. Semantics are “the dependent model implementation. underlying meaning of exchanged models, that is, the constraints that models place on the runtime behavior of the specified Using AOM approach we will demonstrate how to localize the system.” [7] . Design By Contract (DBC) is an example of implementation of a crosscutting behavior that intersect multiple constraints on the model behavior; however their implementation classes and/or operations. In AOM a pointcut model, and an is not localized and crosscut [3] multiple model elements. advice model are defined. Both models and the original models are fed into a weaver. The weaver adds the advice, added A programming language consists of syntax and semantics. behavior, to the join points matched by the pointcut in the model. Syntax is the language constructs, such as UML class diagrams; This paper introduces a novel approach for the modularization while, semantics give the syntactic constructs their meaning. and weaving of executable models. Leaving out the semantics of models created a gap that lead to a wide range of interpretations of the same model. The gap also The main contribution of this paper is to provide a model driven created a chain of tools that can only exchange the syntax of approach to query and weave executable model elements into models. Executable models came to fill in this gap. models. The problem this approach tackles is to localize the DBC constraints for executable models; moreover, localize the Executable models constrain how models behave at run time. implementation of operations. Which reduces code redundancy Code generated from models should have a unique execution and increases modularity. The project was done in KerMeta for behavior. Unique in the sense that if different codes, programming both querying and weaving executable model elements, it is a languages such as Java or C++, to be generated, all should have pure model driven approach that operates on executable models. the same execution behavior. UML is in the process of fully defining Executable UML [7] . KerMeta [5] on the other hand has already defined full behavioral language to specify semantics of models. Section 3 briefly presents KerMeta. Paper is organized as follows: Section 2 presents related work and operation is do section 3 briefly describes KerMeta. Section 4 is the core of this isInstance(element : Element) : Boolean paper; it presents the details of the metamodels used, as well as // false if the element is null the weaving process. Besides, Section 5 demonstrates the if element == void then result := false querying and weaving process on an example model. Original model and modified model are presented in Appendices A and B, else respectively. // true if the element is an instance of this type 2. Related Work // or a subclass of this type There are other attempts to localize DBC constraints. However result := element.getMetaClass == self or they were designed with a specific programming language in mind. A C++ approach [10] presented a mechanism to localize element.getMetaClass.allSuperClasses.cont DBC implementation using Constraint-Specification Aspect ains( self ) [9] [4] Weaver (C-SAW) . ECL was used to locate operations, in end addition to weave assertions at the beginning and end of an end operation to represent pre and post conditions, respectively. No support for Invariant condition. Another approach, Contract4J [2] , Listing 2. KerMeta definition of method isInstance() uses AspectJ to support DBC in Java. It uses Java 5 annotations to mark elements to be amended and define the pre , post , and This work is a demonstration of several of them. The most Invariant conditions. It uses AspectJ behind the scenes to weave [12] in the added code. In contrast with my approach, both of these important is that it reflectively applies MDA to itself . In this approaches are geared more towards a specific programming paper, KerMeta is applied at two levels. First, the language is used language and are not based on executable models. to define the transformation that constitutes the metamodel weaver. Second, the weaving is applied to KerMeta itself by 3. KerMeta introducing the advices in models written in KerMeta. Meta-languages such as MOF1.4 [5] , MOF2.0 [6] , and Ecore [1] are used to specify the structural and syntax parts of a model but not 4. Metamodel Weaver its behavior. For example EMOF specifies an operations The weaver consists of several metamodels, a pointcut signature and stops there, without defining its behavior. A mix of metamodel, an advice (added behavior) metamodel, a link pseudo code and natural language is used to define its behavior. metamodel, and the weaver itself, presented in Figure 1. The KetMeta on the other hand uses an operational semantic to specify following sections present each of these metamodels in details. [11] the precise behavior of models. The example presented in Listings 1 and 2 shows how the definitions of the same method in both MOF and KerMeta.

Operation isInstance(element : Element) : Boolean “Returns true if the element is an instance of this type or a subclass of this type. Returns false if the element is null ”. Listing 1. MOF definition of method isInstance()

KerMeta proposes a rich model oriented environment for metamodeling. It provides support for many use cases, including:

• Implementation of operations directly in metamodels. • Execution of simulation of metamodel behavior. • Transformation and weaving of models. Figure 1 Weaver Metamodel • Verification and validation of models against metamodels (as given by a set of static and dynamic constraints). Weaver::weave , shown in Figure 1, is the starting operation, it is passed a collection of Link and a collection of Model . Link defines • Building new Domain Specific Languages under the a relation between a pointcut MatchPattern and an Advice . For shape of metamodels, Building any model-driven tools, ach join point matched by a pointCut behavior is added. including tools that generate tools (generative programming). Advice has multiple operations getInvariant, getPreCond, and getPostCond to retrieve Invariant , pre and post condition, respectively. An instance advice inherits from Advice and overwrites operationAbs in order to define pre and post conditions. Instance advice can also hold other operations definitions that needs be added to the model. They are retrieved using the operation getOps. This is to provide an operation implementation into a class. Section 5 presents an example with added behavior. Figure 2 shows the pointcut metamodel, MatchPattern . All elements, except MatchPattern , inherit from MatchPattern and with it they inherit the string namePattern to define its name signature. The matching signature consists of a ClassPattern class that has a collection of AttributePattern and a collection of OperationPattern , which in turns has a collection of ParamPattern . All elements inside ClassPattern are optional, Figure 3 Bank metamodel that’s a pointcut in its simplest format is a class name pattern, for * Class Account doesn’t have Invariant . None of the example *Account that will match all classes that end with operations has pre or post conditions, and applyInterest Account . Match patterns used here are similar to AspectJ name is abstract. matching. Section 5 presents an example with pointcut.

Figure 2 Pointcut metamodel The model in Figure 3 represents the element model in Figure 1. The Weaver needs link element(s) to define what behavior to add for a matched pointcut. Figure 4 introduces two of these Link elements. In Figure 4-a a Link is created with a pointCut that matches the operations updateBalance and withdraw . Advice1 5. Example defines the behavior to be added, it introduces the Invariant Next we’ll introduce an example where blocks of executable condition to the matched class, and the post condition to the models were weaved into model elements, classes and operations. matched operations. Figure 3 introduces a basic Bank system with different type of Figure 4-b defines another Link with a pointCut that matches accounts. One thing to note about the class Account is that the classes CheckingAccount and BusinesAccount that inherit from class itself doesn’t have Invariant condition and none of its the class Account . The behavior to be added is an implementation operation has a pre or a post condition, which will be added using for the operation applyInterest . More elements could be used to the weaver. Also the operation applyInterest is abstract where its define more model queries, like number and type of parameters to implementation will be weaved in for two of Account subclasses an operation and its return type. More involved queries were run only. KerMeta representation of the model is presented in on larger models, but for sake of simplicity I introduced these Appendix A. queries on the Bank system.

to query and weave executable models. We chose to localize the implementation of DBC constructs and shared operations implementations in order to improve code redundancy and modularity. In pointcut metamodel we used strings to define many of the match pattern elements, as shown in Figure 2. In the future we’d like to change the parameter type and operation return type to kermeta::language::structure::Type . This will enable us to check for types and super-types, such as Integer and Collection, without having to use strings. It will also enable us to check for validity of operation arguments. However, using the element Type will complicate writing queries and the actual querying process.

7. REFERENCES [1] Budinsky, F., Steinberg, D., Merks, E., Ellersick, R. and Grose, T. Eclipse Modeling Framework . Addison Wesley Professional, 2003. Figure 4-a An instance of Link with a pointcut that matches [2] Dean Wampler, “AOP@Work: Component design with operations updateBalance and withdraw in class Account , and Contract4J”. pre and post conditions. http://www28.ibm.com/developerworks/java/library/j- aopwork17.html

[3] Diotalevi, F., “Contract Enforcement with AOP,” IBM

DeveloperWorks , July 200 4, http://www- 106.ibm.com/developerworks/library/j-ceaop/ [4] Gray, J., Sztipanovits, J., Schmidt, D., Bapty, T., Neema, S., and Gokhale, A., “Two-level Aspect Weaving to Support Evolution of Model-Driven Synthesis,” in Aspect-Oriented Software Development , (Robert Filman, Tzilla Elrad, Mehmet Aksit, and Siobhán Clarke, eds.), Addison-Wesley, 2004. [5] OMG. Meta Object Facility (MOF) Specification 1.4, Object Management Group,http://www.omg.org/cgi- bin/doc?formal/2002-04-03, 2002. [6] OMG. MOF 2.0 Core Final Adopted Specification, Object Management Group,http://www.omg.org/cgi-bin/doc?ptc/03- 10-04, 2004.

[7] OMG, “Semantics of a Foundational Subset for Executable UML Models” 2006. Figure 4-b An instance of Link with a pointcut that matches classes CheckingAccount and BusinessAccount whose parent [8] http://www.kermeta.org/ are Account , and implementation for operation applyInterest . [9] http://www.gray-area.org/Research/C-SAW/ [10] Jing Zhang, Jeff Gray and Yuehua Lin. "A Model-Driven The weaver iterates on each element in the Bank model and Approach to Enforce Crosscutting Assertion Checking". applies each link on it. It iterates on the elements twice, once for [11] Pierre-Alain Muller, Franck Fleurey, Didier Vojtisek, Zoé each link. In the first pass it adds the Invariant condition to the Drey, Damien Pollet, Frédéric Fondement, Philippe Studer class Account and the post condition to the operations and Jean-Marc Jézéquel. “On Executable Meta-Languages updateBalance and withdraw . In the second pass it adds the applied to Model Transformations” operation applyInterest to the classes CheckingAccount and [12] Jean Bézivin, Nicolas Farcet, Jean-Marc Jézéquel, Benoît BusinessAccount . Appendix B presents the generated modified Langlois, and Damien Pollet. -- Reflective model driven model, and Appendix A present the original model before any engineering. -- In G. Booch P. Stevens, J. Whittle, editor, modifications. Proceedings of UML 2003, volume 2863 of LNCS, pages 175--189, San Francisco, October 2003. Springer.

6. Conclusion and future work Executable models are getting high attention in order to add semantics to PIM models. In this paper we presented a novel way 8. Appendix A 9. Appendix B This Appendix shows only modified classes and operations. Unmodified classes were left out and are identical to the originals /* Class Customer was not modified, it was left out from this presented in Appendix A. Weaved code is in the red box. appendix.*/ class Account woven models. { class Account inv balanceValue is { do attribute balance : kermeta :: standard :: Integer balance .isGreaterOrEqual (0)

end operation updateBalance (amnt : attribute balance : kermeta :: standard :: Integer kermeta :: standard :: Integer ) operation applyInterest (ratio : kermeta :: standard :: Real ): is do kermeta :: standard :: ~Void is abstract balance := amnt operation end updateBalance (amnt :ker meta :: standard :: Integer ) :

kermeta :: standard :: ~Void operation getBalance () : kermeta :: standard :: Integer post post1 is do is do result .isNotSameAs (void ). ~and (balance .isGre result := balance aterOrEqual (0)) end end

is do balance := amnt end operation withdraw (amnt : kermeta :: standard :: Integer ) operation getBalance () : kermeta :: standard :: Integer is is do do result := balance end balance := balance - amnt operation withdraw (amnt : kermeta :: standard :: Integer ) : end kermeta :: standard :: ~Void

post post1 is do operation applyInterest (ratio : kermeta :: standard :: Real ) result void is .isNotSameAs ( ). ~and (bal

abstract ance .isGreaterOrEqual (0)) } end is do balance := balance .minus (amnt ) end class CheckingAccount inherits Account } { } class CheckingAccount inherits Account { class SavingAccount inherits Account operation applyInterest (ratio : kermeta :: standard ::Real ) : { } kermeta :: standard :: ~Void is do stdio .writeln ("Adding fund$..." ) class BusinessAccount inherits Account end { } } class BusinessAccount inherits Account { operation applyInterest (ratio : kermeta :: standard :: Real ) : kermeta :: standard :: ~Void is do stdio .writeln ("Adding fund$..." ) end

} Improving Traceability through AOSD

Andreas Rummler Birgit Grammel Christoph Pohl SAP Research CEC Dresden SAP Research CEC Dresden SAP Research CEC Karlsruhe Chemnitzer Str. 48 Chemnitzer Str. 48 Vincenz-Priessnitz-Str. 1 01187 Dresden, Germany 01187 Dresden, Germany 76131 Karlsruhe, Germany andreas.rummler@ birgit.grammel@ christoph.pohl@ sap.com sap.com sap.com

1. INTRODUCTION In real world business applications traditional software product line engineering and model-driven software development (MDSD) [6] often cannot properly reﬂect the decomposition of system features. For instance, Governance, Risk and Compliance (GRC) checks or late introduction of se- curity properties often crosscut the architectural design of a system. To overcome these issues Aspect-Oriented Soft- ware Development (AOSD) [1] modularizes such crosscutting concerns in independent aspects. Although aspects can already be captured at requirements stage [2, 7], there is no clear mapping to later development stages. MDSD can address this by model transformation. However, AOSD still increases the complexity of traceability (and hence, maintainability) because it adds yet another dimension of variability [3]. This issue is one of the most important arguments against applying AOSD techniques in an industrial context. Future research has to take care of this issue in order to lay the basis for industry acceptance of AOSD. According to an internal audit of customers of SAP, missing traceability during the whole development cycle is the top-rated weakness. In addition missing traceability information was explicitly mentioned as weakness in 2005 in an external ISO certiﬁca- Figure 1: Linking of Artifacts in SAPs Development tion audit. Process

2. TRACEABILITY SUPPORT INSIDE SAP ity as outlined above tangles not only code but also such The current state of trace support implemented in SAPs in- models. ternal development process is outlined in figure 1. Market requirements are linked to software specifications comprising software requirements that can be linked to test cases. Further linkage of requirements to design and development 3. IMPROVING TRACEABILITY artefacts, or linkage of those artefacts to test cases is possible THROUGH AOSD in general, but not sufficiently supported by tools (indicated There are approaches to Aspect-Oriented Requirements En- by dashed lines). Currently, several interesting questions gineering (AORE) [2, 7] that can help address some of these typically arising during the development process cannot be questions. For instance relationships, dependencies and in- answered automatically: Have all high-level market require- teractions among existing requirements can be identified at ments really been designed and implemented properly? How early stages of the development lifecycle. However, AORE can this implementation be tested against these require- approaches do not explicitly define mechanisms for mapping ments? Have artefacts been developed whose behaviour is information gathered at the requirements level to later devel- not covered by any requirements or which is even unwanted? opment phases. There is a need for defining mapping guide- Why has one artefact been chosen over another, alternative lines, rules, and heuristics for mapping of entities and trace one? These question can be answered on a fine-grained level information across the entire development lifecycle. Assets by experts involved in the development process, but not by repositories are also required that may collect and main- people dealing with a coarse-grained view. Therefore tools tain product line assets and the mapping rules, guidelines, are needed that are able to give reasonable answers to these and heuristics. In addition, there is a need for a traceabil- questions or at least help people in finding those answers. ity meta-model that defines which trace information: assets, MDSD has its merits for transforming artefacts into each concerns, relationships, dependencies, behaviours, composi- other based on certain models, but crosscutting functional- tions, mappings, needs to be captured and managed. SAP Research is currently involved in an European funded frameworks with aspect-oriented programming. In project called AMPLE, which stands for Aspect-Oriented, Proceedings of the International Conference on Model-Driven Product Line Engineering.1 The focus is on Software Reuse ICSR 06, 2006. providing a holistic treatment of variability by addressing [6] T. Stahl and M. Völter. Model-driven Software each stage in the software life cycle. Another point of inter- Development. John Wiley, 2006. est in AMPLE is providing effective forward and backward [7] B. Tekinerdogan, A. Moreira, J. Araujo, and traceability of variations and their impact. P. Clements. Early aspects: Aspect-oriented requirements engineering and architecture design. In The approach followed in AMPLE relies on the modular- Workshop Proceedings at AOSD Conference, 2005. ization of cross cutting concerns at model level. Starting already at the stage of requirements engineering will foster traceability. To be able to track dependencies between AO and non-AO artefacts along the development cycle, explicit aspect interfaces need to be defined. To rely on earlier work already made available in [4] and [5] seems to be promising. The intrusive nature of AO techniques is reduced in its in- tensity by defining aspect interfaces that form some kind of contract between the to-be-extended system and the extending aspects. Other ongoing work concerns a metamodel for variability including the support of AO concepts and appro- priate tracing information. Based on this metamodel a tool chain is designed that supports the definition of SPL, product generation and full support for tracing relationships and dependencies among automatically generated or manually created artefacts. A comprehensive case study is currently being implemented, consisting of a complete example from SAPs core application business.

4. CONCLUSIONS To summarise this position paper, tracing artefacts through- out the whole development process is a key issue in industry, driven by internal and external forces. Handling variability and documenting decisions on variations is the core issue of traceability. AOSD approaches introduce interesting concepts to modularise cross-cutting concerns at various development stages but it also complicates traceability. Explicit aspect interfaces are one requirement for easier tracking of dependencies between AO and non-AO artefacts. At the workshop, we would like to share our industry perspective on how AOSD and MDSD could further fertilise each other for improving traceability issues, among other challenges.

5. REFERENCES [1] R. E. Filman, T. Elrad, S. Clarke, and M. Aksit. Aspect-Oriented Software Development. Addison-Wesley, 2005. [2] J. Grundy. Aspect-oriented requirements engineering for component-based software systems. In Proceedings of the 4th IEEE Symposium on Requirements Engineering, 1999. [3] S. Katz and A. Rashid. From aspectual requirements to proof obligations for aspect-oriented systems. In Proceedings of the 12th IEEE International Conference on Requirements Engineering, 2004. [4] G. Kiczales and M. Mezini. Aspect-oriented programming and modular reasoning. In Proceedings of the ACM International Conference on Software Engineering, 2005. [5] U. Kulesza, V. Alves, A. Garcia, C. Lucena, and P. Borba. Improving extensibility of object-oriented 1The website for the project can be found at http://www. ample-project.net Reducing Aspect-Base Coupling Through Model Refinement

Aswin van den Berg Thomas Cottenier Tzilla Elrad Motorola Software Group, Motorola Motorola Software Group, Motorola Illinois Institute of Technology 1303 E. Algonquin Rd, 1303 E. Algonquin Rd, 3100 S. Federal Street, Schaumburg, IL 60196, USA Schaumburg, IL 60196, USA Chicago, IL 60696, USA +1 (847) 538-2597 +1 (847) 538-2597 +1 (312) 567-5142 [email protected] [email protected] [email protected] Illinois Institute of Technology 3100 S. Federal Street, Chicago, IL 60696, USA [email protected] ABSTRACT between base modules and aspects. AOP languages allow pointcut descriptors to refer directly to the implementations of Aspect-Oriented Programming languages allow pointcut modules to capture joinpoints, points where aspects inject descriptors to quantify over the implementation points of a behavior through advices. This practice is problematic with system. Such pointcuts are problematic with respect to respect to modularity and independent development. Aspects independent development because they introduce strong mutual need fine-grained control over the modules they advice and, coupling between base modules and aspects. This position paper vice versa, the advised modules need to be aware of those addresses the aspect-base coupling problem by defining pointcut aspects. Therefore, both aspect and base module become hard to descriptors in terms of abstract views of the base module. These evolve independently. abstract views should be towards the architectural viewpoints of There are three main research directions in addressing this the system under development. aspect-base coupling problem. The first direction of research Categories and Subject Descriptors advocates restricting the expressiveness of aspects by forfeiting the obliviousness of modules [1][2][3]. A second approach D.2.1 [Software Engineering]: Design Tools and Techniques – favors investigating alternative ways to modular reasoning in modules and interfaces. D.2.1 [Software Engineering]: Design the presence of aspects. In [4], the authors argue that a global Tools and Techniques – Object-oriented design methods. D.3.3 analysis of the system configuration is required before the [Programming Languages]: Language Constructs and Features interfaces of the system modules can be determined. A third – classes and objects, modules, inheritance. direction of research focuses on methods that allow pointcut descriptors to be defined at a higher level of abstraction, in General Terms terms of the program semantics [5]. Our work with Motorola Languages, Theory, Algorithms. WEAVR in [6] introduces pointcut descriptors that can infer implementation joinpoints from higher level descriptions. This Keywords paper proposes an approach to AO modeling that is integrated Aspect weaving, modeling, refinement, aspect-oriented with a model refinement approach with the purpose to reduce modeling. model-driven software engineering, aspect-oriented the aspect-base coupling. programming.

1. INTRODUCTION 2. REQUIREMENTS FOR ASPECT-BASE DECOUPLING Since the inception of Aspect-Oriented Software Development (AOSD) in 1997, it has been known that Aspect-Oriented Programming (AOP) languages introduce strong coupling match

Joinpoints Pointcut Descriptor +=M0 = f(M1) M0

-1 f f

M1 Joinpoints M1 Refinement

instantiate

Advice Descriptor M2 = Woven_M1

Figure 1: Aspect weaving seen as a model refinement expressed in terms of a realization mapping (f)

it. Therefore there is no aspect-base coupling between the aspect Let M1 be the current refinement of a software system. We and the refinements introduced from M0 to M1. show five requirements for moving towards our goal (see Figure 1): 3. REFERENCES 1. There needs to be an abstract view M0 of the refinement M1 of the system under development that is [1] Aldrich, J. Open Modules: Modular Reasoning about sufficiently describing the behavior of its specification Advice. In Proceedings of the 19th European Conference on towards a particular architectural viewpoint. Object-Oriented Programming, Glasgow, Scotland, LNCS 2. There needs to be a precise definition of what it means 3586, pp. 144-168, Springer, 2005 that a refinement is realizing an architectural view. [2] Griswold, W.G., Shonle, M., Sullivan, K., Song, Tewari, This realization can be described by a well-defined N., Cai, Y., Rajan, H.: Modular Software Design with mapping f from the refinement M1 to the view M0. Crosscutting Interfaces. IEEE Software, 23:1, pp. 51–60, 3. The development process/tool needs to enforce that the IEEE Computer Society, 2006 refinement of the view is actually realizing the view. That is, the process/tool needs to enforce the realization [3] Gybels, K., Brichau, J.: Arranging Language Features for invariant M0 = f(M1). More Robust Pattern-Based Crosscuts. In proceedings of 4. Define pointcut descriptors in terms of the view M0. the International Conference on Aspect-Oriented Software The matching produces a set of joinpoints in M0 Development, , Boston, USA, pp 60–69, ACM Press, 2003. (denoted by JoinpointsM0) [4] Kiczales, G., Mezini, M.: Aspect-Oriented Programming 5. Translate these joinpoints in terms of the refinement and Modular Reasoning. In proceedings of the M1 and instantiate the advice at corresponding points International Conference on Software Engineering, St. in M1. The resulting woven model M2 is more refined Louis, USA, pp 49–58, ACM Press, 2005 than M1 because it has a new concern incorporated in [5] Ostermann, K., Mezini, M., Bockisch, C.: Expressive it. Pointcuts for Increased Modularity. In Proceedings of the

19th European Conference on Object-Oriented Since the pointcut descriptor is written in terms of M0 it is Programming, Glasgow, Scotland, LNCS 3586, pp. 214- completely independent from the refinements that are 240, Springer, 2005 introduced in M1. Since M0 is an abstract view towards an [6] Cottenier, T., van den Berg, A., Elrad, T., Joinpoint architectural viewpoint it is not a view that is dependent on the Inference from Behavioral Specification to Implementation, pointcut descriptor. And because M0 is not dependent on the In Proceedings of the 21st European Conference on Object- pointcut descriptor it follows that also M1 is not dependent on Oriented Programming (ECOOP), Berlin, Germany, 2007 Identiﬁcation of Crosscutting Concerns in Constraint-Driven Validated Model Transformations

László Lengyel Tihamér Levendovszky Hassan Charaf Budapest University of Budapest University of Budapest University of Technology and Economics Technology and Economics Technology and Economics 1111 Budapest, Goldmann 1111 Budapest, Goldmann 1111 Budapest, Goldmann György tér 3., Hungary György tér 3., Hungary György tér 3., Hungary [email protected] [email protected] [email protected]

ABSTRACT Model transformation lies at the heart of the model-driven Domain-specific model processors facilitate the efficient syn- approaches [11] [20]. Transformations appear in many, dif- thesis of application programs from software models. Of- ferent situations in a model-based development process. A ten, model compilers are realized by graph rewriting-based few representative examples are as follows. (i) Refining the model transformation. In Visual Modeling and Transfor- design to implementation; this is a basic case of PIM/PSM mation System (VMTS), metamodel-based rewriting rules mapping. (ii) Aspect weaving; the integration of aspect facilitate to assign Object Constraint Language (OCL) con- models/code into functional artifacts is a transformation on straints to model transformation rules. This approach sup- the design [1]. (iii) Analysis and verification; analysis algo- ports validated model transformation. Unfortunately, the rithms can be expressed as transformations on the design validation introduces a new concern that often crosscuts the [2]. functional concern of the transformation rules. To separate these concerns, an aspect-oriented solution is applied for One can conclude that transformations in general play an constraint management. This paper introduces the identifi- essential role in model-based development, thus, there is a cation method of the crosscutting constraints in metamodel- need for highly reusable model transformation tools that based model transformation rules. The presented algorithms support validated model transformation. make both the constraints and the rewriting rules reusable, furthermore, supports the better understanding of model At the implementation level, system validation can be achieved transformations. by testing. Various tools and methodologies have been developed to assist in testing the implementation of a system (for example, unit testing, mutation testing, and white/black Categories and Subject Descriptors box testing). However, in the case of model transformation D.2.2 [Software Engineering]: Design Tools and Tech- environments, it is not enough to validate that the transfor- niques mation engine itself works as it is expected. The transformation specification should also be validated. There are only General Terms few and not complete facilities provided for testing offline Algorithms, Design and Languages transformation specifications in an executable style. How- ever, online validated model transformation can guarantee that if the transformation finishes successfully, the generated Keywords artifact is valid, and it is in accordance with the required Aspect-Oriented Constraints, Constraint Weaving, Identify- output [8] [9]. ing Crosscutting Constraints, Model Transformation For example, require a transformation that transforms class 1. INTRODUCTION model to relational database management system (RDBMS) Model-driven development approaches (for example Model- model (transformation Class2RDBMS) to guarantee the fol- Integrated Computing (MIC) [19] and OMG’s Model-Driven lowings: a class that is marked as non-abstract in the source Architecture (MDA) [14]) emphasize the use of models at model is transformed into a single table of the same name all stages of system development. They have placed model- in the target model, each table has primary key, each class based approaches to software development into focus. attribute is part of a table, each many-to-many association has a distinct table, and so on.

These types of requirements can be specified by Object Con- straint Language (OCL) [14] constraints assigned to the transformation rules. Unfortunately, often, the same constraint is repetitiously applied in many different places in a transformation, therefore the constraints crosscut the transformation rules and their management becomes hard. In [7], a solution of the case study Class2RDBMS is provided where a transformation is presented with 9 transformation rules and two constraints are emphasized, from which the first one appears 30 times in 9 transformation rules and the second one 16 times in 6 transformation rules. This is very difficult to manually manage crosscutting and scatter- ing constraints, because all of the modifications have to be done on all occurrences of the constraints. Constraints appearing several times in a transformation increase the time of constraint handling and the possibility of making a mis- take during the modification. Using aspect-oriented constraints, a method has been given to solve the problem of the crosscutting constraint in model transformations [7] [9]. Figure 1: Example transformation rule: The main idea is to handle constraints similarly to Aspect- ClassToTable Oriented Programming (AOP) aspects, to provide the transformation constraints with the properties of the AOP aspects. AO constraints are created separately from transformation rules and, using a weaver method, they are woven formation rule during the model transformation process. back to the transformation rules before the execution of the transformation. The result of this method is a consistent In VMTS, LHS and RHS of the transformation rules are constraint management (modification, deletion, and propa- built from metamodel elements. This means that an instan- gation) with crosscutting constraint separation and weaving. tiation of LHS must be found in the input graph instead of the isomorphic subgraph of LHS. The current work proposes a method to identify the crosscutting constraints in model transformations. Our motiva- Rewriting rules can be made more relevant to software engi- tion is driven by the fact that transformation designers pre- neering models if the metamodel-based specification of the fer defining transformation rules directly with constraints. transformations allows assigning OCL constraints to the in- Therefore, a solution should be provided to extract con- dividual transformation rules. This technique facilitates a straints from existing transformation rules. The proposed natural representation for multiplicities, multi-objects and method makes both the constraints and the rewriting rules assignments of OCL constraints to the rules with a syn- reusable, furthermore, facilitates the better understanding tax close to the UML notation. An example metamodel- and maintainability of the metamodel-based model trans- based transformation rule that generates database tables formations. from UML classes is depicted in Fig. 1.

The constraints assigned to the transformation rule guar- 2. BACKGROUNDS antee our requirements. After a successful rule execution, This section as a background information introduces the the conditions hold and the output is valid, this cannot be Visual Modeling and Transformation System (VMTS), the achieved without constraints. problem of the crosscutting constraints in metamodel-based model transformation rules, and the methods provided by VMTS to define and apply transformation constraints as 2.2 Crosscutting Constraints aspects. In model transformation, the dominant decomposition is the functional behavior of the transformation rules. The con- Graph rewriting [17] is a powerful technique for graph trans- straints ensure the correctness of the transformation only formation with a strong mathematical background. The if they are well-defined by the designer. Although they atoms of graph transformations are rewriting rules, each rule are responsible for the correctness, the constraints are usu- consists of a left-hand side graph (LHS) and right-hand side ally treated with secondary importance. They crosscut the graph (RHS). Applying a graph rewriting rule means find- transformation, and it is almost impossible for the designer ing an isomorphic occurrence (match) of LHS in the graph to perform the intuitive activity of verifying the transforma- to which the rule is applied (host graph), and replacing this tion. subgraph with RHS. Our motivating example (transformation ClassToRDBMS) is presented in the previous section. Constraints such as 2.1 Visual Modeling and Transformation Sys- NonAbstract, PrimaryKey, and ClassAttrsAndTableColls (Fig. tem 1) cannot be encapsulated in any of the rules or rule nodes. Visual Modeling and Transformation System (VMTS) [21] However, they express the same constraint concerns on the supports editing models according to their metamodels, and rules: therefore they should be defined separately from the allows specifying constraints written in Object Constraint transformation rules and woven automatically to the appro- Language (OCL) [14]. Models are formalized as directed, priate rule nodes later. labeled graphs. VMTS uses a simplified class diagram for its root metamodel (”visual vocabulary”). Also, VMTS is Since there is not enough space to present all transforma- a model transformation system, which transforms models tion rules and all occurrences of the constraints appearing using graph rewriting techniques. Moreover, the tool facili- in rule CreateTable, we provide statistical data only, and tates the validation of the constraints specified in the trans- the details can be found in [9] and [21]. The transformation Class2RDBMS contains nine transformation rules. In these rules the constraint NonAbstract appears 30 times, constraint Abstract, which requires the presence an abstract class, appears 16 times. Furthermore, the constraints Pri- maryKey and PrimaryAndForeignKey are linked 6 times, and constraints OneToOneOrOneToMany and ManyToMany, which are related to processing the associations between classes, appear 4 times [7]. This means that one of the open issues with respect to the transformation is that the same constraints appear several times. 2.3 Aspect-Oriented Constraint Management in VMTS As it was presented in the previous section, in model transformation, some constraints assigned to transformation rules represent the crosscutting concerns.

In VMTS, aspect-oriented constraints are OCL constrains defined separately from the transformations and transformation rules, and are woven to the rules later using a weaver method. Recall that in VMTS, transformation rules are built from metamodel elements, where a metamodel element can appear arbitrary times in a transformation rule. A rule is not an instance of the metamodel, both of them are on the same meta level. The input and output models are the Figure 2: The weaving process and the input and instances of the metamodels. Each transformation rule node output of the GCW and edge has a metatype that corresponds to a metamodel type. The context information of the aspect-oriented constraints can be used as a type-based pointcut that selects rule nodes based on their metatype. The weaving process dently of any model transformation rule or rule node and driven by the type-based pointcuts is referred to as type- are linked to rule nodes by the GCW. based weaving [10]. In Fig. 1, Class is the context of the constraint NonAbstract and the target rule nodes (rule node The output of the weaver is not stored as a new transfor- Class in LHS and rule node Class in RHS) of the propaga- mation rule. The result is handled as a link between the tion are selected based on this metatype. constraints and a transformation rule. This link is referred to as weaving configuration [10]. A weaving configuration To refine the weaving procedure, weaving constraints are can be executed similarly to a transformation. The differ- applied. A weaving constraint is similar to a property- ence is that it contains the links between the transformation based pointcut, it is also an OCL constraint, which specifies rule nodes and the constraints, therefore, during the execu- the weaving, but it is not woven to transformation rules, tion the transformation engine applies the constraints woven and thus, it is not used during the transformation process. to the transformation rules. Weaving configurations are cre- Weaving constraints facilitate optional conditions during the ated once, they are stored in the database, but they require weaving process. Therefore, it is referred to as constraint- significantly less space than transformation rules, because based weaving in VMTS [10]. A weaving constraint can weaving constraints represent only the rule-constraint rela- be used to represent one or many characters as a means tions. Furthermore, this representation makes the transfor- of specifying more than one attribute during a search pro- mation rule management transparent: it is not required to cedure. This enables to select multiple rule nodes with a modify the rules in each weaving configuration, but only on single specification. For example, the propagation of con- their original place. straint PrimaryKey (Fig. 1) can be refined with weaving constraints. The constraint PrimaryKey can be separated 2.4 Constraint Normalization in VMTS from the transformation rules, and using the weaving con- OCL constraints often contain complex expressions with sev- straint table.name = ’Table*’ it can be woven to rule nodes, eral navigation steps. The constraint evaluation consists of whose names start with the ’Table’ character sequence. two parts. (i) Selecting the object and its properties that the constraint needs to be checked on, and (ii) executing Having separated the constraints from rule nodes, we also the checking. In general, the larger part of the evaluation need a weaver which facilitates the propagation (linking) is the first step, because of its computational complexity. of the constraints to the rule nodes. Our approach solves Each navigation step in a constraint means several queries the aspect-oriented constraint propagation with the Global on the model database. Therefore the original motivation Constraint Weaver (GCW) algorithm [9] (Fig. 2). of the normalization method was to reduce the navigation steps contained by the constraints, because the eliminated This mechanism facilitates our approach towards managing navigation steps accelerate the first part of the constraint constraints using aspect-oriented techniques. Similarly to evaluation. In [9] a method is provided with algorithms to aspects, the constraints are specified and stored indepen- normalize OCL constraints in metamodel-based transformation rules. This normalization method with the results of the should be modularized. Ideally each constraint will have constraint relocation and decomposition algorithms support exactly one assigned color, which means there is no cross- the aspectification of the crosscutting constraints in model cutting. After the coloring, when we realized that there are transformations. constraints with more than one color, the extracting is applied to realize crosscutting constraints as aspects (aspect- 3. IDENTIFICATION OF ASPECT-ORIENTED oriented constraints). Extracting is supported by constraint decomposition [9]. CONSTRAINTS This section provides a method with algorithms to support 3.1 Coloring Algorithm the detection of the crosscutting constraints in metamodel- The input of the coloring algorithm is the model transfor- based model transformations. The input of the method is mation with the propagated constraints. The output is the a transformation (transformation rules and a control flow coloring, where each of the colors represent a concern. Of model), and the expected output is the crosscutting con- course the relevant concerns are also specified by the trans- straints separated as aspects. A simple but promising idea formation designer. is the following: A concern, which represents a color can be related to an op- 1. Collect the constraints appearing in the transforma- tional property that is expressed by a constraint: e.g. an at- tion. tribute value or the existence of specific type adjacent nodes. For example: 2. Identify the repetitive constraints.

3. In fact, not all of the repetitive constraints are cross- context Class inv NonAbstract: cutting constraints. Therefore, for each repetitively not self.abstract appearing constraints decide if the actual constraint is crosscutting for the transformation or not. The constraint NonAbstract represents the concern, which 4. Extract crosscutting constraints as aspects. states that the processed class should be non-abstract.

The separation of concerns principle states that a given context Table inv SourceClass: problem involves different kinds of concerns that should be self.helperNode.class->exists(c | identified and separated to cope with complexity, and to (c.name = self.name)) achieve the required engineering quality factors such as ro- bustness, adaptability, maintainability, and reusability. The principle declares that each concern of a given software de- The constraint SourceClass represents the concern, which sign problem should be mapped to one module in the system. predicates that a generated table has a source class with the Otherwise, the problem should be decomposed into modules same name. such that each module has one concern. The advantage of this is that concerns are localized and as such can be easier If we have only these two constraints, then the coloring is understood, extended, reused, and adapted. simple: the algorithm assigns to each of the constraint concerns a different color. But if a constraint comprises more Many concerns can indeed be mapped to single modules. concerns, then the coloring will be compound: Some concerns, however, cannot be localized and separated easily, and given the design language we are forced to map context Class inv NonAbstractAndProcessed: such concerns over many modules. This is called crosscut- not self.abstract and not self.isProcessed ting concern or aspect. Aspects are not the result of a bad design but have more inherent reasons. A bad design including mixed concerns over the modules could be refactored to The constraint NonAbstractAndProcessed incorporates two a neat design in which each module only addresses a sin- concerns: (i) the matched class should be non-abstract, and gle concern. However, if we deal with these crosscutting (ii) the matched class should be non-processed. In this case concerns, this is not possible in principle that is, each refac- two colors are assigned by the coloring algorithm to the con- toring attempt will fail and the crosscutting will remain. A straint. crosscutting concern is a serious problem, since it is harder to understand, reuse, extend, adapt and maintain a concern The concerns that should be taken into account by the color- because it is spread over many rule nodes. Finding the places ing algorithm are defined by meta OCL constraints. These where the crosscutting occurs is the first problem, adapting meta OCL constraints form an OCL Set. Each element of the concern appropriately is another problem. this Set represents a color (concern ID). These constraints are evaluated for the model transformation constraints. The Our crosscutting constraint identification method can be di- result is the coloring, which is refactored by the extracting vided into two main parts: coloring (Section 3.1) and ex- algorithm (Section 3.2). tracting (Section 3.2) constraints. Based on the user defined or automatically identified concerns the coloring al- Meta OCL constraints are defined as {context, constraint gorithm assigns colors to the constraints of the processed expression, color} triplets. Example simple meta OCL con- model transformation. Each color represents a concern that straints for boolean type attributes: {Class, abstract, Color 1 }{Class, isProcessed, Color 2 }. Example meta OCL con- resulted by the bad design can be solved with refactoring. straint for existing adjacent nodes {Class, self.helperNode.table- In the domain of the metamodel-based model transforma- >size() > 0, Color N }. tion, we can apply constraint relocation and decomposition in order to eliminate the annoying consequences of the bad An important requirement that the whole method should design (crosscutting constraints). provide is that each concept can have only one color, e.g. it is not allowed that abstract has two or more colors. This Algorithm 2 presents the pseudo code of the Extracting means that the elements of the meta OCL Set should be algorithm, which uses the constraint relocation and con- unique. straint decomposition provided by our constraint normalization method [9]. Algorithm 1 presents the pseudo code of the Coloring algorithm. The model transformation T and the meta OCL Set Algorithm 2 Pseudo code of the Extracting algorithm metaOCLs are passed to the algorithm, which iterates on 1: Extracting (Transformation T , ColoringTable the constraints propagated to the rule nodes of the transfor- coloringT able): AspectList mation T (line 3). In an embedded loop, for each constraint 2: AspectList aspectList = new the algorithm iterates on the meta OCL constraints (line 4), AspectList(coloringT able.Colors.Size); and evaluates the relevance of the actual meta constraint 3: Transformation decomposed = DecomposeCon- (metaConstraint) for the actual constraint (C) (line 5). If straint(T ) the constraint C contains the concern represented by the 4: for all ColoringItem coloringItem in coloringT able do actual meta constraint metaConstraint then the color of 5: for all Color color in coloringItem do the meta constraint metaConstraint is assigned to the con- 6: UpdateAspectList(aspectList, color, straint C (line 6). Finally the coloring is returned by the decomposed.GetDecomposedConstraint( algorithm. coloringItem.GetConstraintByColor(color))) 7: end for Algorithm 1 Pseudo code of the Coloring algorithm 8: end for 1: Coloring (Transformation T , OCLSet metaOCLs): 9: return aspectList ColoringTable 2: ColoringTable coloringT able = new ColoringTable(); The transformation T and the coloring coloringT able is passed 3: for all Constraint C in T do to the algorithm. The algorithm decomposes 4: for all Constraint metaConstraint in metaOCLs do Extracting the constraints of the transformation (line 3) [9]. The algo- 5: if CheckConstraintRelevance(C, rithm iterates on the coloring items provided by the coloring metaConstraint) then (line 4), and for each item iterates on the colors assigned to 6: UpdateColoringTable(coloringT able, C, the actual coloring concern (line 5). Based on the actual metaConstraint.Color) color the algorithm retrieves the relevant constraint from 7: end if the actual coloring item. Using this constraint the corre- 8: end for spondent constraint is queried from the decomposed version 9: end for of the transformation. Based on the decomposed constraint 10: return coloringT able the algorithm updates the already prepared aspect list (line 6). Finally the aspect list is returned. This is obvious that meta OCL constraints contain the understanding of the concepts, and this is provided by the 4. RELATED WORK developer. Theoretically, this method can provide a 100% An aspect-oriented approach is introduced in [5] for software solution for our problem. At this point the main question models containing constraints, where the dominant decom- is the quality of the meta OCL constraints, because meta position is based upon the functional hierarchy of a physi- OCL constraints should cover all concerns and should take cal system. This approach provides a separate module for into account everything from the point of transformations specifying constraints and their propagation. A new type of view. To obtain a useful result we should ensure the com- aspect is used to provide the weaver with the necessary infor- pleteness of the defined meta constraints. (Currently this mation to perform the propagation: the strategy aspect. A is the developers responsibility.) Otherwise, the result is strategy aspect provides a hook that the weaver may call in relevant only for the covered part of the concerns. order to process the node-specific constraint propagations.

3.2 Extracting Algorithm At the time of the writing we have no knowledge about The inputs of the constraint extracting algorithm are the that any other approach supports aspect-oriented constraint model transformation and the result of the coloring algo- management in model transformation rules, therefore, there rithm. The outputs are the constraints extracted into as- is no other method for identifying crosscutting constraints pects. in model transformations. But there are other software development fields, where identifying crosscutting concerns is If the coloring is unambiguous, each constraint has maxi- also crucial. mum one color, then aspects can be created based on the colors. Constraints without color are not extracted as as- In [4] an evaluation of clone detection techniques for identify- pects. But complex constraints may have several colors at ing crosscutting concerns is presented. [6] introduces a tool the same time. On the level of the source code, crosscutting that finds clones and displays them to the programmer. The approach is based on program dependence graphs (PDGs) [3] E. Baniassad, S. Clarke, Finding Aspects in and program slicing. In [18] a method is provided for iden- Requirements with Theme/Doc, Early Aspects 2004. tifying crosscutting concerns in requirements specifications. [4] M. Bruntink, A. van Deursen, R. van Engelen, T. [3] provides support for developers to identify aspects early Tourw, On the Use of Clone Detection for Identifying in the software lifecycle. A method is presented for aspect Crosscutting Concern Code, IEEE Trans. on Software identification and analysis in requirements documentation. Engineering, 2005, Vol. 31, No. 10, pp. 804-818. The Prism project [22] develops tools and techniques for [5] J. Gray, T. Bapty, S. Neema and J. Tuck, Handling discovering non-localized units of modularity in large soft- Crosscutting Constraints in Domain-Specific Modeling, ware systems. [12] proposes a model to identify and specify Communications of the ACM, October 2001, pp. 87-93. quality attributes that crosscut requirements including their [6] R. Komondoor, S. Horwitz, Using slicing to identify systematic integration into the functional description at an duplication in source code, 8th Int. Symposium on Static early stage of the software development process. Analysis, pp. 40-56, 2001. [7] L. Lengyel, T. Levendovszky, H. Charaf, Eliminating 5. CONCLUSIONS Crosscutting Constraints from Visual Model This paper has introduced an aspect-oriented solution for Transformation Rules, ACM/IEEE 7th Int. Workshop the problem of crosscutting constraints in metamodel-based on AOM, Montego Bay, Jamaica, October 2, 2005. model transformations. We have presented the aspect-oriented [8] L. Lengyel, T. Levendovszky, H. Charaf, Constraint constraint management of Visual Modeling and Transforma- Validation Support in Visual Model Transformation tion System. So far VMTS is the only environment that pro- Systems, Acta Cybernetica, ISSN 0324-721X, Vol. 17(2), vides aspect-oriented methods for constraint management. pp. 339-357, 2005. The main contribution of the paper is the identification of [9] L. Lengyel, Online Validation of Visual Model crosscutting constraints in model transformations. We have Transformations, PhD thesis, Budapest University of presented an approach with algorithms that semi-automatically Technology and Economics, Department of Automation identifies the crosscutting constraints and separates them and Applied Informatics, 2006. into aspects. [10] L. Lengyel, T. Levendovszky, H. Charaf, Optimizing Constraint Weaving in Model Transformation with Of course we would like to automate the largest possible Structural Constraint Specification, 8th Int. Workshop part of the meta constraint definition. Therefore, the next on AOM, March 21, 2006, Bonn, Germany. question is: which concerns can be identified automatically, and, of course, in which way. The method can be supported [11] A. Metzger, A systematic look at model by providing concern suggestions for the developer. This transformations, In Model-driven Software Development, method will not provide a 100% solution, but the suggested Vol. II of Research and Practice in Software Engineering. concerns can be refined by the developer. Our first sug- Springer, 2005. gestion (Suggestion 1 ) is to identify the constraints of the [12] A. Moreira, J. Arat’ujo, I. Brito, Crosscutting Quality transformation: simple constraints and the subterms of com- Attributes for Requirements Engineering, 14th Int. Conf. plex constraints based on the boolean separators (and, or, on Software Engineering and Knowledge Engineering, xor). The suggested constraints will be the ones, which are pp. 167-174. ACM Press, 2002. propagated at least twice to any of the rule nodes of the [13] OMG MDA Guide Version 1.0.1, 2003. Document transformation. number: omg/2003-06-01, www.omg.org/docs/omg/03-06-01.pdf A heuristic-based solution could improve the flexibility and [14] OMG OCL Spec., Version 2.0, 2006. usability of the current coloring method: suggestions, men- http://www.omg.org/ tioned above, should be defined on a higher level. A lan- [15] OMG QVT, MOF 2.0 Query/Views/Transformation guage should be provided that facilitates to define what Specification, should be checked, and the source code that performs the http://www.omg.org/cgi-bin/apps/doc?ad/05-03-02.pdf checking is generated automatically based on it. For exam- [16] OMG UML Spec., Version 2.1.1, 2007. ple: Suggestion 1 is defined as a heuristic on higher abstrac- http://www.uml.org/ tion level, and the checker that performs the control is auto- [17] G. Rozenberg (ed.), Handbook on Graph Grammars matically generated. The research related to the heuristic- and Computing by Graph Transformation: Foundations, based solution is the subject of our future work. Vol.1 World Scientific, Singapore, 1997. [18] L. Rosenhainer, Identifying Crosscutting Concerns in 6. ACKNOWLEDGMENTS Requirements Specifications, 2004. The fund of ”Mobile Innovation Centre” has supported in [19] J. Sztipanovits and G. Karsai, Model-Integrated part, the activities described in this paper. Computing, IEEE Computer, Apr. 1997, pp. 110-112. [20] J. Sztipanovits, GPCE, vol. 2487 of LNCS, pp. 32-49, 7. REFERENCES Pittsburgh, October 2002. [1] U. Assmann and A. Ludwig, Aspect Weaving by Graph [21] VMTS Website, http://www.vmts.aut.bme.hu Rewriting, Generative Component-based Software [22] C. Zhang, H.-A. Jacobsen, A Prism for Research in Engineering, Springer, 2000. Software Modularization through Aspect Mining, [2] U. Assmann, How to Uniformly specify Program Technical report, Middleware Systems Research Group, Analysis and Transformation, Int. Conference on University of Toronto, 2003. Compiler Construction (CC) 96, LNCS 1060, Springer, 1996. Towards a runtime model based on colored Petri-nets for the execution of model transformations Thomas Reiter Manuel Wimmer Horst Kargl Information Systems Group Business Informatics Group Business Informatics Group Johannes Kepler University Vienna University of Technology Vienna University of Technology Altenbergerstr. 69 Favoritenstr. 9-11 Favoritenstr. 9-11 4040 Linz, Austria 1040 Vienna, Austria 1040 Vienna, Austria +43-732-2468-9236 +43-1-58801-18829 +43-1-58801-18837 [email protected] [email protected] [email protected]

ABSTRACT based on graph transformations like AGG, or VMTS [7] allow to Existing model transformation languages, which range from specify precedence of certain rules. Declarative rules typically purely imperative to fully declarative approaches, have the consist of a semantically corresponding source and target patterns, advantage of either explicitly providing statefulness and the whereby for each match of the source pattern in the input model, a ability to define control flow, or offering a raised level of target pattern is instantiated in the output model. Additionally, abstraction through automatic rule ordering and application. Triple Graph Grammars (TGG) [5] maintain the state of a Existing approaches trying to combine the strengths of both transformation by traces that link matched source and instantiated paradigms do so on the language level, only, without considering target model elements. the benefits of integrating imperative and declarative paradigms in Imperative approaches are similar in usage to traditional the underlying execution model. Hence, this paper proposes a programming languages and allow the developer to explicitly transformation execution model based on colored Petri-nets, manipulate transformation execution state and control flow. which allows to combine the statefulness of imperative Although approaches such as the EOL [4], MTL or Kermeta [6] approaches as well the raised level of abstraction from declarative offer great flexibility and ease of use, the programming model approaches. Furthermore, we show how a Petri-net based does not support the intuitive alignment of concepts that is execution model lends itself naturally to the integration of an prevalent in metamodel or schema integration tasks, and one often aspect-oriented style of transformation definition, as needs to implement manually what a more succinct declarative transformation rules can be triggered not only upon the input description would achieve. However, what a declarative approach model, but on the state of the transformation execution itself. gains in abstraction, it loses in flexibility. Naturally, declarative specifications are convenient language constructs for recurring transformation tasks, but for “tricky” problems, a rule-based 1. INTRODUCTION paradigm can become unwieldy. As model transformations play a key role in model driven To alleviate these limitations, hybrid approaches like ATL [3] or development, several dedicated languages have emerged that Xtend [8][9] combine imperative and declarative styles of allow to define and execute transformations between source and transformation definition. (We regard Xtend as hybrid due to its target metamodels. Compared to transformations implemented in functional style and rule-like “create” extensions.) Thus, the a general purpose programming language or XSL transformations imperative part of a hybrid language is available to accomplish which operate on a models serialization, model transformation tasks that cannot be adequately solved declaratively. However, languages provide a layer of abstraction by allowing to manipulate allowing to intermix imperative and declarative statements models in terms of their abstract syntax given by its metamodel. requires a developer to be aware of how exactly the engine Apart from this basic commonality, different kinds of model orchestrates transformation execution. For instance, when writing transformation languages exist. These approaches range from imperative program parts in ATL, one has to be aware that their purely imperative styles allowing to define how an transformation execution is subject to the engine’s scheduling, and one may not is carried out, to fully declarative transformation definition styles assume that certain declarative rules have yet been dealt with, or focusing on what a transformation's output should be like, that a certain internal state is reached. Hence, the imperative part according to a certain input. is often necessary simply to work around the confines of the engine’s execution procedure, as opposed to enable algorithmic Declarative approaches (i.e. graph transformations) are typically computations. As an example, a common work-around is to based on defining rules that are later on interpreted by an explicitly maintain and observe custom state information in global execution engine to produce the desired result. Hence, the actual variables, for instance to be able to manually trigger rules at transformation execution as well as the order of rule application certain points during a transformation's execution, in case the state generally need not be handled by the user, although approaches information (i.e. trace between source and target model) that is This work has been partly funded by the Austrian Federal Ministry of automatically maintained by the execution engine does not Transport, Innovation and Technology (BMVIT) and FFG under grant suffice. FIT-IT-810806, and the Austrian Federal Ministry for Education, In general, existing declarative and hybrid approaches, are Science, and Culture, and the European Social Fund (ESF) under grant governed by an underlying execution procedure implemented in 31.963/46-VII/9/2002 the respective transformation engine. In our opinion, this net that correspond to the transformation process’ inputs and rigidness is the main cause for trouble when attempting to solve outputs, are generated from models and metamodels, whereas the tricky problems with declarative approaches, or when integrating part that corresponds to the process’ execution logic is created them with imperative styles. As the actual transformation from the integration specification by a custom generator for a definitions can be seen as merely parameterizing an intrinsically certain higher-level language. rigid, pre-defined procedure, we view declarative approaches as data-oriented , in the sense that they specify how input data is Integration mapped onto output data. This is reflected in the rationale, that Source Target Specification models are seen as graphs, and therefore graph transformations Metamodel Metamodel are used to describe and implement model transformations. As opposed to declarative approaches, imperative approaches derive conforms express transformations on a very fine-grained level, which is conforms flexible but incurs explicit handling of control flow without support for the alignment of concepts as it is prevalent in schema Source Target integration tasks, for instance. Instead of specifying what input Model Model data is mapped onto what output data, imperative approaches follow a procedure-oriented paradigm and allow to derive instantiate algorithmically define a function that computes the output model derive derive from the input model. We propose to rethink the notion of models as input and output data which is subject to a transformation that is seen either as an explicit or implicit procedure, but understand a transformation as a process . In a process-oriented view, a transformation execution Source Places Transformation Logic Target Places is carried out by interacting entities that control streams of Transformation Net information from source to target models. The flowing Figure 1. Overall transformation procedure. information stems from the models themselves, and the actual transformation logic is made up by the behavior of individual The gap between the modeling and the transformation net entities and their interaction which each other. technical space is bridged by the mapping described in the Consequently, we propose the transformation net formalism, following. For reasons of brevity, we give a mapping only for the which is based on conditional, colored Petri-nets, to represent three main elements of metamodels, that are classes, references transformation processes. Such an execution model provides the and attributes, and leave other constructs (e.g.: enumerations) explicit statefulness of imperative approaches through markings aside. contained in the net's places. The abstraction of control flow from declarative approaches is achieved as transitions can fire autonomously depending on their environment. To describe Classes, references and attributes of metamodels are mapped to specific firing rules for transitions, we resort to pre/post rules places of a transformation net. known from graph transformations. The following section gives an overview of the transformation net Objects , as instances of classes are mapped to one-colored tokens formalism and describes how models and metamodels can be within a place that corresponds to the object’s class. The token’s mapped onto transformation nets. The example in section three color represents an object’s unique ID. will describe how higher-level languages can be built on-top of Links between objects conforming to a certain reference are transformation nets and how a process-oriented view favors the mapped onto two-colored tokens within a place that corresponds incorporation of aspect-oriented rules. Section four concludes to the link’s reference. The two colors represent a link’s source with an outlook on future work. (ring color) and target (center color) and stand for the ID of the linked objects. 2. TRANSFORMATION NETS Values of attributes are mapped onto two-colored tokens within a What sets transformation nets apart form existing approaches is place that corresponds to the values’ attribute. The two colors their ability of making the transformation process explicit, as represent an object’s unique ID and the denoted value. opposed to assuming a certain predefined execution rigor. Of course, the Petri-net based formalism needs an execution engine, too. But the Petri-net execution engine is generic and not tailored To complete the transformation net and to provide the actual to a specific task unlike declarative model transformation engines. process logic, a system of transitions and places has to be This makes the transformation net formalism a flexible execution established that is capable of streaming tokens from the places environment to be targeted by generators of higher-level corresponding to the input metamodels to places corresponding to transformation languages, such that specific transformation and the output metamodel. Thereby, the transitions represent integration operators can be defined using the semantics offered interacting entities that control the token streams by firing and by transformation nets. removing tokens from their input places and adding tokens to As symbolically displayed in Figure 1, the “compilation” step their output places accordingly. During execution, state produces a transformation net in its initial state (i.e. ready for information is explicitly provided by the markings of places, execution) that uniformly represents models, metamodels and which makes it possible, to trigger transitions according to a transformation specifications. The static parts of a transformation certain runtime state, as opposed to only act upon data comprising the input model. The notion of triggering transitions according to aspect Annotation runtime events or states is similar to the notion of point-cuts determining the execution of advice in aspect-oriented Annotation programming. Hence, transformation nets naturally cater for the text : String use of aspect-oriented techniques on the runtime level. How to annot ref att class incorporate a weaving mechanism on the language level will be out Annotation discussed as part of next section’s example which introduces a %allC2C Att2Annot text : String high-level integration language and demonstrates transformation in.id history objects values annot net generation and execution. history annot 3. EXAMPLE in out Array C2C Array2List LinkedList The example in this chapter deals with the specification of a transformation between two metamodels, which is compiled into a id : String in out contains R2R contains2head head net that finally executes the transformation process. Figure 2 1 shows the source and target metamodels, as well as the input * in out Element C2C Node model and the desired output model. As shown, a transformation Elem2Node between these two metamodels has to transform array input id : String history * * models into linked-list output models. 2-Buf next prev one two The transformation specification in-between the metamodels is in out to from Inverter given in an example language, which comprises several operators Linker whose exact transformation net semantics will be given in the out following section when describing the runtime level. On the Example Source Model Desired Target Model language level, every operator stands for a certain processing A2:Annot. A4:Annot. Arr:Array L1:LinkedList entity, which has inputs and outputs by which individual text = „E2“ text = „E4“ id = „Arr “ operators can be assembled in a component-based way. For contains A1:Annot. A3:Annot. instance, the C2C (Class2Class) component takes objects from the E1:Element E3:Element text = „E1“ text = „E3“ id = „E1“ id = „E3“ “Element” class as input, and outputs them into the “Node” class. head annot next N1:Node N3:Node Analogously the R2R (Reference2Reference) component streams E2:Element E4:Element links from “contains” to “head”. The C2C component offers id = „E2“ id = „E4“ N2:Node N4:Node prev another output port “history”, of which all this components yet handled tokens can be accessed. The 2-Buf component connected Figure 2. Integration specification between metamodels to C2C’s “history” sequentially fills an internal buffer of size two, with example models. which is again provided as output port. A Linker component takes the two objects in the buffer, and produces a link between them After the weaving process is carried out on the language level, which is streamed into the “next” place. A back-link is produced generation takes place to produce a transformation net out of an by the Inverter component that produces back-links from the integration specification. Thereby Petri-net patterns are “next” place and streams them into the “prev” place. instantiated according to the transformation net semantics of the Additionally to these “manually” assembled components, certain operators and assembled according to the overall integration operators can cross-cut a transformation specification: Because specification. Every such pattern declares input and output arcs the target metamodel classes do not have ID attributes, these which represent the component ports of the respective language should be stored within an annotation for eventual round-tripping. operators. The top of Figure 3 shows a transformation net This can be accomplished by the Att2Annot component, which resulting from the above integration specification. The transitions’ henceforth crosscuts the transformation of every object and is firing rules are defined with a visual notation that uses pattern- therefore woven with every C2C component. The transformation filled tokens that can match for certain input tokens and produce specification is itself a model, and due to the component-like output tokens whose color is either different, the same, or a assembly, existing model weavers can be used to merge the aspect combination (two-colored tokens) of the matched input colors. operator into the base transformation specification. The top of Places marked as “ordered” index contained tokens and provide Figure 2 shows the aspect’s definition in a notation inspired from them in a sorted fashion. For instance, the R2R component’s XWeave [2]. The query in the aspect selects all C2Cs, with three transition matches “ArrE1” – the “first” input token. Furthermore, additional sub-queries “in.id”, “history” and “out”, relative to the according to the multiplicity of a reference, a place (e.g. “head”) current C2C operator. The results of “in.id” and “history” are can have a capacity, which constrains the amount of tokens a bound to the “values” and “objects” ports of the Att2Annot place can hold. Places holding two-colored tokens (references and operator, which for every transformed object instantiates a new attributes) have a double-lined border for easier differentiation. Annotation object (“class” port) which is linked up (“ref” port) For simplicity reasons, the example assumes only a single array with the according Node object and sets its text attribute (“att” object, and since there is only a single ordered reference, the port) to the value of the source objects “id” attribute. Element place is compiled into an ordered place as well, as not to Additionally, the “Annotation” class is woven into the target unnecessarily complicate the example. metamodel, as indicated through the dotted lines in Figure 2. Thereby, the result of the “out” query determines the classes to which an “annot” reference will be added. Initial state… val.

obj. Array MM Array att LinkedList MM id C2C history Arr class String Arr in ref annot Annotation String ‚Arr‘ ‚E1‘ Att2Ann LinkedList ‚E2‘ out ‚E3‘ ‚Arr‘ Arr ordered Arr Arr Arr E1 E2 head ‚E4‘ E3 E4 R2R contains out 1 E1 in text ‚E1‘ id E2 ordered Node E3 ‚E2‘ ‚E3‘ E1 E2 annot E4 Linker out ‚E4‘ E3 E4 Element next prev to in out from in out ref hist. one two class hist. 2-Buffer 1 1 Inverter obj. att

C2C val.

Att2Ann

…running… val.

obj. Array MM Array att LinkedList MM C2C history id class String Arr ref annot Annotation String ‚Arr‘ in Arr A1 ‚E1‘ Att2Ann LinkedList ‚E1‘ Arr A1 ‚E2‘ ‚E1‘ ‚E3‘ ‚A‘ Arr ordered Arr E1 Arr Arr E2 head ‚E4‘ E3 E4 R2R E1 A1 contains out 1 in text id E2 ordered ‚E2‘ Node E1 E3 annot E4 ‚E3‘ E4 Linker out E3 E2 ‚E4‘ E1 Element E2 next prev to in out from in out ref hist. one two E2 E3 class hist. 2-Buffer 1 1 Inverter att E2 obj. E3 C2C val.

Att2Ann

…final state val.

obj. Array MM Array att LinkedList MM C2C history id class String A1 ref annot Annotation String in ‚E1‘ LinkedList A2 ‚E1‘ Att2Ann Arr ‚Arr‘ A1 ‚E2‘ Arr A5 A2 ‚E2‘ ordered A3 ‚E1‘ ‚E2‘ ‚E3‘ ‚A‘ Arr A3 A4 Arr Arr ‚E3‘ E2 head A5 ‚E4‘ E3 E4 R2R Arr E1 A4 ‚E3‘ ‚E4‘ E1 A1 ‚E4‘ out 1 E2 contains in A2 A5 E3 ‚Arr‘ id E1 A3 ordered Node E4 E2 annot A4 text E3 Linker out E2 E3 E3 E4 E2 E1 E3 E2 E4 Element E2 E4 next prev E1 E3 to in out from in out ref hist. one two class hist. 2-Buffer 1 1 Inverter obj. att

C2C val.

Att2Ann

Figure 3. Transformation net execution.

The middle and the bottom of Figure 3 show the transformation metamodels, models and execution logic altogether. Therefore, we net during execution and in its finished configuration. For deem a Petri-net based execution model beneficial for debugging instance, one can see how the tokens streamed through the C2C purposes and visualization of a transformation’s state. component are stored in its “history” place. (The history place is Consequently, besides developing generators for further duplicated in the lower C2C, as both the Att2Annot and the 2-Buf integration languages (e.g.: model merging) or existing model components are bound to it.) The 2-Buf component takes in these transformation languages, our next steps will focus on developing tokens and fills its two-place buffer. Once the buffer is full (both dedicated tool support in the form of editors and debuggers for the places have a capacity of just one token), the Linker component’s transformation net formalism. transition can fire and empty the buffer, producing a two-colored token which is streamed into the “next” place. Thereby it is to note, that the creation of two-colored tokens for the “next” link is 5. REFERENCES based on a certain state of the execution, rather than on the input [1] ExSpecT – Executable Specification Tool. model alone. http://www.exspect.com Furthermore, one can see how the previously weaved operators [2] I. Groher and M. Völter. XWeave: models and aspects in form Petri-net patterns that become active after an Array or concert. Proceedings of the 10th international workshop on Element token was streamed. As an example, in the “running” net, Aspect-oriented modeling, (AOSD 2007) ,Canada, the lower Att2Annot pattern has already created an annotation Vancouver: 35-40. with the according value for the “E1” object, and is currently [3] F. Jouault and I. Kurtev. Transforming Models with ATL. In enabled to do the same for “E2” and ”E3”, as both have already Proceedings of the Model Transformations in Practice been handled by a C2C component. Analogously, the rest of the Workshop at MoDELS 2005 , Montego Bay, Jamaica. 2005. patterns stream tokens from source to target places, possibly [4] D. S. Kolovos, R. F. Paige, and F. A.C. Polack. The Epsilon depending on other patterns in turn. The actual firing order, Object Language (EOL). In Proc. of European Conference in however, is handled by the underlying Petri-net engine. Once the Model Driven Architecture (EC-MDA) Bilbao, Spain:128- transformation process has finished, the final net configuration is 142, 2006. used to instantiate a model that conforms to the target metamodel, as shown in the bottom-right corner of Figure 2. [5] A. Königs. Model Transformation with Triple Graph Grammars. Model Transformations in Practice , Satellite 4. CONCLUSION AND FUTURE WORK Workshop of MODELS 2005, Montego Bay, Jamaica, 2005. In this paper we have presented a new execution model for model [6] P. –A. Muller, F. Fleurey, D. Vojtisek, Z. Drey, D. Pollet, F. transformations based on colored Petri-nets. Such a process- Fondement, P. Studer, and J.-M. Jézéquel. On executable oriented execution model embodies the strengths of imperative meta-languages applied to model transformations. In Model and declarative paradigms and is able to explicitly represent a Transformations In Practice Workshop , Montego Bay, transformation’s execution state, which furthermore allows for the Jamaica, October 2005. natural integration of aspect-oriented transformation rules. [7] G. Taentzer, K. Ehrig, E. Guerra, J. de Lara, L. Lengyel, Furthermore, although transformation nets are intended as a low- T. Levendovsky, U. Prange, D. Varro, and S. Varro-Gyapay. level execution model, transformation tasks like establishing the Model Transformation by Graph Transformation: A correct links in the above linked-list example can be expressed Comparative Study. In Proc. Workshop Model elegantly and encapsulated in reusable components. Transformation in Practice , Montego Bay, Jamaica, October 2005. Currently we have developed the TROPIC prototype [8] M. Völter, B. Kolb, . Efftinge and A. Haase. Introduction to (TRansformations on Petri-nets In Color) which can transform openArchitectureare 4.1.x. MDD Tool Implementers Forum , integration specifications established with the CARMEN mapping TOOLS Europe, 2007. framework [10] into colored Petri-nets that can be executed using the ExSpecT [1] tool. After execution, the resulting Petri-net is [9] M. Völter, B. Kolb, . Efftinge and A. Haase. From Front transformed into the actual target model. The CARMEN End To Code - MDSD in Practice. Eclipse Corner Article, framework builds upon an integration language that provides June 2006. http://www.eclipse.org/articles/Article- operators for bridging schematic heterogeneities between FromFrontendToCode-MDSDInPractice/article.html metamodels and ontologies. Future work will deal with extending [10] M. Wimmer, H. Kargl, M. Seidl, M. Strommer and T. Reiter. the existing set of integration operators and generators. Due to the Integrating Ontologies with CAR-Mappings. First fact, that the transformation net approach is very generic, we will International Workshop on Semantic Technology Adoption furthermore investigate in how well the approach is applicable to in Business (STAB'07), Vienna, Austria, May 2007. other model management tasks, such as model merging or incremental transformations. Another advantage of a process-oriented view is that a transformation net represents a single artifact which embodies

Towards a Generic Aspect-Oriented Modeling Framework

Brice Morin Rodrigo Ramos Olivier Barais Centre of Informatics Jean-Marc Jézéquel Federal University of IRISA Rennes Projet Triskell Pernambuco Campus de Beaulieu P.O. Box 7851, CEP

F-35 042 Rennes Cedex 50732970, Recife, Brazil

ßÑÓÖÒÖ× Þ ÕÙ ÐÖ×º Ö ÖØÖÒºÙÔ ºÖ

ABSTRACT

ÔÓÒØÙØ

ÓÒ ÔÓÒØ×

2. A MOTIVATING EXAMPLE

1. INTRODUCTION

ÓÒ ÔÓÒØ×

ÓÒ

ÔÓÒØ×

ÔÓÒØÙØ

ÓÒ ÔÓÒØ×

ÔÓÒØÙØ

ÙÖ ½ ÌÛÓ ÑÓ Ð× ÖÓÑ ØÛÓ «ÖÒØ ÓÑÒ×

ÔÓÒØÙØ

ÓÒ ÔÓÒØ×

ÓÒ

ÔÓÒØ×

ÙÖ ¾ ÂÓÒ ÈÓÒØ× ×ÐØÓÒ Ò ÓØ ÑÓ Ð×

ÙÖ ÍÅÄÌ ÑÔÐØ× Ó Ð×× Ò ËØØ "¹

ÖÑ

ÙÖ ¿ ÓÑÔ Ó×ØÓÒ Ó Ø ×Ô Ø Ò ÓØ ÑÓ Ð×

3. TEMPLATE MECHANISM

ÑÓ Ð ×ÒÔÔ Ø×

ÔÓÒØÙØ

ÓÒ ÔÓÒØ×

ÑÓ Ð ×ÒÔÔ Ø×

3.2 Pattern-framework metamodel

Æ Ñ Ð ÑÒØ

Ì Ö Ð ××

¼ ¼

ÒÑ Ì Ö

ØÖ ÒØÖ Ý Ç ÔÖ ØÓÖ ÒÑ

¼ ¼

3.1 Model snippet ØÖ ÒØÖ Ý

Ì Ö

ØÖ ÒØÖ Ý ØÖ Ü Ø

Ì Ö

×ÒÔÔ Ø

ÑÓ Ð ×ÒÔÔ Ø×

ÒØ Ò ÑÓ Ð

ÑÓÐ ×ÒÔÔØ

ÅÅ

ÒØ Ò

ÑÓ Ð

Ì Ö Ð ××

Ì Ö Ð ×× ÅÅ

¼ ¼

ÌÖ ÌÖ ÒØ Ò ÑÓ Ð

ÒÑ ÅÅ ÅÅ

ÒÑ

¯ ÅÅ

×ÒÔÔ Ø

ÅÅ

¼ ¼

ÅÅ ÅÅ

ÅÅ

ÒØ Ò ÑÓ Ð

ÅÅ

ÅÅ ÅÅ

È ØØÖ Ò

È ØØÖ ÒË ØÖ ÙØÙÖ

È Å ÓÐ

ÅÅ

Ð ÑÒØ×

ÒØ Ò ÑÓ Ð È ØØÖ ÒË ØÖ ÙØÙÖ

ÊÓÐ

ÅÅ ÅÅ

ÅÅ Ê ÓÒ

ÒÚÖÒØ×

Á Ò Ø Ð Ë ØØ ËØØ Ø Ú ØÝ

Î Ö ØÜ

ÈØØ ÖÒ ÖÑ ÛÓÖ

ÈÅÓÐ ÓØ ×ÔÓØ×

ÅÅ

È Ç Ø

ÒØ Ò ÑÓ Ð×

È ØØÖ Ò Ö ÑÛ ÓÖ "

ÅÅ

È Ç Ø

ÅÅ ÅÅ

×ÒÔÔ Ø ÈÌ

×ÒÔÔØ

ÔØØ ÖÒ ÖÑ ÛÓÖ

ÙÖ $ ÑØÑÓ Ð Ó Ø ÔØØÖÒ ÖÑÛÓÖ%

3.3 Constructing model-snippets

ÅÅ ÒØ Ò

ÑÓ Ð

ÑÓ Ð¹×ÒÔÔ Ø×

Ú ÒØ

Ì Ö Ò× Ø ÓÒ Î Ö ØÜ

ÙÖ & ÈÖÓ ×× ÓÖ ÖÚÒ ÑØÑÓ Ð ÓÖ ÔØ¹

ØÖÒ ×ÒÔÔØ×º

Ë ØØ È ×ÙÓË ØØ

ÅÅ

4. ADAPTATION METAMODEL

4.1 Generic Adaptation Metamodel

ÙÖ ) ÈÖÓ ×× ÓÖ Ù×ØÓÑ×Ò Ø ÔØØÖÒ ÖÑ¹

ÛÓÖ%º

ÔØ Ö ÔØ Ö ×Ô Ø ÔØ¹

ØÓÒ× ×Ô Ø ÈØØ ÖÒÅÓ Ð Ø ÑÔÐØ

È Ç Ø

ÈÅÓ Ð

ÅÅ

×ØÖÙØÙÖ ÔØØÓÒ¹

È Ç Ø

× ÈÇ Ø× ÔÖÑ Ø Ö×

3.4 Template Matching

ÙÖ * + ÔØØÓÒ ÅØÑÓ Ð

Ø Ñ¹

ÔÐØ ÔØØÓÒ×

ÙÒÕÙ

4.2 Specializing the Adaptation Metamodel

ÔØØÓÒ

Ü ÙØ

ÔÖÑ Ø Ö×

ÁÒØÖÓ Ù ÌÖÒ×ØÓÒ ÔØ¹

ØÓÒ

ÌÖÒ×ØÓÒ ËØØ ËØØ

ÓÒØÒ Ö

ÓÒØÒÑ ÒØ ÓÑ¹

ÔÓ×

ÙÖ ½½ .ÒÖØ ÓÒÖØ ÔØØÓÒ

ÙÖ , ÓÒØÒÖ ÔØØÖÒ

ÙÖ ½¾ "×ÒÒ Ø ×Ô Ø ÓÖ ËÅ

ÙÒÕÙ

ÙÖ ½¼ ÌÑÔÐØ ÔØØÓÒ

ËÅ ËØØ ÌÖÒ¹

ÙÖ ½¿ ÏÚÒ Ø ×Ô Ø ÒØÓ Ø × ÑÓ Ð

×ØÓÒ

5. APPLICATION

¾¿Ö ÁÒØ ÖÒØÓÒÐ ÓÒ Ö Ò ÓÒ ËÓØÛÖ

!Ò&Ò ÖÒ&¸ Á Ë!³¼½

ÇË,³¼(% ÈÖÓ Ò&× Ó Ø -Ø

ÁÒØ ÖÒØÓÒÐ ÓÒ Ö Ò ÓÒ×Ô Ø¹ÇÖ ÒØ ËÓØÛÖ

, Ú ÐÓÔÑ ÒØ¸ ÁÒ Ù×ØÖÝ ÌÖ

ÙÖ ½ "×ÒÒ Ø ×Ô Ø ÓÖ Ð×× ÅÓ Ð

/Ø ÁÒØ ÖÒØÓÒÐ ÏÓÖ×ÓÔ

ÓÒ ×Ô Ø¹ÇÖ ÒØ ÅÓ ÐÒ&¸´ÇÅ ¾¼¼-µ ÅÓ Ð×

ÇË,³¼(%

ÈÖÓ Ò&× Ó Ø -Ø ÁÒØ ÖÒØÓÒÐ ÓÒ Ö Ò ÓÒ

×Ô Ø¹ÇÖ ÒØ ËÓØÛÖ , Ú ÐÓÔÑ ÒØ

ÙÖ ½$ ÏÚÒ Ø ×Ô Ø ÒØÓ Ø × ÑÓ Ð

6. CONCLUSION

ÅÓ,!ÄË ³¼/% ÅÓ Ð ,ÖÚ Ò

!Ò&Ò ÖÒ& ÄÒ&Ù& × Ò ËÝ×Ø Ñ×¸ ½¼Ø

ÁÒØ ÖÒØÓÒÐ ÓÒ Ö Ò ¸ ÅÓ,!ÄË ¾¼¼/¸ Æ×ÚÐ Ð ¸

Ì ÒÒ ×× ¸ Ë ÔØ Ñ Ö ¿¼ ¹ ÇØÓ Ö -¸ ¾¼¼/

ÂÓÙÖÒÐ Ç Ç Ø Ì ÒÓÐÓ&Ý ´ÂÇÌµ

Á ËÊ Ä ØÙÖ ÆÓØ × Ò ÓÑÔÙØ Ö

Ë Ò

ÈÖÓ Ò&× Ó ÅÇ,!ÄË»ÍÅÄ³¾¼¼-

ÅÓ,!ÄË

Ä ØÙÖ ÆÓØ × Ò ÓÑÔÙØ Ö Ë Ò

ÅÓ,!ÄË ³¼/% ÅÓ Ð ,ÖÚ Ò

!Ò&Ò ÖÒ& ÄÒ&Ù& × Ò ËÝ×Ø Ñ×¸ ½¼Ø

ÁÒØ ÖÒØÓÒÐ ÓÒ Ö Ò ¸ ÅÓ,!ÄË ¾¼¼/¸ Æ×ÚÐ Ð ¸

Ì ÒÒ ×× ¸ Ë ÔØ Ñ Ö ¿¼ ¹ ÇØÓ Ö -¸ ¾¼¼/

ÁÒØ ÖÒØÓÒÐ ÓÒ Ö Ò

7. REFERENCES

!Ò&Ò ÖÒ& Ó ÓÑÔÙØ Ö¹9× ËÝ×Ø Ñ×

ËÓØÛÖ Ò ËÝ×Ø Ñ ÅÓ ÐÒ&% ËÓËÝÅ

Á Ë! ³¼$%

ÈÖÓ Ò&× Ó Ø ¾(Ø ÁÒØ ÖÒØÓÒÐ ÓÒ Ö Ò ÓÒ

¾Ò ÁÒØº ÏÓÖ×ÓÔ ÓÒ ÔÔÐØÓÒ× Ó ;ÖÔ

ËÓØÛÖ !Ò&Ò ÖÒ&

Ò×ÓÖÑØÓÒ ÄÆ Ë ÌÖ