Summary Notes on Software Design
1. Software design: what is design, why need and good design
2. Design versus programming
3. Architectural and detailed designs
4. Some general comments
5. Principal design methodologies
6. Functional decomposition
7. Data flow
8. Data structure
9. Programming calculus
10. Object oriented
1. Software Design

What is design: It is the process of converting a problem specification into a plan for an algorithm-specific or computerspecific solution.
Design
Problem
Spec
Algorithmic-specific
Or
Computer-specific
solution
It is a thought intensive process: it is not possible to come up with a solution which is applicable to all situations.


Why design: to accomplish the following
-
control complexity
-
achieve system quality
-
reduce testing cost
-
reduce evolution cost (repair, adapt, enhance)
What is a good design
-
easy to understand
-
flexible
There are many “concepts” and “measures” associated with the process of design – (e.g., information hiding, abstraction,
cohesion, cyclomatic number); we will discuss several of these later.
2. Design versus programming
Design
-
abstraction from the task situation
-
discovering structure of the problem
-
devising overall system structure to match needs
-
making global decisions to achieve desired solution quality
-
establishing boundaries between subsystems.
Programming

-
devising concrete representation for information
-
forming precise algorithms
-
taking care of housekeeping details
-
forming syntactically correct programs
Design to programming is a continuum and it is not always possible to draw a sharp line between the two activities.
Reqts. Defi

Programming activity faces the
Specifications
Architectural design
machine- and hence is influenced
Detailed design
by the characteristics of the machine
Executable code
Representation
Level
3. Architectural and detailed design
Architectural design



-
problem structure is reorganized via analysis of the problem
-
design structure is devised to fit it
-
major parts are defined and their relationships established
specifications
general context of
desired system
Architectural design
knowledge of small
Structural
description of
system
similar systems
Input
Output
Detailed design
Blueprints for programs and data structures are prepared


Architectural
descriptions
Programming environment
Detailed Design
(abstraction, elaboration,
choice of alternatives)
Blueprints for
programs
details
Input
Output
4. Some General comments
The history of software design is filled with design methodologies and tools. These methodologies can be grouped according to the
principal concept emphasized.
(a) Procedural Emphasis: Sees a system in terms of flow-of-control or procedures.
-Flowcharting method
(b) Control-Flow_Limitation_Emphasis: Restriction of control flow figures to those of sequence, selection, selection and iteration,
all of which are single-entry and single-exit. It is a refinement of the procedural emphasis.
- Structured Programming Method
(c) Invocation Emphasis: Sees a system in terms of separately compiled modules invoking one another.
-
Modular Programming Method
-
Bottom-up Programming
(d) Functional Decomposition Emphasis: Views a system as a procedural unit (or function) which is divisible into subordinate
functions which are in turn sub-divisible.
-
Top-down Design Method
-
Functional Decomposition Method
-
Softech Design Method
-
Step-wise Refinement Method
(e) Data Flow Emphasis: Basically similar to functional decomposition but decomposition is with respect to data flow.
-
Constantine’s Structured Design Method
-
Myer’s Composite Design Method
(f) Data-Structure Emphasis: Sees a system in terms of time-ordered data relationships in the form of tree-structures. Programs are
built around these data structures.
-
Warnier/Orr Logical Construction of Programs (LCP) Method
-
Jackson Design Method
(g) Formal Emphasis: Constructing a formal proof should go hand in hand with the construction of the program.
-
Dijkstra’s programming calculus (programming calculus because depends on formal methods: mathematics, logic)
-
Program proving
(h) OOD

The system is considered to be a set of objects which interact with each other in order to perform the required computations.
Here, object is an entity which has actions defined on it and which requires actions of other.

Other methods are primarily imperative, indicating authority or command in nature, and deal with the actions that need to be
performed in order to satisfy a function or process (transform). By being data oriented, this method differs from other methods
which are all essentially process-oriented even when using data flow or data structure to aid in identifying the process and
their forms.
5. Principal Design Methodologies ( no on method is adhered to in real world)

Functional decomposition

Data flow

Data structure

Object oriented
Functional Decomposition:
It is a top-down approach (not a method, but a collection of methods) involving the following steps. It has been around since the dawn
of civilization (trial and error, divide and conquer); software designers have formalized and synthesized these approaches.
(i) State clearly the system functions or the problem to be decomposed
(ii) Divide, connect and check the intended system function by re-expressing it as an equivalent structure of properly connected
subfunctions-each solving part of the problem.
(iii) Divide, connect and check subfunction for enough to feel comfortable.
- The above process is also known as stepwise refinement. Amongst the proponents of various forms of functional decomposition
design approach people are such as Dijkstra, Wirth, Parnas, Mills, Baker and Liskov
Although generally applicable, it suffers from a major problem of “what to decompose wrt”. Depending upon the choice of what,
various types of cohesion are achieved, e.g.,

