12 - OOSC - Object Design (Specifying Interfaces)

Chapter 12:
Object Design (Specifying Interfaces)
Object-Oriented
SoftwareConstruction
Armin B. Cremers, Sascha Alda & Tobias Rho

(based on Bruegge & Dutoit)
Announcement Practice Talk
♦ Michael Mahlberg (TCG – The Consulting Guild GmbH)
“Experiences with (and without!) coupling and

cohesion from industry”
Thursday, 29th 2006

16:30 (B-IT Lecture Hall)
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 2
Object Design: Closing the Gap
System
Problem
Application objects
Requir ements gap
Solution objects
Custom objects
Object design gap
Off-the-shelf components
System design gap
Machine
Object Design – Interface Design
Requirements analysis activities

Identifying first attributes and operations without specifying their types
or their parameters.
Goal of Interface Design:

Describe the Interface of each object precisely enough so that objects
realized by individual developers fit together with minimal Integration
problems
Activities:
Identify missing attributes and operations from analysis object and
subsystem service
Specify Visibility and Signatures
Specify Contracts (main focus in this lecture)
Developers play different Roles during
Object Design
Class User Call Class
Developer Class Implementor Realize Class
Class Extender Refine Class
Example for the relationship from viewpoint
of abstract class “Game”
Developers responsible for
Developers responsible for the implementation of Game are
the implementation of League are class implementors
class users of Game
League Game
1
*
Tournament TicTacToe Chess
The developer responsible for

the implementation of TicTacToe
is a class extender of Game
Add Visibility Information
UML defines three levels of visibility:

Private (Class implementor):
A private attribute can be accessed only by the class in which it is
defined.
A private operation can be invoked only by the class in which it is
defined.
Private attributes and operations cannot be accessed by subclasses or
other classes.
Protected (Class extender):
A protected attribute or operation can be accessed by the class in which
it is defined and on any descendent (subclass) of the class.
Public (Class user):
A public attribute or operation can be accessed by any class.
Implementation of UML Visibility
in Java
Tournament
- maxNumPlayers: int
+ getMaxNumPlayers():int
+ getPlayers(): List
# removePlayer(p:Player)
+ acceptPlayer(p:Player)
+ isPlayerAccepted(p:Player):boolean
public class Tournament {

private int maxNumPlayers;
public Tournament(League l, int maxNumPlayers)

public int getMaxNumPlayers() {…};
protected void removePlayer(Player p) {…};
public List getPlayers() {…};
public void acceptPlayer(Player p) {…};
public boolean isPlayerAccepted(Player p) {…};
Information Hiding Heuristics
Carefully define the public interface for classes as well as subsystems

(façade)
Always apply the “Need to know” principle.
Only if somebody needs to access the information, make it publicly
available, but then only through well defined channels, so you always
know the access.
The fewer an operation knows
the less likely it will be affected by any changes
the easier the method can be changed
Information hiding is not a major issue during analysis, however
during design it is a problem.
Information Hiding Design Principles
Only the operations of a class are allowed to manipulate

its attributes
Access attributes only via operations.
// Can be accessed directly // Can’t be accessed directly

public Object myAttr = … ; private Object myAttr = … ;
public void getMyAttr(){
return this.myAttr;
}
Add Type Signature Information
Hashtable
-numElements:int
+put()
+get()
+remove()
+containsKey()
+size()
Hashtable
Attributes and operations -numElements:int
without type information +put(key:Object,entry:Object)
are acceptable during analysis +get(key:Object):Object
+remove(key:Object)
+containsKey(key:Object):boolean
+size():int
Design by Contract
Idea: Contracts on a class enable caller (client) and callee (class
itself) to share the same assumptions (semantics) about the class.
Problem: Accurate Semantics cannot be added to standard UML
models discussed so far
Solution/Realization: Design By Contract by Betrand Meyer
(“Object-Oriented Software Construction”, Prentice Hall)
Process of developing software based on the notion of contracts
between objects
Contracts are expressed as assertions (predicates)
Assertions comprise preconditions, postconditions and invariants
Types of Assertions
Precondition:
Preconditions are predicates associated with a specific operation and
must be true before the operation is invoked.
Preconditions are used to specify constraints that a caller must meet
before calling an operation.
Postcondition:
Postconditions are predicates associated with a specific operation and
must be true after an operation is invoked.
Postconditions are used to specify constraints that the object (callee)
must ensure after the invocation of the operation.
Examples of Assertions
Assertion of List method “add”
PreCondition
list != null //List exists
key.instanceOf(String)
List
-list:Collection
+add(key:Object)
+create():void
+remove(key:Object)
+size():int
PostCondition
size = size +1;
containsKey( key ) = true;
Design by Contract
Parties in the contract: class and client
PreCondition binds clients
PostCondition binds class
Contract important for Class User (Client) and Class Implementor
(class)
Contract entails benefits and obligations for both parties
Example
Contract for add

Obligations Benefits
of class List
Only call add() on a Can retrieve item by

Class User non-full and existing List containsKey( );
Make sure that key is in the Does not need to care

Class Implementor List; List has increased by one about Cases, where List
is full or not created
Class invariants and class correctness
Preconditions and postconditions describe properties of individual

methods
Need for global properties of instances which must be preserved by
all routines
Examples (List)
Size of List must not be negative
Size of List must be lower than 1000 entries
The number of elements must be even
Class invariants and class correctness
A class invariant is an assertion to be satisfied by all instances of the

class at all “stable” times (instance in stable state):
on instance creation
before and after every remote call to a routine
may be violated during call
A class invariant only applies to public methods; private methods are

not required to maintain the invariant.
Invariant Rule
An assertion I is a correct class invariant for a class C iff the

following two conditions hold:
The constructor of C, when applied to arguments satisfying the
constructor’s precondition in a state where the attributes have
their default values, yields a state satisfying I.
Every public method of the class, when applied to arguments and
a state satisfying both I and the method’s precondition, yields a
state satisfying I.
Design by Contract
Inheritance
What does inheritance mean in relation to Design by Contract?
Î Overridden methods must conceptually do the same job!
Contract Inheritance
Rule of Thumb: Demand no more, promise no less.
Design by Contract
Inheritance
Demand no more:
A method of subclass is allowed to weaken the preconditions of
the method it overrides
An overridden method with a weaker precondition can handle more
cases than its superclass
Promise no less:
A method must ensure a stronger postcondition than the method
it overrides
An overridden method with a stronger postcondition ensures more
specific cases to the client upon return
Design by Contract
Inheritance – Example 1
A method of subclass is allowed to weaken the preconditions of the
method it overrides. Example (1)
List PreCondition P1
-list:Collection list != null //List exists
+add(key:Object)
+create():void
+remove(key:Object)
+size():int
Correct!
NewList
New PreCondition P2
+add(key:Object) list != null //List exists
Design by Contract
A method of subclass is allowed to weaken the preconditions of the
method it overrides. Example (2)
List PreCondition P1
-list:Collection list != null //List exists
+add(key:Object)
+create():void key.instanceOf(String)
+remove(key:Object)
+size():int
Violated!
NewList
New PreCondition P2
+add(key:Object) list != null //List exists
Length(key) < 10
Design by Contract
A method must ensure a stronger postcondition as the method it
overrides: Example:
List PostCondition P1
-list:Collection size = size +1;
+add(key:Object) containsKey( key ) = true;
+create():void
+remove(key:Object) size > 10
+size():int
Violated!
NewList
PostCondition P2
+add(key:Object) size = size +1;
size > 2
Design by Contract
A method must ensure a stronger postcondition as the method it
overrides: Example:
List PostCondition P1
-list:Collection size = size +1;
+add(key:Object) containsKey( key ) = true;
+create():void
+remove(key:Object) size > 3
+size():int
Correct!
NewList
New PostCondition P2
+add(key:Object) size = size +1;
size > 9
Application of Design by Contract
The Liskov Substitution Principle:

“If an object of type S can be substituted in all places where an
object of Type T is expected, then S is a subtype of T”
Client T
If all preconditions of the methods of type S are weakened and all

postconditions of the methods of type S are stronger than the
methods of type T, then S is a subtype of type T
Client do not has to change its code, if object T is substituted by S
Advantages of Design By Contract
Improves the reliability of programs

Assertions provide accurate documentation for the
implemented classes so that a programmer knows how to
use the classes and what to expect from them;
Assertions provide a way of controlling inheritance
(substitutability)
Assertions can be an important aid to developing critical
systems.
Expressing constraints in UML Models
OCL 2.0 (Object Constraint Language) is part of UML 2.0
OCL allows constraints to be formally specified on single model elements
(attributes, operations, classes) or groups of model elements
(associations and participating classes)
A constraint is expressed as an OCL expression returning the value true
or false.
OCL is not a procedural language (cannot constrain control flow).
More Info:
Introduction of OCL for Together
http://bdn1.borland.com/devcon05/article/1,2006,33187,00.html
Tutorial of University of Koblenz

http://www.uni-koblenz.de/~beckert/Lehre/Praktikum-Formale-Entwicklung/oclIntro.pdf
OCL expressions for Hashtable operation put():
The context keyword indicates the object to which the
expression is valid
Context is a class
Invariant:
context Hashtable inv: numElements >= 0 OCL expression
Precondition:
context Hashtable::put(key, entry) pre:!containsKey(key)
Post-condition:
context Hashtable::put(key, entry) post: containsKey(key) and
get(key) = entry
A constraint can also be depicted as a note attached to the

constrained UML element by a dependency relationship.
<<invariant>>
numElements >= 0
<<precondition>> HashTable
!containsKey(key) numElements:int <<postcondition>>
get(key) == entry
<<precondition>> put(key,entry:Object)
containsKey(key) get(key):Object
remove(key:Object)
<<precondition>> containsKey(key:Object):boolean
containsKey(key) size():int <<postcondition>>
!containsKey(key)
Contract for acceptPlayer in
Tournament
context Tournament::acceptPlayer(p) pre:

not isPlayerAccepted(p)
context Tournament::acceptPlayer(p) pre:

getNumPlayers() < getMaxNumPlayers()
context Tournament::acceptPlayer(p) post:

isPlayerAccepted(p)
Contract for acceptPlayer in
Tournament
context Tournament::removePlayer(p) pre:

isPlayerAccepted(p)
context Tournament::removePlayer(p) post:

not isPlayerAccepted(p)
context Tournament::removePlayer(p) post:

getNumPlayers() = @pre.getNumPlayers() - 1
@pre.= value returned by

method before invoking
value returned by removePlayer
method after invoking
removePlayer
OCL Annotations
JavaDoc (iContract)
public class Tournament { /** The acceptPlayer() operation
/** The maximum number of players * assumes that the specified
* is positive at all times. * player has not been accepted
* @invariant maxNumPlayers > 0 * in the Tournament yet.
*/ * @pre !isPlayerAccepted(p)
* @pre getNumPlayers()<maxNumPlayers
private int maxNumPlayers; * @post isPlayerAccepted(p)
* @post getNumPlayers() =
/** The players List contains * @pre.getNumPlayers() + 1
* references to Players who are */
* are registered with the public void acceptPlayer (Player p)
* Tournament. */ {…}
private List players;
/** The removePlayer() operation
/** Returns the current number of * assumes that the specified player
* players in the tournament. */ * is currently in the Tournament.
* @pre isPlayerAccepted(p)
public int getNumPlayers() {…} * @post !isPlayerAccepted(p)
* @post getNumPlayers() =
/** Returns the maximum number of @pre.getNumPlayers() - 1
* players in the tournament. */ */
public int getMaxNumPlayers() {…} public void removePlayer(Player p) {…}
Constraints can involve more than
one class
♦ Until now: Constraints are valid within a single class

♦ Often, Constraints are necessary to declare assertions
across many classes
Make Assumptions about associations between classes
Definition of global invariants
♦ Expressions for navigating between classes are necessary
♦ Set-based operations
Types of Navigation through a Class
Diagram
1. Local attribute 2. Directly related class 3. Indirectly related class

Tournament League League
start:Date *
end:Date
* *
Player Tournament
*
*
Player
Any OCL constraint for any class diagram can be built

using only a combination of these three navigation types!
Example: League, Tournament and
Player
League
*
+start:Date
+end:Date
+getActivePlayers()
* tournaments
Tournament
+start:Date
+end:Date
+acceptPlayer(p:Player)
* tournaments
* players
players
Player
*
+name:String
+email:String
Model Refinement with 2 additional
Constraints
♦ A Tournament’s planned duration must be under one week.
♦ Players can be accepted in a Tournament only if they are already
registered with the corresponding League.
OCL Collections
♦ Collections are data types used to navigate to associated

classes within a constraint expression.
OCL Sets
Used to navigate a single (1:1, 1:n, or n:m) association
League chess:League
*
Player Bob:Player Isa:Player Marc:Player
league.player = {Bob, Isa, Marc}
OCL Collections
♦ Collections are data types used to navigate to associated

classes within a constraint expression.
OCL Bags
Used to navigate through a series of at least two associations with
one-to-many or many-to-many multiplicity
League chess:League
WM: EM:
* Tournament Tournament
Tournament
* Bob:Player Isa:Player Marc:Player
*
Player
league.tournament.player = {Bob, Isa, Marc,Isa}
OCL Collections
♦ OCL provides many operations for accessing collections (via

Access Operator Æ). Examples:
includes(Object) – returns true if Object is in Collection
union(Collection) – returns a Collection containing elements from
both the original collection and the collection
specified as paramater
asSet(Collection) – returns a Set containing each element of the
collection without any duplicate elements (as
opposed to a bag)
♦ Examples:
{Bob, Isa, Marc}Æincludes( Timo ) = false;
league.tournament.player = {Bob, Isa, Marc,Isa}
league.tournament.playerÆasSet = {Bob, Isa, Marc}
Specifying the Model Constraints
Local attribute navigation *

League
context Tournament inv: +start:Date

+end:Date
end - start <= Calendar.WEEK +getActivePlayers()
Directly related class navigation

{ordered}
context * tournaments
Tournament::acceptPlayer(p)
pre: Tournament
league.players->includes(p) +start:Date
+end:Date
+acceptPlayer(p:Player)
* tournaments
* players
players
Player
*
+name:String
+email:String
OCL supports Quantification
♦ OCL forAll quantifier

forAll (variable | expression) is true, if expression is true for all
elements in the collection
Example: All Matches m in a Tournament t occur within the
Tournament’s time frame:
context Tournament inv:
matches->forAll( m:Match |
m.start.after(t.start) and m.end.before(t.end))
♦ OCL exists quantifier
exists ( variable | expression ) is true if there is at least one
element in the collection for which expression is true
Example: Each Tournament conducts at least one Match on the
first day of the Tournament:
context Tournament inv:
matches->exists(m:Match | m.start.equals(start))
Realization of Constrains in
Programming Language: Java
♦ Often realized in terms of conventional exception handling
♦ Assertions to check pre- and postconditions within methods can be
used since JDK 1.4
♦ The validation of Assertions must be enabled (is disabled by default)
Boolean expression (must be true at runtime,an

AssertionError is thrown, otherwise)
Optional indication of a Message-String

for the AssertionError Objekt
Start:
Start:
java Assertions
x=0
java.lang.ArithmeticException:
/ by zero …
Compilation: java –ea Assertions

x=0
/ by 0
Realization of OCL in Java
♦ Only view OCL compilers and parsers are available.

♦ Dresden OCL Toolkit
Generates Java Code for given OCL assertions
Runtime Evaluation of Assertions
Web: http://dresden-ocl.sourceforge.net/aboutproject.html
♦ IBM OCL Parser
Checking of syntax only, no Code Generation
Web: http://www-306.ibm.com/software/awdtools/library/standards/ocl-
download.html
♦ Together Borland
Summary
♦ There are three different roles for developers during object design
Class user, class implementor and class extender
♦ During object design - and only during object design - we specify
visibility rules
♦ Constraints are boolean expressions on model elements
♦ Contracts are constraints on a class enable class users, implementors
and extenders to share the same assumption about the class
(“Design by contract”)
♦ OCL is a language that allows us to express constraints on UML
models
♦ Complicated constratins involving more than one class, attribute or
operation can be expressed with 3 basic navigation types.

12 - OOSC - Object Design (Specifying Interfaces)

Uploaded by

Copyright:

Available Formats

12 - OOSC - Object Design (Specifying Interfaces)

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

12 - OOSC - Object Design (Specifying Interfaces)

Uploaded by

Copyright:

Available Formats

Chapter 12:

Object Design (Specifying Interfaces)

Armin B. Cremers, Sascha Alda & Tobias Rho

♦ Michael Mahlberg (TCG – The Consulting Guild GmbH)

“Experiences with (and without!) coupling and

