THE AUTOMATION OF DESIGN

Thus far, the discussion of design paradigms has been basically devoted to the significance of design theory for computing systems design. Furthermore, the implicit focus has been on design as an intellectual, cogitative, human activity. In this and the next chapter I shall examine the obverse side of the coin – that is, the implications of computer science for design theory.

This is an issue that becomes rather relevant if we are interested in the automation of design. Specifically, we may ask the following types of questions: does the goal of automation cause us to expand our understanding of the design process (with respect to the architectonics discussed in Part I)? Given the desire to automate design, what are the characteristics of the relevant design paradigms?

The ‘classical’ response to the need to automate any task is to devise algorithms to perform the task. From a ‘classical’ perspective then, we are led to the algorithmic design paradigm. According to this paradigm, given a design problem one constructs algorithms that produce the design form. An algorithmic approach to design automation has the same kind of compelling appeal exhibited by the formal design paradigm: algorithms are formal, objective procedures with well defined, understandable behavioral characteristics. The problem with this paradigm is essentially twofold: firstly, the design problem must itself be sufficiently well-structured (see chapter 3, section 3.3) as to allow the algorithm to contain well defined conditions for its own termination; that is, in order to generate a solution to the design problem, the algorithm must ‘know’ what constitutes a solution and how to recognize the attainment of a solution.

In this book I intend to examine the logic and methodology of design from the perspective of computer science. Computers provide the context in two ways. Firstly, I shall be discussing the structure of design processes whereby computer systems are, or can be, designed. Secondly, there is the question of the role that computers can play in the design of artifacts in general – including other computer systems.

The aim of any systematic enquiry into a phenomenon is to uncover some intelligible structure or pattern underlying the phenomenon. It is precisely such patterns that we call theories. A theory that claims to explain must exhibit two vital properties. It must be simpler – in some well defined sense – than the phenomenon it purports to explain; and it must be consistent with whatever else we know or believe to be true about the universe in which the phenomenon is observed.

The phenomenon of interest in this book is such that it cannot be adequately described by a single sentence. That itself is an indicator of its inherent complexity – and therefore of its intrinsic interest.

INTRODUCTION

Chapters 4 and 5 describe a unifying framework for the structured systems development models. Such a framework is useful for several reasons:

1. (a) Many projects to provide theoretical support for systems development do not use the popular structured analysis and design models. As pointed out in Davis (1982) and Martin (1983, 1984), practitioners are rather hesitant to use new tools that involve an unfamiliar formal language. On the other hand, a unifying theoretical framework that adds formal components to the notations of structured specifications permits users to continue using existing popular practices.

2. (b) Different structured models are suitable for different situations, depending on the characteristics of user requirements, the emphasis and the stage of development (Colter 1982, Lauber 1982, Sanden 1989, Shigo et al. 1980). In other words, we may need more than one of these tools during the development process of a single system. If we provide systems developers with a means of mapping from one model to another, the efficiency of systems development may be greatly improved.

3. (c) A number of development aids have been designed for individual structured models (Delisle et al. 1982, DeMarco and Soceneantu 1984, Kampen 1982, Tse 1985, Tse and Pong 1989). However, these aids are useful only for individual models, and are not applicable to others. If a mapping can be found to transform one model to another, a development aid for one structured methodology may be applied to another.

4. […]

Structured analysis and design methodologies have been recognized as the most popular tools in information systems development (Colter 1982). They are widely accepted by practising systems developers because of the top down nature of the methodologies and the graphical nature of the tools. A complex systems specification can be decomposed into a modular and hierarchical structure which is easily comprehensible. They enable practitioners to visualize the target systems and to communicate with users much more easily than conventional methods.

As a matter of fact, the structured methodologies have been designed by quite a number of distinct authors, each employing a number of models which vary in their in graphical outlook. These include data flow diagrams (DeMarco 1978, Gane and Sarson 1979, McMenamin and Palmer 1984, Weinberg 1980), Jackson structure diagrams, Jackson structure texts (Jackson 1975), system specification diagrams, system implementation diagrams (Cameron 1986, Jackson 1983), Warnier/Orr diagrams (Orr 1977) and structure charts (Page-Jones 1988, Yourdon and Constantine 1979).

INTRODUCTION

An initial algebra framework has been proposed in the last chapter to integrate the structured systems development models. Given a specification in one structured model, the framework provides a formal means of mapping it to an equivalent specification in terms of another model. It does not, however, provide a means of developing the specification in the first place. Not does it consider refinement.

