Use Case and it's component, Interaction diagram

1. T.Y. B.Sc. (Comp. Sci.) Sem I
Object Oriented Software Engineering
(OOSE)
CS-336
Faculty
Dr. Amit D. Kasliwal
Asst. Professor

2. Chapter 5
Basic Behavioral Modeling
Overview
• Interactions
• Use Cases and Use Case Diagram with stereo types
• Interaction Diagram
• Sequence Diagram
• Activity Diagram
• State Chart Diagram

3. Interaction
 An interaction is a behavior that comprises a set of
messages exchanged among a set of objects.
 A message is a specification of a communication
between objects that conveys information with the
expectation that activity will ensue.
 You may find an interaction wherever objects are
linked to one another.
 You will also find interactions in the context of an
operation.
 Finally, you'll find interactions in the context of a
class.

4.  An objects participate in an interaction are either concrete things
(represents something in the real world) or prototypical things.
 For example, p, an instance of the class Person, might represent a
particular human. Alternately, as a prototypical thing, p might
represent any instance of Person.
 Although abstract classes and interfaces, by definition, may not
have any direct instances, you may find instances of these things
in an interaction.
 You can think of an object diagram as a representation of the static
aspect of an interaction, as an interaction by specifying all the
objects that work together.
 An interaction goes further by introducing a dynamic sequence of
messages that may pass along the links that connect these objects.
Interaction

5. Interaction
 For interaction, A link is a semantic connection among
objects. In general, link is an instance of an association.
 Wherever a class has an association to another class, there
may be a link between the instances of the two classes;
wherever there is a link between two objects, one object can
send a message to the other object.

6. Interaction
 In interaction, a message is may be consider as an instance
of an event.
 When you pass a message, the action that results is an
executable statement that forms an abstraction of a
computational procedure.
 An action may result in a change in state

7. • A use case is a description of a set of sequences of actions,
that a system performs to yield an observable result of value
to an actor.
• Every use case must have a name that distinguishes it from
other use cases. A name is a textual string.
• The name alone is known as a simple name; a path name is the
use case name prefixed by the name of the package in which
that use case lives.
• Graphically, a use case rendered as an ellipse showing only
its name
Use Case Diagram

8. • A use case diagram help system analyst to discover
the requirements of the target system from the users
perspective.
• Provides functional description of a system & its
major processes.
• Provides graphic description of the users of a system
& what kinds of interactions to exact within that
system.
• Displays the details of the processes that occur
within the application area.
• Used to design the test cases for testing the
functionality of the system.
Use Case Diagram

9. • Following are the elements of Use Case Diagram
• Actors
• Use Case
• System Boundary
• Association
• Relationships in usecases
Use Case Diagram

10. • An actor portrays any entity (or entities) that performs certain
roles in a given system.
• Actor can be users, organization and external system.
• Actors are responsible for giving input to the system.
• It is shown as a stick figure in a use case diagram depicted
“outside” the system boundary.
• Place an actor that initiates a use case on the left of the use
case & an actor receives the results of a use case appears on
the right of the use case.
Actor Name
<<actor>>
Iconic Notation for
actor
member
<<actor>>
member
Iconic Notation for
actor
Use Case Diagram

11. • Types of actors
• Primary actors
• The main users or entities for which the system is
designed, deriving benefits from it directly.
• They are completely outside the system &drive the
system requirements.
• Use the system to achieve an observable user goal.
• Secondary actors
• Users or entities that supervise, operate or manage the
system.
• They play a supporting role to facilitate the primary actors to
achieve their goals.
• Often appears to be more inside the system than outside.
• They are usually allocated many system requirements that
are not drive directly from the statements of requirements.
Use Case Diagram

12. • Use Case
• Use case in a use case diagram is a visual representation
of a distinct business functionality in a system.
• It is a sequence of transactions performed by the system
that produces a major suit for the actor.
• Ause case is shown as an ellipse in a use case diagram.
• It must have unique and textual (simple/qualified)
name.
Use Case
Request
Book
LMS:Request
Book
Use Case Diagram

