Transcription

1 Contradiction Analysis for Inconsistent Formal Models Nils Przigoda 1 Robert Wille 1,2 Rolf Drechsler 1,2 1 Group for Computer Architecture, University of Bremen, Bremen, Germany 2 Cyber-Physical Systems, DFKI GmbH, Bremen, Germany {przigoda,rwille,drechsle}@informatik.uni-bremen.de Abstract Modeling languages such as UML or SysML in combination with constraint languages such as OCL allow for an abstract description of a system prior to its implementation. But the resulting system models can be highly non-trivial and, hence, errors in the descriptions can easily arise. In particular, too strong restrictions leading to an inconsistent model are common. Motivated by this, researchers and engineers developed methods for the validation and verification of given formal models. However, while these methods are efficient to detect the existence of an inconsistency, the designer is usually left alone to identify the reasons for it. In this contribution, we propose an automatic method which efficiently determines reasons explaining the contradiction in an inconsistent UML/OCL model. For this purpose, all constraints causing the contradiction are comprehensibly analyzed. By this, the designer is aided during the debugging of his/her model. I. INTRODUCTION Modeling languages, such as the Unified Modeling Language (UML) [1] and the Systems Modeling Language (SysML) [2], [3] as some of the best-known representatives, received much attention in the past. They allow for a precise description of a system at a high level of abstraction before precise implementation steps are performed. For this purpose, UML provides appropriate models which hide precise implementation details while being expressive enough to specify a complex system. Within UML, the Object Constraint Language (OCL) [4] enables the enrichment of the respective models by textual constraints which add further information to the description. Using OCL, it is possible to define invariants which restrict valid system states or to describe further properties as well as relations between the specified components 1. The resulting models may be composed of numerous different components with various relations, dependencies, or constraints and usually lead to non-trivial descriptions where errors can easily arise. This may lead to an inconsistent description, where certain UML and OCL constraints contradict each other. Then, no valid system state can be derived from the model anymore obviously a serious design error. Detecting such flaws in early stages of the development is an important task since correcting an inconsistent UML/OCL model is easier than fixing a resulting error in the actual implementation. Motivated by this, researchers and engineers developed corresponding methods and tools for the validation and verification of system descriptions given as a formal model. As an example, the UML-based Specification Environment (USE) [5] provides well-established methods that can be applied e. g. to automatically generate test cases for the respective UML/OCL models [6]. Besides that, researchers began to exploit formal methods for the verification of UML/OCL models. Approaches based on theorem provers like PVS [7], HOL-OCL/Isabelle [8], and KeY [9] have been applied for this purpose. They are capable of checking very large models, but often require a strong formal background of the designer. As a consequence, researchers started to investigate the application of fully automatic proof engines including methods based on constraint programming (CSP) [10], [11], [12], description 1 In this paper, UML/OCL is used as modeling language, but the presented approach can easily be transferred to other modeling languages, e. g. SysML. logic [13], [14], the modeling language Alloy based on relational logic [15], [16], or Boolean satisfiability (SAT) [17], [18]. These approaches are particularly helpful in order to determine a valid system state of the model. Furthermore they are useful, even if the description is inconsistent, since these approaches help to detect the existence of a contradiction. But, in such cases they do not provide any further details on the reason for the contradiction. Hence, the designer is left alone to debug the model, i. e. to identify the UML/OCL constraints that caused the contradiction. In this contribution, we propose an automatic method which aids the designer in this process. A methodology is introduced which efficiently determines so-called reasons of the contradiction, i. e. a subset of all UML/OCL constraints of a model which forms a contradiction and, hence, explains the inconsistency. For this purpose, we exploit the formal proof techniques which have already successfully been applied to initially check for the existence of a contradiction. The resulting problem formulation is extended so that UML/OCL constraints can be disabled in order to derive a valid system state from the model. By exhaustively analyzing all possible combinations that got disabled in order to allow a valid system state, the desired reasons can automatically be determined. Previously proposed approaches for debugging UML/OCL models (discussed in detail in Section III-B) only provided approximations of the reasons. In contrast to this, the solution proposed in this work determines all minimal reasons explaining the problem. The remainder of this work is structured as follows: The next section briefly introduces the terminology used in the following. Afterwards, a precise problem formulation and discussion of related work is provided in Section III. The general concept of the proposed solution is then sketched and illustrated in Section IV, before details on its implementation and evaluation are given in Section V. Finally, the paper is concluded in Section VI. II. PRELIMINARIES In order to keep the paper self-contained, this section provides a brief review on UML/OCL and introduces the notation used to describe the respective models and system states. Definition 1: A model M = (C, R) is a tuple of classes C and relations R (also known as associations). A class c C contains attributes and operations. A relation r = (c 1, c 2, (l, u)) consists of two classes c 1 and c 2 from C. The tuple (l, u) represents the lower and the upper bound, i. e. each instance of c 1 shall be connected with at least l but at most u instances of c 2. Such a pair of bounds is called UML constraints in the following. The lower bound is an arbitrary natural number, while the upper bound is either a positive natural number or infinity. Besides that, the model can additionally be enriched by textual constraints which can be provided in OCL and are denoted as invariants. The set I represents all OCL invariants of a model. Each invariant i I belongs to a class c C and defines an OCL constraint. Example 1: Consider the model given in Figure 1 which consists of two classes, A and C. Both are connected by two relations. The first relation r 1 states that each object of C

