Da

te /R

éfé

renc

e

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 2

Talk outline

• Viewpoint modeling and variability overview• MOVIDA project presentation• MOVIDA tools presentation :

• Obeo Desiger

• Praxis

• Variability tool

• Tutorial example• Conclusion

3 3

Viewpoint modeling

• Viewpoint : an encapsulation of partialinformation 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 practicalapproach 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 5

Challenges

StandardsStandards

OMG Diagram definition RFP

OMG Common Variability Language RFP IEEE-1471 – ISO/IEC 42010

OMG Diagram definition RFP

OMG Common Variability Language RFP IEEE-1471 – ISO/IEC 42010

NeedsNeeds

Environment to define architecture setting

Tool and methodology sustaining a grand scale

Environment to define architecture setting

Tool and methodology sustaining a grand scale

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)

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)

Scientific stakesScientific stakes

6 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 7

MOVIDA Overview 2/2

Viewpoint definition

Representation definition

Use of Obeo Designer

Viewpoint definition

Representation definition

Use of Obeo Designer

Multi-criteria analysis to select the best compromise of architecture

Multi-criteria analysis to select the best compromise of architecture

Variability

Composability

Variability tool

Variability

Composability

Variability tool

Inconsistencies detection

Use of Praxis

Inconsistencies detection

Use of Praxis

8 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 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 10

Variability example

11 11

Obeo Designer

12 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 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 14

Obeo Designer

• Modelers adapted to your own needs :

Your know-how Your modeler Your users

15 15

Obeo Designer

• Applicative domains :

Applicative cartography Software design ex : UML, SOA

Products catalogex : Insurance

System engineeringEx : SysML, Marte, EAST-ADL Risk analysis Business process

ex : BPMN, SPEM

Enterprise Architectureex : Togaf

Your domain

16 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 environmentBased on EMF, GMF and Acceleo

17 17

Obeo Designer

Principles :

18 18

Obeo Designer

• Obeo Designer based on : • Eclipse platform

• Some components of the project Eclipse modeling

19 19

Obeo Designer

TO DO add 1 or 2 more technical slides :Graphical conceptsMapping language

20 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 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 22

Actions based model representation

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)....

Object ID Metaclass Timestamp

Reference orPropertyname

23 23

Overview of PraxisRules

Importing metamodels orOther rulesets

RuleSet declaration

Rule user friendlydescription

Logical connectives

Actions

Built-ins

24 24

Associating a RuleSet to a Viewpoint

1. Select Viewpoint

2. Select RuleSet in Properties View

25 25

Checking Inconsistencies at Runtime

Current Model

Problems view

Inconsistency

26 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 27

Variability tool : choices made

• Feature metamodel :

• Decomposition edge such as or, xor (called here alternative), card

• Attributes : associate metadata to features

• Direct mapping with Domain model elements in features

• Graphical notation :• similar to FORM notation (Kang et al. (1) ) (but simplification of the

notation on the tool)

• Constraints :• Integrated with the graphical editor

(1) Kang, K.C., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: FORM: A Feature-Oriented Reuse Methodwith Domain-Specific Reference Architectures. Ann. Softw. Eng. 5 (1998) 143–168

28 28

Product Derivation Engine models

Source : CVL RFPSource : CVL RFP

RFP CVL (Common Variability Language) PresentationRFP CVL (Common Variability Language) Presentation

• 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

• 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

CVL ModelsCVL Models

Product Derivation ConceptsProduct 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

• 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 29

Feature diagram metamodel

30 30

Resolution metamodel

It references a given FeatureDiagram and some features on it.

31 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

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 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 33

Base Model Decorator

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

34 34

Selection Engine

• We choose to select the feature twoInputs

Selection in the Resolution modelby checking selected features

35 35

Product Derivation Engine

• After derivation we obtain the following model :

36 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 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 38

Practice : Metamodel proposition

• QUESTION 1 : What metamodel could we propose for the component model and the Finite state machine?

39 39

Possible solution used in this tutorial 1/2

• Component metamodel :

40 40

Possible solution used in this tutorial 2/2

• Finite State Machine metamodel :

41 41

Express constraints on this metamodel 1/2

• QUESTION 2 : What constraints could we write on these metamodels?

42 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 43

Write constraints in OCL and Praxis

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

44 44

OCL constraints

• Two states cannot have the same namenot self.owningFSM.ownedState->exists( st | st.name = self.name

and st <> self)

45 45

Praxis Constraints

• Two states cannot have the same name

46 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 47

TO DO : present other constraints

48 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 49

Write constraints in OCL and Praxis

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

50 50

Variability on Finite State Machine

• Two possible choices :• Use calculate1() and finish in st1 state•Use calculate2() and finish in st2 state

51 51

Write constraints in OCL and Praxis

• QUESTION 6 : Use the variability tool (Chapter 5)

52 52

Conclusion

• This tutorial has shown how to :• Create a metamodel and a graphical modeler using EMF and

Obeo Designer

• Write constraints on a given metamodel in OCL and Praxis and how to check it

• Use the variability tool for model created with the previous modeler

• For more information please refer to :• MOVIDA update site : http://movida.gforge.inria.fr/index.php?

n=Main.HomePage

53 53

Questions

Thank you for your attention.

Do you have any questions?