Code Generation in VUML Profile: A Model Driven Approach

Mahmoud Nassar1, Adil Anwar2,3, Sophie Ebersold2, Bouchra Elasri1, Bernard Coulette2 and Abdelaziz Kriouile1 1SI2M, ENSIAS, BP 713 Agdal, Rabat, Morocco

{nassar, elasri, kriouile}@ensias.ma

2 IRIT-MACAO University of Toulouse, Toulouse, France {anwar, ebersold, coulette}@ univ-tlse2.fr

3 LRIMIARF, Mohammed V-Agdal University Rabat, Morocco

Abstract— VUML is a view-based analysis/design method offering a formalism (UML profile) and a process to model software systems through objects and views. The main extension to UML is the multiview class whose goal is to store and deliver information according to the user's viewpoint. VUML supports the dynamic change of viewpoints and offers mechanisms to describe view dependencies. On the semantics side, the VUML meta-model extends the UML one with OCL rules. VUML proposes also a generic implementation pattern to generate the object code corresponding to a VUML class diagram. The proposed pattern uses delegation, handle technique and polymorphism to implement views. In this paper, we present a model driven implementation of this pattern, which integrates the multi-user aspect and supports Java language. We propose a code generation technique that respects the pattern and uses the MDA approach. We specify transformations as a collection of rules implemented in ATL. The proposal is illustrated by a simple example.

I. INTRODUCTION Complexity management and software evolution control

are important challenges in the software engineering field. Several approaches rely on the principle of system decomposition into a set of software units which are less complex to analyze and design. Many researches in software development applied this principle through several terms such as subject-oriented development [7][16][30], aspect-oriented development [5][14][21][33] or object languages [22][23].

At the modeling level, concepts of views/viewpoints [13] are considered as key elements of approaches based on the separation of concerns. Views in UML [29] allow to structure the design activity into separate views: uses cases, logic, component, deployment. However, it is not possible in UML to integrate the concept of view in the heart of artifact modeling, that is in the class diagram itself. For that reason, we decided to develop an extension of UML, called VUML (View based Unified Modeling Language) [24], which is based on the concept of “multiView class”. VUML offers a formalism and a process to carry out a view-based modeling approach from analysis to code generation, targeting main object-oriented languages.

On the methodological level, the VUML process makes possible to model a software system according to each designer’s profile (viewpoint). First, modeling of the needs is done through a use cases diagram. Then, for each identified

actor, therefore for each viewpoint, scenarios are specified as well as the associated class diagrams (called also partial models) in UML. Finally, a global VUML model is produced using an MDE approach by composing the partial models. The composition technique used is a merging of models based on a set of transformation rules [2][3]. More precisely, we define and automate the composition of static UML models through transformation rules refined as correspondence, composition and translation rules. These rules allow first to establish correspondences between input models, then to merge these models so as to produce the global VUML model.

In this paper, we focus our attention on the code generation phase that takes place after the production of a VUML class diagram. This phase was introduced in [25] through a generic pattern. We describe here the implementation of this pattern within the Model-Driven Engineering (MDE) approach, based on the MDA OMG’s initiative [32]. MDE is well adapted to a generic code generation since it allows to reason at different abstraction levels: at the Platform Independent level to produce a code independent from the target language, and then at a Platform Specific level to generate a specific code.

Our VUML code generation process applies the pattern mentioned above to transform a VUML PIM (Platform Independent Model) into an object-oriented PSM (Platform Specific Model). The generated PSM model can then be used to generate code into popular oriented object languages (Java, C++, Eiffel) either by transformation process, or by programming approach.

This paper is organized as follows. In the next section, we present an overview of the VUML profile. Section 3 describes the translation of a multiView Class into object code by using the generic pattern. Section 4 is devoted to the implementation of the code generation with transformation rules expressed in ATL (Atlas Transformation Language) [19]. Section 5 describes main related works. Section 6 concludes this paper and gives outlines of future works.

