Adding a Textual Syntax to an Existing Graphical Modeling Language:

Experience Report with GRL

Vahdat Abdelzad, Daniel Amyot, Timothy Lethbridge

University of Ottawa, Canadadamyot@uottawa.ca

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