UML Artifacts Part 2 Contents 1 Collaboration Diagrams

UML Artifacts (Part 2) Contents 1. Collaboration Diagrams 2. State Transition Diagrams 3. Visibility 4. Review

Collaboration Diagrams For each system operation identified in the Use Case Diagrams, and described in a contract Design a system of interacting objects to perform the operation. The collaboration diagram will indicate the objects participating in the collaboration, and The sequence of messages {message(parameters), sender, receiver} exchanged to achieve the task involved.

Collaboration Diagrams Actor System Op System. Op : Class. A + Operation: xxx Precondition: . . 1: message 1() : Class. B Use Case Diagram Contract Collaboration Diagram

Alternatively (or perhaps primarily) Sequence Diagrams can be used instead of Collaboration Diagrams

Sequence Diagrams Actor System : Class. A : Class. B System Op System. Op + Use Case Diagram Operation: xxx message 1() Precondition: . . Contract Collaboration Diagram

Collaboration Diagrams Notation Student class : Student instance John: Student named instance The Collaboration diagram should consist of illustrations of the messages sent to objects of the classes identified in the creates/destroys, reads, changes sections of the contract. The system operation will be directed to one of the objects in this group that will act as the controller for executing this task.

Collaboration Diagrams Illustrating links UML standard syntax for messages return : = message(parameter : parameter. Type) : return. Type sys. Op() optional 1: tot : = total(): integer : POST sender : Sale receiver

Collaboration Diagrams Illustrating Iteration System. Op( ) 1*: [i: =0. . 9] str : get. Name(): String : Grader sender Sequence number followed by a * indicates iteration CS 335: Class. List receiver Iteration clause is optional

Collaboration Diagrams Illustrating Iteration In the example described on the previous slide, we assumed that the target object contained a sequence of names (simple strings) as an attribute. More generally the Class. List may be considered a collection of Student. Rec objects, and messages may be directed to the collection. The depiction of a message to a multiobject – a group of objects stored in a collection – is indicated on the next slide. 1: message( ) : Class. A Representation of a collection (multiobject)

Collaboration Diagrams Given: A vector of Student. Record 1: inx : = find(name: String): integer v: vector Version 1 – message to a collection (but vector is NOT a concept in the problem domain) 1: inx : = find(name: String): integer : Student. Record Version 2 – (preferred) Emphasizes the objects in the collection, not (the solution domain) container.

Collaboration Diagrams Conditional Paths – mutually exclusive messages msg 1( ) : Class. A 1 a: [test] msg 2( ) : Class. B guard – if true send msg 1 b: [not test] msg 4( ) : Class. C 1 b. 1: msg 5( ) 1 a. 1: msg 3( ) : Class. D

Collaboration Diagrams Creating a new instance during implementation of the system operation c: Controller 1: create( ) 2: add(m) New m: Menu. Item Create a new Menu. Item, m, and add it to the Menu

Sequence Diagrams Sequence diagrams offer an alternate way of expressing the exchange of messages that occur between objects in an object-based system. The notation for objects and collections is the same as used in collaboration diagrams. Time ordering is from top to bottom. : Class. B : Class. A msg 1( ) msg 2( ) Focus of control is illustrated with an activation box msg 3( ) Each message between objects is represented with a message expression on an arrowed line between the objects

Sequence Diagrams Additional Notation Object creation -- let the class. B object create an instance of a class. C object. Newly created class is placed in a column starting at the level (time) of creation. : Class. B : Class. A msg 1( ) msg 2( ) create( ) msg 3( ) time msg 4( ) : Class. C

Sequence Diagrams Conditional Mutually exclusive message conditional – has guardmessage to specify the condition : Class. B : Class. A msg 1( ) [flag = true] msg 2( ) [flag = false] msg 3( ) : Class. C

Sequence Diagrams Iteration forfor a single message Iteration a sequence of messages : Class. C : Class. B : Class. A msg 1( ) *[i = 1. . N] msg 2( ) msg 3( ) msg 4( ) *[k = 1. . M] msg 5( ) Enclose the repeated sequence in a box, and indicate the multiplicity

Refining the Class Diagram For every class, examine each collaboration diagram and identify 1. Every message received by an instance of that class – (these will be the methods for that class) 2. Each object (class) to which an instance of this class sends a message – (these may require reference attributes within the class, depending upon the visibility)

Refining the Class Diagram Class name Data attributes Link attributes methods Class Description Classes to which messages are sent Messages received

State Transition Diagrams State transition diagrams are a useful tool for constructing the individual classes. Specifically, they aid in two important ways in “fleshing out” the structure of the class: 1. method development -- State transition diagrams provide the “blueprints” for developing the algorithms that implement methods in the class 2. attribute identification – Attributes contain the state information needed for regulating the behaviors of the instances of the class When constructing state transition diagrams, take care to ensure that the post-conditions stipulated in the contracts are enforced.

State Transition Diagrams Notation Some events do not trigger a change in state Transitions are labeled with the triggering event and the output if any event|output State 1 State 2 start States are represented with an oval and label State transitions are represented with a directed arc or line final state

