1 / 43

Chapter 9: Object Design: Specifying Interfaces

Chapter 9: Object Design: Specifying Interfaces. Object Design. Object design is the process of adding details to the requirements analysis and making implementation decisions

sahara
Download Presentation

Chapter 9: Object Design: Specifying Interfaces

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. 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. Call Class Class User Realize Class Developer Class Implementor Refine Class Class Extender Developers play different Roles during Object Design

  7. League Game TicTacToe Chess Tournament 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 1 * 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. Tournament - maxNumPlayers: int + getMaxNumPlayers():int + getPlayers(): List + acceptPlayer(p:Player) + removePlayer(p:Player) + isPlayerAccepted(p:Player):boolean Implementation of UML Visibility in Java 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)

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

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

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

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

  19. Real and Integer Operators

  20. String Operators

  21. Customer gender: enum{male, female}name: Stringtitle: StringdateOfBirth: Date Using Enumerations 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. * @invariant 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. * @pre !isPlayerAccepted(p) * @pre getNumPlayers()<maxNumPlayers * @post isPlayerAccepted(p) * @post getNumPlayers() = * @pre.getNumPlayers() + 1 */ public void acceptPlayer (Player p) {…} /** The removePlayer() operation * assumes that the specified player * is currently in the Tournament. * @pre isPlayerAccepted(p) * @post !isPlayerAccepted(p) * @post 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. Tournament League League start:Date end:Date Tournament Player 3 Types of Navigation through a Class Diagram 1. Local attribute 2. Directly related class 3. Indirectly related class * * * Player * * Any OCL constraint for any class diagram can be built using a combination of these three navigation types

  27. League Tournament Player 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. 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 * * *

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

  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. chessNovice:League tttExpert:League winter:Tournament xmas:Tournament start=Dec 21 start=Dec 23 end=Dec 22 end=Dec 25 alice:Player bob:Player marc:Player joe:Player zoe:Player Instance Diagram: 2 Leagues, 2 Tournaments, and 5 Players

  31. League * +start:Date +end:Date +getActivePlayers() {ordered} * tournaments Tournament +start:Date +end:Date +acceptPlayer(p:Player) * tournaments * players players Player * +name:String +email:String 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)

  32. League * +start:Date +end:Date +getActivePlayers() {ordered} * tournaments Tournament +start:Date +end:Date +acceptPlayer(p:Player) * tournaments * players players Player * +name:String +email:String 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

  33. OCL Collections • Sets • 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 minussymmetricDifferenceasSequenceasBag asSequenceasSet firstlastat(int)appendprependasBagasSet

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

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

  41. 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) TournamentControl +selectSponsors(advertisers):List +advertizeTournament() +acceptPlayer(p) +announceTournament() +isPlayerOverbooked():boolean Pre- and post-conditions for ordering operations on TournamentControl

  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)

More Related