Using UML Patterns and Java ObjectOriented Software Engineering

Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces

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 Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2

Developers play different Roles during Object Design Developer Bernd Bruegge & Allen Dutoit Class User Call Class Implementor Realize Class Extender Refine Class Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3

Class user versus Class Extender Developers responsible for the implementation of League are class users of Game Developers responsible for the implementation of Game are class implementors League Game 1 * Tournament Tic. Tac. Toe Chess The developer responsible for the implementation of Tic. Tac. Toe is a class extender of Game Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4

Specifying Interfaces Requirements analysis activities Identifying attributes and operations without specifying their types or their parameters. Object design: Three activities 1. Add visibility information 2. Add type signature information 3. Add contracts Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5

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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6

Implementation of UML Visibility in Java Tournament - max. Num. Players: int + + + get. Max. Num. Players(): int get. Players(): List accept. Player(p: Player) remove. Player(p: Player) is. Player. Accepted(p: Player): boolean public class Tournament { private int max. Num. Players; public Tournament(League l, int max. Num. Players) public int get. Max. Num. Players() {…}; public List get. Players() {…}; public void accept. Player(Player p) {…}; public void remove. Player(Player p) {…}; public boolean is. Player. Accepted(Player p) {…}; Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7

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 realtime systems or games) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8

Information Hiding Design Principles Only the operations of a class are allowed to manipulate its attributes Access attributes only via operations. Do not apply an operation to the result of another operation. Write a new operation that combines the two operations. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9

2. Add Type Signature Information Hashtable -num. Elements: int +put() +get() +remove() +contains. Key() +size() Hashtable Attributes and operations without type information are acceptable during analysis Bernd Bruegge & Allen Dutoit -num. Elements: int +put(key: Object, entry: Object) +get(key: Object): Object +remove(key: Object) +contains. Key(key: Object): boolean +size(): int Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10

3. Add 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11

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: num. Elements >= 0 Precondition: OCL expression Context is a class operation put context Hashtable: : put(key, entry) pre: !contains. Key(key) Post-condition: context Hashtable: : put(key, entry) post: contains. Key(key) and get(key) = entry Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12

Expressing Constraints in UML Models A constraint can also be depicted as a note attached to the constrained UML element by a dependency relationship. <<invariant>> num. Elements >= 0 <<precondition>> !contains. Key(key) <<precondition>> contains. Key(key) Bernd Bruegge & Allen Dutoit Hash. Table num. Elements: int put(key, entry: Object) get(key): Object remove(key: Object) contains. Key(key: Object): boolean size(): int Object-Oriented Software Engineering: Conquering Complex and Changing Systems <<postcondition>> get(key) == entry <<postcondition>> !contains. Key(key) 13

Contract for accept. Player in Tournament (textual description of contracts, out of UML diagram) context Tournament: : accept. Player(p) pre: not is. Player. Accepted(p) context Tournament: : accept. Player(p) pre: get. Num. Players() < get. Max. Num. Players() context Tournament: : accept. Player(p) post: is. Player. Accepted(p) context Tournament: : accept. Player(p) post: get. Num. Players() = @pre. get. Num. Players() + 1 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

Contract for remove. Player in Tournament context Tournament: : remove. Player(p) pre: is. Player. Accepted(p) context Tournament: : remove. Player(p) post: not is. Player. Accepted(p) context Tournament: : remove. Player(p) post: get. Num. Players() = @pre. get. Num. Players() - 1 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

Annotation of Tournament class public class Tournament { /** The maximum number of players * is positive at all times. * @invariant max. Num. Players > 0 */ private int max. Num. Players; /** The accept. Player() operation * assumes that the specified * player has not been accepted * in the Tournament yet. * @pre !is. Player. Accepted(p) * @pre get. Num. Players()<max. Num. Players * @post is. Player. Accepted(p) * @post get. Num. Players() = * @pre. get. Num. Players() + 1 */ public void accept. Player (Player p) {…} /** The players List contains * references to Players who are * are registered with the * Tournament. */ private List players; /** The remove. Player() operation * assumes that the specified player * is currently in the Tournament. * @pre is. Player. Accepted(p) * @post !is. Player. Accepted(p) * @post get. Num. Players() = @pre. get. Num. Players() - 1 */ public void remove. Player(Player p) {…} /** Returns the current number of * players in the tournament. */ public int get. Num. Players() {…} /** Returns the maximum number of * players in the tournament. */ public int get. Max. Num. Players() {…} } Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16

Constraints can involve more than one class How do we specify constraints on more than one class? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

