Unit-3

Software Design Concepts

Software Design is the process of transforming user requirements into a 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, this phase aims to transform the SRS document into a design
document.
The following items are designed and documented during the design phase:
1. Different modules are required.
2. Control relationships among modules.
3. Interface among different modules.
4. Data structure among the different modules.
5. Algorithms are required to be implemented among the individual modules.

Objectives of Software Design

1. Correctness: A good design should be correct i.e., it should correctly implement
all the functionalities of the system.
2. Efficiency: A good software design should address the resources, time, and cost
optimization issues.
3. Flexibility: A good software design should have the ability to adapt and
accommodate changes easily. It includes designing the software in a way, that
allows for modifications, enhancements, and scalability without requiring
significant rework or causing major disruptions to the existing functionality.
4. Understandability: A good design should be easily understandable, it should be
modular, and all the modules are arranged in layers.
5. Completeness: The design should have all the components like data structures,
modules, external interfaces, etc.
6. Maintainability: A good software design aims to create a system that is easy to
understand, modify, and maintain over time. This involves using modular and
well-structured design principles e.g.,(employing appropriate naming conventions
and providing clear documentation). Maintainability in Software and design also
enables developers to fix bugs, enhance features, and adapt the software to
changing requirements without excessive effort or introducing new issues.

Software Design Concepts

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, and the logic, or thinking
behind how you will design software. It allows the software engineer to create the model of
the system 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.
There are many concepts of software design and some of them are given below:
 Software Design Concepts

Points to be Considered While Designing Software

1. Abstraction (Hide Irrelevant data): Abstraction simply means to hide the
details to reduce complexity and increase 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.
2. 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 can divide the system
into components then the cost would be small.
3. 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.
4. 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 a process of developing or presenting the
software or system in a detailed manner which means elaborating a system or
 software. Refinement is very necessary to find out any error if present and then to
reduce it.
5. Pattern (a Repeated form): A 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.
6. 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.
7. 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 impacting the behavior or its functions.
Fowler has defined refactoring as “the process of changing a software system in
a way that it won’t impact the behavior of the design and improves the internal
structure”.

Different levels of Software Design

There are three different levels of software design. They are:
1. Architectural Design: The architecture of a system can be viewed as the overall
structure of the system and 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.
2. 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.
3. 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.

Design Models for Architecture

The software needs the architectural design to represents the design of software. IEEE
defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development of
a computer system.” The software that is built for computer-based systems can exhibit one
of these many architectural styles.
Each style will describe a system category that consists of :

 A set of components(eg: a database, computational modules) that will perform a

function required by the system.
 The set of connectors will help in coordination, communication, and cooperation
between the components.
 Conditions that how components can be integrated to form the system.
  Semantic models that help the designer to understand the overall properties of the
system.
The use of architectural styles is to establish a structure for all the components of the system.

1] Data Centred Architectures:

 A data store will reside at the center of this architecture and is accessed frequently
by the other components that update, add, delete or modify the data present within
the store.
 The figure illustrates a typical data centered style. The client software access a
central repository. Variation of this approach are used to transform the repository
into a blackboard when data related to client or data of interest for the client
change the notifications to client software.
 This data-centered architecture will promote integrability. This means that the
existing components can be changed and new client components can be added to
the architecture without the permission or concern of other clients.
 Data can be passed among clients using blackboard mechanism.

Advantage of Data centered architecture

 Repository of data is independent of clients
 Client work independent of each other
 It may be simple to add additional clients.
 Modification can be very easy

Data centered architecture

2] Data flow architectures:

 This kind of architecture is used when input data is transformed into output data
through a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe and filter
and it has a set of components called filters connected by lines.
 Pipes are used to transmitting data from one component to the next.
 Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form. The filters
don’t require any knowledge of the working of neighboring filters.
  If the data flow degenerates into a single line of transforms, then it is termed as
batch sequential. This structure accepts the batch of data and then applies a series
of sequential components to transform it.

Advantages of Data Flow architecture

 It encourages upkeep, repurposing, and modification.
 With this design, concurrent execution is supported.

Disadvantage of Data Flow architecture

 It frequently degenerates to batch sequential system
 Data flow architecture does not allow applications that require greater user
engagement.
 It is not easy to coordinate two different but related streams

Data Flow architecture

3] Call and Return Architectures: It is used to create a program that is easy to scale
and modify. Many sub-styles exist within this category. Two of them are explained below.

 Remote procedure call architecture: This components is used to present in a

main program or sub program architecture distributed among multiple computers
on a network.
 Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy.
Main program contains number of subprograms that can invoke other
components.
4] Object Oriented Architecture: The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The coordination and communication
between the components are established via the message passing.

Characteristics of Object Oriented architecture

 Object protect the system’s integrity.
 An object is unaware of the depiction of other items.

Advantage of Object Oriented architecture

 It enables the designer to separate a challenge into a collection of autonomous
objects.
 Other objects are aware of the implementation details of the object, allowing
changes to be made without having an impact on other objects.

5] Layered architecture:

 A number of different layers are defined with each layer performing a well-
