This paper presents MSG.84, a language for the functional specification and module design phases of the software life cycle. The paper is divided into six sections.

Section 1 attempts to give a definition for functional specifications, followed by the requirements for a functional specification language. MSG.84 differs from previous specification languages such as PSL/PSA, SREM, and SADT in that the function specifications are defined in a strongly typed version of the actor model of computation. The actor model presented provides a clear and natural framework for specifying the external behavior of a process without describing its internal mechanisms.

Section 2 of the paper discusses models of software systems and refines the actor model terminology. The abstractions necessary to support functional specifications in MSG.84 are transforms, state machines, and data types. A transform is an actor that generates its output based on only its current input. That is, the transformation actor has no memory of its previous inputs or internal state. A state machine, on the other hand, is an actor whose performance is based on previous input data. A data type or data abstraction consists of a set of data objects and a set of operations for creating and manipulating those objects. ADA is mentioned as a language which uses data abstractions, but no example of its use is presented. This reviewer feels that an example of how MSG.84 supports ADA code might be illustrative, especially since ADA uses both the data abstraction and the strong typing features that are present in MSG.84.

Section 3 is devoted to a detailed description of the MSG.84 language, and it includes several supportive examples. Function specifications in MSG.84 are described by means of data abstractions, in order to pin down the information content of the data without prematurely specifying the format of the data structures. Data invariant assertions may be defined in the language. Data states, which represent the long-term memory of an actor, may be specified; control states, which represent the current point in a partially completed transaction involving more than one event, may be specified as well. Control states are similar to R-nets in SREM except that irrelevant details are suppressed.

According to the authors:

When using MSG.84 to record a functional specification, each of the software subsystems to be built and each of the external systems with which they interact are modeled as actors.

This is an important concept, as it documents assumptions about the external interfaces.

In addition, definitions can be imported from other actors, but represent only data formats or actor dependencies, not actual information transfer as in MODULA-2. This import feature is more like ADA packages with data types defined in the specification part. Subsequent ADA program units specify their dependence on these packages by WITHing them.

Section 4 discusses the generation of an extended data flow diagram which is derived from the MSG.84 specifications. Very large subsystems are represented by a hierarchy of diagrams.

Section 5 discusses the supportive computer aids for MSG.84. Automated syntax and type checking of MSG.84 source statements, cross references, pretty printing, and automatic diagram generation are mentioned. In addition, system behavior simulation and automatic derivation of test cases are cited as possibilities. Unfortunately, although these tools would be beneficial in support of MSG.84, they do not appear to be currently implemented according to the authors of this paper.

Section 6 discusses the conclusions of the authors. The authors mention that performance considerations, such as realtime constraints, have not yet been incorporated in MSG.84. In addition, the authors state that the actor model “makes no constraints on the amount of delay in a message transmission” between actors. This reviewer feels that the inability to express realtime constraints severely limits the usefulness of MSG.84 in large system design. In addition, delay times are an important factor in the analysis and design of large, realtime systems. Without this capability, MSG.84 may be of limited use in designing these systems.

In summary, this reviewer believes that the authors have conceived of a very ambitious system, but have implemented very little of it. Furthermore, the system appears to have been used only by students of a system engineering class. It has not been used on any commercial or governmental program. The usefulness of MSG.84 will depend on whether the authors (1) implement all the tools mentioned in Section 5, including the missing realtime capabilities, and (2) test it on a large commercial or government project.