0% found this document useful (0 votes)
7 views

7 - Analysis Modeling

The document discusses Analysis Modeling, which serves as a technical representation linking system descriptions to design models, utilizing tools like E-R Diagrams and DFDs. It details the components of Entity-Relationship Diagrams, including entities, attributes, and relationships, as well as the structure and purpose of Data Flow Diagrams in visualizing data movement within systems. Additionally, it covers the importance of Data Dictionaries in documenting data elements and ensuring system accuracy and completeness.

Uploaded by

Abhinav Saroya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

7 - Analysis Modeling

The document discusses Analysis Modeling, which serves as a technical representation linking system descriptions to design models, utilizing tools like E-R Diagrams and DFDs. It details the components of Entity-Relationship Diagrams, including entities, attributes, and relationships, as well as the structure and purpose of Data Flow Diagrams in visualizing data movement within systems. Additionally, it covers the importance of Data Dictionaries in documenting data elements and ensuring system accuracy and completeness.

Uploaded by

Abhinav Saroya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 44

Analysis Modeling

Ashish Kumar

1
Analysis Modeling
Analysis Model is a technical representation of the
system.
It acts as a link between the system description and
the design model.
In Analysis Modelling, information, behavior, and
functions of the system are defined and translated into
the architecture, component, and interface level
design in the design modeling.
It enables the software engineer to create analysis
and design models of the system to be built.
It performs consistency checking between models.
It is a type of CASE (Computer Aided Software Enggineering) Tool.
It uses different techniques like E-R Diagrams, DFD,
Flow Chart, UML Diagrams.
2
Elements of Analysis Model

3
Entity Relationship
Diagram

4
Entity – Relationship Diagrams
1976 proposed by Peter Chen
ER diagram is widely used in database design
Represent conceptual level of a database
system
Describe things and their relationships in high
level
Entity set – an abstraction of similar things,
e.g. cars, students
An entity set contains many entities
Attributes – common properties of the
entities in a entity sets
Relationship – specify the relations among
5
Entity Set
A database can be modeled as:
a collection of entities,
relationship among entities.
An entity is an object that exists and is
distinguishable from other objects.
 Example: specific person, company, event, plant

Entities have attributes


Example: people have names and addresses
An entity set is a set of entities of the same
type that share the same properties.
Example: set of all persons, companies, trees,
holidays
6
Attribute
An entity is represented by a set of attributes,
that is descriptive properties possessed by all
members of an entity set.
Domain – the set of permitted values for each
attribute
Attribute types:
Simple and composite attributes.
Single-valued and multi-valued attributes
 E.g. multivalued attribute: phone-numbers
Derived attributes
 Can be computed from other attributes
 E.g. age, given date of birth

7
Relationship
A relationship is an association among
several entities.
Example: Hayes depositor
A-102
customer entity relationship set
account entity
A relationship set is a mathematical relation
among n  2 entities, each taken from entity
sets
{(e1, e2, … en) | e1  E1, e2  E2, …,
en  En}
where (e1, e2, …, en) is a relationship
8

Degree of a Relationship Set
Refers to number of entity sets that participate
in a relationship set.
Relationship sets that involve two entity sets
are binary (or degree two). Generally, most
relationship sets in a database system are
binary.
Relationship sets may involve more than two
entity sets.
 E.g. – Suppose employees of a bank may have jobs
(responsibilities) at multiple branches, with different
jobs at different branches. Then there is a ternary
relationship set between entity sets employee, job and
branch
 9
Mapping Cardinalities
Express the number of entities to which
another entity can be associated via a
relationship set.
Most useful in describing binary relationship
sets.
For a binary relationship set the mapping
cardinality must be one of the following types:
One to one
One to many
Many to one
Many to many

10
Mapping Cardinalities

One to One to Many


One
Note: Some elements in A and B may not be mapped to any
elements in the other set
11
Mapping Cardinalities

Many to Many to Many


One
Note: Some elements in A and B may not be mapped to any
elements in the other set
12
ER Diagram Notations

13
ER Diagram Notations

14
ER Diagram Example - 1

 Rectangles represent entity sets.


 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to
