Ch4: Software Architecture and Design
What is a design?
1
Software design
What is a software design?
Software architecture and detailed design
2
Goals for a software design
Design for change:
Maintainability addressed during design:
Most challenging responsibility!
3
Types of changes
Replace an existing algorithm by a more efficient
one.
Example: Sorting algorithms
4
Types of changes (contd..)
Change the data representation
Change in an algorithm or a data structure may be
necessary to improve the performance of the
system
5
Types of changes (contd..)
Programs are written to run on a particular
abstract machine:
Hopefully changes in the abstract machine have
minimal impact on the product
Example
6
Types of changes (contd..)
Change in peripheral devices
Change of “social environment”
Change in the development process
7
Case study: Classification of changes
Classify the changes described earlier into
corrective, adaptive, and perfective.
Summary of changes:
Change in the algorithm.
Change in the data structure
Change in the underlying abstract machine
Change in peripheral devices
Change of social environment
Change in the development process
8
Goals for a software design
Support for product families.
What is a product family?
How to design software for product families?
More information on product families:
C. Hofmeister, D. Nord, and R. Soni, “Applied Software
Architecture”
9
Product families
Sequential Completion: Wrong Way
Requirements
Requirements
Requirements
1
1
1
2
2
2
final
product
Model #1
3
Model #1
4
3
3
6
44
Model #1
Model #2
intermediate
design
Model #2 5
7
Model #3
5
10
Product families (contd..)
1
2
3
Model #1
5
Model #2
7
Model #3
11
Product families (contd..)
Better way to design and develop product families:
12
Case study: Product families
Any other examples of product families?
1. Facility reservation system (conference rooms, hotels, etc.)
13
Modules
What is a module?
14
Modules: Structure and representation
What does a software design depict?
How to depict the relationships among the
modules?
15
Mathematical notation
Let S be a set of modules
S = {M1, M2, . . ., Mn}
A binary relation r on S is a subset of
SxS
If Mi and Mj are in S, <Mi, Mj> r can be written
as Mi r Mj
Transitive closure r+ of r
Mi r+ Mj iff
Mi r Mj or Mk in S s.t. Mi r Mk
(We assume our relations to be irreflexive)
and Mk r+ Mj
r is a hierarchy iff there are no two elements Mi,
Mj s.t. Mi r+ Mj Mj r+ Mi
16
Mathematical notation (contd..)
Cardinality of relation r:
Low cardinality is preferred, Why?
How does low cardinality relate to low coupling?
17
Graphical representation
Relations are more intuitively represented by a graph
M1
M1 is related to M2
M5 is related to M6
M2
M3
M4
M
5
M6
18
Graphical representation (contd..)
Directed Acyclic Graph (DAG)
M1
M1,2
M1,1
M1,3
a DAG
M1,2,1
M1,2,1,1
M1,2,2
M2
M3
M4
19
The USES relation
Defined by Parnas
Module Mi USES Module Mj:
20
USES relation (contd..)
USES relation is statically defined.
Procedure M
Cond
M1
Proc 1
Proc1 in M1
Proc2 in M2
M2
Proc 2
M uses M1
M uses M2
21
Hierarchy and the USES relation
USES relation should be a hierarchy:
Advantages of hierarchical uses relation:
22
Properties of the USES relation
Fan-out:
Fan-in:
Low fan-out/high fan-in is preferable
23
Examples of module use (USES):
24
The IS_COMPONENT_OF relation
Purpose:
Mi IS_COMPONENT_OF Mj
Mj COMPRISES Mi
MS,i={Mk|MkSMk IS_COMPONENT_OF Mi} we
say that MS,i IMPLEMENTS Mi
25
The IS_COMPONENT_OF relation (contd..)
A Graphical View
M M M
8 9
7
M
5
M2
M3
M
6
M1
M4
M1
(IS_COMPONENT_OF)
M2
M3
M M M
8 9
7
M
5
M4
M
6
(COMPRISES)
IS_COMPONENT_OF relation constitutes a hierarchy
26
Conceptual view of a module
“Services needed”
“Services provided”
“CODE”
27
Modules: Interface vs. implementation
Interface:
Implementation:
Separation of concerns is supported by division between
module’s interface and implementation
28
Case study: Example of modularization
Modules in an operating system:
29
Case study: Example of modularization
Modules in a word processing application:
30
© Copyright 2025 Paperzz