Checking the Consistency of UML Class Diagrams ...

Checking the Consistency of UML Class Diagrams Using Larch Prover Pascal Andre1 , Annya Romanczuk2 , Jean-Claude Royer1 , and Aline Vasconcelos2 1 Equipe Genie Logiciel, Methodes et Speci cations Formelles

IRIN - Universite de Nantes 2, rue de la Houssiniere - BP 92208 44322 Nantes Cedex 03

Pascal.Andre,[email protected]

2 Groupe Systemes et Langages a Objet

Ecole des Mines de Nantes 4, rue Alfred Kastler - BP 20722 F-44307 Nantes Cedex 3

[email protected],[email protected]

Abstract. This article presents a formal semantics for UML based on

algebraic abstract types. Currently we only consider class diagrams and object diagrams. These diagrams include class structure, association, cardinality expression, constraint, instance as well as specialization relationship. We give a formal semantics for each of these elements by interpreting the structure of a class as an abstract data type, associations as values of type Association, and specialization as structural projection. We show that a tool like Larch Prover is able to support proofs over UML and especially to detect inconsistencies in these diagrams. We use the critical pair computation to nd inconsistencies in UML diagrams. Several experiments are described illustrating dierent kinds of problems. Keywords. Abstract Data Type, Algebraic Speci cation, Class Diagram, Consistency, Critical Pair, Larch Prover, UML.

1 Introduction One goal of this paper is to describe how to use abstract data types in order to give a formal semantics to part of UML speci cations. Another goal is to show how to check the consistency of the speci cations with the help of Larch Prover [GG89]. Our work focus on features such as association, multiplicity, constraint, association inheritance, and consistency of these features. We present a general framework for a semantics of UML using abstract data types. It is based on choices we consider good

and natural from an object-oriented programming point of view. However other choices are possible and one may adapt our framework. There are several reasons to specify UML notations in a formal way. The most important are to do proofs and to avoid ambiguities and inconsistencies. It also may help to formalize ambiguous concepts like aggregation and composition relationships [BHS99]. The de nition of a formal semantics for UML is a dicult task because UML is a rich, complex, and informal language. Moreover it is a mix of several distinct languages (it is a graphical language with textual parts). There are already several formalizations for UML. These mainly use Z or state-based languages [FBLPS97,LB98]. Here we rather use algebraic data types because they are more abstract than state-based languages. There are also tools and many theoretical frameworks to manage them. From an historic viewpoint, object-oriented languages and abstract data types (ADT for short) share a common ancestor: Simula [KD66]. The two techniques were developed independently, however some works have tried to merge them: FOOPS [GM87], and Eiel [Mey88] (for more detail see [GBB+ 97] about more recent works). The main and rst approach with ADT was [HHK98b]. It reuses a previous work about OMT [BC95]. They use Larch Shared Language. The present work is related to these approaches but we focus on a more operational approach and the checking of consistency within the Larch Prover environment. There are also some dierences, mainly in the semantics given for association, composition and inheritance. A great part of this paper is devoted to the use of Larch Prover to check inconsistencies in UML diagrams. We brie y explain the method we use is based on the critical pair computations. Several kinds of problems were studied and give a means to improve model descriptions. The structure of the paper is the following. Section 2 describes the context: algebraic speci cations of data type and Larch Prover. The third section brie y gives the main elements of our translational semantics of UML class diagram into algebraic speci cations. The next section is devoted to the use of Larch Prover to check UML diagram consistency. We give dierent kinds of example and discuss a general strategy. Lastly we conclude with lessons about these experiments and future extensions.

2 Algebraic Speci cations and Larch Prover For more than twenty years, there is a great amount of works about algebraic speci cations and the de nition of abstract data types. We refer

