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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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

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.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Finding operations Rewrite sequence diagrams to use existing classes Add parameters, if they are still missing. Collect operations. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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 … 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Attribute types Class or a Primitive Type Class or several attributes E.g. Money or integer Class or several attributes E.g. Point or two integers x,y 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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) 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Association Design Study the associations and their usage Usage in one or both directions? If one, then which? Are all associations necessary? 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Nontrivial associations Aggregation associations FlightTraffic-Flightroute Map-Place Other Place-Follow-Place Players-Player 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Qualification and Indexing Place (or at least Special Place) must eventually have placeNo as an attribute. Place FlightTraffic placeNo: Integer getDestinations(p: Place): Set<Place> giveCard() fee(p1, p2: Place): Integer placeNo SpecialPlace NormalPlace ends 1 {indexed} Qualification cardSeen: Boolean Set<SpecialPlace> * hasCard():Boolean giveCard() We are slowly iterating towards an implementable version. Only that version is supposed to contain all details. You should fix things on the way, if you know how they will be. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

FlightTraffic-FlightRoute: Table and List Search Structure 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). 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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, then flightDestinations2[i,j]== flightDestinations2[j,i]==true else flightDestinations2[i,j]== flightDestinations2[j,i]==false Search is a bit slower, but implementation is easier. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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: if you can walk from i to j with s steps, then destinations[i][s][j]==true 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

FlightTraffic-FlightRoute: Table and List Search Structure 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 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Players-Player Observations: Solution: 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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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) 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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

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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Operation Form / 1 Class and operation declaration Description:   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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

Operation Design Analysis-level description forms the basis. Examine operation uses in sequence diagrams. Preconditions guarantee that the operation can be executed (excluding exceptions). 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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; return nil 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa

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. 4.10.2004 Software Engineering 2004 Jyrki Nummenmaa