ITS470

OBJECT-ORIENTED REQUIREMENTS
ANALYSIS
Topic 8
Behavioral Modeling

1
 Learning Outcome
• Write fully developed use case descriptions
• Develop activity diagrams to model flow of activities
• Develop system sequence diagrams
• Develop state machine diagrams to model object
behavior
• Explain how use case descriptions and UML diagrams
work together to define functional requirements

2
USE CASE DESCRIPTION

3
 Use Case Description
• A use case is an activity that the system performs, usually
in response to a request by a user
• It shows how a user uses the system
• A use case might have different flow of activities,
depending on the actor invoking the use case
▪ These flow of activities are called scenarios or use case
instances
• A use case description is a textual model that list and
describes the processing details for a use case
▪ Brief description
▪ Fully developed description

4
 Use Case Descriptions
• Provide information about each use case, including actors,
stakeholders, preconditions, post conditions, the flow of activities
and exceptions conditions
• Activity diagrams (first shown in Chapter 4 - slides) can also be used
to show the flow of activities for a use case
• Brief description of use cases are shown below:

5
 Use Case Descriptions
• Full developed use case description for more complex
use cases.
• Typical use case description templates include:
▪ Use case name
▪ Scenario (if needed)
▪ Triggering event
▪ Brief description
▪ Actors
▪ Related use cases (<<includes>>)
▪ Stakeholders
▪ Preconditions
▪ Post conditions
▪ Flow of activities
▪ Exception conditions

6
 Brief Use Case Description

• Used for very simple use cases

• Single scenario, very few exception condition
• Eg. Add product comment, send message

7
Fully Developed
Use Case
Description

Use case:
Create customer account

8
Fully Developed Use Case Description

9
Fully Developed Use Case Description
Precondition
• Preconditions
▪ What must be true before the use case begins
▪ What objects must exist, information must be available,
condition of actor

10
Fully Developed Use Case Description
Postcondition
• Post conditions
▪ What must be true after the use case is completed
▪ What objects are created, updated; how objects are
associated
▪ Purpose:
• Use for planning test case expected results
• Indicated what objects are important during design

11
Fully Developed Use Case Description
Flow of Activities

Sequence of steps and the response

12
Fully Developed Use Case Description
Exception/Alternative Conditions

13
ACTIVITY DIAGRAM

14
Activity Diagram

15
 Use Case UML Activity Diagram
Create Customer
Account

Note: this shows

flow of activities
only

Another way to
document a
use case
16
 Use Case UML Activity Diagram

Fill shopping cart

Note: this shows

use case with
<<includes>>
relationship

17
SYSTEM SEQUENCE DIAGRAM

18
 SSD
• An SSD is usually used together with use case
description/activity diagram
• Use case description/activity diagram identify the flow of
activities within a use case
• However, they do not explicitly identify inputs or outputs
▪ This is provided by SSD
• Use case diagram shows how actor uses the system
• System sequence diagram shows how actor interacts
with system
▪ Enters input data
▪ Receive output data

19
 System Sequence Diagram (SSD)
Shows the sequence of Shows interactions
messages between an between objects
external actor and the
system

20
SSD Notation
• Actor
• :System
• Lifeline
• Message
• Note

21
SSD Notation
Loop Frame

22
 SSD Notation
Loop Alternate

23
 Message Notation
*

itemID,quan
* [another item] description, price, extendedPrice := addItem(itemID, quantity
tity)

24
SSD Notation
Opt Frame

25
SSD Notation
Alt Frame

26
CREATING AN SSD

27
Recall Use
Case
Description
Create
Customer
Account

28
Recall Activity
Diagram
Create
Customer
Account

29
 Steps for Developing SSD
1. Identify input message
2. Describe the message from the external actor to the
system using the message notation
3. Identify any special conditions on input messages
4. Identify and add output return values
▪ On message itself: aValue:= getValue(valueID)
▪ As explicit return on separate dashed line

