Transcript Document 7582878

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?