Software Design

Introduction
• In the software design phase, the design document is
produced, based on the customer requirements as documented
in the SRS document.
• the design process starts using the SRS document and completes
with the production of the design document.
• The design document produced at the end of the design phase
should be implementable using a programming language in the
subsequent (coding) phase.
OVERVIEW OF THE DESIGN PROCESS

• The design process essentially transforms the SRS document into

a design document.
Outcome of the Design Process

• The following items are designed and documented during the

design phase.
• Different modules required:
• The different modules in the solution should be identified.
• Each module is a collection of functions and the data shared by
these functions.
• Each module should accomplish some well-defined task out of
the overall responsibility of the software.
• Each module should be named according to the task it performs.
• Control relationships among modules:
• A control relationship between two modules essentially arises
due to function calls across the two modules.
• The control relationships existing among various modules should
be identified in the design document.
• Interfaces among different modules:
• The interfaces between two modules identifies the exact data
items that are exchanged between the two modules when one
module invokes a function of the other module.
• Data structures of the individual modules:
• Each module normally stores some data that the functions of the
module need to share to accomplish the overall responsibility of
the module.
• Suitable data structures for storing and managing the data of a
module need to be properly designed and documented.
• Algorithms required to implement the individual modules:
• Each function in a module usually performs some processing
activity.
• The algorithms required to accomplish the processing activities
of various modules need to be carefully designed and
documented with due considerations given to the accuracy of
the results, space and time complexities..
Classification of Design Activities

• A good software design is seldom realised by using a single step

procedure, rather it requires iterating over a series of steps
called the design activities.
• Depending on the order in which various design activities are
performed, we can broadly classify them into two important
stages.
• Preliminary (or high-level) design, and
• Detailed design.
• The meaning and scope of these two stages can vary considerably
from one design methodology to another.
• Through high-level design, a problem is decomposed into a set
of modules. The control relationships among the modules are
identified, and also the interfaces among various modules are
identified.
• However, for the traditional function-oriented design approach, it
is possible to define the objectives of the high-level design as
follows:
• The outcome of high-level design is called the program
structure or the software architecture. High-level design is a
crucial step in the overall design of a software.
• When the high-level design is complete, the problem should
have been decomposed into many small functionally
independent modules that are cohesive, have low coupling
among themselves, and are arranged in a hierarchy.
• Many different types of notations have been used to represent a
high-level design. A notation that is widely being used for
procedural development is a tree-like diagram called the
structure chart.
• Another popular design representation techniques called UML
that is being used to document object-oriented design, involves
developing several types of diagrams to document the object-
oriented design of a systems.
• Once the high-level design is complete, detailed design is
undertaken.
• During detailed design each module is examined carefully to
design its data structures and the algorithms.
• The outcome of the detailed design stage is usually documented
in the form of a module specification (MSPEC) document.
• After the high-level design is complete, the problem would have
been decomposed into small modules, and the data structures
and algorithms to be used described using MSPEC and can be
easily grasped by programmers for initiating coding.
Classification of Design Methodologies

• The design activities vary considerably based on the specific

design methodology being used.
• A large number of software design methodologies are available.
• We can roughly classify these methodologies into procedural
and object-oriented approaches.
• These two approaches are two fundamentally different design
paradigms.
Do design techniques result in unique solutions?

• Even while using the same design methodology, different

designers usually arrive at very different design solutions.
• The reason is that a design technique often requires the designer
to make many subjective decisions and work out compromises
to contradictory objectives.
• As a result, it is possible that even the same designer can work
out many different solutions to the same problem.
• Therefore, obtaining a good design would involve trying out
several alternatives (or candidate solutions) and picking out the
best one.
Analysis versus design

• Analysis and design activities differ in goal and scope.

• The analysis results are generic and does not consider
implementation or the issues associated with specific
platforms.
• The analysis model is usually documented using some graphical
formalism.
• In case of the function-oriented approach that we are going to
discuss, the analysis model would be documented using data
flow diagrams (DFDs), whereas the design would be
documented using structure chart.
• On the other hand, for object-oriented approach, both the
design model and the analysis model will be documented using
unified modelling language (UML).
• The analysis model would normally be very difficult to
implement using a programming language.
• The design model is obtained from the analysis model through
transformations over a series of steps.
• In contrast to the analysis model, the design model reflects
several decisions taken regarding the exact way system is to be
implemented.
• The design model should be detailed enough to be easily
implementable using a programming language.
HOW TO CHARACTERISE A GOOD SOFTWARE DESIGN?

