The Modular Structure of Complex Systems

1. The Modular Structure ofComplex Systems D.L. Parnas, P.C. Clements, D.M. Weiss

2. Why Was This Paper Written • The gap between academic software engineering and practicing software developers • Practitioners tend to be unwilling to adopt work resulting from software engineering research • Research is impractical for “real” software • Managers are not risk takers – research approaches are not proven • The research examples were not like the real problems practitioners encounter • Research ideas require refinement before they can be applied in practice • Practitioners are not intellectually capable of working with ideas formulated in the research lab • This paper provides an example – case study – showing that Parnas’ information hiding approach could be used on a “real” and “hard” software system

3. The Domain • Reimplement the onboard flight program for the A-7E aircraft • Use information hiding, documentation, etc • Can compare the results to the original program which was considered to be a good software system • Compare via functional implementation, the software's ability to adopt to change and the ease of fixing defects

4. Important Software Structures • Module Structure • Decomposition of the system into modules • Hides secrets and provides the assumptions that the implementers of one module are allowed to make of the other modules • Uses Structure • A form of the “requires the presence of relation” • Process Structure • Decomposition of the system into runtime processes – the system has many concurrent processes

5. Information Hiding (Again) • The module structure is formulated using information hiding • Secrets of modules are based on things that are likely to change • Interfaces are designed based on things that are unlikely to change • Goals • The modules should be simple and comprehensible • Enables design for change • A well defined system concern should be quickly mappable to a set of modules • Minimize module coupling (examine fan-out/fan-in)

6. Documentation – Module Guide • The Module Guide is a document • Lead a reader to the module that implements a particular aspect of the system • States the criteria used to assign a particular responsibility to a module • Ways to describe a module • Roles played by the individual modules in the overall system • Secrets associated with each module • Facilities provided by each module

7. The A-7E Modules • During the design of the A-7E modules it was apparent that there would be many modules • Especially compared to an “academically-sized” system • Needed a way to help the users navigate through all of the modules • Solution: Create a module hierarchy based on the type of secret

8. The A-7E Module Structure • High-Level modules • Hardware Hiding Module • Abstracts hardware from the software – allows for plug and play hardware • Behavior Hiding Module • Abstracts requirements related to the system behavior that are likely to change • Software Decision Module • Hides algorithms and implementation decisions

9. The A-7E Module Structure • Design then proceeded to define the second and third-level modules • The third-level modules seem to be at the level that can be directly implemented • Examples: Spatial Relations Module, Aircraft Motion Module, etc. • The higher levels were for organization (they were abstract), while the lower levels were suitable for implementation

10. Conclusions • An information hiding approach towards design is appropriate for “real world” systems • Parnas suggests that the Module Guide was a key artifact for guiding the design, and keeping it on track • The new system never was implemented in the A-7E aircraft, but it was used in a simulator