Textual Predefined Language

Because of the need for such content creation operations, free-text editors were preferred to projectional editors for many years. In the early days of syntax directed editing, Bernard Lang, for example, stated in [149] that the user interfaces of the tools are too complex for inputting programs or per- forming simple editing tasks. They, however, see strengths in maintenance operations executed on programs stored in a projectional programming envi- ronment. Voelter et al. identify several more drawbacks and classify them in [233]. They then demonstrate that modern projectional editors such as Jet- Brains MPS can overcome these drawbacks. Amongst other things, JetBrains MPS applies a hybrid projectional / free-text editing approach in which a user can start to write arbitrary text which is over time parsed into the underly- ing model. This enables scenarios such as copying model snippets represented in plain text into the modeling environment. Another modern projectional editing workbench demonstrating the power of the approach is the Intentional Domain Workbench [115].

In this thesis, the projectional approach to textual modeling was chosen to support multi-format editing since the advantages of directly editing the abstract syntax through text far outweighs the usability drawbacks in this scenario.

5.2

Textual Predefined Language

The textual, predefined language used to visualize deep models is inspired by the MetaDepth language developed by de Lara et al. [50, 167] which is a deep version of the OMG’s Human-Usable Textual Notation (HUTN) [178]. The main modifications made to this syntax are the addition of: 1. durability and mutability to attributes, 2. generalization sets and 3. the containment relationship between clabjects. Since the complete integration of MetaDepth was not a goal of this thesis, rather than giving a full specification of its grammar this section provides only a brief example-based introduction to its concrete syntax.

Even though the predefined textual syntax presented here is based on the MetaDepth language there are significant differences between MetaDepth and the LML supported deep modeling approach. For example, MetaDepth

does not support mutability, the definition of methods inside clabjects and declaring clabjects as abstract by setting their potency to zero. Additionally, it has a slightly different classification semantics and features concepts such as leap potency which are not available in the LML modeling approach. A more detailed description of MetaDepth is available in [50] and the differences between the two deep modeling approaches are outlined in [12].

Figure 5.3 shows the additions to MetaDepth’s concrete syntax to support the LML deep modeling approach described here. The top half of the figure shows a clabject, identifier, inheriting from (supertype)identifier and connected to (target)identifierusing the diagrammatic LML notation. The bottom half of the picture shows the same model but in the MetaDepth inspired language adopted here. The model is visualized using a small pseudo grammar in which static text is written in single quotation marks (“ ’ ”) and linguistic trait values derived from the metamodel are enclosed in square brackets (“[ ]”). A choice between two representations is represented by the pipe symbol (“|”), e.g. “’A’|[B]”. Some linguistic trait identifiers that retrieve data from the model occur more than once in Figure 5.3, hence, they are made unique by putting a string in round brackets before them (“( )”).

As shown in the bottom of Figure 5.3, in MetaDepth a clabject is de- fined by the keywordNodeif it does not have an ontological type followed by its identifier. If a clabject does have one or more ontological types, all (classi- fier)identifiersare listed in a comma-separated list instead of theNodekeyword. The identifier is followed by a colon and the(supertype)identifiersif the clabject has any supertypes. Then the potency of the clabject is defined with a lead- ing @sign. The contents of a clabject, such as attributes, methods and other clabjects, are enclosed in curly brackets.

Attributes are defined through their(attribute)namefollowed by the@sign and theirdurabilityfollowed by a comma followed by theirmutability. Then the

datatype is separated from the durability and mutability by a colon followed by an equals sign and thevalueof the attribute. Methods are represented first by their(method)namefollowed by a pair of round brackets, theirpotencyindicated by a leading@, and theirbody surrounded by curly brackets. Connections in which a clabject participates are represented through the [(t)moniker] located at the opposite end of the connection, followed by a colon and the name of

5.2. Textual Predefined Language

[(attribute)name][durability]_{:[datatype]=[value]}[mutability]

[identifier][potency]_{:[(classifier)identifier]} [(method)name]()[durability]_{:[returnType]}

'Node'|[(classifier)identifier] [identifier]':'[(supertype)identifier]'@'[potency]'{' [(attribute)name]'@'[durability]','[mutability]':'[datatype]'='[value] [(method)name]'()@'[durability]':'[returnType]'{'[body]'}' [(t)moniker]':'[(target)identifier]'['[(t)lower]','[(t)upper]',''container'|'aggregate'|''']' 'Node'|[(classifier)identifier] [identifier]':'[(supertype)identifier]'@'[potency]'{'...'}' '}' 'Edge'|[(conclassfier)identifier] [(con)identifier]':'[(consupertype)identifier]'@'[potency] '('[(s)moniker]'.'[identifier]'[''>'|'X'',''composition'|'aggregation'|''','[(s)lower]','[(s)upper]']', [(t)moniker]'.'[(target)identifier]'[''>'|'X'',''composition'|'aggregation'|''','[(t)lower]','[(t)upper]']')' ' '}'

'Inheritance' [(inh)identifier] [identifier]->[(supertype)identifier]

'(' 'complete'|'incomplete'|'' ',' 'disjoint'|'overlapping'|'' ')' [(t)lower]..[(t)upper][(t)moniker] [(target)identifier][potency]

[(content)identifier][potency] [(supertype)identifier][potency]

[(con)identifier][potency]_{:[(conclassifier)identifier]} [(s)lower]..[(s)upper] [(s)moniker]

Textual Predefined

Language

LML

Figure 5.3: LML concepts in the textual predefined language.

the clabject connected via the connection end. The multiplicity is indicated in square brackets using the notation “[(t)lower]’,’[(t)upper]”. Additionally, the keywords container and aggregate can be defined if the connected clabject is contained or aggregated by the model element. Instances of contained clabjects are rendered within their owning clabject using the same syntax as if they were located in a level.

Connections, which are clabjects connecting two or more other clabjects, are represented through an extended clabject syntax. If they do not have an ontological type their representation starts with the keywordEdge, otherwise it starts with a comma-separated list of (conclassifier)identifiers. Subsequently the(con)identifier is declared followed by the list of (consupertype)identifierssep- arated by a colon from the(con)identifier. The potency is then defined with a leading@ symbol. Finally, the ends of the connection are defined in the form

[(s)moniker].[identifier], [(t)moniker].[(target)identifier]. The details of each connec- tion end are stored in square brackets in the form’>’|’X”,”composition’|’aggregation ’|”’,’[lower]’,’[upper]. The first entry in this expression specifies whether the con- nection end is navigable (>) or not navigable (X), the second entry specifies

the kind of the connection end (i.e. composition, aggregationor neither (empty string) and the last two entries specify the lower and upper cardinalities of the connection end. Connection content (e.g. attributes and methods) is enclosed in curly brackets as previously shown.

Inheritance relationships are represented by the keyword Inheritance, fol- lowed by the name of the (inh)identifier, if defined. Then all subtypeidentifiers

are listed in a comma-separated list followed by an arrow (->) and a comma- separated list of all(supertype)identifiers. Optionally, the inheritance character- istics (complete, incomplete,disjoint,overlapping) can be displayed in brackets as needed.