Software Design

Unit – 5
What is Design?
 A meaningful representation of something to be built
 It's a process by which requirements are translated into blueprint
for constructing a software
 Blueprint gives us the holistic view (entire view) of a

Design Software
SRS Design
Problem Domain
Process Solution Domain
Software Design Process
Design phase transforms SRS document to a
form easily implementable in some programming
language.

SRS Design Design

Document Activities Documents
Analysis versus Design
 An analysis technique helps elaborate the customer requirements
through careful thinking:

And at the same time consciously avoids making any decisions
regarding implementation.

 The design model is obtained from the analysis model

through transformations over a series of steps:

Decisions regarding implementation are consciously made.
Analysis Model -> Design Model

Co m p o n e n
sc e na r i o- ba f l ow- or i e nt t- Level De
se d e l e me e d e l e me sig n
nt s nt s
use-cases - text use- data flow diagrams
case diagrams control-flow
activity diagrams diagrams processing
swim lane narratives
diagrams
In t e rf a c e D e
Analy sis sig n
Model
A rc h i t e c t u ra l D e
c l a ss- ba be ha v i or
a l e l e me
sig n
se d e l e
me nt s
class diagrams nt s
state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cla ss D e
collaboration
diagrams
sig n

Design
Model
Software Design Process?

Requirement Analysis Design Design

Engineering Model Engineering
Model

Process involves
Diversification
&
Convergence
Blue Print for
Constructing Software
The most creative part of the development process
Design and Quality
1. 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.
2. The design must be a readable, understandable guide
for those who generate code and for those who test
and subsequently support the software.
3. The design should provide a complete picture of the
software, addressing the data, functional,
behavioral and from an
perspective.
domains implementation
Quality Guidelines
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
1. 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
Software design work products
 For a design to be easily implemented in a conventional
programming language, the following items must be designed
during the design phase.
• Different modules required to implement the design solution.
• Control relationship among the identified modules. The
relationship is also known as the call relationship or invocation
relationship among modules.
• Interface among different modules. The interface among different
modules identifies the exact data items exchanged among the
modules.
• Data structures of the individual modules.
• Algorithms required to implement each individual module
Module Structure

 A module consists of:


Several functions D1 ..
D2 .. Data

Associated data structures. D3 ..
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..
Characteristics of good Design
 The design must implement all explicit requirements available in
requirement model
 The design must accommodate all implicit requirements given by
stakeholders
 The design must be readable & understandable
 The good design should providecomplete of the
software, behavioral
domains. picture
addressing the data, functional and
Design Models
 It is creative activity
 Most critical activity during system development
 Has great impact on testing and maintenance
 Design document forms reference

Procedural
Design Procedural description of Software components

Interface Design Human computer interaction

Architectural Design Relationship among structural elements

Data Design Data Structure

Design Models Cont.
Data Design Procedural Design
It transforms class models into design class
realization and prepares data structure
(data design) required to implement the
software.

Architectural Design
It defines the relationship between It transforms
major structural elements of the structural
software elements of
software into
Interface Design procedural
description of
It defines how software communicates software
with systems & with humans. An interface components
implies flow of information & behavior.
Quality attributes of software design
The FURPS quality
attributes
F Functionality U Usability
assessed by feature set and capabilities of assessed by considering human
the program, generality of the functions & factors, overall aesthetics,
security of overall system consistency & documentations

R Reliability P Performance
assessed by measuring frequency & measured by processing speed,
severity of failures, accuracy of outputs, response time,
mean-time-of-failure (MTTF), ability to resource consumption, throughput
recover from errors and efficiency

S Supportability
Ability to extend program, adaptability, serviceability, testability, compatibility
Design Principles
1. Design process should not suffer from “tunnel vision”
2. Design should be traceable to the analysis model
3. Design should not reinvent the wheel
4. Design should “minimize the intellectual distance” between the
software and the real world problem
5. Design should exhibit (present) uniformity

nel on Reinvent the

