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

Structured Analysis and Design Process Modeling: Decomposition Diagram Structure Chart

The document discusses structured analysis and design techniques, specifically process modeling using decomposition diagrams and structure charts. It provides an overview of how decomposition diagrams break down activities hierarchically and how structure charts model system structure using modules. Key points include that decomposition diagrams show functional breakdown without sequence, and structure charts describe program functions and subfunctions through modules.

Uploaded by

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

Structured Analysis and Design Process Modeling: Decomposition Diagram Structure Chart

The document discusses structured analysis and design techniques, specifically process modeling using decomposition diagrams and structure charts. It provides an overview of how decomposition diagrams break down activities hierarchically and how structure charts model system structure using modules. Key points include that decomposition diagrams show functional breakdown without sequence, and structure charts describe program functions and subfunctions through modules.

Uploaded by

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

Structured Analysis and Design

PROCESS MODELING
Decomposition Diagram
Structure Chart

ISTM 6201
Lecture 1-A
Subhasish Dasgupta
The Decomposition Diagram

• Illustrates the breakdown of activities in


the functional area to be automated 0 MANAGE
• Uses a tree-structured diagram to PERSONNEL

document the hierarchical breakdown


• Does not show sequence
• Shows the functional breakdown, not the 1 2 3
organizational structure HIRE ADMINISTER TERMINATE
EMPLOYEE EMPLOYEE EMPLOYEE
• Processes are supported by narrative
descriptions
• Can be used either to understand the
business processes or to model the system

1.1 1.2 1.3 1.4


REVIEW CONDUCT SELECT PREPARE
RESUME INTERVIEW CANDIDATE OFFER
Decomposition Diagram

• Each component
ROOT
shown is a block PROCESS

– A parent is composed OFFSPRING

of offspring
PARENT
– The offspring describe PROCESS

the parent process


• The top (parent)
process of the
decomposition
diagram is the root CHILD
PROCESS
CHILD
PROCESS
process
Structure Chart - Design Phase

• Elementary (lowest-level)
A
processes become
system modules
• Hierarchical format is
used to model the B C
system structure in
modules
• Each module is described
by process logic in the X Y
form of pseudo-code
• Modules call modules
PROCESS-DATA MODELING

Data Flow Diagrams


Introduction
• Data flow diagram
– is a graphical tool that analysts to depict the flow of data
in an information system
– the system can be physical or logical, manual or computer-
based
– data flow diagram is one form of a process model
(explained next)
Process Modeling
• Process modeling involves graphically representing the
functions, or processes, which capture, manipulate, store,
and distribute data between a system and its environment
and between components of a system.
• A data flow diagram (commonly known as a DFD) is a type of
process model.
Requirements Structuring
• Requirements Structuring refers to the meaningful
representation of an information system. This involves
representation of:
– the existing system
– the replacement system
Requirements Structuring
Requirements structuring involves the following:
• data flow within the system
• processing logic and timing of events
• structure of data within the system
Deliverables from Process Modeling
• A context diagram which provides the scope of the system
• DFD of the current physical system specify which people and
technologies are used in which processes to move and
transform data
• technology-independent or logical, dfds of the current system
Data flow diagramming mechanics
• Four symbols used
• Two standard sets of data flow symbols
– Gane and Sarson
– DeMarco and Yourdon
DFD symbols
• Data flow
– data in motion, moving from one part of a system to
another
• Data Store
– data at rest
– physical locations include a file folder or a computer based
file
DFD Symbols
• Process
– is the work or actions performed on data so that they are
transformed, stored, or distributed
• Source/Sink
– is the origin and/or destination of the data. Source/sinks
are sometimes referred to as external entities because
they are outside the system
DfD symbols- conventions
Process - Data Transform
• Transforms inputs into outputs
B • Should clearly represent the
A transformation which it performs
• Represents the functional
requirements of a system
• One for each process on the
Decomposition Diagram
VALIDATE • Named with a single verb and
ORDER
DATA object
• Name should be crisp and
descriptive (Avoid “Process Input”
C
or “Analyze Results”)
• If you cannot name it easily, you
have probably partitioned it
improperly
Data Flow
• Packet of information
• Input or output of a process
• Data “in motion” between
CUSTOMER ORDER
processes
• Corresponds to an attribute or
group of attributes
• All parts of the packet must
move together in the system
• Named with a noun and
adjective combination
• May be decomposed
Data Store
B
• Data packets “at rest”
A
• Storage place for data (no
processing is performed)
CUSTOMER
• Connected to processes by
data flows
• Corresponds to entity (or
group of entities) on the
ERD
• Named with a singular
noun; must be crisp and
descriptive
External Agent

