CS 331

Modules

Chapter 6

Overview

• Decomposition and abstraction

• Program organization

• Abstract vs. concrete

• User-defined types

• Example discussion

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?)

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

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

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

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

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

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 :-(

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)

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

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.

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?