Software Design
Software Design
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 modeland 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
proceduraldesign
interfacedesign
architecturaldesign
datadesign
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).
7
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
modulecontrolledinterface
"secret"
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
a specific design decision
16
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
17
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
BFunction
D
Function
CFunction
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 moduleuses/alters data in another module
Common Coupling : 2 modules communicatingvia global data
External Coupling :Modules are tied to anenvironment external to the software
Control Coupling : 2 modules communicatingwith a control flag
Stamp Coupling : Communicating via adata structure passed as a parameter. Thedata structure holds more information thanthe recipient needs.
Data Coupling : (best) Communicatingvia parameter passing. The parameterspassed are only those that the recipientneeds.
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 opensturn knob clockwise;if knob doesn't turn, then
take key out;find correct key;insert in lock;
endifpull/push doormove 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.