• External person, organization,


or system
• Provides data to or receives
CUSTOMER SERVICE data from the process/system
MANAGER
• Ultimate source or sink of data
for the system
• Defines interfaces to and from
the application
• Relationships between External
Agents are not shown
• Named with a proper noun
Constructing DFD - The Context Diagram
• The context diagram is the highest-level view of the system -
provides an overview of a system that shows the system
boundaries, external entities that interact with the system,
and the major information flows between the entities and the
major information flows between entities and the system
Context Diagram: Example- Hoosier Burger’s Food Ordering System
The Context Diagram

• One and only one process


• External agents (sources and sinks) around the perimeter
• External data flows also on the perimeter
• Data flows between system sources/sinks
• The single process, labeled “0,” represents the entire system
The level - 0 Diagram
• A data flow diagram that represents a system’s major
processes, data flows, and data stores at a high level of detail.
• Each process has a number which ends in .0 (corresponding to
the level number of the DFD)
Level – 0 Diagram: Example- Food Ordering System
Level – 1 Diagram: Decomposition of Process 1
Level – 1 Diagram: Decomposition of Process 4
Level – 2 Diagram: Decomposition of Process 4.3
Balancing DFDs
• Inputs and outputs to a process should be should be
conserved at the next level of decomposition.
• Process 1.0 which appears in a level-0 diagram, must have the
same inputs and outputs when decomposed into a level-1
diagram.
• Conservation of inputs and outputs is called balancing.
Eight Rules for Drawing Data Flow Diagrams
• Establish the context of the DFD by identifying all of the input and output
data flows.
• Select a starting point for drawing the DFD: from Inputs, from Outputs, or
from the Center out.
• Give meaningful labels to all data flows.
• Label all processes with action verbs that relate input and output data
flows.
• Omit insignificant functions routinely handled in the programming process.
Example: initialization and termination details.
• Do not include control information or control of flow information.
Example: “read next record”.
• Try to plan for the number of levels. Don’t put too much on one DFD.
• Be prepared to start over. False starts are to be expected.
Structured Design Models
Automation System Boundary

• Partitions data flow processes into manual and


automated systems
• Processes can be inside or outside boundary
• Data flows can be inside and outside of boundary
System Flowchart

• Representation of various computer programs, files,


databases, and associated manual processes
• Graphically describes organization of subsystems
• Can show type of system
– Batch
– Real time
Common System Flow Chart Symbols
System Flow Chart
Structure Chart

• Describes functions and subfunctions of each part of


system
• Shows relationships between modules of a computer
program
• Simple and direct method
– Each module performs a specific function
– Each layer in a program performs specific activities
Components of a Structure Chart
• Module
• Data couple
• Flag
Structure Chart Basics
• There is a single coordinating module at the
root
• Modules below the root are called by the
coordinating module
• Each module is represented as a rectangle
containing a descriptive name of its function.
Data couples and flags

Get grade

A B C Error calculating C

Calculate grade

A= grade for course 1; B=course 2 grade; C= semester grade


Structure Chart Symbols
Structure Chart for
Entire Payroll Program
Developing a Structure Chart

• Transaction Analysis
– System flow chart and event table inputs
– Upper-level modules developed first
– Identifies each transaction supported by program

• Transform Analysis
– Computer program ‘transforms’ inputs into outputs
– Structure charts have input, calculate, and output
subtrees
– Uses DFD fragments for inputs
Steps to Create a Structure Chart
from a DFD Fragment (lower-level DFD)

• Determine primary information flow


• Find process that represents most
fundamental change from input to output
• Redraw DFD with inputs to the left and
outputs to the right
• Generate first draft structure chart
Steps to Create a Structure Chart from a
DFD Fragment (Continued)

• Add other modules


– Input
– Data storage
– Output

• Add logic from structured English or


decision tables
• Make final refinements
Quality of Structure Chart

• Module coupling
– Measure of how module is connected to other modules in
program

• Module cohesion
– Measure of internal strength of module
– Module performs one defined task

• Highly cohesive and loosely coupled modules are


desirable
Module Algorithm Design: Pseudocode

– Describes internal logic of software modules


– Variation of structured English that is closer to
programming code
– Syntax should mirror development language

You might also like