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 req irements analysis and making implementation decisions The object designer m st choose among different ways to implement the analysis model with the goal to minimize exec tion time, memory and other meas res 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 ser es as the basis of implementation Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2

Object Design: Closing the Gap Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3

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

Class user versus Class Extender Developers responsible for the implementation of Game are he implementation of League are class implementors class users of Game Leag e Game 1 * To rnament 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 5

Specifying Interfaces Req irements analysis acti ities Identifying attributes and operations without specifying their types or their parameters. Object design: Three acti ities 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 6

1. Add Visibility Information UML defines three le els of isibility: Pri ate (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. P blic (Class ser): A public attribute or operation can be Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7

Implementation of UML Visibility in Java To rnament - max. N m. Players: int + get. Max. N m. Players(): int + get. Players(): List + accept. Player(p: Player) + remo e. Player(p: Player) + is. Player. Accepted(p: Player): boolean public class To rnament { private int max. N m. Players; Bernd Bruegge & Allen Dutoit public To rnament(Leag e l, int max. N m. Players) public int get. Max. N m. Players() {…}; public List get. Players() {…}; public void accept. Player(Player p) {…}; public void remo e. Player(Player Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 p) {…};

Information Hiding Heuristics Caref lly define the p blic interface for classes as well as s bsystems (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 s efficiency Accessing a private attribute might be Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9

Information Hiding Design Principles Only the operations of a class are allowed to manip late its attrib tes Access attributes only via operations. Hide external objects at s bsystem bo ndary Define abstract class interfaces which mediate between system and external world as well as between subsystems Do not apply an operation to the res lt 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 10

2. Add Type Signature Information Hashtable -n m. Elements: int +p t() +get() +remo e() +contains. Key() +size() Hashtable Attributes and operations without type information re acceptable during analysis Bernd Bruegge & Allen Dutoit -n m. Elements: int +p t(key: Object, entry: Object) +get(key: Object): Object +remo e(key: Object) +contains. Key(key: Object): boolea +size(): int Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11

3. Add Contracts on a class enable caller and callee to share the same ass mptions abo t the class. Contracts incl de three types of constraints: In ariant: 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: Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12

Expressing constraints in UML Models OCL (Object Constraint Lang age) 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 OCL expression operation p t(): Context is a class Invariant: operation put context Hashtable inv: num. Elements >= 0 Precondition: 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 13

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

Contract for accept. Player in Tournament context To rnament: : accept. Player(p) pre: not is. Player. Accepted(p) context To rnament: : accept. Player(p) pre: get. N m. Players() < get. Max. N m. Players() context To rnament: : accept. Player(p) post: is. Player. Accepted(p) context To rnament: : accept. Player(p) post: get. N m. Players() = @pre. get. N m. Players() + 1 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

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

Annotation of Tournament class public class To rnament { /** The maxim m n mber of players * is positi e at all times. * @in ariant max. N m. Players > 0 */ private int max. N m. Players; /** The players List contains * references to Players who are * are registered with the * To rnament. */ private List players; /** Ret rns the c rrent n mber of * players in the to rnament. */ public int get. N m. Players() {…} /** The accept. Player() operation * ass mes that the specified * player has not been accepted * in the To rnament yet. * @pre !is. Player. Accepted(p) * @pre get. N m. Players()<max. N m. Players * @post is. Player. Accepted(p) * @post get. N m. Players() = * @pre. get. N m. Players() + 1 */ public void accept. Player (Player p) {…} /** The remo e. Player() operation * ass mes that the specified player * is c rrently in the To rnament. * @pre is. Player. Accepted(p) * @post !is. Player. Accepted(p) * @post get. N m. Players() = @pre. get. N m. Players() - 1 */ public void remo e. Player(Player p) {…} /** Ret rns the maxim m } n mber of Bernd Bruegge & Allen H. in Dutoitthe to rnament. Object-Oriented Software Engineering: Using UML, Patterns, and Java * players 17

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 18

3 Types of Navigation through a Class Diagram 1. Local attribute To rnament start: Date end: Date 2. Directly related class 3. Indirectly related class Leag e * * Player * To rnament * * 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 19

ARENA Example: League, Tournament and Player Leag e * +start: Date +end: Date +get. Acti e. Players() {ordered} * to rnaments To rnament +start: Date +end: Date +accept. Player(p: Player) * to rnaments players * Bernd Bruegge & Allen H. Dutoit * players Player +name: String +email: String Object-Oriented Software Engineering: Using UML, Patterns, and Java 20

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 21

Instance Diagram: 2 Leagues, 2 Tournaments, and 5 Players chess. No ice: Leag e ttt. Expert: Leag e winter: To rnament start=Dec 21 end=Dec 22 xmas: To rnament 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 22

Specifying the Model Constraints (see Slide 20) Local attribute navigation context To rnament inv: end - start <= Calendar. WEEK Leag e * +start: Date +end: Date +get. Acti e. Players( Directly related class navigation {ordered} * to rnament context To rnament: : accept. Play er(p) pre: leag e. players>incl des(p) To rnament +start: Date +end: Date +accept. Player(p: Pl * to rnament players * Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java * players Player +name: String +email: String 23

Specifying the Model Constraints (see Slide 20) Local attribute navigation context To rnament inv: end - start <= Calendar. WEEK Leag e * +start: Date +end: Date +get. Acti e. Players( {ordered} * to rnament Directly related class navigation context To rnament: : accept. Player( p) pre: leag e. players>incl des(p) To rnament +start: Date +end: Date +accept. Player(p: Pl * to rnament Indirectly related class navigation context Leag e: : get. Acti e. Players post: players * res lt = to rnaments. players. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java >as. Set * players Player +name: String +email: String 24

OCL supports Quantification ¨ OCL forall quantifier /* All Matches in a To rnament occ r within the Tournament’s time frame */ context To rnament inv: matches->for. All(m: Match | m. start. after(t. start) and m. end. before(t. end)) ¨ OCL exists quantifier /* Each To rnament cond cts at least one Match on the first day of the To rnament */ context To rnament inv: matches->exists(m: Match | m. start. eq als(start)) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25

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 26

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

ARENA’s object model identified during the analysis To rnament. Form 1 1 apply. For. To rnament() To rnament. Control * select. Sponsors() * ad ertize. To rnament() accept. Player() anno nce. To rnament() 1 1 To rnament * * players Player * matches * Match start stat s name * start end accept. Player() remo e. Player() sched le() * sponsors * * Ad ertiser matches * play. Mo e() get. Score() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28

Adding type information to ARENA’s object model To rnament. Form 1 1 +apply. For. To rnament() * To rnament. Control * +select. Sponsors(ad ertisers): List +ad ertize. To rnament() +accept. Player(p) +anno nce. To rnament() +is. Player. O erbooked(): boolean 1 1 To rnament * * players Player * matches * Match +name: String * +start: Date +end: Date +accept. Player(p) +remo e. Player(p) +sched le() * sponsors * * Ad ertiser matches * +start: Date +stat s: Match. Stat s +play. Mo e(p, m) +get. Score(): Map Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29

Pre- and post-conditions for ordering operations on Tournament. Control To rnament. Control +select. Sponsors(ad ertisers) +ad ertize. To rnament() +accept. Player(p) +anno nce. To rnament() +is. Player. O erbooked(): boolean context To rnament. Control: : select. Sponsors(ad ertisers) pre: interested. Sponsors->not. Empty and to rnament. sponsors->is. Empty context To rnament. Control: : select. Sponsors(ad ertisers) post: to rnament. sponsors. eq als(ad ertisers) context To rnament. Control: : ad ertise. To rnament() pre: to rnament. sponsors->is. Empty and not to rnament. ad ertised context To rnament. Control: : ad ertise. To rnament() post: to rnament. ad ertised context To rnament. Control: : accept. Player(p) pre: to rnament. ad ertised and interested. Players->incl des(p) and not is. Player. O erbooked(p) context To rnament. Control: : accept. Player(p) post: to rnament. players->incl des(p) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30

Specifying invariants on Tournament and Tournament Control ¨ All Matches of in a Tournament must occur within the time frame of the Tournament context To rnament 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 To rnament. Control inv: to rnament. players->for. All(p| p. to rnaments->for. All(t| t <> to rnament implies not t. o erlap(to rnament))) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31

Specifying invariants on Match Player players* Match ¨ players * * to rnaments To rnament matches * A match can only involve players who are accepted in the tournament context Match inv: players->for. All(p| p. to rnaments->exists(t| t. matches->incl des(self))) context Match inv: players. to rnaments. matches. incl des(se lf) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32