System Design

Software Design
• Software design is an iterative process through which requirements
are translated into a “blueprint” for constructing the software.
• McGlaughlin suggests three characteristics that serve as a guide for
the evaluation of a good design:
 The design must implement all of the explicit requirements
contained in the analysis model, and it must accommodate all of
the implicit requirements desired by the customer.
 The design must be a readable, understandable guide for those
who generate code and for those who test and subsequently
support the software.
 The design should provide a complete picture of the software,
addressing the data, functional, and behavioural domains from
an implementation perspective.
 Design Principles
• The design process should not suffer from “tunnel vision.”
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel
• The design should “minimize the intellectual distance”
between the software and the problem as it exists in the real
world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be reviewed to minimize conceptual
(semantic) errors.
 Design Concepts
software design concepts provide the necessary
framework for "getting it right.“
• Abstraction
• Refinement
• Modularity
• Software Architecture
• Control Hierarchy
• Structural Partitioning
• Data Structures
• Software Procedures
• Information Hiding
Abstraction: It permits one to concentrate on a problem at some level of
generalization without regard to irrelevant low level details; use of abstraction also
permits one to work with concepts and terms that are familiar in the problem
environment without having to transform them to an unfamiliar structure.
Refinement: It is a top-down design strategy originally proposed by Niklaus Wirth. In
each step (of the refinement), one or several instructions of the given program are
decomposed into more detailed instructions. This successive refinement of
specifications terminates when all instructions are expressed in terms of any
underlying computer or programming language.
Modularity: With modularity software is divided into separately named and
addressable components, often called modules, that are integrated to satisfy
problem requirements.
Software architecture: It alludes to “the overall structure of the software and the
ways in which that structure provides conceptual integrity for a system”. In its
simplest form, architecture is the hierarchical structure of program components
(modules), the manner in which these components interact and the structure of data
that are used by the components.
Control hierarchy : It represents the organization of program components (modules)
and implies a hierarchy of control. It does not represent procedural aspects of
software such as sequence of processes, occurrence or order of decisions, or
repetition of operations; nor is it necessarily applicable to all architectural styles.
Structural Partitioning:
• If the architectural style of a system is hierarchical, the program
structure can be partitioned both horizontally and vertically.
• Horizontal partitioning defines separate branches of the modular
hierarchy for each major program function. Control modules,
represented in a darker shade are used to coordinate communication
between and execution of the functions.
• The simplest approach to horizontal partitioning defines three
partitions—input, data transformation (often called processing) and
output.
• Vertical partitioning, often called factoring, suggests that control
(decision making) and work should be distributed top-down in the
program structure. Top-level modules should perform control functions
and do little actual processing work. Modules that reside low in the
structure should be the workers, performing all input, computation,
and output tasks.
 Horizontal Partitioning

Function 1 Function 3

Function 2
Vertical Partitioning

Work Modules

DecisionMaking
module
Data structure: It is a representation of the logical relationship among
individual elements of data. Because the structure of information will
invariably affect the final procedural design, data structure is as
important as program structure to the representation of software
architecture.

Software procedure: It focuses on the processing details of each

module individually. Procedure must provide a precise specification of
processing, including sequence of events, exact decision points,
repetitive operations, and even data organization and structure.

Information Hiding: The principle of information hiding suggests that

modules be "characterized by design decisions that (each) hides from
all others." In other words, modules should be specified and designed
so that information (procedure and data) contained within a module is
inaccessible to other modules that have no need for such information.
 Cohesion
• Cohesion is a qualitative indication of the degree to which a module
focuses on just one thing.
• A cohesive module performs a single task within a software procedure,
requiring little interaction with procedures being performed in other parts
of a program.
• Cohesion may be represented as a "spectrum." We always strive for high
cohesion, although the mid-range of the spectrum is often acceptable.
And, low-end cohesiveness is much "worse" than middle range, which is
nearly as "good" as high-end cohesion.
• It is unnecessary to determine the precise level of cohesion. Rather it is
important to strive for high cohesion and recognize low cohesion so that
software design can be modified to achieve greater functional
independence.
• At the low (undesirable) end of the spectrum, we encounter a
module that performs a set of tasks that relate to each other loosely.
Such modules are termed coincidentally cohesive.
• A module that performs tasks that are related logically (e.g., a
module that produces all output regardless of type) is logically
cohesive.
• When a module contains tasks that are related by the fact that all
must be executed with the same span of time, the module exhibits
temporal cohesion.
• Moderate levels of cohesion are relatively close to one another in the
degree of module independence.
• When processing elements of a module are related and must be
executed in a specific order, procedural cohesion exists. When all
processing elements concentrate on one area of a data structure,
communicational cohesion is present.
• High cohesion is characterized by a module that performs one
distinct procedural task.
 Coupling