Decomposition wrt time order results in temporal cohesion, and decomposition wrt data flow results in sequential cohesion.

Clustering functions that access a shared data base results in communicative cohesion. Finally, decomposition around a
flow chart results in logical cohesion.
Because of these considerations, this method tends to result in unpredictability and variability of designs.
SYSTEM
FUNCTION TO
BE DECOMPOSED
AGGREGATE
INPUT DATA
AGGREGATE
SYSTEM OUTPUT
(A) TOP LEVEL
EXTERNAL
INPUT
FIRST DO
THIS FUNCTION
EXTERNAL
OUTPUT
INTERNAL DATA FLOW
EXTERNAL
INPUT
NEXT DO
THIS FUNCTION
EXTERNAL
OUTPUT DATA
INTERNAL DATA FLOW
EXTERNAL
INPUT
FINALLY DO
THIS FUNCTION
INFORMATION FEEDBACK
(B) FIRST LEVEL DECOMPOSITION
FUNCTIONAL DECOMPOSITION DIAGRAM
EXTERNAL
DATA OUTPUT
6. Data Flow/Structured Design
Basically data flow design is nothing but functional decomposition wrt data flow. The approach was proposed by L.
Constantine and has appeared under different names:

Transform-centered design: proposed by L. Constantine and extended by Ed Yourdon.

Structured-design: Yourdon and Constantine.

Composite design – G Myers.
Basic Steps
(a) Model the system as a data floe graph (DFG) or data flow diagram (DFD).
(b) Identify the input, output and central transform elements (central transform is located between DFG’s most abstract input and
the most abstract output).
(c) Factor the input, output and central transform branches to form a hierarchical program structure i.e., structure chart showing
how modules are called.
(d) Refine and optimize.
Note – a program modeled as a DFG results in a network of programs – not a hierarchy. Yourdon and Constantine solve this problem
by “picking” in the middle and letting the input and output data streams “hang-down” from the middle. At each level a structure part
in one of the input or output data streams can be factorized into a “get” module, a “transform” module and a “put” module. The
hierarchy is formed by an appropriate linking and the result is pictured by a structure chart.
transform center
internal
representation
and form
afferent
path
efferent
path
outside
world
input data “ends”
output data “ends”
Further note that:
The “hierarchical model” is rather superficially imposed on the problem in this approach and this violates the principle of
correspondence (the degree to which the program model corresponds to the real world).
Example

A
DFG
B
C
D
1
2
3
A
Means
A that: data input A becomes
A data output B
data B becomes data C
data C becomes data D
transform the above DFG into a hierarchial form as follows:
Some Comments
- Structural Design is a set of techniques or concepts, none of which is really new. These people have brought these together to form a
consistent approach.
- Bubble flow – like assembly line where parts are flowing and there are situations where these are being tested.
data flow
→
0 transformations
Structure chart
- modules
- how called

Transform analysis
Strategies for analyzing the structure of

Transaction analysis
DFD and deriving the system structure
7. Data Structure Design
Developed simultaneously by M. Jackson (England 1976) and J. Warnier (France 1978). This approach views the program in terms of
its data structures. A correct model of the data structures is then transformed into a set of structure parts that incorporate a correct
model of the original problem.
Jackson claims that two designers solving the same problem will essentially come up with the same program structure using data
structure design. Thus, it satisfies the principle of consistency.
Basic steps (JSD steps; Warnier’s approach is somewhat different)
(a) Define the data structures to be processed from the problem environment.
(b) Derive a program structure based on the data structures.
(c) Derive the tasks to be performed in terms of the elementary operations available and allocate each of these operations to
suitable components of the program structure.
Relationship between different levels of each resulting hierarchy tends to be “is composed of” relationship - it is a static relationship
and does not change during execution.
Structure clash: A structure clash occurs when the data structures to be processed by a program are in some sense not synchronized
(e.g., the input file is sequenced by employee-name and the output file is sorted on salary rate). Jackson’s solution is to create an
intermediate file, which may be costly, or use a process known as “program inversion” – conversion of one structure processor into a
subroutine for the other.