![](bg2.png)
2 Metrics for Inconsistency Resolution
Evaluating Impact. Our starting observation is that applying changes to model ele-
ments which are heavily used by other model elements should be avoided. Thus, to
avoid changing heavily used model elements the resolution operation with the lowest
impact would be preferred. The rationale behind this idea is that changing such model
element is likely to cause changes in the other model elements as well. Such changes
include modifications to a semantically important class (’god class’) and changes to a
referenced model element. Changing a semantically important class will also modify
the expected semantics for the related model elements (e.g., for all classes connected
by association). Changes to a referenced model element result in having to check, and
possibly modify, the existing references. In Table 1 we present a preliminary collection
of impact relationships that capture a number of these relevant connections between
model elements in UML Class and Sequence Diagrams. To calculate the impact we
check how often each model element involved in a resolution operation is taking part
in such a impact relationship. In order to put the amount of connections in relation with
the design of the overall model, we divide the number of occurrences of a specific im-
pact relationship by the maximum number of occurrences in the model. For resolution
operations consisting of several operations to different model elements the impact val-
ues are added. The more impact relationships a model element takes part in, the higher
the impact of this model element in the given model.
Computational Cost. Whereas the impact metric allows for determining model el-
ements which we would like to avoid applying changes to, it fails to take into account
how hard it is, computationally, to actually carry out a certain resolution operation. In
other words, we would like to express the idea that a resolution operation which involves
a small number of computational steps is preferable over a more expensive alternative.
To this end, we introduce the computational cost as a second metric. This is especially
relevant when dealing with large and complex models that contain many inconsisten-
cies. In such models an often applied, computationally expensive resolution will lead
high execution time and thus to poor performance.
Computational cost considers modification and navigation operations on the model
as a data structure. The computational steps which we take into account are on the one
hand operations on the data structure, i.e., modifications, creations, deletions of model
elements and on the other hand navigational steps in the model. Thus, the steps needed
to execute a resolution depend on the UML meta-model.
Example. We explain the usage of the metrics on a short example. Figure 2 shows
an example of the ’Dangling Connectable Feature Reference’ inconsistency as specified
in [5]. This inconsistency occurs when a message in a sequence diagram references an
operation not found in the corresponding class. In the example the AddEventRequest
operation is not found in the Calendar class. The available options to resolve this in-
consistency are to 1) add a new operation to the Calendar class in the class diagram
(AddOp), 2) remove the message AddEventRequest from the sequence diagram
(RmvMsg), 3) change an existing operation in the class diagram to match the exist-
ing AddEventRequest message (ChngOp) and 4) change the AddEventRequest
message in the sequence diagram to refer to an existing operation in the Calendar
49