State Transition Diagrams Additional Notation event|output State [boolean condition] Guard condition – transition occurs only if condition is true State

State Transition Diagrams Example – Nested States in Telephone Call off hook|dial tone [valid subscriber] active idle talking on hook The state labeled active has substates playing dial tone do: hang up answered digit complete|ringing dialing digit connecting

State Transition Diagrams Second Example – A Queue of Capacity Two arrival Size 0 arrival Size 1 departure size 2 departure arrival | balk The queue has three states that indicate its number of occupants. When the queue is full, new arrivals cannot enter, and must leave the system.

Description of Class Queue class Queue { private: int capacity, size; State public: Queue(int cap); State transitions void enqueue(Object obj); //precondition: queue not full //post condition: if (queue not full) // size = size + 1 // else no change Object dequeue(); //precondition: queue not empty //post-condition: size = size-1 }

Visibility For an object A to send a message to object B, B must be visible to A. In determining the visibility of one object to another, we must decide during the design whether the link between objects A and B is: permanent or transient exclusive or shared fixed or variable

Visibility Example 1. permanent, exclusive , and fixed Consider a clock composed of three Counters (hours, mins, secs) Clock Counter * 3 modulus count • The Counters have the same lifetime as the Clock – They are created with the clock and dissolved when the clock is out of scope. • The Counters are bound exclusively to the Clock – They cannot be referenced by any other object in the system

Visibility Implementation of the association between Clock and Counters class Clock { private: Counter hours, mins, secs; public: Counter( ) : hours(24), mins(60), secs(60) {}; //other methods } C++ header file

Visibility Example 2. permanent, shared, fixed Product. Spec describes * Computer The Product. Spec exists before an instance of the product is created. That product (computer) will have a permanent association with its Product. Spec that it will share access to with other computers of the same model.

Visibility (Partial) Specification of class Computer { private: Product. Spec & ps; public: Computer (Product. Spec & the. Mod) : ps(the. Mod) {}; //other methods } The reference variable ps must be initialized in an initialization list, and cannot be reassigned during the life of the object.

Visibility Attribute visibility -- an association that must be remembered is implemented as attribute visibility. We have just seen a couple of examples of attribute associativity. In C++ attribute associativity is provided via three forms of the declaration Counter c; permanent and exclusive; lifetime of the counter is bounded by the lifetime of the object itself. Stack * s; Can be non-permanent, variable, and shared Product. Spec & ps; Permanent and fixed, but not necessarily exclusive; lifetime of the Product. Spec will exceed that of object

Visibility Transient visibility is not remembered, but persists only during the execution of a single method. It is implemented in one of two ways. Parameter visibility – object C is passed from A to B 1: [new sale] create() : POST 3: make. Line. Item(spec, qty) 2: spec: = specification(upc) : Product. Catalog : Sale A Product. Spec object is passed to the Sale object for use by its make. Line. Item method

Visibility Transient associations may also be implemented with locally declared visibility. Consider a method breadfirst. Search that uses an auxiliary Queue to perform a breadth first traversal of a binary tree. The lifetime of the Queue object will be within the scope of the method, and the reference need not exist outside of this method.

Review In designing and constructing an object-oriented system one must: 1. From a statement of the requirements and from the use cases identify the objects (concepts) that occur in the “problem domain” 2. Construct a Concept Diagram showing the static relationship (longterm associations) between concepts 3. Identify the concepts that are outside of the system to be built (Actors) and use Sequence Diagrams to identify the events (system operations) that they generate 4. For each system operation construct a contract that stipulates the state of the system before and after the operation (pre- and post- conditions) and identifies the concepts that collaborate in performing the operation 5. Elaboration – Review your models for lack of clarity and inconsistency and add or modify as necessary.

Review (continued) 6. Enhance the Concept model by exploring the associations in greater detail (roles, aggregation, generalization, link attributes, etc) and iteratively add design concepts from the solution domain (programming concepts) 7. Construct Sequence Diagrams or Collaboration diagrams (for each system operation) to detail the sequence of messages that must be exchanged to implement the task 8. For each relevant object (or collection of aggregates) use a State Chart Diagram (state transition diagram) to detail the states of the system and the sequence of transitions that can occur during its operation 9. Continue elaboration of the models until the system is well understood and class specifications (In C++, header files) can be constructed. 10. Test design and specification for completeness and consistency, then develop test plans and begin (or continue) implementing the classes. (an on-going process during many phases of the project)

Postscript I have been one acquainted with the night. I have walked out in rain – and back in rain. I have outwalked the furthest city light. I have looked down the saddest city lane. I have passed by the watchman on his beat And dropped my eyes, unwilling to explain. I have stood still and stopped the sound of feet When far away an interrupted cry Came over houses from another street, But not to call me back or say good-bye; And further still at an unearthly height, One luminary clock against the sky Proclaimed the time was neither wrong nor right. I have been one acquainted with the night. Robert Frost