Unit-III

Software Architecture and

Design
 Content
• Introduction to Software Design,
• Software Architecture: Role of Software Architecture
• Architecture Views
• Component & Connector View
• Design Concepts: Design Principles, Conceptual
Design and Technical Design, Coupling, Cohesion,
Open Closed Principle
• Function-Oriented Design, Object Oriented Design,
High Level Design
 Introduction to Software Design
• Software Design is a mechanism to transform user
requirements into some suitable form, which helps
the programmer in software coding and
implementation.

• It deals with representing the client's requirement,

as described in SRS (Software Requirement
Specification) document into a form, i.e.easily
implementable using programming language.

• The software design phase is the first step in SDLC

(Software Design Life Cycle), which moves the
concentration from the problem domain to the
solution domain.
 Introduction to Software Design
• In software design, we consider the system to be a set of
components or modules with clearly defined behaviors &
boundaries.
• Software design is the process of defining software solutions
to one or more sets of problems.

• One of the main components of software design is

the software requirement analysis (SRA).

• SRA is a part of the software development process that lists

specification used in software engineering.
 Introduction to Software Design
• There are also semi-standard methods like Unified
Modeling Language and Fundamental modeling concepts.

• Furthermore, a software design may be platform

independent or platform-specific, depending upon the
availability of the technology used for the design.
Objectives of Software Design
 Objectives of Software Design
• Correctness:
A good design should be correct i.e. it should correctly implement all
the functionalities of the system.

• Efficiency:
A good software design should address the resources, time and cost
optimization issues.

• Understandability:
A good design should be easily understandable, for which it should be
modular and all the modules are arranged in layers.

• Completeness:
The design should have all the components like data structures,
modules, and external interfaces, etc.
 Objectives of Software Design
• Maintainability:
A good software design should be easily amenable to change
whenever a change request is made from the customer side.
• The design should be so simple so that it can be easily maintainable
by other designers.

• Flexibility: Able to modify on changing needs.

• Consistency: There should not be any inconsistency in the design.

 Software Design Concepts
• The software design concept simply means the idea or
principle behind the design.

• It allows the software engineer to create the model of the

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.
Software Design Concepts
 Software Design Concepts
1) Abstraction- hide relevant data

Abstraction simply means to hide the details to reduce

complexity and increases efficiency or quality.
2) Modularity- subdivide the system
Modularity simply means to divide the system or project into
smaller parts to reduce the complexity of the system or
project.
 3) Architecture- design a structure of
something/software
• focuses on various elements and the data of the
structure.
• 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.
• Refinement is very necessary to find out any error if
present and then to reduce it.
5) 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.

6) Information Hiding- hide the information

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 it can’t be
accessed by any other modules.

7) Refactoring- reconstruct something

Refactoring simply means to reconstruct something in such a

way that it does not affect the behavior or any other features.
 Software Architecture: Role of Software
Architecture

Definition:
The software architecture of a system is the structures of the
system, which comprise software elements, the externally
visible properties of those elements and the relationships
among them.
 Role of Software Architecture
• Some of the important uses that software architecture
descriptions play are:

1. Understanding and communication

2. Reuse
3.Construction and Evolution
4.Analysis
1) Understanding and communication
• An architecture description is primarily to
communicate the architecture to its various
stakeholders
• which include the users who will use the system,
the clients who commissioned the system, the
builders who will build the system and of course
the architects.
• Software architecture descriptions must facilitate
the understanding of systems.
2) Reused
• Architecture descriptions can help software reuse.

• Reuse is considered one of the main techniques by which

productivity can be improved, thereby reducing the cost
of software.

• Architecture also facilitates reuse among products that

are similar and building product families such that the
common parts of these different but similar products can
be reused.
• Ex:Online shopping application
3) Construction and Evolution
• Construction:
• As architecture partitions the system into parts, some
architecture provided partitioning can naturally be used for
constructing the system, which also requires that the system be
broken into parts such that different teams (or individuals) can
separately work on different parts.