II. VUML PROFILE The VUML profile was developed to meet the needs of

complex information system modeling with UML according to various viewpoints. A viewpoint on the system represents an actor’s requirements and rights. Such viewpoints may be considered as functional user-centered aspects. A view is the result of the application of a viewpoint to an entity (class), and

978-1-4244-3806-8/09/$25.00 © 2009 IEEE 412

by generalization to the entire system. The main concept of VUML language is the multiview class, which is composed of a base class (shared by all viewpoints), and a set of view classes (extensions of the base class), each view class being specific of a given viewpoint. Such a multiview class allows a fine-grained management of access rights and separation of concerns at the class level. VUML’s semantics is described by a meta-model, including constraint rules expressed in OCL [28]. On the methodological level, a process allows to analyze and design software systems with respect to viewpoints. In the following of this section, we present the VUML analysis/design process, a case study, and the VUML meta-model.

A. VUML analysis/design process The VUML analysis/design process is led by a set of

designers who have specific viewpoints. The process is decomposed into five phases (Figure 1):

1. Analyze actor’s requirements: During this phase, actors (in the UML sense) are identified and their requirements are described in terms of use cases. Each actor is associated with a unique viewpoint.

2. Define a common domain glossary: This phase is a general analysis aiming at defining the basic concepts which represent the business domain of the application. At the end, a common glossary of the system is available and shared by all the designers.

3. Design viewpoint models: This phase aims to produce a set of design models according to specific viewpoints. Each viewpoint model (partial model) may be designed in parallel with the others.

4. Analyze conflicts: During this phase, representation conflicts, such as naming and structural conflicts, are detected and resolved. While naming conflicts are solved through renaming into the design models, structural conflicts are solved by applying heuristics allowing a semi-automatic resolution.

5. Compose viewpoint models: The last phase is a composition operation that consists in merging design models developed separately in order to obtain a global VUML design model. In the following sections of this paper, we will focus on this phase.

Figure 1. VUML Analysis and Design Process

B. Case Study To illustrate our approach, we chose the modeling of a

Shared Medical Files Management System (SMFMS) [3]. The medical file of a patient is an important tool of communication, coordination and information among care actors and patients. It makes it possible to follow the hospital course of the patient, it reflects the health evolution of the patient through the intervention of professionals of health and it ensures the traceability of the actions carried out. For this reason, the identification of the principal actors of the system and their activities plays a paramount part of modeling in a viewpoint oriented approach.

Figure 2 below presents a part of the use-case diagram of the SMFMS. In order to reduce the size of models we limited our study to the following actors and activities:

• The patients, go to consultations, pass examinations and tests in analysis laboratories, and follow treatments prescribed. They can consult their file and modify some personal information, etc.

• The doctors carry out diagnoses and examinations, write consultation reports, prescribe medicines, consult previous reports, etc.

• The nurses assist the doctors, give particular treatments, write reports on the patient states, etc.

Figure 2. Excerpt from the use case diagram for the SMFMS

Due to space constraints, we cannot describe here the entire analysis/design process applied to the SMFMS case study. Hence we go directly to the result of the fifth phase that is the result of composition of separate viewpoint models. Figure 3 below shows a VUML model which represents a simplified version of the global design model of SMFMS.

413

Figure 3. Excerpt from the VUML model of SMFMS

C. VUML meta-model The concepts of profile and meta-model are very close and

a combination of those concepts can be beneficial for a project [31]. For this reason, we defined a MOF meta-model to describe how the concepts fit our profile in the UML meta-model. This meta-model extends the UML one with new modeling elements: MultiViewsClass, AbstractView, Base, View, ViewExtension and ViewDependency. The defined meta-model shows that a multiview class consists of a base class and a set of views (cf. Figure 4). These views are connected to the base via a special dependency relationship (extension) and can also be linked to other views by traditional dependency relationships (to manage coherence). Each view is associated with a single actor. Table 1 describes, for each stereotype: the name, the modeling element involved and an informal description of its semantic. OCL constraints have been specified to describe the static semantics of VUML, but such description is not in the scope of this paper. The VUML profile has been implemented first under Objecteering [35], then in the Eclipse platform [3].

