A traffic flow situation is used to explain how four different methodologies would handle the design of a real-time traffic light control system. Two of the methodologies--Jackson system design (JSD) and MASCOT3--have already been developed and used extensively in the field. These are employed as reference points for two new methodologies, apparently developed or pioneered by the authors--MOON and hierarchical object oriented development (HOOD).

The paper makes extensive use of diagrams to illustrate and explain the conventions used by each of these methodologies. The diagrams are clearly labeled and fairly well explained in the text. The paper is much too short to give anything but a sketchy taste of these new methodologies, however; we have no explanation of the conventions that dictate why a certain icon is used in a diagram or of the functional meaning of each convention. For example, MOON uses pulse generator icons that make it difficult to determine if they represent hardware or logical functions.

The historical origin and development of these new methodologies are also unclear. In some places the authors refer to MOON as an extension of MASCOT3, and in other places they refer to MOON as a separate methodology. JSD and MASCOT3 seem to relate strongly to software design and development, and MOON and HOOD seem more related to CASE and hardware- and routine-based quick solutions. The authors claim that MOON and HOOD are better for large systems because of the lack of ambiguity of parts and interfaces (everything is named) and the physically applied level of the design. The paper does not contain enough information to back up their claim.

Unstated by the authors, but apparently the goal of all these exercises, is to depict the design of a system in such a way that programming the system is almost a direct result. The authors give credit to JSD as a methodology that allows managers and designers to understand more of the basis for a given design, but they criticize it as lacking in more specific and applied design solutions.

The paper’s best feature is a 12-criterion analysis of the value of each methodology in a real-time development situation. The criteria are ease of use; lack of ambiguity; conciseness; concurrency and real-time support; deriving implementation from design; support of top-down development; ability to express requirements and constraints; ability to express different views of the system; consistency; phase specificity in the software life cycle; and modularity. This evaluation shows that only JSD can show requirements, but JSD requires much more work to implement than the other three. Many other tradeoffs can be determined by reading this analysis.

This paper provides a good, quick working summary of how four design methodologies would analyze, illustrate, and describe an industrial process to create a real-time system. It can serve as a starting point to analyze which methodology to use in a given situation. In no way should it be read to learn how to use any of these methodologies.