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

Lec 6 - Data and Process Modeling

The document outlines the concepts and tools of data and process modeling, including data flow diagrams (DFDs), data dictionaries, and process descriptions. It explains the importance of creating logical models during the requirements modeling process and provides guidelines for drawing DFDs, documenting data elements, and using process description tools. Additionally, it discusses the relationship between logical and physical models in system analysis.

Uploaded by

nadi59032
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)
3 views

Lec 6 - Data and Process Modeling

The document outlines the concepts and tools of data and process modeling, including data flow diagrams (DFDs), data dictionaries, and process descriptions. It explains the importance of creating logical models during the requirements modeling process and provides guidelines for drawing DFDs, documenting data elements, and using process description tools. Additionally, it discusses the relationship between logical and physical models in system analysis.

Uploaded by

nadi59032
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/ 25

System Analysis and Process

Integration
BAem 414
Data and Process Modeling
Learning Objectives
• Describe data and process modeling concepts and tools, including data flow
diagrams, a data dictionary, and process descriptions
• Describe the symbols used in data flow diagrams and explain the rules for their use

• Draw data flow diagrams in a sequence, from general to specific

• Explain how to level and balance a set of data flow diagrams

• Describe how a data dictionary is used and what it contains

• Use process description tools, including structured English, decision tables, and
decision trees
• Describe the relationship between logical and physical models
Introduction

• During the requirements modeling process described in previous lecture, fact-finding


techniques were used to investigate the current system and identify user
requirements.
• This lecture and the next one explain how that information is used to develop a
logical model of the proposed system and document the system requirements.
• A logical model shows what the system must do (Functional requirements),
regardless of how it will be implemented physically.
• Later, in the systems design phase, a physical model is built that describes how the
system will be constructed.
• Data and process modeling involves three main tools: data flow diagrams, a data
dictionary, and process descriptions.
DATA FLOW DIAGRAMS (DFD)

• A DFD shows how data moves through an information system but does not show
program logic or processing steps.
• A set of DFDs provides a logical model that shows what the system does, not how
it does it.
• DFDs use four basic symbols that represent processes, data flows, data stores, and
entities.
• Several different versions of DFD symbols exist, but they all serve the same
purpose.
DFD symbols - Process Symbol
The symbol
represent data that the for an entity is a
system stores because
Gane and Sarson

rectangle,
one or more processes which a may
path be
forshaded
data to
need to use the data at to move
make from
BANK
a later time Black hole
APPLY it lookone part of the
three-dimensional.
STUDENT
DEPOSIT
PAYMENT Black Box information
system to
another.
Spontaneous
generation.
Process Data Flow Data Store External
Gray hole.
Entry
Yourdon

APPLY BANK
PAYMENT DEPOSIT STUDENT
Guidelines For Drawing DFDs

When drawing a context diagram and other DFDs,


these guidelines should be followed:
• Draw the context diagram so it fits on one page
• Use the name of the information system as the
process name in the context diagram.
• Use unique names within each set of symbols.
• Do not cross lines.
• Provide a unique name and reference number
for each process
• Obtain as much user input and feedback as
possible
Creating A Set Of DFDs

• STEP 1: Draw a context diagram

• STEP 2: Draw a diagram 0 DFD

• STEP 3: Draw the lower-level diagrams


STEP 1: Draw A Context Diagram

• A context diagram is a top-level view of an STUDENT FINAL SUBMETT


information system that shows the system’s RECORD GRADE ED WORK
STUDENT
S
boundaries and scope. SYSTEM

0
• Start by placing a single process symbol in CLASS
ROSTE GRADED
the center of the page. The symbol R GRADIN WORK
G
represents the entire information system, SYSTEM
and it is identified as process 0.
GRADING GRADE
PARAMETER’
• Then place the system entities around the S
REPOR
T

perimeter of the page and use data flows to


connect the entities to the central process. INSTRUCTO
R
STEP 2: Draw A Diagram 0 DFD
• Diagram 0 provides an overview of all the
components that interact to form the overall
system.
• It zooms in on the system and shows major
internal processes, data flows, and data stores.
• Diagram 0 also repeats the entities and data
flows that appear in the context diagram.
• When the context diagram is expanded into
DFD diagram 0, all the connections that flow
into and out of process 0 must be retained.
• A functional primitive is a process that consists
of a single function that is not exploded further
STEP 3: Draw The Lower-level
Diagrams
• To create lower-level diagrams, leveling and balancing techniques must be used.

• Leveling is the process of drawing a series of increasingly detailed diagrams, until


all functional primitives are identified.
• Leveling is also called exploding, partitioning, or decomposing.

