Unit 4

Software Design
CHAPTER OVERVIEW AND COMMENTS
The intent of this chapter is to provide an introduction to the design process and to
describe fundamental design concepts that are essential to an understanding of any
software design method. Basic concepts are introduced and a fundamental design model
is discussed. The design model consists of the data design, architectural design, interface
design, and component-level design.

The goal of design engineering is to produce a model or representation that exhibits

firmness, commodity, and delight.

To accomplish this, a designer must practice diversification and then convergence.

Belady states that “diversification is the acquisition of a repertoire of alternatives, the raw
material of design: components, component solutions, and knowledge, all contained in
catalogs, textbooks, and the mind.”

Once this diverse set of information is assembled, the designer must pick and choose
elements from the repertoire that meet the requirements designed by requirement
engineering and the analysis models.

As this occurs, alternatives are considered and rejected, and the design engineer
converges on “one particular configuration of components, and thus the creation of the
final product.”

1. Software Design Fundamentals

1 Design within the Context of Software Engineering
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.

Component -
sc enario- based f low- oriented L evel Design
element s 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

Arc 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

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

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 of Design (FURPS)

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.

3 Design Concepts
This section discusses many significant design concepts (abstraction, refinement,
modularity, architecture, patterns, refactoring, functional independence, information
hiding, and OO design concepts).
3.1 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).
3.2 Architecture
The complete structure of the software is known as software architecture.
 Structure provides conceptual integrity for a system in a number of ways.
 The architecture is the structure of program modules where they interact with each
other in a specialized way.
 The components use the structure of data.
  The aim of the software design is to obtain an architectural framework of a
system.
 The more detailed design activities are conducted from the framework.

3.3 Patterns
A design pattern describes a design structure that solves a particular design problem
within a specific context and amid “forces” that may have an impact on the manner in
which the pattern is applied and used.

The intent of each design pattern is to provide a description that enables a designer to
determine:
1. whether the pattern is applicable to the current work,
2. whether the pattern can be reused, and
3. whether the pattern can serve as a guide for developing a similar, but functionally
or structurally different pattern.

3.4 Modularity
Software is divided into separately named and addressable components, sometimes called
modules that are integrated to satisfy problem requirements.

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”

3.5 Information Hiding

Modules must be specified and designed so that the information like algorithm and data
presented in a module is not accessible for other modules not requiring that information.

3.6 Functional Independence

The functional independence is the concept of separation and related to the concept of
modularity, abstraction and information hiding.
The functional independence is accessed using two criteria i.e 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”.
3.7. Refinement
 Refinement is a top-down design approach.
 It is a process of elaboration.
 A program is established for refining levels of procedural details.
  A hierarchy is established by decomposing a statement of function in a stepwise
manner till the programming language statement are reached.
3.8 Refactoring
 It is a reorganization technique which simplifies the design of components
without changing its function behaviour.
 Refactoring is the process of changing the software system in a way that it does
not change the external behaviour of the code still improves its internal structure.
3.9 Design classes
 The model of software is defined as a set of design classes.
 Every class describes the elements of problem domain and that focus on features
of the problem which are user visible.
4 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
conf iguration
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 elements
 Data model --> data structures
 Data model --> database architecture
 Architectural 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.” Frank Lloyd Wright
 Application domain
 Analysis classes, their relationships, collaborations and behaviors are
transformed into design realizations
 Patterns and “styles”
 Interface 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
wirelessInterface

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

<<int erfac e>>

K eyPad

readKeystroke()
decodeKey()

Figure 9 .6 UML int erface represent at ion for Cont rolPanel

  Component 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 elements

Indicates how software functionally and subsystem terms will be allocated within
the physical computing environment that will support the software.

5 Pattern-Based Software Design

5.1 Describing a Design Pattern

 The best designers in any field have an uncanny ability to see patterns that
characterize a problem and corresponding patterns that can be combined to create
a solution
 A description of a design pattern may also consider a set of design forces.
 Design forces describe non-functional requirements (e.g., ease of
maintainability, portability) associated the software for which the pattern
is to be applied.
 Forces define the constraints that may restrict the manner in which the
design is to be implemented.
 Design forces describe the environment and conditions that must exist to
make the design pattern applicable.
 The pattern characteristics (classes, responsibilities, and collaborations) indicate
the attributes of the design that may be adjusted to enable the pattern to
accommodate a variety of problems.
 These attributes represent characteristics of the design that can be searched (via
database) so that an appropriate pattern can be found.
 Finally, guidance associated with the use of a design pattern provides an
indication of the ramification of design decisions.
 The name of design patterns should be chosen with care.
 One of the key technical problems in software reuse is the inability to find
