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