Software Design

Concepts
SDD: What is a software design
document?
IEEE defines software design documentation as “a description of
software created to facilitate analysis, planning, implementation,
and decision-making”. In essence, a software design document
(SDD) explains how a software product or a feature will be built
to meet a set of technical requirements. If the requirements
document describes the “what” of your project, the design
document focuses on the “how”.
Why write a software design document?

 The software design document in its original form may indeed

be irrelevant today. A rigid, long, MS Word document that
becomes outdated the moment it's written and is never read by
anyone has no place in modern software development.
 Ourworkflows have evolved – and so should the concept of a
design document.
A software design document—sometimes called software
design specification—is a detailed plan for developing a piece
of software. An SDD should outline the finished software's
functionality (specs) and your team's plans to build it (timeline,
goals, etc.).

In essence, a software design document (SDD) explains how a

software product or a feature will be built to meet a set of
technical requirements. If the requirements document
describes the “what” of your project, the design document
focuses on the “how”.
While an important function of a software design doc is to
communicate the technical details of the planned solution to
your team, it's not the only reason why it's written. The
objective is no longer to create a detailed, fixed blueprint for
your design and serve as documentation later on. It's to help
you organize your thoughts before wasting a bunch of time
implementing the wrong solution or the solution to the wrong
problem. It's a collaborative exercise for your entire team.
Software Design is the process to transform the user
requirements into some suitable form, which helps the
programmer in software coding and implementation.
During the software design phase, the design
document is produced, based on the customer
requirements as documented in the SRS document.
Hence the aim of this phase is to transform the SRS
document into the design document.
The following items are designed and
documented during the design phase: 
• Different modules required.
• Control relationships among modules.
• Interface among different modules.
• Data structure among the different modules.
• Algorithms required to implement among the individual
modules.
 The software design concept simply means the idea or
principle behind the design. It describes how you plan
to solve the problem of designing software, the logic, or
thinking behind how you will design software. It allows
the software engineer to create the model of the system
or software or product that is to be developed or built.
The software design concept provides a supporting and
essential structure or model for developing the right
software.
The following points should be
considered while designing Software: 
 Abstraction- hide Irrelevant data 
Abstraction simply means to hide the details to reduce
complexity and increases efficiency or quality. Different levels of
Abstraction are necessary and must be applied at each stage of
the design process so that any error that is present can be
removed to increase the efficiency of the software solution and to
refine the software solution. The solution should be described in
broad ways that cover a wide range of different things at a higher
level of abstraction and a more detailed description of a solution
of software should be given at the lower level of abstraction.
1.Modularity-
subdivide the system 
Modularity simply means dividing the system or project into smaller parts
to reduce the complexity of the system or project. In the same way,
modularity in design means subdividing a system into smaller parts so that
these parts can be created independently and then use these parts in different
systems to perform different functions. It is necessary to divide the software
into components known as modules because nowadays there are different
software available like Monolithic software that is hard to grasp for
software engineers. So, modularity in design has now become a trend and is
also important. If the system contains fewer components then it would mean
the system is complex which requires a lot of effort (cost) but if we are able
to divide the system into components then the cost would be small.
Architecture- design a structure of something 
Architecture simply means a technique to design a
structure of something. Architecture in designing
software is a concept that focuses on various
elements and the data of the structure. These
components interact with each other and use the
data of the structure in architecture.
 Refinement- removes impurities 
Refinement simply means to refine something to remove
any impurities if present and increase the quality. The
refinement concept of software design is actually a
process of developing or presenting the software or
system in a detailed manner that means to elaborate a
system or software. Refinement is very necessary to find
out any error if present and then to reduce it.
Pattern- a repeated form 
The pattern simply means a repeated form or
design in which the same shape is repeated
several times to form a pattern. The pattern in
the design process means the repetition of a
solution to a common recurring problem within
a certain context.
 Information Hiding- hide the information 
Information hiding simply means to hide the
information so that it cannot be accessed by an
unwanted party. In software design, information
hiding is achieved by designing the modules in a
manner that the information gathered or contained in
one module is hidden and can’t be accessed by any
other modules.
 Refactoring- reconstruct something 
Refactoring simply means reconstructing something in such a
way that it does not affect the behavior of any other features.
Refactoring in software design means reconstructing the
design to reduce complexity and simplify it without affecting
the behavior or its functions. Fowler has defined refactoring
as “the process of changing a software system in a way that it
won’t affect the behavior of the design and improves the
internal structure”.
Different levels of Software Design: 

 Architectural Design: 
