software design: design fundamentals.pptx

Software Design : Design
Fundamentals
By Dr. Shweta Saraswat

Software Design
Definition:
Software design is the process by which
an agent creates a specification of a software
artifact, intended to accomplish goals, using a
set of primitive components and subject
to constraints
Wikipedia

SW Design
 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.

Process of Design Engineering
 During the design process the software
specifications are transformed into design models
 Models describe the details of the data structures,
system architecture, interface, and components.
 Each design product is reviewed for quality before
moving to the next phase of software development.
 At the end of the design process a design model
and specification document is produced.
 This document is composed of the design models
that describe the data, architecture, interfaces and
components.

Entity-
Relationship
Diagram
Data Flow
Diagram
State-Transition
Diagram
Data Dictionary
Process Specification (PSPEC)
Control Specification (CSPEC)
Data Object Description
THE ANALYSIS MODEL
procedural
design
interface
design
architectural
design
data
design
THE DESIGN MODEL

Design Specification Models
 Data design – created by transforming the analysis information
model (data dictionary and ERD) into data structures required to
implement the software. Part of the data design may occur in
conjunction with the design of software architecture. More
detailed data design occurs as each software component is
designed.
 Architectural design - defines the relationships among the
major structural elements of the software, the “design patterns”
than can be used to achieve the requirements that have been
defined for the system, and the constraints that affect the way in
which the architectural patterns can be applied. It is derived from
the system specification, the analysis model, and the subsystem
interactions defined in the analysis model (DFD).

Design Specification Models
 Interface design - describes how the software
elements communicate with each other, with other
systems, and with human users; the data flow and
control flow diagrams provide much of the
necessary information required.
 Procedural / Component-level design - created by
transforming the structural elements defined by the
software architecture into procedural descriptions of
software components using information obtained
from the process specification (PSPEC), control
specification (CSPEC), and state transition diagram
(STD).

8
Design - Fundamental Concepts
 Abstraction
 Architecture
 Patterns
 Modularity
 Information hiding
 Functional independence
 Refinement
 Refactoring

Abstraction
 Data Abstraction
 Procedural Abstraction

Architecture Design
“The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.”
Design can be represented as
 Structural Models
 Defines the components of a system (e.g., modules, objects, filters) and
 How the components are packaged and interact with one another.
 Framework Models
 Increase level of abstraction
 Dynamic Models and Process Models
 Predicts behavioral and reliability aspects
 Functional Models
 Depicts functional Hierarchy.

Patterns
 a pattern is “a common solution to a common
problem in a given context.” While architectural
styles can be viewed as patterns describing the
high-level organization of software (their
macroarchitecture), other design patterns can be
used to describe details at a lower, more local level
(their microarchitecture).
 Creational patterns (example: builder, factory,
prototype, and singleton)
 Structural patterns (example: adapter, bridge,
composite, decorator, façade, flyweight, and proxy)
 Behavioral patterns (example: command,
interpreter, iterator, mediator, memento, observer,
state, strategy, template, visitor)

Design Pattern
 Design Pattern enables a designer to
determine whether the pattern :
 is applicable to the current work
 can be reused
 can serve as a guide for developing a similar, but
functionally or structurally different pattern.

Modular Design
 Easier to change
 Easier to build
 Easier to maintain

Sizing Modules: Two Views
MODULE
What's
inside??
How big
is it??

Information Hiding
 Principle of information hiding says that a good split
of modules is when modules communicate with one
another with only the information necessary to
achieve the s/w function.
 So information hiding enforces access constraints to
both
 procedural detail with a module, and
 local data structure used by that module.
 Data hiding is a CRITERION for modular design.
 How to know what modules to create.

Information Hiding
module
controlled
interface
"secret"
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
a specific design decision

17
Information Hiding (Benefits)
 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

18
Functional Independence
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.

Cohesion
 Internal glue with which component is constructed
 All elements of component are directed toward and
essential for performing the same task

Range of Cohesion
High Cohesion
Low
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental

Examples of Cohesion-1
Function A
Function
B
Function
D
Function
C
Function
E
Coincidental
Parts unrelated
Function A
Function A’
Function A’’
logic
Logical
Similar functions
Time t0
Time t0 + X
Time t0 + 2X
Temporal
Related by time
Function A
Function B
Function C
Procedural
Related by order of functions

Examples of Cohesion-2
Function A part 1
Function A part 2
Function A part 3
Functional
Sequential with complete, related functions
Function A
Function B
Function C
Communicational
Access same data
Function A
Function B
Function C
Sequential
Output of one is input to another

Coupling
 Degree of dependence among components.
No dependencies Loosely coupled-some dependencies
Highly couples-many dependencies

Ways components can be dependent
 References made from one to another
 Component A invokes B
 A depends on B for completion of its function or process
 Amount of data passed from one to another
 Component A passes to B: a parameter, contents of an array, block of
data
 Amount of control one has over the other
 Component passes a control flag to B
 Value of flag tells B the state of some resource or subsystem, process
to invoke, or whether to invoke a process
 Degree of complexity in the interface between components
 Components C and D exchange values before D can complete
execution

Range of Coupling
High Coupling
Loose
Low
Content
Common
External
Control
Stamp
Data
Uncoupled

Content Coupling : (worst) When a module
uses/alters data in another module
Common Coupling : 2 modules communicating
via global data
External Coupling :Modules are tied to an
environment external to the software
Control Coupling : 2 modules communicating
with a control flag

Stamp Coupling : Communicating via a
data structure passed as a parameter. The
data structure holds more information than
the recipient needs.
Data Coupling : (best) Communicating
via parameter passing. The parameters
passed are only those that the recipient
needs.
No data coupling : independent modules.

Summary
The measure of strength
of the association of
elements within a module
The measure of
interdependence of one
module to another
It is the degree to which
the responsibility of a
single component form a
meaningful unit
It describes the
relationship between
software components
It is a property or
characteristic of an
individual module
It is a property of a
collection of modules
COHESION COUPLING

Refinement
 Refinement is a process of elaboration
 It is a top-down design strategy
 A program is developed by successfully refining levels of procedural
details

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

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.

Criteria for Good Design
 A design should:
 Exhibit a hierarchical organization that makes intelligent use
of control among components of software
 Be modular; that is, the software should be logically
partitioned into components that perform specific functions
and sub functions
 Contain distinct and separable representation of data and
procedure
 Lead to modules that exhibit independent functional
characteristics
 Lead to interfaces that reduce the complexity of connections
between modules and with the external environmental
 Be derived using a repeatable method that is driven by
information obtained during software requirements analysis

Conclude
 When a software project is started from scratch, creating
design is the most obvious first step.
 Design allows not only to find out how the software product
is going to look, but also allows both software owners and
developers to realize how it's going to function.
 Therefore a software design must combine functionality,
informativeness, and simplicity, so that even a comman man
could use the app without need to learn. -

software design: design fundamentals.pptx

More Related Content

Similar to software design: design fundamentals.pptx (20)

More from Dr.Shweta (20)

Recently uploaded (20)

software design: design fundamentals.pptx