Tools of structured

analysis and system

Design
Data Flow Diagram
It was first developed by Larry Constantine
as a way of expressing system requirements
in a graphical form.
It is also known as Bubble Chart.
A DFD shows what kind of information will be
input to and output from the system, where
the data will come from and go to, and
where the data will be stored. It does not
show information about the timing of process
or information about whether processes will
operate in sequence or in parallel
DFD Components
External entity:an outside system that sends or
receives data, communicating with the system being
diagrammed. They are the sources and destinations of
information entering or leaving the system. They
might be an outside organization or person, a
computer system or a business system. They are also
known as terminators, sources and sinks or actors.
They are typically drawn on the edges of the diagram.
Process:any process that changes the data,
producing an output. It might perform computations,
or sort data based on logic, or direct the data flow
based on business rules. A short label is used to
describe the process, such as Submit payment.
 Data store:files or repositories that hold
information for later use, such asa database
table or a membership form. Each data
storereceives a simple label, such as
Orders.
Data flow:the route that data takes
between the external entities, processes and
data stores. It portrays the interface
between the other components and is shown
with arrows, typically labeled with a short
data name, like Billing details.
Symbols and Notations Used
in DFDs
Common systems of symbols are
named after their creators:
Yourdon and Coad
Gane and Sarson
Yourdon and DeMarco
Yourdon and DeMarco
 DFD rules and tips
Each process should have at least one input and
an output.
Data stored in a system must go through a
process.
All processes in a DFD go to another process or
a data store.
Processes should be named and numbered for
easy reference
The direction of flow is from top to bottom and
from left to right
Data flow from the source to destination,
although they may flow back to a source.
DFD levels and layers

DFD levels are numbered 0, 1 or 2,

and occasionally go to even Level 3
or beyond. The necessary level of
detail depends on the scope of what
you are trying to accomplish.
DFD Level 0

DFD Level 0 is also called a Context

Diagram. Its a basic overview of the
whole system or process being
analyzed or modeled. Its designed
to be an at-a-glance view, showing
the system as a single high-level
process, with its relationship to
external entities. It should be easily
understood by a wide audience,
including stakeholders, business
 DFD Level 1
DFD Level 1 provides a more detailed
breakout of pieces of the Context Level
Diagram. You will highlight the main
functions carried out by the system, as
you break down the high-level process
of the Context Diagram into its
subprocesses.
DFD Level 2

DFD Level 2 then goes one step

deeper into parts of Level 1. It may
require more text to reach the
necessary level of detail about the
systems functioning.
 Progression to Levels 3, 4 and
beyond is possible, but going beyond
Level 3 is uncommon. Doing so can
create complexity that makes it
difficult to communicate, compare or
model effectively.
Using DFD layers, the cascading
levels can be nested directly in the
diagram, providing a cleaner look
with easy access to the deeper dive.
 Examples of how DFDs can
be used
DFD in software engineering:This is where data flow diagrams got
their main start in the 1970s. DFDs can provide a focused approached
to technical development, in which more research is done up front to
get to coding.
DFD in business analysis:Business analysts use DFDs to analyze
existing systems and find inefficiencies. Diagramming the process can
uncover steps that might otherwise be missed or not fully understood.
DFD in business process re-engineering:DFDs can be used to
model a better, more efficient flow of data through a business process.
BPR was pioneered in the 1990s to help organizations cut operational
costs, improve customer service and better compete in the market.
DFD in agile development:DFDs can be used to visualize and
understand business and technical requirements and plan the next
steps. They can be a simple yet powerful tool for communication and
collaboration to focus rapid development.
DFD in system structures:Any system or process can be analyzed in
progressive detail to improve it, on botha technical andnon-technical
basis.
Agile software
development
Agile software
developmentdescribes a set of
principles forsoftware
developmentunder which
requirements and solutions envolve
through the collaborative effort of
self-organizingcross-functional
teams.
 Agile Manifesto Principles
Customer satisfaction by early and continuous delivery of valuable
software.
Welcome changing requirements, even in late development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between business people and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-
location)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicitythe art of maximizing the amount of work not doneis
essential
Best architectures, requirements, and designs emerge from self-
organizing teams
Regularly, the team reflects on how to become more effective, and
adjusts accordingly
Logical DFD vs. Physical DFD

These are the two categories of a data flow