Visi
Design Principles
6. Design should be structured to accommodate change
7. Design should be structured to degrade gently, even
when
abnormal data, events, or operating conditions are encountered
8. Design is not coding, coding is not design
9. Design should be assessed for quality as it is being created, not
after the fact
10. Design should be reviewed to minimize conceptual (semantic)
errors

Codin Design
 Design Process Rough View

Informal Informal More formal Finished

Design Outline Design Design Design
Design Process
Requirements
Specification Design Activities

Data
Architectura Abstract Interfac Component Structure Algorithm
l Design Specification e Design Design Design
Design

System Software Interface Component Data Algorithm

Architecture Specification Specification Specification Structure Specification
Specification

Design Product
Design Concepts
The beginning of wisdom for a software engineer is to
recognize the difference between getting program to work
and getting it right

» Abstraction » Information Hiding

» Architecture » Functional Independence
» Pattern » Refinement
» Separation of Concern » Aspects
» Modularity » Refactoring
Fundamental Concepts
Abstraction—data and procedure Architecture—the
overall structure of the software
Patterns—”conveys the essence” of a proven design
solution
Separation of concerns—any complex problem can be more easily handled if it is
subdivided into pieces
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
Aspects—a mechanism for understanding how global requirements affect design
Refactoring—a reorganization technique that simplifies the design
OO design concept
Design Classes—provide design detail that will enable analysis classes to be
Data Abstraction

door

manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening
mechanis
m

implemented as a data
structure
Procedural Abstraction
open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter
Architecture
“The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.” [SHA95a]

Structural properties. This aspect of the architectural design representation

defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one
another. For example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the invocation of
methods.
Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families
of similar systems. In essence, the design should have the ability to reuse
architectural building blocks.
Pattern
sDesign 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
Separation of Concerns
• Any complex problem can be more easily handled if it
is subdivided into pieces that can each be solved and/or
optimized independently
• A concern is a feature or behavior that is specified as
part of the requirements model for the software
• By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time
to solve.
Modularity
“Modularity is the single attribute of software that allows a
program to be intellectually manageable" [Mye78].
• Monolithic software (i.e., a 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.
• In almost all instances, you should break the design into
many modules, hoping to make understanding easier and
as a consequence, reduce the cost required to build the
software.
Modularity
Modularity is a fundamental attributes of any
good design.
• Decomposition of a problem cleanly into
modules:
• Modules are almost independent of each
other
• Divide and conquer principle.
In technical terms, modules should display:
High cohesion
Low coupling.
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
Layered Design
Layered Design
• Neat arrangement of modules in
a hierarchy means:
• Low fan-out
• Control abstraction
Characteristics of Module Hierarchy
• Depth:
• Number of levels of control
• Width:
• Overall span of control.
• Fan-out:
• A measure of the number of modules directly
controlled by given module.
Characteristics of Module Structure
• Fan-in:
• Indicates how many modules directly
invoke a given module.
• High fan-in represents code reuse and is
in general encouraged.
Module Structure
Fan Fan in=0
out=2
Fan Fan in=1
out=1

Fan in=2
Layered Design
• A design having modules:
• With high fan-out numbers is not a
good design:
• A module having high fan-out
lacks cohesion.
Bad Design
Information Hiding

module
• algorithm
controlled
interface • data structure

• details of external interface

• resource allocation policy

clients
"secret"

a specific design decision

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
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
Sizing Modules: Two Views

What's How
inside?? big is
it??

MODUL
E
 Functional Independence
Functional independence is achieved by developing modules with
"single-minded" function and an "aversion" to excessive interaction
with other modules.
Cohesion is an indication of the relative functional strength of a
module.
A cohesive module performs a single task, requiring little interaction
with other components in other parts of a program. Stated simply, a
cohesive module should (ideally) do just one thing.
Coupling is an indication of the relative interdependence among
modules.
Coupling depends on the interface complexity between modules, the
point at which entry or reference is made to a module, and what data
pass across the interface.
Aspects
• An aspect is a representation of a cross-cutting concern.
• An aspect of a program is a feature linked to many other parts of
the
program, but which is not related to the program's primary function.
• An aspect crosscuts the program's coreconcerns, therefore
violating
its separation of concerns that tries to encapsulate unrelated functions.
• For example, logging code can crosscut many modules, yet the aspect of
logging should be separate from the functional concerns of the module it
cross-cuts.
Aspects—An Example
Consider two requirements for the SafeHomeAssured.com WebApp.
Requirement A is described via the use-case Access camera surveillance via the
Internet. A design refinement would focus on those modules that would enable
a registered user to access video from cameras placed throughout a space.
Requirement B is a generic security requirement that states that a registered user
must be validated prior to using SafeHomeAssured.com. This requirement is
applicable for all functions that are available to registered SafeHome users. As
design refinement occurs, A* is a design representation for requirement A and B*
is a design representation for requirement B. Therefore, A* and B* are
representations of concerns, and B* cross-cuts A*.

An aspect is a representation of a cross-cutting concern. Therefore, the design

representation, B*, of the requirement, a registered user must be validated prior
to using SafeHomeAssured.com, is an aspect of the SafeHome WebApp.
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.
The Design Model
high

a na ly sis m
ode l
class diagrams
analysis packages
use- cases - t ext class diagrams
Requirement s:
CRC models const raint s
use- case diagrams analysis packages
collaborat ion
act ivit y diagrams CRC models int eroperabilit y
diagrams
sw im lane diagrams collaborat ion diagrams
dat a f low diagrams
collaborat ion diagrams
t arget s and
dat a f low diagrams
cont rol- f low
st at e diagrams cont rol- f low diagrams
conf igurat ion
diagrams processing
sequence diagrams processing narrat ives
narrat ives
st at e diagrams
sequence diagrams

design class realizat ions

subsyst ems
collaborat ion diagrams t echnical int erf ace component diagrams
design class realizat ions
design design classes
subsyst ems
Navigat ion design act ivit y diagrams
collaborat ion diagrams
GUI design sequence diagrams
component diagrams
de sign m design classes
ode l ref inement s t o: act ivit y diagrams
ref inement s t o: sequence diagrams
component diagrams
design class realizat ions design classes
subsyst ems
low collaborat ion diagrams
act ivit y diagrams
sequence diagrams deployment diagrams

archit ect ure int erface component -level deployment -level

element s element element s element s
s
process dimension
Interface Elements
MobilePhone

WirelessPDA

Cont rolPanel

LCDdisplay
LEDindicat or
s Key Pad
keyPadCharact erist ics
speaker
wirelessInt erf ace
r eadKeySt roke()
decodeKey ( )
displaySt at us()
light LEDs()
sendCont rolMsg()

< < int erface> >

Key Pad

r eadKeyst roke()
decodeKey()
Component Elements

SensorManagement
Sensor
Component Elements (Physical Aspects)
Deployment Diagrams
Deployment diagrams are used to visualize the topology of the
physical components of a system, where the software components
are deployed.
Deployment diagrams are used to describe the static deployment
view of a system. Deployment diagrams consist of nodes and their
relationships.
Deployment diagrams are mostly used by system administrators,
network engineers, etc.
These diagrams are used with the sole purpose of describing
how software is deployed into the hardware
system.
It visualizes how software interacts with the hardware to
execute the complete functionality.
Deployment Elements
Cont rol Panel CPI serv
er
Security homeownerAccess

Personal comput
er
externalAccess

Security Surveillance

homeManagement communication
Architectural Design
Why Architecture?
The architecture is not the operational software. Rather, it is a
representation that enables a software engineer to:
(1)analyze the effectiveness of the design in meeting its stated
requirements,
(2) consider architectural alternatives at a stage when making
design changes is still relatively easy, and
(3)reduce the risks associated with the construction of the
software.
Software Architecture & Design
 Large systems are decomposed into subsystems
 Sub-systems provide related services
 Initial design process includes
• Identifying sub-systems
• Establishing a framework for sub-system control

Why to document the Architecture?

 Stakeholder Communication: High-level presentation of system
 System Analysis:Big effect on performance, reliability,
maintainability and –ilities (Usability, Maintainability,
Reliability,other
Extensibility, Security, Portability) Scalability,
 Large-scale Reuse: Similar requirements similar architecture
Architectural Genres
• Genre implies a specific category within the overall software
domain.
• Within each category, you encounter a number of subcategories.
• For example, within the genre of buildings, you would encounter
the following general styles: houses, condos, apartment
buildings, office buildings, industrial building, warehouses, and so
on.
• Within each general style, more specific styles might apply. Each
style would have a structure that can be described using a set of
predictable patterns.
Software Architecture & Design
 Architectural design represents the structure of data and program
components
 It considers,
• Architectural style that the system will take,
• Structure and properties of the components that constitute the
system, and
• Interrelationships that occur among all architectural components
of a system.
 Representations of software architecture are an enabler for
communication between all parties (stakeholders).
 Architecture “constitutes a relatively small, intellectually graspable
model of how the system is structured and how its components
work together”
Software Architecture & Design

marry in haste
repent at leisure

True for
Software
Architectur
e Design
Architectural Styles
 Data-centered architecture style
 Data-flow architectures
 Call and return architecture
 Object-oriented architecture
 Layered architecture
Architectural Styles cont..
 Each style describes a system category that encompasses,
• A set of components (Ex., a database, computational modules)
that perform a function required by a system.
• 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.
Data-centered architecture style
Data-centered architecture style
 A data store (Ex., a file or database) resides at the center of this
architecture and is accessed frequently by other components.
 Client software accesses a central repository.
 In some cases the data repository is passive.
• That is, client software accesses the data independent
of any
changes to the data or the actions of other client software.
Data-flow architectures
Data-flow architectures cont..
 This architecture is applied when input data are to
be transformed.
 A set of components (called filters) connected by pipes
that
transmit data from one component to the next.
 Each filter works independently of those components upstream
and downstream, is designed to
• expect data input of a certain form, and
• produces data output (to the next filter) of a specified form.
Call and return architecture
 This architectural style enables a software designer (system
architect) to achieve a program structure that is relatively easy to
modify and scale.
 A number of sub styles exist within this category as below.
1. Main program/subprogram architectures
• This classic program structure decomposes function into a
control hierarchy where a “main” program invokes a number of
program components, which in turn may invoke still other
components.
2. Remote procedure call architectures
• The components of a main program/subprogram architecture are
distributed across multiple computers on a network
Call and return architecture
Object-oriented architecture
 The components of a system data and the
operations
encapsulatethat must be applied to manipulate the data.
 Communication and coordination between components
is accomplished via message passing.
Layered architecture
 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.
 Component Level Design

Effective programmers
should not waste their time
in debugging, they should
not introduce bug to start
with
Component-Level Design or Procedural Design
 Component is a modular, deployable and replaceable part of a
system that encapsulates implementation and exposes a set of
interfaces.
 Component-level design occurs after data, architectural and
interface designs have been established.
 It defines the data structures, algorithms, interface
characteristics, and communication mechanisms allocated to
each component.
 The intent is to translate the design model into operational
software.
Function Oriented Approach
 The following are the features of a typical function-
oriented design approach:
1. A system is viewed as something that performs a
set of functions.
• Starting at this high level view of the system, each
functionis successively refined into more detailed functions.
• For example, consider a function create-new-library member
– which essentially creates the record for a new member, assigns a
unique membership number to him, and prints a bill towards his
membership charge.
– This function may consist of the following sub-functions:
» assign-membership-number, create-member-record and print-bill
• Each of these sub-functions may be split into more detailed sub-
functions and so on.
Function Oriented Approach Cont..
2. Thesystem state is centralized and shared among
different functions.
• For Ex., data such as member-records is available for reference and
updating to several functions such as:
– create-new-member
– delete-member
– update-member-record
OVERVIEW OF SA/SD METHODOLOGY
 As the name itself implies, SA/SD methodology
involves carrying out two distinct activities:
 Structured analysis (SA)
 Structured design (SD)
 During structured analysis, the SRS document is
transformed into a data flow diagram (DFD) model.
 During structured design, the DFD model is transformed into a
structure chart.
OVERVIEW OF SA/SD METHODOLOGY
It is important to understand that the purpose of structured
analysis is to capture the detailed structure of the system as
perceived by the user, whereas the purpose of structured design is
to define the structure of the solution that is suitable for
implementation in some programming language.
 Structured Analysis
• The results of structured analysis can be easily understood even by
ordinary customers:
• Does not require computer knowledge.
• Directly represents customer’s perception of the problem.
• Uses customer’s terminology for naming different functions and
data.
• The results of structured analysis can be reviewed by customers:
• To check whether it captures all their requirements.
 Structured Analysis
• Based on principles of:
• Top-down decomposition approach.
• Divide and conquer principle:
• Each function is considered individually (i.e. isolated from
other functions).
• Decompose functions totally disregarding what happens in
other functions.
• Graphical representation of results using
• Data flow diagrams (or bubble charts).
Data Flow Diagrams (Bubble Chart)
• DFD is an elegant modelling technique:
• Useful not only to represent the results of structured
analysis.
• Applicable to other areas also:
• e.g. for showing the flow of documents or items in an
organization,
• DFD technique is very popular:
• It is powerful and yet simple to understand and use.
• DFD is a hierarchical graphical model:
• Shows the different functions (or processes) of the system
and
• Data interchange among the processes.
• It is useful to consider each function as a processing station:
• Each function consumes some input data.
• Produces some output data.
Symbols used in Data Flow Diagrams
(Bubble Chart)
Synchronous Operation
• If two bubbles are directly connected by a
data flow arrow:
• They are synchronous

Read- number Validate-

numbers numbers Valid
Data- 0.1 0.2 number
items
Asynchronous Operation
• If two bubbles are connected via a data
store:
• They are not synchronous.

Read- Validate-
numbers numbers
0.1 numbers 0.2 Valid
Data- number
items
Balancing DFDs
The data that flow into or out of a bubble must match
the data flow at the next level of DFD. This is known as
balancing a DFD.
Data Cluttering
Decomposition
• Decomposition of a bubble is also called factoring or exploding.
• Each bubble is decomposed to Between 3 to 7 bubbles.
• Too few bubbles make decomposition superfluous:
• If a bubble is decomposed to just one or two bubbles then this
decomposition is redundant.
• Too many bubbles:
• More than 7 bubbles at any level of a DFD.
• Make the DFD model hard to understand.

• Decomposition of a bubble should be carried on until:

• A level at which the function of the bubble can be described using
a simple algorithm.
Context Diagram
• A Context diagram shows:
• Data input to the system,
• Output data generated by the system,
• External entities.
• Context diagram captures:
• Various entities external to the system
interacting with it.
and
• Data flow occurring between the system
and the external entities.
• The context diagram is also called as the level 0 DFD.
• Establishes the context of the system, i.e.
• Represents:
• Data sources
• Data sinks.
Level 1 DFD
• Examine the SRS document:
• Represent each high-level function as a bubble.
• Represent data input to every high-level function.
• Represent data output from every high-level
function.
Higher Level DFDs
• Each high-level function is separately decomposed
into subfunctions:
• Identify the subfunctions of the function
• Identify the data input to each subfunction
• Identify the data output from each subfunction
• These are represented as DFDs.
Example – 1 (Tic-Tac-Toe
Computer Game)
Tic-tac-toe is a computer game in which a human player and the
computer make alternate moves on a 3 × 3 square. A move consists of
marking a previously unmarked square. The player who is first to
place three consecutive marks along a straight line (i.e., along a row,
column, or diagonal) on the square wins. As soon as either of the human
player or the computer wins, a message congratulating the winner should
be displayed. If neither player manages to get three consecutive marks
along a straight line, and all the squares on the board are filled up, then
the game is drawn. The computer always tries to win a game.
Data Dictionary for Tic-Tac-Toe
Computer Game
• move: integer /* number between 1 to 9 */
• display: game + result
• game: board
• board: {integer}9
• result: [“computer won”, “human won”, “drawn”]
Tic-Tac-Toe Computer Game
Example – 3 (Supermarket Prize
Scheme)
A super market needs to develop a software that would help it to automate a
scheme that it plans to introduce to encourage regular customers. In this
scheme, a customer would have first register by supplying his/her residence
address, telephone number, and the driving license number. Each customer who
registers for this scheme is assigned a unique customer number (CN) by the
computer . A customer can present his CN to the check out staff when he makes
any purchase. In this case, the value of his purchase is credited against his CN.
At the end of each year, the supermarket intends to award surprise gifts to 10
customers who make the highest total purchase over the year . Also, it intends to
award a 22 caret gold coin to every customer whose purchase exceeded Rs.
10,000. The entries against the CN are reset on the last day of every year after
the prize winners’ lists are generated.
Context Diagram for
Supermarket Prize Scheme
Level-1 Diagram for
Supermarket Prize Scheme
Level-2 Diagram for
Supermarket Prize Scheme
Data Dictionary for Supermarket
Prize Scheme
Shortcomings of DFD
• DFDs leave ample scope to be imprecise. In the DFD model, we judge the function
performed by a bubble from its label. However, a short label may not capture the
entire functionality of a bubble. For example, a bubble named find-book-position has
only intuitive meaning and does not specify several things, e.g. what happens when
some input information is missing or is incorrect.
• Control aspects are not defined by a DFD. For instance, the order in which inputs are
consumed and outputs are produced by a bubble is not specified. A DFD model does
not specify the order in which the different bubbles are executed.
• Decomposition: The method of carrying out decomposition to arrive at the successive
levels and the ultimate level to which decomposition is carried out are highly
subjective and depend on the choice and judgment of the analyst. Due to this reason,
even for the same problem, several alternative DFD representations are possible.
• Improper data flow diagram: The data flow diagramming technique does not provide
any specific guidance as to how exactly to decompose a given function into its
subfunctions and we have to use subjective judgment to carry out decomposition.
Object Oriented Approach
 In the object-oriented design approach, the system is viewed as
collection of objects (i.e., entities).
 The state is decentralized among the objects and each
object manages its own state information.
 For example, in a Library Automation Software,
• each library member may be a separate object with its own data
and functions to operate on these data.
• In fact, the functions defined for one object cannot
refer or change data of other objects.
 Objects have their own internal data
Cohesion & Coupling
A good software design implies clean decomposition of the
problem into modules, and the neat arrangement of these
modules in a hierarchy.

The primary characteristics of neat module decomposition

are high cohesion and low coupling.
Cohesion & Coupling
A cohesive module A Coupling is an indication
performs a single task, of the relative
requiring little interaction interdependence among
with other components. modules.
Cohesion
 Cohesion is an indication of the relative functional strength of a
module.
 A cohesive module performs a single task, requiring
little interaction with other components.
 Stated simply, a cohesive module should (ideally) do just
one thing.
 A module having high cohesion and low coupling is said to be
functionally independent of other modules.
 By the term functional independence, we mean that a cohesive
module performs a single task or function.
Classification of Cohesion

Coincidental Low
Logical
Temporal
Procedural
Communicational
Sequential
Functional High
ssification of Cohesion
Classification of Cohesion cont.
Coincidental cohesion
• A module is said to have coincidental cohesion, if it performs a set
of tasks that relate to each other very loosely.
• In this case, the module contains a random collection of functions.
• It is likely that the functions have been put in the module out of
pure coincidence without any thought or design.
• For Ex., in a transaction processing system (TPS), the get-
input,
print-error, and summarize-members functions are grouped
into one module.
Classification of Cohesion cont.
Logical cohesion
• A module is said to be logically cohesive, if all elements of
the module perform similar operations.
• For Ex., error handling, data input, data output, etc.
• An example of logical cohesion is the case where a set of print
functions generating different output reports are arranged into a
single module.

Temporal cohesion
• When a module contains functions that are related by the fact that
all the functions must be executed in the same time span.
• For Ex., the set of functions responsible for initialization, start-up,
shutdown of some process, etc.
Classification of Cohesion cont.
Procedural cohesion
• If the set of functions of the module are all part of a procedure
(algorithm) in which certain sequence of steps have to be carried
out for achieving an objective
• For Ex., the algorithm for decoding a message.
Communicational cohesion
• If all functions of the module refer to the same data structure
• For Ex., the set of functions defined on an array or a stack.
Classification of Cohesion cont.
Sequential cohesion
• If the elements of a module form the parts of sequence, where the
output from one element of the sequence is input to the next.
• For Ex., In a Transaction Processing System, the get-input, validate-
input, sort-input functions are grouped into one module.
Functional cohesion
• If different elements of a module cooperate to achieve a single
function.
• For Ex., A module containing all the functions required to manage
employees’ pay-roll exhibits functional cohesion.
Coupling
 Coupling between two modules is a measure of the degree
of
interdependence or interaction between the two modules.
 A module having high cohesion and low coupling is said to
be functionally independent of other modules.
 If two modules interchange large amounts of data, then they are
highly interdependent.
 The degree of coupling between two modules depends on their
interface complexity.
Classification of Coupling

Data Low

Stamp

Control

Common

Content High
Classification of Coupling
Classification of Coupling Cont.
Data coupling
• Two modules are data coupled, if they communicate through a
parameter.
• Anexample is an elementary (primal) data item passed
as a parameter between two modules,e.g. an integer, a
float, a
character, etc.

Stamp coupling
• This is a special case (or extension) of data coupling
• Two modules (``A'' and ``B'') exhibit stamp coupling if one passes
directly to the other a composite data item - such as a record (or
structure), array, or (pointer to) a list or tree.
• This occurs when ClassB is declared as a type for an argument of
an operation of ClassA
Classification of Coupling Cont.
Control coupling
• If data from one module is used to direct the order of instructions
execution in another.
• An example of control coupling is a flag set in one module and
tested in another module.

Common coupling
• Two modules are common coupled, if they share data
through some global data items.
• Common coupling can leads to uncontrolled error
propagation
and unforeseen side effects when changes are made.
Classification of Coupling Cont.
Content coupling
• Content coupling occurs when one component secretly modifies
data that is internal to another component.
• This violets information hiding – a basic design concept
• Content coupling exists between two modules, if they share code.
User Interface Design
Introduction
• In any software product, user interface portion is responsible for
all interactions with the user.
• Almost every software product has a user interface: can you think
of any software product that does not have any user interface?
• In the early days of computer, no software product had any user
interface:
• all computers were batch systems
• no interactions with users were supported.
• We know that things are very different now:
• almost every software product is highly interactive.
Introduction
• Users interact with a software product through its user interface:
• user-interface portion of any software is directly relevant to
the users.
• many users judge a software from its user interface.
• User interface design:
• a practical and important problem.
• Aesthetics apart, a difficult to use interface:
• leads to higher levels of user errors
• leads to user dissatisfaction.
• Users become particularly irritated when a system behaves in
unexpected ways,
• issued commands do not carry out actions according to
intuitive expectations of users.
Introduction
• A significant portion of the total development effort:
• spent in developing the user interface.
• For many interactive applications:
• as much as 50% of the total development effort is spent on the
user interface part.
• If the user interface is not developed systematically:
• effort required to develop the interface would increase
tremendously :
• leading to customer dissatisfaction.
• It is important to carefully study user interface design
concepts.
• Let us examine what a good interface is:
• Unless we know what a good user interface really is,
Characteristics of Good User Interfaces
• Speed of Learning
• Speed of Use
• Speed of Recall
• Error Prevention
• Aesthetic and Attractive
• Consistency
• Feedback
• Support for multiple Skill Level
• Error Recovery
• User Guidance and On-line Help
Golden Rules of User Interface Design
Place the User in Control Reduce the User’s Memory Load

Make the Interface Consistent

Place the User in Control
 During a requirements-gathering for a major
information
session system, a key user was asked about.new
 Following are the design principles that allow the user
to maintain control:
• Define interaction modes in a way that does not force a user into
unnecessary or undesired actions.
• Provide for flexible interaction.
• Allow user interaction to be interruptible and undoable.
• Streamline interaction as skill levels advance and
allow the
interaction to be customized.
• Hide technical internals from the casual user.
• Design for direct interaction with objects that appear
on the screen.
Reduce the User’s Memory
Load
 The more a user has to remember, the more error-prone
the interaction with the system will be.
 Following are the design principles that enable an interface
to reduce the user’s memory load:
• Reduce demand on short-term
memory.
• Establish meaningful defaults.
• Define shortcuts that are intuitive.
• The visual layout of the interface
should be based on a
real-world
metaphor.
• Disclose informationin
a
progressive fashion.
Make the Interface Consistent
 The interface should present and acquire information in a
consistent fashion.
 Following are the design principles that help make the interface
consistent:
• Maintain consistency across a family of applications.
• If past interactive models have created user expectations, do not
make changes unless there is a compelling (convincing) reason to
do so.
User Interface Analysis and Design Models
 User profile model – Established by a software engineer
• Establishes the profile of the end-users of the system
• basedon age,gender, physical abilities, cultural
education, background, motivation, goals, and
personality.
 Design model
• Derived from– the
Created by amodel
analysis software engineer
of the requirements.
• Incorporates data, architectural, interface, and
procedural representations of the software.
 Implementation model – Created by the software implementers
• The interface “look and feel” coupled with supporting information
that describe interface syntax and semantics
User Interface Analysis and Design Models
 User's mental model – Developed by the user when interacting
with the application
• Often called the user's system perception.
• Consists of the image of the system; that users carry
in their heads.

The role of the interface designer is to merge these differences

and derive a consistent representation of the interface.
User Interface Design Process
User Interface Design Process
Web Application Design
Web Application Design
 Design for WebApp encompasses technical and
nontechnical activities that include:
• Establishing the look and feel of the WebApp
• Defining the overall architectural structure
• Developing the content and functionality that reside within the
architecture
• Planning the navigation that occurs within the WebApp
Web App Interface Design
Design pyramid for WebApps
The objectives of a WebApp
interface are to:

 Establish a consistent
window into the content
and functionality provided
by the interface.
 Guide the user
through ainteractions
series of with
the WebApp.
 Organize the navigation
options and
available to the user.
content
Design pyramid for WebApps Cont.
 Interface Design
• One of the challenges of interface design for WebApps
is the
nature of the user’s entry point.
 Aesthetic Design
• Also called graphic design, is an artistic endeavor
(offer) that
complements the technical aspects of WebApp design.
 Content Design
• Generate content and design the representation for content to be
used within a WebApp.
 Architecture Design
• It is tied to the goals established for a WebApp,
• the content to be presented, the users who will visit,
and the
navigation that has been established.
Design pyramid for WebApps Cont.
 Navigation Design
• Define navigation pathways that enable users to access WebApp
content and functions.
 Component-Level Design
• Modern WebApps deliver increasingly sophisticated
processing
functions that,
• Perform localized processing to generate content and navigation
capability in a dynamic fashion,
• Provide computation or data processing capability
that are
appropriate for the WebApp’s business domain.
• Provide sophisticated database query and access.
• Establish data interfaces with external corporate systems.
WebApp Design Quality Requirement
Summary
 Design Concepts  Component-Level Design
 Design principles 1. Function Oriented Approach
 Architectural Design 2. Object Oriented Approach
• Architectural Styles  Cohesion and Coupling
1. Data-centered architecture  User Interface Design
style
• Design Rules User
2. Data-flow architectures for Interface
3. Call and return architecture 
Web Application Design
4. Object-oriented
architecture
5. Layered architecture