CS 331

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)
• Dont 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 cant do pop(s)
• The set of rules that govern the internal
  behavior is the concrete invariant
• example if malloc() returns 0, cant 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 Ai,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?