2 i2: A.allInstances().forAll(a a.v = 8) i3: C.allInstances().forAll(c c.u = 3) A v: Integer w: Boolean r 1: 2 r 2: 1 as cs C u: Integer i1: v <= 10 implies w Figure 1: A model example A1:A v = 9 w = true C1:C u = 3 (a) An inconsistent instantiation of the model. A1:A C1:C A2:A v = 8 w = true u = 3 v = 8 w = true (b) An consistent instantiation of the model. Figure 2: Two model instantiations is connected with exactly two objects of A. Due to the fact that the lower and upper bound are equal, only one bound is notated. The second relation states that each object of A is connected with exactly one object of C. Additionally, three OCL invariants are provided which restrict the values of the attributes. Note that, in the following, we mainly make use of the convention which denotes sets by upper case letters and single elements by lower case letters. Furthermore, for the sake of simplicity, we restrict ourselves to binary associations. This restriction is not too strong. In fact, it has been shown that models containing n-ary associations can be mapped into an semantically equivalent model solely composed of binary associations by adding some invariants to the affected classes [19]. Modeling languages such as EMF [20] do not support n-ary associations at all. Definition 2: An instantiation of a model M = (C, R) with a set of invariants I is called system state. Furthermore, a system state is called valid, if all UML and OCL constraints are satisfied. If at least one of the different constraints is not satisfied, the instantiation is called invalid. A valid instantiation must be also composed of at least one object of any class. If a valid instantiation of a model exists, then the model is called consistent. Example 2: Consider again the model shown in Figure 1. The instantiation of the model presented in Figure 2a is invalid, because the restriction given by the relation r 1 is not satisfied for the object C1, which is an instance of class C. In fact, it is not possible to determine a valid instantiation composed of one object of class A and one object of class C, because the object of C can never be connected with two different objects of class A. Additionally, the invariant i 2 is also not satisfied, because the attribute v of object A1 is assigned 9. But in order to satisfy i 2, attribute v is assigned 8 for all objects of class A. In contrast, a valid instantiation of the model is shown in Figure 2b. Here, object C1 is connected with exactly two objects of class A, namely object A1 and object A2. Each object of class A is connected with only one object of class C, i. e. the UML constraints r 1 and r 2 are satisfied. However, a valid instantiation must also satisfy the remaining three constraints given by the invariants. Invariant i 1 requires that, for every object of class A, where the attribute v is smaller or equal to 10, the Boolean attribute w is set to true. As v is 8 for both instances and w is true, invariant i 1 is satisfied. The invariant i 2 (i 3 ) is also satisfied, because the attribute v (u) of all object instances of class A (class B) are set to 8 (3). Therefore a valid system state has been determined and this also shows that the model provided in Figure 1 is consistent. III. PROBLEM FORMULATION AND RELATED WORK In this section, the design task of debugging inconsistent model descriptions is introduced and motivated. For this purpose, a model is provided which works as running example throughout the remainder of this paper. Besides that, we briefly review previously proposed solutions to this problem and discuss their potential for improvement which motivated the work at hand. A. Debugging Erroneous Models Although system models based on UML/OCL rely on a high level of abstraction (hiding a significant amount of implementation details), the respective descriptions can be highly non-trivial and, hence, complex to comprehend. Consequently, errors in the descriptions can easily arise and are often hard to detect. This may lead e. g. to an inconsistent description from which no valid instantiation can be derived. Motivated by this, researchers and engineers developed various methods aiming at the verification and validation of UML/OCL models (see e. g. [5], [10], [16], [17], [18]). These methods are very efficient in detecting whether all descriptions in a UML/OCL model are consistent or not. For consistent models, they often even determine a valid system state of the model and, by this, provide a so-called witness confirming that an instantiation of the model indeed is possible. However, in cases where the description is inconsistent, methods such as introduced in [5], [10], [16], [17], [18] only report that a contradiction exists without any details on the reason(s) for this. In these cases, the designer is left alone to debug the model, i. e. to identifiy the reasons for the contradiction. Example 3: Consider the UML/OCL model as shown in Figure 3 which is used as running example in the remainder of this paper. The model describes a system composed of four classes including several attributes which are constrained by several UML constraints (i. e. relations together with their multiplicities) as well as OCL constraints (i. e. invariants). Additionally, it is assumed that 2, 5, 3, and 7 objects shall be instantiated from the classes A, B, C, and D, respectively. However, although maybe not obvious at a first glance, this model is highly over-constrained. In fact, the following contradictions prohibit a valid instantiation of this model 2 : 1) A trivial contradiction is inherent in the invariant i 5. Here, the logical expression by itself is not valid. 2) Somewhat harder to debug are contradictions which span over several invariants. In the model, this is the case for the invariants i 3, i 1, and i 2. The invariant i 3 enforces all attributes v of each instance of class A to be set to the value 8. Adding invariant i 1, the attribute w always has to be true. However, invariant i 2 requires this attribute to be false for exactly one connected instance of class A. 3) In a similar fashion, UML constraints may lead to a contradiction. This is the case for the association between the classes A and C. Since 2 objects are derived from Class A and 3 objects are derived from class C, the multiplicities of this relation (represented by r 1 and r 2 ) are violated. 4) Finally, contradictions may have its origins in the combination of both, UML and OCL constraints. For example, this is the case for the combination of the invariants i 4 and i 7 and the relation r 7. Both, the invariants and the relation, enforce restrictions on the number of links from instantiations of class D to instantiations of class C which are in violation to each other. Without any additional help, debugging an inconsistent UML/OCL description is a cumbersome and time-consuming task. Hence, methods that automatically approximate or even exactly determine reasons for a contradiction are desired. A 2 Note that the model was built to serve as a proper example including various types of contradictions which may occur in practice.

