Multi-level modeling tools provide inherent support for modeling domain scenarios with multiple classi cation levels. However, as the success of domain-speci c modeling tools illustrates users increasingly expect to be able to visualize models using domain-speci c languages. It is relatively straightforward to support this using traditional \two-level" modeling technologies, but many of the bene ts of multi-level modeling would be lost. For example, in a multi-level context it is not only desirable to de ne concrete syntax that is applicable over more than just one instantiation level, it should also be possible to customize the visualization of model elements as they become more specialized over instantiation and inheritance levels. In this paper we present an approach for multi-level concrete syntax de nition which addresses this need by using aspect-oriented principles to parametrize the visualization associated with model elements. We also explain how this is implemented in the Melanee deep modeling tool.
Since concrete syntax de nition is one of the core foundations of domain-speci c,
model-driven development a large number of tools supporting this capability are
available today. Important examples include MetaEdit+ [
Deep modeling has the potential to address this problem because it inherently supports multiple classi cation levels. However, some challenges need to be addressed to support e ective level-spanning concrete syntax de nition and application within a deep modeling environment. The most signi cant is to nd a suitable tradeo between the need to de ne common syntax elements that are suitable across multiple levels whilst providing the exibility to customize the common syntax elements as and where needed. In other words, the most significant challenge is to allow the concrete syntax used to visualize model elements to re ect the specialization that inherently takes place in the instantiation and inheritance hierarchies in a deep model.
The Melanee [
The remainder of this paper is structured as follows: In the next section (Section 2) the underlying deep modeling approach is introduced. Section 3 then introduces the concept of aspect-oriented concrete syntax de nition while Section 4 presents pragmatic observations made during the use of the approach in three di erent domains. The paper closes with conclusions (Section 5). 2
The most widely implemented deep modeling architecture is the orthogonal classi cation architecture shown schematically in Figure 1. Its most obvious di erence to the traditional linear modeling infrastructure of the UML is that there are two \orthogonal" classi cation dimensions. One dimension, the linguistic classi cation dimension, is represented by the vertical stack of levels labeled L2 to L0, and the other dimension, the ontological classi cation dimension, is represented by the horizontal stack of levels labeled O0 to O2.
The linguistic levels essentially capture the organization of the model information from the perspective of how deep modeling is realized in a meta-modeling framework such as EMF. The top most linguistic level (L2), contains all language constructs available in the deep modeling language, while the middle level (L1) contains the user-modeled domain languages and is thus often referred to as the domain level. The ontological dimension, in turn, consists of \ontological" levels which are stacked horizontally within L1. Each model element at this level is classi ed by exactly one model element at level L2, indicated by vertically dashed classi cation lines. The lowest level, L0, contains the real-world concepts modeled by L1. The light bulb represents the concept of EmployeeType which captures the common properties of all employees. The group of stick-men with a wrench L2 L1 L0
* Clabject content potency O0
EmployeeType2 expertise2=1
name
* feature durability in the upper right instantiates this concept as WebshopAdmin (a particular type of employee) which is then further instantiated as Bob (a particular instance of a WebshopAdmin). Classes located in the middle levels (e.g., WebshopAdmin) are instances of the classes at higher levels and types for the classes at the lower levels. Hence, they are named \clabjects" which is a concatenation of the terms \class" and \object".
The domain level, L1, consists of three ontological levels O0 to O2 which are intended to represent the domain concepts/objects. Even though three levels are shown here, the number of levels available is not limited. The concrete syntax used in Figure 1 looks similar to the UML but with some modi cations to make it level-agnostic. Ontological classi cation is shown using horizontal dashed lines or the UML colon notation as used in object speci cations (e.g. Bob). The most important di erence to the UML is the association of numerical values with clabjects, attributes and attribute values in the form of superscripts after their names. Depending on whether they are associated with clabjects, attributes or attribute values they are respectively referred to as \potency", \durability" or \mutability". The potency speci es over how many subsequent ontological classi cation levels a clabject can be instantiated and thus in uence the contents of a deep model. In the example EmployeeType has a potency of two stating that it can be instantiated at the following two levels, here WebshopAdmin with potency one and Bob with potency zero. The durability displayed next to the name of an attribute indicates over how many subsequent instantiation steps an attribute endures. In the example, expertise has a durability of two so all o spring of EmployeeType over the next two levels have to possess such an attribute, here WebshopAdmin and Bob. Finally, the mutability displayed next to the value of an attribute de nes over how many levels the value of an attribute can be changed. The mutability for expertise of EmployeeType is one, hence it can be changed at the next instance level and is xed from then on. On level O1 of the example the expertise for all WebshopAdmins is set to Linux which means that instance Bob has to have Linux as his expertise.
Aspect-oriented concrete syntax de nition employs concepts from aspect-oriented
programing languages [
The meta-model supporting the aspect-oriented de nition of graphical concrete syntax in Melanee is shown in Figure 2. The model is unique for each type of concrete syntax format (e.g. graphical, textual, tabular etc.) to best t the needs of that particular format. Here, for space reasons, the approach is explained only in the context of graphical concrete syntax de nition, but Melanee supports the approach for other formats as well. Melanee's algorithm for visualizing model elements is designed in such a way that it can be con gured to work with any concrete syntax de nition model that supports the join-point and aspect concepts explained below. GraphicalDSLVisualizer 1 content VisualizationDescriptor * name:String
ConditionalDescriptor condition:String
LayoutDescriptor
1 * content LayoutContentDescriptor name:String * content
1
Aspect kind:Aspect={around,=before,=after}
In Melanee any model element can have multiple AbstractDSLVisualizers attached, de ning the concrete syntax in a speci c concrete syntax format. The notation attribute groups visualizers from the same format into \notations" so that families of symbols can be grouped into a given logical \notation". The instanceLevel attribute speci es whether a visualizer is applied only to the instance level or to the level at which the visualizer is de ned as well. The GraphicalDSLVisualizer shown here de nes concrete syntax in a graphical format using VisualizationDescriptors. This is the base class for all types of elements in a concrete syntax de nition. It assigns a name to each element of a concrete syntax de nition making each of those potential join-points. To explicitly declare an element as a join-point a unique name has to be assigned to it. A concrete syntax de nition consist of three types of VisualizationDescriptors: LayoutDescriptor , LayoutContentDescriptor and Aspect. A LayoutDescriptor describes the layout which is applied to layout content (e.g. table layout, ow layout etc.). A LayoutContentDescriptor , which is contained by a LayoutDescriptor , describes the actual displayed O1 2) 1) 3)
EmployeeType0 name2 expertise2 salary2 name salary';'expertise
G name BusinessEmployeeType2 TechnicalEmployeeType2 salary';'expertise
Employee0
G name; salary
G name; salary (a) O1
EmployeeType0 name2 expertise2 salary2
JC JAG
name JB salary';'expertise 3) 4) BusinessEmployeeType2 TechnicalEmployeeType2 JA <around>G= 2) 1)
Employee0
JC <around> = G
JB <around> = name; salary 2)
3) 1) Webshop Admin
35k; Computer Science (b) Online Marketing Employee
35k; Marketing O2 1)
Webshop Admin 35k; Computer Science
Online Marketing Employee
35k; Marketing
O2 Jim; 32k
Bob; 65k
Jim; 32k
Bob; 65k shape such as a rectangle, circle, label mappings etc. By nesting these two concepts any concrete syntax can be de ned as desired. The language is designed to be similar to well known languages for describing UIs such as the Standard Widget Toolkit (SWT), and languages describing concrete syntax for diagrams such as the Graphical Modeling Framework (GMF).
Aspects for join-points are provided by the Aspect model element which inherits the condition attribute from ConditionalDescriptors which are executed when the condition holds true. Aspects are not only ConditionalDescriptors they are also subclasses of VisualizationDescriptor so that they can be added to GraphicalDSLVisualizers. The kind attribute de nes the application strategy of the advice (content) of the Aspect. Three kinds are available { before (adding the content before), after (adding the content after) and around (replacing the content of the join-point). The current meta-model limits the content of an aspect to be LayoutContentDescriptors. However, this does not limit the expressive power of the model.
Based on the visualizer and aspect-oriented concrete syntax de nition
approach a special search algorithm is employed to generate the desired
visualization for each model element in a deep model. This is based on an algorithm for
two-level models [
Figure 3 shows an example of the \Employee" language with concrete syntax attached to model elements indicated by clouds. The concrete syntax de nition uses the meta-model of Figure 2. The order in which clabjects are visited when searching for a model element visualization is indicated by dashed arrows annotated with a number. The search algorithm starts searching at the level of the clabject to visualize. First the clabject itself is visited to determine whether it has an associated visualizer, if not the clabjects in the inheritance hierarchy of the clabject are visited. If no visualizer is found at this level the types of the clabject at the level above are visited. The search continues until a suitable visualizer is found for the clabject. If none is found the pre-de ned concrete syntax is used to render the clabject.
The example in Figure 3(a) shows the \aspect-unaware" search trace of the algorithm for Bob and Online Marketing Employee. Bob has no visualizer attached, so the algorithm visits WebshopAdmin, the type of Bob, which has a visualizer attached. The algorithm stops, returning the stick man icon with a small wrench in the upper right. To nd a suitable visualizer for Online Marketing Employee its supertype (Employee) is visited which contains a visualizer. However, because its instanceLevel attribute is set to true (indicated by the dashed cloud) the algorithm continues searching the type level. The direct type, BusinessEmployeeType, has no visualizer but its supertype (EmployeeType) has. Hence, the search terminates and returns the group-of-stickmen icon to visualize Online Marketing Employee.
Figure 3(b) shows the same example but using aspect-oriented concrete syntax de nition. Only one visualizer is de ned at EmployeeType de ning the joinpoints (dashed rectangles) JA, JB and JC . Variations are modeled through aspects of kind around along the classi cation hierarchy, here at TechnicalEmployeeType and Employee. This focus on modeling variations only reduces the number of fully speci ed Visualizer from four in Figure 3(a) (EmployeeType, BusinessEmployeeType, Employee, WebshopAdmin) to one in Figure 3(b) (EmployeeType). The main di erence between the two search algorithm versions is that discovered aspects are collected on the way to a model element with an aspect-less visualizer and then merged into the visualizer. The trace for OnlineMarketingEmployee is identical to the aspect-unaware version as no aspects are de ned along its classi cation hierarchy. For Bob the search ends at EmployeeType and merges the collected aspects JA, JB and JC into this visualizer.
Comparing the \aspect-unaware" and \aspect-aware" approaches shows that the search algorithm traverses more model elements when applying the aspectaware variant of the algorithm. Additionally, the aspect aware version involves additional computational overhead for merging aspects into join-points, leading to a potential performance issue. The impact of this overhead has to be empirically determined by analyzing numerous practical examples. In the following section pragmatic observations about the approach are made. 4
Because of the novelty of the aspect-oriented concrete syntax de nition approach
only three languages using this features have been published to date. The rst
describes executable behavior of robots [
The model shown in Figure 4 is part of a deep robot behavior modeling and
execution framework in [
typeName3=1 platformName3=1 1 * 1cflow 1 1post JD
uses VariableType 3 * type
name
executionTime2 successful2 JC name':'type
platformName2=Nao0 * split
TypeName = 'detect_red_ball' JA = 'x='x';y='y';theta='theta JB= JB=
JD=O Or2:ControlFlowType JD=X
JD=+ O0 O1 O2
TypeNameJA JB executionTime;successful
executionTime3 successful3 1 post JA = gesture JB=
typeName= 'posture' gesture:Gestures
typeName = 'move' x:Integer y:Integer theta:Integer
Move x=4;y=2.6;theta=0.785
Detect Red Ball Agree ballDetected
not ballDetected X
Disagree
To realize the language without aspect-oriented concrete syntax de nition
features it would be necessary to de ne a complete visualizer for each model
element at level O1 (e.g. Move, XOR) even though the concrete syntax at level O1
is only a slight variation of the one de ned at O0. This unnecessary replication
of visualizers would signi cantly increase the accidental complexity involved in
developing, maintaining and evolving deep models [
In contrast to the previous example where the customization takes place along the classi cation hierarchy, in Figure 5 aspect-orientation is used to model concrete syntax variations in an inheritance hierarchy. The example shows a model for a game environment with a focus on how the inheritance hierarchy is used to determine the concrete syntax of Weapons in an aspect-oriented style. At the center of each Weapon symbol is an icon indicating the type of weapon (e.g. Shuriken). The character at the top right of the symbol indicates the weapon kind (A: AttackWeapon; D: DefenseWeapon) and the text at the bottom gives the name and details of the weapon such as regeneration information. The only common part of all weapon visualizations is the information at the bottom. The weapon kind and type change per subclass. To optimize the concrete syntax de nition, only the weapon details at the bottom are de ned in the visualizer associated with Weapon along with two join-points | one for weapon type (JT ) and one for weapon kind (JK). The weapon kind is associated with the AttackWeapon and DefenseWeapon subclasses since it is xed for all of their subclasses. On the other hand, the weapon types which change for each weapon are de ned locally at Telekinesis, Rocket, etc. The lowest level O2 shows an instance of a modeled game environment which can be executed. Again the aspect-oriented concrete syntax de nition reduces the number of elements involved in concrete syntax de nition as only variations are modeled instead of the whole concrete syntax.
In the examples presented so far, aspect-oriented concrete syntax de nition is used to reduce accidental complexity. Figure 6, however, shows a scenario that cannot be supported without this mechanism. It contains three packages created by independent parties and distributed over the internet | 1. BPMN: providing a business process modeling language, 2. MDPE : supporting modeldriven performance analysis and 3. Security : supporting business process security modeling.
O0
JA=threshold
JB=L O1
MDPE @http://example.org/mdpe
LatencyTask2 threshold2
BPMN @http://example.org/bpmn
Task2 taskName2=1
JTAypeNamBe
J MDPE @http://example.org/mdpe
1:LatencyTask threshold1= '10 minutes' SelectWineToBeAddedForFree1:Task
Security @http://example.org/security
SecurityTask 2 valueGain 2 Security @http://example.org/security 1:SecurityTask valueGain1= '200' (1) (2) (3) (4)
JA=valueGain JB=S 10 minutes SelectWineToBe AddedForFree
L
SelectWineToBeAddedForFree1 :Task, SecurityTask, LatencyTask threshold1= '10 minutes' valueGain 1= '200'
SelectWineToBe AddedForFree 200 SelectWineToBe AddedForFree
S
The BPMN language was de ned with modeling language and concrete syntax extension in mind. To enable the latter, join-points JA and JB are de ned in the concrete syntax de nition of Task. These two are used by the LatencyTask and SecurityTask subclasses from the MDPE and Security packages linked to the BPMN package. They introduce new language constructs into the BPMN language and extend the concrete syntax. The rectangle at O1 contains a detailed view of one Task which is an instance of Task, LatencyTask and SecurityTask for demonstration purposes. In a real model, however, this would be shown as one model element with multiple classi cations. The four rendering options for this model instance, which it is possible to switch between on-the- y, are shown at the bottom of Figure 6. This example shows how distributed deep models can enhance each others concrete syntax de nitions in a decoupled style by using aspect-oriented concrete syntax de nition. Even though the example only shows a linking depth of one, chains of linked models which contribute towards one concrete syntax can be envisaged. 5
Deep modeling technologies not only facilitate the de nition of models that span
more than one class/instance level they also allow domain-speci c (i.e.
userde ned) modeling languages to be used to represent them. These user-de ned
modeling languages often use concrete syntax de nitions which span multiple
classi cation levels, multiple inheritance levels or even multiple models. In this
paper we have shown the potential of aspect-oriented concrete syntax de nitions
to reduce accidental complexity, positively impact model development, evolution
and maintenance, and support new modeling scenarios. The three published
languages and one running example described in this paper demonstrate the
potential advantages of the approach which is fully implemented in the Melanee
tool. The authors are not aware of any other deep modeling tool supporting
aspect-aware, concrete syntax de nition. Besides Melanee, two other deep
modeling tools explicitly support the de nition of user-de ned concrete syntax |
MetaDepth [