UNIT 3: Design

Design

Software design is more creative process than analysis because it deals with the development
of actual mechanism for a new workable system. Software design deals with the transforming
the customer requirements, which is written in SRS document, into a form that is suitable for
implementation in a programming language. Design is highly significant phase in the
software development where the designers plan “how” a software system should be produced
in order to make it functional, reliable and reasonably easy to understand, modify and
maintain. A SRS document tells us “What” a system does, and becomes input to the design
process, which tells us “how” a software system works. Designing software system means
determining how requirements are realized and result is a software design document. So the
purpose of design phase is to produce a solution to a problem given in SES document.

Design Framework:

A framework of design is shown in figure:

It starts with initial requirements and ends up with the final design. Here, data is gathered on
user requirements and analyzed accordingly. A high level design is prepared after answering
questions of requirements. Design is refined in every cycle and finally it is documented to
produce design document.

Conceptual and Technical Design

The process of software desing involves the transformation of ideas into detailed
implementation descriptions, with the goal of satisfying the software requriments. To
transform requirements into a working system, designers must satisfy both customer and
system developers. The customer understand what the system is to do. At the same time, the
system developers must understand how the system is to work. For this reason, design is
really a two part iterative process.

First, we produce conceptual design that tells the customer exactly what the system will do.
Once the customer approves the conceptual design. We translate the conceptual design into
much more detailed document which is technical design. Technical design allows system
developers to understand the actual hardware and software needed to solve the customer’s
problem. This two part design process is shown in figure:

The two design document describe the same system, but in different ways because of the
different audience for the documents. The conceptual design answers the following questions:

• Where will the data come from?

• What will happen to the data in the system?
• How will the system look to users?
• What choices will be offered to the users?
• What is timing of events?
• How will the reports and screens look like?

The conceptual design describe the system in language understandable to the customer. It
does not contain any technicality of the system and is independent of implementation.

While the technical design describes:

• The Hardware configuration

• The software needs
• The communications interfaces
• The input and output of the system
• The network architecture
 • Any other thing that translate the requirements into a solution to the customer’s
problem.

Software Design Strategy:

Software design is a problem solving activity which is comprised of the following steps:

1. Understand the problem

2. Generate potential solutions to the problem
3. Evaluate the potential solutions to pick the best
4. If the best solution is inadequate, return to the step 2 to refine solutions or generate
new solutions.
5. Ensure that the solution is sufficient, and the work is complete and well documented.

Software Design Models:

Software design problems and solutions are often complex and many aspects of software
must be modeled. Software design models may be divided into two broad classes:

1. Static Models

These models represent aspects of software system that do not change during
execution. Generally these models represent software components, their
characteristics and the relationship between software components. Examples of static
models are object and class diagrams, use case diagrams, data structure diagrams,
operation specification and implementation diagrams.

2. Dynamic Models

These models show what happens during software execution. Examples of dynamic
models are interaction diagrams, state chart, data flow diagrams, decision trees and
tables.

Design Activities:

Software design activities can be broadly classified into two important parts:

• Preliminary Design (High level design) and

• Detailed Design

Preliminary Design

High-level design means identification of different modules and the control relationships
among them and the definition of the interfaces among these modules. The outcome of high-
level design is called the program structure or software architecture. Many different types of
notations have been used to represent a high-level design. A popular way is to use a tree-like
diagram called the structure chart to represent the control hierarchy in a high-level design.
Detailed Design

During detailed design, the data structure and the algorithms of the different modules are
designed. The outcome of the detailed design stage is usually known as the module-
specification document.

Items Developed during the Design Phase:

For a design to be easily implemented in a conventional programming language, the

following items must be designed during the design phase.

• Module Structure
• Control relationship among the modules
• Interface among different modules
• Data structure of individual modules
• Algorithms for individual modules

Characteristics of good Software Design:

The definition of “a good software design” can vary depending on the application being
designed. the criteria used to judge how good a given design solution is can vary widely
depending upon the application. The characteristics of good software design are as follows:

• Correctness: A good design should correctly implement all the functionalities

identified in the SRS document.
• Understandability: A good design is easily understandable
• Efficiency: It should be efficient.
• Maintainability: It should be easily maintain for changes.

Difference between Good and Bad Design:

The comparison of good and bad design against its key characteristics are as follows:

Characteristics Good Design Bad Design

