potency:Integer durability:Integer Method Attribute mutability:Integer * feature Level * content instanceLevel:Boolean 1 LMLVisualizer visualizer * userDefinedVisualizer attributes:Map<String,String> width:Integer height:Integer xLocation:Integer yLocation:Integer
Figure 3.1: TheLMLVisualizerandAbstractUserDefinedVisualizer.
ments made in a language. This information usually occupies the most con- crete level of a deep model. This level, however, is not necessarily created using a modeling tool but rather through a tool interpreting the model at the type level. We refer to such a scenario as model usage too because in most cases the tool creating the instance level is controlled through a tool user and thus at the same time a model user.
This gives rise to four key requirements for deep visualization: 1. A visu- alization must be definable at each level, 2. a visualization definition must be available more than one level below its definition, 3. visualizations must be refinable across classification levels, and 4. a modeler must be able to choose between the predefined visualization for defining new language concepts and user-defined visualization for using a language.
3.2
Deep Visualization
Deep visualization refers to the ability to define user-defined visualizations for model content which can be applied over an unlimited number of classification levels. Furthermore, all changes to the visualization definition have immediate effect to all classification levels without the need for deployment or compilation steps. To define visualizations so-called predefined and user-defined visualizers are attached to model elements. Figure 3.1 shows an excerpt of the PLM with an enhancement allowing the configuration of the predefined visualization and the attachment of user-defined visualizations. In this version of the linguis- tic metamodel each linguisticElementhas a predefinedLMLVisualizerattached. This visualizer drives the predefined LML visualization of deep-models. The
theLMLVisualizeris attached to. The key identifies the trait to be visualized and the value represents the configuration for this trait. The configuration values are: 1. default —the default visualization of the trait, 2. noshow — the trait is not shown (i.e. hidden), 3. show — no elision rules are applied for the trait (e.g. hide durability if equal to clabject potency) and 4. tvs — show the trait in the so-called trait value specification underneath the clabject’s designator. In the case of Clabject, for instance, the attributes map contains a key/value pair for name andpotency. Detailed specifications of the predefined diagram- matic LML notation used for visualization of deep models can be found in [27, 89]. Besides the trait visualization, the location (xLocation,yLocation) and size (width, height) of the attached model element is stored in the predefined
LMLVisualizer.
It is possible to replace the predefined visualization with a user-defined vi- sualization. AbstractUserDefinedVisualizersspecifying such a user-defined visual- ization can be attached to theLMLVisualizerfor this purpose. When visualizing a model element at a specific ontological level an algorithm is applied to search for the visualization of the model element in question. This algorithm is called the visualizer search algorithm.
Espinazo-Pagán et al. [76] introduced the first visualization search al- gorithm for searching user-defined visualizations in the domain of two-level user-defined modeling languages. This algorithm was proposed in the context of textual user-defined languages for metamodels (e.g. Ecore, MOF). When visualizing a metamodel instance, the algorithm searches the classification hi- erarchy and the inheritance hierarchy of the instance’s types for visualization descriptions. The algorithm was further improved to support deep models and the orthogonal classification hierarchy by Atkinson et al. in [26] with a focus on diagrammatic languages.
This deep form of the visualization search algorithm starts searching for a visualization at the clabject to be visualized, then searches its supertypes. If no visualization is found, the ontological types of the clabject to be visualized and their inheritance hierarchy are searched. This algorithm is applied recursively over all classification levels until the most abstract ontological classification level is reached. If no user-defined visualization is found at this level, the predefined LML notation is used as a backup for visualization. It is also
3.2. Deep Visualization
possible to mix domain-specific and general purpose renderings in one view on a model, as described for the first time by Atkinson et al. in [17]. The deep visualization search algorithm was first implemented by Gerbig in [8, 89] as part of the work presented here.
Data: elementToVisualize;
Result: A visualizer suitable for visualizing elementToVisualize 1 types ← elementToVisualize;
2 classification: while (type ← types.poll()) 6= null do 3 types ← types ∪ type.getDirectTypes();
4 superTypes ← type ∪ type.getDirectSupertypes();
5 inheritance: while (clabject ← superTypes.poll()) 6= null do 6 for udlVisualizer ∈ getUDLVisualizers(clabject) do 7 if applicable(elementToVisualize, udlVisualizer) then 8 return udlVisualizer;
9 superTypes ← superTypes ∪ clabject.getDirectSupertypes(); 10 types ← types ∪ clabject.getDirectTypes();
11 end
12 end
13 end
Algorithm 3.1: The basic version of the visualizer search algorithm.
Algorithm 3.1 shows the basic deep visualization search algorithm. It ex- pects theelementToVisualizeclabject as input which is either anEntityorConnec- tionto be visualized. First, theelementToVisualizeis added to thetypesqueue in line 1. Then alltypesare iterated using the loop labeled classificationin line 2. The types of the current type are added to the types queue (line 3). After- wards, the supertypes of thetypeand the currenttypeitself are added to the
superTypes queue (line 4). ThesuperTypes queue is then iterated over (line 5) and searched for a visualizer.
AllAbstractUserDefinedVisualizersof the currentclabjectin the inheritance tree are iterated (line 6) and checked if applicable with theapplicable()function. If anAbstractUserDefinedVisualizeris applicable it is returned for visualization, oth- erwise the types and supertypes of the current model element are stored in the
the inheritance hierarchies and ontological types in the following iterations. If no result is found after searching the whole ontological classification hier- archy and inheritance hierarchy, the predefined LMLVisualizer is returned for visualization by the search algorithm.
The visualization search algorithm presented here uses queues instead of lists to store the clabject hierarchies to be searched. This ensures that a breadth first search algorithm is applied and, hence, that the nearestAbstrac- tUserDefinedVisualizerin the classification and inheritance hierarchies is applied. If two visualizers are the same distance from the model element to be visual- ized the current version of the algorithm simply takes the first one discovered. It would be possible to attach concepts such as visualizer priorities to visual- izers to resolve such conflicts, but the visualizer search algorithm could still find two visualizers with the same priority and distance to the clabject to be visualized. The current version therefore aims to keep the user-defined visual- izer definitions simple so that language engineers should find it easy to define languages in such a way that only one visualization at a time is found by the visualizer search algorithm.
Data: elementToVisualize; udlVisualizer; Result: Check if a visualizer is applicable 1 if udlVislualizer.isInstanceLevel() then
2 if isSameLevel(elementToVisualize, udlVisualizer) then return false;
3 end
4 return true;
Algorithm 3.2: The basic version of the visualizer search algorithm’sappli- cablefunction.
The basic version of the applicable function applied to user-defined visu- alizers is shown in Algorithm 3.2. The function expects the elementToVisu- alize (either anEntity or Connection) and the candidate user-defined visualizer (udlVisualizer) as input. It then checks whether the latter is applicable to the for- mer. In the current version of the function applicable means to check whether theinstanceLevelattribute is set to true and theelementToVisualizeis on the same level as theudlVisualizer. If this is the case, the applicable function returns false because the instanceLevel attribute makes a visualizer applicable to instances
3.2. Deep Visualization O1 EmployeeType0 name2 expertise2 salary2 [name] [salary]';'[expertise]
Online Marketing Employee
35k;Marketing 35k;Computer ScienceWebshop Admin O0 BusinessEmployeeType2 TechnicalEmployeeType2 [name] [salary]';'[expertise] Employee0 O2 Bob;65k Jim;32k [name]';'[salary] [name]';'[salary] 2) 2) 3) 4) name1 expertise1 salary1 1) 1)
Figure 3.2: A run of the visualization search algorithm for Bob and Online Marketing Employee.
only. In all other cases theapplicablefunction returns true.
A run of the basic visualizer search algorithm shown in Algorithm 3.1 is demonstrated on the company structure modeling language example in Fig- ure 3.2. For demonstration purpose a notation close to the ArchiMate icon notation is chosen even though the box notation, visualizing model elements as boxes with the icon located in the box’ upper right, is more popular. The icon notation, however, is visually more distinctive. The figure shows the trace of a request to visualizeOnline Marketing Employee and one to visualizeBob. The dashed arrows with a number attached indicate the order in which nodes are visited by the search algorithm. User-defined visualizers are attached to clab- jects using a cloud symbol. The visualizers are defined using instances of a format-specific visualizer metamodel, here the diagrammatic format indicated by theDin the upper right of each cloud. However, to simplify the figure the intended visualization is shown graphically using the intended user-defined vi- sualization in Figure 3.2 instead of using object specifications based on the
diagrammatic user-defined visualization definition metamodel. Text in brack- ets represents a mapping of an attribute’s value to a label while text enclosed in single quotation marks represents a label containing static, unchangeable text. Dashed clouds indicate that theinstanceLevelattribute of the visualizer is set to true and is thus not applied to clabjects residing at the same ontological level as the visualizer. When these rules for user-defined visualizer definitions are applied toEmployee, instances of Employeesare visualized as stickmen with the value of thenameattribute followed by a colon and the value of the salary attribute displayed underneath the stickman icon. The visualization, however, is only applied to instances of Employeebecause the dashed border of the cloud representing the visualizer indicates that the instanceLevel attribute is set to
true.
In the case of Bob, the visualizer search algorithm first looks at Bob it- self for a suitable visualization. Bob, however, has no user-defined visualizer attached. Next the visualization search algorithm looks at the supertypes of
Bob for a suitable visualizer. As Bob does not participate in any inheritance relationships and, thus, does not have any supertypes this step is skipped by the visualization search algorithm. The search at the ontological types follows the search of the supertypes. Bob has one ontological type, Webshop Admin, which can be derived from its visualization. This ontological type has a vi- sualizer attached which visualizes its instances as a stickman with a wrench in the upper right-hand corner. Below the stickman, thenameattribute value followed by a semicolon and the salary attribute value of the Webshop Admin
are displayed. The visualizer search algorithm terminates after two steps once this user-defined visualizer for the visualization of Bob has been applied.
The second visualizer search algorithm trace forOnline Marketing Employee, as displayed in Figure 3.2, involves more steps than the search for the user- defined visualization of Bob. First the visualizer search algorithm searches
Online Marketing Employeeitself for a visualizer but does not find one attached. The supertypes (here the abstractEmployeeclabject) are then searched for vi- sualizers. Employeedoes have a visualizer attached which has theinstanceLevel
attribute set to true as indicated by the dashed border of the cloud repre- senting the visualizer. Thus, because Online Marketing Employee and Employee