3 i3: A.allInstances().forAll(a a.v = 8) i4: C.allInstances().forAll(c c.u = 3) i5: B.allInstances().forAll(b b.x = 11 and b.x = 12) i2: as->one(a a.w = false) r 3: 2 as A v: Integer w: Boolean i1: v <= 10 implies w r 4: 5 bs r 1: 2 r 2: 1 as cs B x: Integer y: Integer bs r 5: 5 cs r 6: 3 C u: Integer cs r 7: 3 ds r 8: 0..7 D z: Boolean i6: cs->forall(c c.u < 10) i7: cs->forall(c c.ds->size() = cs.u->sum() ) Figure 3: Running example reason is thereby a subset of all UML/OCL constraints which forms a contradiction and, hence, have to be considered by the designer for debugging. The definition for a reason is given as follows. Definition 3: A UML/OCL model is over-constrained or inconsistent if the conjunction of all UML constraints such as relations including their multiplicities specified in R as well as OCL constraints such as invariants specified in I are not satisfiable and, thus, no valid instantiation is possible. Then, a reason R for the contradiction is a non-empty set of constraints R R I such that the conjunction of all constraints c i R forms a contradiction, i. e. c i R is equivalent to 0. Example 4: As discussed in Example 3, the model shown in Figure 3 is inconsistent due to four reasons, namely: 1. R 1 = {i 5 }, 2. R 2 = {i 1, i 2, i 3 }, 3. R 3 = {r 1, r 2 }, and 4. R 4 = {i 4, i 7, r 7 }. How to efficiently determine reasons for an inconsistent UML/OCL model is considered in this work. B. Previously Proposed Solutions Determining reasons for inconsistent UML/OCL models has been considered before. For example, approaches presented in [21] and [22] provide respective solutions. Both utilize the same solving engine which is already applied in the first place to check whether a contradiction exists. Torlak et al. have proposed an approach [21] which relies on a technique called unsatisfiable core extraction (see also e. g. [23], [24]). First, they check whether a given model is consistent, i. e. free of a contradiction. For that purpose, they translate the declarative UML/OCL description into a propositional formula which is given to a solving engine (e. g. a SAT solver). In case of a contradiction, the solver will prove that no satisfying solution and, by this, no valid instantiation exists. Then, unsatisfiable core extraction determines a sub-set of the propositional formula (a so-called unsatisfiable core) which still is contradictory 3. This subset is further optimized until a minimal core results. Since each expression in the formula represents invariants or relations of the UML/OCL model, a minimal reason for the contradiction can be determined from the resulting subset. However, a main problem of this approach is that only one contradiction is determined in each turn. 3 Many solving engines such as MATHSAT and Z3 already provide unsat core determination as in-house functionality. c i Example 5: Applied to the running example, the approach presented in [21] may deliver the reason R 1, i. e. the information that i 5 is self-contradictory. Even after fixing this error the designer is still left alone with a contradictory UML/OCL model. In fact, the designer has to explicitly invoke this approach four times until all contradictions have been identified and fixed. Considering that unsat core extraction is a computationally expensive process (i. e. requires significant run-times), this provides potential for further improvement. In [22], a complementary approach has been proposed. Here, the propositional formula is enriched by additional logic allowing to disable certain constraints. The number of constraints to be disabled is thereby restricted by an integer k. At the beginning, k is fixed to 1 (i. e. one invariant may be disabled). If this still leads to a contradiction (checked by the solving engine), k is increased. This procedure is repeated until the solving engine determines the first solution. Then, all solutions for the current value k are determined. This eventually leads to so-called contradiction candidates, i. e. a set of UML/OCL constraints which, once disabled, would lead to a contradiction-free model. However, while this may pin-point the designer to possible problems in the model, this approach only provides limited explanations of the contradiction. Example 6: Applying the approach from [22] will lead to the contradiction candidates r 1, r 2, r 7, i 1, i 2, i 3, i 4, i 5, and i 7. While this includes all contradictory constraints, no relation between them is provided. In fact, this result only represents the union of the actual reasons, i. e. R 1 R 2 R 3 R 4. The designer is left alone figuring out their relations to each other. Overall, while the approaches proposed before already offer proper solutions which aid the designer in debugging contradictory UML/OCL models, they still offer room for improvement. Either only a single reason is determined or all contradictory UML/OCL descriptions are provided at once. In this work, we propose an alternative, which determines all minimal reasons and additionally groups them according to their contradictions. IV. PROPOSED APPROACH In this section, we describe the proposed approach for an advanced analysis of contradictions in UML/OCL models. The general idea is thereby based on the previously proposed solutions described above, i. e. we rely on a solving engine which already has been applied to identify the existence of a contradiction and we enrich the corresponding propositional formula. More precisely, given a UML model M = (C, R) with OCL constraints I, we assume the model has been checked for the existence of a contradiction by transforming it into the propositional formula f con = Φ(M) r R r i, where (1) i I Φ(M) is a propositional sub-formula representing all UML components in a system state such as objects, attribute values, and links, r is a propositional sub-formula representing the given UML relation r R, and i is a propositional sub-formula representing the given OCL invariant i I. For this purpose, existing approaches for UML/OCL validation and verification such as [5], [10], [16], [17], [18] can be utilized. If the respectively applied solving engine cannot determine a valid assignment for this instance, it has been proven that the model is inconsistent and the designer must have a look at all constraints in order to fix the model. In order to provide the designer with the desired reasons, we exploit the idea from [22], i. e. we enrich the corresponding propositional formula so that UML relations or OCL invariants