diagram. A Logical DFD visualizes the data flow
that is essential for a business to operate. It
focuses on the business and the information
needed, not on how the system works or is
proposed to work. However, a Physical DFD
shows how the system is actually implemented
now, or how it will be. For example, in a Logical
DFD, the processes would be business
activities, while in a Physical DFD, the processes
would be programs and manual procedures.
Design Logical Physical
Feature
What the model How the business How the system will be implemented
depicts operates. (or how the current system
operates).
What the Business Programs, program modules, and
processes activities. manual procedures.
represent
What the data Collections of Physical files and databases, manual
stores represent data regardless of files.
how the data are
stored.
Type of data Show data stores Master files, transition files. Any
stores representing processes that operate at two
permanent data different times must be connected
collections. by a data store.
System controls Show business Show controls for validating input
controls. data, for obtaining a record (record
 Entity Relationship
Diagram
An Entity Relationship
Diagram (ERD) is a
visual representation of
different data using
conventions that
describe how these data
are related to each
other. For example, the
elements writer, novel,
and consumer may be
described using ER
diagrams this way:
ER Diagram Symbols and
Notations
There are three basic elements in an
ER Diagram: entity, attribute,
relationship.
Entity

Anentity can be a person, place,

event, or object that is relevant to a
given system. For example, a school
system may include students,
teachers, major courses, subjects,
fees, and other items. Entities are
represented in ER diagrams by a
rectangle and named using singular
nouns.
Weak Entity

A weak entity is an entity that depends on

the existence of another entity. In more
technical terms it can defined as an entity
that cannot be identified by its own
attributes. It uses a foreign key combined
with its attributed to form the primary key.
An entity like order item is a good
example for this. The order item will be
meaningless without an order so it
depends on the existence of order.
Attribute
An attribute is a property, trait, or characteristic of
an entity, relationship, or another attribute. For
example, the attribute Inventory Item Name is an
attribute of the entity Inventory Item. An entity can
have as many attributes as necessary. Meanwhile,
attributes can also have their own specific attributes.
For example, the attribute customer address can
have the attributes number, street, city, and state.
These are called composite attributes. Note that
some top level ER diagrams do not show attributes
for the sake of simplicity. In those that do, however,
attributes are represented by oval shapes.
 Attributes in ER diagrams, note that an
attribute can have its own attributes
( composite attribute )
Multivalued Attribute

If an attribute can have more than one

value it is called an multivalued attribute.
It is important to note that this is different
to an attribute having its own attributes.
For example a teacher entity can have
multiple subject values.
Derived Attribute

An attribute based on another

attribute. This is found rarely in ER
diagrams. For example for a circle
the area can be derived from the
radius.
Relationship

A relationship describes how entities

interact. For example, the entity
carpenter may be related to the entity
table by the relationship builds or
makes. Relationships are represented by
diamond shapes and are labeled using
verbs.
Recursive Relationship

If the same entity participates more than

once in a relationship it is known as a
recursive relationship. In the below
example an employee can be a supervisor
and be supervised, so there is a recursive
relationship.
Cardinality and
Ordinality
Connecting lines, solid lines that connect
attributes to show the relationships of entities in
the diagram.
Cardinalityspecifies how many instances of an
entity relate to one instance of another entity.
Ordinality is also closely linked to cardinality.
While cardinality specifies the occurrences of a
relationship, ordinality describes the relationship
as either mandatory or optional. In other words,
cardinality specifies the maximum number of
relationships and ordinality specifies the absolute
minimum number of relationships.
 These two further defines
relationships between entities by
placing the relationship in the
context of numbers. In an email
system, for example, one account
can have multiple contacts. The
relationship in this case follows a
one to many model. There are
number of notations used to present
cardinality in ER diagrams.
 Cardinality constraints are expressed as follows:
a double line indicates aparticipation
constraint,totalityorsurjectivity: all entities in the entity
set must participate inat least onerelationship in the
relationship set;
an arrow from entity set to relationship set indicates
akey constraint, i.e.injectivity: each entity of the entity
set can participate inat most onerelationship in the
relationship set;
a thick line indicates both, i.e.bijectivity: each entity in
the entity set is involved inexactly onerelationship.
an underlined name of an attribute indicates that it
is akey: two different entities or relationships with this
attribute always have different values for this attribute.
Notation styles that express
cardinality.
 When documenting a system or
process, looking at the system in
multiple ways increases the
understanding of that system. ERD
diagrams are commonly used in
conjunction with adata flow
diagramto display the contents of a
data store. They help us to visualize
how data is connected in a general
way, and are particularly useful for
How to Create an Entity
Relationship Diagram
Identify the entities.The first step in making
an ERD is to identify all of the entities you will
use. An entity is nothing more than a rectangle
with a description of something that your system
stores information about. This could be a
customer, a manager, an invoice, a schedule,
etc. Draw a rectangle for each entity you can
think of on your page. Keep them spaced out a
bit.
Identify relationships.Look at two entities, are
they related? If so draw a solid line connecting
the two entities.
 Describe the relationship.How are the entities
related? Draw an action diamond between the two
entities on the line you just added. In the diamond
write a brief description of how they are related.
Add attributes.Any key attributes of entities
should be added using oval-shaped symbols.
Complete the diagram.Continue to connect the
entities with lines, and adding diamonds to
describe each relationship until all relationships
have been described. Each of your entities may
not have any relationships, some may have
multiple relationships.
Tips for Effective ER
Diagrams
Make sure that each entity only appears once per
diagram.
Name every entity, relationship, and attribute on
your diagram.
Examine relationships between entities closely.
Are they necessary? Are there any relationships
missing? Eliminate any redundant relationships.
Don't connect relationships to each other.
Never connect a relationship to another
relationship.
Use colors to highlight important portions of your
diagram.
Structured Analysis

It is a set of techniques and

graphical tools that allow the analyst
to develop a new kind of system that
is understandable to the user.
 Adata modelis an abstract model
that organizes elements ofdataand
standardizes how they relate to one
another and to properties of the real
world entities.
A data modelinstancemay be one of
three kinds :
Conceptual data model
Logical data model
Physical data model
 Conceptual data model
It is a high-level description of a business's
informational needs.
It typically includes only the main concepts
and the main relationships among them.
It hides the internal details of physical
storage and targets on describing entities,
data type, relationships and constraints.
Conceptualdata modelis a map
ofconceptsand theirrelationshipsused
fordatabases.
Logical data model

Alogicaldata modelorlogical
schemais adata modelof a specific
problem domain expressed
independently of a particular
database management product or
storage technology (physical data
model) but in terms of data
structures such as relational tables
and columns, object-oriented
classes, or XML tags.
Reasons for building a logical
data structure
Helps common understanding of business
data elements and requirements
Provides foundation for designing a database
Facilitates avoidance ofdata
redundancyand thus prevent data &
business transaction inconsistency
Facilitates data re-use and sharing
Decreases development and maintenance
time and cost
Confirms a logicalprocess modeland
helpsimpact analysis.
Physical data model
Aphysical data model(ordatabase design) is
a representation of a data design as
implemented, or intended to be implemented, in
adatabase management system.
Thelogical schemawas the way data were
represented to conform to the constraints of a
particular approach to database management. At
that time the choices were hierarchical and
network. Describing the logical schema, however,
still did not describe how physically data would be
stored on disk drives. That is the domain of
thephysical schema.
Types of data models

Database model
Data structure diagram
Entity-relationship model
Geographic data model
Generic data model
Semantic data model
 Database model
Flat model : This may not
strictly qualify as a data model.
The flat (or table) model
consists of a single,
two-dimensional array of data
elements, where all members
of a given column are assumed
to be similar values, and all
members of a row are assumed
to be related to one another.
 Hierarchical model :The
hierarchical model is similar to the
network model except that links in
the hierarchical model form a tree
structure, while the network model
allows arbitrary graphs
 Network model: This model
organizes data using two
fundamental constructs,
called records and sets.
Records contain fields, and
sets define one-to-many
relationships between
records: one owner, many
members.The network data
model is an abstraction of the
design concept used in the
implementation of databases.
 Relational model: It is a database
model based on first-order predicate
logic. Its core idea is to describe a
database as a collection of
predicates over a finite set of
predicate variables, describing
constraints on the possible values
and combinations of values.The
power of the relational data model
lies in its mathematical foundations
 Object-relational model: Similar
to a relational database model, but
objects, classes and inheritance are
directly supported indatabase
schemasand in the query language.
 Star schema : The simplest style of
data warehouse schema. The star
schema consists of a few "fact
tables" (possibly only one, justifying
the name) referencing any number
of "dimension tables".
Data Structure Diagram

