1. Ch4: Software Architecture and Design

2. 1 What is a design?

3. 2 Software design  What is a software design?  Software architecture and detailed design

4. 3 Goals for a software design  Design for change:  Maintainability addressed during design:  Most challenging responsibility!

5. 4 Types of changes  Replace an existing algorithm by a more efficient one.  Example: Sorting algorithms

6. 5 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

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

8. 7 Types of changes (contd..)  Change in peripheral devices  Change of “social environment”  Change in the development process

9. 8 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

10. 9 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”

11. 10 Product families Requirements 1 2 3 Model #1 Model #2 5 1 2 3 4 6 7Model #3 4 1 2 3 Model #2 5 Model #1 4 intermediate design final product Sequential Completion: Wrong Way

12. 11 Product families (contd..) 1 2 357 Model #1 Model #2 Model #3

13. 12 Product families (contd..)  Better way to design and develop product families:

14. 13 Case study: Product families Any other examples of product families? 1. Facility reservation system (conference rooms, hotels, etc.)

15. 14 Modules  What is a module?

16. 15 Modules: Structure and representation  What does a software design depict?  How to depict the relationships among the modules?

17. 16 Mathematical notation  Let S be a set of modules S = {M 1, M 2,..., M n }  A binary relation r on S is a subset of S x S  If M i and M j are in S,  r can be written as M i r M j  Transitive closure r + of r M i r + M j iff M i r M j or  M k in S s.t. M i r M k and M k r + M j (We assume our relations to be irreflexive)  r is a hierarchy iff there are no two elements M i, M j s.t. M i r + M j  M j r + M i

18. 17 Mathematical notation (contd..)  Cardinality of relation r:  Low cardinality is preferred, Why?  How does low cardinality relate to low coupling?

19. 18 Graphical representation Relations are more intuitively represented by a graph M M M M M M 1 2 3 4 5 6 M 1 is related to M 2 M 5 is related to M 6

20. 19 Graphical representation (contd..)  Directed Acyclic Graph (DAG) M 1 M 2 M 3 M 4 M 1,1 M 1,2 M 1,3 M 1,2,1 M 1,2,2 M 1,2,1,1 a DAG

21. 20 The USES relation  Defined by Parnas  Module M i USES Module M j :

22. 21 USES relation (contd..) USES relation is statically defined. Cond M1 Proc 1 M2 Proc 2 Proc1 in M1 Proc2 in M2 M uses M1 M uses M2 Procedure M

23. 22 Hierarchy and the USES relation  USES relation should be a hierarchy:  Advantages of hierarchical uses relation:

24. 23 Properties of the USES relation  Fan-out:  Fan-in:  Low fan-out/high fan-in is preferable

25. 24 Examples of module use (USES):

26. 25 The IS_COMPONENT_OF relation  Purpose:  M i IS_COMPONENT_OF M j  M j COMPRISES M i  M S,i ={M k |M k  S  M k IS_COMPONENT_OF M i } we say that M S,i IMPLEMENTS M i

27. 26 The IS_COMPONENT_OF relation (contd..) M 1 M M M M MM M 2 4 5 6 7 89 M 3 M M MM M 5 6 7 89 M 2 M 3 M 4 M 1 (IS_COMPONENT_OF) (COMPRISES) A Graphical View IS_COMPONENT_OF relation constitutes a hierarchy

28. 27 Conceptual view of a module “Services needed” “Services provided” “CODE”

29. 28 Modules: Interface vs. implementation  Interface:  Implementation:  Separation of concerns is supported by division between module’s interface and implementation

30. 29 Case study: Example of modularization  Modules in an operating system:

31. 30 Case study: Example of modularization  Modules in a word processing application: