1

Design:
It is a collection of principles, concepts and practices
that lead to the development of high quality system or
product
During design we focus on “how we are going to
build” unlike analysis where we focus on “what we are
going to build”.
Software design is an iterative process through which
requirements are translated into a blueprint for
constructing the software
 Design begins at a high level of abstraction that can be directly traced
back to the data, functional, and behavioural requirements
 As design iteration occurs, subsequent refinement leads to design
representations at much lower levels of abstraction

2
Purpose of Design:
 Design is where customer requirements, business
needs, and technical considerations all come together
in the formulation of a product or system
 The design model provides detail about the software
data structures, architecture, interfaces, and
components
 The design model can be assessed for quality and be
improved before code is generated and tests are
conducted
 Does the design contain errors, inconsistencies, or omissions?
 Are there better design alternatives?
 Can the design be implemented within the constraints, schedule,
and cost that have been established?

(More on next slide) 3

3
Purpose of Design (continued)
A designer must practice diversification and
convergence
 The designer selects from design components,
component solutions, and knowledge available through
catalogs, textbooks, and experience
 The designer then chooses the elements from this
collection that meet the requirements defined by
requirements engineering and analysis modelling
 Convergence occurs as alternatives are considered and
rejected until one particular configuration of components
is chosen

4
4
1. Design within the context of SE:

Design is applied regardless of the S/w process

model
S/w design is the last SE action within the
modeling activity & sets the stage for
Construction.

5
5
Translating the Analysis Model into Design
Model
Each element of the analysis model provides
information that is necessary to create the four
design models
 The data/class design transforms analysis classes into design classes
along with the data structures required to implement the software
 The architectural design defines the relationship between major
structural elements of the software; architectural styles and design
patterns help achieve the requirements defined for the system
 The interface design describes how the software communicates with
systems that interoperate with it and with humans that use it
 The component-level design transforms structural elements of the
software architecture into a procedural description of software
components
6
Analysis Model -> Design Model

Co m p o n e n t -
s c e na rio - ba s e d f lo w- o rie n t e d Le v e l D e s i g n
e le me nt s e le me nt s
us e-cas es - text data flow diagrams
us e-cas e diagrams control-flow diagrams
activity diagrams proces s ing narratives
s wim lane diagrams
In t e rf a c e D e s i g n
An a ly s is Mo d e l

A rc h i t e c t u ra l D e s i g n
c la ss- ba se d be ha v io ra l
e le me nt s e le me nt s
clas s diagrams s tate diagrams
analys is packages s equence diagrams
CRC models D a t a / Cl a s s D e s i g n
collaboration diagrams

De sig n Mo d e l

7
From Analysis Model to Design Model
Component-level Design

(Class-based model, Flow-oriented model

Behavioral model)
Interface Design

(Scenario-based model, Flow-oriented model

Behavioral model)

Architectural Design

(Class-based model, Flow-oriented model)

Data/Class Design

(Class-based model)
8
Importance of good Design:
Quality is the most important thing within design.
Design provides representations which can be assessed for
quality.
With design only we can accurately translate customer
requirements into a finished system or software product.
It serves as a foundation for all SE and S/W support
activities that follow
Without design, there will be huge risk of building an
unstable system-one that fails when small changes are made;
one which is difficult to test & assessed.
The quality of the design is assessed through a series of
formal technical reviews or design walkthroughs
9
2. Design Process and Design Quality
Goals of good design/design process
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.
10
Design Quality Guidelines/
Characteristics of good design
1) A design should exhibit an architecture that
a) Has been created using recognizable architectural styles or
patterns
b) Is composed of components that exhibit good design
characteristics
c) Can be implemented in an evolutionary fashion, thereby
facilitating implementation and testing
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
11
Design Quality Guidelines (continued)
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

12
Design Quality Attributes
 FURPS is an acronym representing a model for classifying software
quality attributes (functional and non-functional requirements):
 Functionality - Capability (Size & Generality of Feature Set), Reusability
(Compatibility, Interoperability, Portability), Security (Safety &
Exploitability)
 Usability - Human Factors, Aesthetics, Consistency, Documentation,
