Program

Design
Week 6 - APSI
 • The application logic for a system will be expressed in
programs that will be written during construction of the
new system.
• Program design is the part of the design phase of the
SDLC during which analysts determine what programs
will be written, create instructions for the
programmers about how the code should be written,
and identify how the pieces of code will fit together to
form a program.
Introduction • Activities involved in program design include:
1. Creating physical Data Flow Diagrams (DFDs) to
make implementation decisions for the new
system, such as selecting the appropriate
programming language(s).
2. Developing structure charts to determine the
organization of the system's processes.
3. Creating program specifications to provide
guidance to programmers regarding what they
should create.
Physical data flow
diagram
The physical data
flow diagram
• The physical DFD contains the
same components as the logical
DFD (e.g., data stores, data
flows), and the same rules apply
(e.g., balancing, decomposition).
• The basic difference between the
two models is that a physical DFD
contains additional details that
describe how the system will be
built.
 Add implementation references.

Steps to Draw a human–machine boundary.

create the Add system-related data stores, data flows, and

physical processes.

DFD Update the data elements in the data flows.

Update the metadata in the CASE repository.

 • The first step in creating a physical DFD is to begin
with the existing logical DFD and add references to
the ways in which the data stores, data flows, and
processes will be implemented.
• Data stores on physical DFDs will refer to files
and/or database tables.
1. Add • Processes refer to programs or human
actions.
implementation • Data flows refer to the physical media for the
data, such as paper reports, bar code
references scanning, input screens, or computer reports.
• The names for the various components on the
physical DFD should contain references to these
implementation details.
• External entities on the DFD are outside of the
scope of the system and therefore remain
unchanged in the physical diagram.
Logicl DFD Physical DFD
Sample physical
process
implementations
 Logical data flow Implementation Sample physical data flow

Physical data
flows (1)
 Logical data flow Implementation Sample physical data flow

Physical data
flows (2)
Physical data
store
2. Draw a human-machine boundary

• The second step is to add a human–machine boundary.

• Physical DFDs differentiate human and computer interaction by a human-
machine boundary, a line drawn on the model to separate human action
from automated processes.
• Every part of every process in the system may not be automated, so it is up
to the project team to determine where to draw a human-machine boundary
and how large to draw it.
• Criteria when drawing the boundary: cost, efficiency, integrity.
3. Add system-related data stores, data
flows, and processes

• The third step is to add to the DFD additional processes, stores, or flows that
are specific to the implementation of the system and have little (or nothing)
to do with the business process itself.
• These additions can be due to technical limitations or to the need for audits,
controls, or exception handling.
Technical • Technical limitations occur when technology
cannot support the way in which the system
is modeled logically.
limitations • For example, suppose that a data store exists
on the logical DFD to hold customer
information, but the database technology
that will be used to build the system cannot
handle the large volume of customers in one
table.
• A physical DFD may need to have two data
stores—one for current customers and one
for old customers—so that the technology
will work properly.
 • Audits, controls, or exception handling refers to
putting checks and balances in place in the
Audits, system in case something goes wrong.
• For instance, consider the search and browse
controls, or processes that we have been working with.
• Suppose that the project team is worried about the
exception transfer of purchase records to the purchase tunes
process.
handling • As a precaution, the team can place a data store
on the physical DFD that captures information
about each batch of records that is sent to the
purchase tunes process.
• In this way, if problems were to occur, there
would be a history of transactions that could be
examined or used for backup purposes.
4. Update the • The fourth step is to update the elements in
the data flows.

data • The data flows will appear to be identical in

both the logical and physical DFDs, but the
elements in physical data flows may contain additional
system-related data elements, for reasons

the data similar to those described in the previous

section.

flows • During step 4, the physical data elements are

added to the metadata descriptions of the
data flows in the CASE repository.
 • Finally, make sure that the information