4 Table I: Possible solutions derived from the running example r 1 r 2 r 3 r 4 r 5 r 6 i 6 r 8 i 1 i 2 i 3 i 5 i 4 i 7 r at least one 1 at least one 1 1 at least one 1 may be disabled. More precisely, the formula from Eq. 1 is extended to f con = Φ(M) (s i i ), (2) r R (s r r ) i I where s c is a new free variable corresponding to a constraint c. However, in contrast to [22], we do not restrict the total number k of constraints to be disabled. Besides this, we also need to extend Definition 3 as we are interested in minimal reasons. Definition 4: A reason R of an inconsistent model as defined in Definition 3 is called minimal if no subset R R exists such that c R c i is already equivalent to 0. Now, passing the formula from Eq. 2 to a solving engine allows to investigate how enabling or disabling UML/OCL constraints keeps or does not keep the model contradictionfree. For example, an assignment determined by the solving engine such as s r1 = 1, s r2 = 1, s r3 = 1, s r4 = 1, s r5 = 1, s r6 = 1, s r7 = 1, s r8 = 0, s i1 = 1, s i2 = 1, s i3 = 1, s i4 = 1, s i5 = 1, s i6 = 1, and s i7 = 1. allows the conclusion that disabling all UML/OCL constraints except r 8 would lead to a valid instantiation of the model. Obviously, this alone does not significantly help in identifying the reasons for a contradiction. But observing all such possibilities indeed provides a proper basis for a comprehensive analysis 4. To illustrate this, Table I lists all possible assignments to the respective s c -variables that have been obtained by applying the formula from Eq. 2 to the running example. More precisely, a 1 denotes that the respective constraint has been disabled, while a 0 denotes that it has been enabled. A - represents a don t care, i. e. the case that, for the considered assignment, the value of the corresponding select variable (stating whether the respective constraint is enabled or disabled) does not matter. This allows to represent all solutions in a compact fashion. The row at the bottom summarizes some of the properties which are exploited for the analysis and discussed next. In fact, some very substantial conclusions can be drawn from Table I. For example, it can be observed that invariant i 5 is disabled in all solutions. Hence, this invariant must be self-contradictory; otherwise at least one solution where all constraints except i 5 are disabled should exists. This is summarized by a 1 in the bottom row of the column i 5. Similarly, it can be concluded that the relations r 3, r 4, r 5, r 6, r 8 and the invariant i 6 are never part of a minimal reason; otherwise the value of the corresponding s c -variable could not arbitrarily be 4 In a similar fashion, contradictions in inputs for constraint-based random simulation are analyzed [25]. switched. This is summarized by a - in the bottom row of the respective columns. Another conclusion may be drawn from the first two columns of Table I. Here, it is evident that at least one of the two constraints is disabled in all solutions. This constitutes an indication that r 1 and r 2 are part of a reason; otherwise at least one solution should exists in which both are enabled. In a similar fashion, this holds for i 1, i 2, and i 3 as well as i 4, i 7, and r 7. All these cases are summarized by at least one 1 in the bottom row of the respective columns. All these observations represent single snapshots and properties which can be exploited to determine the reasons of the contradiction. This eventually leads to the main idea of the proposed approach for contradiction analysis: Using the formula from Eq. 2 and an efficient solving engine, all possible combinations of constraints are iteratively checked starting with the smallest ones. For each combination, the s c -variables are pre-assigned in a fashion that the respective combinations are enabled. If no valid model can be derived assuming this assignment, then a reason for a contradiction has been determined. By excluding all supersets from already determined reasons, minimality is guaranteed. V. IMPLEMENTATION AND EVALUATION This section describes the implementation of the proposed contradiction analysis based on the ideas discussed above. A big drawback of a straight-forward implementation is thereby that the analysis relies on iteratively checking all possible combinations of constraints and, hence, is rather time-consuming. Accordingly, an optimized approach is additionally proposed which addresses this problem. Both implementations are evaluated by means of the running example. A. Straightforward Approach 1) Implementation: The implementation of the proposed ideas is explained with the help of the pseudo code depicted in Figure 4. The algorithm starts with a proper representation of the formula from Eq. 2 (f con) and the two sets R and S which are both initialized to the empty set. R stores all reasons that are found, while S is used to save all s c -variables that are passed to the detailed analysis later. Then, the number of combinations to be considered is simplified based on the observations discussed in Section IV. In other words, for each constraint it is checked if it is selfcontradictory (line 8) or not. If yes, the respective constraint is added to the set of reasons R (line 10). Each of these checks is conducted using the applied solving engine together with an extended version of the formula from Eq. 2, i. e. to check if s c is 1 for all solutions, the conjunction f con (s c = 0) is carried out. If no valid solution can be determined from that, it can be concluded that s c is always 1. Thus, c becomes a reason. If such a check fails (line 11), then the respective constraint c can be a part of a contradiction caused by the conjunction of c with one or more other constraints. Thus, c is passed to the detailed analysis by inserting the respective s c into S (line 13). The next step is to calculate all possible assignments for the select variables which makes the model consistent. For this purpose the extended formula from Eq. 2 is passed to the solving engine and allsat (line 15) will return all the desired assignments A. This can be done naivly by just blocking the last found solution and ask the solving engine for another solution until the solver engine recognizes that there are no more solutions. Finally, the detailed analysis for all elements in S, representing the remaining constraints, is performed (line 17 to 24). First, the power set P(S) of S is created resulting in all subsets (i. e. combinations) of constraints considered for detailed analysis. Note that we exclude the empty set as well as all sets which only contain one element from the power

