DESIGN ENGINEERING

TE (SEM V)
 Software Design Specification
Concept:
• Software design specification provides an
overview of the entire design document.
• SDS document describes all data, architectural,
interface and component-level design for the
software.
• The data design transforms the information
domain model created during analysis into the
data structures that will be required to implement
the software.
 Software Design Specification
• The data objects and relationships defined in the entity
relationship diagram and the detailed data content
depicted in the data dictionary provide the basis for the
data design activity.
• The architectural design defines the relationship between
major structural elements of the software, the “design
patterns” that can be used to achieve the requirements that
have been defined for the system.
• The interface design describes how the software
communicates within itself, with systems that interoperate
with it, and with humans who use it.
• The component-level design transforms structural elements
of the software architecture into a procedural description of
software components.
 Software Design Specification
Design and Software Quality:
• The design must implement all of the explicit
requirements contained in the analysis model,
and it must accommodate all of the implicit
requirements desired by the customer.
• The design must be a readable, understandable
guide for those who generate code and for those
who test and subsequently support the software.
• The design should provide a complete picture of
the software, addressing the data, functional, and
behavioral domains from an implementation
perspective.
 Software Design Specification
Design Principles:
• The design process should not suffer from “tunnel
vision”
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should be structured to accommodate
change
• The design should be assessed for quality as it is being
created.
• The design should be reviewed to minimize conceptual
(semantic) errors.
 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.
• Modular design unintentionally follows the rules of
‘divide and conquer’ problem-solving strategy this is
because there are many other benefits attached with
the modular design of a software.
 Cohesion and Coupling
• 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 cohesion and coupling.
Cohesion and Coupling
 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.
 Cohesion
Seven types of cohesion-
• 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.
• Logical cohesion - When logically categorized elements are
put together into a module, it is called logical cohesion.
• Temporal Cohesion - When elements of module are
organized such that they are processed at a similar point in
time, it is called temporal cohesion.
• Procedural cohesion - When elements of module are
grouped together, which are executed sequentially in order
to perform a task, it is called procedural cohesion.
 Cohesion
Seven types of cohesion-
• Communicational cohesion - When elements of
module are grouped together, which are executed
sequentially and work on same data (information), it is
called communicational cohesion.
• Sequential cohesion - When elements of module are
grouped because the output of one element serves as
input to another and so on, it is called sequential
cohesion.
• Functional cohesion - It is considered to be the highest
degree of cohesion, and it is highly expected. Elements
of module in functional cohesion are grouped because
they all contribute to a single well-defined function. It
can also be reused.
 Cohesion
Advantages:
• High cohesion among system components results in
better program design
• High cohesion components can be easily reused
• High cohesion components are more reliable
Disadvantages:
• Low cohesion components are difficult to maintain
• Low cohesion components cannot be reused
• Low cohesion components are difficult to understand
• Low cohesion components are less reliable
 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.
 Coupling
Five levels of coupling:
• Content coupling - When a module can directly access or modify
or refer to the content of another module, it is called content level
coupling.
• Common coupling- When multiple modules have read and write
access to some global data, it is called common or global coupling.
• Control coupling- Two modules are called control-coupled if one
of them decides the function of the other module or changes its
flow of execution.
• Stamp coupling- When multiple modules share common data
structure and work on different part of it, it is called stamp
coupling.
• Data coupling- Data coupling is when two modules interact with
each other by means of passing data (as parameter). If a module
passes argument list as parameter, then the receiving module
should use all the elements in the list.
 Coupling
Advantages:
• Low coupling components do not force ripple effect to
other components
• Low coupling components can be reused
• With low coupling among components, system can
built faster.
Disadvantages:
• High coupling components are difficult to understand
• High coupling components forces change in other
components if one component changes
• High coupling shows down the development process.
Advantages of High Cohesion and Low
Coupling
Benefits of high cohesion:
• Reliability: Related functions are contained in a single
module
• Maintainability: Debugging tends to be contained in a
single module
• Reusability: Classes that have concentrated
functionalities are not polluted with useless functions
Benefits of low coupling:
• Maintainability: Changes are confined in a single
module
• Testability: Modules involved in unit testing can be
limited to a minimum
• Readability: Classes that need to be analyzed are kept
at a minimum
 Software Architecture
• Requirements of the software should be transformed
into an architecture that describes the software’s top
level structure and recognizes its components.
• The software architecture of a program or computing
system is the structure or structures of the system,
which comprise software components, the externally
visible properties of those components, and the
relationships among them.
• IEEE described architectural design a set of hardware
and software components and their interfaces to set
up the framework for the development of a computer
system
 Architecture Design
There is a distinct difference between the terms
architecture and design. A design is an instance of
an architecture similar to an object being an
instance of a class. For example, consider the
client-server architecture. I can design a
network-centric software system in many different
ways from this architecture using either the Java
platform (Java EE) or Microsoft platform (.NET
framework). So, there is one architecture, but many
designs can be created based on that architecture.
 Architectural Styles
Each style describes a system category that
encompasses:
• A set of components that perform a function
• A set of connectors that enable communication,
coordination and cooperation among components
• Constraints that define how components can be
integrated to form the system
• Semantic models that enable a designer to
understand the overall properties of a system
 Architectural Styles
Following are the common Architectural Styles
• Data-centered architectures
• Data flow architectures
• Call and return architectures
• Object-oriented architectures
• Layered architectures
 Data-centered architectures
A data store (e.g., a file or database) resides at
the center of this architecture and is accessed
frequently by other components that update,
add, delete, or otherwise modify data within the
store.
 Data-centered architectures
Two Components:
1. Central Data
2. Data Accessor

Some advantages of the data-centered

architecture are listed below.
• Clients operate independently of one another.
• Data repository is independent of the clients.
• It adds scalability (that is, new clients can be added easily).
• It supports modifiability.
 Data-flow architectures
This architecture is applied when input data are
to be transformed through a series of
computational or manipulative components into
output data.
 Call and return architectures
This architectural style enables you to achieve a
program structure that is relatively easy to
modify and scale.
 Call and return architectures
• This is also called as a Main program/subprogram
architecture
• In this, function is decomposed into a control
hierarchy where the main program invokes a number
of program components, which in turn may invoke
other components.
• In this, components of the main or subprogram
architecture are distributed over a network across
multiple computers.
 Object-oriented architectures
• The components of a system encapsulate data
and the operations that must be applied to
manipulate the data. Communication and
coordination between components are
accomplished via message passing
 Layered architectures
• A number of different layers are defined, each
accomplishing operations that progressively
become closer to the machine instruction set.
• At the outer layer, components service user
interface operations. At the inner layer,
components perform operating system
interfacing. Intermediate layers provide utility
services and application software functions.
Layered architectures