The architecture of a system can be viewed as the
overall structure of the system & the way in which
structure provides conceptual integrity of the system.
The architectural design identifies the software as a
system with many components interacting with each
other. At this level, the designers get the idea of the
proposed solution domain. 
Preliminary or high-level design: 

Here the problem is decomposed into a set of modules,

the control relationship among various modules
identified, and also the interfaces among various
modules are identified. The outcome of this stage is
called the program architecture. Design representation
techniques used in this stage are structure chart and
UML. 
Detailed design: 

Once the high-level design is complete, a detailed

design is undertaken. In detailed design, each
module is examined carefully to design the data
structure and algorithms. The stage outcome is
documented in the form of a module specification
document. 
Modularization

 Modularization is a technique to divide a

software system into multiple discrete and
independent modules, which are expected to be
capable of carrying out task(s) independently.
These modules may work as basic constructs for
the entire software. Designers tend to design
modules such that they can be executed and/or
compiled separately and independently.
Advantage of modularization:

• Smaller components are easier to maintain

• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the
program
• Components with high cohesion can be re-used again
• Concurrent execution can be made possible
• Desired from security aspect
Coupling and Cohesion:

 When a software program is modularized, its tasks are

divided into several modules based on some
characteristics. As we know, modules are set of
instructions put together in order to achieve some tasks.
They are though, considered as single entity but may
refer to each other to work together. There are
measures by which the quality of a design of modules
and their interaction among them can be measured.
These measures are called coupling and cohesion.
Cohesion

 Cohesion is a measure that defines the degree of intra-

dependability within elements of a module. The greater the
cohesion, the better is the program design.
 There are seven types of cohesion, namely –
• Co-incidental cohesion - It is unplanned and random cohesion,
which might be the result of breaking the program into smaller
modules for the sake of modularization. Because it is unplanned,
it may serve confusion to the programmers and is generally not-
accepted.
1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of
a module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element
of a module form the components of the sequence, where the output from one
component of the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if
all tasks of the module refer to or update the same data structure, e.g., the set of
functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of
purpose of the module are all parts of a procedure in which particular sequence of
steps has to be carried out for achieving a goal, e.g., the algorithm for decoding a
message.
5. Temporal Cohesion: When a module includes functions
that are associated by the fact that all the methods must be
executed in the same time, the module is said to exhibit
temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive
if all the elements of the module perform a similar operation.
For example Error handling, data input and data output, etc.
7. Coincidental Cohesion: A module is said to have
coincidental cohesion if it performs a set of tasks that are
associated with each other very loosely, if at all.
Coupling

Coupling is a measure that defines the level

of inter-dependability among modules of a
program. It tells at what level the modules
interfere and interact with each other. The
lower the coupling, the better the program.
n software engineering, the coupling is the degree of
interdependence between software modules. Two
modules that are tightly coupled are strongly
dependent on each other. However, two modules that
are loosely coupled are not dependent on each
other. Uncoupled modules have no interdependence
at all within them.
Type of coupling
1. No Direct Coupling: There is
no direct coupling between
M1 and M2.

 In this case, modules are

subordinates to different
modules. Therefore, no direct
coupling.
 2. Data Coupling: When
data of one module is
passed to another module,
this is called data
coupling.
3. Stamp Coupling: Two modules are stamp coupled if they communicate
using composite data items such as structure, objects, etc. When the module
passes non-global data structure or entire structure to another module, they
are said to be stamp coupled. For example, passing structure variable in C
or object in C++ language to a module.
4. Control Coupling: Control Coupling exists among two modules if data
from one module is used to direct the structure of instruction execution in
another.
5. External Coupling: External Coupling arises when two modules share
an externally imposed data format, communication protocols, or device
interface. This is related to communication to external tools and devices.
 6. Common Coupling: Two
modules are common coupled
if they share information
through some global data
items.
 7. Content Coupling: Content
Coupling exists among two
modules if they share code,
e.g., a branch from one module
into another module.
Design Verification

 The output of software design process is design documentation, pseudo

codes, detailed logic diagrams, process diagrams, and detailed description of
all functional or non-functional requirements.
 The next phase, which is the implementation of software, depends on all
outputs mentioned above.
 It is then becomes necessary to verify the output before proceeding to the next
phase. The early any mistake is detected, the better it is or it might not be
detected until testing of the product. If the outputs of design phase are in
formal notation form, then their associated tools for verification should be used
otherwise a thorough design review can be used for verification and validation.
Differentiate between Coupling and
Cohesion:
Coupling Cohesion
Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.