here to [Wir90] which is a rather comprehensive introduction and survey about these formal speci cation techniques. An algebraic speci cation of a data type is composed of three main parts: { an heading, containing informations about the module, mainly they are: the name (or sort) of the type, the imported modules, and the constructor names (or generators), { a signature which describes the operation syntax, and { the axioms which describe the semantics of operations. Here is a part of the general association speci cation: Specification: Assoc[A, B] Generic: A, B Sort: Assoc[A, B] Use: Nat, Boolean, A, B, String Constructors: void, addLink Variables: s : String, b, b1 : B, a, a1, a2 : A, Signature: void : Nat name : Assoc[A, addLink : Assoc[A, isEmpty : Assoc[A, isLinked : Assoc[A, isRightLinked : Assoc[A, rightCardinality : Assoc[A, __ \eq __ : Assoc[A,

B] B], B] B], B], B], B],

-> -> A, B -> -> A, B -> A -> A -> Assoc[A, B] ->

Xab

: Assoc[A,B]

Assoc[A, B] Nat Assoc[A, B] Boolean Boolean Boolean Nat Boolean

Axioms: (a \eq a1) /\ (b \eq b1) => addLink(addLink(Xab, a, b), a1, b1) = addLink(Xab, a, b); name(void(i)) = i; name(addLink(Xab, a, b)) = name(Xab); Xab \eq Yab = equal(name(Xab), name(Yab)); isEmpty(void(i)); ~(isEmpty(addLink(Xab, a, b))); ~(isLinked(void(i), a, b)); isLinked(addLink(Xab, a, b), a1, b1) = ((a \eq a1 /\ b \eq b1) \/ isLinked(Xab, a1, b1)); ~(isRightLinked(void(i), a)); isRightLinked(addLink(Xab, a, b), a1) = ((a \eq a1) \/ isRightLinked(Xab, a1)); rightCardinality(void(i), a) = 0; (a \eq a1) => rightCardinality(addLink(Xab, a1, b1), a) = 1+ rightCardinality(Xab, a); ~(a \eq a1) => rightCardinality(addLink(Xab, a1, b1), a) = rightCardinality(Xab, a); End.

where~is logical not, ^ is and, _ is or, => is implication and = is equality. We use an informal syntax close to the Larch Prover one. The neq operator de nes an intensional equality between associations. Of course this

type can be completed with many other operators, for instance anequal operator. The equal operator is an extensional or semantic equality.

2.1 Larch Prover Larch Prover [GG89,GH93] (LP for short) is a theorem prover based on the Larch Shared Language. It allows one to de ne algebraic speci cations, to use rewrite rules and to prove properties. However it does not support neither partial algebras nor genericity. Some modi cations of our speci cations are done to x these problems. Genericity is simply x by a copy and replace mechanism. Partial operations are left unspeci ed, we generate axioms with terms which are assumed to be well-de ned. LP is a set of proof tools, mainly they are: rewriting, critical pair computation, Knuth-Bendix completion procedure, proof by induction, proof by contradiction, and proof by case. LP allows one to de ne existential propositions (with the nE pre x), universal propositions (pre x nA) and propositions with usual logical connectors. It supports rst order predicate calculus with equality. We use LP to prove some properties and also to check consistency of UML diagrams. Such work may require a LP expert. The general way to check consistency is to compute the critical pairs. A critical pair is a potential ambiguity in a set of rules. It can be either a new fact forgotten in the system or an irremediable inconsistent fact (for instance true = false). The command critical-pair with computes critical pairs between two set of rewriting rules. The complete command uses the well-known Knuth-Bendix completion algorithm1. This algorithm computes all the critical pairs and adds them in the system. In this case the process stops with an inconsistency. When the process terminates without inconsistency, the system is consistent. This case is true when there is any user code annotation, in this case the generated system is terminating and consistent. Otherwise the process does not terminate, and we cannot say anything about the consistency. Carefully note, consistency is related to equational logic not to predicate calculus. Strictly speaking, it needs a logical system with only quanti er free equations and rewrite rules. However, rst-order formulas can be transformed (by skolemization) into quanti er free formulas. The consistency problem of such diagrams is not easily checkable. UML being a general purpose language, therefore any adequate semantics is undecidable. It is also true whether we only consider static diagrams. One reason is the possible use 1 More precisely it is the Peterson-Stickel extension of this algorithm.

of annotations, for example in order to express user constraints between associations. Code annotations may complete derived associations, derived attributes, association constraints, invariants and even operations. These code annotations may be OCL expressions, or programming language sentences, or Larch Prover axioms in our approach. OCL is a kind of rst-order functional languages with iterator facilities. The UML guide [RJB99] also suggest to use programming languages. Here we use code annotation written with LP. The use of OCL and a translation similar to [HHK98a] would be a good way. However we have not yet implemented this translation and we think that LP is ner on some aspects than OCL. Thus the problem of consistency of such class diagrams is related to the consistency of rst order predicate logic. This kind of problem is not decidable [Apt90]. It exists several useful approaches to detect either consistency or inconsistency. For example, techniques based on Herbrand's Theorem may detect inconsistency [DJ90], but they require process termination because this problem is semi-decidable. Here we use LP and under some hypotheses it can prove a system consistent or inconsistent for equational logic. These hypotheses concern the use of quanti er free formulas, the termination of the rewriting system and the termination of the Knuth-Bendix completion. In practice it is dicult to prove consistency, and it is often more easy to detect inconsistencies. In section 4 we illustrate dierent examples where we have detected inconsistencies.

3 Translation of UML Class Diagrams In this section we sketch a translational semantics for UML class diagrams. More details can be found in [Roy99,ARRV99]. We avoid the discussion about aggregation and composition which complicate the semantics, see [ARRV99] for a related approach. A class diagram is translated into algebraic de nitions. We do not take into account code and side eects. Thus the existing instances of a class are equated with the values of the ADT associated to that class. A purely functional approach with identities is pertinent here. In order to de ne the mapping rules from UML diagrams to algebraic ADTs, the syntax and semantics of each diagram element concerning the UML class diagram is evaluated. We give in the following the description of some of these mapping rules and the corresponding resulting algebraic constructions. This work is close to [BC95,HHK98b], however there are dierences which are detailed in section 5. An rst abstract dierence is: our de -

nitions improve the previous one's because we have a more concrete and operational approach. When you de ne the semantics of a class there are two types: the eective type and the maximal type. The eective type is the set of the eective instances of the class. The maximal type is the set of all instances of a class coping with subclasses. The previous works take into account only the maximal type, in addition we formalize the eective type. This provides an approach where implicit and explicit descriptions of instances and associations are possible.

3.1 From Class to ADT

We assume that classes are formalized by ADTs. The existing instances of a class are equated with the value of the ADT associated to that class. In such a case, a purely functional approach with identities is relevant. Basic types are supposed to exist (imported ADTs). To explicit the connection between ADT and Object-Oriented programming, we reuse the formal class principles [ACR94]. We consider a functional model with an identity attribute, thus each class C has an associated IdC type. An implicit hypothesis is: two values represent the same object if and only if they have the same identity. As in programming language there are two equalities: { an object equality (eq) which is based on identity equality, and { a semantic equality (equal) which is based on equality of attribute values. As usual, the rst one implies the second one. Taking class C, the following mapping rules are de ned. A single newC constructor represents the instantiation process. Instance attributes are translated into argument types in the constructor signature. Constructor:

newC : IdC, T1, ..., Tn -> C

For each argument type of the constructor, primitive observers, called eld selectors, are de ned Operator: Operator: Operator: Operator:

identity sel1 ... seln

: :

C -> IdC C -> T1

:

C -> Tn

Where sel1:T1, ..., seln:Tn are the typed attributes of class C. By de nition, primitive observers are operations related to the main aspect of the ADT which semantics is de ned in terms of the constructor.

Axiom: Axiom: Axiom: Axiom:

identity(newC(id, X1, ..., Xn)) = id; sel1(newC(id, X1, ..., Xn)) = X1; ... seln(newC(id, X1, ..., Xn)) = Xn;

Object equality is based on identity equality in the following way: Operator: __\eq__ : C, C -> Boolean Axiom: aC1 \eq aC2 = equal(identity(aC1), identity(aC2));

Semantic equality is recursive structural equality (but for identity): Operator: equal : C, C -> Boolean Axiom: equal(newC(id, X1, ..., Xn), newC(jd, Y1, ..., Yn)) = equal(X1, Y1) /\ ... /\ equal(Xn, Yn)

3.2 Association and Multiplicity The ADT of Section 2 describes a general type which potentially de nes many associations between types A and B. An association is a value of Assoc[A, B] with a name and a set of links. Generally the speci er does not describe one association but rather a family of associations. The previous type allows one to de ne an association explicitly from its links or several associations implicitly by properties. We have a higher-order association type which allows one to de ne many general associations, computing cardinality, searching links or searching left or right associated objects. It may be specialized and adapted to dierent situations by adding axioms. Of course it is possible to extend this type to ternary or n-ary associations. To de ne a particular association we declare a new value with a name. Operator: oneAssoc : -> Assoc[A, B] Axiom: name(oneAssoc) = "foo";

One example with explicit links is: Operator: otherAssoc : -> Assoc[A, B] Axiom: otherAssoc = addLink(oneA, oneB, addLink(oneA, otherB, void( "bar")));

To assert multiplicity is simple using numeric relations, for instance: Axiom:

inf(rightCardinality(oneAssoc, aA), 5) /\ inf(1, rightCardinality(oneAssoc, aA));

where inf stands for the \lesser or equal" relation.

3.3 Navigation and Role If one wants an explicit navigation, one may de ne a new operator: Operator: oneAssocLeftToRight : A -> Set[B] Axiom: oneAssocLeftToRight(aA) = rightObjects(oneAssoc, aA)

Of course the same schema allows one to de ne roles associated to the association.

3.4 Constraint

It is possible to de ne general constraints on association, e.g. a rightXor2 constraint. We de ne this constraint between two associations of type A-B and C-D respectively. Variable: ABass : Assoc[A, B], CDass : Assoc[C, D] Operator: rightXor : Assoc[A, B], Assoc[C, D] -> Boolean Axiom: ~(ABass \eq CDass) => rightXor(ABass, CDass) = ((~isRightLinked(ABass, aA) /\ isRightLinked(CDass, aC)) \/ (isRightLinked(ABass, aA) /\ ~isRightLinked(CDass, aC)))

Note that this de nition assumes that the two associations are distinct. A common mistake is to forget such conditions. If A=B and C=D, the two associations can be equal, hence the rightXor de nition would not be consistent. In the previous example, axiom writing is only limited by rst order expressions. Since explicit quanti ers may be used (see examples later) we achieve a great degree of expressiveness.

3.5 Inheritance Specialization is made up of two parts: structural inheritance (attributes and associations) and behavioural inheritance (operations). In this paper we only deal with the structural part. We also consider an extended UML approach with multi-covariant rede nitions. It is well-known that type problems arise in this framework, even in a purely functional approach [Cas97]. Once translated into our algebraic framework, we assume that our speci cations do not carry type-checking problems. For instance, the de nition of equalities in case of specialization is subtle. These problems are well-known and some solutions exist [BCC+ 96,Roy98]. However, we assume that the multiplicity intervals are not rede ned, but each interval are allowed to be specialized. 2 The OR operator in UML has a xor meaning.

Subclass Translation. Let us consider the specialization between class C and SubC one of its subclasses. The SubC de nes a sub1: S1, ..., subm :Sm. We translate the class to

ADT:

proper structure: get the following

Specification: SubC Sort: SubC Use: C, IdSubC, T1, ..., Tn, S1, ..., Sm Constructors: newSubC Variables: id : IdSubC, X1 : T1, ..., Xn : Tn, Y1 : S1, ..., Ym : Sm Signature: newSubC : IdSubC, T1, ..., Tn, S1, ..., Sm -> SubC identity : SubC -> IdSubC sel1 : SubC -> T1 ... seln : SubC -> Tn sub1 : SubC -> S1 ... subm : SubC -> Sm __ \eq __ : SubC, SubC -> Boolean equal : SubC, SubC -> Boolean Axioms: identity(newSubC(id, X1, ..., Xn, Y1, ..., Ym)) = id; sel1(newSubC(id, X1, ..., Xn, Y1, ..., Ym)) = X1; ... seln(newSubC(id, X1, ..., Xn, Y1, ..., Ym)) = Xn; sub1(newSubC(id, X1, ..., Xn, Y1, ..., Ym)) = Y1; ... subm(newSubC(id, X1, ..., Xn, Y1, ..., Ym)) = Ym; End.

The translation also adds eq and equal axioms as previously explained for class translation. We assume to get equalities which are symmetric, the de nition of equalities in case of specialization is subtle. The problem is well-known and some solutions exist [Ing86,BCC+ 96]. Here we simply add declarations to take into account parameter polymorphism. Variable: Operator: Operator: Axiom: Axiom: Axiom: Axiom:

Xc : C, Xs : SubC __ \eq __, equal : C, SubC -> Boolean __ \eq __, equal : SubC, C -> Boolean ~(Xc \eq Xs); ~(Xs \eq Xc); equal(Xc, Xs) = equal(sel1(Xc), sel1(Xs)) /\ ... /\ equal(seln(Xc), seln(Xs)); equal(Xs, Xc) = equal(sel1(Xs), sel1(Xc)) /\ ... /\ equal(seln(Xs), seln(Xc));

Structural Projection. An instance of SubC can be viewed as an instance of C. We formalize this relation by a structural projection which

comes from previous works [Roy92]. The context is here more simple because we have only attributes (i.e. elds with a prede ned type which is not a class) and no invariant. Another minor dierence is that identities are not concerned by this relation, and we do use the equal semantic equality. The interpretation of specialization is done according the schema of Figure 1. Specialization of structure de nes a correspondence between the arguments of the constructor of the ADTs. We assume this correspondence is: the rst n arguments (except identity) of the newSubC constructor corresponds to the n arguments (except identity) of the newC constructor. When a subclass is de ned we add the de nition of the structural relation between the ADT corresponding to the classes. If SubC inherits from C then we de ne the PfSubC,Cg relation between the ADTs associated to SubC and C: PfSubC,Cg(newSubC(id, X1, ..., Xn, Y1, ..., Ym), newC(jd, Z1, ..., Zn)) = equal(X1, Z1) ... equal(Xn, Zn)

^

^

C

This de nes a partial orderADT C

translation

P{SubC,C} SubC

ADT SubC translation

Fig. 1. Structural Specialization ing on abstract data types parallel to the class specialization relationship. This de nition is automatically computed once the specialization relations are known. This relation veri es: 8s1; s2 : SubC; (equalC (s1; s2 ) () 9c : C; P fSubC; C g(s1 ; c) ^ P fSubC; C g(s2 ; c)) where equalC is the equality for two instances of class C. It means that specialization de nes equivalence classes on subclass instances. Furthermore we expect that this relation yields the following property: 8s : SubC; 8c1; c2 : C; P fSubC; C g(s; c1 )^P fSubC; C g(s; c2 ) =) equalC (c1 ; c2 )

Uniqueness of the superclass instances is based on semantic equality, namely the equal predicate. These properties express an isomorphism between the equivalence classes associated to the equalC relation in class C and subclass SubC. We consider PfSubC,Cg as a relation to be more uniform with associations. Note that it can be seen as a total function from SubC to C. In general it is a many-to-one function and it is not onto.

Association and Specialization. Whenever an association is de ned,

we expect that it is inherited in some way, and this has only eect on structural specialization. It also seems nice to de ne a notion of specialization. A more comprehensive discussion about this topic exists in [Roy99]. In Section 3.2 we did not handle class polymorphism, but only monomorphic associations between types. From now on, such an association will be noted assocm . A general de nition of a polymorphic association (assocp ) between two classes is a set of monomorphic associations: ] assocm[Ai; Bj ] assocp[A; B ] = Ai Bj  AB

where Ai and B j are subclasses of A and B (respectively), and assocm [Ai ; B j ] is a monomorphic association between the types associated to Ai and B j . We give a semantics of inclusion to the specialization of associations. Let asub and assoc with the same name and A0 B 0  AB , an association asubp [A0 ; B 0 ] is a specialization of another assocp[A; B ] i asubp[A0 ; B 0] p assocp[A; B ]. Inclusion of polymorphic associations is: asubp[A0 ; B 0] p assocp[A; B ] () 8A iB j  A0 B 0; asubm [A i B j ] m assocm [A i B j ] where m stands for inclusion relation. However it seems useful to get more speci c de nitions. Much work still has to be done in order to get more useful and speci c de nitions, and also to relate them to association classes. 0

3.6 Tool Integration

0

0

0

0

We have not yet translated the OCL language into algebraic speci cations, but the previous work demonstrates its feasibility. See [HHK98a,HCRT99,FC99] for related works. Note that several points are not discussed here because of lack of space. Amongst them we have the relation between our association type and association as class, the speci cation le organization, the

0

management of the existing instances, aggregation, composition, active classes and abstract classes. To allow the automatic generation of algebraic speci cations from an UML diagram, we developed an UML CASE tool carrying the mapping rules integrated in its context. The CASE tool was built in Graphtalk meta-tool3 , see [dV99] for more details.

4 Checking UML Diagrams Consistencies with the Larch Prover As explained before, we use Larch Prover to detect inconsistencies in diagrams. Often it is needed to prove some additional facts, and Larch Prover is of great help in such a case. To illustrate this we consider simple UML diagrams. Of course in some of these examples the problem is obvious, however it will not be the case with more complex examples and when an example is split in several diagrams. However our tool must be nished to check realistic examples. Thus some of these problems are in fact only theoretical or rather a little obscure.

4.1 Examples About Association Consistency Following are examples of inconsistencies with associations, constraints and multiplicities.

A Constraint and Multiplicity Problem. This example illustrates a common problem: Using previous association type we de ne the assoc1 A

B

assoc1 1

{Nand} assoc2

1

Fig. 2. A Simple Example 3 Graphtalk meta-tool is a product of Computer Sciences Corporation.

and assoc2 associations. It can be simply expressed by the P1 existential proposition: assert \E Xab1 \E Yab1 (~(Xab1 \eq Yab1) /\ (rightCardinality(Xab1, a) = 1) /\ (rightCardinality(Yab1, a) = 1) /\ rightNand(Xab1, Yab1))

The Nand constraint may then be de ned by proposition P2: declare operator rightNand : Assoc[A,B], Assoc[A,B] -> Bool assert ~(Xab \eq Yab) => rightNand(Xab, Yab) = ~(isRightLinked(Xab, a) /\ isRightLinked(Yab, a))

4.2 A Simple Proof Below is a simple proof done with the help of the Larch Prover. prove equal(rightCardinality(Xab, a), 1) => isRightLinked(Xab, a) % these are LP comments % The above command tries to resume a proof by induction resume by induction on Xab basis subgoal % This means ok for basis case [] basis subgoal induction subgoal % Try to prove the induction step by implication resume by => => subgoal % Try to prove by case (entity(a1c) \eq identity(ac)) res by case identity(a1c) \eq identity(ac) case identity(a1c) \eq identity(ac) [] case identity(a1c) \eq identity(ac) % Try to prove by case not(entity(a1c) \eq identity(ac)) case ~(identity(a1c) \eq identity(ac)) % Addition of a trivial lemma assert identity(ac) \eq identity(a1c) = false % Critical pair computation to finish the proof crit as* with as* [] case ~(identity(a1c) \eq identity(ac)) [] => subgoal [] induction subgoal [] conjecture qed

This kind of proof is usually not automatic, an expert user must choose the way to process it. Now we can illustrate that the previous UML model is not consistent by de ning two associations as1(a), as2(a):

declare operator as1, as2 : A -> AssocAB fix Yab1 as as2(a), Xab1 as as1(a) in P1 instantiate Xab by as1(a), Yab by as2(a) in P2 LP says that the system becomes inconsistent

% eliminations of \E % elimination of \A

It illustrates one fact: the Nand constraint is not compatible with two multiplicities of 1. There are similar problems with or or other constraints. Note that here we have detailed the process, but there is a more straightforward way which makes use of the critical pair computation as in the following examples. There are also classic problems with type of associations; for instance an inclusion constraint needs that association types are the same. Type-checking and checking multiplicity may really help the speci er to detect this kind of problems. However this is not generally sucient because the speci er can de ne any kind of constraint, and some constraints need a more complex checking. This is illustrated by the next example.

Inconsistency without Multiplicity Problem. We illustrate a sim-

ple example with an inconsistency, but checking multiplicity will not nd it. In this example C1 is a constraint which states that each link in assoc1 A

assoc1 {C1}

assoc2

B 2 1

{C2} 1 assoc3

Fig. 3. Inconsistency Without Multiplicity Problem appears either in assoc2 or in assoc3 and not in both associations. The constraint C2 says that the associations assoc2 and assoc3 are equal. It may seem that this is a consistent example, but it is not. Since multiplicities are strictly greater than zero, the associations are not empty. But the C1 relation and the equality between assoc2 and assoc3 imply that these associations are empty. Below are the corresponding axioms, auxiliary facts and the inconsistency.

declare operator inclus : AssocAB, AssocAB -> Bool assert inclus(void(s), Yab); assert inclus(addLink(Xab, a, b), Yab) = (isLinked(Yab, a, b) /\ inclus(Xab, Yab)) declare operator emptyInter : AssocAB, AssocAB -> Bool assert emptyInter(void(s), Yab); assert emptyInter(addLink(Xab, a, b), Yab) = (~isLinked(Yab, a, b) /\ emptyInter(Xab, Yab)); declare operator C1 : AssocAB, AssocAB, AssocAB -> Bool assert C1(Xab, Yab, Zab) = (inclus(Yab, Xab) /\ inclus(Zab, Xab) /\ emptyInter(Yab, Zab)); declare operator C2 : AssocAB, AssocAB -> Bool assert C2(Yab, Zab) = (inclus(Yab, Zab) /\ inclus(Zab, Yab)) declare operator assoc1 : -> AssocAB declare operator assoc2 : -> AssocAB declare operator assoc3 : -> AssocAB assert rightCardinality(assoc1, a) = 2 assert rightCardinality(assoc2, a) = 1 assert rightCardinality(assoc3, a) = 1 assert C1(assoc1,assoc2,assoc3) assert C2(assoc2, assoc3) % auxiliary facts assert ~(equal(rightCardinality(Xab, a), 0) => ~isEmpty(Xab) assert inclus(Yab, Zab) /\ emptyInter(Yab, Zab) => isEmpty(Yab) % complete ... The system now contains 1 formula and 90 rewrite rules. The rewriting system is guaranteed to terminate. Formula exemple.19, false, is inconsistent.

4.3 Examples with Specialization Wrong Multiplicity or Wrong Constraint. Our specialization se-

mantics implies that multiplicity of the specialized association will be lesser than or equal to the specialized association, hence Figure 4, example a) is inconsistent. Furthermore, some constraints are inconsistent with specialization, for instance Figure 4, example b). We may check these two examples and detect inconsistencies. In the a) case a critical pair computation nds the problem, but a complete command will diverge. In the b) case a complete command will prove that asub must be empty, and if not an inconsistency is detected. set name ex %assoc = assoc1+assoc2 declare operator assoc1 : -> AssocAB declare operator assoc2 : -> AssocAsubB % asub declare operator asub : -> AssocAsubB assert isLinked(asub, anasub, b) => isLinked(assoc2, anasub, b)

