1. Chapter 9: Object Design: Specifying Interfaces

2. Object Design
Object design is the process of adding details to the requirements analysis and making implementation decisions
The object designer must choose among different ways to implement the analysis model with the goal to minimize execution time, memory and other measures of cost.
Requirements Analysis: The functional model and the dynamic model deliver operations for the object model
Object Design: We decide on where to put these operations in the object model
Object design serves as the basis of implementation

3. Object Design: Closing the Gap

4. Plan for the next Lectures
1. Reuse: Identification of existing solutions
Use of inheritance
Off-the-shelf components and additional solution objects
Design patterns
2. Interface specification
Describes precisely each class interface
3. Object model restructuring
Transforms the object design model to improve its understandability and extensibility
4. Object model optimization
Transforms the object design model to address performance criteria such as response time or memory utilization.
Object
Design
lectures
Mapping
Models to Code
lecture

5. Interface Specification
Motivation
How can developers communicate clearly and precisely the details of the classes so that they can make reliable assumptions about the classes they did not implement?

6. Developers play different Roles during Object Design
Call Class
Class Extender
Class Implementor
Class User
Realize Class
Refine Class

7. Class user versus Class Extender
Developers responsible for
the implementation of Game are
class implementors
Developers responsible for
the implementation of League are
class users of Game
League
Game 1 *
TicTacToe
Chess
Tournament
The developer responsible for
the implementation of TicTacToe
is a class extender of Game

8. Specifying Interfaces
Requirements analysis activities
Identifying attributes and operations without specifying their types or their parameters.
Object design: Three activities
Add visibility information
Add type signature information
Add contracts

9. 1. 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 of the class.
Public (Class user):
A public attribute or operation can be accessed by any class.

