David L Parnas

1
David L Parnas

• Chantel Bowie
• History of SW

2
The Idea

• Software should be designed as a set of
  independently changeable components
• Modules units providing interface between
  interface and implementation
• Compiled separately
• Reusable
• Allows multiple developers to work on different
  modules simultaneously

3
An Ugly Duckling . . .

• Philips Computer Industry (Software Development)
• Apeldoorn, Netherlands 1969
• New product
• Design was not clean, it should be beautiful
• Beauty as in Dijkstras well organized systems
• We are not artists, we are engineers

4
Its Beautiful!!!

• What really matters is DESIGN
• Beautiful encapsulated (changeable)
  information
• Interfaces contains solid lasting information
  (simple)
• Keep beauty?
• ALL arbitrary (changeable), very detailed
  information is hidden

5
Concept of Information Hiding

• Shannons Theory of Information
• Claude Shannon, 1948
• Interfaces containing less information, are more
  beautiful
• http//en.wikipedia.org/wiki/Self-information

6
Case Study

• Key Words In Context (KWIC)
• Accepts an ordered set of lines
• Each line is an ordered set of words
• Each word is an ordered set of characters
• Any line may be circularly shifted
• Repeatedly removing the first word, appending it
  at the end of the line
• Output
• Listing of all circular shifts of all lines in
  alphabetical order
• Modules responsibility assignments
• Not sub-programs

7
2 Decompositions

• Each processing step a module
• Flow chart
• Most common approach to modularization
• Interfaces fairly complex

• Information hiding
• Modules no longer correspond to steps
• Characterized by knowledge of a design decision
• Hidden from other modules
• Interfaces more abstract
• Development would begin early

8
Decomposition 1
9
Decomposition 2
10
Comparisons

• Comparison
• Reduce programming of a number of small,
  manageable, programs
• Share all data representations, access methods
• Differences
• Division of work assignment

11
A Winner?

• Almost always incorrect
• Decompose a system into modules based on a
  flowchart
• Abandon!
• A module is one or more subroutines
• List difficult (likely to change) design
  decisions
• Design to hide decision from others
• Allow subroutines/programs to be assembled
  collections of code from various modules

12
Comments