Figure 4. Excerpt from the VUML meta-model

TABLE I. VUML’S STEREOTYPES

III. A GENERIC PATTERN FOR CODE GENERATION To cover the whole development process, we decided to

provide an automated translation of a VUML model into object-oriented code (Eiffel, Java, C++, etc.). More precisely, we defined a generic pattern to transform a multiview class into a multi-target object code. The reader will be able to find a detailed description of the technique employed in [25]. Unlike the existing generators of object code from UML diagrams, our pattern for code generation produces classes with complete functions implementing the views management. This pattern does not depend on any particular target language. It has been tested with Java to build a prototype of a remote educational system. However, the first version of this pattern (see [25]) did not support certain mechanisms of VUML, particularly propagation of the active view and multi-user management (competiting accesses). In this section we

414

propose an improved version of this pattern that overcomes these limits.

In the continuation of this section, examples are given in Java, but the technique applied is valid for all object-oriented languages supporting the polymorphism feature.

The class diagram of the VUML implementation pattern is shown in Figure 5 below. It combines the Role pattern and the handle technique to implement the delegation, and the Strategy pattern with methods overriding for implementing views [8][15].

Figure 5. VUML implementation pattern

We give below only key elements allowing to understand this pattern, by leaving aside the implementation details. A detailed description of the technique used can be found in [9].

A multiview class CMV is translated into a set of classes as follows: a class of the same name CMV is connected by a composition relationship to a class Base_CMV (gathering the attributes and the methods of the base), a class View_CMV, and a list of classes corresponding to views. The views are described by subclasses of View_CMV class.

The class CMV provides two private methods: setCurrentView() allowing to activate/disable a view and getCurrentView() which returns over the active view. The active view is either an instance of View_CMV (a default view when no view is active), or an instance of the class describing a view (e.g. Viewk_CMV).

Methods called by client objects are applied to the instance of the class CMV that contains all the methods defined in the views. Their behavior is restricted to redirecting the call towards the current view which is obtained through the method getCurrentView().

// definition of a method m () in the CMV class

T m(U,args) { setCurrentView(U.getView()); getCurrentView.m(args); }; The selection of the method to be carried out is based on

the polymorphism of View_CMV. The definition of the method m() in the View_CMV class depends on the membership of m() to the base. If m() belongs to the base, the corresponding method in the base is called:

// case where m() belongs to the base class

T m(U,args) { getCMV.getBase.m(args) ; };

If m() does not belong to the class base, the AccessForbidenException() exception is raised:

// case where m() does not belong to the base

T m(U,args){ throw new AccessForbidenException(); }

The Viewk_CMV class is obtained by duplicating the corresponding view Viewk of the VUML model. Thus, if a method m() appears in Viewk, it is defined in the class Viewk_CMV which redefines the method m() of the parent class View_CMV.

The major difference with the first version of the pattern is the fact that for each method m of the multiview class we add a parameter (the first one) which has User as type (User is a system class which has an attribute (view) of type String to store the active view, an accessor (getView) and a settor (setView) to reach this attribute). This parameter makes it possible to refer to the active view during the run-time of a method. This way of proceeding allows the multi-use and the active view propagation.

IV. CODE GENERATION IN VUML : A MODEL DRIVEN APPROACH

The use of model driven engineering techniques to implement an automatic code generation approach has several advantages: on the one hand, it increases the productivity of models by automating transformation operations between the design model and implementation model; on the other hand, it is well adapted to a pattern-based generic code generation approach by allowing to reason at a Platform Independent level (see MDA Guide’s recommendations [32]).