A

C

assoc

A

C

assoc

1

*

2

* {rightXor} B

B

asub

asub

a)

b)

Fig. 4. Wrong Examples with Specialization % the xor constraint assert ((~isLinked(assoc1, a, b) /\ ~isLinked(assoc2, anasub, b) /\ isLinked(asub, anasub, b)) \/ ((isLinked(assoc1, a, b) \/ isLinked(assoc2, anasub, b)) /\ ~isLinked(asub, anasub, b))) % complete The system is complete. % declare operator unasub : -> Asub declare operator unb : -> B assert isLinked(asub, unasub, unb) Added 1 fact named ex.6 to the system. Formula ex.6, false, is inconsistent.

Constraint and Specialized Associations. We present here a more

complex example with a specialized association (assoc) that is specialized twice with asub1 and asub2. % assoc = assoc1+assoc2+assoc3 declare operator assoc1 : -> AssocAB declare operator assoc2 : -> AssocCB declare operator assoc2 : -> AssocDB assert equal(rightCardinality(assoc1, a) + rightCardinality(assoc2, c) + rightCardinality(assoc2, d), % asub1 declare operator asub1 : -> AssocCB assert isLinked(asub1, c, b) => isLinked(assoc2, c, b) % asub2

A

B assoc

2

{cont} asub1 C asub2

D

Fig. 5. Example with Constraint and Specialized Associations declare operator asub2 : -> AssocDB assert isLinked(asub2, d, b) => isLinked(assoc3, d, b) % fact for cont assert equal(c, d) /\ isLinked(asub1, c, b) /\ isLinked(asub2, d, b) => (\E a equal(a, c) /\ isLinked(assoc1, a, b))

In this context we detect an inconsistency if the rede ned associations contains one association with two objects equal with respect to the A equality. However this inconsistency was more dicult to obtain.

4.4 Synthesis With the previous approaches, we have checked several kinds of examples: { multiplicity problem with derived association, { inconsistency between multiplicity and constraint (see Figure 2), { inconsistency without neither multiplicity nor type problem (see Figure 3), { problem with multiple and disjoint specialization, { problem with circular composition, { problems with specialization, multiplicity and constraint (see Figure 4), { problem with constraint and specialized association (see Figure 5).

We have studied dierent examples and proved their inconsistency, but the results are under the in uence of the form of the axioms and the properties known by the system. In the previous examples, the following schema is able to detect an inconsistency: 1. translate the diagram into LP, 2. load the les, 3. try to prove some useful consequences and add them in the system, and 4. check the consistency with complete or critical-pair commands. One may think that in these situations the critical pair computation is able to automatically nd a general counter-example. However, this is still far away from an automatic strategy to check inconsistency. However this approach already gives us some advantages. One have a general approach (for expert only) which allows to de ne any constraint, to prove some properties, to detect inconsistency, and so on. Our approach can be adapted to dierent contexts and may be used to improve or to give formal semantics to UML concepts. One can de ne and prove simple static checking based on the compatibility between multiplicity and constraint, for instance Nand is not compatible with 1-1, composition or transitivity imply that multiplicity are in relation of integer times, the inclusion constraint implies that multiplicities are lesser or equal, etc. Sometimes an automatic strategy to detect problems exists, and it can be implemented in UML tools. Here are some ideas: clearly type-checking is a rst and simple level of checking. It is able, for instance, to detect problem in derived associations or ill-written constraints. A better idea is to check the multiplicity consistency with association constraints. [CLN99] described a language suitable to Entity-Relationships and Data Base models together with a decidable logic for it. This work can be useful to check some parts of the UML static diagrams (cardinality and prede ned constraints). However, [CLN99] deals only with the non recursive structural aspects of objects and do not include any features for the speci cation of behavioural properties of objects. This is insucient because invariant, derived association, constraint are behavioural speci cations of UML class diagrams. We suspect that a similar checking would be able to prove the consistency if there are only set constraints between association regardless of recursive data types.

5 Related Work Much work has been done dealing with a state based semantics (Z or VDM) for OMT or UML class diagrams [DLCP97,EC97,FB97]. This is due to the proximity between theirs models and Entity-Relationship models. We argue that these approaches are dicult to automate in presence of behavioural descriptions. We also consider that from a conceptual point of view classes are closer to ADT than to sets. One important source of information, the oldest in this area, is [BC95]. It is related to OMT and the use of the Larch Shared Language (LSL). The authors study in depth classes, associations, cardinality, aggregation and many aspects of OMT. They also consider notions of state and errors. Following this work, Hamie, Howse and Kent apply it to the UML in [HHK98b]. Based on this framework they also study navigation and OCL [HHK98a]. They use Larch Shared Language in a modular way and they give semantics to some static and dynamic parts of UML, including state changes and time. LSL is an abstract language for speci cation, which is dierent from the Larch Prover tool language. Our de nition is closer to algebraic speci cation for data types and operations are quite easy to de ne. The previous authors have an abstract approach but they do not guarantee usual properties about algebraic speci cations such as consistency and sucient completeness. For us, it is not sucient to write formal speci cations, we want to be able to check them. We have a constructive, more operational and more precise approach, as indicated by the choice of generator, the notion of sensible signatures, and the two equality functions. It is dicult, and even impossible, without additional information, to prove properties in the approach of the previous authors. The two works are complementary on some UML parts, meanwhile they are dierent on several aspects. We interpret neither OCL nor dynamic diagram. Our current approach seems not to be adequate for the semantics a dynamic diagrams, we plan to use other works based on TAG [AR99]. In our context, equality is important because, for example, composition needs object identity and inheritance needs semantic equality. We have an explicit instantiation process; instances and associations can be implicitly or explicitly de ned. Associations in [HHK98b] are interpreted as two functions that map an object of one type to the set of associated objects of another type. In our approach associations are rst class values, hence Assoc[A, B] is a true and constructive type. This is not true in other approaches. We think this is more exible and natural for UML,

and that makes the integration of other constructions easier. For example, there is neither generic constraint nor association class in [HHK98b]. In this work there are no semantics for composition. We also have a proper semantics for specialization which improves the one of [BC95] (reused in [HHK98b]). This work de nes the simulate function which asserts that a subclass is a subtype of another class by requiring that associated sorts are in subsort relationship. The simulate function maps an object identi er of the subclass to an object identi er of the super class that behaves like it. However there is no explicit de nition of this function. We provide such a de nition with the structural projection based on semantic equality. It allows us to de ne associations and inherited code in an operational way.

6 Conclusion Our approach gives a formal semantics to class diagrams of UML using abstract data types. It is an approach which is successful on this sub part of UML. Furthermore, we give semantics to some UML features which are not yet formally de ned, namely association, composition, constraint, and specialized association. We also show that the use of a tool like Larch Prover helps in the proof of properties and also can detect some ill-formed examples. Our work is complementary with previous works and it improves them in several ways: it suggests rst-class association, it allows association constraints, it formalizes structural inheritance, it gives a useful and rigorous de nitions to specialized association. However, this approach must be extended to take into account code inheritance which is a problem known to be dicult. We are currently investigating the case of classes with code description in methods. Adding operations is quite easy in our algebraic speci cations: their axioms can be de ned on constructors. It is more dicult to give a formal semantics to code inheritance. A rst approach uses copy of axioms and operator overloading. Formal speci cations of the meta-level will be considered in future extensions of this work. Further works will concern techniques to prove properties, especially to show schema equivalence. The use of LP is interesting, but actually it surely cannot handle very big examples. We consider that a practical limit should be around 1000 rules in LP. We must optimize our translation and de ne new automatic strategies to check examples.

References [ACR94] Pascal Andre, Dan Chiorean, and Jean-Claude Royer. The Formal Class

Model. In Joint Modular Languages Conference, Modula, Oberon & friends, ISBN 3-89559-220-X, pages 59{78, Ulm, Germany, 1994. GI, SIG and BCS. September, 28-30. [Apt90] K. R. Apt. Logic rogramming, volume B of Handbook of Theoretical Computer Science, chapter 10, pages 495{574. Elsevier, 1990. Jan Van Leeuwen, Editor. [AR99] Pascal Andre and Jean-Claude Royer. A First Algebraic Approach To the Speci cation of Heteregeneous Software Systems. In 14th Workshop on Algebraic Development Techniques, Bonas, France, september 1999. selectionne pour soumission. [ARRV99] Pascal Andre, Annya Romanczuk, Jean-Claude Royer, and Aline Vasconcelos. An Algebraic View of UML Class Diagrams. In Acte de la conference LMO'2K, september 1999. [BC95] Robert E. Bourdeau and Betty H.C. Cheng. A Formal Semantics for Object Model Diagrams. IEEE Transactions on Sotfware Engineering, 21(10):799{ 821, October 1995. [BCC+ 96] Kim Bruce, Luca Cardelli, Guiseppe Castagna, The Hopkins Object Group, Gary T. Leavens, and Benjamin Pierce. On Binary Methods. Theory and Practice of Object Systems, 1(3), 1996. [BHS99] Franck Barbier and Brian Henderson-Sellers. A Survey of the UML's Aggregation and Composition Relationships. L'objet, 5(3):21{47, oct 1999. [Cas97] Giuseppe Castagna. Object-Oriented Programming: A Uni ed Foundation. Number ISBN 3-7643-3905-5 in Progress in Theoretical Computer Science. Birkhauser, 1997. [CLN99] Diego Calvanese, Maurizio Lenzerini, and Daniele Nardi. Unifying classbased representation formalisms. J. of Arti cial Intelligence Research, 11:199{240, 1999. [DJ90] Nachum Dershowitz and Jean-Pierre Jouannaud. Rewrite Systems, volume B of Handbook of Theoretical Computer Science, chapter 6, pages 243{320. Elsevier, 1990. Jan Van Leeuwen, Editor. [DLCP97] Sophie Dupuy, Yves Ledru, and M. Chabre-Peccoud. Integrating omt and object-oriented-z. In Kevin Lano and A. Evans, editors, Proceedings of BCS FACS/EROS ROOM Workshop, june 1997. [dV99] Aline Pires Vieira de Vasconcelos. Formalization of UML Using Algebraic Speci cations. Master's thesis, Master EMOOSE, august 1999. [EC97] Andy Evans and T Clark. Foundations of the Uni ed Modeling Language. In Proc. of the 2nd BCS-FACS Northern Formal Methods Workshop, Ilkley, UK, 23-24 September 1997, 1997. [FB97] Robert France and Jean-Michel Bruel. Integrated informal objectoriented and formal modeling techniques. In Haim Kilov and Bernhard Rumpe, editors, Proceedings ECOOP'97 Workshop on Precise Semantics for Object-Oriented Modeling Techniques, pages 83{89. Technische Universitat Munchen, TUM-I9725, 1997. [FBLPS97] Robert France, Jean-Michel Bruel, M. Larrondo-Petrie, and M. Shro. Exploring the Semantics of UML type structures with Z. In Bowman H. and Derrick J. E, editors, Proc. 2nd IFIP Workshop on Formal Methods for Open Object-Based Distributed Systems (FMOODS), pages 247{260. Chapman and Hall, 1997. [FC99] Liliana Favre and Sylvia Clerici. A Bridge between UML Class Diagrams and Algebraic Speci cations. In 14th Workshop on Algebraic Development Techniques, Bonas, France, september 1999.

[GBB+ 97] N. Guel , O. Biberstein, D. Buchs, E. Canver, M-C. Gaudel, F. von Henke, and Scwier. Comparison of Object-Oriented Formal Methods. Technical report, Deliverable du Projet ESPRIT LTR 20072-DEVA, 1997. Second year report, Deliverables : part2 (papers), page 52. [GG89] Stephan Garland and John Guttag. An overview of LP, the Larch Prover. In Proc. of the third International Conference on Rewriting Techniques and Applications, volume 355 of Lecture Notes in Computer Science. SpringerVerlag, 1989. [GH93] John V. Guttag and James J. Horning, editors. Larch: Languages and Tools for Formal Speci cation. Texts and Monographs in Computer Science. Springer Verlag, 1993. With Stephen J. Garland, Kevin D. Jones, Andres Modet, and Jeannette M. Wing. [GM87] Joseph A. Goguen and Jose Meseguer. Unifying Functional, ObjectOriented and Relational Programming with Logical Semantics, pages 417{ 477. Computer Systems Series. Bruce Shriver and Peter Wegner, Research Directions in Object-Oriented Programming, 1987. [HCRT99] Heinrich Hussmann, Maura Cerioli, Gianna Reggio, and Francoise Tort. Abstract Data Types and UML Models. In 14th Workshop on Algebraic Development Techniques, Bonas, France, september 1999. [HHK98a] A. Hamie, J. Howse, and S. Kent. Interpreting the Object Constraint Language. In Proceedings of Asia Paci c Conference in Software Engineering. IEEE Press, January 1998. [HHK98b] A. Hamie, J. Howse, and S. Kent. Modular Semantics for Object-Oriented Models. In Proceedings of Northern Formal Methods Workshop, eWics Series. Springer Verlag, August 1998. [Ing86] Daniel H. H. Ingalls. A Simple Technique for Handling Multiple Polymorphism. In Norman Meyrowitz, editor, Proceedings of the 1986 ACM Conference on Object-Oriented Programming Systems, Languages and Applications, pages 347{349, Portland, OR, october 1986. ACM SIGPLAN. [KD66] K. Nygaard K. and O-J. Dahl. Simula an Algol-based Simulation Language. C.ACM, 9:671{678, September 1966. [LB98] Kevin Lano and Juan Bicarregui. Semantics and transformations for UML models. In Pierre-Alain Muller and Jean Bezivin, editors, Proceedings of UML'98 International Workshop, Mulhouse, France, June 3 - 4, 1998, pages 97{106. ESSAIM, Mulhouse, France, 1998. [Mey88] Bertrand Meyer. Object-oriented Software Construction. International Series in Computer Science. Prentice Hall, 1988. [RJB99] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Uni ed Modeling Language Reference Manual. Addison-Wesley, 1999. [Roy92] Jean-Claude Royer. A New Set Interpretation for the Inheritance Relation and its Checking. ACM OOPS MESSENGER, 3(3):22{40, july 1992. [Roy98] Jean-Claude Royer. Type Checking Object-Oriented Programs: Core of the Problem and Some Solutions. Journal of Object-Oriented Programming, 11(6):58{66, october 1998. ISSN 0896-8438. [Roy99] Jean-Claude Royer. UML and ADT: A First Approach to Semantics and Veri cations. Research Report 187, Institut de Recherche en Informatique de Nantes, september 1999. [Wir90] Martin Wirsing. Algebraic Speci cation, volume B of Handbook of Theoretical Computer Science, chapter 13, pages 675{788. Elsevier, 1990. Jan Van Leeuwen, Editor.