• Balancing maintains consistency among a set of DFDs by ensuring that input and
output data flows align properly.
• Balancing ensures that the input and output data flows of the parent DFD are
maintained on the child DFD.
Data Dictionary

• A data dictionary, or data repository, is a central storehouse of information about


the system’s data.
• An analyst uses the data dictionary to collect, document, and organize specific facts
about the system, including the contents of data flows, data stores, entities, and
processes.
• The data dictionary also defines and describes all data elements and meaningful
combinations of data elements
• A data element is the smallest piece of data that has meaning within an information
system.
Documenting the Data Elements
• The following attributes usually are recorded and described in the data dictionary:
• Data element name or label.
• Alias.
• Type and length.
• Default value.
• Acceptable values.
• Source.
• Security and permission.
• Responsible user(s).
• Description and comments.
Documenting the Data Flows

The typical attributes that describe the data flows are as follows:
• Data flow name or label.

• Description.

• Alternate name(s).

• Origin.

• Destination.

• Record.

• Volume and frequency.


Documenting the Data Stores

Typical characteristics of a
data store are as follows:
• Data store name or label

• Description.

• Alternate name(s).

• Attributes.

• Volume and frequency.


Documenting the Processes

The following are typical


characteristics of a process:
• Process name or label.

• Description.

• Process number.

• Process description.
Documenting the Entities

• Typical characteristics of an entity include the following:

• Entity name.

• Description.

• Alternate name(s).

• Input data flows.

• Output data flows.


Documenting the Records

• A record is a data structure that


contains a set of related data
elements that are stored and
processed together.
• Typical characteristics of a record
include the following:
• Record or data structure name.

• Definition or description.

• Alternate name(s).

• Attributes.
Data Dictionary Reports

• The data dictionary serves as a central storehouse of documentation for an information system.
• A data dictionary is created when the system is developed, and is updated constantly as the
system is implemented, operated, and maintained.
• In addition to all mentioned components, data dictionary documents the relationships among
these components.
• Many valuable reports can be obtained from a data dictionary, including the following:
• An alphabetized list of all data elements by name
• A report describing each data element and indicating the user or department that is
responsible for data entry, updating, or deletion
• A report of all data flows and data stores that use a particular data element
• Detailed reports showing all characteristics of data elements, records, data flows,
processes, or any other selected item stored in the data dictionary
Process Description Tools

• A process description documents the details of a functional primitive and


represents a specific set of processing steps and business logic.
• Using a set of process description tools, a model is created that is accurate,
complete, and concise.
• Typical process description tools include structured English, decision tables, and
decision trees.
• This lecture deals with structured analysis, but the process description tools can
also be used in object-oriented development, which is described in upcoming
lectures
Modular Design
• Typical process description tools include structured
English, decision tables, and decision trees.
• Modular design is based on combinations of three logical
structures, sometimes called control structures, which
serve as building blocks for the process.
• Sequence. The completion of steps in sequential
order, one after another. One or more of the steps
might represent a subprocess that contains additional
logical structures.
• Selection. The completion of one of two or more
process steps based on the results of a test or
condition.
• Iteration. The completion of a process step that is
Structured English

• Structured English is a subset of standard English


that describes logical processes clearly and
accurately.
• When using structured English, be mindful of
the following guidelines:
• Use only the three building blocks of
sequence, selection, and iteration.
• Use indentation for readability.
• Use a limited vocabulary, including standard
terms used in the data dictionary and
specific words that describe the processing
rules.
Decision Tables

• A decision table is a logical structure that shows every combination of conditions


and outcomes.
• Analysts often use decision tables to describe a process and ensure that they have
considered all possible situations.
1. Tables with one condition: If a process has a single condition, there only are
two possibilities — yes or no.
2. Tables with two
Are the conditions:
hours greater the process
than 40?description contains two conditions:
IfIfboth
so,conditions are met, the function
the calculation is made. is accepted. Otherwise,
Otherwise, thenot.
it is it is
rejected
3. Tables with three conditions
Decision Trees

• A decision tree is a graphical representation of the conditions, actions, and rules


found in a decision table.
• Decision trees show the logic structure in a horizontal form that resembles a tree
with the roots at the left and the branches to the right.
• Decision trees and decision tables provide the same results, but in different forms.
Logical Versus Physical Models

• While structured analysis tools are used to develop a logical model for a new
information system, such tools can also be used to develop physical models of an
information system.
• A physical model shows how the system’s requirements are implemented.

• To understand the relationship between logical and physical models, think back to
the beginning of the systems analysis phase.
• Many analysts follow a four-model approach, which means that they develop a
physical model of the current system, a logical model of the current system, a
logical model of the new system, and a physical model of the new system.
Q/A

You might also like