3 Types of Navigation through a Class Diagram 1. Local attribute Tournament start: Date end: Date 2. Directly related class 3. Indirectly related class League * * Player * Tournament * * Player Any OCL constraint for any class diagram can be built using only a combination of these three navigation types! Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18

ARENA Example: League, Tournament and Player * League +start: Date +end: Date +get. Active. Players() {ordered} * tournaments Tournament +start: Date +end: Date +accept. Player(p: Player) * tournaments players * Bernd Bruegge & Allen H. Dutoit * players Player +name: String +email: String Object-Oriented Software Engineering: Using UML, Patterns, and Java 19

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 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20

Instance Diagram: 2 Leagues, 2 Tournaments, and 5 Players chess. Novice: League ttt. Expert: League winter: Tournament xmas: Tournament start=Dec 21 end=Dec 22 start=Dec 23 end=Dec 25 alice: Player bob: Player marc: Player joe: Player zoe: Player Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21

Specifying the Model Constraints (see Slide 20) Local attribute navigation context Tournament inv: end - start <= Calendar. WEEK * Directly related class navigation League +start: Date +end: Date +get. Active. Players() {ordered} * tournaments context Tournament: : accept. Player(p) pre: league. players->includes(p) Tournament +start: Date +end: Date +accept. Player(p: Player) * tournaments players * Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java * players Player +name: String +email: String 22

Specifying the Model Constraints (see Slide 20) League Local attribute navigation * context Tournament inv: end - start <= Calendar. WEEK +start: Date +end: Date +get. Active. Players() Directly related class navigation {ordered} context Tournament: : accept. Player(p) pre: league. players->includes(p) * tournaments Tournament +start: Date +end: Date +accept. Player(p: Player) Indirectly related class navigation * tournaments context League: : get. Active. Players post: result = tournaments. players->as. Set * players * La cardinalità molti potrebbe dare luogo a ripetizioni dei valori di player per questo bisogna convertire in Set Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java Player +name: String +email: String 23

OCL supports Quantification ¨ OCL forall quantifier /* All Matches in a Tournament occur within the Tournament’s time frame */ context Tournament inv: matches->for. All(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)) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24

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 constratins involving more than one class, attribute or operation can be expressed with 3 basic navigation types. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25

Additional Slides Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26

ARENA’s object model identified during the analysis Tournament. Form apply. For. Tournament() 1 1 Tournament. Control * select. Sponsors() advertize. Tournament() accept. Player() announce. Tournament() 1 * 1 Tournament * * players Player * matches * Match start status name * start end accept. Player() remove. Player() schedule() * sponsors * * Advertiser matches * play. Move() get. Score() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27

Adding type information to ARENA’s object model Tournament. Form 1 1 +apply. For. Tournament() * Tournament. Control * +select. Sponsors(advertisers): List +advertize. Tournament() +accept. Player(p) +announce. Tournament() +is. Player. Overbooked(): boolean 1 1 Tournament * * players Player * matches * Match +start: Date +status: Match. Status +name: String * +start: Date +end: Date +accept. Player(p) +remove. Player(p) +schedule() * sponsors * * Advertiser matches * +play. Move(p, m) +get. Score(): Map Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28

Pre- and post-conditions for ordering operations on Tournament. Control +select. Sponsors(advertisers): List +advertize. Tournament() +accept. Player(p) +announce. Tournament() +is. Player. Overbooked(): boolean context Tournament. Control: : select. Sponsors(advertisers ) pre: interested. Sponsors->not. Empty and tournament. sponsors->is. Empty context Tournament. Control: : select. Sponsors(advertisers ) post: tournament. sponsors. equals(advertisers) context Tournament. Control: : advertise. Tournament () pre: tournament. sponsors->is. Empty and not tournament. advertised context Tournament. Control: : advertise. Tournament () post: tournament. advertised context Tournament. Control: : accept. Player(p ) pre: tournament. advertised and interested. Players->includes(p) and not is. Player. Overbooked(p) context Tournament. Control: : accept. Player(p ) post: tournament. players->includes(p) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29

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->for. All(m| m. start. after(start) and m. start. before(end)) ¨ No Player can take part in two or more Tournaments that overlap context Tournament. Control inv: tournament. players->for. All(p| p. tournaments->for. All(t| t <> tournament implies not t. overlap(tournament))) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30

Specifying invariants on Match Player players * Match ¨ players * * tournaments Tournament matches * A match can only involve players who are accepted in the tournament context Match inv: players->for. All(p| p. tournaments->exists(t| t. matches->includes(self))) context Match inv: players. tournaments. matches. includes(self) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31