existing patterns when hundreds or thousands of candidate patterns exist.
 The search of the “right” pattern is aided immeasurably by a meaningful pattern
name.

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

Frameworks

 A framework is not an architectural pattern, but rather a skeleton with a collection

of “plug points” (also called hooks and slots) that enable it to be adapted to a
specific problem domain.
 Gamma et al note that:
 Design patterns are more abstract than frameworks.
 Design patterns are smaller architectural elements than frameworks
 Design patterns are less specialized than frameworks

2 . EFFECTIVE MODULAR DESIGN

Modularity has become an accepted approach in all engineering disciplines. A modular
design reduces complexity, facilitates change (a critical aspect of software
maintainability), and results in easier implementation by encouraging parallel
development of different parts of a system.

13.5.1 Functional Independence

The concept of functional independence is a direct outgrowth of modularity and the
concepts of abstraction and information hiding. Functional independence is achieved by
developing modules with "single-minded" function and an "aversion" to excessive
interaction with other modules. Stated another way, we want to design software so that
each module addresses a specific subfunction of requirements and has a simple interface
when viewed from other parts of the program structure. It is fair to ask why independence
is important. Software with effective modularity, that is, independent modules, is easier to
develop because function may be compartmentalized and interfaces are simplified
(consider the ramificaTions when development is conducted by a team). Independent
modules are easier to maintain (and test) because secondary effects caused by design or
code modification are limited, error propagation is reduced, and reusable modules are
possible. To summarize, functional independence is a key to good design, and design is
the key to software quality. A module is “single minded” if you can describe it with a
simple sentence— subject, predicate, object.
Independence is measured using two qualitative criteria: cohesion and coupling.
Cohesion
is a measure of the relative functional strength of a module
.
Coupling
is a measure of the relative interdependence among modules.

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. Module communications don’t contain tramp data.
Example-customer billing system.
 Stamp Coupling In stamp coupling, the complete data structure is passed from
one module to another module. Therefore, it involves tramp data. It may be
necessary due to efficiency factors- this choice made by the insightful designer,
not a lazy programmer.
 Control Coupling: If the modules communicate by passing control information,
then they are said to be control coupled. It can be bad if parameters indicate
completely different behavior and good if parameters allow factoring and reuse of
 functionality. Example- sort function that takes comparison function as an
argument.
 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. So it has got disadvantages
like difficulty in reusing modules, reduced ability to control data accesses and
reduced maintainability.
 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.

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. Basically, cohesion is the
internal glue that keeps the module together. A good software design will have high
cohesion.

Types of Cohesion:
 Functional Cohesion: Every essential element for a single computation is
contained in the component. 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. It occurs naturally in functional
programming languages.
  Communicational Cohesion: Two elements operate on the same input data or
contribute towards the same output data. Example- update record int the database
and send it to the printer.
 Procedural Cohesion: Elements of procedural cohesion ensure the order of
execution. Actions are still weakly connected and unlikely to be reusable. Ex-
calculate student GPA, print student record, calculate cumulative GPA, print
cumulative GPA.
 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. This cohesion contains the code for initializing all the parts of the system.
Lots of different activities occur, all at init time.
 Logical Cohesion: The elements are logically related and not functionally. Ex- A
component reads inputs from tape, disk, and network. All the code for these
functions is in the same component. Operations are related, but the functions are
significantly different.
 Coincidental Cohesion: The elements are not related(unrelated). The elements
have no conceptual relationship other than location in source code. It is accidental
and the worst form of cohesion. Ex- print next line and reverse the characters of a
string in a single component.

3. Classical Model: Design Methods

3.1 Data design
 The systematic analysis principles applied to function and behavior should also be
applied to data.
 All data structures and the operations to be performed on each should be identified.
 A data dictionary should be established and used to defined both data and program
design
 Low-level data design decisions should be deferred until late in the design process.
 The representation of data structures should be known only to those modules that
must make direct use of the data contained within the structure.
 A library of useful data structure and the operations that may be applied to them
should be developed.
 A software design and programming language should support the specification and
realization of abstract data type.
3.2 Architectural design
Introduction:  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.

Taxonomy of Architectural styles:

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. 
2. Data flow architectures: 
 This kind of architecture is used when input data to be 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 pipes. 
 Pipes are used to transmit 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. 
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. 

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. 

3.3 Interface design

 The design of interface between software modules
 The design of interface between the software and other external entities
 The design of the interface between a human and a computer
  Design model: data, architecture, interface, procedural representations
 User model: novices, knowledgeable, intermittent users, knowledgeable, frequent
users
 Interface design guidelines
 General interaction
 Information display
 Data input

3.4. Procedural design

Component-level design, also called procedural design, occurs after data, architectural,
and interface designs have been established

