adding a textual syntax to an existing graphical modeling language: experience report with grl...
TRANSCRIPT
Adding a Textual Syntax to an Existing Graphical Modeling Language:
Experience Report with GRL
Vahdat Abdelzad, Daniel Amyot, Timothy Lethbridge
University of Ottawa, [email protected]
SDL 2015, Berlin, October 13
Outline
• Motivation: Current issues with the Goal-oriented Requirement Language
• Other Textual Syntaxes• Six Challenges• TGRL: A Textual Syntax for GRL• Conclusions and Future Work
SDL 2015 – p. 2
SDL 2015 – p. 3
GRL
UCM
http://www.itu.int/ITU-T/studygroups/com17/index.html
intentional elements + actors + indicators + links + strategies
responsibilities + causality + components + scenarios
URN Links
GRL Metamodel (Partial 1/2)
SDL 2015 – p. 4
Contribution
contribution : ContributionType = UnknownquantitativeContribution : Integer = 0correlation : Boolean = false
ContributionType
MakeHelpSomePositiveUnknownSomeNegativeHurtBreak
<<enumeration>>
Decomposition DecompositionType
ANDXORIOR
<<enumeration>>
Dependency IntentionalElementType
SoftgoalGoalTaskResourceBelief
<<enumeration>>
GRLmodelElement
GRLLinkableElement IntentionalElement
type : IntentionalElementTypedecompositionType : DecompositionType = AND
URNmodelElement
id : Stringname : String
Metadata
name : Stringvalue : String
0..1
0..* elem
0..1metadata
0..*
URNlink
type : String
0..*1toLinks
0..*toElem1
1 0..*fromElem1
fromLinks0..*
Indicator
unit : String = ""
ElementLink 0..* 1linksDest0..* dest 1
0..*
1linksSrc
0..* src1
URNspec
name : String
0..10..*
0..1
metadata0..*
1
0..*
1
urnLinks
0..*
GRLContainableElementActor
0..10..*
actor
0..1 elems0..*
GRLspec
0..*
1
links 0..*
1
1
0..1
1
0..10..*1
intElements0..*1
0..*1actors0..*1
ImportanceType
HighMediumLowNone
<<enumeration>>
GRL Metamodel (Partial, 2/2)
SDL 2015 – p. 5
GRLmodelElement
Label
deltaX : IntegerdeltaY : Integer
GRLGraph
Position
x : Integery : Integer
Size
width : Integerheight : Integer
ActorRef
0..1
1
0..1
label 1
1
0..*diagram
1
contRefs0..*
0..1
1
0..1
pos
1
0..1
1
0..1size
1
Actor
1 0..*actorDef
1
actorRefs
0..*
ConcreteStyle
lineColor : StringfillColor : Stringfilled : Boolean = false
GRLLinkableElement
importance : ImportanceType = NoneimportanceQuantitative : Integer = 0
0..1
0..1
linkElement0..1
style0..1
Current Issues
• Graphical syntax is great for validation by stakeholders and for the analysis of strategies– BUT: Creating (goal) models is often a
tedious task with current graphical tools• Even worse for GUI-intensive features in jUCMNav
such as indicators, strategy definitions and contribution overrides
• A textual syntax might be simpler…– SDL, MSC, … offer both textual & graphical– BUT: for GRL, a standard metamodel
already exists
SDL 2015 – p. 7
Question
SDL 2015 – p. 8
• How easy is it to add a textual concrete syntax to an existing metamodel-based language that offers only a concrete graphical syntax?– Good experience with Umple for class/state diagrams
(Forward et al., 2012), but UML metamodel not used• Answer (take away):
– Important conflicts between the reuse of existing metamodels and the usability of the resulting textual syntax and tools require attention!
Other Textual Syntaxes: For Goal Modeling
• Liu and Yu (2001): textual grammar and an XML-based interchange format for draft GRL Not simple, never implemented
• Formal Tropos (Fuxman et al., 2004) For logic constraints, not the full goal modeling
language
SDL 2015 – p. 9
UML Human-Usable Textual Notation (HUTN, from OMG, 2004)
• For automatically supporting user-readable concrete syntaxes of models and model instances based on MOF
• Textual syntax does not need to reflect exactly the structure of the metamodel (shorthands), e.g.:– The use of default values for mandatory attributes (making
them optional);– The selection of an alternate name for any model element;– …
SDL 2015 – p. 10
Problem Solved?
• HUTN not well supported by tools (Rose et al., 2008), and resulting editors are not really usable
• Xtext (2015) more popular, with usable editors, but the underlying metamodel is usually built automatically from the grammar
• EMFText (Heidenreich et al., 2009) and TCS (Jouault et al. 2006) less mature than Xtext, and no longer maintained
• So, there is room for improvement! What do we do in the meantime? Our experience with TGRL…
SDL 2015 – p. 11
Challenge 1: Choice of Keywords
• Need to balance:– Closeness to metamodel concepts and names– Alignment with graphical syntax symbols– Use of domain vocabulary for simpler adoption
• Solutions may differ:– Stick to the metamodel name (e.g., actor)– decomposedBy instead of Decomposition, for
directionality (Goal1 decomposedBy Goal2, Goal3)– No keyword if context is clear (e.g., GRL evaluation
values)
SDL 2015 – p. 12
Challenge 2: Structure Consistency
• Several structures come with properties, which are often optional (given default values)
• In TGRL (as in Umple):– If a structure has only one property (attribute), then
its name is not used (as it is implicit)– If a structure supports many properties, then we use
named assignments, and no order is expected: property_name=value;
SDL 2015 – p. 13
Challenge 3: Alignment of Metamodels
• Option 1: Use original metamodel as is, and cover it with the concrete textual syntax – Simple, direct mapping– But: rigidity might lead to unusable/synthetic
grammars, especially if the original metamodel was oriented towards supporting a graphical notation
• Option 2: Let the grammar produce the metamodel (à la Xtext), and then use model transformations– More flexible, allows syntactic sugar– But: needs a (maintainable) transformation
• Option 2 for TGRL, especially for multiple representations of links between elements
SDL 2015 – p. 14
Challenge 4: Technology Selection
• Linked to Challenge 3, and to discussion of related work• Choice influenced by ease with which a grammar can be
produced, and by the usability of editors• For TGRL: Xtext was selected, with a transformation to
the URN/jUCMNav format. Transformation sub-problem:– Option 1: Model (Xtext-generated metamodel) to
model (URN/jUCMNav), e.g., with Java or ATL– Option 2: Model (Xtext-generated metamodel) to
text (jUCMNav file format in XMI), e.g., with Java or Xtend or Acceleo
– Explored option 2 with Acceleo for TGRL
SDL 2015 – p. 15
Challenge 5: Handling Restrictions and Rules
• Coming from the abstract syntax (metamodel + well-formedness constraints) and (new) concrete textual syntax– E.g., format and management of identifiers,
avoidance of cyclical inclusions/definitions…• Again, this affects the usability of the editors, especially
for auto-completion and useful error messages• Technology dependent:
– Checking the existence of referred elements can be handled directly by Xtext
– However, checking for (link) duplicates needs to be implemented manually
SDL 2015 – p. 16
Challenge 6: Synchronizing Textual and Graphical Models
• Need to decide if this is needed. If so:• Option 1: synchronous approach
– Both representations are refreshed continuously – Implies some sort of MVC pattern
• Option 2: asynchronous approach– On-demand transformation from one representation
to the other– Might be simpler if existing graphical tool does not
easily support external synchronization• For TGRL: we used an asynchronous approach, in one
direction only for now (TGRL to jUCMNav file + autolayout)
SDL 2015 – p. 17
TGRL: A Textual Syntax for GRL
SDL 2015 – p. 18
A Simple Example
SDL 2015 – p. 19
Main Structure and Comments
SDL 2015 – p. 20
grl SDL2015 {
// A Graphical Model comment comment "This is a simple TGRL model"; /* * textual modeling comment */
}
TGRL: Actors
SDL 2015 – p. 21
grl SDL2015{
actor User;
actor Developer { }
actor System { } }
TGRL: Intentional Elements
SDL 2015 – p. 22
grl SDL2015 { actor User { softGoal EasyToUse { name="Have a system that is easy to use"; importance = 100; } indicator LowLearningTime; // Indicator definition } actor Developer { softGoal ReuseComponents {importance=100;} } actor System { goal SomeFunctionality {importance=high; decompositionType=or;} task FirstOption {metadata stereotype="SomeValue";} task SecondOption {description = "Better alternative";} } }
TGRL: Element Links
SDL 2015 – p. 23
actor User { softGoal EasyToUse; indicator LowLearningTime;
LowLearningTime contributesTo EasyToUse {name=C2;help;};}actor Developer {softGoal ReuseComponents; }actor System { goal SomeFunctionality; task FirstOption; task SecondOption; SomeFunctionality decomposedBy FirstOption, SecondOption; FirstOption contributesTo Developer.ReuseComponents {75;};} System.FirstOption contributesTo User.EasyToUse {hurt;}; System.SecondOption contributesTo User.EasyToUse {name=C1;60;}; link mustUse; // Link type definitionUser mustUse System; // Link instance between two actors
TGRL: Evaluation Strategies
SDL 2015 – p. 24
strategy SelectFirst { System.FirstOption = satisfied; User.LowLearningTime = {unit="minutes"; target=30.0; threshold=60.0; worst=120.0; eval=90.0;}}
strategy SelectSecond extends SelectFirst { // Strategy inclusion! System.FirstOption = none; // Overridden System.SecondOption = 100; // Added, quantitatively this time}
strategy RangeExample extends SelectFirst { System.FirstOption = {start = 10; end = 40; step = 5;}}
strategyGroup MyGroup includes SelectFirst, SelectSecond, RangeExample;
TGRL Editor
• Eclipse plugin • Open source
(https://github.com/vahdat-ab/TGRL)• Developed with Xtext• Supports syntax highlight, an outline
view, annotation of syntactic errors, content assistance, and code formatting
SDL 2015 – p. 26
TGRL Transformation
• Transforms TGRL models to URN/jUCMNav models
• Model-to-code transformation (implemented with Acceleo)
• Not handling the layout; relies on jUCMNav’s autolayout
SDL 2015 – p. 27
Conclusions
• Identified six important challenges to consider when adding a textual syntax to a metamodel-based languages primarily supported by a graphical syntax
• Illustrated a new textual syntax for GRL, called TGRL, with a full coverage of the language– Simpler support for indicators, strategies, and
contribution overrides in model creation• Developed a feature-rich Eclipse-based editor with
transformation to jUCMNav
SDL 2015 – p. 28
Future Work
• Explore other such languages (e.g., URN’s UCM) to validate challenges and identify new ones
• Further usability validation of TGRL and the tools• Transformation from jUCMNav to TGRL (or develop
a synchronized textual and graphical tool)• Explore modularity of goal models• Could lead to a contribution to the URN standard• Do similar challenges exist in the absence of a
metamodel?• Does adding a graphical syntax to a language with
only a textual syntax lead to similar challenges?
SDL 2015 – p. 29