exclude them from consideration. TheEmendation Parametersgroup allows the emendation algorithm to be further configured to fit a modelers style of mod- eling. For example, a modeler could choose to add an attribute to instances only and not to types, or to add an attribute to supertypes of instances only. Based on the parameters provided by the user, the impact is recalculated (line 4) and the set of model elements to emend is potentially reduced. If the recalculated set of impacted model elements is not empty, these elements are emended (line 7). The emendation service applies the previously introduced emendation principles during emendation.
9.4
Limitations
Even though the emendation service described above is fully functional and is useful, there are many opportunities for improvements and new functionality. For example, it is possible to support dynamic definitions of classification con- sistency and emendation rules. Dynamically changing the consistency rules without the need for tool re-deployment allows different styles of deep model- ing to be created with relaxed or more strict classification rules as desired by a modeler. Also, the addition of emendation rules on-the-fly allows them to be adapted to specific modeling styles dynamically. To realize such a feature the emendation service architecture can be enhanced as shown in Figure 9.5. This enhancement proposes an additional Consistency Requirements definition containing consistency rules as input to the Impact Analyzer and Emendation Operationsdefinitions as input to theEmendation Service. The emendation op- erations can then be mapped to violated consistency requirements and thus automatically selected and displayed to the user for selection. A version of an impact analyzer running on a recorded change trace using this feature is suggested in [128] for example. Their so-called Complex Change Detection Engine takes definitions of changes as input so that it can detect new kinds of changes on-the-fly.
The proposed parametrization of the emendation service can be enhanced to allow different decisions to be taken on each subtree of the classification tree rather than on the whole classification tree as currently suggested. To realize this, the suggested emendation parametrization UI mock-up displayed
Deep Model Emendation Service Consistency Requirements 1. subscribe User 2. perform changes 3. notify 4. request analysis 5. result 6. request parameters 7. provide parameters 8. emend Impact Analyzer Emendation Operations
Figure 9.5: The extended emendation service architecture after [16].
in Figure 9.4 needs to visualize the classification tree, allow subtree selection and accept corresponding emendation parameters for each subtree. The emen- dation algorithm as presented in Figure 9.2 would also have to be adopted to focus on subtrees rather than always on the whole classification tree.
Currently the emendation service focuses on applying changes to models which are stored locally. However, it is possible to build a web of deep models which reference each other. The presented approach in this chapter does not scale to such a scenario since local changes can also logically effect remote model content linking to the changed model. To support such a case, change recording technologies can be applied which record local changes and transport them to remote models containing links to the changed model on request. Research on this has for example been done in the ontology evolution domain in [132] and modeling in [128]. Such approaches can be adapted to support emendation and evolution in linked deep-model scenarios.
Another possible extension of the emendation service is to support clabject retyping as suggested by de Lara et al. in [56]. This deep modeling approach allows the types of clabjects to be changed dynamically during run-time. How- ever, this is not covered by the emendation service described in this chapter since it focuses on the definition and usage of deep user-defined languages and therefore assumes a constructive rather than exploratory modeling ap- proach [28]. In constructive modeling, instances are built from their types, so the types of clabjects rarely change after creation. In exploratory modeling, however, a bottom up approach is applied which builds types from instances,
9.4. Limitations
so possible types of instances are discovered after the instances have already been created. If a user retypes a clabject it has to be manually ensured that the classification conformance rules are adhered to in the current version of the emendation service. In the tool described in [56] this is taken care of automatically.
In [96], de Lara et. al describe an approach for multi-level model-satisfiability checking and model completion. This approach can be used to check that a model satisfies existing constraints after a change or to generate new model elements to ensure that a model adheres to newly defined constraints.
When a model evolves, the artifacts accompanying it also have to be evolved. These include constraints, transformations, interpreters, concrete syntax etc. This, however, is beyond the scope of the emendation service presented here but is an option for future research. A tool supporting the evolution of constraints in a deep modeling framework is Cross Layer Modeler [57]. The co-evolution of transformations is supported by the CO-URE tool presented in [85], while Di Ruscio et al. [58] support abstract and concrete syntax co-evolution.
Chapter 10
Deep, Seamless,
Multi-format,
Multi-notation Modeling
with Melanee
In [26] the idea for a deep modeling environment was described for the first time by Atkinson et al. This represented the start of a quest to develop a deep modeling environment at the University of Mannheim which ended in the deep modeling environment Melanee [8] developed as part of this thesis. This section first describes the architecture of Melanee and then walks through an example of how to create a language that demonstrates the key features of the tool.
10.1
Melanee Architecture
Melanee is built using the Eclipse Platform as indicated by Figure 10.1. This provides a stable, well-tested foundation with long maintenance cycles. The specific features of Melanee are realized by leveraging state-of-the-art modeling technology to the greatest extent possible. The metamodel, which is based on
Applications Built on Melanee
e.g. Naomi, Deep-Robot Modeling Framework, GeoWars
Deep-OCL Deep-ATL Diagram/Text/Table/Form DSL Designation Application DSL Reasoning
Melanee - The Deep, Domain-specific Language Workbench
EMF GMF Epsilon OCL Eclipse Platform Workbench Management Visualization Search Linguistic Model Deep Model Editor Emendation
Figure 10.1: The Melanee architecture overview.
the definitions presented in [127] is implemented using EMF modeling technol- ogy [213], a de-facto industry standard for model-driven development at the time of writing. The query operations provided by the metamodel elements are implemented using OCL body statements [177, 184], while constraints on the metamodel are defined and validated using the Epsilon Validation Lan- guage [139] of the Eclipse Epsilon Framework [187]. This language basically resembles the OCL [184] when it comes to defining constraints but allows them to be enriched with richer information for displaying error messages and offering automatic quick fixes. The diagrammatic Deep-model Editor is imple- mented using the Graphical Modeling Framework [94]. Wherever features of the model editor are not provided by the default GMF modeling capa- bilities, they are added by extending its XPand-based [69] code generation templates using aspect-oriented technology [197]. The combination of these technologies made it possible to implement Melanee almost exclusively with well-established, model-driven technologies.
The core component shipped with the basic version of Melanee is the Mela-
nee Workbench which offers extension points and extension point management
features for all functionality except the hardwired diagrammatic predefined language editor. All other parts of Melanee can be added and exchanged to fit a particular user’s needs as indicated by the extension points in Fig- ure 10.1. Default implementations of various extensions are available for instal- lation via Melanee’s plug-in manager — namely, 1. a deep constraint language (Deep-OCL), 2. a deep, rule-based transformation language (Deep-ATL), 3. dia-
10.1. Melanee Architecture
grammatic, pre and user-defined languages (Diagram DSL), 4. textual, pre and user-defined languages (Text DSL), 5. tabular pre and user-defined language (Table DSL), 6. form-based pre and user-defined languages (Form DSL), 7. a service for deriving names of modeling elements (Designation), 8. a language to model the configuration of the modeling environment itself (Application DSL) and 9. a service for executing ontology like reasoning operations on a deep- model (Reasoning). Custom applications are built on top of all these plug-ins and the Melanee workbench. Examples are the deep orthographic modeling environmentNaomi[24], theDeep-Robot Modeling Framework[21] and theGeoWars
game [22].
The metamodel on which all plug-ins are build, the PLM, is shown in Fig- ure 10.2. The root class for all meta types isElementwhich defines the name
attribute for all types and connects them to theirLMLVisualizer. TheLMLVisu- alizer stores the visualization parameters for model elements when visualized in the predefined, diagrammatic LML. These parameters are the location rel- ative to the container (xLocationandyLocation), the size (widthandheight) and an extensible list of rendering parameters inattributes. This list specifies how each linguistic trait of a model element is visualized. The options range from
default, which applies the default information hiding rules of the LML, over noshow, which always hides the trait, andtvs, which displays the trait value in the trait value specification below a clabject’s name, to show which ensures that the trait is always visible regardless of the LML elision rules. Addition- ally, for each format the list stores what notation a model element is visualized in. At the time of writing text, diagram, form, table and app are available. The application (app) format is not a format in the usual sense, rather, its visualiz- ers are used to configure the modeling workbench in which the format-specific editors are displayed. Using the feature it is, for example, possible to configure the menus, views and toolbars visible in the modeling workbench. The list of
LMLVisualizer attributescan, however, be extended as necessary.
User-defined visualization of model elements is defined through theAbstrac- tUserDefinedVisualizers attached to the LMLVisualizer. As many AbstractUserDe- finedVisualizers for as many formats and notations as needed can be attached to an LMLVisualizer. For each format, there is a subclass of AbstractUserDe- finedVisualizer which contains a format-specific notation description. The no-
name Level content * Domain name:EString plmVersion:EString=2.0 DeepModel deepModel * LMLVisualizer name:EString attributes[*]:EString xLocation:EInt yLocation:EInt width:EInt height:EInt userDefined Visualizer * potency:EInt durability:EInt * content feature * Inheritance disjoint:EBooleanObject complete:EBooleanObject Supertype Subtype supertype 1 subtype 1 supertype* subtype* Classification kind:ClassificationKind= {instance, isonym, hyponym, instantiation} instance type 1 1 * content Enumeration literals[*]:EString visualizer 1 enumeration * Connection Entity ConnectionEnd lower:EInt upper:EInt navigable:EBoolean moniker:EString kind:ConnectionEndKind= {Basic, Aggregation, Composition}
connectionEnd* connection 1 destination 1 Attribute value:EString mutability:EInt datatype:EString Method body:EString Parameter name:EString expression:EString output:EBoolean parameter * String -> .* Real -> -?\d*(\.\d*)? Integer -> -?\d* Natural -> \d* Boolean -> true|false Character -> . Percent -> \d{1,3}(\.\d*)? Probability -> 0?\.(\d*)? Money -> -?\d*(\.\d{1,2})? void -> <<Annotation>> Datatypes http://melanee.org/PLM/Datatypes 1 inheritance 1 inheritance Package content * type 1 notation[*]:EString instanceLevel:EBoolean
Figure 10.2: The in Melanee implemented PLM.
tations to which an AbstractUserDefinedVisualizer contributes are referred to in thenotationslist. Furthermore, it is possible to configure whether to apply an
AbstractUserDefinedVisualizerto theinstanceLevelsonly or in addition to the level in which the visualizer containing model element resides (i.e. the type level).
TheDomainclass is the outer most container forDeepModels. It has aname
identifying the domain and an attribute storing the version of the employed linguistic metamodel (plmVersion). DeepModels store theLevelswhich organize domain content into ontological classification levels. All level content that is contained in a container inherits from theOwnedElementtype. TheseOwnedEle- ments are eitherPackages, Correlationsor Clabjects. The Inheritance and Classifi- cation Correlations describe logical relationships between the domain concepts
10.1. Melanee Architecture
(i.e. Connections and Entities). The Inheritance relationship specifies whether one class is a subclass of another. Superclasses are connected via thesupertype
reference and subclasses via thesubtype reference. AnInheritance relationship can connect an infinite number of Subtypes and Supertypes enabling multiple inheritance. Furthermore, an Inheritance can be characterized using the dis- jointandcompleteattributes to make set theoretic statements about instances of subclasses. Distinct classes were chosen forSupertypeand Subtypeto make mappings to relational databases more natural since tables storing the connec- tion information are explicitly created for super- and subclasses. TheClassifi- cationrelationship expresses the fact that oneClabjectis an instance of another.
Classificationsare restricted to connecting Clabjects at adjacent levels and are always stored in the container of theinstanceend. Four kinds of Classifications, specified through thekindattribute, exist: instance,isonym,hyponymandinstan- tiation. Instance classifications do not specify further what kind of instances are connected to the classification. Isonym and hyponym declare whether the instance has exactly the same attributes as the ontological type (isonym) or whether the instance has additional attributes beyond the minimal set needed for conformance to the type (hyponym). Instantiation declares that an instance has been created through instantiation rather than, for example, through type inference by a reasoning service.
Domain content is expressed through subclasses ofClabjectand their char- acterizing Features. Two subclasses of Clabject exist which areEntities, repre- senting entities in the problem domain, andConnections, describing relation- ships between Entities in the problem domain. A Clabject’s potency is defined by the potency trait. In the deep modeling approach supported by Melanee
Entities and Connections can be further characterized through Features. Thus, all Connections are equivalent to association classes in the UML. Connections
are connected toEntities throughConnectionEndswhich are stored in the Con- nections. ConnectionEnds are not first class model elements themselves, they exist to group ConnectionEnd traits so that Connections can be implemented more efficiently. A ConnectionEnd specifies: 1. the moniker used to refer to a
ConnectionEnd, 2. whether the connection end is navigable, 3. lower and upper
cardinality constraints and 4. a kind (basic, aggregation, composition). A basic ConnectionEnddoes not convey any kind of containment or ownership relation-
ship. Aggregationrequires aggregated instances to be connected to a connection with its connection end kind set to aggregation orcomposition. Theaggregation kind, however, places no restriction on where the instances are physically lo- cated. Composition, the most restrictive kind, forces the instances to be owned by an instance of the compositionconnection end and to connect to it through a Connectionof kindcomposition.
Featuresfurther characterize Clabjects. Two flavors of features exist as sub- classes of Feature —Attributeand Method. Both have adurabilitytrait describ- ing their durability. Furthermore, Attributes have a mutability trait to define the mutability of an Attribute’s value. In addition to the potencies, Attributes
have a value trait describing the current value of the attribute and adata type
describing the data type of the value. Data types are predefined in the PLM through theDatatypesannotation attached to the EMF package containing the metamodel. The annotation defines the available data types through tuples mapping the data type name to a regular expression in order to check the
valuetrait ofAttributesfor correctness regarding their data type. Methodshave a body trait which defines the functionality of the method in a constraint or action language. A method’s inputs and outputs are represented by Parame- ters. Each Parameter has aname trait to identify theParameter in the body of the owningMethod. Theexpressiontrait specifies the data type in a constraint or action language’s syntax. By setting the output trait to true, a Parameter
can be declared as the result of a method.
All potencies — clabjectpotency, durability, mutability – and the lower and
upperbounds of ConnectionEndsare of data typeEInt which is an integer data type. To present the infinite *-value, -1 is used as in other modeling frame- works such as the EMF.