13. • System Boundary
• It defines the scope of what a system will be.
• Asystem cannot have infinite functionality.
• Defines the limits of the system.
• It is shown as a rectangle spanning all the use
cases in the system.
Use case
Use case
Use caseActor
Issue book
Return
book
System boundary
LMS
Request
book
student
Use Case Diagram

14. • Communication Lines / Relationships
• Use case diagram has communication lines or links to
show communication between its various components.
• Association
• Dependency
• Include
• Extend
• Use casegeneralization
Use Case Diagram

15. • Association
• It is used to describe the relationships between actors &
the use cases they participate in. drawn as a solid line
• Association can be unidirectional &bidirectional.
• It indicates either that the actor initiates the use case, or
receives the results of executing a use case.
.
Use case
Use case
Use caseActor
Association
Issue book
Return
book
LMS
Request
book
student
Use Case Diagram

16. • Dependency
• Arelationship between two use cases is basically a
dependency between two use cases.
• Include
• Include is used when two or more use cases share some
common portion in the flow of events.
• It shows interaction between base use case &inclusion use
case .Inclusion use case is consist of feature of base use case.
• The stereotype <<include>> identifies the relationship
include. Issue
Journal
Issue
Book
Verify
Library Card
<<include>>
<<include>>
Use Case Diagram

17. • Dependency
• Extend
• In an extend relationship , the child use case adds to the
existing functionality &characteristics of the parent use case
• The stereotype <<Extend>> identifies the relationship
Extend.
Excess money
<<Extend>>
Withdraw money
Use Case Diagram

18. • Multiplicity
• How many instances of an actor interact with how many
instances of use case.
• By default we assume one instance of an actor interacts
with one instance of a use case.
• Multiplicity is indicated by number or with the range
separated by two periods(..) or special character .
Withdraw
money
1 0..1
18
Customer
Use Case Diagram

19. • Use Case Generalization
• Aparent-child relationship between use cases.
• Child use case is the enhancement of the parent use case
• Generalization is same as extend relationship
• In generalization parent use case can be replaced by
child but it s not possible with extend
Pay bill by
post
Pay bill by
internet
Pay Bill
19
Use Case Diagram

20. Buy Books
Pay
Bill
Prepare Bill
Validate
CustomerSearch Books
Register
Customer
<<include>>
20
<<include>>
<<include>>
<<include>>
Use Case Diagram
Update Books