5 ContradictionAnalysis Input: f con 1: // initialization 2: // set of all minimal contradiction reasons 3: R 4: // s c variables for detailed analysis 5: S 6: // first step, simple analysis 7: for all c R I do 8: if (f con s c = 0) 0 then 9: // c is self-contradictory 10: R R {{c}} 11: else 12: // c is selected for detailed analysis 13: S S {s c } 14: // calculating all possible assignments 15: A allsat(f con) 16: // detailed analysis 17: for all X P(S) do 18: // from the smallest to the largest 19: if X X : X R then 20: // ensure minimality 21: continue 22: if a A : s c X : a(s c ) = 0 then 23: // reason found 24: R R {X} 25: return R; Figure 4: Straightforward implementation set (this is already covered by the simplifications before). Furthermore, the elements of the power set are ordered according to their cardinality. Then, for each subset X (i. e. for each combination), the conjunction of the respective constraints is tested for a contradiction. If X is a contradiction, then it is not possible to get an assignment a A, where all corresponding select variables are assigned 0. Thus the non-existence of such an assignment implies that X is a contradiction (line 22). To ensure minimality, each contradiction test of a subset X is only carried out if no subset of X, i. e. X X, has already been detected as a reason for a contradiction X R (line 19-21). In summary, the presented contradiction analysis procedure computes all minimal reasons R that explain the contradiction of the considered UML/OCL model. 2) Evaluation: In order to evaluate the algorithm shown in Figure 4, we realized this approach as an Eclipse plugin using both, Java and Xtend. As solving engine, we utilized Satisfiability Modulo Theories (SMT) [26] which has already been successfully applied in order to verify and validate UML/OCL models [18]. Using the resulting tool, we were successful in automatically determining all minimal reasons explaining the contradiction in the running example as discussed in Example 4. By this, engineers are significantly aided in the debugging of contradictory UML/OCL models. In fact, the resulting reasons are more precise and complete compared to the results of previously proposed solutions as discussed in Section III-B. On the contrary, following this straight-forward scheme is computationally expensive: For the running example, a total of 9408 possible assignments have been analyzed requiring a total run-time of approx. 8 CPU hours 5. In order to address this, an optimized implementation is proposed next. B. Optimized Approach 1) Implementation: The huge number of assignments to be analyzed represents a crucial obstacle of the proposed approach. This is caused by the simple determination of all assignments in Line 15 of the algorithm from Figure 4: After the determination of a satisfying assignment, a so-called blocking constraint is added which prevents the solving engine 5 The experiment has been carried out on a Intel i5 with 2.6 GHz cores and 16 GB memory using a 3.11 kernel Linux. from determining the same solution again. By this, all possible assignments are solely obtained. However, for the purposes considered here, explicitly determining all assignments is not necessarily required. In fact, a reduced set of assignments is sufficient. Definition 5: Let a A be one assignment which was obtained by the solving engine and S the set of all s c -variables. Furthermore, let S a be a subset of S (S a S) composed of those s c -variables which are assigned 1 in a. Then a A is called an overset 6 of a, iff S a S a. Blocking the partial assignment including only the variables assigned 1 rather than the complete assignment a, prevents the solving engine not only from obtaining the same assignment again but also all of its oversets. This results in a reduced set of assignments (denoted A ). Considering the reduced set of assignments significantly shrinks the total number of assignments to be analyzed. At the same time, the reduced set of assignments is still sufficient to determine all minimal reasons for the contradiction. Lemma 1: Checking not all possible assignments a A but only the assignments a A of the reduced set, still allows the determination of all minimal reasons for a contradiction. Proof 1: As it is obivious that A is not emtpy, it suffices to prove that no smaller reasons can wrongly be discovered by the algorithm. This will be proven by contradiction. Let R j be a minimal reason to be detected by the algorithm using the complete set of assignments A. Now assume that a smaller reason R j R j would erroneously be detected by relying on the reduced set A. Then, there would be an assignment a A in the complete set such that, for all constraints in the smaller reason R j, the corresponding s c -variables are all assigned 0, i. e. c i R j : a(s ci ) = 0 (otherwise, this reason would have been detected using the complete set A). Then, we can distinguish two cases: 1) This assignment is in A (i. e. a A ): Then, the algorithm would have not detected R j as reason since it violates the corresponding condition in line 22. 2) This assignment is not in A (i. e. a A ): Then, a must have been blocked before by another assignment a A with S a S a. But such an assignment can only have a smaller number of s c -variables set to 1. Consequently, all s c -variables in a assigned 0 will also be assigned 0 in a. Again, the algorithm would have not detected R j as reason since it violates the corresponding condition in line 22. Remark 1: Consider again the minimal reason R j = {c 1, c 2,..., c k }. In an optimal case, the algorithm adds only k blocking constraints. In the worst case, up to 2 k blocking constraints are needed. The actual number of blocking constraints added for R j depends only on the used solving engine and its internal learning techniques which depend on heuristic methods. In order to improve such an heuristic behaviour, the number of disabled constraints is restricted as explained in [22]. At first all assignments with only one disabled constraint are obtained by the solver engine, if they exist. Then the number of disabled constraints is increased by one and the solver engine is called again. Note that, in contrast to [22], we will not stop after the first bunch of assignments. Instead, we call the solving engine for every possible number of disabled constraints and, by this, we obtain a minimal list of assignments. Now, by blocking only oversets of determined assignments and a structured search for every possible number of disabled constraints, we can still ensure that the collected assignments are a reduced set of assignments as described in Definition 5. According to these results, the algorithm shown in Figure 4 can easily be optimized by modifying Line 15. Here, instead of an allsat scheme which determines a complete set of assignments, simply a reduced set of assignments according 6 We are using the word overset to avoid confusions with the term superset.

