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: On the Criteria to be Used in Decomposing Systems into Modules

In the paper called "On the Criteria to be Used in Decomposing Systems into Modules", from 1972*, David L. Parnas discusses modularization as a mechanism for improving flexibility and comprehensibility of a system. David Parnas also emphasizes the shortening of development time because each module can be developed by separate groups. The main point of the paper is the introduction of some criteria that can be used to decompose systems into modules.

A comparison of two different ways to decompose a system is presented. The former decomposition is based on a flowchart, which makes each major part of a process as a module. This kind of decomposition can bring some problems such as:

• Changeability: changes to a specific module require modification of other modules;
• Understandability and Independent Development: modules cannot be understandable or even developed separately.

The second decomposition presented is based on the principles of information hiding, and normally solves the problems listed above. In this case, the modules no longer correspond to steps in the process; each module is characterized by its knowledge of a design decision which it hides from the others. It is also emphasized that the modules’ interfaces must reveal as little as possible about its inner workings.

The design by contract is also commented in the paper, Parnas mentioned that the inputs and outputs of each module must be well defined before implementation starts, what is obvious currently.

In a subsequent post, the remarkable “Uses of the Concept of Transparency in the Design of Hierarchically Structured Systems” shall be discussed.

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.