Software Design

CS215 – Software Engineering

Reference: Software Engineering Concepts
Richard Fairley
 Software Design
The process of design involves “conceiving and
planning out in mind and making a drawing,
pattern and sketch of it

Software
Design

External Architectura Detailed

Design l Design Design

Internal Design
 External Design
External Design involves conceiving, planning out, and
specifying the externally observable characteristics of
software product. The external design includes
• User displays and report format
•External data source and sinks
•Functional Characteristics
• Performance requirement and high level process
structure.
 Internal Design
Internal design involves conceiving, planning out and
specifying the internal structure and processing
details of the software. The main aim is to record
•Design decisions
•Indicate why certain alternative and trade-off were
chosen
•Elaborate test plan
•To provide a blue print for implementation, testing
and maintenance activity,
 Internal Design
Outcome of Internal Design are

• Architectural structure
• Details of algorithms and data structures
• Test plan
 Architectural Design
• Concerned with refining the conceptual view of the
system.
• Identifying internal processing functions
• Decomposing high-level functions into sub
functions.
• Defining internal data streams and data stores
• Establishing the relationship and interconnection
between among functions and data streams and
data stores.
 Detailed Design
• includes specification of algorithm that
implement the functions.
• Concrete data structure that implement the
data stores.
• The actual interconnection among the
functions and data structures
• Packaging scheme for system
Phases Analysis Design Implementation

Planning External Coding

Activities and Architectural Debugging
requirement and testing
definition Detailed

Reviews SSR PDR CDR

 Phases in the design process
Requirements
specifica
tion

Design acti
vities

Architectur
al Abstract Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design

Software Data
System Interface Component Algorithm
specifica
tion structure
architectur
e specifica
tion specifica
tion specifica
tion
specification

Design pr
oducts
 Design phases
• Architectural design Identify sub-systems
• Abstract specification Specify sub-systems
• Interface design Describe sub-system interfaces
• Component design Decompose sub-systems
into components
• Data structure design Design data structures to hold
problem data
• Algorithm design Design algorithms for problem
functions
 Design Concepts
• Abstraction
• Structure
• Information hiding
• Modularity
• Concurrency
• Verification
• Design aesthetics
 Abstraction
•Abstraction is the intellectual tool that allow us to
deal with concept apart from their
implementations.
•Abstraction permits the separation of conceptual
aspects from the implementation details.
•Abstraction allow us to organize and channel out
our thought process by postponing the structural
consideration and detailed algorithm details until
the functional characteristics, data streams and
data stores have been established.
 Abstraction Mechanism
• Functional Abstraction
• Data abstraction
• Control abstraction
 Functional Abstraction
• Involves the use of parameterized sub program. The
ability to parameterized a sub program and to bind
different parameter values on different invocations
of the subprogram is a powerful abstraction
mechanism.
• Functional abstraction can be generalized to
selection of sub programs called as groups.
• Some of these subprograms may have visible
property and some may be hidden,
 Data Abstraction
• Involves specifying a data type or data object by
specifying legal operations on them; representation
and manipulation details are suppressed. E.g. for
stack can specify POP, PUSH operation without their
actual implementation.
• Abstract data type are abstract in the sense that the
representation details of the data items and the
implementation detail of functions that manipulate
the data items are hidden within the group that
implements the abstract data type.
 Control Abstraction
• Is used to state a desired effect without
stating the exact mechanism of control. e.g. IF
and WHILE statements are example of
abstraction of machine code implementation
that involves conditional jump instruction.
“ for all I in S sort files I”
 Information Hiding
• Using Information hiding approach, each
module in the system hides the internal
details of its processing activities and
modules communicate only through well
defined interfaces.
• Design should begin with the a list of difficult
design decisions and design decisions likely to
change.
 Information Hiding
• Each module is designed to hide such a decision
from other modules.
Other candidates for information hiding include
• A data structure, its internal linkages, and the
implementation details of the procedures that
manipulate it.
• The format of control blocks such as those for
queues in an operating system.
• Character codes, ordering of character set, and
other implementation details.
 Information Hiding
• Shifting, masking, and other machine
dependent details.
 Structure
• The use of structuring permits the
decomposition of large system into smaller,
more manageable units with well-defined
relationships to the other units of the system.
• The most general form of the system structure is
the network. A computing network can be
represented as directed graph, consisting of
nodes and arcs.
• The nodes can represent processing elements
that transform the data and the arcs can be used
to used to represent data links between nodes.
 Structure
• Alternatively node can represent data stores and and
the arcs data representation.
• A network might specify the data flow and
processing steps for single subprogram or the data
flow among a collection of sequential subprograms.
• The most complex form of computing network is a
distributed computing system in which each node
represents a geographically distinct process with
private memory.
 Structure
