Software Design

Software Design: Software Design deals with transforming requirements as described in

SRS document into form which can be implemented using programming language.

Software design is the last software engineering action within the modeling activity and sets the
stage for construction (code generation and testing).

The flow of information during software design is illustrated in Figure below. The analysis model,
manifested by scenario-based, class-based, flow-oriented and behavioral elements, feed the
design task.

The architectural design defines the relationship between more structural elements of the software,
the architectural styles and design patterns that can be used to achieve the requirements defined
for the system, and the constraints that affect the way in which the architectural design can be
implemented.

The architectural design can be derived from the System Specs, the analysis model, and
interaction of subsystems defined within the analysis model.

Fig: Translating analysis model into design model

Component -
sc enario- based f low- oriented L evel Design
elements elements
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
Int erfac e Design
Analysis Model

A rc hit ec t ural Design

c lass- based behavioral
elements elements
class diagrams state diagrams
analysis packages sequence diagrams
CRC models Dat a/ Class Design
collaboration diagrams

Design Model
9-2 SEPA, 6/e Instructor’s Guide

The interface design describes how the software communicates with systems that interpolate with
it, and with humans who use it. An interface implies a flow of information (data, and or control) and
a specific type of behavior.
The component-level design transforms structural elements of the software architecture into a
procedural description of software components.

The importance of software design can be stated with a single word – quality. Design is the place
where quality is fostered in software engineering. Design provides us with representations of
software that can be assessed for quality. Design is the only way that we can accurately translate
a customer’s requirements into a finished software product or system.

Design Process and Design Quality

Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software.

Initially, the blueprint depicts a holistic view of software, i.e. the design is represented at a high-
level of abstraction.

Throughout the design process, the quality of the evolving design is assessed with a series of
formal technique reviews or design walkthroughs.

Three characteristics serve as a guide for the evaluation of a good design:

 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

Quality Guidelines

In order to evaluate the quality of a design representation, we must establish technical criteria for
good design.

1. A design should exhibit an architecture that:

(1) Has been created using recognizable architectural styles or patterns,
(2) Is composed of components that exhibit good design characteristics, and
(3) Can be implemented in an evolutionary fashion
a. For smaller systems, design can sometimes be developed linearly.

2. A design should be modular; that is, the software should be logically partitioned into elements
or subsystems
3. A design should contain distinct representations of data, architecture, interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be implemented
and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.

Quality Attributes

Hewlett-Packard developed a set of software quality attributes that has been given the acronym
FURPS. The FURPS quality attributes represent a target for all software design:

 Functionality: is assessed by evaluating the features set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
 Usability: is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
 Reliability: is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure, the ability to recover from failure, and the predictability
of the program.
 Performance: is measured by processing speed, response time, resource consumption,
throughput, and efficiency.
 Supportability: combines the ability to extend the program extensibility, adaptability,
serviceability  maintainability. In addition, testability, compatibility, configurability
etc.
9-4 SEPA, 6/e Instructor’s Guide

Design Concepts
This section discusses many significant design concepts (abstraction, refinement, modularity,
architecture, patterns, refactoring, functional independence, information hiding, and OO design
concepts).
Abstraction
At the highest level of abstraction, a solution is stated in broad terms using the language of the
problem environment. At lower levels of abstraction, a more detailed description of the solution is
provided.
As we move through different levels of abstraction, we work to create procedural and data
abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and
limited function. An example of a procedural abstraction would be the word open for a door.
A data abstraction is a named collection of data that describes a data object. In the context
of the procedural abstraction open, we can define a data abstraction called door. Like any data
object, the data abstraction for door would encompass a set of attributes that describe the door
(e.g. door type, swing direction, weight).
Architecture
Software architecture alludes to the “overall structure of the software and the ways in which
the structure provides conceptual integrity for a system.”
In its simplest from, architecture is the structure of organization of program components (modules),
the manner in which these components interact, and the structure of data that are used by the
components.
The goal of software design is to derive an architectural framework of a system.
The architectural design can be represented using one or more of a number of different models

