Translating the object constraint language into the java modelling language

Translating the Object Constraint Language into the JavaModelling LanguageAli HamieSchool of Computing, Mathematical and Information SciencesUniversity of BrightonBrighton, UKa.a.hamie@ABSTRACTThe Object Constraint Language OCL is a textual specification language that could be used for constraining the modelling elements that occur in UML diagrams. Typical constraints include class invariants and preconditions and postconditions of operations. The Java Modelling Language (JML) is a behavioural interface specification language designed for specifying Java classes and interfaces. This paper defines a translation of OCL expressions and constraints into the Java Modelling Language. The objective of this translation is to be able to map UML object-oriented designs with OCL constraints to Java classes and interfaces annotated with JML specifications, and to carry out logical reasoning about such classes and interfaces using JML tools which include a run time assertion checker and an interactive prover based on PVS.KeywordsOCL, JML, UML, constraints, reasoning1.INTRODUCTIONThe Unified Modelling Language UML [11][12] is widely accepted as the standard for object-oriented modelling and is supported by a number of CASE tools. The Object Constraint Language OCL [10][14] is a part of UML, and was introduced to express additional constraints on object-oriented models that diagrams cannot convey by themselves. The type of constraints that can be expressed using OCL include invariants on classes and types, preconditions and postconditions of operations.Java [1] is a popular and widely used programming language. The Java Modelling Language JML [6][7] is a specification language specifically developed to specify Java classes and interfaces. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.SAC’04, March 14-17, 2004, Nicosia, CyprusCopyright 2004 ACM 1-58113-812-1/03/04...$5.00.The constraints that can be expressed and specified include invariants of classes and interfaces, and preconditions and postconditions of methods. The assertion language of JML is based on Java expressions following the lead of Eiffel [9]. In addition JML supports various constructs and operators such as universal and existential quantifications that are essential for greater expressiveness. The approach of JML is model based like VDM [5] and Z [13] which means that JML specifications can be expressed abstractly in terms of mathematical models such as sets, bags and sequences. JML also provides a library of model types (sets, bags, etc.) to be used in specifications defined as pure Java classes. The advantage of this approach is that the same notation (in this case Java) which will be familiar to object-oriented programmers is used throughout the specification. JML also supports specification only variables (or fields) which is necessary for complete and expressive specifications. In addition, JML specifications allow frame conditions to be expressed and specified [2]. A number of tools [8] that manipulate and check JML specifications are available including a runtime assertion checker [3].This paper presents a translation of OCL expressions and constraints into JML. This translation could be used for mapping object-oriented design models expressed in UML and OCL to Java classes and interfaces annotated with JML specifications. JML is specifically designed for specifying Java programs whereas OCL is not specific to any one programming language. For this reason JML is better suited for specifying the detailed design of a Java program than a generic language like OCL. In the development of a Java application using UML/OCL, one can use the translation so that JML is used for the specification of object constraints in the later stages of the development. The benefits of this include the use of a wide range of tools that support JML for reasoning about specifications, and for the testing and verification of programs. The mapping could also be incorporated within CASE tools that generate Java code from UML diagrams.The paper is organised as follows. Section 2 shows how OCL basic types are translated. Section 3 shows how collections and their operators are translated. Section 4 shows how OCL iterator expressions are translated. Section 5 shows how other constructs are translated. Section 6 provides the conclusion.2.TRANSLATING OCL BASIC TYPESThe OCL supports the following basic types Boolean, Integer, Real and String. OCL expressions of type Boolean are translated to corresponding JML boolean expressions, i.e. expressions of type boolean. The boolean operators and, or, implies, not are translated into the corresponding JML operators &&, ||, ==>, !. Equality of boolean expressions is mapped to the JML equality ==, but it can also be represented by the operator <==>. More formally, we define µ to denote the mapping that takes an OCL expression and provides the corresponding JML expression. If b1and b2 are boolean expressions, then we have:µ(b1 and b2) = µ(b1) &&µ(b2)µ(b1 or b2) = µ(b1) ||µ(b2)µ(b1 implies b2) = µ(b1) ==>µ(b2)µ(not b1) = !µ(b1)µ(b1 = b2) = µ(b1) <==>µ(b2)The OCL types Integer, Real and String are mapped to the types long, double, and String respectively. Operators and expressions on these types are mapped easily.3.TRANSLATING COLLECTIONOPERATORSOCL provides a common supertype Collection(T) for the collection types Set(T), OrderedSet(T), Bag(T), and Sequence(T). The supertype Collection(T) is defined to be abstract so it does not occur in actual OCL constraints, but it is used to define features that all collection types have in common (e.g. the size function).JML defines some model types that represent various kinds of collections implemented as Java classes. All of the collections implement the interface JMLCollection. Collections are divided into two kinds: object and value collections. The elements of object collections are object references. These include JMLObjectSet, JMLObjectBag, JMLObjectSequence and so on. All of these treat their elements as object references (addresses) and don’t care about the values of these objects. For example, objects of type JMLObjectSet are sets of object references. When an object is inserted into such a set, it is not cloned. The equality test used by the membership method has uses Java’s == operator to compare addresses of these objects. In contrast, the value collections, such as JMLValueSet, JMLValueBag, JMLValueSequence contain object values. The objects references stored in such a collection are merely representatives of the corresponding equivalence classes (of all objects with the same value). For example, objects of JMLValueSet are sets of values. When an object is inserted into such a set, it is cloned, so that later changes to the object do not affect its value. The equality test used by the has method uses the equals method of the object’s class. To support cloning, all of the value collection types contain elements that implement the JMLType interface.The OCL type Set(T) contains finite sets with elements from type T. If type T is one of the basic types (i.e. Integer, Boolean, Real, String), then Set(T) is mapped to JMLValueSet. Each set s of Set(T) is then mapped to a set of type JMLValueSet with an additional constraint expressing that the elements of the translated set belong to a suitable JML type. For example if s is of type Set(Integer) then the corresponding set µ(s) belongs to JMLValueSet and satisfies the following constraint:(\forall JMLType e; µ(s).has(e);e instanceof JMLLong)where JMLLong is a reflection of Long that implements JMLType. For the other basic types similar constraints are needed using the types JMLBoolean, JMLFloat and JMLString.If the type T is an object type which corresponds to a class on a class diagram, then Set(T) is mapped to JMLObjectSet. Again each set s is mapped to an object set of type JMLObjectSet with the following constraint:(\forall Object e; µ(s).has(e);e instanceof T)For example, given a class Person representing person objects, a set s : Set(Person) is mapped to a set of type JMLObjectSet with the following constraint:(\forall Object p; µ(s).has(p);p instanceof Person)where Person is the corresponding Java class.In a similar way other collection types such as bags and sequences are mapped to the corresponding JML collection types JMLValueBag, JMLObjectBag, JMLValueSequence, and JMLObjectSequence.3.1Translating EqualityThe equality between OCL collections is denoted by “=”. For example, if s1 and s2 are of type Set(T), the assertion s1 = s2 is true if and only if the two sets contain the same elements. Since JML collection types are defined as pure Java classes, using == as the equality between collections will give the wrong results in the presence of the new operator. Instead the defined method equals is used to compare collections for equality. Thus, we have µ(s1 = s2) = µ(s1).equals(µ(s2)). This mapping works if both s1and s2 contain either values or objects, because equals is defined in both JMLValueSet and JMLObjectSet. In the type JMLValueSet it is defined in terms of equality between values (i.e. equals) and in JMLObjectSet it is defined in terms of equality between objects (i.e. ==). For other OCL collections the mapping of equality is very similar.3.2Translating the Common OperatorsIn this section the operators common to all collection types are translated into JML. Most of these operators will be translated into the methods that are their direct counterparts defined in JML library of collection types.The OCL expression c->size() returns the size of the collection c. This is translated as µ(c->size()) = µ(c).size().The expression E = c->includes(e) expresses that e is an element in the collection c. It is translated as µ(E) = µ(c).has(µ(e)). The expression E = c->excludes(e) expresses that e is not an element in the collection c. This can be treated as the negation of includes, thus µ(E) = !µ(c).has(µ(e)).The expression E = c1->includesAll(c2) expresses that the collection c1 is subcollection of c2. If c1 is a set, then the expression E is translated as:µ(E) = µ(c1).isSuperset(convertFrom(µ(c2))) where convertFrom is a static method that converts a collection into a set. In the translation the name of the method convertFrom will be qualified with the appropriate class which is in this case can be JMLvalueSet or JMLObjectSet depending on whether c2 is a value or object set. If c1 is a bag, we have:µ(E) = µ(c1).isSuperbag(convertFrom(µ(c2)))In the case where c1 is a sequence, we have:µ(E)=µ(c1).isSupersequence(convertFrom(µ(c2)))The expression E = c1->excludesAll(c2) expresses that no element of c2 is an element of c1. The operation excludesAll does not have a corresponding method in JML. One way to translate it is to use universal quantification as follows:µ(E) = (\forAll T e;µ(c2).has(e);!µ(c2).has(e)) The expression E = c->isEmpty() is true when the collection c is empty and false otherwise. The translation of E is given as follows µ(E) = µ(c).isEmpty(). The expression E = c->notEmpty() expresses that c is not empty and can be treated as the negation of isEmpty. Thus µ(E) = !µ(c).isEmpty().The expression E = c->sum() adds the elements of the collection c. The elements must be of type supporting the + operation. This is translated using the JML sum operator \sum as follows µ(E) = (\sum T e; µ(c).has(e);e).3.3Translating Set OperatorsThis section considers some of the operators defined on sets.The expression E = s->union(s1) denotes the union of the sets s and s1. It is translated as µ(E) = µ(s).union(µ(s1)).The expression E = s->union(b) denotes the union of the set s and the bag b. The value of the expression is a bag. JML does not support such an operation. However, this can be translated by converting the set into a bag and use the union operation on bags. That is µ(E) = µ(s).toBag().union(µ(b)).The expression E = s->intersection(s1) denotes the intersection of the sets s and s1. It is translated as follows µ(E) = µ(s).intersection(µ(s1)).The expression E = s->intersection(b) denotes the intersection of the set s and the bag b. The value of the expression is a set. JML does not support such an operation. However this can be translated as µ(s).intersection(µ(b).toSet()).The expression E = s-s1 denotes the difference between s and s1. It is translated as µ(E) = µ(s).difference(µ(s1).The expression E = s->including(e) denotes the set containing all the elements of s plus e. It is translated as follows µ(E)=µ(s).insert(µ(e)). The expression E =s->excluding(e) denotes the set containing all the elements of s without e. It is translated as µ(E) = µ(s).remove(µ(e).The expression E = s->count(e) denotes the number of occurrences of e in s. JML does not have a corresponding method on sets. However, this can be translated by using the conditional expression and method size as µ(E) = µ(s).has(µ(e)?1 : 0. The expression E = s->asBag() returns a bag containing all the elements of s. The expression is translated using the method toBag as µ(E) = µ(s).toBag(). The expression E = s->asSequence() returns a sequence containing all the elements of s in undefined order. It is translated as follows µ(E) = µ(s).toSequence().The operator flatten flattens the set if its elements are themselves collections. JML does not support a corresponding method. However, it is useful to have a method that flattens collection of collections. In this case the translation of E = s->flatten() can be given by µ(E) = µ(s).flatten().3.4Translating Bag OperatorsThis section considers some of the operators defined on bags.The expression E = b->union(b1) denotes the union of the bags b and b1. It is translated as µ(E) = µ(b).union(µ(b1)).The expression E = b->union(s) denotes the union of the bag b and the set s. The value of the expression is a bag. JML does not support such an operation. However, this can be translated by converting the set into a bag and use the union operation on bags. That is µ(E) = µ(b).union(µ(s).toBag()).The expression E = b->intersection(b1) denotes the intersection of the bags b and b1. This expression is translated as follows µ(E) = µ(b).intersection(µ(b1)).The expression E = b->intersection(s) denotes the intersection of the bag b and the set s. The value of the expression is a set. JML does not support such an operation. This can be translated as µ(b).toSet().intersection(µ(s)).The expression E = b->including(e) denotes the bag containing all the elements of b plus e. This expression is translated as µ(E) = µ(b).insert(µ(e)).The expression E = b->excluding(e) denotes the bag containing all the elements of b apart from all occurrences of e. It is translated as µ(E) = µ(b).removeAll(µ(e).The expression E = b->count(e) denotes the number of occurrences of e in b. This expression is translated as µ(E) = µ(b).count(e).The expression E = b->asSet() returns a set containing all the elements of b. The expression is translated using the method toSet as µ(E) = µ(b).toSet(). The expression E = b->asSequence() returns a sequence containing all the elements of b in undefined order. It is translated as µ(E) = µ(b).toSequence().3.5Translating Sequence OperatorsThis section considers some of the operators defined on sequences.The expression E = s->union(s1) denotes the union of the sequences s and s1. The result is the sequence consisting of all the elements in s, followed by all the elements in s1. It is translated as µ(E) = µ(s).concat(µ(s1)).The expression E = s->including(e) denotes the sequence containing all the elements of s plus e added as the last element. It is translated as µ(E) = µ(s).insertBack(µ(e)).The expression E = s->append(e) denotes the sequence of elements, consisting of all the elements of s followed by e. It is translated as µ(E) = µ(s).insertBack(µ(e)).The expression E = s->insert(i, e) denotes the sequence consisting of s with e inserted at position i. It is translated as follows µ(E) = µ(s).insertBeforeIndex(i,µ(e)).The expression E = s->first() denotes the first element of s. It is translated as µ(E) = µ(s).first(). The expression E= s->last() denotes the last element of s, and translated as µ(E) = µ(s).last().The expression E = s->at(i) denotes the ith element of s, and is translated as µ(E) = µ(s).itemAt(i-1). The expression E = s->indexOf(e) denotes the index of element e in s. It is translated as µ(E) = µ(s).indexOf(µ(e)).4.TRANSLATING ITERATOREXPRESSIONSThe OCL supports a number of iterator expressions. The semantics of these expressions is defined in terms of the iterate construct. The expression E = c->exists(e : T | p(e)) is true if the boolean expression p(e) evaluates to true for at least one element in the collection c. In a sense this provides a restricted form of existential quantification where it is quantified over a finite collection. JML provides the operator \exists for existential quantification. Thus, the expression E is translated as follows µ(E) = (\exists T e;µ(c).has(e);µ(p)). The case with more than one iterator is treated in a similar way.The expression E = c->forAll(e : T | p(e)) is true if the boolean expression p(e) evaluates to true for each element in the collection c. Again, this provides a restricted form of universal quantification where it is quantified over a finite collection. JML provides the operator \forall for universal quantification. Thus, E is translated as µ(E ) =(\forall T e;µ(c).has(e);µ(p)). The case with more than one iterator is treated in a similar way. The expression E = c->select(e : T | p(e)) denotes the collection consisting of those elements of c for which the predicate p evaluates to true when e is instantiated with the element. JML does not have a corresponding operation for filtering collections except a form of set comprehension. Thus if c is a set and T is an object type, the expression is translated as µ(E) = new JMLObjectSet{T e | µ(c).has(e)&& µ(p)}. Bags and sequences comprehension is not supported in JML, however these can be represented by using set comprehension together with some auxiliary methods. For example, if b is a bag, then we form the following set:s = new JMLObjectSet{T e| b.toSet().has(e)&& p}Using the set s and the bag b, we build a bag consisting of all the elements of s where the number of occurrences of each element is equal to the number of occurrences of that element in b. This can be formalised by adding a new method buildFrom on bags with the following specification:public JMLObjectBag buildFrom(JMLObjectSet s) requires (s.toBag()).isSubbag(this);ensures (\forall Object e;;result.has(e)<==> (s.has(e)&& result.count(e) = this.count(e))); Sequence comprehension can be simulated in JML in a similar way by converting the sequence to a set, apply set comprehension, and then define a method that builds a sequence from the obtained set and the original sequence.The expression E = c->reject(e : T | p(e)) denotes the collection consisting of those elements of c for which the predicate p evaluates to false when e is instantiated with the element. This can be treated in a similar way to select by negating the predicate p. The expression E = c->collect(e : T | exp) denotes the collection of elements which results from applying exp to every element of c. The result is flattened. JML does not support such an operator and it is not easy to translate it using the existing JML constructs. Therefore it seems sensible to introduce a primitive construct (\collect T e; c.has(e);exp) with the result type depending on the collection c.5.TRANSLATING OTHER OCLCONSTRUCTSThe OCL operators oclIsKindOf and oclIsTypeOf allow to check which type the value of an expression exp has. The translation of exp.oclIsKindOf(T) is µ(exp) instanceof T. The translation of exp.oclIsTypeOf(T) is \typeof(µ(exp)) == \type(T), where \typeof returns the most specific dynamic type of an expression’s value, and \type is used to represent types in expressions.The expression T.allInstances() returns all the instances of type T at a point in time. The operator allInstances may only be used on types (classifiers) that have a finite number of instances. This is normally the case for user defined classes since instances need to be created explicitly. Hence, the operator cannot be applied to String, Integer and Real types. JML does not have a corresponding operator. For this we introduce the operator \allInstances, thus the translation of T.allInstances() is \allInstances(T).The expression E = exp.oclIsNew() returns true of the expression exp refers to a newly created object and false otherwise. It is intended to be used in the postconditions of operations. It is translated as µ(E) = \fresh( µ(exp)).The translation of an OCL variable v is a JML variable with the same name, i.e. µ(v) = v.To translate literals of collections, in case they enumerate the elements of a collection, a JML set is constructed using the collection constructors and the insert method. For example,µ(Set{1,2}) = new JMLValueSet().insert(Integer(1)).insert(Integer(2)) For bags and sequences the translation is similar.6.CONCLUSIONThis paper presented a mapping of OCL expressions and constraints into the Java Modelling Language JML. The mapping can be used for translating object-oriented design models expressed in UML and OCL to Java classes and interfaces annotated with JML specifications. Because JML is tailored to Java, it seems that it is better suited for recording and specifying the detailed design of a Java program than a generic langauge like OCL. Hence, in the development of a Java application using UML/ OCL, it may be better to use JML rather than OCL for the specification of constraints, especially in the later stages of the development. This also ensures that the various tools that support JML could be used for testing and verifying the correctncess of programs with respect to their specifications. The mapping could also be incorporated within CASE tools that generate Java code from UML diagrams. The JML types in the org.jmlspecs.models package are intended to (loosely) correspond to the libraries of mathematical concepts found in theorem provers, such as PVS. The mapping makes it possible to add new packages of such types tailored to OCL. REFERENCES[1]Arnold, K. and Gosling, J., The Java programmingLanguage. The Java Series. Addisson-Wesley, Reading,MA, second edition, 1998.[2]Borgida, A., Mylopoulos, J., and Reiter, R., On the frameproblem in procedure specifications. IEEE Transactions onSoftware Engineering, 21(10): 785-798, October, 1995. [3]Cheon, Y. and Leavens, G., A Runtime Assertion Checkerfor the Java Modeling Language (JML). In SoftwareEngineering Research and Practice (SERP’02), pages 322-328. CSREA Press, June 2002.[4]Guttag, J., Horning, J., Garland, S., Jones, K., Modet, A.,and Wing, J.. Larch : Languages and Tools for FormalSpecification. Springer Verlag, New York, 1993.[5]Jones B. C. Systematic Software Development usingVDM. Prentice Hall 1990.[6]Leavens G., Baker A., and Ruby C., JML: A notation fordetailed design. In Haim Kilov, Bernhard Rumpe, and IanSimmonds, editors, Behavioral Specifications ofBusinesses and Systems, pages 175-188. KluwerAcademic Publishers, Boston, 1999.[7]Leavens G., Baker A., and Ruby C., Preliminary Design ofJML: A Behavioral Interface Specification Language forJava. TR98-06, revised version 2003.[8]Leavens G., Rustan K., Leino M., Poll E., Ruby C., andJacobs B., JML: notations and tools supporting detaileddesign in Java. In OOPSLA 2000 Companion,Minneapolis, Minnesota, pages 105-106. ACM, October2000.[9]Meyer, B., Eiffel: The Language. Object-oriented Series.Prentice Hall, New york, N. Y., 1992.[10]Rational Software Corporation. The Object ConstraintLanguage Specification Version 2.0. Available at, 2003.[11]Rational Software Corporation. The Unified ModelingLanguage UML Version 2.0. Available at, 2003.[12]Rumbaugh J., Jacobson I., and Booch G., The UnifiedModelling Language Reference manual. Addison-Wesley,Reading, Mass., 1998.[13]Spivey, The Z Notation: A Reference Manual.International Series in Computer Science. Prentice-Hall,New York, N. Y., second edition, 1992.[14]Warmer, J., and Kleppe, A., The Object ConstraintLanguage: Precise Modelling with UML. Addison-Wesley,1999.。