Call Class Class User Realize Class Developer Class Implementor

Slides:



Advertisements
Similar presentations
Chapter 13 Abstraction and inheritance. This chapter discusses n Implementing abstraction. u extension u inheritance n Polymorphism/dynamic binding. n.
Advertisements

The role of OCL in the Model Driven Architecture Jos Warmer Klasse Objecten
Chapter 1 Object-Oriented Concepts. A class consists of variables called fields together with functions called methods that act on those fields.
1 The Object Constraint Language: Expressing Constraints in the UML (Most slides created by Robert B. France, Professor Department of Computer Science,
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Example of a Problem Statement: Introduction into.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Art for Chapter 7, Object Design.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 8, Object Design: Object Constraint Language.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Object Constraint Language.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Figure 10-1, Model transformations, refactorings,
Using UML, Patterns, and Java Object-Oriented Software Engineering Art for Chapter 9, Specifying Interfaces.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 10, Mapping Models to Code.
Object Design: Specifying Interfaces Chapter 9. 2 Object Design  Object design is the process of adding details to the requirements analysis and making.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 8, Object Design: Object Constraint Language.
Mapping Activities Done By: Sara Al-Khulaifi 11/12/2005.
CSCE 431: Interfaces and Contracts Some material from Bruegge, Dutoit.
Chapter 9: Object Design: Specifying Interfaces
1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 8, Object Design: Object Constraint Language.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Using UML, Patterns, and Java Object-Oriented Software Engineering Example of a Problem Statement: Introduction into ARENA.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 10, Mapping Models to Code.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Figure 5-2, Products of requirements elicitation.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Advance Information Systems Development (SD3043) Lecture 3: Requirements Elicitation / Analysis/Design Dr. Haris Mouratidis 10 th October.
Using UML, Patterns, and Java Object-Oriented Software Engineering Art for Chapter 8, Object Design: Reusing Pattern Solutions.
111 Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract,
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 10, Mapping Models to Code.
Two Parts of Every ADT An abstract data type (ADT)  is a type for encapsulating related data  is abstract in the sense that it hides distracting implementation.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Few comments about midterm I graded very lightly.
CSC 480 Software Engineering Design by Contract. Detail Design Road Map Begin with architectural models  Class model: domain classes  Overall state.
Falak Nawaz Mapping Models to Code. Object Model activities 1. Reuse: Identification of existing solutions  Use of inheritance  Off-the-shelf components.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 10, Mapping Models to Code.
CEN th Lecture Advance Software Engineering (CEN-5011) Instructor: Masoud Sadjadi Object Design: Specifying.
Interpreting the Object Constraint Presented by: Ed Kausmeyer.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
CS551 - Lecture 6 1 CS551 Modelling with Objects (Chap. 3 of UML) Yugi Lee STB #555 (816)
An association between class Flight and class Person, indicating that a certain group of persons are the passengers on a flight, will have multiplicity.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Chapter 8, Object Design: Object Constraint Language
Chapter 9, Object Design: Specifying Interfaces
Example of a Problem Statement: Introduction into ARENA
Chapter 10, Mapping Models to Code
Chapter 9, Object Design: Object Constraint Language
Chapter 10, Mapping Models to Code
Chapter 9, Object Design: Object Constraint Language
CSCE 606: Interfaces and Contracts
Chapter 9, Object Design: Specifying Interfaces
Example of a Problem Statement: Introduction into ARENA
Chapter 9, Object Design: Specifying Interfaces
Specifying Object Interfaces
Chapter 9, Object Design: Specifying Interfaces
Seminar 3 UML Class Diagram.
Lecture 22 Inheritance Richard Gesick.
Example of a Problem Statement: Introduction into ARENA
Slides by Steve Armstrong LeTourneau University Longview, TX
LECTURE 11: Specifying Systems – State Diag’s & OCL
Unified Modelling Language
Object Design Object design is the process of adding details to the requirements analysis and making implementation decisions The object designer must.
Defining Classes and Methods
The Object Constraint Language
Defining Classes and Methods
Java Modeling Language (JML)
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Object Constraint Language (OCL)
Formal Methods in Software Engineering 1
Presentation transcript:

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

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

Figure 9-3, Declaration for the Tournament class. -maxNumPlayers: int +acceptPlayer(p:Player) +removePlayer(p:Player) +getMaxNumPlayers():int +getPlayers(): List +isPlayerAccepted(p:Player):boolean 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 */ }

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

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

Tournament.acceptPlayer contract context Tournament::acceptPlayer(p) pre: not isPlayerAccepted(p) getNumPlayers() < getMaxNumPlayers() context Tournament::acceptPlayer(p) post: isPlayerAccepted(p) getNumPlayers() = @pre.getNumPlayers() + 1

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

Figure 9-5, Method declarations for the Tournament class annotated with preconditions, postconditions, and invariants 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-6, Associations among League, Tournament, and Player classes in ARENA. +start:Date +end:Date +getActivePlayers() * {ordered} * tournaments Tournament +start:Date +end:Date +acceptPlayer(p:Player) * tournaments * players players Player * +name:String +email:String

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

Figure 9-8, There are only three basic types of navigation 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 Tournament League League start:Date end:Date * * * Player Tournament * * Player

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

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

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

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

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

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

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

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)

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

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

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

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())

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

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)

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)

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()