Chapter 5: Analysis Modeling

Chapter 5
Analysis Modeling

The fundamental step is done where the requirements are completely specified and design representation is
comprehensively made for the software. The model is a combination of model in text and diagrammatic form
to depict requirements for data, function and behaviour in away that is relatively easy to understand and
more important straight-forward to review for correctness, completeness and consistency.
Analysis modelling is used to validate software requirements; you need to examine them from a number of
different points of views.
Analysis modelling represents requirements in three dimensions:
➢ Data
➢ Functional
➢ Behaviour
Elements of Analysis Modelling:
Three objectives of the analysis model:
1. To describe what the customer requires,
2. To establish a basis for the creation of a software design, and
3. To define a set of requirements that can be validated once the software is built.

➢ Data Dictionary: Data Dictionary is a centralized collection of definitions of all data flowing among
functions and, to & from data stores. By centralizing all definitions in the dictionary removes
dangers of duplication and inconsistencies.
➢ Data Modelling:
o Entity Relationship Diagram:
▪ Depicts relationship between data objects.
▪ Used to conduct data modelling activity.

Advanced Software Engineering Page 1 of 8

 Chapter 5: Analysis Modeling
▪
Attributes of each data object noted in ERD can be described using a data object
description.
➢ Functional Model or Information Flow:
o Data Flow Diagram
▪ Two purposes:
1. Provide an indication of how data are transformed as they moved through the
system.
2. To depict the functions that transforms the data flow.
▪ Serves as basis for modelling of function.
▪ A description of each function presented in DFD is contained in a process
specification (PSPEC)
▪ PSPEC describes input to function, algorithm, output produced, restrictions,
limitations etc.
➢ Behavioural Model:
o State Transition Diagram:
▪ Indicate how the system behaves as a consequence of external events.
▪ To accomplish this, STD represents the various modes of behaviour (called states) of
the system and the manner in which transitions are made from state to state.
▪ It serves as a basis for behavioural modelling.
▪ Additional information about the control aspects of the software is contained in the
control specification (CSPEC).

THE DATA DICTIONARY:

The analysis model encompasses representations of data objects, function, and control. In each
representation data objects and/or control items play a role. Therefore, it is necessary to provide an
organized approach for representing the characteristics of each data object and control item. This is
accomplished with the data dictionary.
The data dictionary has been proposed as a quasi-formal grammar for describing the content of objects
defined during structured analysis. This important modeling notation has been defined in the following
manner:

The data dictionary is an organized listing of all data elements that are pertinent to the system, with
precise, rigorous definitions so that both user and system analyst will have a common understanding
of inputs, outputs, components of stores and [even] intermediate calculations.

Today, the data dictionary is always implemented as part of a CASE "structured analysis and design tool."
Although the format of dictionaries varies from tool to tool, most contain the fo1Iowing information:
• Name - the primary name of the data or control item, the data store or an external entity.
• Alias - other names used for the first entry.
• Where-used/how-used - a listing of the processes that use the data or control item and how it is used
(e.g., input to the process, output from the process, as a store, as an external entity.)
• Content description - a notation for representing content.
• Supplementary information - other information about data types, preset values (if known), restrictions
or limitations, and so forth.

Once a data object or control item name and its aliases are entered into the data dictionary, consistency in
naming can be enforced. That is, if an analysis team member decides to name a newly derived data item
Advanced Software Engineering Page 2 of 8
 Chapter 5: Analysis Modeling
xyz, but xyz is already in the dictionary, the CASE tool supporting the dictionary posts a warning to
indicate duplicate names. This improves the consistency of the analysis model and helps to reduce errors.
"Where-used/how-used" information is recorded automatically from the flow models. When a dictionary
entry is created, the CASE tool scans DFDs to determine which processes use the data or control
information and how it is used.

To illustrate the use of the data dictionary, consider the level 2 DFD for the monitor system process for
SafeHome. Referring to the data item telephone number is specified as input. But what exactly is a tele-
phone number? It could be a 7-digit local number, a 4-digit extension, or a 25-digit long distance carrier
sequence. The data dictionary provides precise definition of telephone number for DFD in question. In
addition, it indicates where and how this data item is used and any supplementary information that is
relevant to it. The data dictionary entry begins as follows:

name: telephone number

aliases: none
where-used/how-used: assess against set-up (output)
dial phone (input)
description:
telephone number = [ local number | long distance number ]
local number = prefix + access number
local distance number = 1 + area code + local number
area code = [800 | 888 | 581]
prefix = *a three digit number that never starts with 0 or 1*
access number = * any four number string *

In above example [ a| b] means selection i.e. any one of a or b.

For large computer – based systems, the data dictionary grows rapidly in size and complexity. In fact, it is
extremely difficult to maintain a dictionary manually. For this reason, CASE tools should be used.

DATA MODELLING:
It answers a set of specific questions, relevant to any data processing application.
➢ What are the primary data objects to be processed?
➢ What is the composition of each data object and what attributes describe the object?
➢ Relationship between objects?
Entity Relationship Diagram:
Used for specifying user views and logical requirements. Three concepts:
➢ Entity/data objects: a collection of items that share common properties.
➢ Relations: Define how entities are connected to one another.
➢ Attributes: Defines properties of an entity.

ERD defines all data that are entered, stored, transformed and produced within an application. It focuses
solely on data. Data modelling considers data, independent of the processing that transforms the data.

Advanced Software Engineering Page 3 of 8

 Chapter 5: Analysis Modeling
FUNCTIONAL MODEL OR INFORMATION FLOW:
Information is transformed as it flows through a computer-based system. System accepts input in variety of
forms; applies hardware, software and human elements to transform input to output and produces output
in variety of forms.

Inputs can be:

• Control signal from transducers.
• Data entered through keyboard.
• Packets of information over network.
• Voluminous data file retrieved from secondary storage.
Transforms can be:
• Single logical comparison.
• Complex numerical algorithm.
• Rule-interface approach of an expert system.
Outputs can be:
• Single LED
• 200 page report.

Data Flow Diagrams:

The dataflow diagram is one of the most commonly used systems-modeling tools, particularly for
operational systems in which the functions of the system are of paramount importance and more complex
than the data that the system manipulates. DFDs were first used in the software engineering field as a
notation for studying systems design issues. In turn, the notation had been borrowed from earlier papers on
graph theory, and it continues to be used as a convenient notation by software engineers concerned with
direct implementation of models of user requirements.
DFD is a graphical representation that depicts information flow and the transforms that are applied as data
move from input to output. They describe systems as collection of functions that manipulate data. Data can
be organized in several ways:
• Can be stored in data repositories
• Can flow in data flow
• Can be transferred to or from external environment.
The following are the basic elements of a DFD:
• Functions represented by bubble or rounded rectangle.

• Data Flows, represented by arrows. Arrows going to bubbles

represent input values that belong to the domain of the function
represented by the bubble. Outgoing arrows represent the result of
the function – i.e. values that belong to the range of the function.
• Data stores, represented by open boxes. Arrows entering (exiting)
open boxes represent data that are inserted into (extracted from) the
data store.
• Input- output is represented by special IO boxes

Different Abstraction levels of DFD:

At level 0, DFD is also called fundamental system model or context model which represents entire software
element as a bubble with inputs and outputs.

Advanced Software Engineering Page 4 of 8

 Chapter 5: Analysis Modeling
At level 1, represent each of processes as a sub function of the overall system.
At level 2, add further details to each sub function

CASE STUDY - SAFEHOME SOFTWARE:

In the SafeHome security system, is a microprocessor-based home security system that would protect against
and/or recognize a variety of undesirable situations such as illegal entry, fire, flooding, and others. The
product will use appropriate sensors to detect each situation, can be programmed by homeowner, and will
automatically telephone a monitoring agency when a situation is detected.

