MOVIDA studio : a modeling environment to create viewpoints and manage variability in views

1. MOVIDA studio : a modeling environment to create viewpoints and manage variability in views Marie Gouyette, INRIA Olivier Barais, IRISA Université Rennes 1 Jérôme Le Noir, Thalès Reseach and Technology Cédric Brun, Obeo Marcos Almeida Da Silva, LIP6 Xavier Blanc, Labri, Daniel Exertier, Thalès Corporate Services, Jean-Marc Jézéquel, Irisa, Université de Rennes 1

2. Talk outline • Viewpoint modeling and variability overview • MOVIDA project presentation • MOVIDA tools presentation : • Obeo Desiger • Praxis • Variability tool • Tutorial example • Conclusion

3. Viewpoint modeling • Viewpoint : an encapsulation of partial • information about a system (1) • View : an integration of different types of information taken from the same viewpoint (1) (1) SOMMERVILLE I., SAWYER P., Viewpoints : principles, problems and a practical approach to requirements engineering , Ann. Softw. Eng., vol. 3, 1997, p. 101–130, J. C. Baltzer AG, Science Publishers 3

4. Viewpoint modeling examples Exchanges viewpoint Safety Viewpoint Here, two viewpoints on the same architecture. Safety viewpoint add temperature concern (display temperature and used fan). 4

5. Challenges Needs • Environment to define architecture setting • Tool and methodology sustaining a grand scale Standards OMG Diagram definition RFP OMG Common Variability Language RFP IEEE-1471 – ISO/IEC 42010 Scientific stakes • Define basis of multi-view engineering in Model Driven Engineering context (MDE) • Point of view definition (Obeo) • Inconsistencies detection (Praxis, LIP6, UPMC) • Representation definition (Obeo) • Model composability (INRIA) • Variability (INRIA) • Multi-criteria analysis to select the best compromise of architecture (Thales)

6. MOVIDA Overview 1/2 • MOVIDA : MOdelling VIews and Decision support for Architects • ANR project (2009-2011) • Aim : multi-view engineering in Model Driven Engineering context (MDE) • Partners : • Multi-criteria analysis to select the best compromise of architecture (Thales)

7. MOVIDA Overview 2/2 • Variability • Composability • Variabilitytool • Multi-criteriaanalysis to select the best compromise of architecture • Inconsistenciesdetection • Use of Praxis • Viewpointdefinition • Representationdefinition • Use of Obeo Designer

8. Check inconsistencies between the different viewpoint • Is information from different viewpoints on the same system are consistent? • How to check it? • => Writing some constraints • Should Manage : • Incremental check : check only the last actions on the model not the whole actions on the model • Multi-model : detect inconsistencies between different models

9. Variability overview • Software Product Line (SPL) : • Engineering techniques to manage software systems that have some commonalities and some variations (variability) between them • Variability can be modeled through features. • Feature : • “a distinguishable characteristic of a concept (e.g system components and so on) that is relevant to some stakeholder of the concept” (1) (1) Ulrich W. Eisenecker, K.C., ed.: Generative Programming : Method Tools and Applications. Addison- Wesley Professional (2000)

10. Variability example

11. Obeo Designer

12. MOVIDA tools presentation • We will present here three of tools used in MOVIDA : • Obeo Designer (Obeo) • Praxis (UPMC, LIP6) • Variability tool (INRIA/IRISA)

13. Obeo Designer • Aims : • Express a need • Describe a solution • Check the model • Produce code or documentation • Keep consistency between model and code Graphical modeling

14. Obeo Designer • Modelers adapted to your own needs : Your know-how Your modeler Your users

15. Obeo Designer • Applicative domains : Applicative cartography Software design ex : UML, SOA Products catalog ex : Insurance System engineering Ex : SysML, Marte, EAST-ADL Business process ex : BPMN, SPEM Risk analysis Enterprise Architecture ex : Togaf Your domain

16. Obeo Designer • Key functionalities : • No code to define the modeler • Modeler described by a model, dynamically interpreted • Numerous possibilities of representation • Diagrams, tables, matrices, trees • Viewpoint approach • Presentation of information necessary and sufficient • Traceability • Synchronization between model and generated code • Integration to Eclipse environment • Based on EMF, GMF and Acceleo

17. Obeo Designer • Principles :

18. Obeo Designer • Obeo Designer based on : • Eclipse platform • Some components of the project Eclipse modeling

19. Obeo Designer • TO DO add 1 or 2 more technical slides : • Graphical concepts • Mapping language

20. Praxis overview • Aim : Incremental detection of inconsistency in design models • Principles : • Model represented as the set of construction actions • Incremental inconsistency detection based on increments • Tool separated into two parts : • PraxisRules inconsisteny rules editor • Praxis inconsistency detector

21. Praxis : choices made • Construction Actions : • Six actions based on MOF metamodel • Create and Delete • Ex: create(a, class) • AddProperty and RemProperty • Ex: addProperty(a, name, ‘User’) • AddReference and RemReference • Ex: addReference(a, ownedOperation, op) • PraxisRules : • Rule based language based on Prolog • Rules describe inconsistencies • Rules are contex-free