30
1 Identify Input Message

31
2 Describe the message
•Verb-noun: what the
system is asked to do
▪ createNewCustomer()
▪ enterAddress()
▪ enterCreditCard()

•Consider parameters the

system will need
▪ Name, phone, emails
▪ Address
▪ Credit card information

32
 3 Identify Special Condition
• Iteration/loop frame
• Opt or Alt frame

• Example- multiple addresses

33
 Identify and Add
4
Output Return Values
• On message itself: aValue:= getValue(valueID)

• As explicit return on separate dashed line

34
35
STATE MACHINE DIAGRAM

36
 State Machine Diagram
• State machine diagram
▪ A UML diagram showing the life (changing) of an object in
states and transitions
• State
▪ A condition during an object’s life when it satisfies some
criterion, performs some action, or waits for an event
• Transition (process of change)
▪ The movement of an object from one state to another state
• Action Expression
▪ A description of activities performed as part of a transition

37
 State Machine Diagram (continued)

• Pseudo state
▪ The starting point of a state machine diagram (nested black
dot)
• Origin state
▪ The original state of an object before transition
• Destination state
▪ The state to which the object moves (change) after the
transition
• Guard condition
▪ A true/false test to see whether a transition can launch

38
 State Machine Diagram
for a Printer

transition-name (parameters, …) [guard-condition] / action-expression

39
 Composite States
• State containing other states and transitions
• Printer can be On and either Idle or Working

Action-expressi
on

40
 Concurrent Path
• Multiple paths in composite state
• Printer ‘On’ paths are independent

41
 Steps for Developing State Machine
Diagram
1. Review the class diagram and select classes that might
require state machine diagrams
2. For each class, make a list of status conditions (states)
you can identify
3. Begin building diagram fragments by identifying
transitions that cause an object to leave the identified
state (change)
4. Sequence these states in the correct order and
aggregate combinations into larger fragments
5. Review paths and look for independent, concurrent
paths

42
 Steps for Developing State Machine
Diagram (continued)
6. Look for additional transitions and test both directions
7. Expand each transition with appropriate message
event, guard condition, and action expression
8. Review and test the state machine diagram for the
class
▪ Make sure state are really state for the object in the class
▪ Follow the life cycle of an object coming into existence and
being deleted
▪ Be sure the diagram covers all exception condition
▪ Look again for concurrent paths and composite states

43
 1

Review the
class diagram

RMO CSMS class

diagram
(Figure 4-23 page
103)

44
 1 …. and Select Classes
• Select classes that have status condition that
needs to be tracked
• Eg:
▪ Sale, SaleItem class
• Customers need to know status of sale and status of
individual items
▪ InventoryItem class
• Track in-stock and out-of-stock items
▪ Shipment class
• Track arrivals
▪ Customer class
• Track active and inactive customers

45
 2 Identify Status Condition
• SaleItem
▪ Ready to be shipped
▪ On back order
▪ Shipped

46
3 Identify Exit Transition

47
 Sequence the State-Transition
4
Combinations in Correct Order

48
 5 Look for Concurrent Paths
• None for SaleItem object

49
 6 Look for Additional Transitions
• Examine every pair of state to look for possible
combinations, especially backward transition
▪ Ready to ship on back order? √
▪ Shipped ready to ship? x
▪ On back order newly added? x
▪ Newly added on back order? √

50
 7 Extend Each Transition

• Complete all transitions with correct names,

guard-conditions and action expression

51
 7 Review and Test
• Make sure state are really state for the object in the class
• Follow the life cycle of an object coming into existence
and being deleted
• Be sure the diagram covers all exception condition
• Look again for concurrent paths and composite states

May use walkthrough

52
First-cut State Machine
for Sale (Order)

53
Second-cut State Machine
for Sale (Order)

54
INTEGRATING REQUIREMENTS
MODEL

55
Integrating Requirements Models

56