about the DFD components in the CASE
5. Update the repository is updated with
implementation-specific information.
metadata in • This information can include when batch
the CASE processes will be run and how often,
names of the actual tables or files that are
repository represented by data flows, and the sizes
and projected growth rates of the data
stores.
An example of logical and physical DFD
A sample
physical DFD
Structure chart
Designing • Do not jump right into the implementation
phase by coding without much thought or
planning. This can lead to disastrous results,
programs such as inefficient programs, code that does
not work with other code, and a system that
doesn’t do what it’s supposed to do.
• Take time in the design phase to create a
maintainable system.
• Create a design that is modular and flexible-
using a top-down modular approach.
A modular approach in
directing someone to
your house
• First, drive from your house
to the highway.
• Then, drive from the
highway to the appropriate
exit.
• Next, locate my
neighbourhood.
• Finally, drive to my house.
Good program design

Create structure chart, a high-

level diagram, that shows the Write program specifications
various components of a describe exactly what needs to
program, how the components be included in each program
should be organized, and how module.
the components interrelate.
 • The structure chart is an important technique
that helps the analyst design the program for
the new system.
• The structure chart shows all the components of
code that must be included in a program at a
high level, arranged in a hierarchical format
that implies sequence (in what order
Structure chart components are invoked), selection (under what
condition a module is invoked), and iteration
(how often a component is repeated).
• The components are usually read from top to
bottom, left to right, and they are numbered by
a hierarchical numbering scheme in which
lower levels have an additional level of
numbering (e.g., the third level of modules
would be numbered 1.1.1, 1.1.2, 1.1.3... ).
Structure chart
example of GPA
Syntax

Module Couples
 • A structure chart is composed of modules (lines of
program code that perform a single function) that
work together to form a program
• The modules are depicted by a rectangle and
connected by lines, which represent the passing of
control.

Module (1) • A control module is a higher-level component that

contains the logic for performing other modules,
and the components that it calls and controls are
considered subordinate modules.
• At times, modules are reused. These modules,
called library modules, have vertical lines on both
sides of the rectangle to communicate that they
will appear several times on the structure chart.
 • The lines that connect the modules communicate
the passing of control.
• There are two symbols that describe special types
of control that can appear on the structure chart.
• The curved arrow, or loop, indicates that the
execution of some or all subordinate modules is
repeated, and
• A conditional line (depicted by a diamond) denotes

Module (2)
that execution of one or more of the subordinate
modules occurs in some cases but not in others.
• Structure charts can become quite unwieldy,
especially when they depict a large or complex
program.
• A circle is used to connect parts of the structure chart
when there are space constraints and a diagram needs
to be continued on another part of the page (i.e., an
on-page connector), and
• A hexagon is used to continue the diagram on another
page entirely (i.e., an off-page connector).
Couples

• Couples, shown by arrows, are drawn on the structure chart to show that
information is passed between modules, with the arrowhead indicating which way
the information is being sent.
• Data couples, shown by arrows with empty circles, are used to represent the
passing of pieces of data or data structures to other modules.
• Control couples, drawn with the use of arrows with filled-in circles, are used to
pass parameters or system-related messages back and forth among modules.
• In general, control flags should be passed from subordinates to control modules, but
not the other way around.
• The presence of couples signals that modules on the structure chart depend on each
other in some way.
 Structure chart element Purpose Symbol

Structure chart
elements (1)
 Structure chart element Purpose Symbol

Structure chart
elements (2)
Revised
structure chart
example of GPA
 • Process models are used as the starting point for
structure charts.
• There are three basic kinds of processes on a process
model: afferent, central, and efferent.

Building the • Afferent processes are processes that provide

inputs into the system.

structure
• Central processes perform critical functions in the
operation of the system
• Efferent processes deal with system outputs.
chart • Each process of a DFD tends to represent one module
on the structure chart, and if levelled DFDs are used,
then each DFD level tends to correspond to a different
level of the structure chart hierarchy (e.g., the process
on the context-level DFD would correspond to the top
module on the structure chart).
 Transform
