System Analysis and Design

AC3010

1
Part 2: System analysis

Chapter 7: Behavioral modeling

Part 2: System analysis

Analysis

Requirements
determination

System request Functional modeling

System proposal

Structural modeling

Behavioral modeling

3
Chapter syllabus

• 7.1. Behavior Models

• 7.2. Interaction Diagrams
• Sequence Diagram
• Collaboration/Communication Diagram
• 7.3. State Machine Diagrams
• Behavioral state machine diagram
7.1. Behavior Models

• Behavioral modeling describes how the identified objects in structural

modeling interact and communicate to fulfill the uses cases.
• In the development stage, the objects’ behaviors are implemented as methods.

Functional Models Structural Models Behavioral Models

• External behavioral • Internal structural • Internal behavior

(functional) view (static) view (dynamic) view

o Use case diagram o CRC card o Sequence diagrams

o Use case description o Class diagram o Communication diagrams
o Activity diagram o Object diagram o State machine diagram
o etc.

5
7.1. Behavior Models

• Behavioral models describe the internal dynamic aspects of the system

• Analysis phase:
• describe what the internal logic of the process is without specifying how the process is
implemented
• Design & Implementation phase:
• fully specify the detailed design of the operations contained in the objects
• Typical behavioral models classification :
• Interaction diagrams
• To represent the distribution of the behavior of the system over the actors and
objects in the system.
• How actors and objects collaborate to provide the functionality defined in a use-case
• Sequence diagrams and Communication/Collaboration diagrams
• Behavioral state model
• To represent the changes that occur in the underlying data
• Behavioral State Machine diagram

6
7.2. Interaction Diagrams

• Focus on object level

• Sequence diagrams and Communication/Collaboration diagrams
• Notions (rappel’)
• Objects: an instantiation of a class
• Attributes: describe information about the object
• Operation: the behaviors of an instance of a class
• method/function call in Java/C++
• message transfer in Ruby
• Messages, methods, functions, operations, verbs, and controllers are all basically
different terms of the same thing: the behavior that allocated to a class

7
Sequence Diagrams

8
Sequence Diagrams

• Sequence diagrams illustrate the objects that participate in a use case and the
messages that pass between them over time for one use case.

• Primary goals:
• Allocate behavior to objects/classes
• Show in detail how objects/classes interact with each other over the lifetime of the use case
• Finalize the distribution of operations among classes
• Sequence diagram shows the design at a much more concrete and detailed view
• It may show additional infrastructure objects, details of persistence storage mechanisms
etc. depending on the architecture of the proposed system.

9
Sequence Diagram notation

• The objects across the top of the

diagram are interacting with
each other by passing messages
back and forth
• The vertical dotted lines (or
object life-lines) represent time
• Focus of control
• indicate which object “has the
focus,” or is currently in control
• can be switched off to reduce the
distraction

• Messages: arrows with title, can be

numbered

10
Type of messages

• Synchronous message
• An operation call.
• The sender object transfers message to the receiver object, then pauses to
wait for the receiver object to return control.
• The receiver object performs the requested operation, if necessary, can
transfer control to another object and when the operation is completed
returns control to the sender object, possibly with a response result.
• The return message can be explicitly represented by the dashed arrow or can
be omitted, since it is the default at the end of the operation.
• Asynchronous message
• Just sending of a signal/operation call.
• The message enters the receiver's queue.
• The sender continue his work without waiting for the results
• The receiver performs an action and may also return a message to the sender.
But if there is a return, it must be expressed explicitly.

11
Type of messages

• Lost message:
• Known the sender, but don’t known the receiver
• Receiver is out of description scope, or this is a distribution.
• Found message:
• Know the receiver, but don’t known the sender
• Sender is out of description scope

12
Sequence Diagram Building

• There’s a direct link between each use case, its robustness diagram, and the
sequence diagrams
• The process of drawing the robustness diagram can rewrite the use case => use case
text should be complete, correct, detailed, and explicit.
• Draw a sequence diagram for every use case, with both basic and alternate
courses on the same diagram
• Map use case text to the messages on the sequence diagram
• Assign operations to classes while drawing messages and review class
diagrams frequently

13
Sequence Diagram Building

• Objects: Actor, boundary object, entity object from robustness diagram

• Controller objects from robustness diagram
• map to “logical” software functions
• can be turned into 1 or more messages between objects (or occasionally a real
controller class)
• <=> allocating operations to classes

14
Sequence Diagram Steps

Doug Rosenberg and Matt Stephens, 2007, Use Case

Driven Object Modeling with UML, Theory and
Practice, Apress
15
Sequence Diagram Steps

• Primary goals: Allocate behavior to objects/classes

Decision-making !

16
 CASE STUDY: Write Customer Review sequence diagram

• Step 1: Copy Use case text

• Step 2: Copy entity objects
• Step 3: Copy boundary
objects and actors

17
CASE STUDY

• Step 4: Walk through

the controllers

18
CASE STUDY

• Step 4: Walk through

the controllers

“ a pure OO version”
19
CASE STUDY

• Can be extended
• Tie the design closely with the
implementation details of the
target framework before begin
coding

Spring Framework
“ a framework
dependent version”

20
Sequence Diagram Building

• Keep updating and refining the static model (the class diagrams)
• These detailed class diagrams should use the same elements as on the sequence
diagrams
• When assigning a message on the sequence diagram (the dynamic model), an
operation is automatically added to the appropriate class in the static model.
• Update the use case text if needed

21
CASE STUDY

• Update the static model

Static model based on the

pure OO sequence diagram

22
• Prefactored static model

23
Quiz

Figure out the errors and then draw the corrected diagram
• Question 1

not matching

wrong
caller

24
Quiz

• Question 1

25
Quiz