• Evolution : A software system also evolves with time.

• During evolution, new features are added to the system.
• The architecture of the system can help in deciding where to
add the new features with minimum complexity and effort and
what the impact on the rest of the system might be of adding
the new features.
4) Analysis
• Analysis will allow the designers to consider alternatives
and select the one that will best suit the needs.

• It is possible to analyze or predict the properties of the

system being built from its architecture.

• For example, the reliability or the performance of the

system can be analyzed.
• Such an analysis can help determine whether the system
will meet the quality and performance requirements and
if not, what needs to be done to meet the requirements.
 Architecture Views
• In software, the different drawings are called views.
• A view represents the system as composed of some types of
elements and relationships between them.
• Different views expose different properties and attributes,
thereby allowing the stakeholders and analysts to properly
evaluate those attributes for the system.
• A view describes a structure of the system.
• Most of the proposed views are
✔ Module
✔ Component and connector
✔ Allocation
Views of Software Architecture.
 1) Module
• In a module view, the system is viewed as a collection of code units, each
implementing some part of the system functionality.

• These views are code-based and do not explicitly represent any runtime structure of
the system.

• Examples of modules are packages, a class, a procedure, a method, a collection of

functions and a collection of classes.

• The relationships between these modules are also code-based and depend on how
code of a module interacts with another module.

• Examples of relationships in this view are:

"is a part of" (i.e., module B is a part of module A)
"uses or depends on" (a module A uses services of module B to perform its own
functions and correctness of module A depends on correctness of module B,)
"generalization or specialization" ( Module B is a generalization of a Module A.)
2) Component and Connector (C&C)
• In a component and connector (C&C) view, the system is viewed as
a collection of runtime entities called components. That is, a
component is a unit which has an identity in the executing system.
• examples of components :Objects (not classes), a collection of
objects, and a process are.
• While executing, components need to interact with others to
support the system services.
• Connectors provide means for this interaction.
• Examples of connectors are pipes and sockets.
• Shared data can also act as a connector. If the components use
some middleware to communicate and coordinate, then the
middleware is a connector.
• Hence, the primary elements of this view are components and
connectors.
3) Allocation
• An allocation view focuses on how the different
software units are allocated to resources like the
hardware, file systems, and people.
• That is, an allocation view specifies the relationship
between software elements and elements of the
environments in which the software system is
executed.
• They expose structural properties like which
processes run on which processor, and how the
system files are organized on a file system.
 Component and Connector View
• Components are usually computational elements or data
stores that have some presence during the system execution.
• Connectors define the means of interaction between these
components.
• A C&C view of the system defines the components, and which
component is connected to which and through what
connector.
• A C&C view describes a runtime structure of the
system—what components exist when the system is
executing and how they interact during the execution.
• The C&C structure is essentially a graph, with
• components as nodes and
• connectors as edges
 Some of the common symbols used for
Components representing commonly found
component types
Connectors
•Interaction between components may be through a
connectors.

•For example, a component may interact with another using the

procedure call mechanism (a connector,) which is provided by
the runtime environment for the programming language.

•Examples are remote procedure call TCP/IP ports and a

protocol like HTTP.

•Connectors need not be binary and a connector may provide a

n-way communication between multiple components.
Example
Design and build a simple system for taking an on-line survey
of students on a campus. There is a set of multiple choice
questions and the proposed system will provide the survey
form to the student, who can fill and submit it online

We also want when user submit form ,he /she also shown the
current result of survey
 Design Concepts
• A particular area provided by design principle for the judgments
of particular aspects of design. We have three types of
principles which are explained below:

1. Division of problems -
The base of these principles is to divide a big problem in to
little parts.
Every little part developed by different programs individually.
Every little part can be individually altered.
For the solution of big problem it is necessary to became
proper coordination between these small pieces of problems.
 Design Concepts
2. Top down design planning -
• When planning of system starts from that target which system
wants to get then that approach is called top down design
planning.
• When we see the desired task is not easy for achieving then
this task divided in parts and these parts is called sub task.

