MS. R. S.

MORE
ME (COMPUTER)
Lecturer
)
Department of Information Technology
https://reenamorersm.wordpress.com/
Email: [email protected]
 Analysis Model
UNIT - III Analysis Modelling principle
Analysis Model Objective
SOFTWARE MODELLING & DESIGN Analysis Rule of thumb
DATA MODELING
□ Analysis model often begin with data
modeling.
□ Data model consists of three interrelated pieces of
information:
■ The data object,
■ The attributes that describe the data object, and
■ The relationships that connect data objects to one
another.
DATA OBJECT
□ A data object is a representation of almost any
composite information that must be understood by
software.
composite information - number of different properties or
□ attributes.
A data object can be:-
□
■ An external entity (e.g., anything that produces or consumes
information),
■ A thing (e.g., a report or a display), An
■ occurrence (e.g., a telephone call) Event (e.g.,
■ an alarm),
■ A role (e.g., salesperson),
■ An organizational unit (e.g., accounting department), A place (e.g.,
■ a warehouse),
■ A structure (e.g., a file).
FOR EX.- SET OF ATTRIBUTES CAN BE DEFINED FOR
A PERSON OR A CAR (I.E. DATA OBJECT)
DATA ATTRIBUTES
□ Define the properties of a data object.
□ Attributes name a data object, describe its
characteristics, and in some cases, make
reference to another object.
□ In addition, one or more of the attributes must
be defined as an identifier( Key value or
Unique value).
Ex. Data object Car has Id number as identifier.
RELATIONSHIPS
□ Data objects are connected to one another in different
ways.
□ Consider two data objects
□ Book
□ Bookstore
□ A connection is established between book and
bookstore because the two objects are related.
RELATIONSHIP
□ To determine relationship between them, must
understand the role of book and bookstore.
□ Can define a set of object/relationship pairs that define
the relevant relationships.
For Example:
■ A bookstore orders books.
■ A bookstore displays books.
■ A bookstore stocks books.
■ A bookstore sells books.
■ A bookstore returns books.
CARDINALITY AND MODALITY
□ Additional element of data modeling.
□ Object X relates to object Y does not provide
enough information.
□ How many occurrences of object X are
related to how many occurrences of object Y
called cardinality.
CARDINALITY
□ Representing the number of occurrences objects in a given
relationship.
□ Cardinality is the specification of the number of occurrences
of one [object] that can be related to the number of
occurrences of another.
□ Cardinality is usually expressed as simply 'one' or 'many’.
1:1 – One object can relate to only one other object.
□
1:M – one object can relate to many objects.

□
□ M:N – Some no. of occurrences of an object can
relate to some other no. of occurrences of another
object.
MODALITY
□ Cardinality does not provide an indication of whether or not a
particular data object must participate in the relationship.
Modality of a relationship is 0 if there is no explicit need for the
□ relationship to occur or the relationship is optional.
The modality is 1 if an occurrences of the relationship is
mandatory.
□
FUNCTION MODELING & INFORMATION
FLOW
□ Information is transformed as it flows through a computer-based
system. The system accepts input in a variety of forms; applies
hardware, software, and human elements to transform it; and produces
output in a variety of forms
□ Structured analysis began as an information flow modeling
technique.
□ A rectangle is used to represent an external entity (software,
hardware, a person)
□ A circle (sometimes called a bubble) represents a process or
transform that is applied to data (or control) and changes it in some
way.
FUNCTION MODELING & INFORMATION
FLOW
□ An arrow represents one or more data items
(data objects) and it should be labeled.
□ The double line represents a data store—stored information
that is used by the software.
□ First data flow model (sometimes called a level 0 DFD or
context diagram) represents the entire system.
□ It provides incremental detail with each
subsequent level.
INFORMATION FLOW MODEL
CREATING A DATA FLOW MODEL
□ It enables software engineer to develop models of
the information domain and functional domain at
the same time.
□ Data flow diagram may be used to represent a system
or software at any level of abstraction
□ As DFD is refined into greater levels of detail,
the analyst performs an implicit functional
decomposition of the system.
□ As DFD refinement results in corresponding
refinement of data as it moves through the processes
that represent the application
DFD GUIDELINES
□ Depict the system as single bubble in level 0.
□ Primary input and output should be carefully noted
□ Refine by isolating candidate processes and their
associated, data objects and data stores
□ All arrows and bubbles should be labeled with
meaningful names.
□ Information flow continuity must be
maintained from level to level.
□ One bubble at a time should be refined.
DATA FLOW MODELS
□ A level 0 DFD, also called a fundamental system model or a
context model, represents the entire software element as a single
bubble with input and output data indicated by incoming and
outgoing arrows.
Level 0 DFD refinement into level 1 DFD with all relevant
□ processes to the system.
Level 1 DFD each processes can be refined into level 2
□ DFD.
Refinement of DFD continues until each bubble performs a
□ simple function.
CONTROL FLOW MODEL
□ Application which contains collection of classes
are dependent on event rather than data, produce
control information rather than reports or
displays.
□ Such application require the use of control flow
modeling in addition to data flow modeling.
GUIDELINE FOR CONTROL FLOW
□ List all processes that are performed by the software. List all the
□ interrupt conditions.
□ List all activities that are performed by operator or actor.
List all data conditions.
□
Review all the “Control items” as possible for control flow inputs
□ / outputs.
Describe the behavior of a system by identifying its states;
□ identify how each state is reached; define the transitions between
states.
Focus on possible omission – a very common error in specifying
□ control
CONTROL SPECIFICATION (CSPEC)
□ CSPEC represent the behavior of the system in two different ways.
It contains a state diagram – sequential specification of behavior.
□
It also contain program activation table –
combinatorial specification of behavior.
□ By reviewing the state diagram, a software engineer can determine
the behavior of the system and can discover whether there are
□ “holes” in specified behavior.
CSPEC describe the behavior of the system, but it gives us no
information about the inner working of the processes that activated
result.
□
PROCESS SPECIFICATION (PSPEC)
□ Used to describe all flow model processes that appear
at the final level of refinement.
□ It include narrative text, a program design language
(PDL) description of the process algorithm,
mathematical equations, tables, diagrams or charts.
□ By providing a PSPEC to accompany each bubble in
the flow model, the software engineer creates a “mini-
spec” that can serve as guide for design of the
software component that will implement the process.