0% found this document useful (0 votes)
15 views

Unit Iv

ooad unit 4 jntuk r20

Uploaded by

kondri tejaswini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views

Unit Iv

ooad unit 4 jntuk r20

Uploaded by

kondri tejaswini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 60

Unit-iv

• Basic Behavioral Modeling-I:


• Interactions,
• Interaction diagrams
• Use cases,
• Use case Diagrams,
• Activity Diagrams.
• Case Study:
• Web Application: Vacation Tracking System
Interaction diagrams
• An interaction diagram is a graphical
representation of how objects interact with
one another in a scenario.
There are four types of interaction diagrams–
1. sequence diagrams,
2. communication diagrams,
3. interaction overview diagrams and
4. timing diagrams.
Interactions
• objects interact by exchanging messages.
• A message is typically 'sent' using a normal function call,
• but can also be sent as an inter-thread or inter-process
signal, or an event triggered by a hardware device or
operating system interrupt such as a timer.
• An interaction is a set of message exchanges that
collectively achieve some purpose, usually one that
represents some higher-level action.
• In other words, an interaction is the collection of inter-
object messages that produces some outcome.
The key elements in interaction diagrams

• lifelines
• messages.
Life lines
• Lifeline is a named element which represents
an individual participant in the interaction.
Life line syntax

Each lifeline has an optional name, a type and an optional selector.

Name - used to refer to the lifeline within the interaction.

Type - the name of the classifier of which the lifeline represents an instance.

Selector - a Boolean condition that may be used to select a single instance


that satisfies the condition.
Graphical representation of life line
• A lifeline is shown using a symbol that consists
of a rectangle forming its "head" followed by a
vertical line (which may be dashed) that
represents the lifetime of the participant.

Lifeline "data" of class Stock


Message

• A message represents a specific kind of


communication between two lifelines in an
interaction.
• This communication may involve:
• calling an operation - a call message;
• creating or destroying an instance - a creation
or destruction message;
• sending a signal.
Types of messages
1. Synchronous message

2. Asynchronous message

3. Message return

4. Object creation

5. Object destruction

6. Found message

7. Lost message
synchronous message call.
• In a synchronous message call, the sender
waits for the receiver to finish executing the
requested

Synchronous call messages are shown with filled arrow head.

Web Client searches Online Bookshop and waits for results.


Asynchronous Call

• Asynchronous call –
• send message and proceed immediately
without waiting for return value.
Asynchronous messages have an open arrow
head.
Service starts Task and proceeds in parallel without waiting.
Reply Message
Reply message to an operation call is shown as a dashed line with open arrow
head (looks similar to creation message).

Web Client searches Online Bookshop and waits for results to be


returned.
Create Message

• Create message is sent to a lifeline to create


itself.
It is shown as a dashed line with open arrowhead (looks the same as
reply message), and pointing to the created lifeline's head.

«create»,
Delete message (called stop ) is sent to terminate another
lifeline.
The lifeline usually ends with a cross in the form of an X at the
bottom denoting destruction occurrence.
Lost Message
is a message where the sending event is known, but there is no receiving
event.

It is interpreted as if the message never reached its destination.

The semantics is the trace <sendEvent>, receiveEvent is absent.

Lost messages are denoted with as a small black circle at the arrow end of the
message.

Web Client sent search message which was lost.


Found Message

• Found Message is a message where the


receiving event is known, but there is no
(known) sending event.
• It is interpreted as if the origin of the message
is outside the scope of the description.
• The semantics is simply the trace:
<receiveEvent>, while send event is absent.
• Found Messages are denoted with a small black
circle at the starting end of the message.
Online Bookshop gets search message of unknown origin.
Types of interaction diagrams

• Sequence diagrams .

• Communication diagrams .

• Interaction overview diagrams.

• Timing diagrams.

• Sequence and communication diagrams are the most important


diagrams from the perspective of use case realization,
Sequence Diagram
• It shows an interaction between life lines
arranged in a time sequence.
• It has two dimensions :
1.Vertical Dimension representing time
2.Horizontal Dimension representing different
objects.
Sequence Diagram : Objects

• An object is shown as a box of at the top of


the dashed vertical line also know as the
lifeline of the object.
• It represents the object’s existence during the
interaction.
Sequence Diagram : Message
• An interaction is a set of messages exchanged
among a set of objects to accomplish a
particular purpose within a given context
(such as a collaboration).

