Ch4: Software Architecture and Design

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

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

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

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

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

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

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

8 Advantages of modular designs

9 Properties of modular designs  Cohesion:  Coupling:

10 Top-down design strategy General Specific

11 Bottom-up design strategy Pieces Compose

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

13 IS_COMPONENT_OF revisited M 1 M M M M MM M M 3 M M MM M M 2 M 3 M 4 M 1 (IS_COMPONENT_OF) (COMPRISES) What design strategy do the relations IS_COMPONENT_OF & COMPRISES depict?

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

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

16 TDN (contd..)

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

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

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

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

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

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

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

24 Abstract objects  Example of an abstract object: stack

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 PUSH ST

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

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

28 ADT definition

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

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

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

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