• few desirable characteristics that every good software design for

general applications must possess.
• Correctness: A good design should first of all be correct.
• That is, it should correctly implement all the functionalities of
the system.
• Understandability: A good design should be easily
understandable.
• Unless a design solution is easily understandable, it would be
difficult to implement and maintain it.
• Efficiency: A good design solution should adequately address
resource, time, and cost optimisation issues.
• Maintainability: A good design should be easy to change. This is
an important requirement, since change requests usually keep
coming from the customer even after product release.
Understandability of a Design: A Major Concern

• The design of a certain problem, assume that we have arrived at a

large number of design solutions and need to choose the best
one.
• all incorrect designs have to be discarded first.
• Out of the correct design solutions, how can we identify the best
one?
• a good design should help overcome the human cognitive
limitations that arise due to limited short-term memory.
• A large problem overwhelms the human mind, and a poor design
would make the matter worse.
• A good design solution should be simple and easily
understandable.
• If design solution is misunderstood:
1. implementation has a large number of defects.
2. push up the development costs.
3. the effort required to maintain the product would also increase
manifold.
4. lead to a program that is full of bugs and is unreliable.
An understandable design is modular and layered

• How can the understandability of two different designs be

compared, so that we can pick the better one?
• A design solution should have the following characteristics to be
easily understandable:
• It should assign consistent and meaningful names to various
design components.
• It should make use of the principles of decomposition and
abstraction in good measures to simplify the design.
• These two principles are exploited by design methodologies to
make a design modular and layered.
• The characteristics of an easily understandable design as follows:
A design solution is understandable, if it is modular and the
modules are arranged in distinct layers.
Modularity
• A modular design is an effective decomposition of a problem.
• A modular design, in simple words, implies that the problem has
been decomposed into a set of modules that have only limited
interactions with each other.
• Decomposition of a problem into modules facilitates taking
advantage of the divide and conquer principle.
• If different modules have either no interactions or little
interactions with each other, then each module can be
understood separately.
• Modularity is an important characteristic of a good design
solution.
• But, even with this, how can we compare the modularity of two
alternate design solutions?
• From an inspection of the module structure, it is at least possible
to intuitively form an idea as to which design is more modular.
• But, can we quantitatively measure the modularity of a design
solution?
• Unless we are able to quantitatively measure the modularity of a
design solution, it will be hard to say which design solution is
more modular than another.
• Unfortunately, there are no quantitative metrics available yet to
directly measure the modularity of a design.
• However, we can quantitatively characterize the modularity of a
design solution based on the cohesion and coupling existing in
the design.
• A software design with high cohesion and low coupling among
modules is the effective problem decomposition.
Layered design

• A layered design is one in which when the call relations among

different modules are represented graphically, it would result in
a tree-like diagram with clear layering.
• In a layered design solution, the modules are arranged in a
hierarchy of layers.
• A module can only invoke functions of the modules in the layer
immediately below it.
• The higher layer modules can be considered to be similar to
managers that invoke (order) the lower layer modules to get
certain tasks done.
• A layered design can be considered to be implementing control
abstraction, since a module at a lower layer is unaware of
(about how to call) the higher layer modules.
• When a failure is detected while executing a module, it is
obvious that the modules below it can possibly be the source of
the error.
• This greatly simplifies debugging since one would need to
concentrate only on a few modules to detect the error.
• A layered design can make the design solution easily
understandable, since to understand the working of a module,
one would at best have to understand how the immediately lower
layer modules work without having to worry about the functioning
of the upper layer modules.
Functional independence

• the term functional independence, we mean that a module

performs a single task and needs very little interaction with
other modules.
• A module that is highly cohesive and also has low coupling with
other modules is said to be functionally independent of the
other modules.
• Functional independence is a key to any good design.
Advantages

• Error isolation: Whenever an error exists in a module, functional

independence reduces the chances of the error propagating to the
other modules.
• a module interaction with other modules is low.
• an error existing in the module is very unlikely to affect the
functioning of other modules.
• a failure is detected, error isolation makes it very easy to locate
the error.
• Scope of reuse: Reuse of a module for the development of other
applications becomes easier.
• A functionally independent module performs some well-defined
and precise task and the interfaces of the module with other
modules are very few and simple.
• A functionally independent module can therefore be easily taken
out and reused in a different program.
• Understandability: When modules are functionally independent,
complexity of the design is greatly reduced.
• This is because of the fact that different modules can be
understood in isolation, since the modules are independent of
each other.