In this section we describe how a MDA process can be used to implement a pattern-based multi-target code generation. The process acts in two transformation steps. During the first step, a VUML design model (PIM in MDA approach) independent from any target platform, is transformed into a model representing the object-oriented platform (PSM in MDA approach). The second step aims to generate the object text code from the PSM model. Figure 6 shows this MDA process with Java as target language. In the following of this section, we present the source and target meta-models, the transformation rules and their implementation in ATL (ATLAS Transformation Language).

CMV

-getBase() :Base_CMV ; -getCurrentView() :View_CMV ; -setCurrentView(String) ; +m(U:User, args) : T;

View_CMV

getCMV():CMV ; m(args) : T;

Base_CMV Base Attributes

Base Methods

-viewsList

-currentView

ViewN_CMV ViewN Attributes

ViewN Methods

Viewk_CMV Viewk Attributes

Viewk Methods

View1_CMV View1 Attributes

View1 Methods

415

Figure 6. Code generation process in VUML approach

A. Specification of PIM and PSM models In the MDE field, models are considered as first class

entities [6]. A model should be defined according to the semantics provided by its meta-model: we say that a model is conform (consistent) with its meta-model. Another approach to use meta-modeling in UML is to define a profile. Indeed, the UML profile mechanism can be used to develop PIMs as we did with VUML profile for viewpoint oriented modeling, or to develop PSMs, such as UML profiles for EJB, CORBA, etc. In our case, the source model is conform to the VUML profile whose main stereotypes are shown in table 1 (Section II).

The target model (Java for instance) must also be conform to a meta-model. Figure 7 shows a simplified version of the Java meta-model proposed in [4]. It consists in a number of named elements. Packages make a total encapsulation for classes. The association relationship whose end is named 'constructor' can be used to specify Java methods declared as constructors. A method returns a type and may have a list of parameters of the type specified by the JavaType class. The body of a method is described by the metaclass 'Body' whose expression attribute describes the behavior of the method, and the association whose end is called 'invokedmethod' lets specify the call to another method.

Figure 7. Excerpt from the Java meta-model

B. Transformation rules In this section we describe the transformation rules. We

distinguish the rules which apply to the specific VUML elements and those that apply to elements of the UML meta-model. Indeed, all the rules in the first category are derived according to the implementation pattern as described previously (see Section III). For space reason, we present some transformation from the first category. The transformation rules of the second category are detailed in the transformation UML2Java [4].

• For each Base class instance in the VUML model named CMV for example:

- Create a JavaClass instance named Base_CMV in the Java model.

- For each Attribute instance of the Base class instance, create a Field with the same name and the same type in the Base_CMV class.

- For each Operation instance of the Base class instance, create a Method with the same (name, parameters, etc.) in the Base_CMV class.

• For each Multiview class instance (named for example CMV) in the VUML model :

- Create a JavaClass instance in the Java Model with the same name CMV.

- Create a JavaClass instance in the Java model named ViewCMV.

- Create a Java Method instance named ‘getCMV’ owned by the ViewCMV class. This Method has the CMV class as returned type.

- Create a Field named ‘currentView’, owned by the CMV class and it has ViewCMV as type.

- Create a Field named viewList owned by the CMV class and it has Vector as type. This attribute is used to store instances of the class ViewCMV.

- Create an attribute named base owned by the CMV class, and it has Base_CMV as type.

- Create the Methods getBase(), setCurrentView() and getCurrentView() owned by the CMV class, their definitions are described in the implementation pattern (figure 5).

- For each Operation instance belongs to a base or a view class instance, create a Java method with the same name, type and parameters. Create also a parameter which has User as type (see Section III).

• For each Operation instance of a View class instance which belongs to the Multiview class instance CMV :

- Create a Java Method with the same name, type and parameters in the ViewCMV Java class. The behaviour of the created method is defined as below: if the operation belongs to the base class then this behaviour is restricted to invoke the same method from the base class, else it raises an exception (see Section III).