Adata structure diagram(DSD) is a

data model or diagram used to
describe conceptual data models by
providing graphical notations which
document entities and their
relationships, and the constraints
that bind them.
Entity-relationship
model
An entity-relationship model (ERM),
sometimes referred to as an entity-
relationship diagram (ERD), is an
abstractconceptual data
model(orsemantic data model)
used insoftware engineeringto
represent structured data. There are
several notations used for ERMs.
Geographic data model
A data model inGeographic information
systemsis a mathematical construct for
representing geographic objects or surfaces
as data. For example,
thevectordata model represents geography
as collections of points, lines, and polygons;
therasterdata model represent geography
as cell matrixes that store numeric values;
and theTriangulated irregular network(TIN)
data model represents geography as sets of
contiguous, no overlapping triangles
Generic data model
Generic data models are generalizations of
conventional data models. They define
standardized general relation types,
together with the kinds of things that may
be related by such a relation type. Generic
data models are developed as an approach
to solve some shortcomings of conventional
data models. For example, different
modelers usually produce different
conventional data models of the same
domain.
Semantic data model

A semantic data model in software

engineering is a technique to define
the meaning of data within the
context of its interrelationships with
other data. A semantic data model is
an abstraction which defines how the
stored symbols relate to the real
world
Data Dictionary

