Requirements Modeling: Behavioral Modeling

Ahsan Riaz
Department of Computer Science
CUI, Abbottabad Campus

Slide Set to accompany

Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A
Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the
author.

These slides are designed

All copyright MUST appearSoftware
to accompany
information Engineering:
if these slides are posted on aAwebsite for student use.
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
Roger Pressman.

1
Quick Recap
It encompasses seven distinct
tasks:
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Management

Building an Analysis model

Scenario-based elements
Class-based elements
Behavioral elements
Flow-oriented elements 2
Today’s Agenda
It encompasses seven distinct
tasks:
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Management

Building an Analysis model

Scenario-based elements
Class-based elements
Behavioral elements
Flow-oriented elements 3
Behavioral Modeling
 The behavioral model indicates how software will respond to
external events or stimuli
 To create the Behavioral model, the analyst must perform the
following steps:
• Evaluate all use-cases to fully understand the sequence of
interaction within the system
• Identify events that drive the interaction sequence and
understand how these events relate to specific objects
• Create a sequence for each use-case
• Build a state diagram for the system
• Review the behavioral model to verify accuracy and consistency

4
Creating a Behavioral Model

1) Identify events found within the use cases

2) Build a state diagram for each class, and if
useful, for the whole software system
Identifying Events in Use Cases
• An event occurs whenever an actor and the system exchange information
• An event is NOT the information that is exchanged, but rather the fact that
information has been exchanged
• Some events have an explicit impact on the flow of control, while others
do not
– An example is the reading of a data item from the user versus comparing the
data item to some possible value
 Identifying Events in Use Cases with
Example
• A use-case is examined for points of
information exchange.
• The homeowner uses the keypad to key in a
four-digit password. The password is
compared with the valid password stored in
the system. If the password in incorrect, the
control panel will beep once and reset itself
for additional input. If the password is correct,
the control panel awaits further action.
Building a State Diagram
• A state is represented by a rounded rectangle
• A transition (i.e., event) is represented by a labeled arrow
leading from one state to another

• The active state of an object indicates the current overall

status of the object as is goes through transformation or
processing
–A state name represents one of the possible active states of an
object
• The passive state of an object is the current value of all of
an object's attributes
Building State Diagram – an example

State diagram for the ControlPanel class

Sequence Diagram

10
Sequence Diagram

11
Sequence Diagram
 Figure illustrates a partial sequence diagram for the SafeHome
security function
 Each of the arrows represents an event
 Time is measured vertically (downward), and the narrow vertical
rectangles represent time spent in processing an activity
 States may be shown along a vertical time line

12
Summary
It encompasses seven distinct
tasks:
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Management

Building an Analysis model

Scenario-based elements
Class-based elements
Behavioral elements
Flow-oriented elements 13