Interpreting the Object Constraint
Presented by: Ed Kausmeyer
Historical Note About Paper
• From Sept. 1998
• UML had only recently become the
universal modeling language
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
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
Navigation in OO Modeling
• Following links from one object to locate
another object or collection of objects
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
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
•
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
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)
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{})
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
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
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
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]
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)))
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 collectf : 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 collectf :
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)
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
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 iteratef,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
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
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,)
Summary of mapping elements from OCL to LSL
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.pd
f