Download - Interaction diagram
Engineering Technical college-ErbilDep. of ISE
Software ConstructionLecture Slides #5: Interaction UML models S1 2014
Asst.Prof.Dr.Raghad Z.Yousif
Dynamic Modeling with UML
Diagrams for dynamic modeling Interaction diagrams describe the dynamic
behavior between objects Statecharts describe the dynamic behavior of a
single object
Dynamic Modeling with UML
Interaction diagrams Sequence Diagram:
Dynamic behavior of a set of objects arranged in time sequence, new objects added to the right
Good for real-time specifications and complex scenarios Derived from use case scenario
Collaboration Diagram : Shows the relationship among objects. Does not show time Objects are arranged in a graph or network format
Sequence Diagrams vs Collaboration Diagrams
Sequence diagram
:ClassA
message2()
:ClassB
message1()
message3()
Sequence Diagrams vs Collaboration Diagrams
Collaboration diagram
:ClassA
:ClassB
message1()
1. message2()
2. message3()
Sequence Diagrams vs Collaboration Diagrams
Sequence diagrams : Strength: clearly show sequence or time ordering of
events, simple notation Weakness: forced to extend to the right when adding
new objects Collaboration diagrams :
Strength: space economical flexibility to add new objects in two dimensions, better to illustrate complex branching, iteration and concurrent behavior
Weakness: difficult to see sequence of messages, more complex notation
Dynamic Modeling with UML State Chart Diagram:
A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events).
Activity Diagram: Special type of statechart where all states are action
states
State Chart Diagram vs Sequence Diagram
State chart diagrams help to identify: Changes to objects over time
Sequence diagrams help to identify The temporal relationship between objects over time Sequence of operations as a response to one ore more
events
Dynamic Modeling
Definition of dynamic model: A collection of multiple state chart diagrams, one
state chart diagram for each class with important dynamic behavior.
Purpose: Detect and supply methods for the object model
How do we do this? Start with use case or scenario Model interaction between objects => sequence
diagram Model dynamic behavior of single objects =>
statechart diagram
Start with Flow of Events from Use Case
Flow of events from “Process Sale” Use case: 1. Customer arrives at POS checkout with goods and/or
services 2. Cashier starts new sale 3. Cashier enters item identifier 4. System records sale line item and presents item
description, price and running total. Cashier repeats steps 3-4 until indicates done
5. System presents total with taxes calculated 6. Cashier tells customer the total and asks for
payment 7. Customer pays and system handles payment
What is an Event?
Something that happens at a point in time Relation of events to each other:
Causally related: Before, after, Causally unrelated: concurrent
An event sends information from one object to another
One distinguishes between The instance of an event : enterItem The attributes of an event : itemID, quantity
Asst.Prof.Dr.Raghad Z.Yousif
Sequence Diagrams
From the flow of events in the use case or scenario proceed to the sequence diagram
A sequence diagram is a graphical description of objects participating in a use case or scenario.
Relation to object identification: Objects/classes have already been identified during
object modeling Objects are identified as a result of dynamic modeling
Heuristic: An event always has a sender and a receiver. Find
them for each event => These are the objects participating in the use case
Sequence Diagrams
Use cases and participating objects are found. What now? Sequence diagram - A diagram that shows object
interactions arranged in time sequence for a specific use case or scenario.
A sequence diagram includes time but does not include object relationships.
A sequence diagram is useful to model a use case or scenario with its participating objects. It often leads to the detection of new participating objects.
Drawing Sequence Diagrams
Each column represents an object that is participating in the interaction.
The vertical axis represents time (from top to bottom). Messages are shown by full arrows.
Labels on full arrows represent message names and arguments.
Activations (i.e., the time it takes to perform an operation) are depicted by a rectangle attached to an object. The height of the rectangle is indicative for the duration of the operation The vertical rectangle shows that an object is active, that
is, it is handling a request made by another object. The operation can itself send other requests to other
objects An object can request an operation from itself (looping
arrow)
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Sequence Diagrams:Cashier
makenewSale()
: System
enterItem(itemID, quantity)
description, total
endSale()
total
makePayment(amount)
change due, receipt
Sequence Diagrams
Iterations may have square brackets containing a
continuation condition (until) specifying the condition that must be satisfied in order to exit the iteration and continue with the sequence
may have an asterisk followed by square brackets containing an iteration (while or for) expression specifying the number of iterations
Sequence Diagrams
Iteration in sequence diagrams is denoted by a box with an associated iteration expression.
:Cashier
makenewSale()
: System
enterItem(itemID, quantity)
description, total
*[more items]
Sequence Diagrams
Iteration in sequence diagrams is denoted by a box with an associated continuation expression.
:Cashier
makenewSale()
: System
enterItem(itemID, quantity)
description, total
[no more items]
Sequence Diagrams
Naming objects Class name only :Classname Instance name only objectName Instance name and class name together object:Class Most of the time you use the class name, but if
you refer to a particular instance in a scenario the object:Class notation is used.
A scenario is an instance of a use case, where we take real or hypothetical people and things and follow them through the steps of the use case.
Sequence Diagrams
Conditional messages: A message might contain a guard condition denoted in square brackets
obj1:Class
[x < 15] calculate()
obj2: Class
message()
Sequence Diagrams
Sequence diagrams may contain branches. Branching involves multiple messages originating at the same time from a single class role.
The branch represents conditionality if the guard conditions on all the branches are mutually exclusive. Thus, only one message is sent.
The branch represents concurrency if the guard conditions are mutually inclusive. Thus multiple messages are sent.
Sequence Diagrams
Conditionality
obj1:Class
[x < 15] calculate()
obj2: Class
message()
obj3: Class
[x > 20] calculate()
Sequence Diagrams
Concurrency
obj1:Class
calculate()
obj2: Class
message()
obj3: Class
calculate()
Asst.Prof.Dr.Raghad Z.Yousif
Sequence Diagrams
Creation and destruction of an object in sequence diagrams are denoted by the stereotypes <<create>> and <<destroy>>
:Creator
<<create>>: Created Object
message()
<<destroy>> X
Sequence Diagrams
Iteration over a Collection (multiobject) The message is send to each element rather
than repeatedly to the collection itself.
:Sale
* st:=subtotal()
:SalesLineItem
t:=total()
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Collaboration Diagrams
Collaboration diagrams contain Classes Associations Message exchanges within a collaboration
Collaboration diagrams describe a set of classes and associations involved in message exchange sequences, that is a collaboration among class roles and association roles, and their interactions.
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Asst.Prof.Dr.Raghad Z.Yousif
Collaboration Diagrams
:Register
:Payment
1: makePayment(cash)
1.1 create(cash)
:Sale
makePayment(cash)
1. The first (external) message makePayment is sent to an instance of a Register. The sender is not identified.
2. The Register instance sends the makePayment message to to a Sale instance.
3. The Sale instance creates an instance of a Payment.
Collaboration Diagrams
Link : A link is a connection path between two objects, it indicates some form of navigation and visibility between the objects. A link is an instance of an association.
Note that multiple messages, and messages both ways can be exchanged along the same link.
:Register
1: makePayment(cash)2: foo()
:Sale
2.1: bar()
link
Collaboration Diagrams
Messages : each message between objects is represented with a message expression and a small arrow indicating the direction of the message. A sequence number is added to show the sequential order of messages.
:Register
1: msg2()2: msg3() 3: msg4()
:Sale
3.1: msg5()
msg1()
Collaboration Diagrams
Creation of instances : the stereotype <<create>> and the property new are used to indicate the creation of new instances.
:Register
<<create>>1: make(cashier)
:Sale {new}
Collaboration Diagrams
Messages number sequencing : The order of messages is illustrated with sequence numbers. The numbering scheme is: The first message is not numbered The order and nesting of subsequent messages is shown
with a legal numbering scheme, in which nested messages have a number appended to them. Nesting is denoted by prepending the incoming message number to the outgoing message number
:Register
:Payment
1: msg2()
1.1 msg3()
:Sale
msg1()
Collaboration Diagrams
:classA
:classC
1: msg2()
1.1 msg3() 2.1 msg5()
:classB
msg1()
:classD
2: msg4()
2.2: msg6()
Collaboration Diagrams
Conditional Messages : A conditional message is shown by following a sequence number with a conditional clause in square brackets.
:Foo
1 [color=red]: msg2()
:Bar
msg1()
Collaboration Diagrams
:classA
:classC
1a [test]: msg2()
1a.1: msg3()
:classB
msg1()
:classD
1b [not test]: msg4()
1b.1: msg5()
Mutually exclusive messages:
State Chart Diagrams
The state of an object is defined by the set of values currently held by its attributes.
At any moment in time, an object exists in a certain manner or conditon, which we say is a state.
Source State
Entry andExit actions
Target State
Event [Guard] / Action
State Chart Diagrams
Statechart diagrams are useful when A class has an interesting or complex life cycle,
e.g. classes that create or delete instances or associations
An instance can update its attributes in a variety of ways as it goes through a life cycle.
If two classes are depending on each other, in that one of them can start the other on its life-cycle, or change the order in which it goes from state to state.
If you find that the object’s current behavior depends on what happened to it before, that is on its past history.
Statechart Diagrams
Graph whose nodes are states and whose directed arcs are transitions labeled by event names.
Distinguish between two types of operations: Activity: Operation that takes time to complete
associated with states Action: Instantaneous operation
associated with events associated with states (reduces drawing complexity): Entry,
Exit, Internal Action A statechart diagram relates events and states for one
class An object model with a set of objects has a set of
state diagrams
Statechart Diagrams
An action is an atomic behavior that is associated with a state or a transition, and is considered part of the life cycle.
Atomic means that it cannot be split any further without losing or changing the meaning of what it was.
An entry action is an action performed each time the object enters or reenters a state, regardless of how it got there.
Statechart Diagrams
State diagram for book class showing entry and exit actions
3: Checkedentry/ Loan.L2 :
Archive Loan
1: Shelvedentry/ UpdateTimeShelved()
exit / UpdateTimeOut()
2: Signed Outentry/ Loan.L1 : Request
Link to Subscriber exit / UpdateTimen()
Event B3:Librarian shelves
book
Event B1:Subscriber requests
loan
Event B2:Subscriber returns
book
Statechart Diagrams
The life-cycle of a loan instance
1: Current
<<create>> Event L1: Request Link to subscriber (Book ID No., Subscriber ID No., Date/Time Out)
2: Archivedentry/
UpdateTimeIn()
Event L2: Archive Loan(Date/Time In)
initialstate
finalstate
Event L3: After (90 days)
/delete archivedloan