Repair Examples

In this section we give some minimal examples of model inconsistencies and their repairs collected from the literature.

Create Interface Operation

This example is a simplified version of the running example in [TOLR2017]. Figure 1 depicts an UML class diagram consisting of an interface IA and a class A implementing this interface. A consistency rule demands that a class must implement all methods of the respective interface.

Fig. 1: Create Interface Operation - Model A

In a next stept the interface IA is extended by a the operation signature op() as shown in Figure 2 introducing an inconsistency regarding the consisteny rule mentioned above. The implementation of the operation is missing in class A.

Fig. 2: Create Interface Operation - Model B

The introcued inconsistency could be fixed in several ways, e.g.:

  • remove the operation signature op() from the interface IA, i.e. perform a simple undo.
  • remove the association between the interface IA and the class A.
  • Add a new operation op() in class A, i.e. implement the operation op() of the interface IA as shown in Figure 3.
Fig. 3: Create Interface Operation - Model C

Create Message Signature

This is a standard example motivating the problem of editing multiple model views of a model which depend on each other. It serves as running example, among others, in [MnJC17] and [TOLR2017].

Figure 4 shows an UML model from different point of views. The class diagram represents the static structure of the system and consists of the two classes A and B and an association connecting the classes via the properties a and b. The sequence diagram represents the dynamic view, i.e. the behavoir of one scenario using liflines and messages. A lifline represents a property of a class, e.g., a:A represents the property a of the class A.

A consistency rule demands that the signature of a message in a sequence diagram must be identical to the signature of an operation of the class referenced by the receiving lifeline.

Fig. 4: Create Message Signature - Model A

In Figure 5 a new message with the signature op is added to the sequence diagram leading to an inconsistency. The class B referenced by the receiving lifeline of the message op does not contain an operation having the same signature like the message.

Fig. 5: Create Message Signature - Model B

The introcued inconsistency could be fixed in several ways, e.g.:

  • remove the message with the signature op, i.e. perform a simple undo
  • add a new operation having the same signature like the new message as shown in Figure 6.
Fig. 6: Create Message Signature - Model C

Create Transition and Event

An similar example of the previous one has been depicted in [POKK17] between state machines and class diagramms. Figure 7 shows an UML model consisting of the class A and the state machine StateMachineA. The state machine consistes of the two states A and B. A consistency rule may demand that a transition is always triggered by an event, which usually refer to an operation of a class.

Fig. 7: Create Transition and Event - Model A

In Figure 8 a transition is added to the state machine leading to an inconsistency. The event of the new transition does not refer to an operation.

Fig. 8: Create Transition and Event - Model B

The introcued inconsistency could be fixed in several ways, e.g.:

  • remove the transition, i.e. perform a simple undo
  • set the operation op of class A as event of the transition that as illustratrated in Figure 9 using equal names
Fig. 9: Create Transition and Event - Model C

Invert Inheritance

This example has been extracted from [MnGC13]. Figure 10 depicts an UML class diagram consisting of the classes A and B. The class A inherits form the class B via the genralization relation. A consistency rule demands that such a generalization relation must be acyclic.

Fig. 10: Invert Inheritance - Model A

In Figure 11 the consistency rule is violated by the creation of the new generalization relation from the class B to the class A.

Fig. 11: Invert Inheritance - Model B

The introcued inconsistency could be fixed in several ways, e.g.:

  • remove the new generalization, i.e. perform a simple undo
  • remove the old generalization from class A to class B as shown in Figure 12.
Fig. 12: Invert Inheritance - Model C

Reconnect Transition

Another example briefly mentioned in [TOLR2017] is the deletion of the target state of a transition. Figure 13 depicts an UML state machine consisting of the states A, B and C. The states A and B are connected via the transtion triggered by the event op.

Fig. 13: Reconnect Transition - Model A

In Figure 14 the target state B of the transition is removed which leads to an inconsistency, since every transition must have extaxtly one source and target state.

Fig. 14: Reconnect Transition - Model B

The introcued inconsistency could be fixed in several ways, e.g.:

  • re-create the state B and set it as target state of the transition, i.e. perform a simple undo
  • remove the transition
  • set the state C as target state of the transition as shown in Figure 15.
Fig. 15: Reconnect Transition - Model C

Replace Operation Return Parameter

This example has been extracted from [PjSM15]. Figure 16 depicts an UML class diagram consisting of the class A. The class contains an operation op() with a return parameter of the type Integer. A consistency rule demands that an operation must not have more than one return parameter.

Fig. 16: Replace Operation Return Parameter - Model A

In Figure 17 a further return parameter of the type String is added to the operation op which violates the consistency rule.

Fig. 17: Replace Operation Return Parameter - Model B

The introcued inconsistency could be fixed in several ways, e.g.:

  • remove the new return parameter, i.e. perform a simple undo
  • remove the old return parameter as shown in Figure 18.
Fig. 18: Replace Operation Return Parameter - Model C

References

  • Macedo, N., Guimaraes, T., & Cunha, A. (2013, November). Model repair and transformation with Echo. In 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE) (pp. 694-697). IEEE. read
  • Macedo, N., Jorge, T., & Cunha, A. (2017). A feature-based classification of model repair approaches. IEEE Transactions on Software Engineering, 43(7), 615-640. read
  • Pietsch, C., Ohrndorf, M., Kelter, U., & Kehrer, T. (2017, October). Incrementally slicing editable submodels. In Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering (pp. 913-918). IEEE Press. read
  • Puissant, J. P., Van Der Straeten, R., & Mens, T. (2015). Resolving model inconsistencies using automated regression planning. Software & Systems Modeling, 14(1), 461-481. read
  • Taentzer, G., Ohrndorf, M., Lamo, Y., & Rutle, A. (2017, April). Change-preserving model repair. In International Conference on Fundamental Approaches to Software Engineering (pp. 283-299). Springer, Berlin, Heidelberg. read