Responsiveness
 Reliability - Availability (Failure Frequency) (Robustness/ Durability/
Resilience), Failure Extent & Time-Length (Recoverability/Survivability)),
Predictability (Stability), Accuracy (Frequency/Severity of Error)
 Performance - Speed, Efficiency, Resource Consumption (power, ram,
cache, etc.), Throughput, Capacity, Scalability
 Supportability (Serviceability, Maintainability, Sustainability, Repair
Speed) - Testability, Flexibility (Modifiability, Configurability,
Adaptability, Extensibility, Modularity), Installability, Localizability
13
3. Design Concepts
 Abstraction—data, procedure
 Architecture—the overall structure of the software
 Patterns—”conveys the essence” of a proven design solution
 Modularity—compartmentalization of data and function
 Information hiding—controlled interfaces
 Functional independence—single-minded function and low
coupling
 Refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design
 Design Classes-classes which implement a software infrastructure
to support business solution
14
Abstraction
It is a means of describing a program/ function at an
appropriate level of detail.
At Highest level it is represented in broad terms
At Lowest level it is represented in more detailed form
Types:
• Data
• Procedural

15
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

It is a named collection of data that describes a data object

16
Procedural Abstraction
open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter

It refers to a sequence of instructions that have specific and limited

function. 17
Architecture:
“The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.” [SHA95a]
 Architecture is the structure or organization of program
components[modules], the manner in which these components interact
and the structure of data that are used by the components
 Consists of components, connectors, and the relationship between them

 Different types of models are used to develop architectural design

 Structural: Represents architecture as an organized collection of program
components.
 Framework: Identifies repeatable architectural design frameworks encountered
in similar type of applications.
 Dynamic: Indicates how the structure or system configuration changes based
on behavior aspects(events).
 Process: Focus on the design of business or technical process
 Functional: Used to represent functional hierarchy of a system.
18
Patterns:
Design pattern describes a design data structure which provides a
reliable solution to a recurring problem.
• A design structure that solves a particular design
problem within a specific context
• It provides a description that enables a designer to
determine whether the pattern is applicable, whether
the pattern can be reused, and whether the pattern can
serve as a guide for developing similar patterns

19
Modular Design
 Software is divided into separately named and addressable
components (i.e., modules) that are integrated to satisfy
requirements (divide and conquer principle)
 Makes software intellectually manageable so as to grasp the control
paths, span of reference, number of variables, and overall complexity
 Advantages:
 Fast delivery & quality of s/w increment as each module is tested.
 Changes can be easily accommodated.
 Testing and debugging can be conducted effectively
 Easy to maintain.
 Disadvantages:
 To many modules may lead to misunderstanding of a system structure
 Designer may have to adjust modules frequently which may lead to
inconsistency & complexity

20
Modularity: Trade-offs
What is the "right" number of modules
for a specific software design?

module development cost

cost of
software
module
integration
cost

optimal number number of modules

of modules

21
Information Hiding
 It states that modules should be designed in such a way that
information contained within it should be inaccessible to other
modules that have no need for such information.
 The designing of modules so that the algorithms and local data
contained within them are inaccessible to other modules
 This enforces access constraints to both procedural (i.e.,
implementation) detail and local data structures

22
Information Hiding

module • algorithm
controlled
interface • data structure
• details of external interface
• resource allocation policy

clients "secret"

a specific design decision

23
Why Information Hiding?
reduces the likelihood of “side effects”
limits the global impact of local design decisions
emphasizes communication through controlled
interfaces
discourages the use of global data
leads to encapsulation—an attribute of high quality
design
results in higher quality software

24
Functional Independence
 Modules that have a "single-minded" function and which avoids
excessive interaction with other modules
 High cohesion – a module performs only a single task
 Low coupling – a module has the lowest amount of connection needed
with other modules

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.
25
Stepwise Refinement
Development of a program by successively refining levels
of procedure detail
It is a process of elaboration
Complements abstraction, which enables a designer to
specify procedure and data and yet suppress low-level
details
Abstraction specifies the procedure & data without low
level details whereas refinement helps the designer to
reveal low level details as design progresses.

26
Stepwise Refinement
open

walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

27
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 refactored, 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.

