1. Adding a Textual Syntax to an Existing Graphical Modeling Language: Experience Report with GRL Vahdat Abdelzad, Daniel Amyot, Timothy Lethbridge University of Ottawa, Canada damyot@uottawa.ca SDL 2015, Berlin, October 13

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

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

4. GRL Metamodel (Partial 1/2) SDL 2015 – p. 4

5. GRL Metamodel (Partial, 2/2) SDL 2015 – p. 5

6. URN for Legal Compliance and Regulatory Intelligencep. 6 Navigator view Outline view Editor Scenarios and Strategies view Properties view Toolbar Palette http://softwareengineering.ca/jucmnav/

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

8. 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!

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

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

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

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

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

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

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

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

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

18. TGRL: A Textual Syntax for GRL SDL 2015 – p. 18

19. A Simple Example SDL 2015 – p. 19

20. Main Structure and Comments SDL 2015 – p. 20 grl SDL2015 { // A Graphical Model comment comment "This is a simple TGRL model"; /* * textual modeling comment */ }

21. TGRL: Actors SDL 2015 – p. 21 grl SDL2015{ actor User; actor Developer { } actor System { } }

22. 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";} }

23. 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 definition User mustUse System; // Link instance between two actors

24. 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;

25. TGRL: Contribution Overrides SDL 2015 – p. 25 contribution FirstOverride { System.C1 = 30; User.C2 = make; } contribution SecondOverride extends FirstOverride { System.C1 = {start = -40; end = 0; step = 10;} } contributionGroup SomeOverrides includes FirstOverride, SecondOverride;

26. TGRL Editor Eclipse plugin Open source (https://github.com/vahdat-ab/TGRL)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

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

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

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