12 - OOSC - Object Design (Specifying Interfaces)

8/11/2019 12 - OOSC - Object Design (Specifying Interfaces)

1/45

Armin B. Cremers, Sascha Alda & Tobias Rho(based on Bruegge & Dutoit)

Object-OrientedSoftwareConstruction

Chapter 12:Object Design (Specifying Interfaces)


2/45

Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 2

Announcement Practice Talk

Michael Mahlberg (TCG The Consulting Guild GmbH)

Experiences with (and without!) coupling andcohesion from industry

Thursday, 29th 2006 16:30 (B-IT Lecture Hall)


3/45


Object Design: Closing the Gap

Custom objects

Application objects

Off-the-shelf components

Solution objects

System Problem

Machine

System design gap

Object design gap

Requir ements gap


4/45


Object Design Interface Design

Requirements analysis activities

Identifying first attributes and operations without specifying their typesor their parameters.

Goal of Interface Design:

Describe the Interface of each object precisely enough so that objectsrealized 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)


5/45


Developers play different Roles duringObject Design

Developer

Call Class

Class Extender

Class Implementor

Class User

Realize Class

Refine Class


6/45


7/45


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 isdefined.

A private operation can be invoked only by the class in which it isdefined.

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 whichit is defined and on any descendent (subclass) of the class.

Public (Class user): A public attribute or operation can be accessed by any class.


8/45


Implementation of UML Visibilityin Java

Tournament

- maxNumPlayers: int

# removePlayer(p:Player)+ acceptPlayer(p:Player)

+ getMaxNumPlayers():int+ getPlayers(): List

+ isPlayerAccepted(p:Player):boolean

publicTournament(League l, int maxNumPlayers)

public intgetMaxNumPlayers() {};protected voidremovePlayer(Player p) {};

publicList getPlayers() {};

public voidacceptPlayer(Player p) {};

public booleanisPlayerAccepted(Player p) {};

