1. Interpreting the Object Constraint Presented by: Ed Kausmeyer

2. Historical Note About Paper From Sept. 1998 UML had only recently become the universal modeling language

3. Object Constraint Language (OCL) Forms part of UML Precise textual language that allows the expression of constraints in object-oriented (OO) systems that can’t be expressed using standard diagrammatic notations Requires that some parts of a model already be defined in diagrams

4. Purpose of Paper Propose a semantics to check that OCL is unambiguous and to improve OCL Provide a semantics for classes, states, associations, and attributes Set the stage for the creation of CASE (computer-aided software engineering) tools that support integrity checking of whole UML models, not just integrity checking of the parts defined in OCL

5. Navigation in OO Modeling Following links from one object to locate another object or collection of objects

6. Navigation: An Example At the right is a UML class diagram for a system that supports scheduling of offerings of seminars to a collection of attendees by presenters who must be qualified for the seminars they present

7. Navigation: An Example Navigation expressions start with objects Ex. Declare a variable s that refers to an instance of the Seminar object: s : Seminar A navigation expression is written using an attribute or role name, & an optional parameter list Ex. The value of the title attribute for the object represented by s is given by s.title The name self can be used in expressions referring to the object on which an operation is called Ex. For an instance of Seminar, self.title

8. Navigation: An Example Navigating from an object via an association role can result in a single object or a collection Ex. For p:Presenter, p.qualifiedFor results in a set of seminars p is qualified for s.offering ( s is a Seminar ) results in a sequence since the association between Seminar & Offering has the annotation {ordered} on the offering role

9. Navigation: An Example For the declaration p:Presenter, p.qualifiedFor.title (which can also be expressed as p.qualifiedFor- >collect(title) ) involves navigating first from a single object & then from a collection (of seminars the presenter is qualified for), finally resulting in a bag (of titles of seminars the presenter is qualified for) Navigating from a bag yields a bag (and similarly from a sequence and from a set)

10. Navigation: An Example Navigation expressions can be used for expressing invariants (which must be true at all times for all instances of a specific object) Ex. The following means a presenter must be qualified for all seminars he is assigned to present: Presenter: self.qualifiedFor- >includesAll(self.o ffering.seminar) Preconditions & postconditions can be expressed; the value of a property at the start of an operation is denoted by postfixing the property name with @pre Ex. The following operation marks a presenter as absent by canceling his presentations within specific dates: markAsAbsent(p:Presenter, from, to: Date) pre: true post: p.offering@pre->forAll(o | o.date >= from and o.date <= to implies o.presenter = Set{})

11. Semantics: Class Diagrams Provide a semantics for OCL expressions and UML class diagrams using Larch Shared Language (LSL) Traits: LSL specification modules that describe abstract data types and theories

12. Semantics of Object Types & Attributes Object type: description of a set of objects in terms of properties & behavior they all share; represented in LSL as a basic sort consisting of elements that uniquely represent instances of the object type, which can be thought of as object identifiers; an object’s attributes are formalized as functions on the sort representing the object Ex. In LSL, the Presenter object type is represented by a sort of Presenter identifiers while the name attribute is represented as a function with the signature name:Presenter  String

13. Semantics of Associations Associations: relationships between objects; object types & attributes can have binary associations Each association in a class diagram has two role names that can be used for navigation Ex. The association between Presenter and Seminar has the names qualified and qualifiedFor Associations are represented in LSL as two related functions that satisfy certain axioms; the functions are defined in a way that is independent of the structures of the object types involved, resulting in a generic Larch theory for associations that can be renamed to specify each particular association in the model Ex. The association between Presenter & Seminar is represented as two functions with the signatures qualified: Set[Seminar]  Set[Presen ter] & qualifiedFor: Set[Presenter]  Set[Semi nar] where Set[Seminar] & Set[Presenter] are the power sorts of Seminar & Presenter