 Thursday, 29th 2006

Requir ements gap

Object design gap

System design gap

 Requirements analysis activities

 Goal of Interface Design:

Class User Call Class

Developer Class Implementor Realize Class

Class Extender Refine Class

The developer responsible for

UML defines three levels of visibility:

public class Tournament {

public Tournament(League l, int maxNumPlayers)

 Carefully define the public interface for classes as well as subsystems

 Only the operations of a class are allowed to manipulate

// Can be accessed directly // Can’t be accessed directly

Contract for add

Only call add() on a Can retrieve item by

Make sure that key is in the Does not need to care

 Preconditions and postconditions describe properties of individual

 A class invariant is an assertion to be satisfied by all instances of the

 A class invariant only applies to public methods; private methods are

 An assertion I is a correct class invariant for a class C iff the

 Rule of Thumb: Demand no more, promise no less.

 The Liskov Substitution Principle:

 If all preconditions of the methods of type S are weakened and all

 Improves the reliability of programs

 Tutorial of University of Koblenz

 A constraint can also be depicted as a note attached to the

context Tournament::acceptPlayer(p) pre:

context Tournament::acceptPlayer(p) pre:

context Tournament::acceptPlayer(p) post:

context Tournament::removePlayer(p) pre:

context Tournament::removePlayer(p) post:

context Tournament::removePlayer(p) post:

@pre.= value returned by

♦ Until now: Constraints are valid within a single class

1. Local attribute 2. Directly related class 3. Indirectly related class

Any OCL constraint for any class diagram can be built

♦ Collections are data types used to navigate to associated

league.player = {Bob, Isa, Marc}

♦ Collections are data types used to navigate to associated

* Bob:Player Isa:Player Marc:Player

♦ OCL provides many operations for accessing collections (via

Local attribute navigation *

context Tournament inv: +start:Date

Directly related class navigation

♦ OCL forAll quantifier

Boolean expression (must be true at runtime,an

Optional indication of a Message-String

Compilation: java –ea Assertions

♦ Only view OCL compilers and parsers are available.

You might also like

Thursday, 29th 2006

Requirements analysis activities

Goal of Interface Design:

Carefully define the public interface for classes as well as subsystems

Only the operations of a class are allowed to manipulate

Preconditions and postconditions describe properties of individual

A class invariant is an assertion to be satisfied by all instances of the

A class invariant only applies to public methods; private methods are

An assertion I is a correct class invariant for a class C iff the

Rule of Thumb: Demand no more, promise no less.

The Liskov Substitution Principle:

If all preconditions of the methods of type S are weakened and all

Improves the reliability of programs

Tutorial of University of Koblenz

A constraint can also be depicted as a note attached to the