1. OBJECT DESIGN • Now we need to design in such detail that the design can be implemented. • It will be important to know, which structures the programming language supports, in order not to use inappropriate constructs. • E.g. Java does not support multiple inheritance -> use interfaces instead in such situations.

2. Class Diagram Before Design Player Piece Card color: Integer use name: String 0..1 effect (p: Pelaaja) funds: Integer 0..1 move(p: Place) getPlace(): Paikka isAtAirport(): Boolean 0..1 hasMoney(): Boolean * getPlace(): Place move(p: Place) own isWinner(): Boolean Bandit Treasure Jewel Dice hasTreasure(): Boolean 0..1 0..1 value: Integer giveTreasure(): Treasure located throw(): Integer takeTreasure(t: Treasure) pay() 1 clearFunds() {ordered} * Order ofnavigation play Players Game 1 1 addPlayer(n: String) initialize() nextPlayer(): Player addPlayer(n: String) FlightTraffic treasurePlayer(p: Place): throwDice() Player movePlayer(p: Paikka) getDestinations(p: Place): 1 takeCard(p: Place) set of Place end() 1 Place place Map * hasCard():Boolean follow giveAdjacent(p: Place, giveCard() Aggregation n: Integer): set<Paikka> cover SpecialPlace NormalPlace * * 2 FlightRoute

3. Examine All Sequence Diagrams! User Game Player Place Card Choose to take card pay() showFunds(p:Player) turnCard() effect(p:Player) showFunds(p:Player)

4. Object Design Tasks • Improve efficiency by adding derived attributes and associations. • Design implementation of associations. • Increase maintainability by using design patterns. • Reorganise class structure, inheritance and interfaces. • Add additional classes, operations and attributes necessary for implementation. • Design for user interface implementation. • Edit the sequence diagrams to refer to existing classes. • Identify operations based on the sequence diagrams. • Describe complicated and important operations.

5. Finding operations • Rewrite sequence diagrams to use existing classes • Add parameters, if they are still missing. • Collect operations.

6. Get Operations From Sequence Diagrams Luokka Operation Meaning Player move(p:Place) Move player to place p pay() Pay one unit game money hasMoney() True, if funds>0, false otherwise … …

7. Attribute types • Class or a Primitive Type • E.g. Money or integer • Class or several attributes • E.g. Point or two integers x,y

8. Efficiency Considerations • Shortening association paths • If necessary, add more associations. • Add an association between Game and Player • Derived attributes • Avoid unnecessary re-computing • Explicit update, every time when source values change • Explicit update, at intervals • Implicit (compute when necessary)

9. Association Design • Study the associations and their usage • Usage in one or both directions? • If one, then which? • Are all associations necessary?

10. Association Implementation • Small cardinality (1 or 2, maybe 3) -> a referencing attribute • Larger cardinality -> a container class, e.g. list • Qualification -> a container class with hashing or indexing

11. Nontrivial associations • Aggregation associations • FlightTraffic-Flightroute • Map-Place • Other • Place-Follow-Place • Players-Player

12. Qualification and Indexing Place (or at least Special Place) must eventuallyhave placeNo as an attribute. Place FlightTraffic placeNo: Integer getDestinations(p: Place): giveCard() Set<Place> fee(p1, p2: Place): Integer placeNo SpecialPlace NormalPlace ends {indexed} 1 cardSeen: Boolean Qualification hasCard():Boolean Set<SpecialPlace> * giveCard() We are slowly iterating towards an implementable version. Only that version contains all details.

13. FlightTraffic-FlightRoute • Observations: • Qualification using Place • Association is used by getDestinations(p: Place), which returns a set of places based on a a given place. • FlightRoute objects are to be organised in such a way that for each place we can find the other places reachable with a flight route. • Solution: • Each place is given an identifying number 0..n. Use a search structure (table, binary tree, …) to find other places based on the number. • Similarly associations Map-Place and Place-Follow-Place