• A message can be either a signal or a call.


• Within a process or a thread, messages are
ordered in sequence by time.
Sequence diagram for with drawing amount from ATM
The basic events flow for the use case Withdraw Funds is shown below:

1. The account holder identifies himself to the ATM.


2. The ATM requests the account holder authentication.
3. The account holder provides his authentication.
4. The ATM authenticates the holder’s identity with the holder’s bank.
5. The bank confirms the holder’s identity authentication.
6. The ATM requests for an operation from the account holder.
7. The account holder selects the operation “Withdraw Funds”.
8. The ATM requests for an amount.
9. The account holder provides with an amount.
10. The ATM requests the holders’s bank for funds withdrawal authorization.
11. The holders’s bank authorizes the withdrawal.
12. The ATM provides a receipt.
13. The account holder takes the receipt.
14. The ATM releases the holder’s identification means.
15. The account holder takes his identification (if the identification was a physical object).
16. The ATM dispenses the money.
17. The account holder takes the money.
Activity diagrams
• What are activity diagrams?
• Activity semantics
• Activity partitions
• Activity nodes : control nodes and object
nodes , pins.
• Advanced activity diagrams
What is an activity diagram?
• Activity diagram is another important diagram
in UML to describe dynamic aspects of the
system.
• Activity diagrams are OO flowcharts.
• In the Unified Modeling Language, activity
diagrams can be used to describe the business
and operational step-by-step workflows of
components in a system.
Activities

• Activities are networks of nodes connected by


edges. There are three categories of node:
• 1.action nodes - represent discrete units of
work that are atomic within the activity;
• 2.control nodes - control the flow through the
activity;
• 3.object nodes - represent objects used in the
activity.
Edges
• Edges represent flow through the activity.
There are two categories of edge:
• 1.control flows - represent the flow of control
though the activity;
• 2.object flows - represent the flow of objects
through the activity.
simple activity diagram for the business
process Send letter.
an example of an activity diagram for order
management system.
• The following diagram is drawn with the four
main activities:
• Send order by the customer
• Receipt of the order
• Confirm order
• Dispatch order
• The activity diagram is made to understand
the flow of activities and mainly used by the
business users.
Activity semantics

Activity diagrams model behavior using the


token game.
This game describes the flow of tokens around
a network of nodes and edges according to
specific rules.

Tokens move from a source node to a target


node across an edge depending on:
–source node postconditions;
–edge guard conditions;
–target preconditions.
Activity partitions

• To make your activity diagrams easier to read,


activities may be divided into partitions using
vertical, horizontal or curved lines.
• Each activity partition represents a high-level
grouping of related actions.
• Activity partitions are sometimes called
swimlanes
Action nodes

• Action nodes execute when:


• there is a token simultaneously on each of
their input edges AND
• the input tokens satisfy all of the action node
local preconditions
Action nodes perform a logical AND on their input tokens –

the node isn’t ready to execute until tokens are present on all of its input edges .
There are four types of action nodes.
Call action node
• The most common type of action node is the
call action node.
This type of node can invoke:
• an activity;
• a behavior;
• an operation.
Accept time event action node
• It responds to time.
• This type of node has a time expression, and it
generates a time event when this expression
becomes true.
Control nodes

• Control nodes manage the flow of control


within an activity .
Initial & final nodes
• The initial node is the point at which flow
starts when an activity is invoked.
• An activity may have more than one initial
node.
• The activity final node stops all flows within
an activity.
• The flow final node simply stops one of the
flows within the activity.
Decision and merge nodes
• A decision node has one input edge and two
or more alternate output edges.
• The decision node acts like a crossroads in the
flow where the token must take one direction
only.
• Each of the output edges is protected by a
guard condition such that the edge will accept
a token if and only if the guard condition
evaluates to true.
Merge nodes
• Merge nodes have two or more input edges
and a single output edge.
• They merge all their incoming flows into a
single outgoing flow.
Fork and join nodes
• A fork node splits a flow into multiple
concurrent flows.
• A fork node has one incoming edge and two or
more outgoing edges.
• Join nodes have multiple incoming edges and
a single outgoing edge.
• a simple example of a Product process that
uses fork and join nodes. In this example:
• the product is designed first;
• the product is marketed and manufactured
concurrently;
• the product is sold only after both the
marketing and manufacturing processes are
complete.

You might also like