Figure out the errors and then draw the corrected diagram
• Question 2: from Create New Book use case

No data validation

26
Quiz

• Question 2

27
Quiz

• Question 3
Edit Shopping Cart use
case
+ Begin/end problem
+ Where is customerID?
-> missing Customer
Account corresponding to
this Shopping Cart,
Customer Session
corresponding to this
Customer Account
+ Wrong caller
+ Not need

redundant

28
Quiz

• Question 3

29
Other Sequence Diagrams Reference

• Object

https://www.uml-diagrams.org 30
 Other Sequence Diagrams Reference

• Overlapping
execution

• Create Message • Delete Message

• Runtime constraint

https://www.uml-diagrams.org 31
Other Sequence Diagrams Reference

• Callback

32
Other Sequence Diagrams Reference

• Combined fragment

33
Other Sequence Diagrams Reference

• Loop to execute exactly 10 times.

• Loop to execute from 5 times to 10 times.

Stop when the guard is false.

• Loop with break.

https://www.uml-diagrams.org 34
Other Sequence Diagrams Reference

• in any order, possibly parallel

• in the strict sequential order • in weak sequencing

https://www.uml-diagrams.org 35
Collaboration/Communication Diagrams

36
Collaboration/Communication Diagrams

• Communication diagram (called collaboration diagram in UML 1.x)

• a kind of UML interaction diagram
• shows interactions between objects using sequenced messages in a free-
form arrangement.
• Communication and Sequence Diagrams
= View of the dynamic aspects of an OO system
= Show HOW a set of objects collaborate to implement a use case or a scenario
= Capture semantics of the use-case flow of events;
= Identify objects, classes, interactions, and responsibilities

The CD shows HOW different objects depend on each other

37
Communication Diagrams

38
Communication Diagrams

• Example

39
Communication Diagrams

• Example

40
Collaboration Diagrams vs. Sequence Diagrams

• Collaboration Diagrams • Sequence Diagrams

• Emphasize the structural • Show the explicit sequence of
collaboration of a society of messages
objects (the relationships • To understand the sequencing
among objects) of messages in time order
• To understand all the effects on • not include object relationships
a given object • Better for visualizing overall
• Better for visualizing patterns flow
of collaboration amongst the • Have notation for control logic
objects
• Most people prefer
• Don’t have any notation for
• Better for real-time
control logic (iteration markers
specifications and for complex
and guards)
scenarios

Do not use communication diagrams to model process flow

(using activity diagram instead).
Other Communication Diagrams Reference https://www.uml-diagrams.org

• Object

• Concurrent Messages • Conditional Messages

• Sequential Loop

• Concurrent Loop

https://www.uml-diagrams.org 42
7.3 State Machine Diagrams

43
7.3 State Machine Diagrams

• Some of the objects are quite dynamic: can pass through a variety of states
over their life time
• The dynamic model that shows the different states through which a single
object passes during its life in response to events, along with its responses
and actions
• Typically not used for all objects
• Just for complex ones to further define them and to help simplify the design of
algorithms for their methods

44
7.3 State Machine Diagrams

• A behavior diagram which shows discrete behavior of a part of

designed system through finite state transitions.
• Two kinds of state machines
• Behavioral state machine
• Protocol state machine

• What does it show?

• Different states of the object
• What events cause the object to change from one state to another

• When ?
• To help understand the dynamic aspects of a single class
• How its instances evolve over time

45
Behavioral State Machine elements
Behavioral State Machine

• Behavior is modeled as a traversal of a graph of state nodes

connected with transitions.
• Transitions are triggered by events.
Behavioral State Machine

48
Guidelines for Creating Behavioral State Machines

1. Create a behavioral state machine for objects whose behavior changes based
on the state of the object.
2. To adhere to the left -to-right and top-to-bottom reading conventions, the
initial state should be drawn in the top left corner of the diagram and the final
state should be drawn in the bottom right of the diagram.
3. Names of the states are simple, intuitively obvious, and descriptive.
4. Question black hole and miracle states. Black hole states, states that an object
goes into and never comes out of, most likely are actually final states. Miracle
states, states that an object comes out of but never went into, most likely are
initial states.
5. Be sure that all guard conditions are mutually exclusive.
6. All transitions should be associated with a message and operation.
When to Use State Diagrams

•  describing the behavior of an object across several use cases

•  describing behavior that involves a number of objects collaborating
• => Combine state diagrams with other techniques
• => If you do use state diagrams, don’t try to draw them for every class in the
system. Use state diagrams only for those classes that exhibit interesting
behavior
Verifying and Validating The Behavioral Model

1. Every actor and object included on a sequence diagram must be included as an

actor and an object on a communication diagram, and vice versa.
2. If there is a message on the sequence diagram, there must be an association
on the communications diagram, and vice versa.
3. Every message that is included on a sequence diagram must appear as a
message on an association in the corresponding communication diagram, and
vice versa.
4. If a guard condition appears on a message in the sequence diagram, there
must be an equivalent guard condition on the corresponding communication
diagram, and vice versa.
5. The sequence number included as part of a message label in a
communications diagram implies the sequential order in which the message
will be sent.
6. Many representation-specific rules have been proposed

51
 Other State Machine Diagrams Reference

• Transition to terminate pseudostate: invoking a DestroyObjectAction.

• Entry point, Exit Point

• Choice
• Choice based on guards applied to the value inside diamond.
• Fork
• Fork splits transition into two transitions.
• Join
• Join merges transitions into single transition.

https://www.uml-diagrams.org 52
Other State Machine Diagrams Reference

Superstate with nested substates

Other State Machine Diagrams Reference
Exercise

• Draw the sequence diagram, communication diagram for your project

• Select and draw one State Machine Diagram for your project

55
56