10. Implementation of UML Visibility in Java
Tournament
- maxNumPlayers: int
+ acceptPlayer(p:Player)
+ removePlayer(p:Player)
+ getMaxNumPlayers():int
+ getPlayers(): List
+ isPlayerAccepted(p:Player):boolean
public class Tournament {
private int maxNumPlayers;
public Tournament(League l, int maxNumPlayers)
public int getMaxNumPlayers() {…};
public List getPlayers() {…};
public void acceptPlayer(Player p) {…};
public void removePlayer(Player p) {…};
public boolean isPlayerAccepted(Player p) {…};

11. 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 possible, 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 class can be changed
Trade-off: Information hiding vs efficiency
Accessing a private attribute might be too slow (for example in real-time systems or games)
Information hiding is not a major issue during analysis, however during design it is a problem.
Limit the effect of changes so that changes can be understood clearly and do not cause a major recompilation of the whole system (also called black box design)

12. Information Hiding Design Principles
Only the operations of a class are allowed to manipulate its attributes
Access attributes only via operations.
Hide external objects at subsystem boundary
Define abstract class interfaces which mediate between system and external world as well as between subsystems
Do not apply an operation to the result of another operation.
Write a new operation that combines the two operations.

13. 2. Add Type Signature Information
Hashtable
+put()
+get()
+remove()
+containsKey()
+size()
-numElements:int
Attributes and operations
without type information
are acceptable during analysis
Hashtable
+put(key:Object,entry:Object)
+get(key:Object):Object
+remove(key:Object)
+containsKey(key:Object):boolean
+size():int
-numElements:int

14. 3. Add Contracts
Contracts on a class enable caller and callee to share the same assumptions about the class.
Contracts include three types of constraints:
Invariant:
A predicate that is always true for all instances of a class. Invariants are constraints associated with classes or interfaces.
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 must ensure after the invocation of the operation.

15. Expressing constraints in UML Models
OCL (Object Constraint Language)
OCL allows constraints to be formally specified on single model elements or groups of model elements
A constraint is expressed as an OCL expression returning the value true or false. OCL is not a procedural language (cannot constrain control flow).
OCL expressions for Hashtable operation put():
Invariant:
context Hashtable inv: numElements >= 0
OCL expression
Context is a class
operation put
Precondition:
context Hashtable::put(key, entry) pre: !containsKey(key)
Post-condition:
context Hashtable::put(key, entry) post: containsKey(key) and get(key) = entry

16. Expressing Constraints in UML Models
A constraint can also be depicted as a note attached to the constrained UML element by a dependency relationship.
<<invariant>>
numElements >= 0
HashTable
<<precondition>>
!containsKey(key)
<<postcondition>>
get(key) == entry
numElements:int
put(key,entry:Object)
get(key):Object
remove(key:Object)
containsKey(key:Object):boolean
size():int
<<precondition>>
containsKey(key)
<<postcondition>>
!containsKey(key)
<<precondition>>
containsKey(key)

17. Contract for acceptPlayer in Tournament
context Tournament::acceptPlayer(p) pre:
not isPlayerAccepted(p)
getNumPlayers() < getMaxNumPlayers()
context Tournament::acceptPlayer(p) post:
isPlayerAccepted(p)
getNumPlayers() + 1
Value of the object or attribute before execution of the method

18. Contract for removePlayer in Tournament
context Tournament::removePlayer(p) pre:
isPlayerAccepted(p)
context Tournament::removePlayer(p) post:
not isPlayerAccepted(p)
getNumPlayers() - 1

19. Real and Integer Operators
Steve Webster, dec.bournemouth.ac.uk
Downloaded from

20. String Operators

21. gender = #male implies title = ‘Mr. ‘
Using Enumerations
Customer
gender: enum{male, female} name: String title: String dateOfBirth: Date
gender = #male implies title = ‘Mr. ‘

22. Boolean Operators

23. Other Special Keywords
self
An instance of the context
result
In postconditions, it refers to the return value of the context method

24. JavaDoc Annotation of Tournament class
public class Tournament {
/** The maximum number of players  * is positive at all times. maxNumPlayers > 0  */
private int maxNumPlayers;
/** The players List contains    * references to Players who are  * are registered with the  * Tournament. */
private List players;
/** Returns the current number of  * players in the tournament. */
public int getNumPlayers() {…}
/** Returns the maximum number of  * players in the tournament. */
public int getMaxNumPlayers() {…}
/** The acceptPlayer() operation  * assumes that the specified  * player has not been accepted * in the Tournament yet. !isPlayerAccepted(p) getNumPlayers()<maxNumPlayers isPlayerAccepted(p) getNumPlayers() = * @pre.getNumPlayers() + 1 */
public void acceptPlayer (Player p) {…}
/** The removePlayer() operation * assumes that the specified player * is currently in the Tournament. isPlayerAccepted(p) !isPlayerAccepted(p) getNumPlayers() = @pre.getNumPlayers() - 1 */
public void removePlayer(Player p) {…} }

25. Constraints can involve more than one class
How do we specify constraints on
more than one class?

26. 3 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 * * *
Tournament
Player * *
Player
Any OCL constraint for any class diagram can be built
using a combination of these three navigation types

27. Association Navigation in OCL
Association navigation is realized using the opposite rolename.
object.rolename – the set of objects on the other side of the association
If the rolename is missing, then the name of the class with lowercase first letter is used.
If there are multiple types of associations between two classes, then rolenames are required.
League
From context of League
self.tournaments refers to the set of objects of class Tournament associated with this league.
From context of Tournament
self.player refers to the set of objects of class Player associated with this tournament
tournaments *
Tournament * *
Player

28. ARENA Example: League, Tournament and Player
players *
tournaments
{ordered}
Tournament
+start:Date
+end:Date
+acceptPlayer(p:Player)
League
+getActivePlayers()
Player
+name:String
+ String

29. Model Refinement with 3 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.
The number of active Players in a League are those that have taken part in at least one Tournament of the League.
To better understand these constraints we instantiate the class diagram for a specific group of instances
2 Leagues, 2 Tournaments and 5 Players

30. Instance Diagram: 2 Leagues, 2 Tournaments, and 5 Players
alice:Player
bob:Player
marc:Player
winter:Tournament
tttExpert:League
joe:Player
xmas:Tournament
chessNovice:League
start=Dec 21
end=Dec 22
start=Dec 23
end=Dec 25
zoe:Player

31. Specifying the Model Constraints
Local attribute navigation
context Tournament inv:
end - start <= Calendar.WEEK
players *
tournaments
{ordered}
Tournament
+start:Date
+end:Date
+acceptPlayer(p:Player)
League
+getActivePlayers()
Player
+name:String
+ String
Directly related class navigation
context Tournament::acceptPlayer(p) pre:
league.players->includes(p)

32. Specifying the Model Constraints
Local attribute navigation
context Tournament inv:
end - start <= Calendar.WEEK
Directly related class navigation
context Tournament::acceptPlayer(p) pre:
league.players->includes(p)
Indirectly related class navigation
context League::getActivePlayers post:
result = tournaments.players->asSet
players *
tournaments
{ordered}
Tournament
+start:Date
+end:Date
+acceptPlayer(p:Player)
League
+getActivePlayers()
Player
+name:String
+ String

33. OCL Collections Sets Sequences Bags
Used when navigating a single association
Sequences
Used when navigating a single ordered association
Bags
Unlike sets, bags can contain the same object multiple times
Used to accumulate objects when accessing indirectly related objects

34. Operations on Collections

35. Collection hierarchy Collection Set Bag Sequence
minus symmetricDifference asSequence asBag
asSequence asSet
first last at(int) append prepend asBag asSet

36. OCL supports Quantification
OCL forall quantifier
/* All Matches in a Tournament 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
/* 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))

37. 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 constraints involving more than one class, attribute or operation can be expressed with 3 basic navigation types.

38. Additional Slides

39. ARENA’s object model identified during the analysis
TournamentForm 1 1
applyForTournament()
TournamentControl *
selectSponsors()
advertizeTournament()
acceptPlayer()
announceTournament() * 1 1
Tournament
name *
start * * *
players
end
sponsors * *
Player
Advertiser
acceptPlayer()
removePlayer()
schedule() *
matches *
Match
matches *
start
status
playMove()
getScore()

40. Adding type information to ARENA’s object model
TournamentForm 1 1
+applyForTournament()
TournamentControl *
+selectSponsors(advertisers):List
+advertizeTournament()
+acceptPlayer(p)
+announceTournament()
+isPlayerOverbooked():boolean * 1 1
Tournament
+name:String
+start:Date
+end:Date * * * *
players
sponsors * *
Player
Advertiser
+acceptPlayer(p)
+removePlayer(p)
+schedule() *
matches *
Match
matches *
+start:Date
+status:MatchStatus
+playMove(p,m)
+getScore():Map

41. Pre- and post-conditions for ordering operations on TournamentControl
+selectSponsors(advertisers):List
+advertizeTournament()
+acceptPlayer(p)
+announceTournament()
+isPlayerOverbooked():boolean
Pre- and post-conditions for ordering operations on TournamentControl
context TournamentControl::selectSponsors(advertisers) pre:
interestedSponsors->notEmpty and
tournament.sponsors->isEmpty
context TournamentControl::selectSponsors(advertisers) post:
tournament.sponsors.equals(advertisers)
context TournamentControl::advertiseTournament() pre:
tournament.sponsors->isEmpty and
not tournament.advertised
context TournamentControl::advertiseTournament() post:
tournament.advertised
context TournamentControl::acceptPlayer(p) pre:
tournament.advertised and
interestedPlayers->includes(p) and
not isPlayerOverbooked(p)
context TournamentControl::acceptPlayer(p) post:
tournament.players->includes(p)

42. Specifying invariants on Tournament and Tournament Control
All Matches of in a Tournament must occur within the time frame of the Tournament
context Tournament inv: matches->forAll(m| m.start.after(start) and m.start.before(end))
No Player can take part in two or more Tournaments that overlap
context TournamentControl inv: tournament.players->forAll(p| p.tournaments->forAll(t| t <> tournament implies not t.overlap(tournament)))

43. Specifying invariants on Match
players *
Player
Tournament *
tournaments
players *
matches
Match *
A match can only involve players who are accepted in the tournament
context Match inv: players->forAll(p| p.tournaments->exists(t| t.matches->includes(self)))
context Match inv: players.tournaments.matches.includes(self)