UNIT - 3

Software Design

Definition
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation. Software design is the process
by which an agent creates a specification of a software artifact, intended to accomplish
goals, using a set of primitive components and subject to constraints.
A software product is considered a collection of software modules. A module is a part of a
software product which has data and functions together and an interface with other modules to
produce some outcome.
For Example: A banking S/W system consists of various modules like ATM interface, online
transaction, loan management, deposit, and so on. Each of these modules interacts with other modules
to accomplish the banking activities.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.

Software Design Process

Software design yields three levels of results:
• Architectural Design - The architectural design is the highest abstract version of the system.
It identifies the software as a system with many components interacting with each other. At
this level, the designers get the idea of proposed solution domain. The external design
considers the architectural aspects related to business, technology, major data stores, and
structure of the product.
• High Level Design (Physical Design) - The high-level design breaks the ‘single entity-
multiple component’ concept of architectural design(conceptual view) into less-abstracted
view of sub-systems and modules and depicts their interaction with each other. High-level
design focuses on how the system along with all of its components can be implemented in
forms of modules. It recognizes modular structure of each sub-system and their relation and
interaction among each other.
• Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards modules
and their implementations. It defines logical structure of each module and their interfaces to
communicate with other modules.

Characteristics of good software design:

The quality of a software design can be characterized by the application domain.
For example real time software will focus more on efficiency and reliability issues whereas academic
automation s/w will concentrate on understandability and usability issues.
A designer always tries to produce a good design. The desirable characteristics that a good s/w
design should have are as follows:
1. Correctness: A design is said to be correct if it is correctly produced according to the stated
requirements of customers in the SRS. It should fulfill all the functional features, satisfy
constraints, and follow the guidelines. A correct design is more likely to produce accurate
outcomes.
2. Efficiency: It is concerned with performance related issues; for example, optimal utilization of
resources. The design should consume less memory and processor time. Software design and
its implementation should be as fast as required by the user.
 3. Understandability: It should be easy to understand what the module is, how it is connected to
other modules, what data structure is used, and its flow of information. An understandable
design will make the maintenance and implementation tasks easier.
4. Maintainability: A difficult and complex design would take a larger time to be understood and
modified. Therefore, the design should be easy to be modified, should include new features,
should not have unnecessary parts, and it should be easy to migrate it onto another platform.
5. Simplicity: A simple design will improve understandability and maintainability. Introducing a
simple design is rare because a design follows certain steps and criteria. Still designers always
think to “keep it simple” rather than “make it complex”.
6. Completeness: It means that the design includes all the specifications of the SRS. A complete
design may not necessarily be correct. But a correct design can be complete.
7. Verifiability: The design should be able to be verified against the requirements documents
and programs. Interfaces between the modules are necessary for integration and function
prototyping.
8. Portability: The external design mainly focuses on the interface, business, and technology
architectures. These architectures must be able to move a design to another environment. This
may be required when the system is to be migrated onto different platforms.
9. Modularity: A modular design will be easy to understand and modify. Once a modular system
is designed, it allows easy development and repairing of required modules independently.
10. Reliability: This factor depends on the measurement of completeness, consistency, and
robustness in the software design. Nowadays, most people depend and rely on S/W to work
and yield correct results. If there is any unreliable part of software, it can cause major dangers.
11. Reusability: The software design should be standard and generic so that it can be used for
mass production of quality products with small cycle time and reduced cost. The object code,
classes, design patterns, packages, etc., are the reusable parts of software.

