Hello

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|MkSMk 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