Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
51 views

Program Design: Mostafijur Rahman Akhond Lecture, CSE BRAC University

The document discusses program design which involves determining programs to write and creating instructions for programmers. It covers moving from logical to physical data flow diagrams, designing programs using structure charts, and developing detailed program specifications. Structure charts show program components hierarchically and design guidelines include high cohesion, fan-in, and low fan-out to create modular, reusable programs. Program specifications provide explicit instructions for coding specific program pieces.

Uploaded by

kaosar alam
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
51 views

Program Design: Mostafijur Rahman Akhond Lecture, CSE BRAC University

The document discusses program design which involves determining programs to write and creating instructions for programmers. It covers moving from logical to physical data flow diagrams, designing programs using structure charts, and developing detailed program specifications. Structure charts show program components hierarchically and design guidelines include high cohesion, fan-in, and low fan-out to create modular, reusable programs. Program specifications provide explicit instructions for coding specific program pieces.

Uploaded by

kaosar alam
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

Program Design

Ref: Whitten et all, Systems Analysis and Design Methods 7e. McGraw-Hill Higher Education

Mostafijur Rahman Akhond


Lecture, CSE
BRAC University
Outline

●Moving from logical to physical process models.


●Designing programs.
●Structure chart.
●Program specification.

2
Introduction
● Program design – Analysts determine what programs will be written and create
instructions for the programmers.
● Various implementation decisions are made about the new system (e.g., what
programming language(s) will be used.)
● The DFDs created during analysis are modified to show these implementation
decisions, resulting in a set of physical data flow diagrams.
● The analysts determine how the processes are organized, using a structure
chart to depict the decisions.
● Detailed instructions called program specifications are developed.

3
Steps to Create the Physical Data
Flow Diagram

4
Physical DFD Example

5
Logical to Physical dfd

Logical Model of the Promote Tunes Process


Physical Model for Promote Tunes Process

6
Structure Chart

▪ The structure chart is an Important program


design technique that help the analyst design
the program.
▪ It shows all the components of code in a
hierarchical format that implies
– Sequence (in what order components are
invoked),
– Selection (under what condition a module is
invoked),
– Iteration (how often a component is repeated)
7
An academic system needs a program that will print a listing of students along with their
grade point averages (GPAs), both for the current semester and overall. First, the program
must retrieve the student grade records; then it must calculate the current and cumulative
GPAs; finally, the grade list can be printed.

8
Structure chart notions

9
Structure chart notions (2)

10
Revised Structure chart

11
12
Design Guidelines

▪ High quality structure charts result in


programs that are modular, reusable,
and easy to implement.
▪ Measures of good design include
– cohesion,
– appropriate levels of fan-in and fan-out.

13
Build Modules with High Cohesion

● Cohesion refers to how well the lines of code within each module relate to
each other.

● Cohesive modules are easy to understand and build because their code
performs one function effectively.

● There are various types of cohesion.

Functional cohesion – all elements of the modules contribute to


performing a single task.

Temporal cohesion – functions are invoked at the same time.

Coincidental cohesion – there is no apparent relationship among a


module’s functions.
14
15
Cohesion Decision Tree

16
Create High Fan-In
● 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.
- This is a good situation because high fan-in indicates that a
module is reused in many places on the structure
chart.

17
Avoid High Fan-Out
• fan-in is call by other modules.
• fanout is call from that module.

• A large number of subordinates associated with a single control


should be avoided.
• The general rule of thumb is to limit a control module’s
subordinates to approximately seven for low fan-out.

18
Examples of Fan-in and Fan-out

19
Check list for structure chart quality

20
Program Specification
• Program Specifications are documents that include explicit
instructions on how to program pieces of code.
• There is no formal syntax for program specification.
• Four components are essential for program specification:
- Program information;
- Events;
- Inputs and outputs; and
- Pseudocode – a detailed outline of lines of code that need to
be written.
- Additional notes and comments can also be included.

21
22
Pseudocode Example

23
Summery

Moving from logical to physical process models.


- Physical DFDs show implementation details.
Structure chart.
- The structure chart shows all of the functional
components needed in the program at a high level.
Building structure chart.
- Module, control connection, couples, review.
Structure chart design guidelines.
- Cohesion, coupling, and fan-in/fan-out.
Program specifications.
- Program specifications provide more detailed instructions
to the programmers.

24

You might also like