• Inside each processes one might have
functional abstraction groups ,data
abstraction groups and control abstraction
group.
• Each group might consist of visible
specification part and a hidden body.
 Modularity
Modular systems consist of a well defined,
manageable units with well defined interfaces among
units Desirable properties of modular system includes]

• Each processing abstraction is a well defined sub

system that is potentially useful in other application.
• Each function in each abstraction has a single, well
defined purpose.
•Each function manipulate no more than one major
data types.
 Modularity
• Function share global data selectively. It is
easy to identify all routines that shares a
major data structure.

• Function that manipulate instances of abstract

data types are encapsulated with the data
structure being manipulated.
 Concurrency
• Software systems can be categorized as
sequential or concurrent. In sequential
systems only one portion of the software
is active at any time.
• Concurrent system can have independent
processes that can be activated
simultaneously if multiple processors are
available.
 Concurrency
• Problems unique to concurrent system includes
Deadlocks
Mutual Exclusion
Synchronization of processes
• Concurrency is the fundamental principle of
software design because parallelism in software
introduces added complexity and additional
degrees of freedom into design process.
 Verification
This is typically done in two steps:

• verification that the software requirement

definition satisfy the customer
needs( verification of requirements)

• verification that the design satisfy the

requirements definition( verification of the
design).
 Aesthetics
Simplicity, elegance and clarity of purpose
distinguish products of outstanding quality
from mediocre products
 Design Notations

• Data flow diagrams

• Structure charts
• HIPO diagrams
• Procedure specifications
• Pseudocode
• Structured English
• Structured Flowcharts
 Data flow diagrams
• Data flow diagrams are directed graphs in
which the node specify the processing activity
and the arcs specify the data items
transmitted between processing nodes.
 Data Flow Diagram
(depicting flow of data among components)
Source or Destination of Data

Flow of Data

Processing

Data Store
 Example of DFD

Inventory Info Packaging

Instructions

Shipping
Order
Process Instruction
Customer Package
Order Order
Invoice

Customer Info
 Structure Charts
• Used during architectural design to document
hierarchical structure, parameters, and
interconnections in a system.

• The structure of a hierarchical system can be

specified using a structure chart.

• The chart can be augmented with module- by-

module specification of the input and output
parameters, as well as input and output parameter
attribute.

• During architectural design the parameter

attributes are abstract: they are defined into
concrete representation during detailed design.
Difference Between Flow Chart and
Structure Chart

• Structure chat has no decision

boxes.
• Sequential ordering of task
inherent in flow chart can be
suppressed in structure chart.
Format of a structure chart

A Selection
Repetition

B C D E

F G H
in out
1
2
3
4 Input Output
5 Data Data
6
7
8
 HIPO diagrams
• HIPO diagrams( Hierarchy-Process-Input-Output) were
developed at IBM as design representation scheme for top-
down software development, and as external
documentation aids for released products.

• A set of HIPO diagrams contains a visual table of contents, a

set of overview diagrams and a set of detail diagrams.

• The visual table of contents is a directory to the set of

diagrams in the package; it consists of a tree-structured
directory, a summary of contents of each overview diagram
and a legend of symbol definition .
 HIPO Diagrams
• The visual table of contents is a stylized structure
chart.
• Overview diagrams specify the functional processes
in the system. Each overview diagram describes the
inputs, processing steps, and outputs for the function
being specified. An overview diagram can point to
several subordinate detail diagrams, as required.
Visual Table of Contents for a HIPO
package

Legend 1

2 5 8

3 4 6 7 9 12

Contents
1. --- 10 11
2. ---
3. ---
 Procedure Templates
• Procedure interface specifications are
effective notations for architectural design
when used in combination with structure
charts and data flow diagrams.
• They also provide a natural transition from
architectural to detailed design and from
detailed design to implementation.
 Procedure Templates
PROCEDURE NAME:
PART OF( subsystem name & number)
CALLED BY:
PURPOSE:
DESIGNER/DATE(s): LEVEL 1

PARAMETERS:(names,modes,attributes,purpose)
INPUT ASSERTION: ( preconditions)
OUTPUT ASSERTION:(post conditions)
GLOBALS:( name, modes,attributes, purposes, shared with)
SIDE EFFECTS: LEVEL 2
 Procedure Templates
LOCAL STRUCTURES: (names, attributes,purposes)
EXCEPTIONS: (conditions, responses)
TIMING CONSTRAINTS:
OTHER LIMITATIONS: LEVEL 3

PROCEDURE BODY: (pseudocode, structured English, structure flow chart,

decision table) LEVEL 4
 Pseudocode
