date /référence movida studio : a modeling environment to create viewpoints and manage variability...
Post on 20-Dec-2015
217 views
TRANSCRIPT
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?