search further for a visualization ofOnline Marketing Employeefrom the ontolog- ical types ofOnline Marketing Employeebecause no supertypes are left to search. The ontological type ofOnline Marketing Employee, isBusinessEmployeeTypewhich does not have a visualizer attached. Hence, the visualization search algorithm continues to search the inheritance hierarchy of BusinessEmployeeType. Its su- pertype,EmployeeType, has a user-defined visualizer attached. This visualizer visualizes instances of EmployeeTypeas a group of stickmen with the value of thename,salaryandexpertiseattributes rendered at the bottom. This visualizer is then returned for visualization ofOnline Marketing Employeeby the visualizer search algorithm.
3.3
Multi-format Modeling
The format of a modeling language determines whether it is visualized in a diagrammatic, textual or tabular form etc. A multi-format editor supports modeling using different formats at the same time in a seamless manner. This means that editing in one format does not negatively impact the editing ex- perience in an other format. For instance it should not happen that editing a model in a textual format causes the diagrammatic format to lose layout meta- data for parts of the model. To support multi-format editing, the visualizer search algorithm has to be extended to find visualizers in different formats, vi- sualizer metamodels for different formats have to be present and editors which are meta-data preserving (e.g. diagrammatic layout information) have to be supplied.
A mockup of a multi-format modeling environment is shown in Figure 3.3. The left-hand side shows the user-defined company structure modeling lan- guage in a diagrammatic editor. The employees are rendered as stickmen. Five employees exist which areAllen,Tim,Jim,BobandDon. These employees are located in boxes representing the departments they work in. The three departments in this example are Online Marketing, Toy Research and Customer Service. The departments themselves are located in the Quality Toys Inc. com- pany represented by a house pictogram. The editor at the bottom of the multi-format modeling environment shows the same model in a tabular for- mat. Here the employees of the Online Marketing department are displayed
Company Structure Modeling Language Diagrammatic
Tabular - Online Marketing
Textual
Form - Allen
Allen;32k
Online Marketing Toy Research Customer Service
Tim;36k Bob;48k Don;23k
R
Jim;42k R
Quality Toys Inc.
Name Salary Expertise
Allen 32k Online Marketing
Tim 36k Online Marketing
Quality Toys Inc.{ Online Marketing{
Allen (32k, Online Marketing); Tim (36k, Online Marketing); }
Toy Research{
Jim (42k, Toy Engineer);
Name Allen
Salary Expertise
32k Online Marketing
Figure 3.3: A multi-format modeling environment.
in a tabular form. Rows represent the distinct employees and columns their corresponding ontological attributes.
The right-hand side of the modeling environment shows the company struc- ture model opened in a textual format in the upper half and in a form-based format in the bottom half. The textual syntax represents the company by its name and encloses its departments in curly brackets. The departments are represented by their name and enclose their employees within curly brack- ets. Employees are represented by their name followed by their salary and expertise in round brackets. Employees are terminated with a semicolon. The form-based format shows one selected employee, Allen. The attributes of Allen
can be edited through the text boxes holding the respective values.
In a multi-format modeling environment it is possible to use all these views on a model in different formats in an equal way. The modeling workbench does not prefer one format over another and editing in one format does not influ- ence an other format in a negative way. To enable such a multi-format editing experience a projectional approach to language editing is applied throughout all formats including the textual format. This is a derivation from the classical paradigm of editing text through parser-based technologies. In a projectional approach the user directly interacts with the abstract syntax when manip- ulating a model through the user interface (i.e. its concrete syntax). In a parser-based approach, the concrete syntax is manipulated only through the user interface and then at predefined points in time, e.g. compile or save,
3.3. Multi-format Modeling Clabject Method * feature * content AbstractWeavingLink Attribute Element Feature Level 1 abstractSyntaxElement FormWeavingLink form:Form widget:Widget TableWeavingLink table:Table cell:Cell DiagramWeavingLink editor:Editor shape:Shape TextWeavingLink editor:Editor offset:Integer length:Integer EObject
Figure 3.4: Abstraction of the weaving models underlying the projectional editors.
transformed into a model. [235]
Projectional editing is supported by model weaving [35] between the ab- stract and concrete syntax. This weaving model stores links between an ab- stract syntax element and its representation in the concrete syntax. A widely distributed example of such a weaving model is the GMF Notation Model [94] based on the OMG Diagram Interchange Specification [179].
Figure 3.4 shows an abstract version of the weaving models created for each format. In this model each AbstractWeavingLink connects an EObject through the abstractSyntaxElement reference from the PLM with its representation in the concrete syntax. By connecting to an EObject it is possible not only to connect a weaving model to instances of metaclasses (e.g. Clabject and Fea- ture) of the PLM but also to their traits (e.g. potency, durability) which are of typeEStructuralFeature inheriting fromEObject. This ability to support the editing of linguistic traits as well as ontological attributes makes it possible to support format-specific editors leveraging the ontological and linguistic dimen- sion. The subclasses ofAbstractWeavingLink have format-specific attributes for weaving an element in the concrete syntax to a model element in the abstract syntax. The TableWeavingLink stores which abstractSyntaxElement is stored in whichcellin atable. TheTextWeavingLinkstores theoffset (start position) and thelengthof the text representing theabstractSyntaxElementin a certain textual
editor. AFormWeavingLinkstores the widgetin a form representing anabstract- SyntaxElement and the DiagramWeavingLink stores which shape is representing whichabstractSyntaxElementin a certain diagrammatic editor.
When an edit operation is performed in any format-specific editor the weav- ing link is followed to the abstract syntax and changes are transported from the format-specific editor to the abstract syntax. Each change to the abstract syntax is then immediately transferred to all format-specific editors by follow- ing their weaving links from the abstract syntax to the concrete syntax of the changed abstract syntax element. By applying this edit and update procedure all formats can be edited with equal rights by one modeler.
A weaving model needs to support model manipulation operations such as editing, adding, deleting and moving model elements in both the format- specific editor and the abstract syntax model representation of the model being edited in the format-specific editor. These operations, however, are very spe- cific to the format the weaving model is being applied to. Thus, their detailed description is deferred to the subsequent format-specific chapters.
Data: elementToVisualize; udlVisualizer; helper Result: Check if a visualizer is applicable 1 if udlVislualizer.isInstanceLevel() then
2 if isSameLevel(elementToVisualize, udlVisualizer) then return false;
3 end
4 if helper.isRightFormat(udlVisualizer) then return true; 5 return false;
Algorithm 3.3: Multi-format version of the visualizer search algorithm’s applicablefunction.
The multi-format extension to the visualizer search algorithm’sapplicable
function is shown in Algorithm 3.3. The extension consists of a new format- specific helper input to the applicable function alongside the elementToVisualize
and udlVisualizer. This helper is used to configure the visualization search al- gorithm for each specific format. In this version the helper provides only one function, theisRightFormat()-function. This function takes a visualizer as input and returns a boolean value stating whether the visualizer is applicable for the format of the helper or not. This is usually done by checking whether the visualizer conforms to the user-defined visualizer meta type from the format- specific metamodel for which the helper is implemented. This helper is then used in addition to the original, format unaware algorithm, in line 4 of the
3.3. Multi-format Modeling O1 EmployeeType0 name2 expertise2 salary2 [name]([salary],[expertise]); TechnicalEmployeeType2 Bob;65k [name]';'[salary] Employee0 name1 expertise1 salary1 O2 WebshopAdmin2
[Name] [Salary] [Expertise]
Name [name] Salary [salary] Expertise [expertise] O0 2) 4) 3) 5) format=Ta format=Ta format=Ta format=Ta 1) format=Ta
Figure 3.5: A run of the format-aware visualization search algorithm forBob.
applicable-function as shown in Algorithm 3.3. The extension enables the visu- alizer search algorithm to search for a format-specific user-defined visualizer with the help of a format-specifichelper.
A run of the format-aware visualization search algorithm is demonstrated in Figure 3.5 on the example ofBob. This example shows a subset of the earlier introduced company structure modeling language. User-defined visualizers for four different formats are attached to the clabjects in the example. The format they define the visualization for is indicated by the italic letters at the upper right corner of the clouds representing the visualizers —Ffor form visualizer,
Te for textual visualizer, Ta for tabular visualizer and D for diagrammatic visualizer. Additionally, the arrows representing the trace of the visualizer search algorithm have been extended to show the format for which the search is executed, hereformat=Tato indicate a search for a visualizer in the tabular format.
The visualizer search algorithm first looks atBobfor a visualizer but none is found. Next, the supertypes ofBobare searched for a visualizer. This search ends without a result becauseBobdoes not have any supertypes. Afterwards, the types of Bobare searched,WebshopAdminwhich does have a visualizer at-
tached. Hence, this visualizer is tested for application by the visualizer search algorithm but the result is negative because the visualizer is for the diagram- matic format and a visualizer for the tabular format is being sought. After this check the supertypes of WebshopAdminare searched, Employee. Employee does not have a visualizer attached so the search continues at the type level with
TechnicalEmployeeType the ontological type of WebshopAdmin. TechnicalEmploy- eeType does not have a visualizer attached either, so the visualization search algorithm continues at the supertypes of TechnicalEmployeeType,EmployeeType.
EmployeeTypehas three visualizers for three different formats attached — form, text and table. The visualizer search algorithm checks all three visualizers us- ing the applicable function presented in Algorithm 3.3 and returns a positive result for the tabular visualizer. The visualizer search algorithm then termi- nates and returns the tabular user-defined visualizer.