Design Principles:
The fundamental concepts or design principles underlining the software design process are:-
1. Abstraction
Abstraction refers to a powerful design tool, which allows software designers to consider
components at an abstract level, while neglecting the implementation details of the
components. IEEE defines abstraction as 'a view of a problem that extracts the
essential information relevant to a particular purpose and ignores the remainder of the
information.'
Each step in the software process is accomplished through various levels of abstraction. At the
highest level, an outline of the solution to the problem is presented whereas at the lower levels, the
solution to the problem is presented in detail.
For example, in the requirements analysis phase, a solution to the problem is presented using
the language of problem environment and as we proceed through the software process, the abstraction
level reduces and at the lowest level, source code of the software is produced.
There are three commonly used abstraction mechanisms in software design namely,
functional abstraction, data abstraction and control abstraction.
i. Functional abstraction: Functional abstraction can be generalized as collections of
subprograms referred to as 'groups'. Within these groups there exist routines which may be
visible or hidden. Visible routines can be used within the containing groups as well as within
other groups, whereas hidden routines are hidden from other groups and can be used within the
containing group only.
ii. Data abstraction: This involves specifying data that describes a data object. For example, the
data object window encompasses a set of attributes (window type, window dimension) that
describe the window object clearly. In this abstraction mechanism, representation and
manipulation details are ignored.
iii. Control abstraction: This states the desired effect, without stating the exact mechanism of
control. For example, if and while statements in programming languages (like C and C++) are
abstractions of machine code implementations, which involve conditional instructions. In the
architectural design level, this abstraction mechanism permits specifications of sequential
subprogram and exception handlers without the concern for exact details of implementation.
 2. Architecture
Software architecture refers to the structure of the system, which is composed of various
components of a program/ system, the attributes (properties) of those components and the relationship
amongst them.
The software architecture does the following:-
• Provides an insight to all the interested stakeholders that enable them to communicate with each
other
• Highlights early design decisions, which have great impact on the software engineering activities
(like coding and testing) that follow the design phase
• Creates intellectual models of how the system is organized into components and how these
components interact with each other.
3. Patterns
A pattern provides a description of the solution to a recurring design problem of some specific
domain in such a way that the solution can be used again and again. The objective of each pattern is to
provide an insight to a designer who can determine the following.
i. Whether the pattern can be reused
ii. Whether the pattern is applicable to the current project
iii. Whether the pattern can be used to develop a similar but functionally or structurally different
design pattern.
Types of Design Patterns
i. Architectural patterns: These patterns are high-level strategies that refer to the overall
structure and organization of a software system. i.e., they define the elements of a software
system such as subsystems, components, classes, relationship between the elements along with
the rules and guidelines for specifying these relationships. Note that architectural patterns are
often considered equivalent to software architecture.
ii. Design patterns: These patterns are medium-level strategies that are used to solve design
problems. They provide a means for the refinement of the elements of a software system and
Specific design elements such as relationship among components or mechanisms that affect
component-to- component interaction. Note that design patterns are often considered
equivalent to software components.
iii. Idioms: These patterns are low-level patterns, which are programming-language specific. They
describe the implementation of a software component, the method used for interaction among
software components, etc., in a specific programming language. Note that idioms are often
termed as coding patterns.
iv. Modularity: Modularity is achieved by dividing the software into uniquely named and
addressable components, which are also known as modules. A complex system (large
program) is partitioned into a set of discrete modules in such a way that each module can be
developed independent of other modules. After developing the modules, they are integrated
together to meet the software requirements. Note that larger the number of modules a system is
divided into, greater will be the effort required to integrate the modules.

Fig: Modules in Software Programs

Modularizing a design helps to plan the development in a more effective manner,
accommodate changes easily, conduct testing and debugging effectively and efficiently, and conducts
maintenance work without adversely affecting the functioning of the software.
4. Information Hiding
Modules should be specified and designed in such a way that the data structures and
processing details of one module are not accessible to other modules. They pass only that much
information to each other, which is required to accomplish the software functions. The way of hiding
unnecessary details is referred to as information hiding. IEEE defines information hiding as 'the
technique of encapsulating software design decisions in modules in such a way that the module's
interfaces reveal as little as possible about the module's inner workings; thus each module is a 'black
box' to the other modules in the system.
Fig: Information Hiding