14. FlightTraffic-FlightRoute • Search will be based on special places (as only they have flight connections. • Therefore, we may give them numbers 0..k • Create a table k x 1 table flightDestinations • Each cell contains a list (or a reference to a list) of possible destinations, e.g. from cell flightDestinations[1] we find a list of possible flight destinations from place 1 (assuming k is at least 1).

15. FlightTraffic-FlightRoute: Table Only Search Structure • As an alternative, create a boolean k x k table flightDestinations2 • If there is a flight destination between special place i and special place j, thenflightDestinations2[i,j]==flightDestinations2[j,i]==trueelseflightDestinations2[i,j]==flightDestinations2[j,i]==false • Search is a bit slower, but implementation is easier.

16. Applying a similar idea to using dice • Create a k x 6 table destinations (6 being the maximum value for dice) • Each cell contains a list (or a reference to a list) of possible destinations, e.g. from cell [1,6] we find a list of possible destinations. • Alternatively, use a k x 6 x k table: ifyou can walk from i to j with s steps, thendestinations[i][s][j]==true

17. FlightTraffic-FlightRoute • Search will be based on special places (as only they have flight connections. • Therefore, we may give them numbers 0..k • Create a k x 6 table (6 being the maximum value for dice) • Each cell contains a list (or a reference to a list) of possible destinations, e.g. from cell [1,6] we find a list of possible destinations

18. Players-Player • Observations: • Navigation for finding the players • Operations nextPlayer() and treasurePlayer(p: Place) • Player objects need an order • Solution: • Use a table indexed by player number. • Change {ordered} into {indexed}, qualification can be removed.

19. Abstract Classes and Virtual (Abstract) Operations • Is it possible to define the operation for the superclass? -> If not -> {abstract}. • If there are abstract operations, then the superclass will be abstract.

20. Superclass-Subclass Example • Place is a superclass of SpecialPlace and NormalPlace. • Operation hasCard is in a way only meaningful for special places. • However, we may want to ask any place if it has a card. • Solution: define hasCard for Place and make it return false by default. • SpecialPlace will redefine hasCard.

21. Speculative Design • Add abstract classes or interfaces • E.g. prepare for new forms of transportation • New abstract class Traffic • with a virtual operation price (p1: Place, p2: Place): Integer. Same in FlightTraffic. • change operation fee() into form fee(h: Integer)

22. Object Design Class Diagram <<interface>> Player Piece Card color: Integer use name: String 0..1 effect (p: Pelaaja) funds: Integer 0..1 move(p: Place) getPlace(): Paikka isAtAirport(): Boolean 0..1 hasMoney(): Boolean * getPlace(): Place move(p: Place) owns isWinner(): Boolean Bandit Treasure Jewel Dice hasTreasure(): Boolean 0..1 0..1 value: Integer giveTreasure(): Treasure located throw(): Integer effect takeTreasure(t: Treasure) effect effect (p: Player) pay() (p: Player) 1 (p: Player) clearFunds() 1 {indexed} * hasturn 1 play Players Game <<interface>> 1 1 Traffic addPlayer(n: String) initialize() nextPlayer(): Player addPlayer(n: String) getDestinations(p: Paikka): treasurePlayer(p: Place): throwDice() Set<Place> {abstract} Player movePlayer(p: Paikka) fee(p1, p2: Place): 1 takeCard(p: Place) Integer {abstract} end() Place FligthTraffic Set<place> * hasCard():Boolean getDestinations(p: Place): {indexed} 1 giveCard() Set<Place> covers fee(p1, p2: Place): placeNo, 1 Integer steps placeNo Map SpecialPlace NormalPlace ends {indexed} 1 cardSeen: Boolean giveAdjacent(p: Place, n: Integer): set<Paikka> hasCard():Boolean Set<SpecialPlace> * giveCard()

23. Operation Design • Operation descriptions are designed with such accuracy that it is possible to implement them based on this design. • An operation form may be used.

24. Operation Form / 1 Class and operation declaration Description: A short operation description. Result: Result of the operation. Assumes: Preconditions, which are to be checked explicitly. Reads: Attributes, whose values the operation reads without modifying them, and objects, whose state the operation reads without modifying them.

25. Operation Form / 2 Changes: Attributes, whose values are changed, and objects, whose instances are changed. Exceptions: Possible exceptions, under which the operation terminates abnormally and does not produce the required result. Scenario: Sequence diagram showing the related object interactions. Algorithm: Algorithm for the operation.

26. Operation Design • Analysis-level description forms the basis. • Examine operation uses in sequence diagrams. • Preconditions guarantee that the operation can be executed (excluding exceptions).

27. Operation Design • Exceptions are described separately (execution terminates without correct result). • If the object uses other objects during the execution, this can be described with a sequence diagram (it may be possible to get this from earlier diagrams). • Non-trivial algorithms are written using a pseudo language.

28. Example: treasurePlayer(p: Place) Class: Players Operation: treasurePlayer(p: Place): Player Description: If there is a player in place p with the treasure, returns that player. Result: Returns player Q, for which Q.owns  nil and Q.uses.located = p, if such Q exists, otherwise nil. Assumes: p  nil

29. Example: treasurePlayer(p: Place) continued Reads: Player, Piece Exceptions: Player has no piece. Algorithm: while players not processed do Q = unprocessed player; if Q.hasTreasure() then if Q.getPlace() == p then return Q end end end; return nil

30. Final Checks Check that everything matches: • The required classes exist. • The required operations exist. • The required attributes exist. • The required associations exist. • The types match.