and
transaction
structures
Transaction structure
• The transaction structure is used when each
module performs one of a group of
individual transactions.
• This transaction structure contains a control
module that calls subordinate modules, each
of which handles a particular transaction.
• Transaction structures often occur where the
actual system contains menus or sub-menus,
and they are usually found higher up in the
levels of a structure chart.
• The high levels of the DFD usually represent
activities that belong in a transaction
structure.
Transform structure
• A transform structure has a control module that calls
several subordinate modules in sequence, after
which something “happens.”
• These modules are related because together they
form a process that transforms some input into an
output.
• Often, each module accepts an input from the
module preceding it, works on the input, then
passes it to the next module for more processing.
• The control module describes what the subordinates
will do (e.g., create student grade listing), and the
subordinates are invoked from left to right and
transform the student grade records into two types
of listings for student grades.
• In a levelled DFD, the lowest levels usually represent
transform structures.
 Applying the concepts of building the structure chart
Step 1: Identify modules and levels for the structure chart
Applying the concepts of building the structure chart
Step 2: Add special connection to the structure chart
Applying the concepts of building the structure chart
Step 3: Add couples to the structure chart
Design guidelines

1 2 3 4 5
Build Build loosely Create high Avoid high Assess the
modules with coupled fan-In fan-out chart for
high cohesion modules quality
 • Cohesion refers to how well the lines of code within
each structure chart module relate to each other.
• Ideally, a module should perform only one task, making
it highly cohesive.
Build • The more tasks that a module has to perform, the more
complex the logic in the code must be to implement the
modules tasks correctly.
• Typically, you can detect modules that are not cohesive

with high from titles that have an “and” in them, signalling that
the module performs multiple tasks.

cohesion
• Another signal of poor cohesion is the presence of
control flags that are passed down to subordinate
modules; their presence suggests that the subordinate
has multiple functions from which one is chosen.
• Factoring is the process of separating out a function
from one module into a module of its own.
 Types Definition Example

Types of
cohesion (1)
 Types Definition Example

Types of
cohesion (2)
 • Coupling involves how closely modules are
Build inter-related, and the second guideline for
good structure chart design states that

loosely
modules should be loosely coupled.
• The numbers and kinds of couples on the

coupled structure chart reveal the presence of

coupling between modules.

modules • The fewer the arrows on the diagrams, the

easier it will be to make future alterations to
the program.
 Types Definition Example

Types of
coupling (1)
 Types Definition Example

Types of
coupling (2)
 • Fan-in describes the number of control
modules that communicate with a
subordinate.
• A module with high fan-in has many different
control modules that call it.
• High fan-in indicates that a module is reused
Create high in many places on the structure chart, which
suggests that the module contains well-written
fan-In generic code.
• Fan-in also occurs when library modules are
used.
• Structures with high fan-in improve the
reusability of modules and make it easier for
programmers to recode when changes are
made or mistakes are uncovered, because a
change can be made in one place.
Which structure chart is better?
 • Avoid a large number of subordinates
associated with a single control.
• A control module will become much less
Avoid high fan- effective when given large numbers of
out modules to control.
• The general rule of thumb is to limit a control
module’s subordinates to approximately
seven.
 Which
structure
chart is
better?
 üLibrary modules have been created whenever
possible.
üThe diagram has a high fan-in structure.

Assess the üControl modules have no more than seven

subordinates.

chart for üEach module performs only one function (high

cohesion).

quality üModules sparingly share information (loose

coupling).
üData couples that are passed are actually used by
the accepting module.
üControl couples are passed from “low to high.”
Tugas 3
Buat physical DFD.

Opsional (nilai tambahan): Buat structure chart.

Tugas 1 - 3 dipresentasikan di pertemuan ke-7: system request, use case diagram, context
diagram, logical DFD, physical DFD.

Laporan lengkap tugas 1 - 3 (termasuk hasil revisi) diunggah di IDE paling lambat hari Selasa, 16
April 2024 pukul 17.00: cover (no klpk, NPM, nama), deskripsi perusahaan, system request,
kebutuhan fungsional, diagram konteks dan DFD logis, DFD fisik, structure chart (opsional).