Change Change in one part of the system One conceptual change requires
does not always require a change in changes to many parts of the
another part of the system. system.
Logic Every piece of logic has written at Logic has to be duplicated
once.
Nature Simple Complex
Cost Low Very High
Extension System can be extended with System can’t be extended so
changes in only one piece easily
Link The logic link can easily be found The logic link can’t be
remembered
Interface Design:

Interface design is the specification of the interaction between a system and its environment.
During the interface design, the internals of the system are completely ignored in favor of the
relationship between the system and its environment. Here, main focus is on the interaction of
users with the system. Interface design includes the specification of user inputs, user outputs,
sequence of user inputs and outputs. This design should include:

• Precise description of the events in the environment to which the system must
respond.
• Specification of data input and output of the system
• Specification of ordering and timing of events for input and output.

Architectural Design

Architectural design is the specification of the major components of a system, their

responsibilities, properties, and the relationships between components. Components and their
relationships are identified without emphasis on the internal details. Architectural design adds
important details ignored during interface design. Design of internals of the major
components is ignored until the last phase of design.

Detailed Design

Detailed design is the specification of the internal elements of all major system components,
their structure, properties, relationships, processing and their algorithms and data structure.
The detail design may include:

• Decomposition of major system components into program units.

• Allocation of functional responsibilities to units.
• Unit interfaces.
• Data and control interactions between units.
• Algorithms and data structures.

Modularization

A modular system consists of well defined, manageable units with well defined interfaces
among the units. Desirable properties of a modular system include:

• Each module is a well defined subsystem that is potentially useful in other

applications.
• Each module has a single, well defined purpose.
• Modules can be separately compiled and stored in a library.
• Modules can use other modules.
• Modules should be easier to use than to build.
• Modules should be simpler from the outside than from the inside.
Modularity is the single attribute of software that allows a program to be intellectually
manageable. In enhances the design clarity, which in turn eases implementation, testing,
documenting and maintenance of the software product.

Modularity is a fundamental principle governing any good design. Decomposition of a

problem into modules facilitates the design by taking advantages of the divide and conquer
principles. If different modules are independent of each other, then each module can be easily
understood. This also reduces the complexity of the design solutions. We must use clean
decomposition of a problem into modules and their arrangements in to a neat hierarchy.

Clean decomposition means that the modules in a software design should display high
cohesion and low coupling.

Cohesion and Coupling

Most researchers and engineers agree that a good software design implies clean
decomposition of the problem into modules. The primary characteristics of a neat module
decomposition are high cohesion and low coupling.

Cohesion is a measure of the functional strength of a module whereas the coupling between
two modules is a measure of the degree of interdependence or interaction between the two
modules.

A module is having high cohesion and low coupling is said to be functional independence of
other modules. By the term functional independence, we mean that a minimal interaction
with other modules. Functional independence is a key to any good design.

Module coupling

Coupling is the measure of degree of interdependence between modules. Two modules with
high coupling are strongly interconnected so they are dependent on each other. Two modules
with low coupling are not dependent on one another. A good design will have low coupling.

Coupling is the measured by the number of interconnections between modules. Loose

coupling can be achieved in the following ways:

• Controlling the number of parameters passed amongst modules.

• Avoid passing undesired data to calling modules.
• Maintain parent-child relationship between calling and called modules.
• Pass data not the control information.

Classification of Cohesiveness

Different types of coupling are content, common, control, stamp and data. The strength of
coupling from lowest coupling (Best) to highest coupling (Worst).
Data coupling: Two modules are data coupled, if they communicate through a parameter. An
example is an elementary data item passed as a parameter between two modules, e.g. an
integer, a float, a character, etc. This data item should be problem related and not used for the
control purpose.

Stamp coupling: Two modules are stamp coupled, when complete data structure is passed
from one module to another such as a record in PASCAL or a structure in C.

Control coupling: Control coupling exists between two modules, if data from one module is
used to direct the order of instructions execution in another. An example of control coupling
is a flag set in one module and tested in another module.

Common coupling: Two modules are common coupled, if they share data through some
global data items.

Content coupling: Content coupling exists between two modules, if they share code, e.g. a
branch from one module into another module.

Module Cohesion

Cohesion is a measure of the degree to which the elements of a module are functionally
related. Different classes of cohesion that a module possess are as follows:

Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a set

of tasks that relate to each other very loosely, if at all. In this case, the module contains a
random collection of functions. It is likely that the functions have been put in the module out
of pure coincidence without any thought or design.

Logical cohesion: A module is said to be logically cohesive, if all elements of the module
perform similar operations, e.g. error handling, data input, data output, etc.

