Tải bản đầy đủ (.ppt) (46 trang)

UML sơ đồ tương tác

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (558.14 KB, 46 trang )

UML Sơ đồ tương tác
GV : TS. Trương Quốc Định
Sequence Diagrams2
Interaction Diagrams

A series of diagrams describing the dynamic behavior of
an object-oriented system.

A set of messages exchanged among a set of objects within a
context to accomplish a purpose.

Often used to model the way a use case is realized through a
sequence of messages between objects.
Sequence Diagrams3
Interaction Diagrams (Cont.)

The purpose of Interaction diagrams is to:

Model interactions between objects

Assist in understanding how a system (a use case) actually
works

Verify that a use case description can be supported by the
existing classes

Identify responsibilities/operations and assign them to classes
Sequence Diagrams4
Interaction Diagrams (Cont.)

UML



Collaboration Diagrams

Emphasizes structural relations between objects

Sequence Diagram

The subject of this tutorial
Sequence Diagrams5
A First Look at Sequence Diagrams

Illustrates how objects interacts with each other.

Emphasizes time ordering of messages.

Can model simple sequential flow, branching, iteration,
recursion and concurrency.
Sequence Diagrams6
Object

Object naming:

syntax: [instanceName][:className]

Name classes consistently with your class diagram
(same classes).

Include instance names when objects are referred to
in messages or when several objects of the same
type exist in the diagram.


The Life-Line represents the object’s life
during the interaction

Lifelines are drawn as a box with a dashed line
descending from the center of the bottom edge.
The lifeline's name is placed inside the box.
myBirthday
:Date
Sequence Diagrams7
Messages

An interaction between two objects is performed as a
message sent from one object to another (simple
operation call, Signaling, …)

If object obj
1
sends a message to another object obj
2

some link must exist between those two objects
Sequence Diagrams8
Messages (Cont.)

A message is represented by an arrow between the life
lines of two objects.

Self calls are also allowed


The time required by the receiver object to process the
message is denoted by an activation-box.

A message is labeled at minimum with the message
name.

Arguments and control information (conditions, iteration)
may be included.
Sequence Diagrams9
Return Values

Optionally indicated using a dashed arrow with a label
indicating the return value.

Don’t model a return value when it is obvious what is being
returned, e.g. getTotal()

Prefer modeling return values as part of a method invocation,
e.g. ok = isValid()

Model a return value when you need to refer to it elsewhere,
e.g. as a parameter passed in another message.
Sequence Diagrams10
Synchronous Messages

Nested flow of control, typically implemented as an
operation call.

The routine that handles the message is completed before the
caller resumes execution.

:A :B
doYouUnderstand()
Caller
Blocked
return
(optional)
yes
Sequence Diagrams11
Asynchronous Messages

If a caller sends an asynchronous message, it can continue
processing and doesn’t have to wait for a response.

We can see asynchronous calls in multithreaded
applications and in message-oriented middleware.
Asynchrony gives better responsiveness and reduces the
temporal coupling but is harder to debug.
Sequence Diagrams12
Object Destruction

An object may destroy another object via a
<<destroy>> message.

An object may destroy itself.

Avoid modeling object destruction unless memory
management is critical.
:A :B
<<destroy>>
Found Message


A found message is a message where the receiving event
occurrence is known, but there is no (known) sending
event occurrence.

We interpret this to be because the origin of the message
is outside the scope of the description. This may for
example be noise or other activity that we do not want to
describe in detail.
Lost Message

A lost message is a message where the sending event
occurrence is known, but there is no receiving event
occurrence.

We interpret this to be because the message never reached
its destination.
Self Message

A message defines a particular communication between
Lifelines of an Interaction.

Self message is a kind of message that represents the
invocation of message of the same lifeline.
Recursive Message

A message defines a particular communication between
Lifelines of an Interaction.

Recursive message is a kind of message that represents

the invocation of message of the same lifeline. It's target
points to an activation on top of the activation where the
message was invoked from.
Object state and Constraint

Sequence diagrams can show how an object changes state
overtime.

We do this by placing the object state on the lifeline at the
appropriate point. This allows we to see very clearly
which events give rise to state changes.
Object state and Constraint (cont.)
Object state and Constraint (cont.)

The message acceptPayment(…) causes a state transition
on the :Order object from state unpaid to paid.

The message deliver( ) sent from the :DeliveryManager
object to the :Order object causes a state transition in
:Order from state paid to delivered.

The timing constraint says that there must be 28 days or
less between time A and time B. Time A marks the point
at which the :Order object undergoes transition into the
state paid, and time B marks the point at which the :Order
object undergoes transition into the state delivered.
Combined Fragment

Combined fragment is an interaction fragment which
defines a combination (expression) of interaction

fragments. A combined fragment is defined by an
interaction operator and corresponding interaction
operands. Through the use of combined fragments the user
will be able to describe a number of traces in a compact
and concise manner.
Combined Fragment (Cont.)

Interaction operator could be one of:

alt - alternatives

opt - option

loop - iteration

break - break

par - parallel

strict - strict sequencing

seq - weak sequencing

critical - critical region

ignore - ignore

consider - consider

assert - assertion


neg - negative
Alternatives

The interaction operator alt means that the combined
fragment represents a choice or alternatives of behavior.
At most one of the operands will be chosen. The chosen
operand must have an explicit or implicit guard expression
that evaluates to true at this point in the interaction.

An implicit true guard is implied if the operand has no
guard.

An operand guarded by else means a guard that is the
negation of the disjunction of all other guards. If none of
the operands has a guard that evaluates to true, none of the
operands are executed and the remainder of the enclosing
interaction fragment is executed.
Alternatives (Cont.)
Option

The interaction operator opt means that the combined
fragment represents a choice of behavior where either the
(sole) operand happens or nothing happens. An option is
semantically equivalent to an alternative combined
fragment where there is one operand with non-empty
content and the second operand is empty.
Loop

The interaction operator loop means that the combined

fragment represents a loop. The loop operand will be
repeated a number of times. The loop construct represents
a recursive application of the seq operator where the loop
operand is sequenced after the result of earlier iterations.

Loop could be controlled by either or both iteration
bounds and a guard.

Loop operand could have iteration bounds which may
include a lower and an upper number of iterations of the
loop. Textual syntax of the loop is:

loop-operand ::= loop [ '(' min-int [ ',' max-int ] ')' ]

min-int ::= non-negative-integer

max-int ::= positive-integer | '*'

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay
×