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.