5. Stepwise Refinement
Stepwise refinement is a top-down design strategy used for decomposing a system from a
high level of abstraction into a more detailed level (lower level) of abstraction. Software designers
start the stepwise refinement process by creating a sequence of compositions for the system being
designed. Each composition is more detailed than the previous one and contains more components
and interactions.
To have a clear understanding of the concept, let us consider an example of stepwise
refinement. Every computer program comprises input, process, and output.
1. INPUT
• Get user's name (string) through a prompt.
• Get user's grade (integer from 0 to 100) through a prompt and validate.
2. PROCESS
3. OUTPUT
This is the first step in refinement. The input phase can be refined further as given here.
1. INPUT
o Get user's name through a prompt.
o Get user's grade through a prompt.
o While (invalid grade) Ask again:
2. PROCESS
3. OUTPUT
Note: Stepwise refinement can also be performed for PROCESS and OUTPUT phase.

6. Refactoring
Refactoring is an important design activity that reduces the complexity of module design
keeping its behaviour or function unchanged. Refactoring can be defined as a process of modifying a
software system to improve the internal structure of design without changing its external behavior.
During the refactoring process, the existing design is checked for any type of flaws like redundancy,
poorly constructed algorithms and data structures, etc., in order to improve the design.
For example, a design model might yield a component which exhibits low cohesion (like a
component performs four functions that have a limited relationship with one another). Software
designers may decide to refactor the component into four different components, each exhibiting high
cohesion. This leads to easier integration, testing, and maintenance of the software components.

7. Structural Partitioning
When the architectural style of a design follows a hierarchical nature, the structure of the
program can be partitioned either horizontally or vertically. Structural partitioning provides the
following benefits.
• The testing and maintenance of software becomes easier.
• The negative impacts spread slowly.
• The software can be extended easily.
In horizontal partitioning, the control modules are used to communicate between functions
and execute the functions.
In vertical partitioning, the functionality is distributed among the modules--in a top-down
manner.
The modules at the top level called control modules perform the decision-making and do
little processing whereas the modules at the low level called worker modules perform all input,
computation and output tasks.
8. Concurrency
Computer has limited resources and they must be utilized efficiently as much as possible. To
utilize these resources efficiently, multiple tasks must be executed concurrently. Every system must
be designed to allow multiple processes to execute concurrently, whenever possible.
For example, if the current process is waiting for some event to occur, the system must
execute some other process in the mean time.
However, concurrent execution of multiple processes sometimes may result in undesirable
situations such as an inconsistent state, deadlock, etc. Thus, the system must control the concurrent
execution and synchronize the actions of concurrent processes. One way to achieve synchronization is
mutual exclusion, which ensures that two concurrent processes do not interfere with the actions of
each other.
In software design, concurrency is implemented by splitting the software into multiple independent units
of execution, like modules and executing them in parallel. In other words, concurrency provides
capability to the software to execute more than one part of code in parallel to each other.
Example
The spell check feature in word processor is a module of software, which runs along side the word
processor itself.

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. A modular design focuses on
minimizing the interconnection between the modules. The most common criterions are functional
independency; levels of abstraction; information hiding; functional diagrams, such as DFD, modular
programming languages, coupling, and cohesion. An effective modular system has low coupling and
high cohesion. So, coupling and cohesion are most popular criterions used to measure the
modularity in a system. The primary characteristics of neat module decomposition are high cohesion
and low coupling.

1. Coupling:
Coupling between two modules is a measure that defines the degree of interdependence or
interaction between the modules of a program. A module having high cohesion and low coupling is
said to be functionally independent of other modules. If two modules interchange large amounts of
data, then they are highly interdependent.
The degree of coupling between two modules depends on their interface complexity. The
interface complexity is basically determined by the number of types of parameters that are
interchanged while invoking the functions of the module. Module coupling can be Tightly or Loosely
coupled based on the dependencies. The lower the coupling, the better the program.

Fig: Module Coupling

Classification of Coupling:
Six types of coupling can occur between any two modules.

Fig: Types of Coupling

