Hiding Assumptions and Parnas Partitioning*

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.

Modularity

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:

• Modules must be independent of each other.
• A module implements an indivisible function.
• A module should have only one entrance and exit.
• The function of a module is unaffected by:
  • the source of its input,
  • the destination of its output, and
  • the history of the module.
• Modules must be small, that is,
  • less than one page of source code,
  • less than one page of flowchart,
  • less than 10 decision statements, etc.
• Modules must be separately compilable.
• Modules should have uniform work content.
• Modules must be separately testable.

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.

The Parnas Approach

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."

Maher's Results

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:

• The type of change was not listed in the Hiding Assumption List, so the design did not attempt to localize its impact.
• The actual implementation had wandered from the intent of the original partitioning decision due to lax enforcement of the isolation decisions.

Note that neither of these two problems represent weaknesses in the Parnas Partitioning approach, but in the way it was conducted.

The Hiding Assumption List

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:

• Develop an initial Hiding Assumption List that is as large as possible -- while it never helps to add impossible changes to the list, all other changes are acceptable.
• Order the initial list according to the probability of occurrence of the change"there is no need to have a quantitative measure of this probability, the ability to rank all changes to their relative probability of occurrence is sufficient.
• Determine what design action is required to minimize the impact of each change. Categorize the impact of each design change on the performance of the program.
• Immediately accept the design actions that have no impact on performance. They represent design alternatives that provide insurance against the corresponding change at no cost.
• Review the remaining entries in the ordered Hiding Assumption List, starting with the most probable entries. Determine the acceptability of each design action based on the likelihood of the change and the magnitude of the performance impact. In some cases it will be desirable to seek a more moderate design action that provides some measure of protection against change but with an acceptable impact on performance.
• When the impact on performance has built to the margin of tolerability, reject all design actions which lie lower on the ordered list.

This technique represents an attempt to buy the maximum insurance against program change with the minimum cost.

Objections

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.

Conclusion

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.