The document provides an overview of advanced state modeling and interaction modeling techniques in UML. It discusses nested state diagrams and concurrent state diagrams for controlling complexity in state diagrams. It also covers activity models, use case models, and sequence models for interaction modeling. The relationships between class models, state models, and interaction models are also briefly described.

2. https://sites.google.com/a/cmrit.ac.in/manoj-c5559/

3. UNIT – 3
ADVANCED STATE MODELING, INTERACTION
MODELING:
State Modeling: Nested state diagrams; Nested states; Signal
Advanced generalization; Concurrency; A sample state model;
Relation of class and state models; Practical tips.
Interaction Modeling: Use case models; Sequence models;
Activity models. Use case relationships; Procedural sequence
models; Special constructs for activity models.

4.  Two major features are introduced for
controlling complexity and
combinatorial explosion in state
diagrams
◦ Nested state diagrams
◦ Concurrent state diagrams
 Many other features are also added
◦ propagated transitions
◦ broadcast messages
◦ actions on state entry, exit
◦ …
S2
S1
Nested State Diagrams
Concurrent State Diagrams

5.  Activities in states are composite items denoting other
lower-level state diagrams
 A lower-level state diagram corresponds to a sequence
of lower-level states and events that are invisible in the
higher-level diagram.

6.  When one state is complex, you
can include substates in it.
◦ drawn as nested rounded
rectangles within the larger
state
 Caution: Don't over-use this
feature.
◦ easy to confuse separate states
for sub-states within one state
superstate
substates

7. A state may be represented as nested substates.
◦ In UML, substates are shown by nesting them in a superstate box.
◦ A substate inherits the transitions of its superstate.

8. Idle
off hook / play dial tone
[valid subscriber] Active
on hook
PlayingDialTone
digit digit
connected
complete
Talking
Dialing Connecting

9. Simple State
Complex State
Substate1
entry: entry action
event( args )[ cond ] /
action event( args )[ cond ] / ^target.event(args)
action ^target.event(args)
Substate2
event( args )[ cond ] /
action ^target.event(args)
event( args )[ cond ] /
action ^target.event(args)

10. Super-state
event-1
A B
C
event-2
event-1
A B
event-2 event-2
C

11. Checking
do / check
Item
Dispatching
do / initiate
delivery
Delivering
[all items checked &&
some items not in stock]
Order item
[all items checked && all items available]
Dispatch items
[all items available]
Item received
delivery
get first item
Ordering
Exit/ Item received
do / order Item
cancelled Canceling
*[all items checked]
get next item
entry / deliver
Items
do / Remove
Item

13.  Transitions can be specific
◦ A transition can be from a specific
substate (T1)
◦ A transition can be to a specific
substate inside the nested state (T2)
 Transitions can be general
◦ We saw that a transition from the
superstate is valid for all substates
(T3)
◦ A transition into the superstate (T4)
normally goes to the default initial
state (start state leading to F)
T1
S
A B
E
F
C
D
T2
T4
T3

14. ◦ concurrency is a property of systems in which several computations are
executing simultaneously, and potentially interacting with each other.
◦ Dashed line indicates that an order is in two different states, e.g. Checking &
Authorizing
◦ When order leaves concurrent states, it’s in a single state: Canceled, Delivered
or Rejected
◦ Concurrent Sub states - Used when two or more state diagrams are
executing concurrently within a single object.

15.  Complex systems usually have
concurrency
◦ “subsystems” that operate (mostly)
independently
 Heart monitor device
◦ The power supply and the heart
monitoring application are really
concurrent subsystems
◦ They should be modeled that way!!
◦ They are mostly independent: the
monitoring application doesn’t care
where it gets its power
Heart Monitor
Monitoring
Subsystem
Power
Subsystem

16. Startup
Alarm
Operational
Off
Switch on
Switch off
Startup
Complete
Problem
detected
Running
Monitoring Subsystem
Mains on
Battery Mains
Mains off
Dotted line
separates
concurrent state
machines
Power Subsystem

17. release key
Ignition turn key to start
[Transmin iNsseiountral]
turn key off
Transmission
Forward
Accelerator
depress accelerator
release accelerator
push R
push N
push N push F
upshift
downshift
upshift
downshift
stop
Brake
depress brake
release brake
Car
off starting on
Neutral Reverse
first second third
off on off on

