|CONTENTS:||Modularity, The Parnas Approach, Maher's Results, The Hiding Assumption List, Objections, Conclusion|
A. J. Maher was faced with unacceptably high costs relating to changes to the software for avionics systems. Recognizing the importance of software design techniques that minimize the cost impacts of software changes, his team first applied modern structured software design methods (including simplicity of form, readability of code, and hierarchical organization). Initial results using these methodologies achieved some success, but the cost of program changes was still unsatisfactorily high. Maher then turned to Parnas' technique for partitioning computer programs to facilitate future changes. This technique was used on several Kearfott avionics systems with significant success.
Consider the following definition of modularity: A program is modular if it is decomposed into a number of small manageable modules. What is meant by the phrase "manageable module"? The software engineering literature includes the following proposed guidelines for use in defining a manageable module:
These definitions have demonstrated beneficial effects on program design. But there are many examples of good, modular programs (by the above criteria) that are still difficult and expensive to change. In particular, these definitions of modularity do not appear to assure flexibility in program design.
Parnas illustrates the weakness of following these types of definitions of modularity using the example of a simple program to generate a key-word-in-context index. Some potential changes are easily handled within single modules, but others require changes to several or all of the modules. If the latter changes are likely to occur, the given modularization will not result in a program that is easy to maintain.
For ease of maintenance, we would like the effect of each change to be localized to a single module. Parnas' suggestion is to make an explicit list of design assumptions or characteristics that are likely to change in future versions of the system. Then when you partition the problem to form your program modules, select a partitioning that succeeds in hiding each design assumption in as small a portion of the program as possible. The design assumption might be hidden in a single statement (if possible), or in a single module, or in a minimum number of modules. Then, if future changes are of the type indicated in your list of changeable design assumptions, you can be assured that their impact is highly localized. This allows you to expect that a localized design change can be much more easily implemented than if its impact was to spread over many modules. Note that if you do not know the nature of probable future changes to your system, you are likely to be unsuccessful in selecting a problem partitioning that will localize the impact of these changes.
The Parnas approach requires that you build a list of changeable design assumptions whose impact you wish to hide from as much of the program as possible. This is referred to as the Hiding Assumption List. The program is then designed to localize the impact of each change represented on the list.
The Hiding Assumption List is useful not only as a design tool but also to serve as a means of communications with the customer on changeability assumptions and modularity decisions. Broad participation from the customer and the development organizations are desirable since the list can contain assumptions from all levels, including: system requirements, system design, and software design. Since design assumptions are usually top level concepts, they can be expressed in language understandable by everyone. Maher believes this to be one of the major advantages of the Parnas Partitioning approach:
"It does not require knowledge of Computer Science in general or even knowledge of the design details of the program in question, for someone to participate in constructing the Hiding Assumption List. All that is required is the ability to predict which features of the system design are likely to change in the future. ... For operational systems, we even suggest that the list of participants in constructing the Hiding Assumption List be expanded to include the end user of the system. ... In short, we feel that one major advantage of the Hiding Assumption List is its ability to be used for communication by ALL personnel involved in establishing system requirements or system design, since it is written in plain English."
The software design that resulted from Maher's use of the Hiding Assumption List demonstrated its high degree of flexibility and adaptability. However, the early attempts to use Parnas Partitioning were not 100% successful. There were also some cases where the requested change was not localized and the effort required for its implementation was not trivial. There appear to be two primary causes for these problems:
Note that neither of these two problems represent weaknesses in the Parnas Partitioning approach, but in the way it was conducted.
We have seen the danger of a list that is too short. By canvassing everyone who can initiate a change in the system, we increase the likelihood that the resulting list will be complete, that is, that no changes with significant probability of occurrence are omitted.
The list can also be too long. If it includes all changes that the contributors can think of, the resulting program may reach an intolerable level of inefficiency.
How do we resolve the dilemma of a Hiding Assumption List that is either too long or too short? Maher suggests that the following steps be followed to provide sufficient modulation to the basic partitioning concept to assure its practicality:
This technique represents an attempt to buy the maximum insurance against program change with the minimum cost.
There is one common objection to the apparent simplicity of the Parnas Partitioning approach: "If I could specify all future changes in a system, I could develop the final system in the first place. But I don't know all future changes, therefore, the Hiding Assumption List must be incomplete."
This objection fails to take into account the fact that the details of the design change do not have to be known in order to construct a Hiding Assumption List. It is only necessary to identify those design assumptions that are likely to change. It is not necessary to specify the new design assumption for the purposes of partitioning the system design to localize the impact of a change in design assumption. Parnas Partitioning can therefore be effectively used for systems where your only knowledge of a possible change is the fact that your current design assumption will be revised.
Experience has demonstrated the high utility of the Parnas Partitioning approach to the design of flexible computer software.
The Parnas Partitioning approach does not obsolete other modularity criteria. It continues to be desirable to have small, manageable modules and the various design principles for their construction listed earlier should be used in conjunction with Parnas Partitioning for best results.
*These notes are derived from "On the Criteria to be Used in Decomposing Systems into Modules" by D. L. Parnas [CACM, December 1972] and "Parnas Partitioning" by A. J. Maher [The SINGER Company].
Return to Software Engineering Page
JP9601172021 — Copyright ©1996,2005 Dr. Jody Paul