416

• For each View class instance in the VUML model which belongs to the Multiview class instance CMV :

- Create a JavaClass instance with the same name; this class will have the ViewCMV class created previously as parent.

- For each Attribute instance of the View class instance: create a Field with the same name and the same type in the view class.

- For each Operation instance of the View class instance: create a Method with the same (name, parameters, etc.) in the view class.

• For each Package class instance in the VUML model:

- Create a JavaPackage class instance with the same name. The path field contains the full path name’s packages separated by dots.

C. Implementation in ATL To implement and validate our approach, we needed

transformation language-based rules. We wanted to focus on declarative approaches to allow the developer to define its transformation at a high level of abstraction, without worrying about the final execution. At this stage it does not take into account the implementation constraints, including the rules enforcement. The management of the rules enforcement order may be delegated to a rules engine, but it is often necessary to help this engine by introducing imperative code depending on the complexity of the transformation.

The choice of a model transformation language was focused on ATL [19] which is a hybrid transformation language allowing to combining both declarative and imperative approaches. The first step of the implementation was to translate the target meta-model (Java) into a textual format using KM3 [20], a meta-model specification language conform to MOF [26]. To implement the VUML profile we used the Topcased editor [12].

We describe below a subset of the transformation rules developed largely using the declarative features of ATL.

1 module VUML2JAVA; -- Module Template 2 create OUT : JAVA from IN : UML2, PRO : UML2; 3 helper context UML2!Class def : getBase : UML2!Class= 4 let dependency : UML2!Dependency = 5 self.clientDependency->asSequence() in 6 if not dependency.oclIsUndefined() 7 then 8 dependency->select(d |d.hasStereotype('viewExtension')) 9 ->first().supplier 10 else false 11 endif 12 ; 13 helper context UML2!Element def :hasStereotype(s : String) : 14 Boolean = 15 if self.getAppliedStereotypes()->select(e | e.name = s) 16 ->notEmpty() 17 then true 18 else false 19 endif 20 ; 21 rule View2Class { 22 from v : UML2!Class(not 23 v.isInProfileDefinition and

24 v.hasStereotype('view')) 25 to out : JAVA!Class( 26 name <- v.name, 27 owner <- v.package, 28 isAbstract <- v.isAbstract, 29 isPublic <-v.isPublic(), 30 extend <- 31 thisModule.viewExtension2extensionClass(v.getBase) 32 ) 33 } 34 unique lazy rule viewExtension2extensionClass { 35 from vex : UML2!Class 36 to ex : JAVA!Class( 37 name <- 'View_' + vex.name, 38 owner <- vex.package, 39 isPublic <- true 40 ) 41 } Figure 8. Excerpt from the VUML2JAVA transformation in ATL

An ATL transformation definition consists of one or several modules. Each module is composed of four sections: a header section, an import section for importing libraries, a section which containing helpers, and transformation rules to implement transformation functionalities.

In the header section we specify the module name, the declaration of the involved models with their corresponding meta-models (Line 1-2). In the example, IN and PRO represent the source models (PRO is the model definition of the VUML profile) which are conform to the UML2 metamodel, while OUT denotes the target model which is conform to the metamodel JAVA.

The helpers in ATL are comparable to global methods in programming languages; their use have the advantage to increase the modularity of transformations, and this is performed by delegate complex processing to provide information useful for the transformation rules. In the example given above, the helper getBase (line 3-12) applies to a class stereotyped view, and returns the class stereotyped base which are connected through the dependency relationship stereotyped viewExtension.

Transformation rules are declared as matched rules (declarative feature of ATL); their call is done implicitly by the language engine. On the example, the rule View2Class (lines 21-33) creates as output a Java class from a UML class stereotyped as 'view', the guard condition being specified by the helper ‘hasStereotype’ (lines 13-20). In line 31, there is a call for the rule viewExtension2extensionClass, another type of declarative rules called 'unique lazy rules' (lines 34-41).