A structured place to keep details of

the contents of data flows,
processes, and data store.
It is a structured repository of data
about data.
It is a set of definitions of all DFD
elements.
 Advantages of Data
Dictionary
Documentation- it is a valuable
reference in any organization.
It improves analyst/user communication
by establishing consistent definitions of
various elements, terms and procedures
It is important step in building a
database.
 Items to be defined in Data
Dictionary
Data Elements- smallest unit of data that
provides for no further decomposition.
For example: date consists of day, month and year
DataStructure- a group of data elements
handled as a unit.
For example: phone is a data structure consisting of
four data elements: area-code-exchange-number-
extension.
Data Flows and Data Stores- data flows are
data structures in motion, whereas data stores are
data structures at rest. A data store is a location
where data structures are temporarily located.
Data Dictionary

Smallest Unit of Data

Group of Data Elements

Groups of Data
Structures
Data Elements

Fore.g.
Author Name:
First
Middle
Last Alias
The Description of Data Element should
include:
1. Name
2. Description &
3. An Alias (Synonym)
Data Elements

Whether or not Data Element has the

following:
A Different Name:
For e.g. A Purchase Order may exist as Pur. Order,
Purchase Ord., or P.O. We will record all these in Data
Dictionary under Definition of Purchase Order.
Usage Characteristics
Range of Values or Frequency of use or both.
2 types:
Value within Range: For e.g. Payroll between 1000 and 10000
= Continuous Value.
Specific Value: For e.g. Depts. In a Firm coded 100
(Accounting), 110 (HR), 111 ( Operations) etc.
Data Elements

Control Information
Such as Source, Date of Origin,
Users, or Access Authorization.
For e.g. Looking for Properties of Word
Doc.
Physical Location
In terms of Record of File or Database.
For e.g. Where Storage is done C Drive,
D Drive, CD ROM etc.
Data Structures

Itis the Group of Elements .

For e.g.
Data Structures: Book Details
Data Elements: Author Name (M)
Title of the Book (M)
ISBN (Optional)
Publisher Name (M)
Quantity Ordered (M)
Some Element are Mandatory whereas
others are Optional
Why do we use these
tools?
Use graphics whenever possible to
help communicate better with the
user.
Differentiate between logical and
physical system
Build a logical system model to
familiarize the user with system
characteristics and interrelationships
before implementation
Decision Tree

Once the data elements are defined in

the data dictionary, we begin to focus
on the processes.
For example:
Bookstores get a trade discount of 25%;
for orders from libraries and individuals,
5% allowed on orders of 6-19 copies per
book title; 10% on orders for 20-49 copies
per book title; 15% on orders for 50
copies or more per book title
Decision Tables
Itis a table of possibilities foe defining a
problem and the actions to be taken
It is a single representation of the
relationships between conditions and actions
It consists of two parts: stub and entry
The stub part is divided into an upper
quadrant called the condition stub and a
lower quadrant called the action stub
The entry part is also divided into an upper
quadrant, called the condition entry and a
lower quadrant called the action entry