LECTURE NO 16

INTERFACE SPECIFICATION(PART2)
Prepared by:
Ms.Sundas Shujah
Lecturer CS, COMSATS Abbottabad
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE

• A constraint can be expressed in natural language or in a formal language

such as Object Constraint Language (OCL) .
• OCL is a language that allows constraints to be formally specified on single
model elements (e.g., attributes, operations, classes) or groups of
model elements (e.g., associations and participating classes).
• A constraint is expressed as a boolean expression returning the value True or
False.
• A constraint can be depicted as a note attached to the constrained UML
element by a dependency relationship.

Fall2019
Fall2019
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE

• Textual OCL:
• Attaching OCL expressions to diagrams can lead to clutter.
• For this reason, OCL expressions can be alternatively expressed in a textual
form.
• For example, the invariant for the Tournament class requiring the attribute
maxNumPlayers to be positive is written as follows:
context Tournament inv:
self.getMaxNumPlayers() > 0

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE

• The context keyword indicates the entity to which the expression applies. This
is followed by one of the keywords inv, pre, and post, which correspond to
the UML stereotypes «invariant», «precondition», and «postcondition»,
respectively.
• Then follows the actual OCL expression. OCL’s syntax is similar to object-
oriented languages such as C++ or Java.
• However, OCL is not a procedural language and thus cannot be used to
denote control flow.
• Operations can be used in OCL expressions only if they do not have any side
effects.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE

• For invariants, the context for the expression is the class associated with the
invariant.
• The keyword self (e.g., self.numElements) denotes all instances of the class.
• Attributes and operations are accessed using the dot notation (e.g.
self.maxNumPlayers accesses maxNumPlayers in the current context).
• The self keyword can be omitted if there is no ambiguity.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE

• For preconditions and postconditions, the context of the OCL expression is

an operation.
• The parameters passed to the operation can be used as variables in the
expression. For example,
• consider the following precondition on the acceptPlayer() operation in
Tournament:
context Tournament::acceptPlayer(p:Player) pre:
!isPlayerAccepted(p)

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE
• The variable p in the constraint !isPlayerAccepted(p) refers to the parameter
p passed to the acceptPlayer(p) operation.
• As this is a precondition, the constraint must be True before the execution of
the acceptPlayer(p) operation. Hence, the constraint reads in English:
• “acceptPlayer(p) assumes that p has not yet been accepted in the
Tournament”.
We can write several preconditions for the same operation. If there are
more than one precondition for a given operation, all preconditions
must be True before the operation can be invoked.
For example, we can also state that the Tournament must not yet have
reached the maximum number of Players
before invoking acceptPlayer():
context Tournament::acceptPlayer(p:Player) pre:
getNumPlayers() < getMaxNumPlayers()
Fall2019
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE

• Post conditions are written in the same way as preconditions, except for the
keyword post
• indicating that the constraint is evaluated after the operation returns. For
example, the following
• postcondition on acceptPlayer(p) states that the Player p should be known
to the Tournament after acceptPlayer() returns:
context Tournament::acceptPlayer(p:Player) post:
isPlayerAccepted(p)

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
OBJECT CONSTRAINT LANGUAGE

• For postconditions, we often need to refer to the value of an attribute before

and after the execution of the operation. For this purpose, the suffix @pre
denotes the value of self or an attribute before the execution of the
operation.
• For example, if we want to state that the number of Players in the
Tournament increases by one with the invocation of acceptPlayer(), we
need to refer to the value of getNumPlayers() before and after the
invocation of acceptPlayer().
• We can write the following postcondition:
context Tournament::acceptPlayer(p:Player) post:
getNumPlayers() = self@pre.getNumPlayers() + 1

Fall2019