Once the output model is generated, the last step in the transformation process focuses to generate the final code for the Java output model. To achieve that, we use an ATL Query [4], whose example is presented below:

query JAVA2String_Query = JAVA!JavaElement.allInstances()-> select(e | e.oclIsKindOf(JAVA!Class))-> collect(c | c.toString().writeTo('C:/CodeJAVA/' + c.owner.name + '/'+ c.name + '.java')); -- Query Template uses Java2String;

Figure 9. Excerpt from the Java2String transformation in ATL

417

This query allows browsing the generated target model and selecting instances Class items whose content will be edited into a separate text file (.Java). The definition of the helper toString on a Java class item involves the invocation of this helper also on all properties and methods elements belonging to this class. The definition of this helper is specified in the library named Java2String. An example of code generated by the transformation is presented below:

package modelVUML; private class MedicalForm { private View_MedicalForm currentView; private vector viewsList = new vector(); private Base_MedicalForm _base; public MedicalForm() { currentView=new View_MedicalForm(this); } private Base_MedicalForm getBase() { return _base; } private View_MedicalForm getCurrentView() { return currentView; } private void setCurrentView(String view) { currentView=view; } public MedicalForm getMedicalForm(User U) { setCurrentView(U.getView()); getCurrentView.getMedicalForm(); } public void setMedicalForm(User U,MedicalForm f) { setCurrentView(U.getView()); getCurrentView.setMedicalForm(f); } }

Figure 10. Excerpt from the generated MedicalForm Java class

V. RELATED WORKS Automating the transformation of design to code targets

several advantages such as increase of productivity, enhancement of portability, time delivery reducing, eliminating errors associated with manual programming. Model Driven Development (MDD) and generative programming [10] are main approaches able to face this challenge.

The GReAt language (Graph Rewriting And Transformation) [1] developed by the ISIS laboratory at the University of Vanderbilt is a graphical model transformation language based on the theory of graph transformation. It uses the UML standard and OCL language [28] to represent the transformation domains and the involved integrity constraints. Agrawal et al used this language to develop code generators for Domain Specific Languages (DSL), and to convert state-flow models (StateFlow) into C++ code. This technique uses a meta-model whose meta-classes represent specific fragments of code. These classes are instantiated with the appropriate names of the elements generated during the transformation process. The language GReAt meets most of requirements expressed in the QVT RFP [27] with the exception of the bi-directionality transformation feature.

Czarnecki et al [11] define the code generation operation as a special case of a model-to-model transformation, by

defining a meta-model corresponding to the target language. However, the code produced is often given in text format for practical reasons related to the reuse of existing compilers. In this case, code generation approaches are called model-to-code transformations. Two categories are distinguished: i) approaches based on a visitor mechanism like in the Jamda Framework [17]. It includes a set of Java classes for manipulating models, and a visitor mechanism to navigate in the internal structure of models and generate the code in a text file. ii) approaches based on a set of templates to translate models into code. Within this category there are several commercial tools and open source Frameworks [18] [34]; the technique is based on using a generic program consisting of meta-code for access to the source information and to perform the code selection and the iterative expansion.

The first step of our code generation process is generic because it is independent from the target language. The implementation guarantees a high level of abstraction by focusing on the definition of transformation regardless of the target language. Our approach is in fact a hybrid one because it combines the use of MDE techniques to generate the PSM model, and the use of a visitor pattern mechanism to translate this PSM model into an object code in a text format.

VI. CONCLUSION AND PERSPECTIVES In this paper, we have presented a code generation process

for the VUML profile, according to the MDA standard [32]. This approach combines the use of pattern and model transformation techniques. The proposed implementation pattern is generic; it allows an automated translation of a model VUML (a class diagram so far) into a multi-target object code. This pattern uses the polymorphism and the handle technique, which confers dynamism on a multiview object making it possible to adapt its behavior to the active view.

