I Gede Made Karma

  Types of Diagrams UML Interaction Diagrams

• Structural Diagrams – focus on static aspects of the software system

  Class, Object, Component, Deployment – j p p y

• Behavioral Diagrams – focus on dynamic

  I Gede Made Karma aspects of the software system _{Department of Computer Science Michael L. Collard, Ph.D. Kent State University} Use-case, Interaction, State Chart, Activity _{Kent State University 2}

• – Behavioral Diagrams Refining the Object Model
• Typically, only very simplistic object models can be
• Use Case Diagram – high-level behaviors of the directly derived from use cases.

  system, user goals, external entities: actors

• A better understanding of the behavior of each use case is
• Sequence Diagram – focus on time ordering of

  necessary (i.e., analysis) messages g

• Use interaction diagrams to specify and detail the
• Collaboration Diagram – focus on structural

  behavior of use cases

  organization of objects and messages

• This helps to identify and refine key abstractions and
• State Chart Diagram – event driven state

  relationships changes of system

• Operations, attributes, and messages are also identified
• Activity Diagram – flow of control between

  during this process activities _{Kent State University 3 Kent State University 4} Collaboration Diagrams

  Interaction Diagrams

  For each system operation

• There is one (or more) Interaction diagram per use case

  identified in the Use Case Diagrams, and

• – Represent a sequence of interactions
• – Made up of objects, links, and messages

  described in a contract

• Sequence diagrams q g
• – Models flow of control by time ordering Design a system of interacting objects to perform the – Emphasizes passing messages wrt time operation.
• – Shows simple iteration and branching
• Collaboration diagrams The collaboration diagram will indicate the objects
• – Models flow of control by organization

  participating in the collaboration, and

• – Structural relationships among instances in the interaction

  The sequence of messages {message(parameters), sender,

• – Shows complex iteration and branching
_{Kent State University 5} receiver} exchanged to achieve the task involved.

  Collaboration Diagrams Actor System Alternatively (or perhaps primarily) System Op SystemOp Sequence Diagrams can be used :ClassA instead of Collaboration Diagrams

  Operation:xxx p