We find that the proposed term algebra as well as the DeMarco, Yourdon and Jackson notations fit nicely into a functorial framework. We can integrate the models by providing functorial bridges from one type of specification to another. An overview of the functorial relationships is shown in Figure 5.1. The framework also provides a theoretical basis for manipulating incomplete or unstructured specifications through refinement morphisms.

The main advantages of the functorial framework can be summarized as follows:

1. (a) A systems developer may conceive the target system in terms of structured tasks, which are the equivalents of standard structuring mechanisms such as sequence, selection and iteration used in the structured methodologies. The DeMarco, Yourdon or Jackson notations are simply seen as variations on the same theme.

2. (b) Although the initial algebra framework provides a formal means of mapping a structured specification from one form to another, it does not offer much help at the initial stage when we are trying to develop the specification. Using the functorial framework, we can refine a draft specification of structured tasks using morphisms, which preserves structuredness. Properties of continuous functions and structured functions can be used to verify the correctness of such manipulation. These concepts help a systems developer to visualize the internal structure of a system, assemble or refine subsystems, and verify the consistency and completeness of a design.

3. […]

INTRODUCTION

In this chapter, we shall give a further illustration of the theoretical usefulness of our framework by applying it in the identification of unstructuredness. Since DeMarco data flow diagrams are mainly used as communication tools with users during the analysis stage of systems development, they are problem-oriented and probably unstructured. Some mechanism must be available enabling us to detect the unstructured elements so that we can construct structured tasks and define refinement morphisms accordingly. We shall extend our concepts in tasks and show that only one single criterion is necessary and sufficient for identifying unstructuredness. Looking at it in another way, a single criterion is necessary and sufficient for proving a task to be structured.

Quite a number of papers have already addressed a similar problem of detecting unstructuredness in program schemes and transforming the schemes into structured equivalents. These papers can roughly be classified as follows:

1. (a) Many of the papers are based on heuristic arguments (Colter 1985, McCabe 1976, Mills 1972, Oulsman 1982, Williams 1977, Williams and Ossher 1978, Williams and Chen 1985). Each paper gives a new proposal supposedly better than earlier ones (Prather and Giulieri 1981). According to the arguments in McCabe (1976), Oulsman (1982), Williams (1977) and Williams and Ossher (1978), unstructuredness may be due to any of four elements — branching out of a loop, branching into a loop, branching out of a selection and branching into a selection. The identification of these elements, however, has remained a difficult task. Since unstructured elements cannot exist in isolation, the authors recommend that we should identify unstructured compounds, or combinations of unstructured elements. Unfortunately, the number of combinations is endless, so that we can never exhaust all the possible cases (Williams 1983).

2. […]

Structured analysis and design methodologies have been recognized as a popular and powerful tool in information systems development. A complex system can be specified in a top-down and graphical fashion, enabling practitioners to visualize the target systems and communicate with users much more easily than by means of conventional methods. As a matter of fact, the structured methodologies have been designed by quite a number of distinct authors, each employing a number of models which vary in their graphical outlook. Different models are found to be suitable for different stages of a typical systems life cycle. A specification must be converted from one form to another during the development process. Unfortunately, however, the models are only derived from the experience of the authors. Little attempt has been made in proposing a formal framework behind them or establishing a theoretical link between one model and another.

A unifying framework is proposed in this book. We define an initial algebra of structured systems, which can be mapped by unique homomorphisms to a DeMarco algebra of data flow diagrams, a Yourdon algebra of structure charts and a Jackson algebra of structure texts. We also find that the proposed initial algebra as well as the structured models fit nicely into a functorial framework. DeMarco data flow diagrams can be mapped by a free functor to terms in the initial algebra, which can then be mapped to other notations such as Yourdon structure charts by means of forgetful functors.

INTRODUCTION

In this chapter, we shall give an illustration of the practical usefulness of our framework. We shall discuss a prototype system which has been developed to implement the structured tasks. It has been implemented on a Macintosh using Turbo Pascal. It enables the user to draw a hierarchy of DeMarco-like task diagrams and stores them as structured tasks, which are stored physically in the form of pointers and linked lists. It helps the user to review the task diagrams to an appropriate level of detail, and zoom in/zoom out to lower/higher levels through refinements and abstractions as required. Given an incomplete task specification, the system prompts the user to define further details of his design considerations. For example, if the user wants to build a hierarchical structure into a flat task diagram, he will be prompted to supply the necessary details such as the names of intermediate levels. Given a hierarchy of task diagrams, the system then transforms them automatically into a term algebra, a Yourdon structure chart and also Jackson structure text. An example of an application of the system will be given in Section 7.2. An overview of the system with examples of its algorithms will be given in Section 7.3.

