The predefined diagrammatic visualization for deep models is shown in Fig- ure 4.1. The visual language used as predefined language is the LML as pre- sented in [27, 89, 127]. The LML reuses as many concepts as possible from established modeling languages such as the Entity-Relationship (ER) model- ing language [45] and the UML [182] but extends the concrete syntax of these languages in a level-agnostic way. The main goal of the LML is to use a uni- form visualization for the type and instance facet of a concept in the problem domain. This stands in clear contrast to the UML [182] which uses different visualizations for model elements depending on whether their type or instance facet is represented in a model. In the UML, types are represented by the con- crete syntax for classes while instances are represented by a modification of the class’ concrete syntax referred to as instance specifications. Other examples of this distinction in the UML are attribute (type level) and slots (instance level) or association (type level) and link (instance level).
The LML has three basic concepts: 1. entities with their attributes and methods (Figure 4.1(a)), 2. connections with attributes, methods and asso- ciated connection ends (Figure 4.1(b)) and 3. generalizations (Figure 4.1(c)). Entities are visualized using the widely known UML concrete syntax for classes. Theidentifierof an entity is a string positioned at the top of the box represent- ing the clabject. Optionally, instead of a simple name, complex statements indicating inheritance, location and classification hierarchies can be specified using deep model element designation as presented in [10]. Next to theidentifier
the potency of the clabject is displayed using the superscript (potency) nota- tion. Below the identifier, a list of linguistic attributes and their values can be displayed within square brackets, for example, to make trait values more explicit to a modeler. This section is referred to as the trait value specifica-
tion (tvs) based on the name given to linguistic attributes — traits. The first
compartment of an entity displays its attributes. In Figure 4.1(a) the example attribute is called id. The name of the attribute is followed by its durability,
1 in the example, its datatype if defined (here String), its value (here ’123’) and the mutability displayed next to the value using potency notation, 1 in the example. In order to promote readability and reduce the amount of infor-
4.1. Diagrammatic Predefined Visualization id1:String='123'1 identifier1 getId(p:String)1:String [potency=1] (a) 0..* moniker ~1 (b) complete;disjointidentifier (c) (d)
Figure 4.1: Visual concepts of the level-agnostic modeling language.
mation displayed in the LML, elision rules can be applied to hide information which can be derived from the model context. For example, durability of an attribute can be hidden if it is the same as the containing clabject’s potency and the mutability can be hidden if it is equal to the attribute’s durability.
The second compartment of an entity contains the operations describing the behavior of the entity. In the example an operation namedgetIdis contained by the entity. An operation’s parameters are displayed in round brackets. They are defined through their name followed by a colon and the indication of their data type. In the example one parameter namedpof typeStringis defined for the operation getId. The parameter definition is followed by the operation’s durability in potency notation followed by a colon and the return type of the operation, here String. Again elision rules are applied to the durability of operations. In case that the durability is equal to the clabject potency it is hidden.
Model elements which are owned by an entity are represented in the final compartment which is blank in Figure 4.1(a). These can be entities, connec- tions and inheritance relationships. Again, elision rules can be applied to hide empty compartments if they do not contain any information.
The notation for connections is inspired by the ER notation in which re- lationships are represented as diamonds to which attributes can be attached in the form of ellipses. The UML supports this diamond notation for associ- ations, too, but it is usually only used for higher-order associations. In the UML, association’s can be given features using the association class concept. Association classes are presented using a class symbol connected to the asso- ciation via a dashed line. In LML all connections are essentially association classes, in contrast to the UML which distinguishes between associations and association classes.
Figure 4.1(b) shows a connection rendered in the LML. This connection has no name given (∼) and a potency of 1. The example connection does not own any attributes, operations or model elements and, hence, the correspond- ing compartments can be hidden for space reasons. Attributes, operations and owned model elements are visualized in the same way as within entities shown in Figure 4.1(a). A connection is connected with other clabjects (i.e. entities and connections) via connection ends, represented as solid lines. Four kinds of connection ends exist: 1. composition (filled diamond line decora- tion), 2. aggregation (not filled diamond line decoration), 3. navigable (arrow line decoration), and 4. not navigable (no line decoration). Monikers naming the connection ends and multiplicities are attached as strings to the connec- tion end that they name or constrain as seen in Figure 4.1(b). A detailed description of connections supported in LML is found in [20, 97].
Generalizations (Figure 4.1(c)) are visualized as rectangles with a curved top and bottom. An identifier can be placed within the shape together with statements about properties of the associated generalization sets —complete,
incomplete,disjoint,overlapping. These properties cover the same semantics as in the UML [182] and are, hence, not further described here. A generalization can be connected with an unlimited number of super- and subtypes. A supertype is indicated by a line decorated with a non-filled triangle while a subtype ending has no line end decoration.
Connections and generalizations can alternatively be represented in an im- ploded form as shown in Figure 4.1(d). In this form the node in the middle of the connection is replaced by a small black rectangle about the size of the lines it is connected with. This feature called dotability [127] is very useful for reducing the space used by generalizations and connections which do not pro- vide additional information (e.g. attributes) to be rendered inside the exploded form.