To validate our work, we have applied our approach to a case study (SMFMS system) resulting from real needs. Taking a source model conform to the VUML profile [25], and considering a target object platform such java, we applied the proposed process, by implementing the transformation rules presented in this paper.

To implement the different rules, the choice of a dedicated transformation language was made on ATL language, one of the main transformation language of the market. This choice enabled us to code the majority of the transformation rules in a declarative form. In this way, the execution order of transformation rules is implicitly specified by the developer. Thus, it is taken in charge by a resolution algorithm implemented in the ATL engine. The requirements relating to the implementation constraints such as model serialization, debugging, are taken into account by the development environment of ATL.

The use of MDE techniques for code generation allows a real automation. The code produced by this technique answers the criteria of legibility, maintainability, robustness and effectiveness. In addition to the code generation, the profile carried out allows to visualize and publish the generated code by using external editors.

418

Once the architectural code is generated, it remains to generate the functional code of the methods to have the complete system code. For this purpose, we are working first on the integration of the concept of viewpoint in dynamic modeling with UML (mainly activity and state-transition diagrams), and second on the enhancement of the code generator to take into account this dynamic aspect.

In addition, given that the generated code usually undergoes several updates by the programmer, one of important perspective of our work is to use the reverse engineering technique to get the updates into VUML model.

ACKNOWLEDGEMENTS This work has been partially supported by the COMPUS

Project MA/06/151, VOLUBILIS 2006.

REFERENCES [1] A. Agrawal, G. Karsai, Z. Kalmar, S. Neema, F. Shi, A. Vizhanyo, The

Design of a Language for Model Transformations, Journal of Software and System Modeling, in review, 2005.

[2] A. Anwar, M. Nassar, S. Ebersold, B. Coulette, A. Kriouile, “A QVT- Based Approach For Model Composition: Application to the VUML Profile”, In Proc of ICEIS 2008, pp. 360-367. Barcelona, Spain, Juin 2008.

[3] A. Anwar, S. Ebersold, M. Nassar, B. Coulette, A. Kriouile, “Towards a generic approach for model composition”, International Conference on Software Engineering Advances (ICSEA), IEEE Computer Society press, Malte, October 27-30, 2008.

[4] ATL Web site, The ATL UML to JAVA transformation. Available at http://www.eclipse.org/gmt/atl/atlTransformations/.

[5] E. Baniassad, S. Clarke, “Theme: An approach for aspect-oriented analysis and design”, In Proc. of the International Conference on Software Engineering. (2004), pp. 158 -167.

[6] J. Bézivin, O. Gerbé, “Towards a Precise Definition of the OMG/MDA Framework”, ASE’01,Automated Software Engineering, San Diego, USA, November 26-29, 2001.

[7] S. Clarke, “Extending Standard UML with Model Composition Semantics”, Science of Computer Programming, 44 (2002) 71.100.

[8] P. Coad, Object-oriented Patterns. Communications of the ACM, 1992. [9] X. Crégut, S. Marcaillou, M. Nassar, B. Coulette, “Un patron de

génération de code pour le profil VUML”, LMO-OCM’2005, Berne, Suisse, 9-11 mars 2005. pp. 5-11.

[10] K. Czarnecki, U.W. Eisenecker, Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000.

[11] K. Czarnecki, S. Helsen, Classification of Model Transformation Approaches, In 2nd OOPSLA Workshop on Generative Techniques in the context of Model Driven Architecture. Anaheim, CA, USA. October 2003.

[12] P. Farail, P. Gaufillet, A. Canals, C. L. Camus, D. Sciamma, P. Michel, X. Crégut, M. Pantel, “the TOPCASED project : a Toolkit in OPen source for Critical Aeronautic SystEms Design”, Embedded Real Time Software (ERTS), Toulouse, 25-27 January, 2006.