18. Two types of concurrency
1. System concurrency
◦ State of overall system as the aggregation of state diagrams, one
for each object. Each state diagram is executing concurrently with
the others.
2. Object concurrency
◦ An object can be partitioned into subsets of states (attributes and
links) such that each of them has its own subdiagram.
◦ The state of the object consists of a set of states: one state from
each subdiagram.
◦ State diagrams are divided into subdiagrams by dotted lines.

20.  The class model describes the class & objects in a
system and their relationship.
 The state model describes the life cycles of the objects.
 The interaction model describes how the objects
interact.
 The interaction model starts with use cases that are
then elaborated with sequence and activity diagrams

21.  Use case: focuses on functionality of a system- i.e,
what a system does for users
 Sequence diagrams: shows the object that interact and
the time sequence of their interactions
 Activity diagrams: elaborates important processing
steps

27. Functional vs. Non-Functional
Requirements
Functional
Non-Functional
Functional requirement are user ‘visible’ features and are
typically initiated by stakeholders of the system – generate
report, login, etc.
Non-functional requirements are ‘non-visible’ features and
but required for a effective running of an application – security,
backup, etc.

29.  Use Case diagrams show the various activities the users
can perform on the system.
◦ System is something that performs a function.
 They model the dynamic aspects of the system.
 Provides a user’s perspective of the system.
29

30. A use case is a model of the interaction between External users of a
software product (actors) and The software product itself
 More precisely, an actor is a user playing a specific role describing a
set of user scenarios capturing user requirements contract between
end user and software developers

31.  Use case diagrams are used to visualize, specify, construct,
and document the (intended) behavior of the system, during
requirements capture and analysis.
 Provide a way for developers, domain experts and end-users to
Communicate.
 Serve as basis for testing.
 Use case diagrams contain use cases, actors, and their
relationships.
31

32.  Actors: A role that a user plays with respect to the system, including
human users and other systems. e.g., inanimate physical objects (e.g.
robot); an external system that needs some information from the
current system.
 Use case: A set of scenarios that describing an interaction between a
user and a system, including alternatives.
 System boundary: rectangle diagram representing the boundary
between the actors and the system.
 Association: Communication between an actor and a use case;
Represented by a solid line.

33. Actors
Could be human beings, other systems,
timers and clocks or hardware devices.
Actors that stimulate the system and are the
initiators of events are called primary actors
(active)
Actors that only receive stimuli from the
system are called secondary actors (passive)

34. Actors
Who/what will be interested in the system?
Who/what will want to change the data in the
system?
Who/what will want to interface with the
system?
Who/what will want information from the
system?

35. 1. Avoid showing communication between actors.
2. Actors should be named as singular. i.e student and NOT students. NO names
should be used – i.e John, Sam, etc.

37. 1. Start by identifying the actors of the system
2. Define the goals of the system and how they can be
achieved using the systems’ actors
3. Illustrate these goals and actors actions using use-case
diagram(s)
37

38.  A use case describes a sequence of actions a system performs to
yield an observable result or value to a particular actor
 Naming convention = verb + noun (or) verb + noun-phrase,
◦ e.g. withdraw cash
 A good use case should:
◦ Describe a sequence of transactions performed by a system that
produces a measurable result (goal) for a particular actor
◦ Describe the behavior expected of a system from a user's
perspective
◦ Enable the system analyst to understand and model a system from
a high-level business viewpoint
◦ Represent the interfaces that a system makes visible to the
external entities and the interrelationships between the actors and
the system
38

39.  Use case is a particular activity a user can do on the
system.
 Is represented by an ellipse.
 Following are two use cases for a library system.
39
Borrow Reserve

41. • What are the tasks of each actor?
• Will any actor create, store, change, remove, or read
the information?
• Will any actor need to inform the system about the
sudden, external changes?
• Does any actor need to informed about certain
occurrences in the system?
• What use cases will support and maintain the system?
• Can all functional requirements be performed by the
use cases?

42. Construct Description Notation
Use-case A sequence of transactions
performed by a system that produces
a measurable result for a particular
actor
Actor A coherent set of roles that users
play
when interacting with these use
cases
System
Boundary
The boundary between the physical
system and the actors who interact
with the physical system
42