14. Collections & Their Operations Collection is defined in OCL as an abstract type with the concrete types Set, Sequence, & Bag as its subtypes The Collection object type can be represented in LSL as a sort with certain axioms & functions while the Set, Sequence, & Bag object types can be represented as abstract data types Since LSL does not support subsorting, the function toCollection must be overloaded to handle the following three signatures to map each subtype to the supertype (let Collection[T] be the sort of collections of type T ): toCollection:Set[T]  Collection[T] toCollection:Bag[T]  Collection[T] toCollection:Sequence[T]  Collection[T]

15. The Select and Reject Operations Provide ways to specify subsets of a collection The select operation is specified as collection->select(v: T | b-expr-v) where v is the iterator that refers to objects from collection & b-expr-v is a boolean expression; this operation results in a subset of all elements for which the boolean expression evaluates to true ; applying this operation to a set, sequence, & bag results in a set, sequence, & bag, respectively; select can be realized in LSL by defining certain functions & axioms The reject operation is the same as select except that it results in a subset of all elements for which the boolean expression evaluates to false (i.e., collection-> reject(v:T|b-expr-v) is equivalent to collection-> select(v:T|not(b-expr-v)) )

16. The Collect Operation The collect operation is given by collection->collect(v: T | expr-v), which returns the collection of the results of all the evaluations of expr-v ; the meaning of the collect operation is given by the functions with the signatures collect f : Collection[T]  Collection[S] and f:T  S, where f(v)=expr-v ; this means a collection of one object type can be derived from another collection of a different object type; different functions must be defined to support the polymorphism of the collect operation when translating from OCL to LSL (for example, the function collect f : Set[T]  Bag[S] is needed for translation since applying the collect operation in OCL to a set results in a bag); it is necessary to define certain axioms as well In OCL, applying a property to a collection of objects is interpreted as a collect over the members of the collection with the specified property; i.e., for any propertyname of objects in a collection, collection.propertyname is equivalent to collection- >collect(propertyname)

17. Quantifications: forAll & exists Operations forAll operation: specified by collection- >forAll(v: T | b-expr-v) ; returns true if the boolean expression b-expr-v evaluates to true for all elements in collection & returns false otherwise The exists operation returns true if there is at least one element in collection for which the boolean expression b-expr-v evaluates to true

18. The Iterate Operation Specified by collection->iterate(v: T; acc: S = expr | expr-v-acc) v is used to iterate over collection and expr-v-acc is evaluated for each v. After each evaluation of expr-v-acc, its value is assigned to acc. In this way, the value of acc is built up during the iteration of collection Its meaning can be expressed by iterate f,expr : Collection[T]  S and f:T,S  S, where f(v,acc)==expr-v-acc This operation provides a mechanism to iterate through a collection & evaluate the elements in that collection

19. System State Define an LSL system state sort  Define a function  :   Set[T] that returns the set of existing objects of type T in a given state  The operation T.allInstances that returns the set of all instances of object type T is interpreted as the set  (  ) Associations & attributes of object types are interpreted as functions with additional arguments for the system states Ex. The attribute title is interpreted as the function title: Seminar,   String

20. Invariants, Preconditions, & Postconditions Each expression in invariants, preconditions, & postconditions is interpreted as a function & has a universal quantifier added to it In the following example invariant presented earlier ------- Presenter: self.qualifiedFor- >includesAll(self.offering.seminar) -------- self.qualifiedFor is interpreted as qualifiedFor(self,  ) while self.offering.seminar is interpreted as seminar(offering(self,  ),  ) The invariant then becomes  p: Presenter,  :  seminar(offering(self,  ),  )  qualifiedFor(self,  )

21. Summary of mapping elements from OCL to LSL

22. Article Bibliographical Information Hamie, Ali, John Howse and Stuart Kent. Interpreting the Object Constraint Language. 28 Sept. 1998. Division of Computing, University of Brighton, Lewes Rd., Brighton, UK. Scholarly Paper. Available at http://www.cs.ukc.ac.uk/pubs/1998/784/content.p df