21. • Sequence diagrams describe interaction among classes
in terms of an exchange of messages over time.
• Depicts the sequence of actions that occurs in a system.
• The order of invocation of methods in each object is
captured by sequencediagram.
• Shows the dynamic behavior of a system.
• It is two-dimensional in nature.(horizontal axis shows
the life of the object & vertical axis shows the sequence
of the creation or invocation of these objects.
• Used to model usage scenarios, the logic of methods
and thelogic of services.
Sequence Diagram

22. • Elements of Sequence Diagram
• Class Roles
• Actor
• Lifelines
• Messages
• Activation
• Creating objects
• Deleting objects
• Simple &BlockIteration
• Branching
Sequence Diagram

23. • Class Roles
• Class roles describe the way an object will behave in
context.
• Use the UML object symbol to illustrate class roles, but
don’t list objectattributes.
• Actor
• An external entity that interacts with the system
.
Object Name : Class
Name
:Class Name
Actor
Sequence Diagram

24. • Lifeline
Vertical dashed lines that indicate the objects presence
over time.
Object :Class Object :Class
Actor
C : Cashier B:Bill
l
Customer
Prepare bil <<create>>
Lifelines 2/15/2017jaya kolekar 19
Sequence Diagram

25.  Messages
 Messages that arrows that represent communication
between objects.
 Each message sent to a class invokes a static method /
operation on that class.
 Each message sent to an object invokes an operation on
that object.
Object :Class Object :Class
Actor
C : Cashier B:Bill
l
Customer
Prepare bil <<create>>
message
Sequence Diagram

26. Arrow Message Type Description
Synchronous Sender sends message to receiver &wait
for procedure completion receiver.
Simple Messages with single thread of control.
One object sends the message to the
passive object.
Asynchronous The sender sends the message &
immediately continues with next step.
Return Return message from called procedure of
the receiver to the sender.
Delayed
message
The message will take significant time
to arrive at the receiving object.

27. Sequence Diagram

28.  Activation : Activation Box represent the time an object
needs to complete a task.
 The receiver object is active when it receivers the
message from sender.
 Each message sent to an object invokes an operation on
that object.
Object :Class Object :Class
Actor
C : Cashier B:Bill
l
Customer
Prepare bil <<create>>
Activation
Sequence Diagram

29. • Creating objects
• Objects can be created during interaction.
• An object dynamically create a new object by using
<<create>> message.
• New objects lifeline starts with the receipt of create
message.
C : Cashier B:Bill
l
Customer
Prepare bil <<create>>
<<create>>
Sequence Diagram

30. • Deleting objects
• Objects can be deleted on receiving a <<destroy>>
message from another object.
• Alarge Cross (X) is placed at the end of the objects lifeline
to indicate that the objects life has been terminated at
that time.
:order
01:OrderLine
Additem(i)
new(i)
:Shopping cart
<<destroy>>
remove(i)
Sequence Diagram

31. • Structured control
• Asequence of messages is fine for showing a single, linear
sequence, but often need to show conditionals &loops.
• Shows concurrent execution of multiple sequences.
• Acontrol operator is shown as a rectangular region within the
sequence diagram.
• Control operator has a tag a text label inside a small pentagon
in the upper left corner to tell what kind of a control operator
it is.
• Types of control in sequence diagram
• Optional Execution
• Conditional Execution
• Parallel Execution
• Loop(Iterative) Execution
Sequence Diagram

32. • Simple &block iteration
• Sometimes a task is to be performed repeatedly, then in
sequence diagram such task is represented by a name
preceded by an asterisk “ * “.
• Arepetition or loop within a sequence diagram is depicted as a
rectangle. C : Cashier B:Bill
Customer
Prepare bill <<create>>
B:Bill
Buyproduct
Get productdetails
Add product
Update quantity
[all product added]
unDisplay total Calculate total amo t
loop
Sequence Diagram

33. Structure control : Conditional execution
Sequence Diagram

34. Sequence Diagram

35. Sequence Diagram

36. • A sequence diagram is an interaction diagram which
emphasizes on the time ordering of messages.
• It is an alternate representations of an interaction (Collaboration)
• Sequence diagram describe the interaction among classes in
terms of an exchange of message over time.
• It shows the sequence of actions that occurs in system
• Sequence diagrams are normally associated with use cases
• The elements of sequence diagram are class roles, activation,
Message, lifeline, creating objects, destroying objects and loops.
• We can show simple branching in sequence diagram
• Best used during early analysis phases in design because they
are simple and easy to comprehend
Sequence Diagram

37. • It shows the dynamic nature of the system.
• Like basic behavioral modeling, Advanced Behavioral
model describes the interaction in the system
Diagrams used are
Activity Diagram
State Chart Diagram

38. • Activity diagram used for modeling dynamic aspect
of systems.
• It is used for business process(logic & rules) modeling.
• It is essentially a flowchart, showing flow of control
from activity to activity.
• It shows concurrency as well as branches of control.
• It describes
• How activities are coordinated to provide a service.
• The events needed to achieve some operation.
• Focus on the flow of activities involved in a single
process.
Activity Diagram

39. • Elements of Activity Diagram
• Start /Initial Activity
• Activity Node
• Action
• Transition
• Decisions
• Synchronization Bar [Fork and Join ]
• Final Activity

40. • Start / Initial Activity
• This shows the starting point of first activity of
the flow .
• Graphically denoted by a solid circle.
• There can be only one initial state in a diagram.
Initial Activity

41. • Activity
• Activity is parameterized behavior represented as
coordinated flow of actions.
• An activity is a process being modeled, such as washing
a car.
• An activity is a set of actions.
• Represented by a rectangle with rounded (almost oval )
edges.
Activity Scan library card

42. • Action
• An action represent a single step within an activity.
• Actions are active steps in the completion of
a process like calculations.
• Represented by a rectangle with rounded corner.
Action Bill=item*price
Activity Diagram

43. • Transition The flow of the activity is shown using arrowed lines
called transition.
• A line going into a node is called an incoming edge, and a line
exiting a node is called an outgoing edge.
• Transitions are modeled using arrows.
Supplier sends shipment
and bill
Generate shipment
error notice
Send it to
supplier
S/R clerk verifies the
bill
with purchase order
Send shipment to
inspector
Activity 1
Activity 2
Transition
Activity Diagram

44. • Decision/Branching Similar to flowcharts, a logic where a decision is to be
made is depicted by a diamond , with the options written on either side
of the arrows emerging from the diamond, within box brackets.
Supplier sends shipment
and bill
Generate shipment error
notice
Send it to supplier
S/R clerk verifies the bill
with purchase order
Send shipment to
inspector
Activity3
actyivity1
Activity2
Decision
[opt 1] [opt2]
Guard expression

45. Check account
balance
Scan library card
Pay overdue fine
Scan asset
[Unpaid overdue fine]
[no unpaid fine]
Branch
Merge
Guard expression
Activity Diagram

46. .
• Synchronization Bar [Fork and Join]
• Activities often can be done in parallel to split (“fork”)
processing, or to resume processing when multiple
activities have been completed (“join”), synchronization
bars are used.
• These are modeled as solid rectangles, with multiple
transitions going in and/or out.
• Fork denotes the beginning of parallel activity.
• Join denotes the end of parallel processing.
Synchronization bar
Activity Diagram

47. • Forking node
• Join node
Activity Diagram

48. Synchronization Bar
[Fork and Join] activity1
activity3activity2
activity5
activity4
activity6
Start
Fork
Join
Merge
Branch
[condition 2][condition 1]
End

49. Receive order
Send InvoiceFill order
Regular delivery
Overnight delivery
Close order
Start
Fork
Join
Merge
Branch
[normal order][rush order]
Receive
payment
Activity diagram for
processing an order
End

50. • Swim Lanes
• A swim lane used to distinguish activities carried out by
individual actors in an activity diagram.
• Swimlanes are vertical columns separated by thick vertical
black lines with actor’s name.
• Place each of the activity below the actor performing these
activities & then show how these activities are connected.
• Each swim lane has a unique name within its diagram. It
represents some real world entity.
• In an activity diagram partitioned into swim lane, every
activity belongs to exactly on swim lane, but transitions
may cross lanes.
Activity Diagram

51. Actor Actor Actor
activity
activity
activity
activity
activity
activity
swimlane

52. Customer Sales Stockroom
Request
service
Pay bill
Take Order
Fill Order
Deliver Order
Collect Order

53. • Final Activity
• The end of the activity diagram is shown by a bull’s
eye symbol, also called as a final activity.
• An activity diagram can have zero or more activity
final nodes.
Graphical notation
Activity Diagram

56. • Using an interaction we can model the behavior of a
society of objects.
• Also we can model the behavior of an individual object.
• State machines may be visualized in two ways.
• Using activity diagram, we can focus on the activates that
take place within the object.
• Using state-chart diagrams(state diagram), we can focus
on the event-ordered behavior of an object, which is
especially useful in modeling reactive systems.
State Chart Diagram

57. • Purpose of State Chart Diagrams:
• To model dynamic aspect of a system.
• To model life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model states of an object .
• Elements of state chart diagram
• Initial State
• State
• Transition
• Event
• Final State
State Chart Diagram

58. • Initial State
• This shows the starting point or first activity of the flow.
• Denoted by a solid circle.
• This is also called as a pseudostate , where the state has no
variable describing it further and no activities.
Initial State
State Chart Diagram

59. • State
• Represents the state of object at an instant of time.
• It is a condition or situation during the life of an object
during which it satisfies some condition, perform some
activity, or waits for some event.
• Denoted by a rectangle with rounded corners &
compartments.
• Changes in the system that occur, in background thread
while the main process is running, are called sub states.
State
notation
State Name
State variable
Board train
Train-no
State Action
State Chart Diagram

60. • Parts of state
• Name
• Entry/exit effect
• Internal transition
• Substates
• Deferred events
State Chart Diagram

61.  Transition
 An arrow indicating the object to transit from one state to
the other.
 The actual trigger event & action causing the transition
are written beside the arrow, separated by a slash.
 Transitions that occur because the state completed an
activity are called triggerless transitions.
 If an event has to occur after the completion of some
event or action, the event or action is called the guard
condition.
Event[Guard condition ]/Action
State Chart Diagram

62. • Parts of Transition
• Source state Event Trigger
• Guard Condition Effect or Action
• Target state
• Event
• An event is something that happens at a point in time.
• An event is a one way transmission of information from one
object to another
• An event has no duration. Following are the types of events
• CallEvent SignalEvent
• TimeEvent ChangeEvent
State Chart Diagram

63. • Final Sates
• The end of the state diagram is shown by a bull’s eye
symbol, also called a final state.
• A final state is another example of a pseudo
state because it does not have any variable or
action described.
Final
State
State Chart Diagram

64. • Entry & Exit Actions
• An alternative to showing actions on transitions,
actions can be associated with entering or exiting a
state.
• Entry and Exit action is shown inside the state box
following the keyword Entry or exit and “ / “
State name
Entry/action
Exit/action
Event/action1,action2
Do/activity
Event/defer
State Chart Diagram

65. • Internal Transition
• Internal transitions are the events handled inside a state
without leaving it.
• Used when we want to handle the event but don’t want to
fire the states entry & exit action.
• Activities
• In a state the object does some work that will continue
until it is interrupted by an event
• Deferred events
• It is a list of events that are not handled in that stae but,
rather, are postponed and queued for handling by other
object in another state.
State Chart Diagram

66. Idle
Validating
Selectin
g
Card
inserted
cancel
Active
Printing
maintain
[continue]
Maintenance
Processing
[not
continue]
Entry/read card
Exit/eject card
State Chart Diagram

67. • History States
• A flow may require that the object go into a trance, or wait
state, and on the occurrence of a certain event, go back to the
state it was in when it went into a wait state-its last active
state.
• This is shown in a state diagram with the help of a letter
H enclosed within a circle.
H
History State
State Chart Diagram

68. Washing
CleanUP
Start[close door]
[open door]
Idle
Rinsing
Active
H
History State
State Chart Diagram

69. Engineering Study
Clear Theory Exam
Clear practical exam
Concurrent State
State Chart Diagram

70. Idle
Testing
device
s
Sel
fdiagnosis
Waiting command
commanding
Composite state
Maintenance
Testing
Concurrent states
maintain
Concurrent State
State Chart Diagram

71. • State chart diagram is simply a presentation of a state
machine which shows the flow of control from state to state.
• State chart diagrams are important for constructing
executable systems through forward & reverse engineering.
• Useful in modeling the lifetime of an object
• State chart diagrams commonly contain – Simple states and
composite states, Transitions- including events and actions
• It is one of the five diagrams in UML for modeling the
dynamic aspects of systems.
State Chart Diagram