45. • Functionality provided by the system
• Consist of a series of steps which collectively add
value to the user of the system
• Examples
– Issue a book to a member
– Receive a book back from a member
– Query the current location of a book
– Maintain member’s information
– Maintain book’s information

47. 47
Actor
System name
Use-case
Association System boundary

48. client employee
48 A Library System.
supervisor
library system
borro
w
reserve
Order title
Fine
payment

49. 49
Teacher
Student
Printing administrator
Grade system
Record
grades
View grades
Distribute
Report cards
Create report
cards

52. Include: a dotted line labeled <<include>> beginning at base use case
and ending with an arrows pointing to the include use case. The include
relationship occurs when a chunk of behavior is similar across more
than one use case. Use “include” in stead of copying the description of
that behavior.
<<include>>
Extend: a dotted line labeled <<extend>> with an arrow toward the base
case. The extending use case may add behavior to the base use case. The base
class declares “extension points”.
<<extend>>

53. base <<include>> included
 The base use case explicitly incorporates the behavior
of another use case at a location specified in the base.
 The included use case never stands alone. It only
occurs as a part of some larger base that includes it.
53 ניתוח מערכות מידע

54.  Enables to avoid describing the same flow of events
several times by putting the common behavior in a use
case of its own.
54 ניתוח מערכות מידע
updating
grades
output
generating
verifying
student id
<<include>>
<<include>>

56.  Include relationships are used when two or more use cases
share some common portion in a flow of events
 This common portion is then grouped and extracted to form an
inclusion use case for sharing among two or more use cases
 Most use cases in the ATM system example, such as
Withdraw Money, Deposit Money or Check Balance, share
the inclusion use-case Login Account
56

57. 57
Login Account
(Included use case)
Withdraw Money
(Base use case)

58. 58

59. base <<extend>> extending
 The base use case implicitly incorporates the behavior
of another use case at certain points called extension
points.
 The base use case may stand alone, but under certain
conditions its behavior may be extended by the
behavior of another use case.
59 ניתוח מערכות מידע

60.  In UML modeling, you can use an extend relationship
to specify that one use case (extension) extends the
behavior of another use case (base)
 This type of relationship reveals details about a system
or application that are typically hidden in a use case
60

61. 61
Process Excess Amount
(Extending use case)
Withdraw Money
(Base use case)
If conditional guard is true, extending flow is executed

62. 62

63. Slide 2 (of 48)

64. Figure 16.12

65.  Generalization.
student
non-graduate
student
65 ניתוח מערכות מידע
graduate
student

66. Construct Description Notation
Association The participation of an actor in a
use case, i.e. an instance of an
actor and instances of a use case
communicating with each other
Generalization A taxonomic relationship between
a general use case and a more
specific use case. The arrow head
points to the general use case
Extend A relationship between an
extension use case and a base
use case, specifying how the
behavior of the extension use case
can be
inserted into the behavior defined
66

67. Construct Description Notation
Include A relationship between a base use
case and an inclusion use case,
specifying how the behavior for the
inclusion use case is inserted into the
behavior defined for the base use
case. The arrow head points to the
inclusion use case
67

68.  Both Make
Appointment and
Request Medication
include Check Patient
Record as a subtask
(include)
 The extension point is
written inside the base
case Pay bill; the
extending class Defer
payment adds the
behavior of this
extension point.
(extend)
 Pay Bill is a parent use
case and Bill
Insurance is the child
use case.
(generalization)
(TogetherSoft, Inc)

73. Each use case may include all or part : of the following
 Title or Reference Name - meaningful name of the UC
 Author/Date - the author and creation date
 Modification/Date - last modification and its date
 Purpose - specifies the goal to be achieved
 Overview - short description of the processes
 Cross References - requirements references
 Actors - agents participating
 Pre Conditions - must be true to allow execution
 Post Conditions - will be set when completes
normally
 Normal flow of events - regular flow of activities
 Alternative flow of events - other flow of activities
 Exceptional flow of events - unusual situations
 Implementation issues - foreseen implementation
problems
ניתוח מערכות מידע
73

75. The sequence model elaborates the themes of use cases.
Two kinds of sequences models
 Scenarios
 Sequence diagram