defined set of operations. Each layer will do some operations that becomes closer
to machine instruction set progressively.
 At the outer layer, components will receive the user interface operations and at
the inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.
 One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication
system.
 Layered architecture

Abstraction

An abstraction is a tool that enables a designer to consider a component at an abstract level

without bothering about the internal details of the implementation. Abstraction can be used for
existing element as well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the user of
the function.

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the
basis for Object Oriented design approaches.

Coupling and Cohesion

Module Coupling

In 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.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of
relations between the modules. That is, the coupling increases as the number of calls between
modules increase or the amount of shared data is large. Thus, it can be said that a design with
high coupling will have more errors.

Types of Module 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.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module
belong together. Thus, cohesion measures the strength of relationships between pieces of
functionality within a given module. For example, in highly cohesive systems, functionality is
strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or

"low cohesion."

Types of Modules Cohesion

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.

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 Cohesion shows the relationship within the module.
modules.

Coupling shows the Cohesion shows the module's

relative independence between the modules. relative functional strength.

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

In coupling, modules are linked to the other In cohesion, the module focuses on a single thing.
modules.

S/W Design Approaches

S/W Design approach refers to the approach that is taken to design a software system. There
are several strategies that can be used to design software systems, including the following:
1. Top-Down Design: This strategy starts with a high-level view of the system and
gradually breaks it down into smaller, more manageable components.
2. Bottom-Up Design: This strategy starts with individual components and builds the
system up, piece by piece.
 3. Iterative Design: This strategy involves designing and implementing the system in
stages, with each stage building on the results of the previous stage.
4. Incremental Design: This strategy involves designing and implementing a small
part of the system at a time, adding more functionality with each iteration.
5. Agile Design: This strategy involves a flexible, iterative approach to design, where
requirements and design evolve through collaboration between self-organizing and
cross-functional teams.

Bottom-up approach:
The design starts with the lowest level components and subsystems. By using these
components, the next immediate higher-level components and subsystems are created or
composed. The process is continued till all the components and subsystems are composed into
a single component, which is considered as the complete system. The amount of abstraction
grows high as the design moves to more high levels.
By using the basic information existing system, when a new system needs to be created, the
bottom-up strategy suits the purpose.

Bottom-up approach

Advantages of Bottom-up approach:

 The economics can result when general solutions can be reused.
 It can be used to hide the low-level details of implementation and be merged with
the top-down technique.
Disadvantages of Bottom-up approach:
 It is not so closely related to the structure of the problem.
 High-quality bottom-up solutions are very hard to construct.
 It leads to the proliferation of ‘potentially useful’ functions rather than the most
appropriate ones.

Top-down approach:
Each system is divided into several subsystems and components. Each of the subsystems is
further divided into a set of subsystems and components. This process of division facilitates
forming a system hierarchy structure. The complete software system is considered a single
entity and in relation to the characteristics, the system is split into sub-systems and components.
The same is done with each of the sub-systems.
This process is continued until the lowest level of the system is reached. The design is started
initially by defining the system as a whole and then keeps on adding definitions of the
subsystems and components. When all the definitions are combined, it turns out to be a
complete system.
For the solutions of the software that need to be developed from the ground level, a top-down
design best suits the purpose.

Top-down approach

Advantages of Top-down approach:

 The main advantage of the top-down approach is that its strong focus on
requirements helps to make a design responsive according to its requirements.
Disadvantages of Top-down approach:
 Project and system boundaries tend to be application specification-oriented. Thus,
it is more likely that the advantages of component reuse will be missed.
 The system is likely to miss, the benefits of a well-structured, simple architecture.
 Hybrid Design:
It is a combination of both top-down and bottom-up design strategies. In this, we
can reuse the modules.

Advantages of using a S/W Design Approaches:

1. Improved quality: A well-designed system can improve the overall quality of the
software, as it provides a clear and organized structure for the software.
2. Ease of maintenance: A well-designed system can make it easier to maintain and
update the software, as the design provides a clear and organized structure for the
software.
3. Improved efficiency: A well-designed system can make the software more efficient,
as it provides a clear and organized structure for the software that reduces the
complexity of the code.
4. Better communication: A well-designed system can improve communication
between stakeholders, as it provides a clear and organized structure for the software
that makes it easier for stakeholders to understand and agree on the design of the
software.
5. Faster development: A well-designed system can speed up the development
process, as it provides a clear and organized structure for the software that makes it
easier for developers to understand the requirements and implement the software.
Disadvantages of using a S/W Design Approaches:
1. Time-consuming: Designing a system can be time-consuming, especially for large
and complex systems, as it requires a significant amount of documentation and
analysis.
2. Inflexibility: Once a system has been designed, it can be difficult to make changes
to the design, as the process is often highly structured and documentation-intensive.

Function Oriented Design :