28
Design Classes
 Refines the analysis classes by providing design detail that will enable
the classes to be implemented
 Creates a new set of design classes that implement a software
infrastructure to support the business solution
Types of Design Classes:
 User interface classes – define all abstractions necessary for
human-computer interaction (usually via metaphors of real-world
objects)
 Business domain classes – refined from analysis classes; identify
attributes and services (methods) that are required to implement
some element of the business domain
 Process classes – implement lower level business abstractions
required to fully manage the business domain classes
 Persistent classes – represent data stores (e.g., a database) that will
persist beyond the execution of the software
 System classes – implement software management and control
functions that enable the system to operate and communicate within
its computing environment and the outside world

29
Characteristics of a Well-Formed Design
Class(what is a well formed design class)
 Complete and sufficient
 Contains the complete encapsulation of all attributes and methods that exist
for the class
 Contains only those methods that are sufficient to achieve the intent of the
class
 Primitiveness
 Each method of a class focuses on accomplishing one service for the class
 High cohesion
 The class has a small, focused set of responsibilities and single-mindedly
applies attributes and methods to implement those responsibilities
 Low coupling
 Collaboration of the class with other classes is kept to an acceptable
minimum
 Each class should have limited knowledge of other classes in other
subsystems
30
4. The Design Model
hig h

a n a ly s is m o d e l

c la s s dia gra ms
a na lys is pa c ka ge s
us e - c a s e s - t e xt c la s s dia gra ms
Re quire m e nt s :
CRC mode ls us e - c a s e dia gr a ms c ons t ra int s
a na lys is pa c ka ge s
c olla bora t ion dia gr a ms
a c t ivit y dia gr a ms CRC mode ls int e rope ra bilit y
da t a f low dia gr a ms s w im la ne dia gra ms c olla bora t ion dia gra ms t a rge t s a nd
c ont rol- flow dia gra ms c olla bora t ion dia gra ms da t a f low dia gra ms
proc e s s ing na r ra t ive s s t a t e dia gra ms c ont rol-f low dia gr a ms
c onf igura t ion
s e que nc e dia gr a ms proc e s s ing na r ra t ive s
s t a t e dia gra ms
s e que nc e dia gra ms

de s ign c la s s re a liz a t ions

s ubs ys t e ms
c olla bora t ion dia gr a ms t e c hnic a l int e rf a c e c ompone nt dia gra ms
de s ign c la s s re a liz a t ions
de s ign de s ign c la s s e s
s ubs ys t e ms
Na viga t ion de s ign a c t ivit y dia gra ms
c olla bora t ion dia gra ms
GUI de s ign s e que nc e dia gra ms
c ompone nt dia gra ms
d e s ig n m o d e l de s ign c la s s e s
re f ine m e nt s t o: a c t ivit y dia gra ms
re f ine m e nt s t o: s e que nc e dia gra ms
c ompone nt dia gra ms
de s ign c la s s re a liz a t ions de s ign c la s s e s
s ubs ys t e ms a c t ivit y dia gra ms
lo w c olla bor a t ion dia gra ms s e que nc e dia gra ms de ployme nt dia gr a ms

arc hit e c t ure int e rfa c e co m po nent -leve l de plo ym e nt -le ve l

e le m e nt s ele m e nt s ele m e nt s e le m e nt s

p ro c e s s d ime ns io n
31
Introduction
 The design model can be viewed in two different dimensions
 (Horizontally) The process dimension indicates the evolution of the
parts of the design model as each design task is executed
 (Vertically) The abstraction dimension represents the level of detail
as each element of the analysis model is transformed into the design
model and then iteratively refined
 Elements of the design model use many of the same UML
diagrams used in the analysis model
 The diagrams are refined and elaborated as part of the design
 More implementation-specific detail is provided
 Emphasis is placed on
 Architectural structure and style
 Interfaces between components and the outside world
 Components that reside within the architecture

32
Introduction (continued)
 Design model elements are not always developed in a sequential
fashion
 Preliminary architectural design sets the stage
 It is followed by interface design and component-level design, which often
occur in parallel
 The design model has the following layered elements
 Data/class design
 Architectural design
 Interface design
 Component-level design
 A fifth element that follows all of the others is deployment-level design