SafeHome software enables the homeowner to configure the security system when it is installed,
monitors all sensors connected to the security system, and interacts with the homeowner through a
keypad and function keys contained in the SafeHome control panel.
During installation, the SafeHome control panel is used to "program" and configure the system. Each
sensor is assigned a number and type, a master password is programmed for arming and disarming the
system, and telephone number(s) are input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to the system. After
a delay time that is specified by the homeowner during system configuration activities, the software
dials a telephone number of a monitoring service, provides information about the location, reporting
the nature of the event that has been detected. The telephone number will be redialed every 20 seconds
until telephone connection is obtained
All interaction with SafeHome is managed by a user-interaction subsystem that reads input provided
through the keypad and function keys, displays prompting messages on the LCD display, and
displays system status information on the LCD display. Keyboard interaction takes the following
form...

“Context-level DFD for SafeHome”

Again considering the SafeHome product, a level 0 DFD for the system is shown in figure above. The
primary external entities (boxes) produce information for use by the system arid consumes information
generated by the system. The labeled arrows represent data objects or data object type hierarchies. For
example, user commands and data encompasses all configuration commands, all activation/deactivation
commands, all miscellaneous interactions, and all data that are entered to qualify or expand a command.
The level 0 DFD is now expanded into a level I model. But how do we proceed? A simple, yet effective
approach is to perform a "grammatical parse" on the processing narrative that describes the context level
bubble. That is, we isolate all nouns (and noun phrases) and verbs (and verb phrases) in the SaftHome
Advanced Software Engineering Page 5 of 8
 Chapter 5: Analysis Modeling
narrative presented below. To illustrate, we again reproduce the processing narrative underlining the first
occurrence of all nouns and italicizing the first occurrence of all verbs.3

Referring to the "grammatical parse," a pattern begins to emerge. All verbs are SaftHome processes; that is,
they may ultimately be represented as bubbles in a subsequent DFD. All nouns are either external entities
(boxes), data or control objects (arrows), or data stores (double lines). Note further that nouns and verbs can
be attached to one another (e.g., sensor is assigned number and type). Therefore by performing a
grammatical parse on the processing narrative for a bubble at any DFD level, we can generate much useful
information about how to proceed with the refinement to the next level. Using this information, a level I
DFD is shown in figure. The context level process has been expanded into six processes derived from an
examination of the grammatical parse. Similarly, the information flow between processes at level 1 has been
derived from the parse.

“Level 1 DFD for SafeHome”

It should be noted that information flow continuity is maintained between levels 0 and 1. The processes
represented at DFD level 1 can be further refined into lower levels. For example, the process monitor sensors
can be refined into a level 2 DFD as shown in figure. Note once again that information flow continuity has
been maintained between levels.

Advanced Software Engineering Page 6 of 8

 Chapter 5: Analysis Modeling

The refinement of DFDs continues until each bubble performs a simple function. That is, until the process
represented by the bubble performs a function that would be easily implemented as a program component.

BEHAVIOURAL MODELLING:
Behavioural modelling is an operational principle for all requirements analysis methods. Yet, only extended
versions of structured analysis provide a notation for this type of modelling.

State Transition Diagram:

The STD represents the behavioural of a system by depicting its states and the events that cause the system
to change state. In addition, the STD indicates what actions are taken as a consequence of a particular event.

Creating a State Transition Diagram:

The control specification (CSPEC) represents the behavior of the system (at the level from which it has been
referenced) in two different ways. The CSPEC contains a state transition diagram that is a sequential
specification of behavior. It can also contain a program activation table - a combinatorial specification of
behavior.
A state transition diagram for the level I control flow model for SafeHome is shown in the figure. The labeled
transition arrows indicate how the system responds to events as it traverses the four states defined at this
level. By studying the STD, a software engineer can determine the behavior of the system and, more
important can ascertain whether there are “holes” in the specified behavior. For example, the STD indicates
that the only transition from the reading user input state occurs when the start/stop switch is encountered
and a transition to the monitoring system status state occurs. Yet there appears to be no way, other than the
occurrence of sensor event, that will allow the system to return to reading user input This is an error in
specification and would, be uncovered during review and corrected. Examine the STD to determine
whether there are any other anomalies.

Advanced Software Engineering Page 7 of 8

 Chapter 5: Analysis Modeling

Microwave oven operation

Advanced Software Engineering Page 8 of 8