• Used in both the architectural and detailed design
phases.
• Using pseudocode the designer describes the system
characteristics using short, concise, English language
phrases that are structured by keywords such as IF-
THEN-ELSE, While-DO, and End. Key words and
indentation describes the flow of control while
English phrases describes the processing actions.
 Pseudocode
• Using the top-down design strategy \, each English
phrase is expanded into more detailed pseudocode
until the design specification reaches the level of
detailed implementation language.
• E.g.
Initialize tables and counters;Open file
Read the first text record
 Structure Flow Charts
• Traditionally used for specifying and documenting
algorithmic details in a software system.

• Flowcharts incorporate rectangular boxes for

actions, diamond shape boxes for decisions, directed
arcs for specifying interconnections between boxes
and a variety of symbols for representing input and
output.

• Unlike flow chart structure charts are restricted to

composition of certain basic terms.
• The basic forms are characterized by single
entry into and single exit from the form.
• Structure flowchart are logically equivalent
to pseudo code. They have same expressive
power as pseudo code.
• Structured flow chart are preferred in
situations where clarity of control flow is to
be emphasized.
 Structured Flow Charts
S1
S
S2 P

P P
S1 S2
S

REPEAT S UNTIL P
IF P THEN S1 ELSE S2
WHILE P DO S
 Structured English
Structured English can be used to provide a step-by-
step specification for an algorithm. Structured English
can be used at any desired level of detail. Structured
English is often used to specify cookbook recipes.
1.Preheat Oven to 350 degree F.
2.MIX eggs,milk, and vanilla.
3.Add flour and baking soda.
4.Pour into a greased baking dish
5.Cook until done.
 Decision Tables
Decision tables can be used to specify
complex design logic in a high level
software specification. They are useful
for specifying algorithm logic during
detailed design.
 Module-Level Concepts
• Now we will consider some concepts specific
to function oriented design.
• A module is a logically separable part of a
program.
• In a system using functional abstraction,
coupling and cohesion are two modularization
criteria, which are often used together.
 Cohesion
• Cohesion of a module represent how tightly bound
the internal elements of the module are to one
another.
• We are interested in determining how closely the
elements of module are related to one another.
• The greater the cohesion of each module in the
system, the lower the coupling between module is.
 Cohesion
• A measure of how well a component 'fits
together'
• A component should implement a single logical
entity or function
• Cohesion is a desirable design component
attribute as when a change has to be made, it
is localised in a single cohesive component
• Various levels of cohesion have been identified
 Cohesion levels
• Coincidental cohesion (weak)
– Parts of a component are simply bundled together
• Logical association (weak)
– Components which perform similar functions are
grouped
– For example:
output text to screen
output line to printer
output record to file
– Seems ok
– Problem is it carries out a range of similar but
different actions
– No single well defined action
 Cohesion levels

• Temporal cohesion (weak)

– Components which are activated at the same time are
grouped
– For example:
clear screen
open file
Initialise total
– again not related
– solution is to make initialisation module all other
specialised modules:
call init_terminal
call init_files
call init_calculations
 Cohesion levels
• Procedural cohesion (weak)
– The elements in a component make up a single control
sequence
• Communicational cohesion (medium)
– All the elements of a component operate on the same
data
– e.g. display and log temperature
• Sequential cohesion (medium)
– The output for one part of a component is the input to
another part
 Cohesion levels

• Functional cohesion (strong)

– optimal type of cohesion
– performs a single well-defined action on a single
data object
– e.g. calculate average
– Each part of a component is necessary for the
execution of a single function
• Object cohesion (strong)
– Each operation provides functionality which allows
object attributes to be modified or inspected
 Cohesion as a design attribute
• Not well-defined. Often difficult to classify
cohesion
• Inheriting attributes from super-classes
weakens cohesion
• To understand a component, the super-classes
as well as the component class must be
examined
• Object class browsers assist with this process
 Coupling
• A measure of the strength of the inter-connections
between system components
• Loose coupling means component changes are
unlikely to affect other components
• Shared variables or control information
exchange lead to tight coupling
• Loose coupling can be achieved by state
decentralisation (as in objects) and component
communication via parameters or message
passing
 Tight coupling

Module A Module B

Module C Module D

Shared data
area
 Loose coupling
Module A

A’s data

Module B Module C

B’s data C’s data

Module D

D’s data
 Coupling levels

• Altering another modules code (LISP, Assembler)

• Modifying data within another module
– fault that appears in one module may be due to
another
– complicated understanding and debugging
– can be done via global variables or pointers or call be
reference in C++ / Java
• Shared or global data
 Coupling levels

• Procedure call with a parameter that is a switch

(or a function pointer in C)
– io (command, device buffer, length);
– where command is 0,1,2 for read, write open; better to
use
– read( device, buffer, length);
• Procedure call with parameters that are pure data
– ideal is call by value, where a small number of
parameters are used and a copy of the data is passed
to the procedure invoked
– clear what information is being communicated
 Coupling levels
