DESIGNS AS FORMAL ENTITIES

A formal system consists of a set of axioms – that is, formulas or assertions that are assumed or known to be true – and a set of inference or proof rules that allows one to make deductions. Given a formal system a formal proof of an assertion or formula F consists of a finite sequence of formulas

F1, F2, …, Fn = F

such that each Fi is deduced from Fi−1 (2 ≤ i ≤ n) using the set of axioms and the rules of inference. A formula F for which there exists a formal proof is called a theorem.

Let us suppose that the requirements R of a design problem and the design D itself are both representable within the common framework of a formal system. In that case the problem of demonstrating that D satisfies R – that there is a fit between D and R – can be addressed by the designer formally proving the assertion ‘D satisfies R’. The latter assertion becomes, in effect, a theorem.

The notion of treating designs as formal entities so that one may prove (or verify) their correctness with respect to a requirements set is at the heart of the formal design (FD) paradigm. This paradigm originated some two decades ago in seminal papers by Floyd (1967) and Hoare (1969) which together laid the foundations for proving the correctness of programs.

INTRODUCTION

Recall (from chapter 5) that according to the evolutionary model a design at any stage of its development is best viewed as a tentative or conjectural solution; in other words, as a hypothesis which must be tested in the course of that evolutionary cycle and its successors.

It may also be recalled that in the TPD paradigm (chapter 9) the plausibility state of a constraint is determined by the evidence invoked in support of or against the plausibility of that constraint. Accordingly, it was noted (in section 9.4) that there is an analogy between plausibility states in TPD and the states of hypotheses or conjectures in science (see fig. 9.3).

Finally, in discussing the nature of program correctness proofs in chapter 8 (section 8.9), we noted Fetzer's (1988) suggestion that computer programs be viewed not as mathematical theorems (as is assumed in the FD paradigm) but as empirical, refutable, conjectures.

These various discussions appearing in diverse parts of this book collectively seem to suggest that there is some sort of a connection between the method of design and the method of science.

The subject of this penultimate chapter is precisely this issue. More exactly, I wish to examine whether, or under what conditions, the design process may legitimately be viewed as a process of scientific theory construction. I will anticipate later arguments by stating in advance the following thesis.

As stated at the beginning of chapter 3 the designer's brief is to develop a form such that an artifact constructed according to this form would satisfy the requirements. The form is the design. The ultimate output of a design process must, then, be an explicit description or representation of the form in some abstract or symbolic language. I shall use the term design description to refer to such symbolic representations of forms. When ‘design’ is used as a noun it becomes essentially a synonym for ‘form’.

The concept of form is elusive, abstract, and complex. It may refer to the visible shape of an entity – as when naturalists and biologists talk of biological forms. It may refer to the essential or ultimate nature of a thing – as when philosophers talk of Platonic forms. It may denote the way in which certain parts are arranged and related to one another in an entity – as when one talks of the form of an essay, an argument, a solution, or a musical composition. Finally, architects talk of forms or ‘built’ forms (March 1976, Alexander 1964) in which term they embrace in a complex, diffuse fashion, the totality of shape, structure and relationships of parts as manifested in buildings.

These examples clearly reveal that form as a general concept is multifaceted. Thus, when we undertake to design an artifact the end product of our activity – the form of the artifact itself and how it is to be described – is critically dependent on how or for what purpose the design is to be used.

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.