• These sub tasks have some quality which is:

• Size of problem will be small
• Reduce the level of difficulty
• Easy to achieve
 Design Concepts
3. Bottom up design planning -
According to this principle a big problem divided in
two little parts which is called modules and solved
these modules one by one individually so that no
one module can effected each other.
We have two types of approaches.
The top down approach goes from high level to the
lower level.
bottom up approach goes the opposite that mean it
goes lower level to top level.
 Design Concepts
• Bottom up design planning -

• In this approach individual modules are combined with

each other so that a big module can be built which is the
target of this system.
• A good idea is must require for the success of this
approach..
 Design Principles
• Software design should correspond to the analysis model:
• Often a design element corresponds to many requirements,
therefore, we must know how the design model satisfies all the
requirements represented by the analysis model.
• Choose the right programming paradigm:
• A programming paradigm describes the structure of the
software system. Depending on the nature and type of
application, different programming paradigms such as
procedure oriented, object-oriented and prototyping
paradigms can be used.
• Software design should be uniform and integrated:
• Software design is considered uniform and integrated, if the
interfaces are properly defined among the design components
 Design Principles
• Software design should be flexible:
• Software design should be flexible enough to adapt
changes easily. To achieve the flexibility, the basic
design concepts such as abstraction, refinement, and
modularity should be applied effectively.
• Software design should ensure minimal conceptual
(semantic) errors:
• The design team must ensure that major conceptual
errors of design such as ambiguousness and
inconsistency are addressed in advance before dealing
with the syntactical errors present in the design
model.
 Design Principles
Software design should be structured to degrade gently
Software should be designed to handle unusual changes and
circumstances, and if the need arises for termination, it must
do so in a proper manner so that functionality of the
software is not affected.

Software design should represent correspondence between

the software and real-world problem:
The software design should be structured in such away that it
always relates with the real-world problem.
Software reuse:
software components should be designed in such a way that
they can be effectively reused to increase the productivity
 Design Principles
• Designing for testability:
A common practice that has been followed is to keep the
testing phase separate from the design and implementation
phases

• Prototyping:
• Prototyping should be used when the requirements are not
completely defined in the beginning.
• The user interacts with the developer to expand and refine
the requirements as the development proceeds. Using
prototyping, a quick ‘mock-up’ of the system can be
developed.
Coupling and Cohesion
Coupling and Cohesion
Coupling and Cohesion
Coupling
Coupling and Cohesion
 Coupling
• Coupling: Coupling is the measure of the degree of interdependence
between the modules.
• A good software will have low coupling.

• Types of Coupling:
• Data Coupling: If the dependency between the modules is based on the
fact that they communicate by passing only data, then the modules are
said to be data coupled.
• In data coupling, the components are independent to each other and
communicating through data.

• Stamp Coupling In stamp coupling, the complete data structure is passed

from one module to another module.

• Control Coupling: If the modules communicate by passing control

information, then they are said to be control coupled.
 Coupling
• External Coupling: In external coupling, the modules depend
on other modules, external to the software being developed
or to a particular type of hardware. Ex- protocol, external file,
device format, etc.

• Common Coupling: The modules have shared data such as

global data structures. The changes in global data mean
tracing back to all modules which access that data to evaluate
the effect of the change

• Content Coupling: In a content coupling, one module can

modify the data of another module or control flow is passed
from one module to the other module. This is the worst form
of coupling and should be avoided.
 Factors affect the Coupling
1. Type of connection between modules
2. Complexity of the interface
3. Type of information flow between modules

If coupling increases then the interface

complexity increases.
 Cohesion
• Cohesion is a measure of the degree to
which the elements of the module are
functionally related.
• It is the degree to which all elements
directed towards performing a single task
are contained in the component.
Cohesion
 Cohesion
