Inconsistencies and their Impact on Software Design Models

Integrated software development environments (IDE) provide rich automated features for detecting and fixing errors at the code level. For example, Eclipse has support for so-called "Quick Fixes" that generate potential resolutions for resolving programming errors. Programmers find these resolution mechanisms extremely useful. Some design tools have started to develop similar features by presenting choices for fixing design problems. However, the support currently provided at the model level is very limited. For modeling languages, such as the Unified Modeling Language, constraints are typically defined in form of consistency rules. Automated resolution mechanisms then require tool developers to manually describe how a violation of a consistency rule could be fixed. When the number of consistency rules increases, this represents a significant effort. Furthermore, developers of such resolution mechanisms must take care that their fixes are correct in the sense that they resolve the inconsistencies without introducing new ones. For multi-paradigm modeling languages, such as UML, this is extremely difficult to achieve because of the numerous interactions among consistency rules. An additional problem when developing tool support for resolution mechanisms in UML models is that different development teams often use different consistency rules; or different sets of consistency rules are used at different stages of the project lifecycle. `Hard coded` resolution mechanisms defined for a fixed set of consistency rules are useless as they neglect the varying impact of these different rule sets. This proposal work will develop a principled foundation for understanding changes in design models. This is a complex problem because not every change causes inconsistencies, not every inconsistency is undesirable, and not every undesirable inconsistency is fixable without causing new inconsistencies. It is also infeasible and impractical to enumerate all ways of fixing a given inconsistency as there are too many that would thus certainly overwhelm the designer. It is also beneficial to know what caused an inconsistency when deciding how to fix it (some are caused by incorrect changes; others are caused by correct albeit incomplete changes). Finally, there are inconsistencies a designer likes to eliminate quickly and others a designer is willing to tolerate. Understanding how to resolve inconsistencies is an unsolved problem but it is vital to the future of software modeling - and software engineering in general.

Many software companies rely on software design models. Yet, these companies also have become disillusioned on the value of software modelling. Unlike other engineering disciplines, in which modelling has proven itself as an effective mechanism for dealing with complexity, software models have yet to reach that level of maturity. A key challenge is the evolution of models and or the designers inability to understand changes and how these changes impact the software design model. Changes have desired effects because they add or change features. However, they also have undesired side effects as they frequently introduce errors. In context of design models, these errors manifest themselves as inconsistencies. This project explored how to detect and resolve inconsistencies if they are detectable through defined constraints. Inconsistencies typically arise due to the failure to propagate changes in design models completely and correctly. Resolving inconsistencies in software models is a complex task because the number of repair actions grows exponentially. To deal with this problem, the project contributed a method that copes with large numbers of repair alternatives by focusing on what caused an inconsistency and presenting repairs in a scalable repair tree. The cause is computed by examining the structure of the inconsistent constraint and its behaviour during validation. This allows us to identify where the constraint failed and why. A key aspect of our method is that it treats inconsistencies as symptoms of errors rather than errors. Indeed, since an incorrect change to a model may cause multiple inconsistencies (or none if not observable), it is not useful for the engineer to identify the error by exploring the repairs of individual inconsistencies. Our method advocates exploring errors by investigating combinations of inconsistencies. Our method thus allows inconsistencies to be explored and filtered in various dimensions. Another key aspect of our method is that it ought to be generic and not only be applicable to currently used modelling languages (such as the UML). We thus also applied the method to a range of modelling technologies from product lines engineering, mechatronics engineering, co-evolution of meta model and models, and decision making. In doing so, we evaluated not only the correctness and scalability on a particular domain but also its applicability for many domains.