Chapter 9
Moving to Design
The Structured Approach To
Designing The Application
Architecture
• Module-an identifiable component of a computer
program that performs a defined function
• Computer program—a set of modules that are
compiled into a single executable entity
• System flowchart– a diagram that describes the
overall flow of control between computer
programs in a system
• Pseudocode– structured-programming-like
statements that describe the logic of a module
The Automation System
Boundary
• Partitions the data flow diagram processes into
manual and automated processes
• Processes outside the system boundary are manual
processes (eg., enter customer orders, inspect
reports, etc)
• Processes that are inside the system boundary may
be carried out on-line or in batch mode
• data flows are found inside, outside, or crossing
the system boundary and the program boundaries.
• Data flows that cross the system boundary
represent input and outputs of the system.
The System Flowchart
• Process or program
• File of Database
• Document or report
• File on Magnetic tape
• Input of output screen display
System Flowchart
• Manual Operation
• Communication between components
• Communication Link
The Structure Chart
• A hierarchical diagram showing the relationships
between the modules of a computer program
• Program call—the transfer of control from a
module to a subordinate module to perform a
requested service
• Data couples –the individual data items that are
passed between modules on a program call
Developing a Structure Chart
• Transaction analysis—the development of a
structure chart based on a DFD that describes the
processing for several types of transactions
• Transform analysis –the development of a
structure chart based on a DFD that describes the
input-process-output data flow
• Afferent data flow –incoming data
• Efferent data flow– outgoing data flow
• Central transform – set of DFD processes that are
located between the input and output processes.
Evaluating the Quality of a
Structure Chart
• Module coupling –the manner in which
modules relate to each other (data coupling
is preferred)
• Module cohesion – a measure of the internal
strength of the module
It is most desirable to have highly cohesive
and loosely coupled modules
Coupling
• A measure of how a module is connected to
the other modules in the program
• Objective– make the modules as
independent as possible.
Cohesion
• The degree to which all of the code within a
module contributes to implementing one welldefined task.
• Modules that implement a single task tend to have
relatively low coupling because all of their
internal code acts on the same date item(s)
• A flag passed down the structure chart is also an
indicator of poor cohesion in the low-level
module.
The Object-Oriented Approach