=Paper=
{{Paper
|id=None
|storemode=property
|title=Utilizing the Relationships Between Inconsistencies for more Effective Inconsistency Resolution
|pdfUrl=https://ceur-ws.org/Vol-661/paper7.pdf
|volume=Vol-661
|dblpUrl=https://dblp.org/rec/conf/kbse/NohrerE10a
}}
==Utilizing the Relationships Between Inconsistencies for more Effective Inconsistency Resolution==
https://ceur-ws.org/Vol-661/paper7.pdf
Utilizing the Relationships Between Inconsistencies for
more Effective Inconsistency Resolution
Alexander Nöhrer Alexander Egyed
Institute for Systems Engineering and Institute for Systems Engineering and
Automation Automation
Johannes Kepler University Linz, Austria Johannes Kepler University Linz, Austria
alexander.noehrer@jku.at alexander.egyed@jku.at
ABSTRACT of a defect, but usually involve other model elements that
During software modeling, engineers are prone to making when changed could also resolve the inconsistency. In ac-
mistakes. State-of-the-art tool support can help detect these cordance, fixing inconsistencies individually could mean fix-
mistakes and point to inconsistencies in the model. They ing the symptoms only but not the defects (i. e., much like
even can generate fixing actions for these inconsistencies. temperature-lowering medication merely “fixes” the symp-
However state-of-the-art approaches process inconsistencies tom – the fever – but not the cause – an infection). Much
individually, assuming that each single inconsistency is a like a good doctor attempts to identify all symptoms about
manifestation of an individual defect. This paper presents a sickness to then hypothesize about the cause, a good soft-
our vision of the next steps in inconsistency resolution. We ware modeler should identify relationships among inconsis-
believe that inconsistencies are merely expression of defects. tencies to reason about the cause(s) (defects) for these incon-
That is, inconsistencies highlight situations under which de- sistencies. Perhaps a key difference here: software models
fects are observable. However, a single defect in a software typically contain many defects.
model may result in many inconsistencies and a single in- A lot of research has been conducted to avoid and help
consistency may be the result of multiple defects. Incon- detect and correct inconsistencies. The issue that inconsis-
sistencies may thus be related to other inconsistencies and tencies are not self-contained is largely ignored in literature
we thus believe that during fixing, one should consider the but of essential importance, it is far more important to fix
clusters of such related inconsistencies. The main benefit the cause than just the symptoms. After all, the goal of en-
of clustering inconsistencies is that it becomes easier to de- gineers is not just to resolve one inconsistency at a time but
tect the defect the bigger the cluster. This paper discusses in the end to get a consistent model. In order to get a consis-
the idea in principle, provides some qualitative aspects of its tent model, all defects have to be resolved. Of course some
benefit, and gives an outlook on how we plan to realize our inconsistencies can only be resolved by fixing the underlying
vision. defects, but those defects often cause additional inconsisten-
cies at other locations. In certain situations this even could
Categories and Subject Descriptors: I.6.4 Simulation be reversed, meaning that several defects cause the same
and Modeling: Model Validation and Analysis inconsistency. An example for such an situation would be
General Terms: Algorithms, Human Factors, Verification. a requirement change in a already consistent model. This
Keywords: User Guidance, Grouping and Clustering, In- requirement change could require a set of model changes con-
consistencies flicting with the present requirements. As a consequence the
first change would introduce an inconsistency without being
the defect itself, instead the other model elements that are
1. INTRODUCTION required to be changed are the defects. This also relates
C. W. Johnson and C. Runciman already wrote in 1982 [6] to the need of tolerating inconsistencies [1], since prevent-
“It is important to distinguish between an error diagnosis ing them in this case would significantly change the typical
and error reporting. Correct error diagnosis must rely upon work flow. So the challenge lies in determining where the
the programmer as it may depend upon intentions that are defects are located and how to fix them, not just their symp-
not expressed in his program. The compiler’s job is correct toms, whilst not being too concerned with not causing new
error reporting using a form and content of reports most inconsistencies since they could be required to achieve the
likely to help the programmer in error diagnosis. We can engineer’s goals.
compare error reports to the symptoms of a sick patient: We present our vision and proposed approach of how to
the location at which the error is detected is not necessarily exploit interrelations between inconsistencies for resolving
its source.” them in this paper. It is our believe that using this informa-
This is analogous to the modeling world, where incon- tion will result in fewer, concrete fixes and provide guidance
sistencies are the symptoms (rules and/or constraints that to engineers for locating the defects. Additionally we ad-
are violated) which are caused by defects (the sources of dress open issues and discuss steps that in our opinion have
symptoms that need fixing) in the model. It is thus the to be taken to provide some insights in the qualitative as-
job of the designer to identify the defects by exploring the pects of this approach. However we are ignoring techniques
choices for fixing the inconsistencies – one of these choices (if for including semantic analysis of constraints and generelly
complete) for each inconsistency inevitably must involve fix- information on how the inconsistencies were created for the
ing a defect. Thus, inconsistencies are the sheer symptoms
39
in essence identified the locations where to fix (e.g., change
the name of the turn-on method) and concrete actions in
addition identify how to fix that location (e.g., change the
name of the turn-on method to activate). However, the
fixing of inconsistencies also has side effects onto other de-
sign constraints: negative side effects if the fixing causes
new inconsistencies or positive side effects if the fixing of
an inconsistency also fixes other inconsistencies. While the
existence of these side effects has been widely published, to
date they have not been exploited much. Existing state of
the art, either attempts to minimize negative side effects (a
heuristic that is not at all guaranteed to be the right strat-
egy) or focuses only on visualizing them. If the goal is to
avoid negative side effects (i. e., avoid additional inconsis-
tencies) then possible fixes for the above model would be:
I1 The first inconsistency could be fixed by adding the op-
eration activate to the class Light (F1 ), or changing
Figure 1: Several Inconsistencies in an UML model its operation turn-on to activate (F2 ). Of course the
of a Light and a Switch model constraint C1 could be changed to fit the model
(F3 ).
I2 The second inconsistency would also be fixed with fixes
time being, at this point we just plan to investigate if incon-
F1 and F2. Additional fixes would be to change the
sistencies are related and how this fact can be used to our
inconsistent action in the state-chart to turn-on (F4 )
advantage before combining it with other technologies.
or to deactivate (F5 ), or simply remove it (F6 ). And
This paper is structured as follows: In Section 2 we de-
again also the meta-model constraint C2 could be
scribe the scenario and problem we address. This is followed
changed (F7 ).
by the vision of how we want to tackle the problem in Sec-
tion 3. In Section 5 we discuss the state-of-the-art and re- I3 The third inconsistency again could be fixed with fixes
lated work. In Section 4 we describe in detail how we plan F1 and F2. Additional fixes would be to change the
to realize our vision. Finally we draw a conclusion and give inconsistent message in the collaboration diagram to
an outlook to future work in Section 6. turn-on (F8 ) or to deactivate (F9 ), or simply remove
it (F10 ). And of course the meta-model constraint C3
2. SCENARIO AND PROBLEM could be changed (F11 ).
During modeling, engineers are prone to making mistakes. Looking at these inconsistencies individually results in sev-
State-of-the-art tool support can help to detect these mis- eral equally viable fixing actions. To choose one of those fix-
takes and point to inconsistencies in the model. For exam- ing actions for each individual inconsistency automatically is
ple, Figure 1 shows a simple UML model describing a Light not reasonable as all are viable. Clearly, the decision on how
with a Switch containing three inconsistencies: to fix an individual inconsistency should be made by the soft-
ware engineer. Since the example given is a fairly small and
I1 A violated model constraint (C1 ) that states that the comprehensible model, it should be no challenge for an engi-
Light class has to have at least two operations named neer to figure out that all inconsistencies can be resolved by
activate and deactivate. either choosing fixing action F1 or F2. In larger, more com-
plex models, such “ideal” fixing actions cannot be identified
I2 A violated meta-model constraint (C2 ) that states that
manually as easily, and as a consequence automated support
state-chart actions must be defined as an operation
is needed. Nonetheless, even the “ideal” fixing actions with
in the owner’s class. In this case the owner of the
the least number of changes and/or the fewest negative side
state-chart class is Light and Light has no activate
effects are not necessarily the fixes the software engineers
operation defined.
intends. For example, if a model is fully consistent but a
I3 A violated meta-model constraint (C3 ) that states that requirement change requires a set of model changes, then
collaboration message actions must be defined as an the first change likely causes inconsistencies because the set
operation in receiver’s class. In this case the receiver’s of model changes are not yet finished. The fix with the least
class is Light which has no activate operation de- number of changes and fewest negative side effects is then
fined. often a simple undo to restore the initial, correct state – a
minimal, consistent solution, however, clearly an incorrect
Typical tool support for fixing these inconsistencies will only one with respect to the intended requirements change.
look at each inconsistency individually and generate fixing Even though this paperfocuses on modeling with the UML
actions for each of them [4, 5, 8, 7]. Current state of the , we previously also investigated the concept of tolerating
art has produced interesting solutions for suggesting fixes to conflicts in other domains. In [9] we discussed different fixing
inconsistencies. There is the pioneering work of Nentwich strategies in the domain of decision-making and product-
et al. [8] that demonstrated how to generate fixing actions line engineering especially. From our experiences in these
for inconsistencies (one inconsistency at a time). They dis- domains, the same basic principles discussed in this paper
tinguished abstract and concrete fixes where abstract fixes are valid. If decision makers pick conflicting decisions, those
40
Figure 3: Overview of Fixes for the Example from
Figure 1
Figure 2: Examples of different Interrelations be-
tween Inconsistencies
fixes the software engineer should consider. In other words
the cause for those three inconsistencies is possibly a single
decisions are often involved in several related rule violations defect in which case one of the two fixing actions must be
in the decision model (symptoms). taken. However, if multiple defects cause the inconsistencies
then other combinations of fixing actions are also possible.
3. VISION On the right hand side a different scenario is shown. We can
As mentioned in the introduction, fixing inconsistencies see that both I1 and I2 are related to I3 but they are in no
should not focus on fixing them individually because they relation to each other. In this scenario it is safe to say that
are only the symptoms of defects. Software modelers should there are at least two defects as there exists no single fixing
identify relationships among inconsistencies to reason about action that could resolve all three inconsistencies at hand.
the cause(s) (defects) for these inconsistencies. In the example described in Section 2, all three described
Looking at a group of inconsistencies instead of a single inconsistencies are related, they all can be fixed by either
one provides more information about the defect and should choosing fixing actions F1 or F2 as is apparent in Figure 3
prove to be useful in reasoning about possible fixes: 1) by (assuming the constraints are correct and therefore fixes F3,
reducing the number of possible fixes and thus more eas- F7, and F11 are irrelevant and grayed out). In this exam-
ily identifying the defect(s) at hand and 2) by understand- ple, we even have the special situation that fixing I1 in any
ing how many defects are involved and what combination of case resolves all three inconsistencies. Additionally if the de-
changes are necessary fix them. The latter aspect in particu- signer decides that there are multiple defects, the number of
lar is challenging because fixes for defects do not necessarily combined fixing actions is reduced by the fact that F1 and
involve single changes to a model but may require sets of F2 respectively always have to be part of the solution. Fur-
changes. While the set of changes is a subset of the changes thermore, choosing F2 to change the operation name from
of the individual inconsistencies, the combinatorial explosion turn-on to activate in the class Light, excludes fixes F4
in what combination of changes of the individual inconsis- and F8 as they would require the operation turn-on to be
tencies to consider would be hard to decide manually. A present in the class Light.
fixing action in this scenario thus involves all the changes to To summarize we think that calculating fixes for more
fix the defect(s) involved and thus all its/their inconsisten- than one inconsistency at a time, especially if they are in-
cies. Depending on the number of inconsistencies that are terrelated, is highly beneficial. Possible positive effects are:
investigated at a time, this could mean a significant scalabil- 1. A reduction in the number of possible fixing actions,
ity improvement when only searching for fixing actions with through reasoning with more facts in the knowledge
a number of changes considerably smaller than the num- base (notice that knowledge about relationships among
ber of inconsistencies. In addition, the search for fixes that inconsistencies reduces the number of fixing actions).
involve single changes only, could be used to determine if
inconsistencies are related and if one or more defects caused 2. As a consequence an increase in scalability since the
the inconsistencies under investigation respectively. calculation can be cut-off as soon as a combined solu-
Figure 2 shows two sets of inconsistencies that are differ- tion is not achievable any more.
ent in terms of their relationships. An ellipse represents the
fixing actions of a single inconsistency which are depicted 3. More precise fixing actions since the impact of the
as black dots. Fixing actions that are located in the over- changes onto a larger amount of model elements is al-
lapping areas of the ellipses are fixing actions shared among ready considered.
several inconsistencies. These fixing actions could fix all in-
4. Supporting designers by unburden them of having to
consistencies involved – however, it is not necessarily true
know about interrelations when choosing a fixing ac-
that there is a single concrete fix for every fixing action in
tion.
case the fixing action is abstract. On the left hand side of
Figure 2, a scenario with three inconsistencies and an over-
lap among all of them is shown. In this case, there exist 4. PROPOSED APPROACH
two possible fixing actions to resolve all three inconsisten- We propose to realize our vision stepwise. First of all we
cies (overlap among all three ellipses). This implies that will use the choice generation technique described by Egyed
those inconsistencies are related, however it does not nec- et. al. [5] to better characterize fixes for individual incon-
essarily imply that these fixes are indeed the only correct sistencies (i. e., to compute concrete fixes for given abstract
41
fixes). As a second step, we will investigate overlaps among changes could cause several inconsistencies. Even with con-
inconsistencies. Initially, we will require the software engi- sidering all those inconsistencies while searching for fixes the
neer to identify relationships among inconsistencies; how- result will probably be an undo, since it is the simplest fix.
ever, we will also develop heuristics to help the engineer. However combined with trusting this first change the search
Questions we plan to answer are: would continue and hopefully come up with changes that
are required by the requirements change anyway.
• How often occur interrelated inconsistencies in real
world examples?
5. RELATED WORK
• How many choices for fixing an inconsistency can be The problem of resolving inconsistencies has received con-
excluded considering these interrelations? How strong siderable attention in the last two centuries. In this section
is this reduction? we give a brief overview of work that has been done in this
• Can abstract fixes become constrained fixes (con- research area. On the one hand, in order to resolve incon-
strained fixes being abstract fixes with some restric- sistencies, they have to be detected and tolerated. Almost
tions, for example the location is known and some pos- 20 years ago, Balzer argued that inconsistencies should be
sibilities of how to fix the inconsistency at that location detected and communicated to the developers; however, de-
have been excluded) or constrained fixes concrete fixes velopers should not be hindered in continuing their work
respectively? If yes, how often does this happen? despite the presence of inconsistencies [1]. However at some
point those inconsistencies have to be resolved, preferably
If the above mentioned qualitative aspects prove to be use- with the support of automated techniques.
ful, as a next step we plan to investigate how the choice First off all, to resolve inconsistencies they have to be de-
generation can be improved and sped up by considering the tected. However the knowledge if the whole model or a sin-
interplay among related inconsistencies already during the gle constraint is consistent, is not enough to produce fixes.
choice generation. For that we will rely on concepts and As Nentwich et. al. for example stated in [7], it is impor-
algorithms from CSPs (Constrained Satisfaction Problems). tant that trace links from the inconsistency to the model
We also think some sort of grouping of actions the user can element(s) in question exist. In their work they propose
take will be necessary to reduce the amount of information to use first-order logic to express consistency rules and are
we have to deal with. This grouping for example could be ac- able to provide trace links between inconsistent elements.
cording to the effect on other inconsistencies or consistency Performance also is an issue when checking for consistency
rules in general. and approaches like the incremental consistency checking
As a final step we are planning to automatically deter- approach by A. Egyed [3] addresses this issue.
mine which inconsistencies are related. On the one hand for For generating fixing or repair actions several approaches
certain consistency rules it could easily be defined on the exist. On the one hand, Xiong et. al. propose writing ad-
meta-level, on the other hand for situational and not so ob- ditional “fixing procedures” for each constraint, in order to
vious relations an online determination could be necessary. produce fixes when needed [11]. On the other hand Nen-
Online meaning in this case that the determination would twich et. al. describe in their work [8] a method for gener-
occur while engineers are using the modeling tool. Our basic ating interactive repairs from first order logic formulae - the
idea for this task until now is: same formulae that they already used to detect inconsisten-
cies [7]. Another approach described by Egyed et. al. in
1. Get all model elements of one inconsistency that are their paper [5] shows how to generate choices for fixing an
involved during the evaluation of the consistency rule. inconsistency without having to understand such formulae
2. Look for other inconsistencies that share model ele- which can be complex in case conistency rules are written
ments with the one under investigation and repeat this in programming languages. These approaches look at other
step for those inconsistencies. model elements already defined in the model and use them
as choices. This generated choices are then reduced by look-
3. Do a pairwise search for fixes with a cardinality of one. ing at the impact of each choice [4, 2] and removing those
If there are none handle those inconsistencies as none- that would cause additional inconsistencies.
related. If there are fixes search for overlaps with other Despite the considerable progress on research for fixing
pairwise search results to form inconsistency clusters. inconsistencies, to the best of our knowledge no approach
looks at more than one inconsistency at a time. However
Additionally we want to incorporate the concept of trust into the need for a more “global” approach during consistency
our reasoning, this concept was already described in [9]. The checking itself is demonstrated by Sabetzadeh et. al. in [10]
concept basically states that some pieces of information ob- but not used for fixing yet. Additionally Nentwich et. al.
served through user behavior can be trusted. Such pieces already stated in their work [8], that one of the biggest chal-
of information are not evident from the model itself. An lenges is not to look at one single inconsistency but to look
example would be that design decisions that introduce an at inconsistencies from a more “global” point of view. This
inconsistency and are not undone must be important to the notion is also in accordance with our vision that a more
user and therefore can be assumed to be correct. Of course “global” view should be beneficial for fixing inconsistencies.
this assumption could only hold if it would be apparent
to the user that an inconsistency was just created through
tool support like instant consistency checking as described 6. CONCLUSIONS AND FUTURE WORK
in [3]. This sort of trust would for example benefit engi- In this work, we presented our vision of the next steps in
neers in including new requirements into consistent models. inconsistency resolving, namely to not look at them individ-
As already mentioned the first change of a series of model ually but in clusters of related inconsistencies. We described
42
the potential we think this approach can have for resolving [4] A. Egyed. Fixing Inconsistencies in UML Design
inconsistencies and hope that we can substantiate it in the Models. In ICSE, pages 292–301. IEEE Computer
near future. As a result we hope we can further improve the Society, 2007.
user guidance during modeling. Once we have evaluated and [5] A. Egyed, E. Letier, and A. Finkelstein. Generating
validated the qualitative properties of searching for fixes for and Evaluating Choices for Fixing Inconsistencies in
several inconsistencies at once, we are planning to explore UML Design Models. In ASE, pages 99–108. IEEE,
the scalability properties. 2008.
Open questions that also would be interesting to inves- [6] C. W. Johnson and C. Runciman. Semantic Errors -
tigate are: Are there different relationships between incon- Diagnosis and Repair. In SIGPLAN Symposium on
sistencies? Can more conceptual parallels be found to the Compiler Construction, pages 88–97, 1982.
compiler community and used? To what degree can cluster- [7] C. Nentwich, L. Capra, W. Emmerich, and
ing algorithms be applied? From a user guidance point of A. Finkelstein. xlinkit: A Consistency Checking and
view it would be interesting to investigate how important Smart Link Generation Service. ACM Trans. Internet
qualitative aspects can be utilized. For example if the user Techn., 2(2):151–185, 2002.
tells the system that certain inconsistencies are related, but [8] C. Nentwich, W. Emmerich, and A. Finkelstein.
no common fix can be found. As stated before this would Consistency Management with Repair Actions. In
imply that those inconsistencies are not related. How is this ICSE, pages 455–464. IEEE Computer Society, 2003.
piece of information useful to the user and can it be used to
[9] A. Nöhrer and A. Egyed. Conflict Resolution
guide the user to a satisfying solution?
Strategies during Product Configuration. In
D. Benavides, D. Batory, and P. Grünbacher, editors,
Acknowledgments VaMoS, volume 37 of ICB Research Report, pages
This research was funded by the Austrian FWF under agree- 107–114. Universität Duisburg-Essen, 2010.
ment P21321-N15. [10] M. Sabetzadeh, S. Nejati, S. M. Easterbrook, and
M. Chechik. Global consistency checking of
7. REFERENCES distributed models with TReMer+. In W. Schäfer,
M. B. Dwyer, and V. Gruhn, editors, ICSE, pages
[1] R. Balzer. Tolerating Inconsistency. In ICSE, pages 815–818. ACM, 2008.
158–165, 1991. [11] Y. Xiong, Z. Hu, H. Zhao, H. Song, M. Takeichi, and
[2] L. C. Briand, Y. Labiche, and L. O’Sullivan. Impact H. Mei. Supporting Automatic Model Inconsistency
Analysis and Change Management of UML Models. In Fixing. In H. van Vliet and V. Issarny, editors,
ICSM, pages 256–265. IEEE Computer Society, 2003. ESEC/SIGSOFT FSE, pages 315–324. ACM, 2009.
[3] A. Egyed. Instant consistency checking for the UML.
In L. J. Osterweil, H. D. Rombach, and M. L. Soffa,
editors, ICSE, pages 381–390. ACM, 2006.
43