The Modular Structure of Complex Systems

The Modular Structure of Complex Systems

D.L. Parnas, P.C. Clements, and D.M. Weiss

Published in IEEE Transactions on Software Engineering, March 1985

Summary by Shana Hyvat

Introduction

As systems become more complex, refined approaches to software engineering are necessary. While researchers may explore new theoretical approaches, often those approaches may not work in practice. This at one time, seemed to be the case with modularization. This paper seeks to validate the notion of modularization, particularly in the case of complex systems.

Parnas et. al. refer to a “gap”, in the early 80’s, between researchers’ visions of modular software engineering and the actual implementation in industrial and governmental software engineering laboratories. Several reason are attributed to this “gap”:

·  Responsible managers will not implement untested principles.

·  Examples used in research differed from practical problems.

·  Researcher’s ideas needed refinement before they could be implement

·  “Old-style” programmers claim modularization is impractical.

·  Some academics claim, practitioners were not intellectually capable of the task of modularization.

Parnas et. al. had an understanding of modularization as well as an understanding of the real implementation done by programmers and so were led to reject both that modularization is impractical and that programmers were incompetent. In order to close the “gap” they went on to implement a real and significant complex system, with a modular structure.

They choose the Onboard Flight Program for the A-7E aircraft to implement and test modularization. It’s a complex program that is considered the best of its kind and while it has its merits, the program is complicated and uses many “dirty tricks”. Its important to not that choosing a “sufficiently challenging” system to implement is important to validate the merits of modularization and not the coincidence of a simple program.

Background and Guiding Principles

The structure of the software system is the decomposition into parts and the relations between the parts. While the paper only discusses the module structure it is important to keep in mind the overall view of the system. I will make an analogy with the structures to aspects of object oriented systems. While this analogy may not be precise to the definition it will help to clarify the roles of these structures.

Module Structure

A module consists of a group of closely related programs that one programmer or a team of programmers are responsible for. The module structure is the decomposition of the program into modules. A module can be thought of as an object and the module structure is the definition of the objects in some system.

Uses Structure

The uses structure determines the executable subsets of the software. The components of this structure are programs and programs are parts of modules. The uses structure can be thought of as the methods of an object.

Process Structure

The process structure is the decomposition of the run-time activities of the system into processes. Any process may invoke programs in several modules. The process structure can be though of as the execution of the main method. Although the true definition of a process would allow an object to make meaningful calls to a man method.

Goals of Modular Structure

From here on, the paper only discuses modular structure as it is the foundation of the entire system. The goals of modular structure discussed in this paper, are similar to what we think of modular structure in object oriented programming. There are several such goals. Each module is simple enough to be fully understood.

Change implementation without affecting other modules.

Interfaces must be unlikely to change.

Simultaneous changes to different modules can be made independently, as in the case of making a huge software change.

In practice, when implementing the system, the authors noticed following these goals was leading to a software system composed of hundreds of small modules. With hundreds modules it becomes difficult to keep track of which ones would be affected by changes. Also, maintaining the software would prove to be difficult as engineers would be ignorant to the internal structure of the modules and would have to search though many module documents to find the ones they need to change.

To fix these problems the authors decided to organize the models into a tree-structured hierarchy. Interestingly, this works very much like classes in an object oriented approach. Additional goals for the hierarchy must also be met. 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.

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.

There are different kinds of information that can be used to describe modules. One is, its function of the module with respect to the entire system. Modules can also be described by the information that it keeps secret, in the module guide. The module specification provides an in-depth look at function and facilities of the module.

A-7E Module Structure

For the Onboard Flight Program for the A-7E aircraft, there are three top level modules. It seems appropriate to mention the top level modules, as they are general enough to be considered in other software projects.

The Hardware-Hiding Module includes the programs that need to be changed if changes are made to the hardware. This module implements a virtual hardware interface that is used by the rest of the software. The secrets of this module are the data structures and algorithms used to implement the virtual hardware. A program in this module might be one that does output to the hard-drive.

The Behavior-Hiding Module includes the programs that need to be changed if changes are made to the requirements specification of the program. The requirements specification are the secrets of this module. A program in this module might be one that initiates flight sequence.

The Software Decision Module includes all the programs that have nothing to do with either the hardware or the specification requirements. They contain various utility programs define by the software designers. A program in this module might be one that sorts an array of integers.

Conclusions

A running program for the A-7E was not produced, but the authors made some interesting observations based on their work in modularizing the system. Information hiding in complex systems is practical when using the module guide, where the hierarchical structure of the module is documented. Some other advantages of the module guide is that new programmers gain a quick grasp of project without having to discuss the project with others. The model guide must be comprehensive in including all aspects of the module including secrets, roles and interfaces. In fact, the authors found that they had modules without clear responsibilities and determined that they needed to focus more on secrets when defining models.

Clearly many of these principles exist in what we know today as Object Oriented.

Similar challenges exist in the next generation of modular structures, specifically, for Agent Oriented approaches. In Agent Oriented approach many of the ideas in theory have yet to find their way into practice.

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.

4