Level Navigations and OCA
To support the definition of constraints on intermediate levels which refer to navigations defined at higher ontological classification levels a syntax modifi- cation is introduced to dynamically move the definition context of a clabject to a level on which the required navigations are available. To do this definition context move, the new definition context is enclosed in underscores (_) and is used in the same way as an attribute or operation access.
Constraint Example 8.4.7 (Definition Context Movement). 1definition context Steve: self._ManagementEmployee_.intern
2execution context Steve ⇒ {Ann,Bree}
Constraint Example 8.4.7 shows an example in the context of Figure 8.9. The constraint is defined in the definition context of Steve. The intent of the constraint is to retrieve all interns who are managed bySteve. Steve, however, possesses two different ways of navigating to the managed interns (itIntern,
marketingIntern). The currently defined navigations can be extended in future as needed, so for example an hrInternnavigation could be introduced if Steve
starts managing interns in the human resource department. Hence, theintern
navigation from level O1 must be used to navigate to all interns. To use
this navigation, a definition context move fromStevetoManagementEmployeeis made (self._ManagementEmployee_) in the first line of Constraint Example 8.4.7, making the navigations of ManagementEmployee available — here intern only.
Theinternnavigation is then used to navigate to all interns managed bySteve. The result of this navigation, shown in line two, is a set containing Annand
Breewho are connected withStevevia instances of the connection defining the
intern navigation.
A consequence of applying a definition context move is that a navigation can change from a type level navigation to an instance level navigation if the definition and execution context were equal before the move and are different after. This influences the result of a navigation over connections with a cardi- nality upper bound different to one. In the example shown here the navigation changes from a type level navigation to an instance level navigation through the definition context move. This is not a problem in this case because Steve
is only connected via connections with cardinality upper bounds of one. Orthogonal classification of model elements is supported by the option to select either the ontological or linguistic dimension for constraint definition in the deep constraint language. The default context for constraints is the ontological dimension because user-defined visualizations are defined within this dimension. To switch to the linguistic dimension the expression _l_ is used in the same way as an attribute access. Once the switch to the linguistic dimension has been performed all following attribute calls etc. are performed from a linguistic point of view. To switch back to the ontological dimension the expression _o_ is used.
Constraint Example 8.4.8 (OCA Support).
1definition context Steve: self._l_.getAllAttributes().value 2execution context Steve ⇒ {’Steve’, ’Management’, ’120k’}
3definition context StudentEmployeeType: self._l_.getAllSupertypes()._o_
_ .salary
4execution context StudentEmployeeType ⇒ {”}
Constraint Example 8.4.8 demonstrates the seamless switching between the linguistic and ontological dimension in the context of the example shown in Figure 8.9. In the figure the linguistic metamodel (L2) is placed on the right
spanning all ontological classification levels (O0 - O2). The first line of the
constraint example defines a constraint onStevethat first switches over to the linguistic dimension (_l_) to make all linguistic metamodel features ofClabject,
8.4. A Deep Constraint Language Supporting Deep Visualization O0 O2 EmployeeType0 name2 expertise2 salary2 ManagementEmployeeType2 manages * StudentEmployeeType2 manages2 Steve0:ManagementEmployee name0=Steve expertise0=Management salary0=120k ::manages0 1 ::manages0 itIntern 1 marketingIntern durability * feature Attribute mutability value potency getAllSupertypes() getAllAttributes() L2 L1 ManagementEmployee1 name1=Management Employee
expertise1=Management
salary1=95k
InternEmployee1 name1=Intern Employee
expertise1 salary1=12k :manages1 * intern O1 Ann0:InternEmployee name0=Ann expertise0 salary0=15k Bree0:InternEmployee name0=Bree expertise0 salary0=14.5k
Figure 8.9: Constraint example in the context of the OCA.
Steve’slinguistic type, available. Then thegetAllAttributes()method of Clabject
is used to retrieve the list of all attributes belonging toSteve. These are then queried for their values using the linguisticvaluetrait. The second line of the constraint example displays {’Steve’, ’management, ’120k’}as the result of the executed query. The second constraint starting in the third line of the example defines a constraint onStudentEmployeeType. First, it queries all supertypes of
StudentEmployeeType using the linguisticgetAllSupertypes() operation and then switches back to the ontological dimension (_o_) to get the salary of all su- pertypes. The result of this query displayed in the last line of the constraint example shows an empty string becauseEmployeeType, the only supertype of
Chapter 9
Seamless Modeling
Deep modeling makes it possible for a modeler to work on several classification levels at the same time since all levels are treated equally and no deployment steps are required to make changes to one classification level available to the others. This feature, called seamless modeling below, gives significantly more flexibility to modelers than metamodeling approaches using a fixed metamodel level and a soft user model level. To change the metamodel and apply the changes to the deployed modeling tool, several steps have to be executed in such approaches. First, the modeling environment has to be switched into the metamodeling mode which often involves a switch from the tool in which the modeling language is used to the tool in which the modeling language is defined. Second, the new metamodel has to be supplied to the modeling envi- ronment which often involves manual effort such as deploying the new version of the metamodel including its accompanying tool to a central update reposi- tory and invoking the update mechanism of each deployed tool. Third, model evolution mechanisms have to be applied. When using deep modeling, the first two of these tasks are completely unnecessary since there is no difference between metamodeling and user modeling (i.e. a modeler can use all classifica- tion levels seamlessly). The model evolution problem, however, also exists in deep modeling. In fact, the problem is even more acute in deep modeling since it is much easier for modelers to make changes to more than one classification level. In contrast, in traditional modeling environments based on one clas-
sification level pair, the operational classification level can only be switched when the underlying modeling language is changed (e.g. from the user-defined language at M1 to the metamodeling language at M2). As a consequence, the
vast majority of work is done at the user-model level.
Modeling across multiple classification levels also increases the impact of changes to a model because it is not longer just one classification level that is affected by a change, multiple classification levels can be affected in both the type and instance directions of the classification hierarchy at the same time. Figure 9.1 gives an example of the complexity introduced by a change in a model consisting of seven model elements. The language shows an excerpt of the company structure modeling language. Using this language, different
CompanyTypes can be created. ITCompany, a type of company producing in- formation technology (IT) related goods, andToyCompany, a type of company producing toys, are created as two types of companies at level O1. These are
themselves instantiated with four concrete companies namedPineapple,Banana- soft, Supertoys and Boringtoys. After the whole model has been created, it is noticed that a company has to possess a taxIDso the taxIDattribute is added to the CompanyType clabject. This change, however, makes all instances and instances of instances of CompanyType invalid. To fix the model, all six clab- jects in the classification hierarchy of CompanyType—ITCompany,ToyCompany,
Pineapple, Bananasoft, Supertoys and Boringtoys — have to have their taxID at- tribute added manually. Moreover, the same manual effort would have to be performed when changes to potencies, durabilities, attribute data types etc. are performed. The effort of such manual changes grows as the number of inheritance relationships, classification levels and model elements increases, making the approach increasingly difficult to use in an iterative development process.
To handle the complexity of these knock-on changes when working at mul- tiple classification levels, a good deep modeling tool should provide a so-called
emendation service [16]. Such a service constantly watches for changes to
the edited deep model at all ontological levels and automatically calculates the impact of these changes in terms of violations of the classification consis- tency rules, as e.g. defined by Kennel in [127]. If a violation of these rules is detected, the service attempts to correct the classification relationships con-
9.1. Used Formalism O 0 O 1 O 2 ITCompany1 companyName1 Pineapple 0 companyName = Pineapple0 Bananasoft 0 companyName = Bananasoft0 ToyCompany1 companyName1 Supertoys 0 companyName = Supertoys0 Boringtoys 0 companyName = Boringtoys0 CompanyType2 companyName =2 2 taxID =2 2
Figure 9.1: Impact of adding thetaxIDattribute.
cerned by executing changes to repair the affected parts of the model. This is done by suggesting update operations over the whole deep model and applying them if confirmed by the modeler.
The idea of applying evolution services to models is not new. Research on this topic has been performed in the area of metamodel (co)-evolution (e.g. [39, 107, 108, 199, 200]), ontology evolution (e.g. [132, 165, 173]) and deep modeling (e.g. [16, 56, 57]). The first research on model evolution in the context of deep models was performed by Demuth et al. in [57]. However, this only briefly covered the evolution of deep models as a side aspect of a deep modeling extension to Rational Software Architect [156] (at the time of writing known as IBM Rational Software Modeler). The most complete consideration of deep model emendation, upon which this work is based, is described by the author of this thesis in [16].
9.1
Used Formalism
The classification rules for the deep modeling approach used in this work as the foundations of the emendation service are defined by Kennel in [127]. The principles of the emendation service, however, also work with other formaliza- tions of deep modeling such as that of Rossini et al. [204]. In the following, classification rules are expressed using first order logic and set theory. The
for-all (∀) and exists (∃) quantifiers as well as the element-of (∈) operator
are used from set theory. Furthermore, the logical and (∧), or (∨), implies ( =⇒ ), equal (=) and not-equal (6=) operators are used from propositional
Symbol Description
C The set of all clabjects (entities and connections) c A clabject from the set of all clabjects
potency(c) The potency of c
ct The type of the clabject c, i.e. ct = type(c)
connections(c) The connections associated with c
attributes(c) All attributes of c including inherited attributes con A connection from the set of all clabjects cont The type of a connection, i.e. cont = type(con)
mandatory(cont,c) Is connection contmandatory for c?
conforms(cont,con) Does connection con conform to its type cont?
∀c ∈ C For each clabject c from the set of all clabjects C ∃c ∈ C It exists one clabject c in the set of all clabjects C
Table 9.1: Description of the used symbols.
logic, functions and predicates are used from first order logic. Table 9.1 gives an overview of the symbols and conventions used in the formalization. Cap- ital letters represent the set of all instances of a linguistic meta type. For instance Crefers to the set of all clabjects in a deep model. Lowercase letters refer to a single element in the set of all elements of a type. Hence, c refers to one particular clabject from the set of all clabjects C. Access to linguistic metamodel attributes (also known as traits) and methods is designated by a function named after the method name (e.g. conforms(cont,con)) or trait name which is accessed (e.g. durability(c)). An ontological type of a model element is designated by atin the index (e.g. ct) and ontological instances by ani in the index (e.g. ci).