public classTournament {

private intmaxNumPlayers;


9/45


Information Hiding Heuristics

Carefully define the public interface for classes as well as subsystems(faade)

Always apply the Need to know principle.

Only if somebody needs to access the information, make it publiclyavailable, but then only through well defined channels, so you alwaysknow 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, howeverduring design it is a problem.


10/45


Information Hiding Design Principles

Only the operations of a class are allowed to manipulateits attributes

Access attributes only via operations.

// Can be accessed directly

public Object myAttr = ;

// Cant be accessed directly

private Object myAttr = ;

public void getMyAttr(){

return this.myAttr;

}


11/45


Add Type Signature Information

Hashtable

+put(key:Object,entry:Object)+get(key:Object):Object

+remove(key:Object)+containsKey(key:Object):boolean+size():int

-numElements:int

Hashtable

+put()

+get()+remove()+containsKey()+size()

-numElements:int

Attributes and operationswithout type information

are acceptable during analysis


12/45


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


13/45


Types of Assertions

Precondition:

Preconditions are predicates associated with a specific operation andmust be true before the operation is invoked.

Preconditions are used to specify constraints that a caller must meetbefore calling an operation.

Postcondition:

Postconditions are predicates associated with a specific operation andmust be true afteran operation is invoked.

Postconditions are used to specify constraints that the object (callee)must ensure after the invocation of the operation.


14/45


Examples of AssertionsAssertion of List method add

List

+add(key:Object)+create():void+remove(key:Object)+containsKey(key:Object):boolean+size():int

-list:Collection

PreCondition

list != null //List exists

key.instanceOf(String)

PostCondition

size = size +1;containsKey( key ) = true;


15/45


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


16/45


Example

Contract for add

of class List

Class User

Class Implementor

Obligations Benefits

Only call add() on a

non-full and existing List

Make sure that key is in the

List; List has increased by one

Can retrieve item by

containsKey( );

Does not need to care

about Cases, where Listis full or not created


17/45


Class invariants and class correctness

Preconditions and postconditions describe properties of individualmethods

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


18/45


Class invariants and class correctness

A class invariant is an assertion to be satisfied by all instances of theclass 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.


19/45


20/45


Design by ContractInheritance

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.


21/45


Design by ContractInheritance

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 morecases 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


22/45


Design by ContractInheritance Example 1

A method of subclass is allowed to weaken the preconditions of the

method it overrides. Example (1)

List


-list:Collection

NewList

+add(key:Object)New PreCondition P2


PreConditionP1



Correct!


23/45


List

+add(key:Object)+create():void+remove(key:Object)+containsKey(key:Object):boolean

+size():int

-list:Collection

NewList

+add(key:Object)

A method of subclass is allowed to weaken the preconditions of the

method it overrides. Example (2)

Violated!

New PreCondition P2



Length(key) < 10

PreConditionP1





24/45


A method must ensure a stronger postcondition as the method it

overrides: Example:

Violated!


List


-list:Collection

NewList

+add(key:Object)

PostConditionP2

size = size +1;

containsKey( key ) = true;

size > 2

PostConditionP1

size = size +1;


size > 10


25/45


A method must ensure a stronger postcondition as the method it

overrides: Example:

Correct!


List


-list:Collection

NewList

+add(key:Object)

New PostCondition P2

size = size +1;


size > 9

PostConditionP1

size = size +1;


size > 3


26/45


Application of Design by Contract

The Liskov Substitution Principle:

If an object of type S can be substituted in all places where anobject of Type T is expected, then S is a subtype of T

If all preconditions of the methods of type S are weakened and allpostconditions of the methods of type S are stronger than themethods 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

T

S

Client


27/45


Advantages of Design By Contract

Improves the reliability of programs

Assertions provide accurate documentation for the

implemented classes so that a programmer knows how touse the classes and what to expect from them;

Assertions provide a way of controlling inheritance(substitutability)

Assertions can be an important aid to developing criticalsystems.


28/45


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


29/45



OCL expressions for Hashtable operation put():

The context keyword indicates the object to which theexpression is valid

Invariant:

context Hashtable inv: numElements >= 0 OCL expression

Context is a class

Precondition: context Hashtable::put(key, entry) pre:!containsKey(key)

Post-condition:

context Hashtable::put(key, entry) post: containsKey(key) andget(key) = entry


30/45


A constraint can also be depicted as a note attached to theconstrained UML element by a dependency relationship.

!containsKey(key)

containsKey(key)

containsKey(key)

get(key) == entry

!containsKey(key)

numElements >= 0

HashTable

put(key,entry:Object)

get(key):Objectremove(key:Object)containsKey(key:Object):booleansize():int

numElements:int


C t t f tPl i


31/45


Contract for acceptPlayer inTournament

contextTournament::acceptPlayer(p) pre:

not isPlayerAccepted(p)

contextTournament::acceptPlayer(p) pre:getNumPlayers() < getMaxNumPlayers()

contextTournament::acceptPlayer(p) post:

isPlayerAccepted(p)

Contract for acceptPlayer in


32/45


contextTournament::removePlayer(p) pre:

isPlayerAccepted(p)

contextTournament::removePlayer(p) post:not isPlayerAccepted(p)

contextTournament::removePlayer(p) post:

getNumPlayers() = @pre.getNumPlayers() - 1

Contract for acceptPlayer inTournament

@pre.= value returned bymethod before invoking

removePlayervalue returned bymethod afterinvoking

removePlayer

OCL Annotations


33/45


public classTournament {

/** The maximum number of players* is positive at all times.* @invariant maxNumPlayers > 0*/

private intmaxNumPlayers;

/** The players List contains* references to Players who are* are registered with the* Tournament. */

privateList players;

/** Returns the current number of* players in the tournament. */

public intgetNumPlayers() {}

/** Returns the maximum number of* players in the tournament. */

public intgetMaxNumPlayers() {}

/** The acceptPlayer() operation* assumes that the specified* player has not been accepted* in the Tournament yet.* @pre !isPlayerAccepted(p)* @pre getNumPlayers()


34/45


Constraints can involve more thanone 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


35/45


Types of Navigation through a ClassDiagram

Tournament

start:Dateend:Date

League

Player Tournament

League

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

*

*

*

*

Player*

Any OCL constraint for any class diagram can be builtusing only a combination of these three navigation types!

Example: League Tournament and


36/45


Example: League, Tournament andPlayer

players

* tournaments

Tournament

+start:Date+end:Date

+acceptPlayer(p:Player)

*League

+start:Date+end:Date

+getActivePlayers()

* Player

+name:String+email:String

* players

tournaments*

Model Refinement with 2 additional


37/45


Model Refinement with 2 additionalConstraints

A Tournaments planned duration must be under one week.

Players can be accepted in a Tournament only if they are already

registered with the corresponding League.


38/45


OCL Collections

Collections are data types used to navigate to associatedclasses within a constraint expression.

OCL Sets

Used to navigate a single (1:1, 1:n, or n:m) association

League

Player

*

*

chess:League

Isa:Player Marc:PlayerBob:Player

league.player = {Bob, Isa, Marc}


39/45


OCL Collections

Collections are data types used to navigate to associatedclasses within a constraint expression.

OCL Bags

Used to navigate through a series of at least two associations withone-to-many or many-to-many multiplicity

League

Tournament

*

chess:League

Isa:Player Marc:PlayerBob:Player*

*Player

WM:

Tournament

EM:

Tournament

league.tournament.player = {Bob, Isa, Marc,Isa}

OCL C ll i


40/45


OCL Collections

OCL provides many operations for accessing collections (viaAccess Operator ). Examples:

includes(Object) returns true if Object is in Collection

union(Collection) returns a Collection containing elements fromboth the original collection and the collectionspecified as paramater

asSet(Collection) returns a Set containing each element of the

collection without any duplicate elements (asopposed to a bag)

Examples:

{Bob, Isa, Marc}includes( Timo ) = false;

league.tournament.player = {Bob, Isa, Marc,Isa}

league.tournament.playerasSet = {Bob, Isa, Marc}

S if i th M d l C t i t


41/45


Specifying the Model Constraints

Local attribute navigationcontext Tournamentinv:

end - start includes(p)

OCL Q ifi i


42/45


OCL supports Quantification

OCL forAll quantifier

forAll (variable | expression) is true, if expression is true for allelements in the collection

Example: All Matches m in a Tournament toccur within theTournaments time frame:

contextTournament 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 oneelement in the collection for which expression is true

Example: Each Tournament conducts at least one Match on thefirst day of the Tournament:

contextTournament inv:matches->exists(m:Match | m.start.equals(start))

Realization of Constrains in


43/45


Programming Language: Java

Often realized in terms of conventional exception handling

Assertions to check pre- and postconditions within methods can beused since JDK 1.4

The validation of Assertions must be enabled (is disabled by default)

Compilation:

Start:

Boolean expression (must be true at runtime,anAssertionError is thrown, otherwise)

Start:

java Assertions

x = 0java.lang.ArithmeticException:

/ by zero

java ea Assertions

x = 0

/ by 0

Optional indication of a Message-String

for the AssertionError Objekt

Realization of OCL in Java


44/45


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

S mmar


45/45


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 specifyvisibility rules

Constraints are boolean expressions on model elements

Contracts are constraints on a class enable class users, implementorsand extenders to share the same assumption about the class(Design by contract)

OCL is a language that allows us to express constraints on UMLmodels

Complicated constratins involving more than one class, attribute or

operation can be expressed with 3 basic navigation types.

12 - OOSC - Object Design (Specifying Interfaces)

Documents