Proposicions no de llei i altres proposicions

Depending on the kind of change made to a deep model, different emendation operations are suggested to keep classification relationships valid. These are listed in the following paragraphs:

Add/Remove/Move Attribute. The move attribute operation can be

subsumed by the add and remove operations on attributes, because the move operation can be understood, as previously described, as a remove operation at the source followed by an add operation at the target. Both the add and remove operations on attributes have an impact on the classification relation- ships in a deep model. The minimum change which has to be performed after adding an attribute to a clabject is to add the same attribute to the instances of the changed clabject. The instances then conform to their type again because they have at least the set of attributes required by their type (Definition 9.2.2). As an instance can have more features than the type it is left to the modeler to configure an emendation service in such a way that the types and their instances also obtain new attributes that are added. When removing an attribute which is defined at the changed clabject’s types, it also has to be removed in the type direction of the classification hierarchy to retain

attribute correctness (Definition 9.2.2). It is left to the modeler to configure the

emendation service so that the feature is also removed in the instance direc- tion. This is not required to satisfy the attribute correctness well-formedness property because instances are allowed to posses more attributes than their types.

Add/Delete Connection. Connecting and disconnecting connections to and from clabjects can effect connection correctness (Definition 9.2.3). Con-

nection correctness requires all instances of a clabject to have conforming con-

nections for type level connections which are defined as mandatory by their lower cardinality constraint. All connections, both mandatory and not manda- tory, must adhere to the cardinality constraints at the type level. In the case

of the addition of a newly created connection, the user is not supported by the emendation service since all connections are initially connected to clabjects with a lower multiplicity of zero allowing instances of the connected clabject to be valid without having instances of this connection connected. The delete operation, however, can affect a clabject’s conformance to its type and should, thus, be supported by an emendation service.

Add/Remove Supertype. Adding and removing supertypes of a clabject in an inheritance hierarchy results in a change to the set of attributes pos- sessed by the clabject with the added or removed supertype in its inheritance hierarchy. In the case of the addition of a new supertype, the emendation operation for adding an attribute has to be executed for each newly inherited attribute and in the case of the removal of the supertype the remove attribute operation has to be executed for each attribute which is no longer inherited. The same applies to inherited connections.

Change Attribute Traits. The events which effect classification relation- ships when traits of features are changed are changes to the durability, mutabil- ity, data type, name and value of an attribute as indicated by Definition 9.2.2 describing attribute correctness. When a change is made to the durability of an attribute, all model elements in the classification tree are analyzed to de- termine whether the feature needs to be added or removed at instance levels. Additionally, the durability value has to be recalculated for the whole classifi- cation hierarchy. Mutability has an effect on the values of attributes. When a change is made to the mutability of an attribute it has to be determined whether the value of any instance’s attributes has to be set to the value de- fined by its type. Like durability, the analysis has to be performed on the whole classification hierarchy. A change to the data type and name of an attribute requires this change to be made to all derived attributes in the classification hierarchy. When changing the value of an attribute with mutability zero, the new value has to be propagated to the effected attributes.

Change Clabject Traits. Changes to the traits of a clabject as well as to the connections they are connected to can effect the validity of classifica-

9.3. The Emendation Service

tion relationships. The only trait of clabjects which influences classification is the potency trait as defined in the potency correctness (Definition 9.2.1) well- formedness rule. A change to this trait immediately effects the maximum depth of the classification tree that can be generated from the clabject. If the potency value is reduced the depth of the classification tree has to be decreased, either by deleting classification relationships, which creates untyped clabjects, or by deleting clabjects which would otherwise have a negative potency (which is for- bidden). Potency is recalculated throughout the whole classification tree after a potency change no matter whether it is increased or decreased. Changes to traits of connections and their connection ends (e.g. lower cardinality bound) effect connection correctness (Definition 9.2.3). Hence, emendation operations have to be offered to ensure that a clabject conforms to its types after changes to such traits. These include 1. automatic addition and deletion of connec- tions, 2. automatic renaming of connection end monikers, and 3. automatic adjustment of connection multiplicities.

Data: changedClabject, changedTrait, oldValue, newValue, operation Result: All instances are updated to conform after the operation 1 impact ← calculateImpact(changedClabject, changedTrait, oldValue,

newValue);

2 if impact 6= ∅ then

3 options ← queryOptionsFromUser(changedClabject, changedTrait,

oldValue, newValue, operation, impact);

4 impact ← reduceImpactBasedOnOptions(changedClabject,

changedTrait, oldValue, newValue, impact, options);

5 if impact 6= ∅ then

6 for current ∈ impact do

7 applyEmendationOperation(current, changedClabject,

changedTrait, oldValue, newValue, options);

8 end

9 end

10 end

Emendation Operation for:{Executed Operation} Changes

{Changed Attribute 1} {New Value} {...} Effected Model Elements

{Model Element 1} Emendation Parameters {...} {Parameter 1} {...} Cancel OK

Figure 9.4: A dialog for querying emendation parameters.

The algorithm applied by the emendation service is shown in Algorithm 9.2. The expected input to the algorithm is the changedClabject, changedTrait, old- Value,newValueand executedoperation. The effect of the algorithm is to change all model elements inchangedClabject’sclassification tree to ensure that all clas- sification relationships are valid after a change. The emendation service first uses the previously introduced impact analyzer algorithm to calculate the im- pact of a change (line 1). As earlier mentioned, this impact is calculated in such a way that the entire set of clabjects that are possibly effected by a change are taken into account.

If the impact analyzer identifies an impact on the model (line 2), the user is queried about the options that the emendation operation could apply (line 3). These options, together with the possible parametrization of the emendation service, allow modelers to use the emendation service in a way that best fits their modeling style. For example, a user can apply a style in which types and instances must always have exactly the same number of attributes or in which attributes are only added to supertypes and never to subtypes.

Figure 9.4 shows a mockup of a dialog box querying the user for such a parametrization decision. The title of the dialog shows the identified op- eration ({Executed Operation}), e.g. Change Potency or Add Attribute. The

Changesgroup shows the applied change, e.g. a change to the durability of an attribute. TheEffected Model Elementsgroup displays model elements effected by the change (i.e. the impact). By deselecting model elements, a user can