EVALUATION OF THE DIAGRAM DEFINITION STANDARD FOR...
Transcript of EVALUATION OF THE DIAGRAM DEFINITION STANDARD FOR...
EVALUATION OF THE DIAGRAM
DEFINITION STANDARD FOR
VISUAL LANGUAGE
SPECIFICATION
DRT/LIST/DILS/Laboratoire d’Ingénierie dirigée par les modèles pour les Systèmes Embarqués
June 22nd 2015
CEA | 22 JUNE 2015
THE MOTIVATION
| PAGE 2 CEA | 22 JUNE 2015
Class
Concrete
syntax
Graphical
vocabulary
Visual aspect Abstract syntax Semantic
Specification Specification
Specified with models
Usable by computers ✓ Rely on ”by example” interpretation
Not usable by computers ✕
Visual modeling language specification
THE MOTIVATION
| PAGE 3 CEA | 22 JUNE 2015
Domain
model
(*.ecore)
Graphical
definition
(*.gmfgraph)
Tools
definition
(*.gmftool)
Mapping
model
(*.gmfmap)
Generator
model
(*.gmfgen)
Diagram editor
(plugin Eclipse)
GMF-Tooling provides a formalism to specify a modeling
language, and then generate the appropriate diagram editor
UML spec
Tool builder
Rely on ”by example” interpretation
Not usable by computers ✕
THE MOTIVATION
| PAGE 3 CEA | 22 JUNE 2015
Generator
model
(*.gmfgen)
Diagram editor
(plugin Eclipse)
GMF-Tooling provides a formalism to specify a modeling
language, and then generate the appropriate diagram editor
This process has never been used because the
GMFGen model had to be adapted anyway ✕
UML spec
Tool builder
Rely on ”by example” interpretation
Not usable by computers ✕
THE DIAGRAM DEFINITION ARCHITECTURE
| PAGE 5 CEA | 22 JUNE 2015
Diagram Definition support the MVC pattern required to provide tooling for a visual
language [OMG12].
Abstract
Syntax
Concrete
Syntax
Graphical
Vocabulary [OMG12] Object Management Group,
Diagram Definition 1.0 - formal/2012-07-01,
OMG, 2012.
THE DIAGRAM DEFINITION ARCHITECTURE
| PAGE 6 CEA | 22 JUNE 2015
UMLDI exemplify the use of DD for the specification of the UML
concrete syntax [OMG12].
Abstract
Syntax
Concrete
Syntax
Graphical
Vocabulary
OBJECTIVES OF THE EVALUATION APPROACH
| PAGE 7 CEA | 22 JUNE 2015
Generator
model
(*.gmfgen)
Diagram Editor
(Eclipse plugin)
Build a
prototype
Build a
prototype use
Is the DD standard sufficient to fully
specify the concrete syntax of a
language ?
Can we generate fully featured
spec-compliant tooling ?
Language
specification
DD
M2M M2T build
USE CASE
| PAGE 8 CEA | 22 JUNE 2015
Restrictions:
• 1-1 mapping to the abstract syntax
• Reuse UML abstract syntax from Papyrus
• Reuse UML rendering implementation from Papyrus
ANALYSIS OF GMFGEN REQUIREMENTS
| PAGE 9 CEA | 22 JUNE 2015
GenLink
GenCompartment
GenNode
GenLabel
GenLabelNode
What we need to know to build the GMFGen model:
• The different kind of graphical element’s behavior
• The different kind of graphical relations
• Connections with the abstract syntax (ModelFacet)
• Connections with graphical vocabulary (FigureViewMap)
Inclusion
Edge’s
Source/target
GenAfxNode
DOES DD ANSWER THE GMFGEN REQUIREMENTS ?
| PAGE 10 CEA | 22 JUNE 2015
Only three kind of
graphical elements
Use of a UML profile
DI meta-model
Do we know enough about graphical element’s behavior distinction ?
DOES DD ANSWER THE GMFGEN REQUIREMENTS ?
| PAGE 11 CEA | 22 JUNE 2015
Do we know enough about graphical relations ?
Extract of UMLDI meta-model
Not enough information on
graphical relations
DOES DD ANSWER THE GMFGEN REQUIREMENTS ?
| PAGE 11 CEA | 22 JUNE 2015
Do we know enough about graphical relations ?
Extract of UMLDI meta-model
Not enough information on
graphical relations
Syntax enrichment
DOES DD ANSWER THE GMFGEN REQUIREMENTS ?
| PAGE 13 CEA | 22 JUNE 2015
Do we know enough about abstract syntax connections ?
Each graphical element can be
linked to any abstract syntax
elements
Extract of DI meta-model
From that, can we automatically deduce connections between graphical
inclusion relations and abstract syntax containments ?
DOES DD ANSWER THE GMFGEN REQUIREMENTS ?
| PAGE 14 CEA | 22 JUNE 2015
From that, can we automatically deduce connections between graphical
relations and abstract syntax containments ?
Diagram
Package
Class
packagedElement
Abstract syntax
Simple case, can be solved
automatically ✓
DOES DD ANSWER THE GMFGEN REQUIREMENTS ?
| PAGE 14 CEA | 22 JUNE 2015
From that, can we automatically deduce connections between graphical
relations and abstract syntax containments ?
Diagram
entry
State
Behavior
exit doActivity
Abstract syntax
Ambiguous case, can not be
solved automatically ✕
DOES DD ANSWER THE GMFGEN REQUIREMENTS ?
| PAGE 14 CEA | 22 JUNE 2015
From that, can we automatically deduce connections between graphical
relations and abstract syntax containments ?
Development of an algorithm to analyze the whole UML meta-model.
172 containments cases including 34 ambiguous.
Considering the UML redefinition mechanism allows to solve only one case.
Language designer or user intervention is required.
Diagram
entry
State
Behavior
exit doActivity
Abstract syntax
THE SOLUTION PROPOSAL
| PAGE 17 CEA | 22 JUNE 2015
UMLDI enriched
• Graphical element distinction
THE SOLUTION PROPOSAL
| PAGE 17 CEA | 22 JUNE 2015
UMLDI enriched
• Graphical element distinction
• Syntax enrichment
THE SOLUTION PROPOSAL
| PAGE 17 CEA | 22 JUNE 2015
UMLDI enriched
• Graphical element distinction
• Syntax enrichment
• Connections with abstract syntax elements
THE SOLUTION PROPOSAL
| PAGE 17 CEA | 22 JUNE 2015
UMLDI enriched
• Graphical element distinction
• Syntax enrichment
• Connections with abstract syntax elements
• Graphical element’s behavior distinction
THE SOLUTION PROPOSAL
| PAGE 21 CEA | 22 JUNE 2015
Tool generation process
Execution of the prototype on UMLDI Execution of the GMFT M2T transformation
Containments computation
+
M2M Transformation
M2T Transformation
deployment
Eclipse plugin
Diagram editor within Eclipse
THE SOLUTION PROPOSAL
| PAGE 22 CEA | 22 JUNE 2015
Generated diagram editor
Graphical elements
are correctly handled
Graphical relation are
correctly handled
Only the simple
cases are handled
WHAT THE SOLUTION DO
| PAGE 23 CEA | 22 JUNE 2015
✓
• Improve our understanding of the DD standard : what we can do, what
are the limitations.
• Proposal of a formalism to fully specify the graphical syntax of a language
using the DD standard
• Development of a prototype to validate the proposal.
WHAT THE SOLUTION DO NOT DO
| PAGE 24 CEA | 22 JUNE 2015
✕
• Only the very simple cases are handled.
• The graphical vocabulary is not exploited.
• Ad-hoc graphical element’s behavior identification.
WHAT THE SOLUTION COULD DO
| PAGE 25 CEA | 22 JUNE 2015
• Handle the graphical vocabulary using a modular QVTo DIDG
transformation.
• Handle n-m mapping to the abstract syntax using a framework for
incremental transformation.
• Handle real label specification.
• Provide a more general and flexible mechanism for graphical element’s
behavior identification, or
• Provide a declarative framework to model UI interactions.
HANDLING THE GRAPHICAL VOCABULARY
| PAGE 26 CEA | 22 JUNE 2015
UMLDI DG
FigureViewMap
+ void paint(Graphics graphics)
QVTo
mapping
Class
Diagram canvas
FigureViewMap
+ void paint(Graphics graphics)
FigureViewMap
+ void paint(Graphics graphics)
1. Get UMLDI element
2. Produce DG element
3. Render DG element
4. Repaint related FigureViewMaps
1
2
3
4
instanceOf
DRT/LIST
DILS
LISE
Commissariat à l’énergie atomique et aux énergies alternatives
Centre de Saclay | 91191 Gif-sur-Yvette Cedex
Etablissement public à caractère industriel et commercial | R.C.S Paris B 775 685 019
| PAGE 27
CEA | 22 JUNE 2015
Thank you for your attention
Any questions ?
PROTOTYPE OVERVIEW
| PAGE 28 CEA | 22 JUNE 2015
PROTOTYPE OVERVIEW
| PAGE 29 CEA | 22 JUNE 2015
Kind of element handled
(UMLDI meta-model) Java class
Kind of element
generated
(GMFGen model)
DI::Diagram DIGenDiagram GenMultiFacetedNode
DI::Shape DiGenShape GenMultiFacetedNode
DI::Shape « affixed » DiGenAfxNode GenAffixedNode
DI::Shape « compartment » DiGenCompartment GenCompartment
DI::Shape « label » DIGenLabelNode GenLabelNode
DI::Shape « internallabel » DIGenLabel GenLabel
DI::Edge DIGenEdge GenLink