Patterns

A design pattern “conveys the essence of a proven design solution to a recurring problem within a
certain context amidst computing concerns.”
A design pattern describes a design structure that solves a particular design problem within a
specific context

Modularity

Software architecture and design patterns embody modularity; that is, software is divided into
separately named and addressable components, sometimes called modules that are integrated to
satisfy problem requirements.
 Software Design
Monolithic software (large program composed of a single module) cannot be easily grasped by a
software engineer. The number of control paths, span of reference, number of variables, and
overall complexity would make understanding close to impossible.

It is the compartmentalization of data and function. It is easier to solve a complex problem when
you break it into manageable pieces. “Divide-and-conquer”

Don’t over-modularize. The simplicity of each small module will be overshadowed by the
complexity of integration “Cost”.

Information Hiding

It is about controlled interfaces. Modules should be specified and design so that information
(algorithm and data) contained within a module is inaccessible to other modules that have
no need for such information.

Hiding implies that effective modularity can be achieved by defining by a set of independent
modules that communicate with one another only that information necessary to achieve software
function.

The use of Information Hiding as a design criterion for modular systems provides the greatest
benefits when modifications are required during testing and later, during software maintenance.
Because most data and procedures are hidden from other parts of the software, inadvertent errors
introduced during modifications are less likely to propagate to other location within the software.

Functional Independence

The concept of functional Independence is a direct outgrowth of modularity and the concepts of
abstraction and information hiding.

Design software so that each module addresses a specific sub-function of requirements and has a
simple interface when viewed from other parts of the program structure.

Functional independence is a key to good design, and design is the key to software quality.
Independence is assessed using two qualitative criteria: cohesion and coupling.

Cohesion is an indication of the relative functional strength of a module.

Coupling is an indication of the relative interdependence among modules.

A cohesive module should do just one thing.

Coupling is a qualitative indication of the degree to which a module is connected to other modules
and to the outside world “lowest possible”.
9-6 SEPA, 6/e Instructor’s Guide

Refinement

It is the elaboration of detail for all abstractions. It is a top down strategy. A program is developed
by successfully refining levels of procedural detail.A hierarchy is developed by decomposing a
macroscopic statement of function (a procedural abstraction) in a stepwise fashion until
programming language statements are reached.

Refactoring

It is a reorganization technique that simplifies the design of a component without changing its
function or behavior. When software is re-factored, the existing design is examined for
redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed
data structures, or any other design failures that can be corrected to yield a better design.

Data Abstraction

Procedural Abstraction
 Software Design

“The overall structure of the software and the ways in which that structure provides
conceptual integrity for a system.”

Modular Design

easier to build, easier to change, easier to fix ...

Modularity: Trade-offs

What is the "right" number of modules for a specific software design?

Information Hiding
9-8 SEPA, 6/e Instructor’s Guide

Stepwise Refinement
Functional

Independe
nce

COHESION - the degree to which a

module performs one and only one
function.

COUPLING - the degree to which a

module is "connected" to other
modules in the system.

Sizing Modules: Two Views

What's How big

inside?? is it??

MODULE
 Software Design

Refactoring

 Fowler [FOW99] defines refactoring in the following manner:

 "Refactoring is the process of changing a software system in such a way that it does not
alter the external behavior of the code [design] yet improves its internal structure.”
 When software is re-factored, the existing design is examined for
 redundancy
 unused design elements
 inefficient or unnecessary algorithms
 poorly constructed or inappropriate data structures,
 or any other design failure that can be corrected to yield a better design.

Design classes

As the design model evolves, the software team must define a set of design classes that refines
the analysis classes and creates a new set of design classes.
Five different classes’ types are shown below:

