1 / 30

OBJECT DESIGN

This title describes the task to design an implementable class diagram with specific attributes and associations for a software engineering project from 2004.

khite
Download Presentation

OBJECT DESIGN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

  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 is supposed to contain all details. You should fix things on the way, if you know how they will be. Software Engineering 2004 Jyrki Nummenmaa

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related