• + + 1: message1() Precondition:.. :ClassB Use Case Contract Diagram Collaboration Diagram Sequence Diagrams Collaboration Diagrams

  Notation

  Actor System :ClassA :ClassB System Op John:Student Student :Student SystemOp

  Operation:xxx message1() + + Precondition:..

  class instance 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

  Use Case Contract

  system operation will be directed to one of the objects in this

  Diagram Collaboration Diagram group that will act as the controller for executing this task. Collaboration Diagrams Collaboration Diagrams

  Illustrating Iteration Illustrating links

  SystemOp( )

  UML standard syntax for messages

  1*: [i:=0..9] str : getName(): String [ ] g () g

  return := message(parameter : parameterType) : returnType return : message(parameter : parameterType) : returnType

  CS335:ClassList :Grader sysOp()

  optional receiver sender

  Sequence number followed by 1: tot := total():integer

  Iteration clause is optional :Sale a * indicates iteration :POST

  sender receiver

  Collaboration Diagrams Collaboration Diagrams

  Illustrating Iteration Given: A vector of StudentRecord In the example described on the previous slide, we

  1: inx := find(name: String): integer

  assumed that the target object contained a sequence of v: vector names (simple strings) as an attribute. More generally the ClassList may be considered a collection of y Version 1 – message to a collection (but vector is NOT a V i 1 t ll ti (b t t i NOT StudentRec objects, and messages may be directed to concept in the problem domain) the collection. The depiction of a message to a multiobject – a group of objects stored in a collection –

  1: inx := find(name: String): integer is indicated on the next slide.

  :StudentRecord

  1: message( )

  :ClassA Version 2 – (preferred) Emphasizes the objects in the collection, not (the solution domain) container. Representation of a collection (multiobject)

  Collaboration Diagrams Collaboration Diagrams

  Conditional Paths – mutually exclusive messages Creating a new instance during implementation of

  msg1( )

  the system operation

  1a: [test] msg2( )

  :ClassB :ClassA

  guard – if true send msg

  New

  1 1: create( ) t ( )

  c: Controller m:MenuItem

  1b: [not test] msg4( ) 1a.1: msg3( ) 1b.1: msg5( )

  :ClassC :ClassD

  2: add(m)

  :MenuItem Create a new MenuItem, m, and add it to the Menu

  Collaboration Diagrams Example Collaboration Diagram

• Emphasizes the organization of the objects that participate in an interaction _{Request(order, customer) 2: cost:=researce(order)}
• Classifier roles C ss e o es
orderTaker TicketDB<
• Association
_{ome er) rcos} t)<
• Messages, flow, and sequencing cust tom _{Kent State University}
_{17 Kent State University CreditBureau 1: ch 3: d redit eckC ebit( (cus 18}

  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. :ClassA :ClassB _{msg1( )} Focus of control is illustrated with an activation box ^{msg2( ) msg3( )} Each message between objects is represented with a message expression on an arrowed line between the objects Sequence Diagrams Additional Notation :ClassA :ClassB

  Object creation -- let the classB object create an instance of a classC object.

  Newly created class is placed in a column starting at the level _{msg1( ) msg2( ) msg3( )} :ClassC ^{create( )} _{msg4( )} starting at the level (time) of creation. time Sequence Diagrams :ClassA :ClassB :ClassC Conditional message – has guard to specify the condition Mutually exclusive conditional message [flag = true] msg2( ) ^{msg1( )} _{[flag = false] msg3( )}

  Sequence Diagrams :ClassA :ClassB

  Iteration for a single message

  :ClassC

  Iteration for a sequence of messages _{msg1( )}

• *[i = 1..N] msg2( )
_{msg3( ) msg4( ) msg5( )} *[k = 1..M]<
• X-axis is objects
• – Object that initiates interaction is left most
• – Object to the right are increasingly more subordinate
• Y-axis is time
• – Messages sent and received are ordered by time
• Object life lines represent the existence over a period of time
• Activation (double line) is the execution of the procedure.

  Enclose the repeated sequence in a box, and indicate the multiplicity

  Sequence Diagrams

  Y i i ti Kent State University ²³

  Example: Sequence Diagram _{c:client p:planningAssistant :TicketAgent &lt;&lt;create&gt;&gt;} Kent State University ^{&lt;&lt;destroy&gt;&gt; 24 setItinerary(i) calculateRoute() route notify()}

  Message Passing Example _{S : sampler WD : sensors WS : sensors Temp : sensors Hum : sensors}

• Send – sends a signal (message) to an object _{Every 1/60 sec.}
• Return – returns a value to a caller • Call – invoke an operation • Call invoke an operation Every 0.5 sec.

  call

• Stereotypes _{Every 5 min.}

  send

• – &lt;&lt;create&gt;&gt;
• – &lt;&lt;destroy&gt;&gt; Return _{Kent State University}
_{25 Kent State University 26} Properties of Sequence Diagrams Collaboration vs Seq
• Initiator is leftmost object (boundary object) • The two diagrams really show the same information
• Next is typically a control ob>Collaboration diagrams show more static g
• Then comes entity objects • Then comes entity objects structure (however, class diagrams are better at t
• Sequence diagrams clearly highlight the _{Kent State University}
_{27 Kent State University} orderings and very useful for multi-tasking ₂₈ Refining the Class Diagram Refining the Class Diagram

  For every class, examine each collaboration diagram and identify Class name

  1. Every message received by an instance of that class – (these will be the methods for that class) Data attributes Classes to which Classes to which

  2 Each object (class) to which an instance of this class Link attributes messages are sent sends a message – (these may require reference attributes within the class, depending upon the Messages visibility) methods received

  2. Each object (class) to which an instance of this class

  Class Description

  State Transition Diagrams

  active idle off hook|dial tone [valid subscriber] talking on hook do: hang up playing dial tone dialing connecting digit digit complete|ringing answered

  //precondition: queue not full //post condition: if (queue not full) // size = size + 1 // else no change

  void enqueue(Object obj); State State transitions

  Queue( int cap);

  class Queue { private: int capacity, size; public:

  Description of Class Queue

  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.

  Size0 Size1 size2 arrival arrival arrival | balk departure departure

  Second Example – A Queue of Capacity Two

  State Transition Diagrams

  The state labeled active has substates

  Example – Nested States in Telephone Call

  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 p p p g g 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

  Guard condition – transition occurs only if condition is true

  event|output [boolean condition] [ ]

  Additional Notation State State

  State Transition Diagrams

  States are represented with an oval and label State transitions are represented with a directed arc or line

  start State 1 State 2 final state

  Transitions are labeled with the triggering event and the output if any Some events do not trigger a change in state

  St t 2 event|output

  Notation

  State Transition Diagrams

  Object dequeue(); //precondition: queue not empty //post-condition: size = size-1 }

• * modulus
• 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

  C++ header file

  Visibility

  The reference variable ps must be initialized in an initialization list, and cannot be reassigned during the life of the object.

  Computer (ProductSpec &amp; theMod) : ps(theMod) {}; //other methods }

  bli public:

  ProductSpec &amp; ps;

  (Partial) Specification of class Computer class Computer { private:

  Visibility

  The ProductSpec exists before an instance of the product is created. That product (computer) will have a permanent association with its ProductSpec that it will share access to with other computers of the same model.

  ProductSpec Computer * describes

  Example 2. permanent, shared, fixed

  Visibility

  Counter( ) : hours(24), mins(60), secs(60) {}; //other methods }

  Visibility

  public:

  Counter hours mins secs; Counter hours, mins, secs;

  Implementation of the association between Clock and Counters class Clock { private:

  Visibility

  cannot be referenced by any other object in the system

  3

  count

  Clock Counter modulus

  Example 1. permanent, exclusive , and fixed Consider a clock composed of three Counters (hours, mins, secs)

  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 d id d i th d i h th th li k b t bj t A decide during the design whether the link between objects A and B is: permanent or transient exclusive or shared fixed or variable

  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; Stack * s; ProductSpec &amp; ps; permanent and exclusive; lifetime of the counter is bounded by the lifetime of the object itself. Can be non-permanent, variable, and shared Permanent and fixed, but not necessarily exclusive; lifetime of the ProductSpec will exceed that of object

  Visibility

  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

  9. Continue elaboration of the models until the system is well understood and class specifications (In C++, header files) can be constructed.

  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

  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 g p

  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)

  Review (continued)

  5. Elaboration – Review your models for lack of clarity and inconsistency and add or modify as necessary.

  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

  2. Construct a Concept Diagram showing the static relationship (long- p g g p ( g term associations) between concepts

  Transient visibility is not remembered, but persists only during the execution of a single method. It is implemented in one of two ways.

  1. From a statement of the requirements and from the use cases identify the objects (concepts) that occur in the “problem domain”

  In designing and constructing an object-oriented system one must:

  Review

  Transient associations may also be implemented with locally declared visibility. Consider a method breadfirstSearch 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.

  Visibility

  A ProductSpec object is passed to the Sale object for use by its makeLineItem method

  1: [new sale] create()

  Parameter visibility – object C is passed from A to B :ProductCatalog :POST :Sale 2: spec:= specification(upc) 3: makeLineItem(spec, qty)

  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)