1. User Interface classes: define all abstractions that are necessary for HCI.
2. Business domain classes: are often refinements of the analysis classes defined earlier. The
classes identify the attributes and services that are required to implement some element of
the business domain.
3. Process classes: implement lower-level business abstractions required to fully manage the
business domain classes.
4. Persistent classes: represent data stores that will persist beyond the execution of the
software.
5. System classes: implement software management and control functions that enable the
system to operate and communicate within its computing environment and with the outside
world.

Inheritance, Messages, Polymorphism

9-10 SEPA, 6/e Instructor’s Guide

The Design Model

high

analysis model

class diagrams
analysis packages
use-cases - text class diagrams
Requirements:
CRC models use-case diagrams constraints
analysis packages
collaboration diagrams
activity diagrams CRC models interoperability
data flow diagrams swim lane diagrams collaboration diagrams targets and
control-flow diagrams collaboration diagrams data flow diagrams
processing narratives state diagrams control-flow diagrams
configuration
sequence diagrams processing narratives
state diagrams
sequence diagrams

design class realizations

subsystems
collaboration diagrams technical interface component diagrams
design class realizations
design design classes
subsystems
Navigation design activity diagrams
collaboration diagrams
GUI design sequence diagrams
component diagrams
design model design classes
refinements to: activity diagrams
refinements to: sequence diagrams
component diagrams
design class realizations design classes
subsystems activity diagrams
low collaboration diagrams sequence diagrams deployment diagrams

architecture interface component-level deployment-level

elements elements elements elements

process dimension

 Data design elements

Data design creates a model of data and/ or information that is represented at high level of
abstraction .
 Architectural design elements “similar to the floor plan of a house”
 “You can use an eraser on the drafting table or a sledge hammer on the construction
site.”
 Application domain
 Analysis classes, their relationships, collaborations and behaviors are transformed
into design realizations
 Patterns and “styles”
 Software Design
 Interface level design elements “The way in which utilities connections come into the
house and are distributed among the rooms”
 the user interface (UI)
 external interfaces to other systems, devices, networks or other producers or
consumers of information
 internal interfaces between various design components.

MobilePhone

WirelessPDA

Cont rolPanel

LCDdisplay
LEDindicators
keyPadCharacteristics K eyPad
speaker
wirelessInterf ace

readKeyStroke()
decodeKey ()
displayStatus()
lightLEDs()
sendControlMsg()

<<int erfac e>>

K eyPad

readKeystroke()
decodeKey()

Figure 9 .6 UML int erfac e represent at ion for Cont rolPa ne l

 Component level design elements

It is equivalent to a set of detailed drawings and specs for each room in a house.
The component-level design for software fully describes the internal detail of each software
component.

 Deployment level design elements

Indicates how software functionally and subsystem terms will be allocated within the
physical computing environment that will support the software.
9-12 SEPA, 6/e Instructor’s Guide

Pattern-Based Software Design

Describing a Design Pattern

 The best designers in any field have an ability to see patterns that characterize a problem
and corresponding patterns that can be combined to create a solution. Throughout design
process s/w eng should look for every opportunity to reuse existing design patterns(when
they meet needs of design) rather than creating new ones.

Using Patterns in Design

Design patterns can be used throughout software design.

Once the analysis model has been developed, the designer can examine a detailed representation
of the problem to be solved and the constraints that are imposed by the problem.

The problem description is examined at various levels of abstraction to determine if it is amenable

or agreeable to one or more of the following design patterns:

Architectural patterns:
These patterns define the overall structure of the software, indicate the relationships among
subsystems and software components, and define the rules for specifying relationships among the
elements (classes, packages, components, subsystems) of the architecture.

Design patterns: These patterns address a specific element of the design such as an aggregation
of components to solve some design problems, relationships among components, or the
mechanisms for effecting component-to-component communication.

Idioms: Sometimes called coding patterns, these language-specific patterns generally implement
an algorithmic element of a component, a specific interface protocol, or a mechanism for
communication among components.