Ch4: Software Architecture and Design

1. Ch4: Software Architecture and Design

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

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

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

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

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

7. 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. Modules: Interface vs. Implementation (contd..) File I/O module openFile() closeFile() readFile() Unix O/S Windows O/S AIX O/S

9. Advantages of modular designs

10. Properties of modular designs • Cohesion: • Coupling:

11. Top-down design strategy General Specific

12. Bottom-up design strategy Pieces Compose

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

14. M M M M M M 6 8 9 5 1 7 M M M 3 4 2 M M M 4 2 3 M M M M M M 1 6 8 9 5 7 (IS_COMPONENT_OF) (COMPRISES) IS_COMPONENT_OF revisited What design strategy do the relations IS_COMPONENT_OF & COMPRISES depict?

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

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

17. TDN (contd..)

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

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

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

21. Categories of modules • Advantages of categorization into modules: • Categories of modules:

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

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

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

25. Abstract objects • Example of an abstract object: stack

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

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

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

29. ADT definition

30. ADT examples • Set: • Multiset: • Sequence: • Graph:

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

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

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