33
Design Elements
 Data/class design
 Creates a model of data and objects that is represented at a high level of
abstraction
 Architectural design
 Depicts the overall layout of the software
 Interface design
 Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the architecture
 Includes the user interface, external interfaces, and internal interfaces
 Component-level design elements
 Describes the internal detail of each software component by way of data
structure definitions, algorithms, and interface specifications
 Deployment-level design elements
 Indicates how software functionality and subsystems will be allocated
within the physical computing environment that will support the software

34
Design Model Elements
 Data elements
 Data model --> data structures
 Data model --> database architecture
 Architectural elements
 Application domain
 Analysis classes, their relationships, collaborations and behaviors are transformed into
design realizations
 Patterns and “styles”
 Interface elements
 the user interface (UI)
 external interfaces to other systems, devices, networks or other producers or
consumers of information
 internal interfaces between various design components.
 Component elements
 Internal details about each component
 Deployment elements
 Describes s/w functionality & subsystems within the environment

35
Interface Elements
Mo b ile P h o n e

W ire le s s P DA

Co n t r o lP a n e l

LC Dd is p la y
LEDin d ic a t o r s
k e y Pa d C h a r a c t e r is t ic s Ke y P a d
s pe a ke r
wir e le s s In t e r f a c e

r e a d Ke y St r o k e ( )
d e c o d e Ke y ( )
d is p la y St a t u s ( )
lig h t LEDs ( )
s e n d Co n t r o lMs g( )

< < in t e rfa c e > >

Ke y P a d

r e a d Ke y s t r o k e( )
d e c o d e Ke y ( )

F ig u re 9 .6 UML in t e rfa c e re p r e s e n t a t io n fo r Co n t r o l P a n e l

36
Component Elements

SensorManagement
Sensor

37
Deployment Elements
Co n t ro l Pa n e l CPI s e rv e r

Security homeownerAcces s

Pe r sona l c omput e r

externalAcces s

Security Surveillance

homeManagement communication

Fig u re 9 . 8 UML d e p lo y m e n t d ia g ra m fo r S a f e Ho m e
38
Design Patterns
 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.
 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.

39
5.Pattern-based Software Design:
What types of design pattern are available for the Software
Engineer?
 Mature engineering disciplines make use of thousands of design patterns for such things
as buildings, highways, electrical circuits, factories, weapon systems, vehicles, and
computers
 Design patterns also serve a purpose in software engineering
 Types of Design Patterns:
 Architectural patterns
 Define the overall structure of software
 Indicate the relationships among subsystems and software components
 Define the rules for specifying relationships among software elements
 Design patterns
 Address a specific element of the design such as an aggregation of components or
solve some design problem, relationships among components, or the mechanisms for
effecting inter-component communication
 Consist of creational, structural, and behavioral patterns
 Coding patterns/Idioms
 Describe language-specific patterns that implement an algorithmic or data structure
element of a component, a specific interface protocol, or a mechanism for
communication among components 40
Design Pattern Template
 Pattern name—describes the essence of the pattern in a short but
expressive name
 Intent—describes the pattern and what it does
 Also-known-as—lists any synonyms for the pattern
 Motivation—provides an example of the problem
 Applicability—notes specific design situations in which the pattern is
applicable
 Structure—describes the classes that are required to implement the
pattern
 Participants—describes the responsibilities of the classes that are
required to implement the pattern
 Collaborations—describes how the participants collaborate to carry
out their responsibilities
 Consequences—describes the “design forces” that affect the pattern
and the potential trade-offs that must be considered when the pattern
is implemented
 Related patterns—cross-references related design patterns
41
Frameworks
A framework is not an architectural pattern, but rather a
architecture/code skeleton with a collection of “plug points”
(also called hooks and slots) that enable it to be adapted to a
specific problem domain.
A framework is a collection of cooperating classes in OOP
context.
It provides generic structure & behavior for a set of S/W
abstractions, along with the context.
Also called as reusable-mini architecture.
 Design patterns are more abstract than frameworks.
 Design patterns are smaller architectural elements than frameworks
 Design patterns are less specialized than frameworks
42