What is it ? Data, architectural, and interface design must be translated into operational
software. To accomplish this, the design must be represented at a level of abstraction that
is close to code.

Component-level design establishes :-

The algorithmic detail required to manipulate data structures,
Effect communication between software components via their interfaces, and
Implement the processing algorithms allocated to each component.

Who does it ? A software engineer performs component-level design.

Why is it important? You have to be able to determine whether the program will work
before you build it. The component-level design represents the software in a way that
allows you to review the details of the design for correctness and consistency with earlier
design representations (i.e., the data, architectural, and interface designs). It provides a
means for assessing whether data structures, interfaces, and algorithms will work.

What are the steps? Design representations of data, architecture, and interfaces form the
foundation for component-level design. The processing narrative for each component is
translated into a procedural design model using a set of structured programming
constructs. Graphical, tabular, or text-based notation is used to represent the design
approach is to represent the procedural design using some intermediate (e.g., graphical,
tabular, or text-based) representation that can be translated easily into source code

STRUCTURED PROGRAMMING
In the late 1960s, Dijkstra and others proposed the use of a set of constrained logical
constructs from which any program could be formed
The constructs are sequence, condition, and repetition. Sequence implements processing
steps that are essential in the specification of any algorithm. Condition provides the
facility for selected processing based on some logical occurrence, and repetition allows
for looping. These three constructs are fundamental to structured programming—an
important component-level design technique.
The structured constructs were proposed to limit the procedural design of software to a
small number of predictable operations. Complexity metrics indicate that the use of the
structured constructs reduces program complexity and thereby enhances readability,
testability, and maintainability. logical chunks that allow a reader to recognize procedural
elements of a module, rather than reading the design or code line by line Any program,
regardless of application area or technical complexity, can be designed and implemented
using only the three structured constructs

Graphical Design Notation

Figure .1 illustrates three structured constructs

Another graphical design tool, the box diagram, evolved from a desire to develop a
procedural design representation that would not allow violation of the structured
constructs.

1) repetition or if-then-else) is well defined and clearly visible as a pictorial

representation,
(2) arbitrary transfer of control is impossible,
(3) the scope of local and/or global data can be easily determined,
(4) recursion is easy to represent.

The graphical representation of structured constructs using the box diagram is illustrated
in Figure 16.3.
-+++
16.1.3 Program Design Language
Program design language (PDL), also called structured English or pseudocode
following characteristics:
• A fixed syntax of keywords that provide for all structured constructs, data declaration,
and modularity characteristics.
• A free syntax of natural language that describes processing features.
• Data declaration facilities that should include both simple (scalar, array) and complex
(linked list or tree) data structures.
• Subprogram definition and calling techniques that support various modes of interface
description.

DESIGN DOCUMENT
The Design Specification addresses different aspects of the design model and is
completed as the designer refines his representation of the software. First, the overall
scope of the design effort is described. Much of the information presented here is derived
from the System Specification and the analysis model (Software Requirements
Specification).

Next, the data design is specified. Database structure, any external file structures, internal
data structures, and a cross reference that connects data objects to specific files are all
defined.
The architectural design indicates how the program architecture has been derived from
the analysis model. In addition, structure charts are used to represent the module
hierarchy (if applicable).

The design of external and internal program interfaces is represented and a detailed
design of the human/machine interface is described. In some cases, a detailed prototype
of a GUI may be represented. Components—separately addressable elements of software
such as subroutines, functions, or procedures—are initially described with an English-
language process- ing narrative. The processing narrative explains the procedural
function of a component (module). Later, a procedural design tool is used to translate the
narrative into a structured description.
The Design Specification contains a requirements cross reference. The purpose of this
cross reference (usually represented as a simple matrix) is (1) to establish that all
requirements are satisfied by the software design and (2) to indicate which components
are critical to the implementation of specific requirements.

The first stage in the development of test documentation is also contained in the design
document. Once program structure and interfaces have been established, we can develop
guidelines for testing of individual modules and integration of the entire package. In
some cases, a detailed specification of test procedures occurs in parallel with design. In
such cases, this section may be deleted from the
Design Specification. Design constraints, such as physical memory limitations or the
necessity for a specialized external interface, may dictate special requirements for
assembling or packaging of software. Special considerations caused by the necessity for
program overlay, virtual memory management, high-speed processing, or other factors
may cause modification in design derived from information flow or structure. In addition,
this section describes the approach that will be used to transfer software to a customer
site.

The final section of the Design Specification contains supplementary data. Algorithm
descriptions, alternative procedures, tabular data, excerpts from other documents, and
other relevant information are presented as a special note or as a separate appendix. It
may be advisable to develop a Preliminary Operations/Installation Manual and include it
as an appendix to the design document