relationship sets.
 Ellipses represent attributes
 Double ellipses represent multivalued attributes.
 Dashed ellipses denote derived attributes.
 Underline indicates primary key attributes. 15
ER Diagram Example - 2

16
Data Flow Diagram

17
Data Flow Diagram (DFD)
A structured analysis technique that employs a
set of visual representations of the data that
moves through the organization, the paths
through which the data moves, and the processes
that produce, use, and transform data.
Data flow diagrams (DFDs) are used to depict the
flow and transformation of data in an information
processing system.
DFDs give an overview to an analyst specifying
where data originates, how it is processed and
where the results go.
DFDs act as a graphical communication aid
between a user and an analyst. It is also useful as
a communication aid between an analyst and a
system designer. 18
Data Flow Diagram (DFD)
The procedure to develop a DFD starts with one
DFD giving an overview of the system to be
designed. This is called a context diagram.
The context diagram is expanded into a series of
DFDs, each describing a specific function. This
method of top down analysis and breaking down
DFDs to give more and more detail is known as
levelling.
The main merit of DFD is that it provides an
overview of what data flows in a system, what
transformations are done on the data, what files
are used and where results flow.
It is a good documentation aid which is
understood by both programmers and non-
programmers (i.e., laypersons). As DFD specifies
only what processes are performed and not how19
Why Data Flow Diagrams?
Can diagram the organization or the
system
Can diagram the current or proposed
situation
Can facilitate analysis or design
Provides a good bridge from analysis to
design
Facilitates communication with the user at
all stages

20
What Data Flow Diagrams Provides?
What data is system processes.
What transformation are performed.
What data are stored.
What results are produced , etc.

21
Characteristics of Data Flow Diagrams
 Graphical Representation: Data Flow Diagram (DFD) use
different symbols and notation to represent data flow
within system. That simplify the complex model.
 Problem Analysis: Data Flow Diagram (DFDs) are very
useful in understanding a system and can be effectively
used during analysis. Data Flow Diagram (DFDs) are quite
general and are not limited to problem analysis for
software requirements specification.
 Abstraction: Data Flow Diagram (DFD) provides a
abstraction to complex model i.e. DFD hides unnecessary
implementation details and show only the flow of data and
processes within information system.
 Hierarchy: Data Flow Diagram (DFD) provides a hierarchy
of a system. High- level diagram i.e. 0-level diagram
provides an overview of entire system while lower-level
diagram like 1-level DFD and beyond provides a detailed
22
data flow of individual process.
Characteristics of Data Flow Diagrams
 Data Flow: The primary objective of Data Flow Diagram
(DFD) is to visualize the data flow between external entity,
processes and data store. Data Flow is represented by an
arrow Symbol.
 Ease of Understanding: Data Flow Diagram (DFD) can be
easily understand by both technical and non-technical
stakeholders.
 Modularity: Modularity can be achieved using Data Flow
Diagram (DFD) as it breaks the complex system into
smaller module or processes. This provides easily analysis
and design of a system.

23
Levels of DFD
Context level diagram - shows just the inputs
and outputs of the system.
Level 0 diagram - decomposes the process into
the major sub processes and identifies what data
flows between them.
Child diagrams - increasing levels of detail.
Primitive diagrams - lowest level of
decomposition.