Coupling shows the relationships between modules. Cohesion shows the relationship within the module.

Coupling shows the relative independence between the modules. Cohesion shows the module's relative functional strength.

While creating, you should aim for low coupling, i.e., dependency among While creating you should aim for high cohesion, i.e., a cohesive component/
modules should be less. module focuses on a single function (i.e., single-mindedness) with little
interaction with other modules of the system.

In coupling, modules are linked to the other modules. In cohesion, the module focuses on a single thing.
 Cyclomatic complexity of a code section is the
quantitative measure of the number of linearly
independent paths in it. It is a software metric used to
indicate the complexity of a program. It is computed using
the Control Flow Graph of the program. The nodes in the
graph indicate the smallest group of commands of a
program, and a directed edge in it connects the two nodes
i.e. if second command might immediately follow the first
command.
 Forexample, if source code contains no control
flow statement then its cyclomatic complexity will
be 1 and source code contains a single path in it.
Similarly, if the source code contains one if
condition then cyclomatic complexity will be 2
because there will be two paths one for true and the
other for false. 
Mathematically, for a structured program, the directed graph inside
control flow is the edge joining two basic blocks of the program as
control may pass from first to second. 
So, cyclomatic complexity M would be defined as,

M = E – N + 2P 
where, 
E = the number of edges in the control flow graph 
N = the number of nodes in the control flow graph 
P = the number of connected components 
Steps that should be followed in calculating
cyclomatic complexity and test cases design are: 
 
• Construction of graph with nodes and edges from
code.
• Identification of independent paths.
• Cyclomatic Complexity Calculation
• Design of Test Cases
Let a section of code as such: 

A = 10
IF B > C THEN
A = B
ELSE
A = C
ENDIF
Print A
Print B  Control Flow
Graph of code:

Print C
The cyclomatic complexity
calculated for above code
will be from control flow
graph. The graph shows
seven shapes(nodes), seven
lines(edges), hence
cyclomatic complexity is 7-
7+2 = 2. (M = E – N + 2P )
Use of Cyclomatic Complexity: 

• Determining the independent path executions thus proven to

be very helpful for Developers and Testers.
• It can make sure that every path have been tested at least once.
• Thus help to focus more on uncovered paths.
• Code coverage can be improved.
• Risk associated with program can be evaluated.
• These metrics being used earlier in the program helps in
reducing the risks.
 Advantages of Cyclomatic Complexity:.

• It can be used as a quality metric, gives relative

complexity of various designs.
• It is able to compute faster than the Halstead’s metrics.
• It is used to measure the minimum effort and best
areas of concentration for testing.
• It is able to guide the testing process.
• It is easy to apply.
Software Maintenance:

Software Maintenance is the process of modifying a

software product after it has been delivered to the
customer. The main purpose of software
maintenance is to modify and update software
applications after delivery to correct faults and to
improve performance. 
Need for Maintenance – 

Software Maintenance must be performed in order to: 

 Correct faults.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system features, and
telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.
Categories of Software Maintenance – 

1. Corrective maintenance: 
Corrective maintenance of a software product may be essential
either to rectify some bugs observed while the system is in use, or to
enhance the performance of the system. 
2. Adaptive maintenance: 
This includes modifications and updations when the customers need
the product to run on new platforms, on new operating systems, or
when they need the product to interface with new hardware and
software. 
 
Perfective maintenance: 
A software product needs maintenance to support the new features
that the users want or to change different types of functionalities of
the system according to the customer demands. 
Preventive maintenance: 
This type of maintenance includes modifications and updations to
prevent future problems of the software. It goals to attend
problems, which are not significant at this moment but may cause
serious issues in future. 
Reverse Engineering – 

Reverse Engineering is processes of extracting knowledge or design

information from anything man-made and reproducing it based on
extracted information. It is also called back Engineering. 
Software Reverse Engineering – 
Software Reverse Engineering is the process of recovering the design
and the requirements specification of a product from an analysis of it’s
code. Reverse Engineering is becoming important, since several
existing software products, lack proper documentation, are highly
unstructured, or their structure has degraded through a series of
maintenance efforts. 
Why Reverse Engineering? 

• Providing proper system documentation.

• Recovery of lost information.
• Assisting with maintenance.
• Facility of software reuse.
• Discovering unexpected flaws or faults.
Used of Software Reverse Engineering
– 
• Software Reverse Engineering is used in software
design, reverse engineering enables the developer or
programmer to add new features to the existing
software with or without knowing the source code.
• Reverse engineering is also useful in software testing,
it helps the testers to study the virus and other
malware code .