6 Table II: Experimental results Model C R I O #R Sizes #solve Run-time CivStat < 1 s CivStat , 4 11 < 1 s CivStat , 4, s CivStat , 4 11 < 1 s CivStat < 1 s CivStat , 4, s CivStat , s CivStat , s CivStat , 3 11 < 1 s CarRental , s RunningExample , 2, 3, s Legend: C : Number of classes R : Number of relations I : Number of invariants O : Maximal number of considered object instantiations per class #R: Number of reasons sizes: a list with the sizes of each reason #solve: the number of sat solver calls to Definition 5 is obtained. This is sufficient to perform the following detailed analysis but, at the same time, significantly reduces the number of analysis steps. 2) Evaluation: In order to evaluate the optimized approach, the refined algorithm has been realized as an Eclipse plugin as well. Here, the determination of assignments as described above has been adjusted, while the rest of the algorithm remains identical. Also the improved tool enabled the automatic determination of all minimal reasons explaining the contradiction in the running example as discussed in Example 4. But this time, only 18 rather than 9408 assignments were sufficient for this purpose. As the solving engine had to be invoked respectively fewer times, this led to a significant reduction in the required run-time: Instead of more than 8 hours, the reasons have been determined in just a few seconds. By this, the designer is clearly aided during the debugging of his/her model. In order to further evaluate the optimized solution, the Eclipse plugin has also been tested with the well-known models from the USE package [5]. For this purpose the CivStat model has been edited nine times such that all nine models became inconsistent and different. Furthermore, the (inconsistent) CarRental2 model has been considered which is a variation of the (consistent) CarRental (both are provided by the USE package as well). Table II summarizes the obtained results. The first columns provide the name of the respective models followed by their number of classes ( C ), their number of relations ( R ), their number of invariants ( I ), their maximal number of considered object instantiations per class ( O ), the number of detected reasons (#R), the sizes of the detected reasons (Sizes), the number of solver calls (#solve), and the over-all run-time. Note that the number of solver calls includes all calls with an UNSAT as result and thus, is not equal to the number of assignments which have to be analyzed in order to get all minimal reasons. The numbers clearly show that the optimization of the proposed solution can not only determine all minimal reason but also does this in feasible run-time for the considered models. The detection of one and more reasons for all considered models does never require more than some seconds. VI. CONCLUSION In this contribution, we considered the automatic determination of reasons explaining the contradiction in an inconsistent UML/OCL model. Most of the solutions for the validation and verification of UML/OCL descriptions allow efficient checks which show the existence of an inconsistency. But after that, the designer is usually left alone to identify the reasons for it. Previously proposed solutions for debugging of UML/OCL models only provided either a single reason or all contradictory UML/OCL descriptions at once. We proposed an alternative which determines all minimal reasons and additionally groups them according to their contradictions. For this purpose, all possible combinations of UML/OCL constraints are analyzed. It has been shown that a naive implementation of the proposed idea provides the desired result but requires a significant amount of run-time. Accordingly, an optimization has additionally been introduced addressing this issue. The resulting solution is capable of efficiently providing the designer with a set of minimal reasons which aids him/her during the debugging of inconsistent UML/OCL models. ACKNOWLEDGEMENTS This work was supported by the German Federal Ministry of Education and Research (BMBF) within the project SPECifIC under grant no. 01IW13001, the German Research Foundation (DFG) within the Reinhart Koselleck project under grant no. DR 287/23-1, and a research project under grant no. WI 3401/5-1, as well as the Siemens AG. REFERENCES [1] J. Rumbaugh, I. Jacobson, and G. Booch, Eds., The Unified Modeling Language reference manual. Addison-Wesley Longman Ltd., [2] G. Martin and W. Müller, UML for SOC Design. Springer, [3] T. Weilkiens, Systems Engineering with SysML/UML:Modeling, Analysis, Design. Morgan Kaufmann, [4] J. Warmer and A. Kleppe, The Object Constraint Language: Precise modeling with UML. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., [5] M. Gogolla, F. Büttner, and M. Richters, USE: A UML-based specification environment for validating UML and OCL, Science of Computer Programming, vol. 69, no. 1-3, pp , [6] M. Gogolla, M. Kuhlmann, and L. Hamann, Consistency, Independence and Consequences in UML and OCL Models, in Tests and Proof, 2009, pp [7] M. Kyas, H. Fecher, F. S. de Boer, J. Jacob, J. Hooman, M. van der Zwaag, T. Arons, and H. Kugler, Formalizing UML Models and OCL Constraints in PVS, Electronic Notes in Theoretical Computer Science, vol. 115, pp , [8] A. D. Brucker and B. Wolff, A Proposal for a Formal OCL Semantics in Isabelle/HOL, in Theorem Proving in Higher Order Logics, ser. Lecture Notes in Computer Science, vol Springer, 2002, pp [9] B. Beckert, R. Hähnle, and P. H. Schmitt, Verification of Object-Oriented Software: The KeY Approach. Springer, [10] J. Cabot, R. Clarisó, and D. Riera, Verification of UML/OCL Class Diagrams using Constraint Programming, in ICST Workshops, 2008, pp [11] T. Mancini, Finite satisfiability of UML class diagrams by constraint programming, in Description Logics, [12] H. Malgouyres and G. Motet, A UML model consistency verification approach based on meta-modeling formalization, in Symposium on Applied Computing. ACM, 2006, pp [13] D. Berardi, D. Calvanese, and G. De Giacomo, Reasoning on UML class diagrams, Artif. Intell., vol. 168, no. 1, pp , [14] R. V. D. Straeten, T. Mens, J. Simmonds, and V. Jonckers, Using Description Logic to Maintain Consistency between UML Models, in The Unified Modeling Language, Modeling Languages and Applications, 2003, pp [15] D. Jackson, Software Abstractions - Logic, Language, and Analysis. MIT Press, [16] K. Anastasakis, B. Bordbar, G. Georg, and I. Ray, UML2Alloy: A Challenging Model Transformation, in Int l Conf. on Model Driven Engineering Languages and Systems, ser. Lecture Notes in Computer Science, vol Springer, 2007, pp [17] E. Torlak and D. Jackson, Kodkod: A relational model finder, in TACAS, ser. Lecture Notes in Computer Science, O. Grumberg and M. Huth, Eds., vol Springer, 2007, pp [18] M. Soeken, R. Wille, M. Kuhlmann, M. Gogolla, and R. Drechsler, Verifying UML/OCL models using Boolean satisfiability, in Design, Automation and Test in Europe, 2010, pp [19] M. Gogolla and M. Richters, Expressing UML Class Diagrams Properties with OCL, in Object Modeling with the OCL, ser. Lecture Notes in Computer Science, T. Clark and J. Warmer, Eds., vol Springer, 2002, pp [20] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, EMF: Eclipse Modeling Framework 2.0, 2nd ed. Addison-Wesley Professional, [21] E. Torlak, F. S.-H. Chang, and D. Jackson, Finding Minimal Unsatisfiable Cores of Declarative Specifications, in Formal Methods, 2008, pp [22] R. Wille, M. Soeken, and R. Drechsler, Debugging of inconsistent UML/OCL models, in Design, Automation and Test in Europe, 2012, pp [23] J. Zhang, S. Shen, J. Zhang, W. Xu, and S. Li, Extracting minimal unsatisfiable subformulas in satisfiability modulo theories, Comput. Sci. Inf. Syst., vol. 8, no. 3, pp , [24] R. Gershman, M. Koifman, and O. Strichman, An approach for extracting a small unsatisfiable core, Formal Methods in System Design, vol. 33, no. 1 3, pp. 1 27, [25] D. Große, R. Wille, R. Siegmund, and R. Drechsler, Contradiction Analysis for Constraint-based Random Simulation, in Forum on specification and Design Languages, 2008, pp [26] S. Ranise and C. Tinelli, The satisfiability modulo theories library, SMT-LIB, [Online]. Available: