TÍTULO PRELIMINAR

The emendation service and impact analyzer focus on the model manipulation operation categories identified in literature such as [110, 173, 186]. As a basis for the set of operations used for deep model emendation, the basic opera- tions defined by Opdyke [186] are chosen. These are: 1. Creating an Entity, 2. Deleting an Entity, 3. Changing an Entity and 4. Moving an Entity. The first three are atomic changes to a metamodel whereas the fourth is a complex change composed of the create and delete operations. Other complex changes can be envisaged but are out of scope here. The following paragraphs provide an overview of how these operations occur in deep modeling and can violate the aforementioned classification rules.

Creating an Entity. In the case of deep modeling the operation for creating a program entity can be applied to entities, connections, features and inheri- tance relationships. The operations which affect classification correctness are the addition of attributes, connections and supertypes (through inheritance relationships) to entities and connections. The addition of an attribute effects

attribute correctness (Definition 9.2.2) as instances of a clabject no longer have

for the clabjects in the level above the changed clabject (i.e. type level) because Definition 9.2.2 only restricts instances to having at least the attributes of their type without making any statement about the maximum number of attributes an instance can possess. Hence, instances can have more attributes than their type without violating the attribute correctness well-formedness rule. Never- theless, an instance might change from an isonym to a hyponym. The add attribute operation is also indirectly executed when adding supertypes to a clabject through inheritance as the clabject inherits all attributes of the newly added supertype. When adding a connection to a clabject which is manda- tory for instances (i.e. lower bound higher than one), connection correctness (Definition 9.2.3) is violated by instances.

Deleting an Entity. The attribute correctness constraint is violated by each delete operation that changes the set of attributes available to a clabject. Ex- amples of such delete operations are the deletion of attributes, the deletion of clabjects serving as supertypes for other clabjects and the deletion of inher- itance relationships. After such an operation has been performed, clabjects potentially no longer have all the attributes required to be a valid instance of their types. Moreover, connection correctness (Definition 9.2.3) is potentially violated by deleting mandatory connections or clabjects connected to other clabjects . However, it is not a problem to delete clabjects which are not as- sociated to connections and do not participate in any inheritance relationship or classification relationships.

Changing an Entity. Changing an entity refers to changing the values of meta-attributes of clabjects and features. For potency correctness (Defini- tion 9.2.1) the potency values of clabjects are relevant. Hence, changes to the potency of a clabject can effect the validity of classification relationships in the type and instance direction. Attribute correctness (Definition 9.2.2) is effected by changes to the name, data type, durability, mutability and values of an attribute. Again, this effects types as well as instances of the clabjects which contain the changed attribute and their subclasses. Also connection cor-

rectness (Definition 9.2.3) can be effected by changes to traits of connections

9.3. The Emendation Service

that was originally not mandatory, for instance, can become mandatory after a change to the cardinality of a connection.

Moving an Entity. The move operation is a composition of the delete op- eration at the source and the add operation at the target. Hence, it can be treated as a complex evolution operation with the effects of a remove operation at the source followed by an add operation at the target.

Data: changedClabject, changedTrait, oldValue, newValue Result: List of by a change possibly impacted clabjects. 1 impact;

2 if classificationEffectingChange(changedClabject, changedTrait, oldValue, newValue) then

3 possibleImpact ← buildClassificationTree(changedClabject); 4 for current ∈ possibleImpact do

5 if violatesClassification(changedClabject, current, changedTrait, oldValue, newValue) then

6 impact ← impact ∪ current;

7 end

8 end

9 return impact;

Algorithm 9.1: The impact analyzer algorithm.

The operations presented previously and the checking of the rules they violate are implemented in theImpact Analyzer. The algorithm describing its operation is displayed in Algorithm 9.1. The algorithm expects the changed- Clabject, the changedTrait, the oldValue andnewValue as input and calculates a list of all model elements which are impacted by the change. This list not only contains the minimal set of changes needed to keep classifications valid but is extended to include the maximum set of all impacted model elements. When adding an attribute, for example, it would be possible to calculate the impact only in the instance direction of the classification tree. For a modeler, however, it can also be desirable to additionally add the attribute in the type direction to apply a more strict style of attribute correctness (Definition 9.2.2) which

Figure 9.3: The impact of a change.

would ensure that instances do not have more attributes than their types (i.e. are isonyms only).

The algorithm first checks in line 2 whether the change is one of the former described changes which effect either potency correctness (Definition 9.2.1), at-

tribute correctness (Definition 9.2.2) or connection correctness (Definition 9.2.3).

Examples of such changes are a change to the potency of a clabject or the ad- dition/removal of features from a clabject. If a change potentially violates the classification rules, the algorithm builds up the classification tree for the changed model element using the buildClassificationTree(changedClabject) opera- tion in line 3. The classification tree is the transitive closure over all classi- fication and generalization relations which originate from the changedClabject. For each of the elements in the classification tree the algorithm then checks whether one of the definitions for classification correctness (Definition 9.2.1 - Definition 9.2.3) is violated by the change (line 5). If the change to the clabject violates the classification rules it is included as an impacted item (line 6). The algorithm terminates after the whole classification tree of the changedClabject

has been checked and returns theimpact in line 9.

Figure 9.3 illustrates a change and the result of a run of the impact analyzer presented in Algorithm 9.1. The figure shows two abstract deep models con- sisting of three levels in which clabjects are represented by black solid circles connected via classification relationships (dashed arrows) and generalization relationships (solid arrows). The left-hand side shows the model with a change applied to a clabject indicated by a non-solid circle. The impact calculated for the change is shown on the right-hand side of the figure, indicated in gray. It can be observed that a change to one model can have multiple knock-on changes which makes it important to help users keep track of things. The

9.3. The Emendation Service

emendation service supporting these changes is presented in the following sec- tion.