Temporal cohesion: When a module contains functions that are related by the fact that all
the functions must be executed in the same time span, the module is said to exhibit temporal
cohesion.

Procedural cohesion: A module is said to possess procedural cohesion, if the set of

functions of the module are all part of a procedure (algorithm) in which certain sequence of
steps have to be carried out for achieving an objective, e.g. the algorithm for decoding a
message.
Communicational cohesion: A module is said to have communicational cohesion, if all
functions of the module refer operates on the same input data or contributes towards the same
output data, e.g. the set of functions defined on an array or a stack.

Sequential cohesion: A module is said to possess sequential cohesion where the output from
one element of the sequence is input to the next.

Functional cohesion: Functional cohesion is said to exist, if different elements of a module

cooperate to achieve a single function.

Structure Charts

Concept of structure chart is according to the black box i.e. a system is broken down
decomposed into well defined processing modules. A structural chart is a graphical
representation of the program’s organization. Flowcharts illustrate how the program will
create the desired output. A structure chart is a hierarchy chart with arrows showing the flow
of data and control information between the modules. Structure charts are used as design
tools for functionally decomposing structured programs.

A structure chart is used to show the programmers that how the system is partitioned into
modules, what are the relationships between these modules and identify the parameters or
information passed between modules. A structure chart shows what tasks the system must
perform, while the flowchart shows how the system will perform these tasks.

A structure chart depicts:

• the size and complexity of the system, and

• number of readily identifiable functions and modules within each function
Pseudocode:

This is an outline of a program, written in a form that can easily be converted into real
programming statements. Pseudocode cannot be compiled nor executed, and there are no real
formatting or syntax rules. It is simply one step - an important one - in producing the
final code. The benefit of pseudocode is that it enables the programmer to concentrate on
the algorithms without worrying about all the syntactic details of a particular programming
language. In fact, you can write pseudocode without even knowing what programming
language you will use for the final implementation. Each individual designer may have their
own personal style of pseudocode. Pseudocode is not a rigorous notation, since it is read by
other people, not by the computer. There is no universal "standard" for the industry, but for
instructional purposes it is helpful if we all follow a similar style.

Consists of natural language-like statements that precisely describe the steps of an algorithm
or program.

• Statements describe actions.

• Focuses on the logic of the algorithm or program.
• Avoids language-specific elements.
 • Written at a level so that the desired programming code can be generated almost
automatically from each statement.
• Steps are numbered. Subordinate numbers and/or indentation are used for dependent
statements in selection and repetition structures.

Flow Charts

Flowcharts are the tools used to describe or show the logical sequences and steps that occur
in a process or decision making situations. Flowchart uses different symbols to represent the
action or steps in a process.

Flow Chart verses Structure Chart

A flow chart is a conventional technique to represent the flow of control in a program. A

structure chart differs from a flow chart in three potential ways:

1. It is usually difficult to identify the different modules of the software from its flow
chart representation.
2. Data interchange among different modules is not represented in a flow chart.
3. Sequential ordering of tasks inherent in a flow chart is suppressed in a structure chart.

Strategy of Design

A good system design strategy is to organize the program modules in such a way that are
easy to develop and change. Structured design techniques help developers to deal with the
size and complexity of the programs. Analyst creates instructions for the developers about
how code should be written and how piece of code should fit together to form a program.

There are many strategies or techniques available for performing system design. They include
bottom-up approach, top-down approach and hybrid approach.

Bottom-Up Approach:

A common approach is to identify modules that are required by many programs. This
approach lead to a style of design where we decide how to combine these modules to provide
larger ones than combine even more larger once and so on till we arrive at one big module
which is the whole of the desired program. The set of these modules form a hierarchy which
is a cross linked tree structure.
Since the design progressed from bottom layer to upwards, the method is called bottom-up
design. The main argument for this design is that if we start coding a module soon after its
design, the chances of recoding is high, but the coded module can be tested and design sooner
than a module which is at higher level.

This method has one terrible weakness that we need to use a lot of intuition to decide exactly
what functionality a module must provide. If we get it wrong, then at a higher level, we will
find that it is not as per requirements then we have to redesign at a lower level. This design
approach is best for those systems which are build from existing system.

Top-Down Approach

The essential idea of top down design is that the specification is viewed as describing a black
box for the program. A top down design approach starts by identifying the major modules of
the system, decomposing then into their lower level modules and iterating until the desired
level of detail is achieved. This is stepwise refinement which starts from an abstract design
and then refine in more details until we reach a level where no more refinement is needed and
design can be implemented directly.