24
Elements of Data Flow Diagrams
Elements of Data Flow Diagrams
Process: Input to output transformation in a system
takes place because of process function. The symbols
of a process are rectangular with rounded corners,
oval, rectangle or a circle. The process is named a
short sentence, in one word or a phrase to express its
essence.
Data Flow: Data flow describes the information
transferring between different parts of the systems.
The arrow symbol is the symbol of data flow. A
relatable name should be given to the flow to
determine the information which is being moved. Data
flow also represents material along with information
that is being moved. Material shifts are modeled in
systems that are not merely informative. A given flow
should only transfer a single type of information. The
direction of flow is represented by the arrow which
Elements of Data Flow Diagrams
Data Store: The data is stored in the warehouse for
later use. Two horizontal lines represent the symbol of
the store. The warehouse is simply not restricted to
being a data file rather it can be anything like a folder
with documents, an optical disc, a filing cabinet. The
data warehouse can be viewed independent of its
implementation. When the data flow from the
warehouse it is considered as data reading and when
data flows to the warehouse it is called data entry or
data updating.
External Entity: The Terminator is an external entity
that stands outside of the system and communicates
with the system. It can be, for example, organizations
like banks, groups of people like customers or
different departments of the same organization, which
is not a part of the model system and is an external
Creating a Set of DFDs
Create a graphical model of the information
system based on your fact-finding results
Performing three main tasks
Step 1: Draw a context diagram
Step 2: Draw a diagram 0 DFD
Step 3: Draw the lower-level diagrams
Context Diagram
A data flow diagram (DFD) of the scope of an
organizational system that shows the system
boundaries, external entities that interact with
the system and the major information flows
between the entities and the system.
A diagram giving an entire system’s data flows
and processing with a single Process (circle) is
called a context diagram.
A context diagram is expanded into a number of
inter-related processes. Each process may be
further expanded into a set of inter-connected
sub processes. This procedure of expanding a
DFD is known as levelling.
29
Context Diagram
Just one process
All sources and sinks that provide data to or
receive data from the process
Major data flows between the process and all
sources/sinks
No data stores

30
Context Diagram - Example

31
Drawing Guidelines for Context Diagram
1. Draw the context diagram so it fits on one page
2. Use the name of the information system as the
process name in the context diagram
3. Use unique names within each set of symbols
4. Do not cross lines
5. Provide a unique name and reference number
for each process
6. Obtain user input and feedback

32
O – Level Diagram
A data flow diagram (DFD) that represents a
system’s major processes, data flows and data
stores at a high level of detail.
Process is “exploded”
Sources, sinks, and data flows repeated from
context diagram
Process broken down into subprocesses,
numbered sequentially
Must retain all the connections that flow into and
out of process 0
Lower-level data flows and data stores added

33
Drawing Guidelines for 0-Level DFD
If same data flows in both directions, you can use a
double-headed arrow
Diagram 0 represents exploded view of process 0
Parent diagram
Child diagram
Functional primitive

34
Drawing Guidelines for Lower Level DFD
Must use leveling and balancing techniques
Leveling
Uses a series of increasingly detailed DFDs to
describe an information system
Exploding, partitioning, or decomposing
Balancing
Ensures that the input and output data flows of
the parent DFD are maintained on the child
DFD

35
Data Dictionary
& Its Elements

36
Data Dictionary
What does “Backordered
item” mean?

What does “New Customer info.”


contain?

How does the “account receivable report” 37


Data Dictionary
A list of names used in the system models
arranged alphabetically and their meaning and
information about them.
It contains the descriptions of all data objects
consumed or produced by the software.
Types of information provided:
Description of data
If composite data, describe elements
Data representation or type
Creator, creation date, user contacts
Other names for the data (aliases)

38
Data Dictionary
Data dictionary is a metadata
Created in parallel with DFD
Created in top-down approach
Data dictionary should be kept up-to-date with
the DFD model

39
Advantages of Data Dictionary
Documentation for the whole system
Eliminate redundancy in a system which has been
created by different people
Identify aliases
Provide a starting point to develop reports and
screens
Validates the data flow diagrams for
completeness and accuracy
Develop the logic for DFD processes

40
Element of Data Dictionary
Name
 primary name for each data or control item, data store, or
external entity
Alias
 alternate names for each data object
Where-used/how-used
 listing of processes that use the data or control item and
how it is used
 input to process
 output from process
 as a store
 as an external entity
Content description
 notation for representing content
Supplementary information
 other data type information, preset values, restrictions, 41
Using the Data Dictionary
 Data dictionaries may be used to:
Create reports, screens, and forms.
Generate computer program source code.
Analyze the system design for completion and
to detect design flaws.

42
Automatic Data Dictionary
Using CASE tools:
Easy to change and add
Created and integrated with other models
Checks that the DFD is valid
 e.g. all data needed for a process is input to it
 Data store contains data input/ output to/from it
 Derived data should be output from process
 Checks data source and destination in DFD

Use data structures to create reports and


screens

43
Thank You

44

You might also like