The visualization search algorithm in Figure 3.7 starts its search with the
Jimclabject which does not have a user-defined visualizer attached and does not have any supertypes. Hence, its ontological typeOnline Marketing Employee
is searched for a user-defined visualizer. Online Marketing Employee does not have a visualizer attached either. Its supertype, however, has a visualizer for the diagrammatic format attached as indicated by theDprinted in italics in the upper right part of the visualizer. The notation of the visualizer is printed below the format, in this casecompany. When checking the visualizer for applicability, the notation in which Jim is to be visualized is looked up. The notation of Jim is set to derived so the algorithm uses the notation of
Jim’s container, theOnline Marketing department. Online Marketing has derived
set for its notation too. Therefore, the container ofOnline Marketingis searched.
Quality Toys Inc. has derived set for its notation, but its container, levelO2, has
the diagram notation set to company. By setting the notation of level O2 to
companyall level content which has its notation set toderivedis visualized using thecompanynotation, includingJim. Since the algorithm retrievedcompanyas notation of Jim and the visualizer under investigation is applicable for the diagrammatic format and thecompanynotation, the algorithm terminates and returns the visualizer ofEmployee.
3.5
Aspect-oriented Visualization
The definition of deep modeling languages can span multiple levels as shown in the previous examples. Typically, a general language is defined at the higher levels of abstraction and then refined across the following levels. For instance, in the example used to demonstrate the visualizer search algorithm, very general concepts of workers are defined at the highest level of abstrac- tion, level O0, and refined by concepts for a specific company in the following
level, level O1. In this example, web shop administrators and online market- ing employees are introduced as company-specific types. The language is then
used to model the specific company on the lowest level, O2. This concept
of generic languages which are repeatedly refined across ontological levels is a pattern that can be observed very often in the use of deep models, e.g. in [7, 15, 21, 53, 55, 92, 113, 203]. This pattern of using domain-specific metamod-
eling languages to model other domain-specific modeling languages is referred to as domain-specific metamodeling [242]. De Lara et al. put this term into the context of deep modeling in [55]. In a three level model they refer to O0
(the most abstract level) as the domain-specific metamodeling language defini-
tion,O1 as the domain-specific modeling language definition andO2(the most
concrete level) as the model.
When defining such deep languages not only the concepts in the language are refined across classification levels but also their notations. The example in Figure 3.8 shows how the diagrammatic notation for a Webshop Admin is refined across classification levels. Figure 3.8 demonstrates how the notation from EmployeeType represented as a group of stickmen with their name, salary
and expertiseprinted at the bottom evolves to TechnicalEmployeeType, a group of stickmen with a wrench displayed in their upper right, Employee, a single stickman, and Webshop Admin, a stickman with a wrench at its upper right. To define this language using the previously described approach four visual- izers would need to be defined which differ only in minor ways as shown in Figure 3.8(a). EmployeeTypeandTechnicalEmployeeTypehave basically the same visualizer apart from the wrench in the top right of the symbol. AlsoEmployee
andWebshop Adminbasically replicate the visualizers of their types for the sole purpose of replacing the group of stickmen with a single stickman.
The problem of defining visualizers in this way is not only that a comple- mentary visualizer has to be defined even when there are only small modifica- tions to the general visualizer provided at a higher level of abstraction. Addi- tional maintenance issues arise when the general part of the notation changes and this change has to be propagated to all visualizers applying modifications manually. By applying aspect-oriented notation definition, as described in [11], these drawbacks can be overcome. The aspect-oriented notation definition fea- ture applies the concepts of aspect-oriented programming languages [130] such as AspectJ [129]. A general notation can be defined and the variable parts can be defined as join points which are configurable through aspects by assigning an identifier (i.e. name) to them. Hence, only modifications to the general notation are modeled and changes to the general notation are automatically transported to all the elements that extend it.
3.5. Aspect-oriented Visualization Bob;65k O1 EmployeeType0 name2 expertise2 salary2 [name] [salary]';'[expertise] O0 TechnicalEmployeeType2 Employee0 O2 [name]';'[salary] name1 expertise1 salary1 Webshop Admin 35k;Computer Science [name]';'[salary] [name] [salary]';'[expertise] (a) Bob;65k O1 EmployeeType0 name2 expertise2 salary2 O0 TechnicalEmployeeType2 Employee0 O2 name1 expertise1 salary1 Webshop Admin 35k;Computer Science J A<around> = [name] [salary]';'[expertise] JA JB JC J C<around> = [name]';'[salary] J B<around> = (b)
Figure 3.8: Deep notation definition without (a) and with (b) aspects.
points and aspects consisting of point cuts and advices. The parts of a gen- eral syntax which are customizable by ontological instances or subtypes in an inheritance hierarchy are declared as join points by assigning them an iden- tifier. Ontological instances and subtypes can then provide aspects for the join points. Three application kinds of aspect advices are available: 1. around, replacing the join point 2. after, placing the aspect content after the join point and 3. before, placing the aspect content before the join point. The terms
before and after in the previous description refer to the position in the con-
tainment tree relative to the join point in the visualizer which is merged with the provided aspect’s advice. In addition to the kind, aspects have a condition which has to hold true in order to apply the aspect to a join point. The place of the aspect in the inheritance and classification hierarchies, the condition and the identifier of the join point together build the so-called point cut identifying the join points to which an aspect contributes. The advice of the aspect is the contributed concrete syntax.
Figure 3.8(b) shows the same example as Figure 3.8(a) but with aspect- oriented user-defined notation applied. The diagrammatic visualizer attached toEmployeeTypedefines three join points for which aspects can provide content. These are JA to allow an icon to be placed next to the model element’s icon (stickman figure),JB to allow the text shown below the model element’s icon to be customized and JC to allow the model element’s icon to be customized. This general visualizer is then customized by TechnicalEmployeeTypeto display a wrench in the upper right of the model element’s icon, where JA is placed. The abstractEmployeeclabject further customizes this generic syntax to show a single stickman instead of a group of stickmen (JC) and to limit the text below the icon to thenameandsalaryof the employee.
A comparison of Figure 3.8(a) and Figure 3.8(b) shows that the version us- ing aspects features one visualizer less than the version not using aspects. Ad- ditionally the aspects version does not duplicate the visualizers but only models modifications. This leads to smaller, less complex visualizers and modifications made to the general syntax definition of EmployeeTypeare automatically trans- ported to all subtypes and instances. We argue that this reduction in the number of model elements needed to model the notation reduces accidental complexity [38]. The positive impact of aspect-oriented notation definition is demonstrated in two case studies [11, 21].
The modified visualizer search algorithm supporting aspect-oriented nota- tion definition is shown in Algorithm 3.5. The search algorithm is modified to check whether discovered visualizers provide a visualizer containing aspects or a visualizer providing a full visualization definition. Aspects are collected until a full visualizer is found and then merged into this visualizer. To implement this behavior a map, name2aspect, is introduced to the algorithm in line 1. This map stores the name of the join point and a list of all aspects provided for this join point. When merging the aspects into the final visualizer differ- ent strategies are applied depending on the kind of aspect. Aspects of kind
before are applied so that aspects defined at more concrete classification and
inheritance levels are merged first, whereas aspects of kind after are applied in the reverse order. In the case of aspects of kind around, only the aspect defined at the most concrete classification level for which the condition holds is applied. In addition to the mapping of join points to aspects, the behavior
3.5. Aspect-oriented Visualization
Data: elementToVisualize; helper; notation; mergeAspects Result: A visualizer suitable for rendering elementToVisualize 1 name2aspect;
2 types ← elementToVisualize;
3 classification: while (type ← types.poll()) 6= null do 4 types ← types ∪ type.getDirectTypes();
5 superTypes ← type ∪ type.getDirectSupertypes();
6 inheritance: while (clabject ← superTypes.poll()) 6= null do 7 for udlVisualizer ∈ getUDLVisualizers(clabject) do
8 if applicable(elementToVisualize, udlVisualizer, helper) then 9 aspects ← getAspects(udlVisualizer, elementToVisualize,
helper); 10 if aspects = ∅ then 11 visualizerToMerge ← udlVisualizer; 12 break classification; 13 end 14 addActiveAspectsToMap(udlVisualizer,
elementToVisualize, name2aspect, helper);
15 end
16 end
17 superTypes ← superTypes ∪ clabject.getDirectSupertypes(); 18 types ← types ∪ clabject.getDirectTypes();
19 end
20 end
21 return mergeVisualizer(visualizerToMerge, name2aspect, mergeAspects,
helper);
of the visualizer search algorithm is modified in case a visualizer applicable to the notation is discovered (line 9 - 14).
First, the aspects are retrieved from the udlVisualizer using the getAspects
operation and stored in the aspects list in line 9. The helper provided to the getAspectsoperation identifies the format-specific meta types etc. for as- pect orientation. Moving this functionality into format-specific helpers allows aspect-orientation to be implemented in a way that optimally fits a specific format. Then theaspectslist is checked to determine whether the udlVisualizer
provides aspects or not by checking if the aspects list is empty (line 10). If this list is empty the visualizer is stored as the visualizer into which all so far discovered aspects are merged (visualizerToMerge) in line 11, and the search is stopped in line 12. If theudlVisualizerprovides aspects, these are stored in the
name2aspect map using the addActiveAspectsToMap operation in line 14. This operation checks each aspect of the udlVisualizer whether the condition holds
true in the context of elementToVisualize and adds it to the name2aspectsmap. The helper passed to the function, again, handles format specificities in the notation definition metamodels. The final modification to the visualizer search algorithm is the last line, line 21, in which the merged visualizer is returned.
In line 21 the aspect-aware visualization search algorithm terminates re- turning a visualizer which is merged with its aspects by the mergeVisualizer
operation. This operation merges the udlVisualizer with aspects provided via the name2aspects map for its join points in case that it contains entries and themergeAspectsflag is set to true. Otherwise the visualizer is not merged and returned by themergeVisualizeroperation.
A run of the aspect-aware visualizer search algorithm as described in Al- gorithm 3.5 is shown in Figure 3.9 on the example of Bob. Again, the dashed arrows show the traces of the search algorithm. Join points are declared by dashed gray rectangles with a name attached to their border. For instance, the gray rectangle around the group of stickmen in the visualizer of EmployeeType
is declared as a join point namedJC. Aspects are defined in visualizers by first stating the join point name, its type (i.e. around, after, before) and then the content (i.e. advice) of the aspect. The visualizer of Employee, for example, provides an aspectJC replacing (around) the group of stickmen defined inEm- ployeeTypewith a single stickman. Visualizers providing aspects are attached
3.5. Aspect-oriented Visualization O1 EmployeeType0 name2 expertise2 salary2
Online Marketing Employee
35k;Marketing 35k;Computer ScienceWebshop Admin O0 BusinessEmployeeType2 TechnicalEmployeeType2 Employee0 O2 Bob;65k Jim;32k 2) name1 expertise1 salary1 J A<around> = [name] [salary]';'[expertise] JA JB JC 3) 4) J A<around> = 5) J C<around> = [name]';'[salary] J B<around> = J C<around> = [name]';'[salary] J B<around> = J C<around> = [name]';'[salary] J B<around> = 1)
Figure 3.9: A run of the aspect-aware visualization search algorithm forBob.
to the arrows indicating the visualizer search algorithm trace when collected for future merging by the algorithm.
The aspect-aware visualizer search algorithm trace forBobshows that first
Bob itself is checked for a visualizer. Since Bob does not have any visualizer attached and no supertypes, the ontological types of Bob are searched. Web- shop Admindoes not have any visualizers attached but its supertype,Employee
does. The visualizer provides two aspects: one for join pointJB, setting the text displayed for theEmployeeto its name and salary; and one for join point
JC, setting the figure representing theEmployeeto a stickman. These two as- pects are collected by the visualization search algorithm and the algorithm continues searching in the ontological type hierarchy of Bob, which first con- tainsTechnicalEmployeeTypeand finallyEmployeeType. TechnicalEmployeeTypehas a visualizer attached providing an aspect for join point JA which is an icon indicating thatBob is a technical employee. The visualizer search algorithm collects this aspect, too and continues its search atEmployeeType.
EmployeeTypespecifies a full visualizer which describes a visualization of the model element under investigation and does not provide any aspects. Hence,
[backgroundColor:= if(salary > 50k) then 'red' else 'white' endif]
Company Structure O2 Quality Toys Inc.
Toy Research
Name Jim Salary 42k
General Information
Jim
Delete Employee Amount 4.2k
Yearly Bonus Salary
[visible:= if(salary > 40k) then true else false endif]
Figure 3.10: The context-sensitive form-based visualization of Jim.
this visualizer is used for the visualization and merged with the collected as- pects. In this case, all aspects are of kind around replacing the join points in the visualizer description of EmployeeType. The visualization created by the aspect-aware visualization search algorithm is a stickman with a wrench at the upper right-hand side and the values of the ontological name and salary
attributes below it.
3.6
Context-sensitive Visualization
Context-sensitive visualization is a feature frequently required in the domain of model execution as described in [22]. Context-sensitive refers to the state of a model at the point of time a visualization is requested. This state is represented by the values of the ontological attributes of the model elements. Examples for context-sensitive visualization are the red coloring of a bottle neck in a business process, or the coloring of attributes when passing a certain threshold.
To realize context-sensitive visualization the notation definitions have to be enriched with constraint expressions. These expressions can for example set attributes of visualizer content, show/hide subtrees of a visualizer or change the color of notation elements.
Figure 3.10 shows a form-based visualization of Jimat its left-hand side. The right-hand side of the figure shows a context-sensitive visualization defi- nition attached to the salarytext box and the Yearly Bonus Salary group. The
3.6. Context-sensitive Visualization
definition of the context-sensitivity first shows the attribute to set and then the expression calculating the value. In the example, theSalarytext box gets a red background color in case theSalary of Jimis bigger than 50k. Also the
Yearly Bonus Salary group becomes visible for employees which have a yearly salary higher than 40k and thus qualify for a bonus.
Chapter 4
The Diagrammatic Format
Larkin and Simon [153] describe a diagram as a data structure in which infor- mation is indexed in a two-dimensional space. Moody [170] lists lines, graphic areas, 3D graphic elements, labels and spatial relationships as the graphical symbols which can be used in a diagrammatic notation. This thesis does not consider 3D graphic elements, but they could be added by extending the meta- model for defining diagrammatic concrete syntax with concepts from the 3D space. The layout of a diagram (i.e. the location of diagram content in the two-dimensional space) is referred to as secondary notation in [192] which can transport useful additional information in addition to the elements explicitly expressed in the diagram. This information can play a key role in the read- ability of a diagram. To demonstrate this, the authors of [192] show how bad layout can lead to misunderstandings of diagrams in the electric circuit do- main. Störrle [214, 215] also shows a correlation between layout quality and understanding of UML models. Moreover, Klauske and Dziobek [131] argue that their research and experience shows that in Simulink [241] up to 30% of modeling time is spent on diagram layout.The key advantage of the diagrammatic format over formats presented later in this thesis is its effectiveness in communicating relationships between model elements using spatial layout information and the visual representation of dependencies through edges. The other formats (i.e. text, table, forms) do not have such a feature for graphically representing relationships using edges and spatial information.