INTRODUCTION

In this chapter we shall compare our approach with five related systems development environments. These environments include PSL/PSA, ADS/SODA, SADT/EDDA, SAMM/SIGS and RSL/SREM. They have been chosen for comparison because of the following reasons:

1. (a) They were pioneer systems development environments meant to cover the entire systems life cycle, and have stood the test of time.

2. (b) They are better known and documented, so that interested readers can obtain further information easily.

3. (c) They are still under active development and recent enhancements have been reported.

4. (d) The languages examined cover a wide spectrum of characteristics. Some were originally developed as manual tools, but others were meant for mechanical support from the very beginning. For some languages, a system can be specified in a multi-level fashion, but not for others. Some languages use graphics as the specification medium while others are purely textual. Some of the development environments generate graphical feedback to users whereas others generate textual documentation.

5. (e) The final reason is a pragmatic one. We have included projects which are familiar to the present author. Part of this chapter is derived from the research results of a joint project with Mr Daniel Pong (Tse and Pong 1982, Tse and Pong (to appear)).

PSL/PSA AND META/GA

PSL was the first major language for defining a system formally and analysing it automatically (Teichroew 1971, Teichroew et al. 1980, 1982, PSL/PSA Introduction 1987).

Structured systems development methodologies have been recognized as the most popular tools in information systems development. They are widely accepted by practising systems developers because of the top down nature of the methodologies and the graphical nature of the tools. Unfortunately, however, the models are only derived from the experience of the authors. In spite of the popularity of these models, relative little work has been done in providing a theoretical framework to them. In this project, we have tried to solve the problem by defining a unifying theoretical framework behind the popular structured models.

We have defined an initial algebra of structured systems, which can be mapped by unique homomorphisms to a DeMarco algebra of data flow diagrams, a Yourdon algebra of structure charts and a Jackson algebra of structure texts (with equations). As a result, specifications can be transformed from one form to another. Algebraic interpreters may be adapted to validate the specifications.

We have also found that the proposed term algebra as well as the DeMarco, Yourdon and Jackson notations fit nicely into a functorial framework. The framework provides a theoretical basis for manipulating incomplete or unstructured specifications through the concepts of structured tasks and refinement morphisms. Moreover, DeMarco data flow diagrams can be mapped to term algebras through free functors. Conversely, specifications in term algebras can be mapped to other notations such as Yourdon structure charts by means of functors.

This part describes three different approaches to the use of formal methods in the verification and design of systems and circuits.

Chapter 2 describes the stages involved in the verification of a counter using a mechanized theorem prover.

The next chapter describes a mathematical model of synchronous computation within which formal transformations which are useful in the design process can be defined.

Chapter 4 describes verification in a different framework – that of the algebra of communicating processes.

ABSTRACT

In designing VLSI-circuits it is very useful, if not necessary, to construct the specific circuit by placing simple components in regular configurations. Systolic systems are circuits built up from arrays of cells and therefore very suitable for formal analysis and induction methods. In the case of a palindrome recognizer a correctness proof is given using bisimulation semantics with asynchronous cooperation. The proof is carried out in the formal setting of the Algebra of Communicating Processes (see Bergstra & Klop [1986]), which provides us with an algebraical theory and a convenient proof system. An extensive introduction to this theory is included in this paper. The palindrome recognizer has also been studied by Hennessy [1986] in a setting of failure semantics with synchronous cooperation.

INTRODUCTION

In the current research on (hardware) verification one of the main goals is to find strong proof systems and tools to verify the designs of algorithms and architectures. For instance, in the development of integrated circuits the important stage of testing a prototype (to save the high costs of producing defective processors) can be dealt with much more efficiently, when a strong verification tool is available. Therefore, developing a verification theory has very high priority and is subject of study at many universities and scientific institutions.

However, working on detailed verification theories is not the only approach to this problem. Once having a basic theory, the development of case studies is of utmost importance to provide us with new ideas.