i) 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.
ii) Stamp coupling: Two modules are stamp coupled, if they communicate using a composite data
item such as a record in PASCAL or a structure in C.
iii) 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.
iv) External Coupling: It occurs when two modules share an externally imposed data format,
communication protocol, or device interface. All the modules share the same I/O device or the
external environment.
v) Common coupling: Two modules are common coupled, if they share data through some global
data items.
vi) Content coupling: Content coupling exists between two modules, if they share code, e.g. a branch
from one module into another module.

2. Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module. A good software design implies clean decomposition of the problem into modules, and the
neat arrangement of these modules in a hierarchy. The greater the cohesion, the better is the program
design.
Cohesion is a measure of functional strength of a module. A module having high cohesion and
low coupling is said to be functionally independent of other modules. By the term functional
independence, we mean that a cohesive module performs a single task or function. A functionally
independent module has minimal interaction with other modules.
Classification of cohesion:
The different classes of cohesion that a module may possess are depicted in fig. given below:

Fig: Types of Cohesion

i) Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a set of tasks
that relate to each other very loosely. In this case, the module contains a random collection of
functions.
For example, in a transaction processing system (TPS), the get-input, print- error, and summarize-
members functions are grouped into one module. The grouping does not have any relevance to the
structure of the problem.
ii) 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.
An example of logical cohesion is the case where a set of print functions generating different output
reports are arranged into a single module.
iii) 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.
The set of functions responsible for initialization, start-up, shutdown of some process, etc. exhibit
temporal cohesion.
iv) 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.
v) Communicational cohesion: A module is said to have communicational cohesion, if all functions
of the module refer to or update the same data structure, e.g. the set of functions defined on an array
or a stack.
vi) Sequential cohesion: A module is said to possess sequential cohesion, if the elements of a module
form the parts of sequence, where the output from one element of the sequence is input to the next.
For example, in a TPS, the get-input, validate-input, sort-input functions are grouped into one module.
vii) Functional cohesion: Functional cohesion is said to exist, if different elements of a module
cooperate to achieve a single function.
For example, a module containing all the functions required to manage employees’ pay-roll exhibits
functional cohesion.

Differences between cohesion and coupling are given below:

COHESION COUPLING

Cohesion is the concept of intra module. Coupling is the concept of inter module.

Cohesion represents the relationship within Coupling represents the relationships between

Increasing in cohesion is good for Increasing in coupling is avoided for software.

Cohesion represents the functional Coupling represents the independence among

Highly cohesive gives the best software. Where as loosely coupling gives the best

In cohesion, module focuses on the single In coupling, modules are connected to the other

Design Methodologies:
A Design methodology provides the techniques and guidelines for the design process of a
system. There are different design processes for different design methodologies. The goal of all
design methodologies is to produce a design for the solution of a system. A design process consists of
various design activities. The most popular design methodologies are:
1) Function Oriented Design
2) Object Oriented Design

1) Function Oriented Design:

In function-oriented design, the system is comprised of many smaller sub-systems known as
functions. These functions are capable of performing significant task in the system. Function oriented
design inherits some properties of structured design where divide and conquer methodology is used.
 This design mechanism divides the whole system into smaller functions, which provides means of
abstraction by concealing the information and their operation.. These functional modules can share
information among themselves by means of information passing and using information available
globally.

The following are the salient features of a typical function-oriented design approach:
i. A system is viewed as something that performs a set of functions. Starting at this high-level view of
the system, each function is successively refined into more detailed functions.
For example, consider a function create-new library-member which essentially
creates the record for a new member, assigns a unique membership number to him, and prints a bill
towards his membership charge. This function may consist of the following sub functions:
• Assign-membership-number
• Create-member-record
• Print-bill
Each of these sub-functions may be split into more detailed sub functions and so on.
ii. The system state is centralized and shared among different functions, e.g. data such as member-
records is available for reference and updation to several functions such as:
• Create-new-member
• Delete-member
• Update-member-record

2) Object Oriented Design:

