1. Chapter 13 Design Concepts and Principles

2. Analysis to Design
component- level design

3. Where Do We Begin?
modeling
Prototype
Spec
Design

4. A good design Implement all explicit and implicit requirements
Be a readable and understandable guide for developers and customers
Provide a complete picture of software

5. Design Principles (1)
From Davis [DAV95]
The design process should not suffer from ‘tunnel vision.’
The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world.
The design should exhibit uniformity and integration.

6. Design Principles (2)
From Davis [DAV95]
The design should be structured to accommodate change.
The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is being created, not after the fact.
The design should be reviewed to minimize conceptual (semantic) errors.

7. Fundamental Concepts Abstraction — data, procedure, control
Refinement — elaboration of detail for bstractions
Modularity — compartmentalize data and function
Architecture — overall structure of the software
Partitioning — partition the program structure
Data structure — the logical relationship of data
Procedure — the algorithms that achieve function
Hiding — controlled interfaces
Function independences — cohesion, coupling

8. Abstraction
Data abstraction
Procedure abstraction
Control abstraction

9. Data Abstraction door manufacturer model number type swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure

10. Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter

11. Refinement Refinement — elaboration of detail for all abstractions
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

12. Modular Design
modularity—compartmentalization of data & function

13. Sizing Modules: Two Views

14. 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

16. An Effective Modular System
Modular decomposability
Modular composability
Modular understandability
Modular continuity
Modular protection

17. Architecture
“The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]
superordinate
subordinate

18. Partitioning the Architecture
“horizontal” and “vertical” partitioning are required

19. Horizontal Partitioning
define separate branches of the module hierarchy for each major function
use control modules to coordinate communication between functions
function 1
function 3
function 2

20. software that is easier to test
software that is easier to maintain
propagation of fewer side effects
software that is easier to extend

21. Vertical Partitioning: Factoring
design so that decision making and work are stratified
decision making modules should reside at the top of the architecture
decision-makers
workers

22. Data Structure Data Structure — a representation of the
logical relationship
Item: integer, string…
Vector: array
Space: structure
Linked list, node

23. Software Procedure
Procedure — a precise specification of
processing

24. Information Hiding Hiding — controlled interfaces module clients
"secret"
clients
a specific design decision

25. Why Information Hiding?
Leads to encapsulation — an attribute of high quality design
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
Results in higher quality software

26. 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.

27. Cohesion
The degree to which a module performs one and only one function

28. Coupling
A measure of interconnection among modules

29. uncouple
control
stamp
data
content
common

30. Content Coupling
Common Coupling

31. Design Heuristics
Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion.
Attempt to minimize structures with high fan-out; strive for fan-in as depth increases.
Keep the scope of effect of a module within the scope of control of that module.
Evaluate module interfaces to reduce complexity and redundancy and improve consistency.
Define modules whose function is predictable, but avoid modules that are overly restrictive.
Strive for “controlled entry” modules by avoiding “pathological connections.”

34. Design Specification