[13] Finkelstein, J. Kramer, and M. Goedicke. “Viewpoint Oriented Software Development”, In Software Eng. and Applications Conference. Toulouse, France, pages 337-351, 1990.

[14] R. B. France, I. Ray, G. Georg, S. Ghosh, “An aspect-oriented approach to design modeling”. IEE Proceedings - Software, Special Issue on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design 151 (2004) 173.185.Gamma, and al. Design patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

[15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995.

[16] W. Harrison, H. Ossher, “Subject-oriented programming: a critique of pure objects”. In OOPSLA’93, Washington D.C., pages 411-428, 1993.

[17] Jamda: The Java Model Driven Architecture 0.2, May 2003, http://sourceforge.net/projects/jamda/.

[18] Java Emitter Templates (JET). Part of the Eclipse Modeling Framework, see JET Tutorial by Remko Pompa at http://eclipse.org/articles/Article-JET2/jet_tutorial2.html.

[19] F. Jouault, I. Kurtev, “Transforming Models with ATL”, In Proceedings of the Model Transformations in Practice, Workshop at Models 2005, Montego Bay, Jamaica 2005.

[20] F. Jouault, J. Bézivin, “KM3: a DSL for Metamodel Specification”, Proc. of 8th FMOODS, LNCS 4037, Bologna, Italy, Kolski C., Interfaces homme-machine, Paris, Hermès, 2006, p. 171-185.

[21] G. Kiczales, J. Lampng, A. Mendhekar, C. Maeda, L.C. Videira, “Aspect-Oriented Programming”, In ECOOP’97. Springer-Verlag LNCS 1241. Finland, 1997.

[22] H. Mili, J. Dargham, A. Mili, “Views: A Framework for Feature-Based Development and Distribution of OO Applications”, In Thirty-Third Hawaii International Conference on System Science, Honolulu, 2000.

[23] O. Muller, B. Caron, B. Carré, and G. Vanwormhoudt. “Réutilisation d'aspects fonctionnels : des vues aux composants”. Revue RSTI - L'Objet, septembre, 2003, pp. 241-255.

[24] M. Nassar, B. Coulette, X. Crégut, S. Marcaillou, and A. Kriouile. “Towards a View based Unified Modeling Language”. In ICEIS’03, Angers, France, 2003.

[25] M. Nassar, Analyse/conception par points de vue : le profil VUML, Thèse de l’Institut National Polytechnique de Toulouse - Septembre 2005.

[26] OMG/MOF Meta Object Facility (MOF) 1.4. Final Adopted Specification Document. formal/02-04-03, 2002.

[27] OMG Request for Proposal : MOF 2.0 Query/ Views/Transformations, RFP. Object Management Group, Inc 2002. [online] available: http://www.omg.org/docs/ad/02-04-10.pdf.

[28] OMG, UML 2 OCL Final Adopted Specification, 2003, http://www.omg.org/docs/ptc/03-10-14.pdf.

[29] OMG, 2004. Unified Modeling Language, version 2.0, http://www.omg.org.

[30] H. Ossher, M. Kaplan, A. Katz, W. Harrison, V. Kruskal, Specifying subject-oriented composition. Theory and Practice of Object Systems, Wiley and Sons 2 (1996).

[31] M. Peltier, “Transformation entre un profil UML et un métamodèle MOF”, Revue l’Objet, vol. 8, n°1-2/2002, LMO’2002, pp. 25-40.

[32] S. Richard et al., Object Management Architecture Guide.MDA Guide Version 1.0.1.http://doc.omg.org/omg/2003-06-01.

[33] C. Szyperski, Component Software, Addison-Wesley, 1999. [34] Velocity1.3.1. The Apache Jakarta Project, March 2003,

http://jakarta.apache.org/velocity/. [35] Web Site of Objecteering, 2004, http://www.objecteering.com

419