The Modular Structure of Complex Systems

1
The Modular Structure ofComplex Systems

• D.L. Parnas, P.C. Clement, and D.M. Weiss
• Published in IEEE Transactions on Software
  Engineering, March 1985

Presented by Shana Hyvat Readings in Software
Engineering
2
Motivation
Software Systems are getting more complex and yet
there exists a growing gap between approaches
presented in theory and implementations in
practice.
3
Possible Reasons for the gap

• Managers will not implement untested principles
• Theoretical examples lack practical relevance
• Theoretical approaches need refinement
• Modular Systems are impractical
• Practitioners are not intellectually capable

4
Valid reasons to address

• Managers will not implement untested principles
• Theoretical examples lack practical relevance
• Theoretical approaches need refinement
• Modular Systems are impractical
• Practitioners are not intellectually capable

5
Implement a Real and Significant Complex System
This is not without challenges, but still will
serve as a model for practical projects.
6
A Sufficiently Challenging Program

• Onboard Flight Program (OFP)for the A-7E
  aircraft

• High quality, complex program
• Considered the best of its kind
• Code is complicated and uses many dirty tricks
• Important time and size constraints are barely met

7
Software Structures
Decompositions of the Program

• Module Structure
• like defining objects
• Uses Structure
• like defining objects methods
• Process Structure
• like defining the execution of methods in the
  main method

8
Design Principle Model Structure
Decomposition Criterion Information Hiding

• Details that are likely to change become secrets
  of a particular module, and exist nowhere else
• like private data variables
• Secret information comes out through a module's
  access programs
• like accessor methods of an object

9
Goals of Modular Structure

• Each module is simple enough to be fully
  understood
• Change implementation in one module without
  affecting other modules
• Interfaces must be unlikely to change
• Simultaneous changes to different modules can be
  made independently

10
Problems in Modular Structure

• The large number of modules makes it unlikely
  that all relevant modules will be known when a
  change is necessary
• Information hiding works too well engineers
  don't necessarily know the inner structure of the
  modules and would have to search to find the
  right ones to change
• It would be easy to miss changing important
  modules

11
Tree-Structured Hierarchy

• The hierarchical structure of the module will be
  documented in a module guide
• A software engineer should understand how to use
  the module without knowing its internal
  implementation
• A reader with well defined concern, should be
  able to distinguish relevant components of a
  model from irrelevant ones

12
Tree-Structured Hierarchy (continued)

• The number of branches in the tree should be
  small enough to help identify dependences in the
  tree and to verify that there are no overlapping
  responsibilities.

13
Module Description

• Three kinds of information can be used to
  describe modules
• Its function with respect to the entire system
• The information it keeps secret
• The facilities it provides
• The module guide focuses on secrets, with some
  functional description
• The module specification provides an in-depth
  look at function and facilities

14
A-7E Module Structure Top Level

• Hardware-Hiding Module
• Includes the programs that need to be changed if
  any of the hardware is changed
• A virtual hardware interface that is used by the
  rest of the software
• The secrets are the implementation the virtual
  hardware

15
A-7E Module Structure Top Level

• Behavior-Hiding Module
• Includes programs that need to be changed if
  there are changes in requirements specification
  about the behavior

• Software Decision Module
• Modules that don't relate to the hardware or the
  requirements
• Utility modules defined by the software designers

16
Conclusions

• Running program for the A-7E was not produced
• Authors Observations
• Information hiding in complex systems is
  practical when using the module guide
• With the model guide new programmers gain a quick
  grasp of project
• Important to discuss, secrets, roles and
  interfaces in the module guide.

17
Conclusions
In addition Clearly many of these principles
exist in what we know today as Object
Oriented. Implementing a complex system may not
prove to produce a final product, but may provide
an environment from which to cultivate models for
real implementations.