Function oriented design is the result of focusing attention to the function of the program.
This is based on the stepwise refinement. Stepwise refinement is based on the iterative
procedural decomposition. Stepwise refinement is a top-down strategy where a program is
refined as a hierarchy of increasing levels of details.
We start with a high level description of what the program does. Then, in each step, we take
one part of our high level description and refine it. Refinement is actually a process of
elaboration. The process should proceed from a highly conceptual model to lower level
details. The refinement of each module is done until we reach the statement level of our
programming language.
2. 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. Thus, it is
orthogonal to function -oriented design. Object-oriented design begins with an examination
of the real world “things”. These things are characteristics individually in terms of their
attributes and behavior.
Objects are independent entities that may readily be changed because all state and
representation information is held within the object itself. Object may be distributed and may
execute sequentially or in parallel. Object oriented technology contains following three
keywords –

1. Objects –
Software package are designed and developed to correspond with real world
entities that contain all the data and services to function as their associated entities
messages.

2. Communication –
Communication mechanisms are established that provide the means by which
object work together.

3. Methods –
Methods are services that objects perform to satisfy the functional requirements
of the problem domain. Objects request services of the other objects through
messages.
Difference Between Function Oriented Design and Object Oriented Design :
COMPARISON FUNCTION ORIENTED
FACTORS DESIGN OBJECT ORIENTED DESIGN

The basic abstractions are not the

The basic abstractions, which
real world functions but are the data
Abstraction are given to the user, are real
abstraction where the real world
world functions.
entities are represented.

Function are grouped together on

Functions are grouped together
the basis of the data they operate
Function by which a higher level
since the classes are associated with
function is obtained.
their methods.

carried out using structured

execute analysis and structured design Carried out using UML
i.e, data flow diagram

In this approach the state

In this approach the state
information is not represented in a
State information is often
centralized memory but is
information represented in a centralized
implemented or distributed among
shared memory.
the objects of the system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the use

Begins by identifying objects and
Begins basis case diagrams and the
classes.
scenarios.

In function oriented design we

Decompose decompose in We decompose in class level.
function/procedure level.

This approach is mainly used This approach is mainly used for

Use for computation sensitive evolving system which mimics a
application. business or business case.
Software Design Specification:

Software Design Specification is a written document that provides a description of a software

product in terms of architecture of software with various components with specified
functionality.
The design specification addresses different aspects of the design model and is completed as
the designer refines his representation of the software. These design documents are written
by software engineers/designers or project managers and further passed to the software
development team to give them an overview of what needs to be built and how.

S.No Software Design Document Module, Subpart

1. Existing software documentation

2. System Documentation
Reference Documents 3. Vendor(hardware or software)
01. documents
4. Technical reference

1. Processing narrative
Modules for each module 2. Interface description
02. 3. Design language(or other) description
4. Modules used

1. System objective
2. Hardware, software and human
Scope interfaces
3. Major software functions
03. 4. Externally defined database
5. Major design constraints, limitations

1. Data description
Design Description 2. Derived program structure
04.
3. Interface within structure

1. Test guidelines
Test Provisions 2. Integration strategy
05.
3. Special considerations

06. Packaging 1. Special program overlay provisions

2. Transfer consideration

File Structure and global 1. External Files structure

07. data 2. Global data
3. File and data cross – reference
S.No Software Design Document Module, Subpart

08. Requirement cross-reference 1. cross-reference

Importance of Design Documentation:

1. Requirements are well understood: With proper documentation, we can remove
inconsistencies and conflicts about the requirements. Requirements are well understood by
every team member.
2. Architecture/Design of product: Architecture/Design documents give us a complete
overview of how the product look like and better insight to the customer/user about their
product.
3. New Person can also work on the project: New person to the project can very easily
understand the project through documentations and start working on it. So, developers need
to maintain the documentation and keep upgrading it according to the changes made in the
product/software.
4. Everything is well Stated: This documentation is helpful to understand each and every
working of the product. It explains each and every feature of the product/software.
5. Proper Communication: Through documentation, we have good communication with
every member who is part of the project/software. Helpful in understanding role and
contribution of each and every member.
Control Flow Graph (CFG)

A Control Flow Graph (CFG) is the graphical representation of control flow

or computation during the execution of programs or applications. Control flow graphs are
mostly used in static analysis as well as compiler applications, as they can accurately
represent the flow inside a program unit. The control flow graph was originally developed
by Frances E. Allen..
Characteristics of Control Flow Graph
1. The control flow graph is process-oriented.
2. The control flow graph shows all the paths that can be traversed during a program
execution.
3. A control flow graph is a directed graph.
4. Edges in CFG portray control flow paths and the nodes in CFG portray basic
blocks.
There exist 2 designated blocks in the Control Flow Graph:
1. Entry Block: The entry block allows the control to enter into the control flow
graph.
2. Exit Block: Control flow leaves through the exit block.
Hence, the control flow graph comprises all the building blocks involved in a flow diagram
such as the start node, end node and flows between the nodes.
General Control Flow Graphs
Control Flow Graph is represented differently for all statements and loops. Following images
describe it:
1. If-else
2. While

3. do-while

4. for

Example
if A = 10 then
if B > C
A=B
else A = C
endif
endif
print A, B, C
Flowchart of above example will be:
Control Flow Graph of above example will be:
Advantage of CFG
There are many advantages of a control flow graph.
1. It can easily encapsulate the information per each basic block.
2. It can easily locate inaccessible codes of a program and syntactic structures such
as loops are easy to find in a control flow graph.