1. CS 331 Modules Chapter 6

2. Overview Decomposition and abstraction Program organization Abstract vs. concrete User-defined types Example discussion

3. Decomposition Break the problem down into sub-tasks “stepwise decomposition” (Parnas 72) –But how can we tell if this has been done right? –Minimize the amount of information one routine needs to have about another (low coupling) –Don’t have routines do too many things at once (high cohesion) (Constantine 78?)

4. Information Hiding External vs. internal behavior What a routine does vs. how the routine does it One approach: if a specification or design decision seems likely to change, then isolate those portions of the program that need to be modified Example: concrete representations of data structures

5. Abstraction Procedural abstraction is provided in most modern PLs –functions and procedures Data abstraction is available in some PLs A data abstraction is a set of data objects, and the set of operations defined on those objects –e.g. for a stack, operations are push, pop, isEmpty

6. What is a module? One definition: a module is a program construct that implements a data abstraction by associating data objects and their operations –text says “collection of variable and procedure declarations” (paraphrase of Sethi) –a module may enforce information hiding, as in C++ classes –it may be possible to compile a module separately from the program(s) which use it

7. External vs. Internal Behavior The external behavior of a module is provided by public members, either functions, variables or constants. (What the user sees.) The internal behavior is provided by private members, perhaps in conjunction with public members. (The internal behavior refers to how the private members interact with each other.)

8. Representations The abstract representation is how the user visualizes the data –matrix of real numbers, with operations such as invert() and transpose() The concrete representation is how the module implements it –a matrix may be represented as a set of row and column linked lists, for example

9. Invariants The set of rules that govern the external behavior are formalized in the abstract invariant –example: if isEmpty(s) then can’t do pop(s) The set of rules that govern the internal behavior is the concrete invariant –example: if malloc() returns 0, can’t do a push because the stack is full :-(

10. Tie it together The external behavior of a module, as provided by the public members, is governed by the abstract invariant(s) The private members, operating on the concrete representation of the object, in accordance with (the consistency rules specified in) the concrete invariant, implement the external behavior (Guttag 75)

11. User-defined Types If a PL allows the programmer to create modules, with the result that modules are used in the same way as if they were built into the language, then that PL supports user-defined types The PL may or may not support information hiding, or invariant checking, or overloading, or dynamic type checking...

12. Example: Sparse Matrices External behavior: –create a matrix A, specifying its size –access and/or modify A[i,j] for suitable i,j –iterate through a row or column of A From these operations we can print the matrix, compute its transpose, perform elementary row operations, etc.

13. Questions What is a suitable concrete representation? What are the private members? –Functions? Variables? Constants?? Given the private members, what is the concrete invariant? Can we provide the external behavior given the available private functions? Does the concrete invariant imply the abstract invariant?