76.  A scenario is a sequence of events that occurs during
one particular execution of a system.
For example:
John logs in, transmits a message from John to the
broker system.

79.  A sequence diagram shows the participants in an interaction and the
sequence of messages among them.
 A sequence diagram shows the interaction of a system with its
actors to perform all or part of a use case.
 Each use case requires one or more sequence diagrams to describe
its behaviour.

80.  Sequence diagrams, also known as event diagrams or event
scenarios, illustrate how processes interact with each other by
showing calls between different objects in a sequence.
These diagrams have two dimensions:
 The vertical lines show the sequence of messages and calls in
chronological order
 Horizontal elements show object instances where the messages
are relayed.

81.  Components Of A Sequence Diagram
Sequence Diagram
Active objects Messages
Control Activation Box Lifeline
Information

82. Active Objects:
◦ Any objects that play a role in the system
◦ Can be any object or class that is valid within the system
◦ Can be an Actor that is external to the system and derives benefits
from the system
Messages:
◦ Used to illustrate communication between different active
objects.
◦ Used when an object needs
 to activate a process of a different object
 to give information to another object

83. Lifeline
◦ Denotes the life of actors/objects over time during a sequence
Focus of control (activation box)
◦ Means the object is active and using resources during that time
period
Control information
◦ Shows the control flow in the system
◦ Creation and destruction of an object through <<create>> and
<<destroy>>

84.  Squares with object type, optionally preceded by object name and
colon
◦ write object's name if it clarifies the diagram
◦ object's "life line" represented by dashed vert. line
84

85. Objects are displayed at the top of the
diagram
The vertical dimension represents time
Each object has a dashed line – lifeline
– extending below it – to indicate the
period of time during which objects
playing that role actually exist
Object Name

86.  Creation: arrow with 'new'
written above it
 Deletion: an X at bottom of
object's lifeline
86

87.  The messages in an
interaction are drawn from
top to bottom, in the order
that they are sent.
 Messages are shown
as arrows pointing from the
lifeline of the role sending the
message to the lifeline of the
receiver.
 When a message is
sent, control passes from the
sender of the message to the
receiver.
Object Name Object Name
message

88. Return of control is shown using dashed arrow returning to
the calling object.
Object Name Object Name
message

89.  Message (method call) indicated by horizontal arrow
to other object
◦ write message name and arguments above arrow
89

90.  Activations - show when a method is active – either executing or
waiting for a subroutine to return
◦ Either that object is running its code, or it is on the stack waiting
for another object's method to finish
90

91. • Period of time during
which an object is
processing a message,
Shown on a lifeline as a
narrow rectangle whose
top is connected to a
message.
• When an object finishes
processing a message,
control returns to the
sender of the message
Object Name Object Name
message

92. a : Assembly part : CatalogEntry
getNumber()
: Client
count(part)
return number
Lifeline
Messages
Activation(
optional)
control returns to the
sender of the message
(optional)

94. Caller Phone Recipient
Picks up
Dial tone
Dial
Ring notification Ring
Picks up
Hello

97.  Activity diagrams and use cases are logical model which describe
the business domain’s activities without suggesting how they are
conduct.
 A diagram that emphasizes the flow of control from activity to
activity in an object.
 Similar to the traditional program flowchart.
 Used to provide detail for complex algorithms.
 Primary activities and the relationships among the activities in a
process.

98. Purpose
◦ to model a task (for example in business modelling)
◦ to describe a function of a system represented by a use case
◦ to describe the logic of an operation
◦ to model the activities that make up the life cycle in the Unified
Process

99.  Initial Node
 Control Flow
 Action or Activity
 Object Flow
 Branch
 Merge
 Fork
 Join
 Final Node
09/29/14 99

100.  This represents the start of
the flow of an activity
diagram.
 An activity diagram contains
a single start node.
 The name of the initial node
is entered on the node. It
takes the form of an
adjective.
09/29/14 100

101.  A control flow connects any combination of:
◦ activities
◦ branches
◦ merges
◦ forks
◦ joins
 A control flow has direction, which is indicated by the arrow head
– you may only traverse the control flow in the direction of the
arrow.
 A control flow may not enter an initial state.
 A control flow may not exit a final node.
 A control flow is the representation of an occurrence of an event.
 The name of the event is entered on the control flow. It takes the
form of something has been done, noun-verb(past-tense)
09/29/14 101

102.  The activity represents the
actions that occur as a result of
an incoming event from a control
flow.
 The name of the activity is
entered on the activity and takes
the form of something being
done, present tense verb-noun
09/29/14 102

103.  The branch is used to show alternative paths in the
activity diagram.
 Label the decision node with a question(?).
 Do not label the merge, (unless you have a good
reason to).
 One control flow enters the decision node and two
or more alternative control flows exit the decision
node.
 Only one of the paths may be transitioned as the
result of an event occurring.
 Each exiting control flow contains the condition
under which it is taken (called a guard), dependent
upon the answer to the question. These guards must
be mutually exclusive.
09/29/14 103

104.  The guards on exiting control flows must cover all possible
outcomes of the question being asked by the branch.
◦ The simplest way to ensure all possible outcomes are covered is
to phrase the branch question such that the only possible answers
are ‘Yes’ or ‘No’. Note, this can add extra branches to the
diagram.
 Two or more control flows enter the merge node and one control
flow exits.

105. 09/29/14 105
 The fork may be represented by vertical or
horizontal bars.
 The fork represents that the flow through the
diagram has split into 2 paths that are running
in parallel (multitasking).
 The fork has a single control flow on entry and
several control flows exiting.
 Use a fork when there is no requirement on the
order of activities in a flow.
◦ For example, the Dematerializer receives an
event that the door is shut. It now suspends
the cargo and creates a vacuum, but these
actions may be performed in parallel, so we
model them with a fork.

106. 09/29/14 106
 For every fork there should be a join (if not
your activity diagram is broken).
 The join may be represented by vertical or
horizontal bars.
 A join simply shows that when the parallel
activities have finished that they then come
back to join a single flow again.
 The join has several control flows entering and
a single control flow on exit.
 The exiting control flow cannot be executed
until every incoming control flow has
completed.
 There is no need to label the fork or join.

107.  The final node represents the termination of the activity
diagram.
 There may be several termination states in a single
diagram.
 Label the final node with an adjective.
09/29/14 107

109. [Condition]
For each X:
START POINT
END POINT
STEP
TRANSITION
DECISION POINT
GUARD
PARALLEL STEPS
REPEATED STEPS

113. START
POINT

114. The Start Point
represents the
EVENT that
triggers the use
case.

115. Actor elects to Add Customer
END
POINT

116. Actor elects to Add Customer
Label the End Point to
EXPLICITLY confirm
that the intent of the use
case has been achieved.

117. Actor elects to Add Customer
Customer added

118. Actor elects to Add Customer
This makes it clear to the
reader that the use case
is complete and that
nothing further is needed
in order to fulfil the
intent.
Customer added

119. Actor elects to Add Customer
End of process

120. To reach the End
Point…

121. … you need to
model STEPS.

122. Link the steps
with
TRANSITIONS.

124. Transitions use arrow
heads to show the
direction of process
flow.

125. I like to put a note
against any step that
achieves the goal of
the use case.
Goal X achieved

126. Goal X achieved
… because it might not
be the last step.

127. Often in a use case
the System has to
make a decision
based on business
rules...

128. The actual decision
takes place within a
STEP

129. System
determines
whether X or Y
The actual decision
takes place within a
STEP

130. System
determines
whether X or Y
A DECISION POINT
is then used to help
the reader navigate
the diagram.

131. DECISION
POINT

132. Decision Points
contain text which
describes the nature
of the decision to be
made.

133. So was it X or Y?

134. Decision points allow
the flow to branch
away from the
Primary Path.

135. [Condition 2]
[Condition 1]
Transitions
coming out of
Decision Points
must have a
GUARD.

136. [IT WAS “Y”]
[IT WAS “X”]
A Guard needs to
explicitly describe a
condition which must
be true in order to
proceed down that
path.

137. [Condition 2]
[Condition 1]
If the flow
rejoins the
Primary Path, it
is known as an
Alternate Path.

138. [Condition 1] [Condition 2]
You can show how
paths rejoin by
using a MERGE
POINT.

139. [Condition 1] [Condition 2]
You can show how
paths rejoin by
using a MERGE
POINT.

140. [Condition 1] [Condition 2]
I prefer to model
merging paths like this.