22. Actions based model representation Timestamp Metaclass Object ID create(xmiid_TyAw, fsm, 811). addProperty(xmiid_TyAw, name, 'F', 812). create(xmiid_VuRw, state, 813). addProperty(xmiid_VuR,name, 'initial', 814). create(xmiid_XZtw,state, 816). addProperty(xmiid_XZt,name, 'end', 817). addReference(xmiid_TyA,ownedstate, xmiid_VuR, 815). addReference(xmiid_TyA,ownedstate, xmiid_XZt, 818). ... Reference or Property name

23. Overview of PraxisRules Importing metamodels or Other rulesets RuleSet declaration Rule user friendly description Logical connectives Actions Built-ins

24. Associating a RuleSet to a Viewpoint • Select Viewpoint • Select RuleSet in Properties View

25. Checking Inconsistencies at Runtime Current Model Inconsistency Problems view

26. Variability tool overview • Aim : model variability on an architecture with the possibility to derive it to obtain the final architecture • Tool separated into four parts : • Graphical feature diagram editor with constraints to check it • Base Model Decorator • Selection Engine • Product Derivation engine • Technologies used : • EMF (Eclipse Modeling Framework) • Obeo Designer • Praxis • Kermeta (Domain Specific Language dedicated to metamodel engineering (INRIA Triskell team)

27. Variability tool : choices made • Featuremetamodel : • Decompositionedgesuch as or, xor (calledherealternative), card • Attributes : associatemetadata to features • Direct mappingwith Domain model elements in features • Graphical notation : • similar to FORM notation (Kang et al. (1) ) (but simplification of the notation on the tool) • Constraints : • Integratedwith the graphical editor (1) Kang, K.C., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures. Ann. Softw. Eng. 5 (1998) 143–168

28. Product Derivation Engine models RFP CVL (Common Variability Language) Presentation CVL Models • Source : CVL RFP • Base Model : general architecture model • Variability model : feature diagram model • features are associated with domain model elements • Resolution model : contain feature selection • Resolved model : specialized architecture model Product Derivation Concepts • Use the models defined above as in CVL approach (but it is not CVL here) • Use negative variability : domain model elements associated to unselected features are removed

29. Feature diagram metamodel

30. Resolution metamodel It references a given FeatureDiagram and some features on it.

31. Example of variability in an architecture • Two variability points on these architecture : • The first is plugged in the mains • The second have a second input controller • A second fan can be added as option

32. Feature Diagram Editor • Now, each Domain Model Element is added as a text in the feature • The attribute maxConsumption is represented in gray.

33. Base Model Decorator • Aim : make appears a graphical decorator on Domain Model Elements added on an optional feature (Here a Fan element)

34. Selection Engine • We choose to select the feature twoInputs Selection in the Resolution model by checking selected features

35. Product Derivation Engine • After derivation we obtain the following model :

36. Tutorial example presentation • Aim of this tutorial : using the following tool to create a new DSML on which we can add some variability • Steps : • EMF and Obeo Designer • Praxis and OCL • Variability tool

37. Example presentation • We want to model some component which behavior can be modeled through a Finite State Machine model. • These components can have : • Provided and required ports • A way to link these ports • Some interfaces with some operations • A link to a given Finite State Machine • For the finite state machine we need : • States • Transitions

38. Practice : Metamodel proposition • QUESTION 1 : What metamodel could we propose for the component model and the Finite state machine?

39. Possible solution used in this tutorial 1/2 • Component metamodel :

40. Possible solution used in this tutorial 2/2 • Finite State Machine metamodel :

41. Express constraints on this metamodel 1/2 • QUESTION 2 : What constraints could we write on these metamodels?

42. Example of constraints • Components constraints : • A bundle must have a provided interface and a required interface • For a given,component that references a FSM, transitions input from this fsm must to operations names associated with this component • Finite State Machine constraints : • Two states elements cannot have the same name • The FSM must be determinist : we cannot have two transition starting with the same state and with the same input

43. Write constraints in OCL and Praxis • QUESTION 3 : How to write these constraints in OCL and Praxis?

44. OCL constraints • Two states cannot have the same name • not self.owningFSM.ownedState->exists( st | st.name = self.name and st <> self)

45. Praxis Constraints • Two states cannot have the same name

46. Creating a PraxisRules Plugin • File > New > Other > PraxisRules Plug-in Project Wizard • Anatomy of a PraxisRules Plug-in Project Built-ins declaration RuleSet and its Prolog compiled version Rules Metadata

47. TO DO : present other constraints

48. Write constraints in OCL and Praxis • QUESTION 4 : Create an EMF model for FSM and an Obeo Designer modeler following the tutorial (Chapter 3)

49. Write constraints in OCL and Praxis • QUESTION 5 : Write constraints in Praxis and OCL (Chapter 4)

50. Variability on Finite State Machine • Two possible choices : • Use calculate1() and finish in st1 state • Use calculate2() and finish in st2 state