The Modular Structure of Complex 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

Motivation Software Systems are getting more complex and yet there exists a growing “gap” between approaches presented in theory and implementations in practice.

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

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

This is not without challenges, but still will serve as a model for practical projects. Implement a Real and Significant Complex System

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

Software Structures Module Structure like defining objects Uses Structure like defining objects’ methods Process Structure like defining the execution of methods in the main method Decompositions of the Program:

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

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

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

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

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.

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

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

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

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.

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.