Revisiting Parnas: On the Design and Development of Program Families

The paper presents a comparison between techniques to develop program families. “Stepwise refinement”, introduced by Dijkstra, tries to develop programs through the use of informal, intermediate representations of programs that are then refined. The refinement introduces the design decisions by implementing the informal program in actual languages.

The technique introduced by Parnas is called “Module Specification”.  In this technique, the intermediate stages are specifications of behavior that is “encapsulated” into modules. He asserts that this approach leads to decrease the final cost of producing the software as the modularization helps to deal with complexity. Also, the use of modules and specifications helps to postpone design decisions, particularly those that will differentiate family members.

Sometimes, Parnas focus seems to be only to broaden the family possibility, in other words, increase the amount of variation points. This occurs specially at the beginning of the process. His strategy aims in making the design to enable the postponement of the decisions. In some sense, he puts the focus of a software family as it was to have as many members as possible.

Although the use of information hiding to postpone design decisions points is an excellent way to create variation points, leading to the Strategy design pattern, I think it should be used with care because it could lead to overgeneralization of the modules. Modules that are unlikely to change or vary may have to carry the complexity needed to implement the improbable variation. Maybe, this occurs only at early stages in the process.

The most interesting point is that the author starts thinking about planning before developing a program family. He also gives importance to the order in which the design decisions are made. This suggests that an approach for software families should choose the degree of importance of each aspect and characteristic so that the resulting program addresses its purposes properly.

Revisiting Parnas: The influence of software structure on reliability

Here, Parnas steps aside from software correctness and formal proof of programs and discusses another problem: Is a program that outputs correct useful if we cannot rely on it when we demand?

He introduces the term Reliability “a measure of the extent to which the system can be expected to deliver usable services when those services are demanded”. In other words, a system is considered to be highly reliable, if it is highly probable that, when we demand a service from the system, it will perform to our satisfaction.

Software structure may harm reliability when build upon the wrong assumption that nothing can go wrong. Parnas consider some situations that can influence reliability, among them the influence of external dependencies and the correctness of the software itself.

The author explains that the error detection and handling mechanism is often neglected or poorly done. It is important that the interface between modules enable communication about errors as well. The means to express this possibility of errors between interrelated modules seems to be well solved, e.g., by Exceptions and try-catch blocks in modern languages such as Java. Still, the way to use them correctly is easily overlooked.

Nowadays, software architecture studies contemplate a whole bunch of other attributes of software architectures. Yet, the influence of software structure on reliability is still a hot topic in software architecture. And although some of the early questions can be answered, new ones arrive.

Revisiting Parnas: Use of the concept of transparency in the design of hierarchically structured systems

In year 1975, Parnas publishes with D.P. Siewiorek “Use of the Concept of Transparency in the Design of Hierarchically Structured Systems”.  The publication talks about the difficulties in using an Outside In (aka Top down) approach to design and develop software. The main point discussed in the piece is the cost of using abstraction in software constructions.

For the authors, the use of abstractions is an excellent way to make big systems understandable as a whole, as higher level abstractions hide the inner workings of a piece of software. The approach that starts from the outside in can have some difficulties, however. (1) The difficulty to obtain a good specification of the “outside” and (2) even harder to express it without implying internal design decisions, (3) the derivation from such a specification is frequently not feasible, (4) inner details of the implementation can already be fixed, such as hardware or an operating system.

The term Transparency is then discussed. Considering a two level system, say a lower, hardware level and a higher, control software level. Transparency is the measure of how much of a lower level capability is available at a higher level. Complete transparency means that if it is feasible in a lower level tier, it should be feasible in an upper level tier. When a design decision restricts the possibilities of a lower level tier when used through an upper level tier, there is a loss of transparency. For instance, if our Data Access Object layer only permits data selection from the database, there is clearly a loss of transparency as the ability to insert and delete data was suppressed.

Complete transparency is not always a good thing. There is a trade-off between transparency and flexibility of a design. The increase of transparency between two levels can lead to great implementation difficulties and inefficiencies. The designer should be aware and ponder. As stated: “Loss of transparency is often one of the goals of a design”.

Concluding on the difficulties with the outside in approach, the authors affirm that usually the design comprises many inter-related objects. Moreover, there is limited experience with man-man symbiosis, so it is often impossible to specify the outside before construction and not want to change it afterwards.

I would say that we still have limited experience with human-human symbiosis, what one could name as managerial issues in software development. Also, there usually is a lack of engineering expertise, where software designers and developers forget about key principles stated decades ago.

Revisiting Parnas: A Technique for Software Module Specification with Examples

During this month, in a series of posts we shall revisit the works from David L. Parnas. The exploration will concentrate itself in particular on the publication concerning software architecture and design, from 1970 to 2000. 

In the paper called “A Technique for Software Module Specification with Examples”, from 1972*, Parnas introduces a way to specify software pieces. His ideas could be considered the early stages of Bertrand Meyer’s, Design By Contract. The technique is based on formal description of initial possible values and its types, parameters and effects. 

The effects session also describes errors states in which an error handling routine will be called, even though the error handling routine itself is not described by the specification. This is very well argued by Parnas and totally coherent for me: errors can be handled differently in many levels and should be a concern for the user of the function.

The main point of the article, is not the notation itself, but the set of principles upon which it was build. Those principles state for (1) the need of a concise specification for the function’s user and for the implementer. (2) It promotes Information Hiding by stating that no information about the structure calling program should be conveyed. The principles are also in favor of (3) a more formal specification that can possibly be machine tested. Finally, (4) it encourages the use of a Domain Language for the specification. 

The set of four principles define succinctly the main characteristic any software specification technique should have. I see the use of formal methods as a weak point, when it comes to certain contexts of development, such as large information systems, where the formal specification could be worthy only in small chunks of the system.  On the other hand, I think the machine testability should gain more focus nowadays, as AOP and unit testing techniques and frameworks are so widespread.

In a subsequent post, the remarkable “On the criteria to be used in decomposing systems into modules” shall be discussed. ‘Till then.

*There is an earlier paper, from 1971, entitled “Information Distribution aspects of design Methodology”, but it wasn’t possible to retrieve it from the available internet academic databases.