1. Ch4: Software Architecture and Design

2. 1 Modules: Interface vs. Implementation (contd..)  Interface design considerations:

3. 2 Module: Interface vs. Implementation (contd..) Symbol table GET(Varname) returns (int,POS) PUT(Varname,value) returns POS CREATE(Varname,size) Retrieve value Store new value New entry creation size = #of entries it represents

4. 3 Module: Interface vs. Implementation (contd..)  Module symbol table hides:

5. 4 Modules: Interface vs. implementation (contd..)  Support for prototyping:

6. 5 Modules: Interface vs. Implementation (contd..)  Separation of interface and implementation supports information hiding:

7. 6 Modules: Interface vs. Implementation (contd..)  Secrets that may be hidden in the module:  How the algorithm works (quicksort, bubble sort, etc.)  Data formats (Binary, ASCII, etc.)  Data structure (linked list, array etc.)  User interfaces (AWT)  Texts (language specific grammars, spellings, etc.)  Details of interfacing with input/output devices

8. 7 Modules: Interface vs. Implementation (contd..) openFile() closeFile() readFile() File I/O module Unix O/SAIX O/SWindows O/S

9. 8 Advantages of modular designs

10. 9 Properties of modular designs  Cohesion:  Coupling:

11. 10 Top-down design strategy General Specific

12. 11 Bottom-up design strategy Pieces Compose

13. 12 Top-down vs. bottom-up design strategy  Which choice is better?  How should documentation be structured?

14. 13 IS_COMPONENT_OF revisited 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) What design strategy do the relations IS_COMPONENT_OF & COMPRISES depict?

15. 14 Design notation  Why do we need a design notation?  What are the different types of design notation?

16. 15 Textual Design Notation (TDN)  Textual design notation loosely based on Ada  Interface description  Module may export:  Comments are used to describe

17. 16 TDN (contd..)

18. 17 TDN (contd..)  Uses  Implementation  An entity E exported by module M is denoted by M.E

19. 18 TDN (contd..) R T YX X Export section: Consistency and completeness analysis:

20. 19 Graphical design notation (GDN) Graphical notation: Y Z Module X A B R T C B

21. 20 Categories of modules  Advantages of categorization into modules:  Categories of modules:

22. 21 Categories of modules: Standard categories  Functional modules:  Libraries:  Common pools of data:

23. 22 Categories of modules (contd..)  Abstract objects  Abstract data types

24. 23 Abstract objects  What is an abstract object:  Difference between an abstract object and a library module:

25. 24 Abstract objects  Example of an abstract object: stack

26. 25 Abstract objects (contd..) Public Interface User PUSH POP TOP EMPTY Private Implementation Designer Head: Int; ST: Array[100] of Int; Push(X Int) … End; Int Pop() … End; TOP 5 10 15 20 PUSH 5 20 15 105 2015 10 5 ST

27. 26 Motivating ADTs  All built in types are ADTs  Use of ADTs:

28. 27 Motivating ADTs (contd..)  Applications may require multiple abstract objects of one “type”.  Abstract data types (ADTs) introduced to address these issues.

29. 28 ADT definition

30. 29 ADT examples  Set:  Multiset:  Sequence:  Graph:

31. 30 Abstract data types: Stack example Stack ADT indicates that details of the data structure are hidden to clients

32. 31 Abstract objects vs. ADTs O K O K T H I S G O I S O D Module object Single instance Has state Multiple instances ADT has no state Stack S1, S2, S3; STACK of chars STACK

33. 32 Abstract data types: Summary  Proposed by B. Liskov (MIT) in 1975  Abstract data type:  ADTs and OO