1 / 29

Art for Chapter 9, Specifying Interfaces

Art for Chapter 9, Specifying Interfaces. Figure 9-1, the class implementor, the class extender, and the class user role. Call Class. Class User. Realize Class. Developer. Class Implementor. Refine Class. Class Extender. League. Game. TicTacToe. Chess. Tournament.

Download Presentation

Art for Chapter 9, 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. Art for Chapter 9, Specifying Interfaces

  2. Figure 9-1, the class implementor, the class extender, and the class user role. Call Class Class User Realize Class Developer Class Implementor Refine Class Class Extender

  3. League Game TicTacToe Chess Tournament Figure 9-2, ARENA Game abstract class with user classes and extender classes. 1 *

  4. public class Tournament { private int maxNumPlayers; /* Other fields omitted */ 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) {…}; /* Other methods omitted */ } Tournament -maxNumPlayers: int +getMaxNumPlayers():int +getPlayers(): List +acceptPlayer(p:Player) +removePlayer(p:Player) +isPlayerAccepted(p:Player):boolean Figure 9-3, Declaration for the Tournament class.

  5. Tournament -maxNumPlayers: int Figure 9-4, Examples of invariants, preconditions, and postconditions in OCL attached as notes to the UML model. «invariant» «precondition» getNumPlayers() < getMaxNumPlayers() getMaxNumPlayers() > 0 «postcondition»isPlayerAccepted(p) «precondition»!isPlayerAccepted(p) +getNumPlayers():int +getMaxNumPlayers():int «postcondition»!isPlayerAccepted(p) +acceptPlayer(p:Player) «precondition»isPlayerAccepted(p) +removePlayer(p:Player) +isPlayerAccepted(p:Player):boolean

  6. Tournament invariant context Tournament inv: self.getMaxNumPlayers() > 0

  7. Tournament.acceptPlayer contract 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

  8. Tournament.removePlayer contract context Tournament::removePlayer(p) pre: isPlayerAccepted(p) context Tournament::removePlayer(p) post: not isPlayerAccepted(p) context Tournament::removePlayer(p) post: getNumPlayers() = @pre.getNumPlayers() - 1

  9. 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) {…} } Figure 9-5, Method declarations for the Tournament class annotated with preconditions, postconditions, and invariants

  10. League +start:Date +end:Date +getActivePlayers() Tournament +start:Date +end:Date +acceptPlayer(p:Player) Player +name:String +email:String Figure 9-6, Associations among League, Tournament, and Player classes in ARENA. * {ordered} * tournaments * tournaments * players players *

  11. tttExpert:League chessNovice:League winter:Tournament xmas:Tournament start=Dec 23 end=Dec 25 alice:Player bob:Player marc:Player joe:Player zoe:Player Figure 9-7, Example situation with two Leagues, two Tournaments, and five Players. start=Dec 21 end=Dec 22

  12. Tournament League League start:Date end:Date Tournament Player Player Figure 9-8, There are only three basic types of navigation. Any OCL constraint can be built using a combination of these three types. 1. Local attribute 2. Directly related class 3. Indirectly related class * * * * *

  13. Examples of constraints using each type of navigation 1. Local attribute context Tournament inv: end - start <= Calendar.WEEK 2. Directly related class context Tournament::acceptPlayer(p) pre: league.players->includes(p) 3. Indirectly related class context League::getActivePlayers post: result = tournaments.players->asSet

  14. 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))

  15. 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))

  16. TournamentForm applyForTournament() TournamentControl selectSponsors() advertizeTournament() acceptPlayer() announceTournament() Tournament acceptPlayer() Player Advertiser removePlayer() schedule() Match start status playMove() getScore() Figure 9-9, Analysis objects of ARENA identified during the analysis of Announce Tournament use case. 1 1 * * 1 1 name * * start * * players sponsors * * end * matches * matches *

  17. Figure 9-10, a sequence diagram for the applyForTournament() operation. :Player :TournamentForm :TournamentControl t:Tournament p:Player applyForTournament(p) isPlayerOverbooked(p) getStartDate() getEndDate() getTournaments() tournaments

  18. 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 Figure 9-11, Adding type information to the object model of ARENA. 1 1 * * 1 1 * * * * players sponsors * * * matches * matches *

  19. 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

  20. 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)))

  21. 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)

  22. User «invariant»email <> nil email:String notify() Figure 9-13, A simple example of contract inheritance: An invariant specified in a superclass must hold for all of its subclasses. LeagueOwner Player Advertiser Spectator

  23. Analysis Document Analysis model RAD analysis System design Design goals Object design Initial object design model Generate class stubs Initial class stubs Implementation Document Commented code ODD object design Figure 9-14, Embedded ODD approach. Class stubs are generated from the object design model. Subsystem decomposition

  24. TournamentStyle League getTournamentStyle() planRounds(Tournament) :TournamentStyle :List legalNumPlayers(n:int) :boolean Tournament name start Player end name:String acceptPlayer() email:String removePlayer() plan() notify(Player,Message) getMatches(Tournament) Match start status plan() score getPreviousRound():Round isPlanned():boolean playMove(Player,Move) isCompleted():boolean getMoves():List Figure 9-16, new Round class and changes in the TournamentStyle, Tournament, and Round APIs. 1 * * tournaments players * {ordered} players * * 1 matches Round *

  25. Constraints on TournamentStyle • Only tournaments without rounds and with the right number of players can be planned. context TournamentStyle::planRounds(t:Tournament) pre: t <> nil and t.rounds = nil and legalNumPlayers(t)->contains(t.players->size) • All players are assigned to at least one match context TournamentStyle::planRounds(t:Tournament) post: t.getPlayers()->forAll(p| p.getMatches(tournament)->notEmpty) context TournamentStyle::planRounds(t:Tournament) post: result->forAll(r1,r2| r1<>r2 implies r1.getEndDate().before(r2.getStartDate()) or r1.getStartDate().after(r2.getEndDate())

  26. Invariant on Round • A player cannot be assigned to more than one match per round context Round inv:matches->forAll(m1:Match| m1.players->forAll(p:Player| p.matches->forAll(m2:Match| m1 <> m2 implies m1.round <> m2.round)))

  27. Constraints on Round.plan() • Invoking plan() on a Round whose previous Round is completed results in a planned Round context Round.plan() post: @pre.getPreviousRound().isCompleted() implies isPlanned() • A round is planned if all matches have players assigned to them context Round.isPlanned() post:result implies matches->forAll(m|  m.players->size =     tournament.league.game.numPlayersPerMatch) • A round is completed if all of its matches are completed. context Round.isCompleted() post: result implies matches->forAll(m| m.winner <> nil)

  28. Constraints on KnockOutStyle • The number of players should be a power of two. context KnockOutStyle::legalNumPlayers(t:Tournament) post: result Sequence[2..t.maxNumPlayers]->select(elem| floor(log(elem)/log(2)) = (log(elem)/log(2))) • The number of matches in a round is 1 for the last round. Otherwise, the number of matches in a round is exactly twice the number of matches in the subsequent round. context KnockOutStyle::planRounds(t:Tournament) post: result->forAll(index:Integer|    if (index = result->size) then       result->at(index).matches->size = 1    else       result->at(index).matches->size = (2*result->at(index+1).matches->size))    endif)

  29. Constraints on KnockOutRound • A player can play in a round only if it is the first round or if it is the winner of a previous round. context KnockOutRound inv: previousRound = nil or matches.players->forAll(p| round.previousRound.matches->exists(m| m.winner = p)) • If the previous round is not completed, this round cannot be planned. context KockOutRound::plan() post: not self@pre.getPreviousRound().isCompleted() implies not isPlanned()

More Related