Most design methodologies are based on this approach and this is suitable, if the
specifications are clear and development is from the scratch. If coding of a part starts soon
after its design then nothing can be tested until all the subordinated modules are coded.

Hybrid Approach

Hybrid approach has really become popular after the acceptance of reusability of modules. In
this approach we use the combination of both top-down and bottom-up approach to design
software.

Function Oriented Design:

The design activity begins when the SRS document for the software to be developed is
available. The design process for software systems often has two levels. At the first level the
focus is on deciding which modules are needed for the system, their specification of these
modules and how the modules should be interconnected.

Function oriented design is an approach to software design where the design is decomposed
into a setoff interacting units, where each unit has a clearly defined functions. So the system
is designed from a functional viewpoint.

Object Oriented Design:

Object oriented design is the result of focusing attention not on the function performed by the
program, but instead on the data that are to be manipulated by the program. Object oriented
design begins with an examination of the real world things that are part of the problem to be
solved. These things, which we call objects are characterized individually in terms of their
attributes and behavior. Each object maintains its own state, and offers a set of services to
other objects.
Size Oriented Metrics:

Size oriented metrics are derived by normalizing quality and productivity measures by
considering the size of the software that has been produced. The establishment of size is very
critical and difficult area of the project planning. The project size is a measure of the problem
complexity in terms of the effort and time required to develop the product.

Currently, two metrics are widely used to estimate size: Line of Code
(LOC) and Function Point (FP). The usage of each of these metrics in project size estimation
has its own advantages and disadvantages which are discussed as.

Line of Code (LOC):

LOC is the simplest among all metrics available to estimate project size. This metric is very
popular, being the simpler to use. Using this metric, the project size is estimated by counting
the number of source instructions in the developed program. While counting the number of
source instructions, the lines used for commenting the code and the header lines are ignored.

Determining the LOC count at the end of a project is a very simple job. However, accurate
estimation of the LOC count at the beginning of a project is very difficult. In order to
estimate the LOC count at the beginning of a project, project manager usually divide the
problems into modules, and each module into sub-modules and so on, until the sizes of the
different leaf level modules can be approximately predicted. To be able to do this past
experience in developing similar projects proven helpful. By using the estimation of the
lowest level modules, project manager arrive at the total size estimation.

Advantages of LOC

• Simple to measure

Shortcomings of LOC:

• LOC gives a numerical value of problem size that can vary widely with individual
coding style. Different programmers have their code in different ways.
• It is language dependent.
• User cannot easily understand it.
• A good problem size measure should consider the overall complexity of the problem
and the effort needed to solve it. It should consider the total effort needed to specify,
design, code, test etc and not just the coding effort.
• LOC measure correlates poorly with the quality and efficiency of the code. A larger
code does not necessarily imply better quality or higher efficiency.
• It is very difficult to accurately estimate LOC in the final product from the problem
specification. The LOC count can be accurately computed only after the code has
been fully developed.

Function Point Metric:

Function point metric was proposed by Albercht in 1983. This metric overcome many of the
shortcoming of the LOC metric. One of the main advantage of using the function point metric
is that it can be used to easily estimate the size of a software product directly from the
problem specification.

The basic idea of function point metric is that the size of the software product is directly
dependent on the number of different functions or features it supports. Function-oriented
software metrics use a measure of the functionality delivered by the application as a
normalization value. Since ‘functionality’ cannot be measured directly, it must be derived
indirectly using other direct measures. Function points are derived using an empirical
relationship based on countable (direct) measures of software's information domain and
assessments of software complexity. Function points are computed by completing the
following table.

Five domain characteristics are determined and counts are provided in the appropriate table
location. Information domain values are defined as:

1. Number of User Inputs: Each user input that provides distinct application oriented
data to the software is counted. Inputs should be distinguished from inquiries, which
are counted separately.
2. Number of User Outputs: Each user output that provides application oriented
information to the user is counted. In this context output refers to reports, screens,
error messages, etc. Individual data items within a report are not counted separately.
3. Number of User Enquiries: An inquiry is defined as an on-line input that results in
the generation of some immediate software response in the form of an on-line output.
Each distinct inquiry is counted.
4. Number of Files: Each logical master file is counted.
5. Number of External Interfaces: All machine readable interfaces that are used to
transmit information to another system are counted.