• Passing a serial data stream
– most ideal situation
– one module passes stream of data to another
– once passed data is outside control of process/module
– like piping in UNIX
– data can be thought of as a temporary intermediate file
– only possible in languages that support concurrency such
as Ada and Erlang and Parallel C
 Coupling and inheritance
• Object-oriented systems are loosely
coupled because there is no shared state and
objects communicate using message passing
• However, an object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes. Such changes must be carefully
controlled
 DESIGN TECHNIQUES
Several techniques have been developed for
software design. These are
• Step-Wise Refinement
• Levels of abstraction
• Structured Design
• Integrated top down development
• Jackson Design method
 Step-Wise Refinement
Step-wise refinement is a top-down technique for
decomposing a system from high-level specifications
into more elementary levels. This is also called as
“stepwise program development” and “successive
refinement”. It involves following activities:
• Decomposing design decision to elementary levels.
• Isolating design aspects that are not truly
interdependent.
• Postponing decisions concerning
representation details as long as possible.
• Carefully demonstrating that each successive
step in the refinement process is faithful
expansion of previous steps.
 Benefits of step-wise refinement
• Top-down decomposition
• incremental addition of details
• Postponement of design decisions
• Continual verification of consistency
 Integrated Top-Down
Development
• Integrated top-down development integrates design,
implementation, and testing.
• Design proceeds top-down from the highest level
routine.
• They have the primary function function of
coordinating and sequencing lower-level routines.
• Lower-level routines can not access the high-level
routines.
 STRATEGY:
DESIGN MAIN
CODE MAIN
MAIN STUBS FOR GET, PROCESS, PUT
TEST GET
DESIGN GET
CODE GET
GET PROCESS PUT TEST MAIN GET
DESIGN PROCESS
CODE PROCESS
STUBS FOR SUB1, SUB2
TEST MAIN GET PROCESS
SUB1 SUB2 DESIGN PUT
CODE PUT
TEST MAIN, GET, PROCESS, PUT
DESIGN SUB1
CODE SUB1
TEST MAIN, GET, PROCESS, PUT,SUB1
DESIGN SUB2
CODE SUB2
TEST MAIN GET, PROCESS, PUT,SUB1,SUB2
 Advantages
• This technique provide orderly and systematic
framework for software development.
• Design and coding are integrated.
• Test cases are developed systematically and
each routine is tested in actual operating
environment.
 Disadvantages
• Early high level design decisions may have to
be reconsidered when the design progresses
to lower levels
• System may be very expensive test harness
for newly added procedures
 Jackson Structured Programming
This a systematic technique for mapping the structure
of problem into a program structure to solve the
problem.
• The problem is modeled by specifying the input and output
data structure using tree structured diagrams.
• The input-output model is converted into a structural model
for the program identifying points of correspondence
between nodes in the input and output trees.
• The structural model of the program is expanded into a
detailed design that contains the operations needed to solve
the problem.
Input and output data is specified using a graphical
notation to specify data hierarchy, sequence of
data, repetition of data items, and alternate data
items.
A

B C D

E o O selection
F 0

* Zero or more
occurrences
G * H I
Specification of object A using Jackson Structured Programming notation
• The second step of Jackson method involves
converting the input and output structures into a
structural model of the program.
• The third step expands the structural model of
the program into a detailed design model
a) A list of operations required to perform the
processing steps is developed.
b) the operations are associated with the program
structure
c) Program structure and operations are expressed
in a notation called schematic logic, which is
stylized pseudocode. Control flow for selection
and iteration are specified in this step.
Input and output structure of an inventory
program

INPUT FILE Output Report

Part Group*
heading Body
Movement *
record
NET *
Issue o Receipt o MOVEMENT
TIME
Correspondence between Input and output
structure of an inventory program

INPUT FILE Output Report

Part Group*
heading Body
Movement *
record
NET *
Issue o Receipt o MOVEMENT
TIME
Program Structure for an inventory problem

Program

Process Process
heading Body

Process PTGP *
and line
Process Process
PTGP Body line
Process Record *

Process Issue o Process Receipt o`

Operations needed in the inventory
program

1. OPEN FILES
2. CLOSE FILES
3. STOP RUN
4. READ A RECORD INTO PART_NUM,
MOVMNT
5. WRITE HEADING
6. WRITE NET_MOVEMENT LINE
7. SET NET_MOVMNT TO ZERO
8. ADD MOVMNT TO NET_MOVMNT
Association of operations wit Program Structure

Program

Process Process
1 4 5 heading Body
2 3

Process PTGP *
and line
Process Process
7 PTGP Body 6
line
4 Process Record *

9 Process Issue o Process Receipt o` 8