Chapter 5

Software Design
 Software Design
• Design is the highly significant phase in the software
development where the designer plans “how” a
software system should be produced in order to make it
• Functional
• Reliable
• reasonably easy to understand, modify and maintain.

• It is about solution of the problems mentioned in

requirement document.
• Design is a creative activity
• it determines the major characteristics of a system
• Design has great impact on testing and maintenance
• The output of this phase is a design document to be
used for implementing the system
 Definition: Design is a problem-solving process whose
objective is to find and describe a way:
• to implement the system’s functional requirements.
• while respecting the constraints imposed by the
quality, platform and process requirements
including the budget
• and while adhering to general principles of good
design quality
• A designer is faced with a series of design issues
• These are sub-problems of the overall design
problem.
• Each issue normally has several alternative solutions:
design options.
• The designer makes a design decision to resolve each
issue.
• This process involves choosing the best option
from among the alternatives.
 Levels in Design Process
• The design process for software systems often has two
levels.
• Top-level design (System design or conceptual design ):
• Identifies the components needed for the system,
their behavior, and relationships (architectural
design)
• Decides which modules are needed for the system,
the specifications of these modules, and how the
modules should be interconnected.
• Detailed design (Logic design):
• The internal design of the modules, or how the
specifications of the module can be satisfied, is
decided.
• For each module data structures and algorithms are
designed.
• Outcome of detailed design is module specification.
 Strategy of design
• Top-down design
• First design the very high level structure of the
system.
• Then gradually work down to detailed decisions
about low-level constructs.
• Finally arrive at detailed decisions such as:
• the format of particular data items;
• the individual algorithms that will be used.
• Bottom-up design
• Make decisions about reusable low-level utilities.
• Then decide how these will be put together to create
high-level constructs.

bottom-up top-down
 Hybrid Design: Normally a mix of top-down and
bottom-up approaches are used
Top-down design is almost always needed to give the
system a good structure.
Bottom-up design is normally useful so that reusable
components can be created.
 Phases of Design
Architectural design:- Identify sub-systems
Abstract specification:- Specify sub-systems
Interface design:- Describe sub-system interfaces
Component design:- Decompose sub-systems into
components
Data structure design:- Design data structures to hold
problem data
Algorithm design:- Design algorithms for problem
functions
 Requirements
specification

Design acti
vities

Architectural Abstract Interface Component Data Algorithm

design specificatio design design structure design
n design

Software Data
System Interface Component Algorithm
specification structure
architecture specification specification specification
specification

Design pr
oducts
 Principles Leading to Good Design
A design is said to be good design if
Increasing profit by reducing cost and increasing
revenue
Ensuring that we actually conform with the
requirements
Accelerating development
Increasing qualities such as: Usability, Efficiency,
Reliability, Maintainability, Reusability
In order to achieve the design goals (especially for
object oriented systems) we need to follow the following
Divide and conquer Reuse existing
Increase cohesion where designs and code
possible where possible
Decrease coupling where Design for
possible flexibility
Keep the level of Anticipate
abstraction as high as obsolesce
possible Design for
Increase reusability where Portability
possible Design for
Testability
 1: Divide and conquer (Modularity)
• Trying to deal with something big all at once is
normally much harder than dealing with a series of
smaller things.
• A system could be subdivided in the following way
• A distributed system is divided up into clients and
servers - a system is divided up into subsystems – a
subsystem can be divided up into one or more
packages - a package is divided up into classes - A
class is divided up into methods
• Some of the advantages of dividing and tackling a
problem are:-
• Separate people can work on each part.
• An individual software engineer can specialize in his
or her component, becoming expert at it.
• Each individual component is smaller, and therefore
easier to understand.
• Parts can be replaced or changed without having to
replace or extensively change other parts.
• Opportunities arise for making the component
reusable
 2: Increase cohesion where possible
• Cohesion is a measure of the degree to which the
elements of a module are functionally related.
• A subsystem or module has high cohesion if it keeps
together things that are related to each other, and keeps
out other things
• This makes the system as a whole easier to
understand and change
• Type of cohesion:
• Functional, Layer, Communicational, Sequential,
Procedural, Temporal, Utility
 3:Reduce Coupling where possible
• Coupling occurs when there are interdependencies
between one module and another
• When interdependencies exist, changes in one place
will require changes somewhere else.
• A network of interdependencies makes it hard to see
at a glance how some component works.
• Type of coupling: Content, Common, Control, Stamp,
Data, Routine Call, Type use, Inclusion/Import,
External
 Design methods
• Two fundamentally different software design
approaches are: Function-oriented design & Object-
oriented design
• Function oriented design (FOD)
• A system is looked upon 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
sub functions & functions are mapped to a module
structure.
• This can be done either in bottom-up or top-down
fashion
• Example:
• The function to create-new-library- member
consists of the following sub-functions:
• creates the record for a new member,
• assigns a unique membership number,
• prints a bill towards the membership
• Object Oriented Design (OOD)
• System is viewed as a collection of objects (i.e.
entities).
• System state is decentralized among the objects: each
object manages its own state information.
• Similar objects constitute a class: each object is a
member of some class.
• Example: Library Automation Software:
• Each library member is a separate object - with its own data and
functions.
• Functions defined for one object: cannot directly refer to or
change data of other objects.
 Software Architecture
• Software architecture is used for establishing the
overall structure of a software system
• It represents the link between specification and detail
design processes
• Often carried out in parallel with some specification
activities
• During the architecture design choices like using some
type of middleware, back end database, server, or
security component. are made
• Key uses of architectural descriptions are:
• Understanding and communication,
• reuse,
• Construction & evolution
• analysis
 Architecture attributes
• The system architecture affects non-functional
requirements. For instance
• Performance - Localize operations to minimize sub-
system communication. This means use large-grain
components instead of fine-grain components.
• Security - Use a layered architecture with critical
assets in inner layers
• Safety - Isolate safety-critical components
• Maintainability - Use fine-grain, self-contained
components