• Coupling is a qualitative indication of the degree to which a
module is connected to other modules and to the outside
world.
• Coupling depends on the interface complexity between
modules, the point at which entry or reference is made to a
module, and what data pass across the interface.
• In software design, we strive for lowest possible coupling.
Simple connectivity among modules results in software that is
easier to understand.
 No Direct
Coupling

a d i
Data Data
variable Control
Structure
Flag

b c e j k

f g h

Global Data b
Area
• Modules a and d are subordinate to different modules. Each is unrelated and
therefore no direct coupling occurs. Module c is subordinate to module a and
is accessed via a conventional argument list, through which data are passed.
As long as a simple argument list is present (i.e., simple data are passed; a
one-to-one correspondence of items exists), low coupling (called data
coupling) is exhibited in this portion of structure.
• A variation of data coupling, called stamp coupling, is found when a portion of
a data structure (rather than simple arguments) is passed via a module
interface. This occurs between modules b and a.
• At moderate levels, coupling is characterized by passage of control between
modules. Control coupling is very common in most software designs and is
shown in Figure, where a “control flag” (a variable that controls decisions in a
subordinate or super-ordinate module) is passed between modules d and e.
• High coupling also occurs when a number of modules reference a global data
area. Common coupling, as this mode is called, is shown in Figure. Modules c,
g, and k each access a data item in a global data area.
• The highest degree of coupling, content coupling, occurs when one module
makes use of data or control information maintained within the boundary of
another module.
 Structure Charts (SC)
• SC shows the static structure, not the logic and different
from flow charts.
• Structure is decided during design.
• SC represents modules and interconnections
• Each module is represented by a box
• If A invokes B, an arrow is drawn from A to B
• Arrows are labeled by data items
• Different types of modules in a SC exist such as Input,
output, transform, coordinate and composite modules.
• Implementation does not change structure and structure
affects maintainability.
Different Types of modules
Iteration and decision
 Structured Design Methodology
• SDM views software as a
transformation function
that converts given
inputs to desired outputs.
• The focus of SD is the
transformation function. Input Transformation Output
• Uses functional functions
abstraction.
• Specify functional
modules and
connections.
• Low coupling and high
cohesion is the objective
 Steps of SDM
1. Identify most abstract inputs and most
abstract outputs in a DFD
2. First level factoring
3. Factoring of input, output, transform
modules
4. Improving the structure
 Step 1
Most abstract inputs:
• data elements in DFD that are furthest from the actual inputs,
but can still be considered as incoming. These are logical data
items for the transformation.
• Travel from physical inputs towards outputs until data can no
longer be considered incoming.
• Go as far as possible, without loosing the incoming nature.
Most abstract outputs:
• Similar as of most abstract inputs.
• Represents a value judgment, but choice is often obvious.
Bubbles between mai and mao: central transforms
• These transforms perform the basic transformation
• With mai and mao the central transforms can concentrate on
the transformation
Example – counting the no of different
words in a file
 Step 2: First Level Factoring
• Divided the problem into three separate
problems
• Each of the three diff. types of modules
can be designed separately
• These modules are independent
• For each most abstract input data item,
specify a subordinate input module
• The purpose of these input modules is
to deliver to main the mai data items
• For each most abstract output data
element, specify an output module
• For each central transform, specify a
subordinate transform module
• Main module is a coordinate module
 Step 3: Factoring Input modules
• The transform that produced the mai data
is treated as the central transform
• Then repeat the process of first level
factoring
• Input module being factored becomes the
main module
• A subordinate input module is created for
each data item coming in this new central
transform
• A subordinate module is created for the
new central transform
• Generally there will be no output modules
• The new input modules are factored
similarly Till the physical inputs are
reached
• Factoring of the output modules is
symmetrical
 Step 3: Factoring Central Transforms
• No rules for factoring the
transform modules
• Top-down refinement
process can be used
• Determine sub-transforms
that will together compose
the transform
• Then repeat the process
for newly found transforms
• Treat the transform as a
problem in its own right
 Step 4
• The above steps should not be followed blindly
• The structure obtained should be modified if needed
• Low coupling, high cohesion being the goal
• Design heuristics used to modify the initial design
• Design heuristics - A set of thumb rules that are generally useful
 Module Size: Indication of module complexity Carefully
examine modules less than a few lines or greater than about
100 lines
 Fan out: no. of arrows going out of the module, indicating the
no. of sub ordinates of the module
 fan in: no. of arrows coming in the module, indicating the no.
of super ordinates of the module
 A high fan out is not desired, should not be increased beyond
5 or 6
 Fan in should be maximized