Design
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 1
Analysis -> Design
Detailed DFDs;
Flowchart; N-S
chart; pdl;
component level
designs
Scenario-based
diagrams
Structure Chart
UML class hierarchy
Procedural
design
Interface
design
Architectural
design
Structural components and
procedural description of software
Layout and interaction mechanisms
for human-machine interaction;
Internal and external interfaces
Relationships among major
structural components of program;
Patterns and styles
Class diagrams
Data design
Information domain model created
during analysis
data structures and database model
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 2
Design Principles


Design not equal to coding!!!
Design should:
•
•
•
•
•
•
•
Consider alternative approaches
Be traceable to analysis model
Be structured to accommodate change
Degrade gently
Assess for quality while creating design
Be reviewed
Design derived from repeatable method
driven by information in req. analysis phase.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 3
Fundamental Concepts of Good
Design

Abstraction
•
•
Solution stated in problem environment
Data, procedure, control

Refinement: Top-down design strategy

Software Architecture
•
Hierarchical structure of procedural
components
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 4
Concepts of Good Design

Modularity
•
•
•
Easier to solve problems when broken up
(logical partition)
“size” based on independent functional
characteristics (high cohesion and low coupling)
Lead to interfaces with reduced complexity
easier to build, easier to change, easier to fix ...
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 5
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.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 6
A structure chart showing data
coupling
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 7
Concepts of Good Design cont.

Information Hiding
•


Controlled interfaces
Use of patterns that convey essence of a
proven design solution
Refactoring – a reorganization technique that
simplifies the design
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 8
Refactoring

Fowler [FOW99] defines refactoring as:
"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.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 9
Design Patterns



Best designers have an uncanny ability to see
patterns and combine them to create a solution
A description of a design pattern may also consider
Design forces describe non-functional
requirements (e.g., ease of maintainability,
portability) associated with the software
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.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 10
Frameworks


A framework is not an architectural pattern,
but rather a skeleton with a collection of
“plug points” (or hooks and slots) that enable
it to be adapted to a specific problem
domain.
Note that:
•
•
©Ian Sommerville 2006
Design patterns are more abstract, less
specialized and have smaller architectural
elements than frameworks.
In an OO context, a framework is a collection of
collaborating classes
Software Engineering, 8th edition. Chapter 11
Slide 11
Assessment of Design Notations

Design notations should
•
•
•
•
•
•
•
•
•
Support modularity
Be simple
Be easy to edit
Be machine readable
Maintainable
Enforce structure
Represent data
Goal of automatic verification
“code-to” ability
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 12
Design Post-Processing






Processing narratives for each module
Interface description for each module
Local/global data structures defined
All design restrictions/limitations noted
Conduct design review
Consider optimization
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 11
Slide 13