Module 2

Software Engineering
Content of the Module 2

Chapter 1:

Understanding Requirements

Chapter 2:

Requirements modeling scenario, information and Analysis

classes.

Chapter 3:

Requirement Modeling Strategies

 Chapter 2:
Requirement modelling
strategies
Content 1. Flow oriented modelling
2. Behavioral modelling
1.Requirements modeling strategies
1. Requirement modeling
● Two views
● Structured analysis - considers data and the processes that
transform the data as separate entities. Data objects are modeled
in a way that defines their attributes and relationships. Processes
that manipulate data objects are modeled in a manner that shows
how they transform data as data objects flow through the system.
● Object-oriented analysis - focuses on the definition of classes
and the manner in which they collaborate with one another to affect
customer requirements.
2. Flow - Oriented modeling
● data flow diagram (DFD) and related diagrams and information are not a
formal part of UML, they can be used to complement UML diagrams and
provide additional insight into system requirements and flow.
● The DFD takes an input-process-output view of a system.
○ data objects flow into the software,
○ transformed by processing elements,
○ resultant data objects flow out of the software.
● DFD representation:
○ Data objects are represented by labeled arrows
○ Transformations are represented by circles (also called bubbles).
● The DFD is presented in a hierarchical fashion.
○ The first data flow model (sometimes called a level 0 DFD or context diagram) represents the system
as a whole.
○ Subsequent data flow diagrams refine the context diagram, providing increasing detail with each
subsequent level.
 Flow-oriented modeling

Creating a data flow model

● The data flow diagram enables you to develop models of the
information domain and functional domain.
● A few simple guidelines can derivation of a data flow diagram:
a. The level 0 data flow diagram should depict the software/system as a single
bubble
b. Primary input and output should be carefully noted
c. Refinement should begin by isolating candidate processes, data objects, and
data stores to be represented at the next level
d. All arrows and bubbles should be labeled with meaningful names
e. Information flow continuity must be maintained from level to level
f. one bubble at a time should be refined.
 Flow-oriented modeling

Creating a data flow model

● To illustrate the use of the DFD and related notation, again consider
the safehome security functions , in level 0 Data
DFD
objects

External
entities
Creating a data flow model Flow-oriented modeling

● The level 0 DFD must now be expanded into a level 1 data flow
model.
Creating a data flow model Flow-oriented modeling

● The level 1 DFD must now be expanded into a level 2 data flow
model.

● Refinement of DFDs continues until each bubble performs a simple

function i.e easily implemented as a program component.
Creating a control flow model Flow-oriented modeling

● Some applications are driven by events rather than data, produce

control information rather than reports, and process information with
heavy concern for time and performance. Such applications require
the use of control flow modeling in addition to data flow modeling.
● Event is implemented as a boolean value or discrete list.
● Guidelines to select potential candidate events:
a. List all sensors that are “read” by the software.
b. List all interrupt conditions.
c. List all “switches” that are actuated by an operator.
d. List all data conditions.
e. Recalling the noun/verb parse that was applied to the processing narrative, review all
“control items” as possible control specification inputs/outputs.
f. Describe the behavior of a system by identifying its states, identify how each state is
reached, and define the transitions between states.
g. Focus on possible omissions—a very common error in specifying control; for example,
ask: “Is there any other way I can get to this state or exit from it?”
 Flow-oriented modeling
The control specification
● Control Specification (CSPEC) represents the behavior of the
system in two different ways:
○ State diagram that is a sequential specification of behavior.
○ Program activation table a combinatorial specification of behavior.
Flow-oriented modeling
Flow-oriented modeling
Flow-oriented modeling
 Flow-oriented modeling
The Process specification
● Process Specification (PSPEC) is use to describe all flow model
processes that appear at the final level of refinement.
3. Creating a Behavioral model
3. Creating a behavioral model
To create the model, should 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.
 Crating a behavioral model

Identifying events with the use case

● the use case represents a sequence of activities that involves
actors and the system.
● An event occurs whenever the system and the actor exchange
information.
● Consider the Safehome software. When homeowner enter the
password, password compare takes place . event generated by
homeowner and recognized by the controlpanel.
 Crating a behavioral model

State representations
● In the context of behavioral modeling, two different characterizations of states
must be considered:
○ the state of each class as the system performs its function and
○ the state of the system as observed from the outside as the system performs its function.
● The state of a class takes on both passive and active characteristics.
● A passive state is simply the current status of all of an object’s attributes. For
example, the passive state of the class Player would include the current position
and orientation attributes
● The active state of an object indicates the current status of the object as it
undergoes a continuing transformation or processing. The class Player might
have the following active states: moving, at rest, injured, being cured; trapped, lost,
and so forth.
● An event (sometimes called a trigger) must occur to force an object to make a
transition from one active state to another.
 Crating a behavioral model

An action occurs
concurrently with the
state transition or as a
consequence of it
and generally involves
one or more operations
(responsibilities) of the
object

A guard is a Boolean condition that

must be satisfied in order for the
transition to occur.
Crating a behavioral model