Once these data have been collected, a complexity value is associated with each count.
Organizations that use function point methods develop criteria for determining whether a
particular entry is simple, average, or complex.
To compute function points (FP), the following relationship is used:

FP = count total × [0.65 + 0.01 × Σ(Fi)] where count total is the sum of all FP entries
obtained from above table. Or FP = UFP * TCF where the UFP is unadjusted function point
and TCF is technical complexity factor.

The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following
questions [ART85] which can vary from 0 to 70:

1. Does the system require reliable backup and recovery?

2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?

Each of these questions is answered using a scale that ranges from 0 (not important or
applicable) to 5 (absolutely essential).

Advantages of FP:

• FP approach is independent of the language, tools or methodologies used for

implementation.
• FP can be estimated from requirement specification or design specification.
• FPs are directly linked to the statement of requirements. Any changes in requirements
can easily be followed by a re-estimation.
• FPs are based on the system user’s external view of the system.
• More accurate than estimated LOC.

Shortcomings of FP:

• Subjective counting
• Hard to automate and difficult to compute
• Ignores quality of output
• Oriented to traditional data processing applications
Halstead’s Software Science Metrics:

The software science developed by M. H. Halstead principally attempts to estimate the

programming effort.

The measurable and countable properties are:

• n1 = Number of Unique operators appearing in that implementation

• n2 = Number of Unique operands appearing in that implementation
• N1 = Total usage of all the operators appearing in that implementation
• N2 = Total usage of all the operands appearing in that implementation

From these metrics Halstead defines:

1. The Program Vocabulary n as:

n = n1 + n2

2. The implementation program length N as:

N = N1 + N2

3. Program Length Equation

It may be necessary to know about the relationship between program length N and
vocabulary n. N` means it is calculated rather than counted.
N` = n1 log2 n1 + n2 log2 n2
4. Program Volume: This metric is for the size of any implementation of any
algorithm. V = N log2 n
5. Program Level: It is the relationship between program volume and potential volume.
L = V* / V
6. Potential Volume: Many different but equivalent programs may implement an
algorithm. Amongst all these programs, the one that has minimal size is said to have
the potential volume V*. The implementation of this algorithm would then require
nothing more than invoking the procedure and supplying the operands for its input
and output parameters. The potential volume of an algorithm implemented as a
procedure call could be expressed as:
V* = (2 + n2*) log2 (2 + n2*)

The first term in the parentheses, 2, represents the two unique operators for the
procedure call. The second term n2* represents the number of conceptually unique
input and output parameters.

7. Programming Effort: The programming effort is restricted to the mental activity

required to convert an existing algorithm to an actual implementation in a
programming language.
E = V / L or E = V / L^
8. Time: The programming time T of a program in second is simply
T` = E / S
 The stroud number S is the Stroud’s moments per second with range from 5 to 20.
Generally S is set to 18.

9. Estimated Program Level / Difficulty: Halsted offered an alternative formula that

estimates the program level.
L^ = 2 n2 / (n1 N2) and D^ = 1/ L^ = (n1 N2)/2n2

Advantages of Halstead Metrics:

• Do not require in-depth analysis of programming structure.

• Predicts rate of error.
• Predicts maintenance of effort.
• Useful in scheduling and reporting projects.
• Measure overall quality of programs.
• Simple to calculate.
• Can be used for any programming language.

Drawbacks of Halstead Metrics:

• It depends on completed code.

• It has no use as a predictive estimating model.

Cyclomatic Complexity Metric

Cyclomatic Complexity is also called structural complexity of the program. It defines the
upper bound on the number of independent paths in a program. Cyclomatic complexity is a
software metric that provides a quantitative measure of the logical complexity of a program.
The value computed by the Cyclomatic complexity defines the number of independent paths
in the basis set of a program and provides us with an upper bound for the number of tests that
must be conducted to ensure that all statements have been executed at least once.

Cyclomatic complexity can be computed in one of the three ways:

1. No of bounded regions + 1
2. Edges – Nodes +2
3. No of predicates node +1

Decision nodes are known as predicate nodes. To calculate the Cyclomatic complexity, we
have to first draw the control flow graph from the code.

Control Flow Graph

A control flow graph describes the sequences in which the different instructions of a program
get executed. In other words, it describes how the control flows through the program. In order
to draw the control flow graph of a program, we need to first number all the statements of a
program. The different numbered statements serve as the nodes of the control flow graph.
Each circle represents one or more procedural statements which also called a flow graph
node. An edge must terminate at a node.