Parnas 1 Modularization

Author: James P. Gunderson
Date:15-DEC-1998
Version:1.0
This is the design documant for the development of the parnas1.map for the DEMon system. The original description comes from the paper "On the Criteria to be used in Decomposing Systems into Modules (Comm. ACM V 15:12 December 1972. In this paper Parnas discusses two different decompositions of a small program (KWIC), and the effects of those decompositions on the response of the program to change.

Functional Requirements:

  1. Batch - program operates in batch mode
  2. LineDef - definition of the line structure
  3. WordDef - definition of the word structure
  4. Shift - definition of the circular shift operation
  5. Output - definition of the output format
  6. Sort - output will be sorted
  7. Sequence - general sequence of operations

Modular Decomposition

In the first Decompostion the program was decomposed into 5 modules:
  1. Input - read the input and store it
  2. Shift - produce an index of the circular shifts
  3. Sort - produce an index of the sorted circular shifts
  4. Print - output the sorted shifts
  5. Control - a top level sequencer.

Each of these has specific design decisions embedded in the module.

Design Parameters

Module Num Param Num Design Param
0 0 Batch
0 1 LineDef
0 2 WordDef
0 3 Shift
0 4 Output
0 5 Sort
0 6 Sequence
1 0 ReadLines
1 1 Store
1 2 Format1
1 3 Index1
1 4 Batch
2 0 Load/Store
2 1 Format1
2 2 Index1
2 3 Index2
2 4 PairStore
3 0 Format1
3 1 Index1
3 2 Format2
3 3 Index2
3 4 Index3
3 5 Batch
4 0 Format1
4 1 Format2
4 2 Index1
4 3 Index2
4 4 Index3
4 5 Batch
5 0 Sequence
5 1 Batch

Dependencies

To develop the dependencies, a connection matrix was developed which answered the question "If a change is made in this design parameter, where might other changes need to be made to maintain consistency?"

The reason "might" is used in that the actual change will be determined by a probability distribution, so we needed to analyse the possible connectivity in the decomposition. For example, in looking at the Input Module, if there was a requirement to alter the Index1 design parameter, what other modules might be affected? Clearly, any module which relies on Index1, might be affected, and so dependencies would be established from (1, 3) to {(2,2), (3,1), (4,2)}.

In addition, it might be possible for a change in a design parameter to affect a functional requirement. For example, if something in Shift Module precluded the use of batch mode (admittedly, hard to imagine), this would cause a change to the functional requirement (0,0), and all other modules which depend on batch mode.

Using this type of analysis the following connectivity set was produced:
SourceDestination Set
(0,0){ (0,6), (1,1), (1,2), (1,4), (2,0), (2,1), (2,4), (3,5), (4,0), (5,1) }
(0,1){ (1,0), (1,1), (1,3), (2,2), (3,1), (4,2) })
(0,2){ (1,3), (3,3), (4,3) }
(0,3){ (2,3), (3,3), (4,3) }
(0,4){ (0,0), (1,4), (2,4), (3,5), (4,4), (4,5), (5,1) }
(0,5){ (0,0), (1,4), (2,4), (3,4), (3,5), (4,5) }
(0,6){ (5,0) }

Revision history:
Last modified: Tue Dec 15 16:47:39 1998