Object oriented design works around the entities and their characteristics instead of functions
involved in the software system. This design strategy focuses on entities and its characteristics.
In the object-oriented design approach, the system is viewed as collection of objects (i.e.
entities). The state is decentralized among the objects and each object manages its own state
information.
For example, in a Library Automation Software, each library member may be a separate object
with its own data and functions to operate on these data. In fact, the functions defined for one object
cannot refer or change data of other objects. Objects have their own internal data which define their
state. Similar objects constitute a class. In other words, each object is a member of some class.
Conceptually, objects communicate by message passing.

Function-oriented vs. object-oriented design approach

The following are some of the important differences between function-oriented and object-
oriented design.
• Unlike function-oriented design methods, in OOD, the basic abstraction are not real-world
functions such as sort, display, track, etc, but real-world entities such as employee, picture,
machine, radar system, etc.
For example in OOD, an employee pay-roll software is not developed by designing
functions such as update-employee-record, getemployee-address, etc. but by designing objects such
as employees, departments, etc.
• In OOD, state information is not represented in a centralized shared memory but is distributed
among the objects of the system.
For example, while developing an employee pay-roll system, the employee data such as the
names of the employees, their code numbers, basic salaries, etc. are usually implemented as global
data in a traditional programming system; whereas in an object-oriented system these data are
distributed among different employee objects of the system.
Objects communicate by message passing. Therefore, one object may discover the state
information of another object by interrogating it. Of course, somewhere or other the real-world
functions must be implemented. In OOD, the functions are usually associated with specific real-
world entities (objects); they directly access only part of the system state information.
• Function-oriented techniques such as System Analysis/System Design group functions together as
a group, they constitute a higher-level function. On the other hand, object-oriented techniques
group functions together on the basis of the data they operate on.

To illustrate the differences between the object-oriented and the function-oriented design approaches,
 an example can be considered.
Example: Fire-Alarm System
The owner of a large multi-stored building wants to have a computerized fire alarm system for his
building. Smoke detectors and fire alarms would be placed in each room of the building. The fire
alarm system would monitor the status of these smoke detectors. Whenever a fire condition is
reported by any of the smoke detectors, the fire alarm system should determine the location at which
the fire condition is reported by any of the smoke detectors, the fire alarm system should determine
the location at which the fire condition has occurred and then sound the alarms only in the
neighbouring locations. The fire alarm system should also flash an alarm message on the computer
console. After a fire condition has been successfully handled, the fire alarm system should support
resetting the alarms by the fire fighting personnel.
In the function-oriented program, the system state is centralized and several functions accessing
this central data are defined.
In the object oriented program, an appropriate number of instances of the class detector and alarm
should be created. In case of the object-oriented program, the state information is distributed among
various sensor and alarm objects.

Software design process can be perceived as series of well-defined steps. Though it varies according
to design approach (function oriented or object oriented, yet it may have the following steps involved:
• A solution design is created from requirements or previously used system and/or system sequence
diagram.
• Objects are identified and grouped into classes on behalf of similarity in attribute characteristics.
• Class hierarchy and relation among them is defined.
• Application framework is defined.

Software Design Approaches

Two generic approaches for software designing are:

Top Down Design

A system is composed of more than one sub-systems and it contains a number of components.
Further, these sub-systems and components may have their own set of sub-systems and components and
creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then decomposes it to achieve
more than one sub-system or component based on some characteristics. Each sub-system or component
is then treated as a system and decomposed further. This process keeps on running until the lowest level
of system in the top-down hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining the more specific
part of it. When all components are composed the whole system comes into existence.
Top-down design is more suitable when the software solution needs to be designed from scratch and
specific details are unknown.

Bottom-up Design
The bottom up design model starts with most specific and basic components. It proceeds with
composing higher level of components by using basic or lower level components. It keeps creating
higher level components until the desired system is not evolved as one single component. With each
higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing system,
where the basic primitives can be used in the newer system.