Types of Cohesion:
• Functional Cohesion: A functional cohesion performs the
task and functions. It is an ideal situation.
• Sequential Cohesion: An element outputs some data that
becomes the input for other element, i.e., data flow between
the parts.
• Communicational Cohesion: Two elements operate on the
same input data or contribute towards the same output data.
Example- update record into the database and send it to the
printer.
• Procedural Cohesion: Elements of procedural cohesion
ensure the order of execution. Ex- calculate student GPA, print
student record, calculate cumulative GPA, print cumulative
GPA.
 Cohesion
• Temporal Cohesion: The elements are related by their timing
involved. A module connected with temporal cohesion all the
tasks must be executed in the same time-span.
• Logical Cohesion: The elements are logically related and not
functionally. Ex- A component reads inputs from tape, disk,
and network.
• Coincidental Cohesion: The elements are not
related(unrelated). The elements have no conceptual
relationship between the component.
 Function Oriented Design

• Function Oriented design is a method to

software design where the model is
decomposed into a set of interacting units or
modules where each unit or module has a
clearly defined function.
• Thus, the system is designed from a
functional viewpoint.
 Function Oriented Design -Design Notations
For a function-oriented design, the design can be
represented graphically or mathematically by the
following:
 Function Oriented Design Strategies
• Data Flow Diagram (DFD)
A data flow diagram (DFD) maps out the flow of information
for any process or system.
• Data Dictionaries:
Data dictionaries are simply repositories to store information
about all data items defined in DFDs. At the requirement
stage, data dictionaries contains data items.
• Structure Charts:
It is the hierarchical representation of system which partitions
the system into black boxes (functionality is known to users
but inner details are unknown). Components are read from
top to bottom and left to right
• Pseudo Code:
Pseudo Code is system description in short English like
phrases describing the function.
 Object-Oriented Design
• In the object-oriented design method, the system is
viewed as a collection of objects (i.e., entities).
• The state is distributed among the objects, and each
object handles its state data.
• For example, in a Library Automation Software, each
library representative may be a separate object with
its data and functions to operate on these data.
• Objects have their internal data which represent
their state
• Each object is a member of some class.
• Classes may inherit features from the superclass.
Object-Oriented Design
 Object-Oriented Design
• Objects: All entities involved in the solution design are known
as objects. For example, person, banks, company, and users
are considered as objects.
• Classes: A class defines all the attributes, which an object can
have and methods, which represents the functionality of the
object.
• Messages: Objects communicate by message passing
Messages are often implemented as procedure or
function calls.
• Abstraction In object-oriented design, complexity is handled
using abstraction.
 Object-Oriented Design
• Encapsulation: Encapsulation is also called an information
hiding concept. The data and operations are linked to a single
unit.
• Inheritance: Sub-classes can import, implement, and re-use
allowed variables and functions from their immediate super
classes. This property of OOD is called an inheritance.
• Polymorphism: OOD languages provide a mechanism where
methods performing similar tasks but vary in arguments, can
be assigned the same name. This is known as polymorphism,
which allows a single interface is performing functions for
different types
 High-level design
• High-level design provides a view of the system at an abstract
level. It shows how the major pieces will fit together and
interact with each other.

• A high-level design should also specify assumptions about the

environment in which the finished application will run.
• For example, it should describe the hardware and software
you will use to develop the application.

• The high-level design does not focus on the details of how the
pieces of the application will work.

• The purpose of a high-level design and how it can help you

build an application.
 High-level design
• The architecture diagram provides an overview of an entire
system.

• Identifying the main components that would be developed for

the product and their interfaces.

• The HLD uses possibly nontechnical to mildly technical .

• High-level design explains the architecture that would be used

for developing a software product.

• Identifying the main components that would be developed for

the product and their interfaces.
High-level design
 High-level design
High-level design is:
A graphical representation of the structure of your software system
A document that defines high-level details of each module in your
system, including a module’s interface (including input and output
data types)
Notes on possible algorithms or data structures the module can use
to meet its responsibilities
A list of any non-functional requirements that might impact the
module