We now introduce a second view of concurrent processes whereby each process is a term over a certain signature of operator symbols. By interpreting these symbols on nets, we will solve the problem of compositionality. As interpretations we take a selection of the operators suggested in Lauer's COSY, Milner's CCS and Hoare's CSP.

Lauer's COSY (Concurrent Systems) is one of the first approaches to compositionality of processes on a schematic, uninterpreted level [LTS79]. It originates from path expressions [CH74] and can thus be seen as an extension of regular expressions to include parallelism. We use here COSY's operator for parallel composition because, as we shall see later in Chapter 4, it enjoys pleasant logical properties.

A significant step beyond COSY is Milner's CCS (Calculus of Communicating Systems) with its conceptual roots in algebra and the λ-calculus [Mil80, Mil83]. From CCS we take the idea that processes are recursive terms over certain operator symbols, i.e. they form the smallest set that is generated by the operator symbols and closed under parameterless recursion. In COSY only iteration is present as might be clear from its background in regular expressions. By using recursion we ensure that process terms are Turing powerful even on the schematic level without the help of interpreted values or variables. We also take CCS's choice operator because it allows a very clear treatment on the level of nets, and its notion of action morphism by which actions can be renamed.

INTRODUCTION

This chapter initiates and serves as a preamble to a systematic discussion of several design paradigms. The concept of a paradigm is central, not only to this (the second) part of the book but also to the discussion of the relationship between design and science in Part III. It is, thus, of some importance to specify as exactly as possible what I mean when I use the terms ‘paradigm’ and ‘design paradigm’ in this work. The necessity for such clarification becomes specially urgent given the fact that in certain intellectual circles the word ‘paradigm’ has assumed the unfortunate status of a cult-word.

The present chapter also serves a second, less obvious, function. And that is, to demarcate the fundamentally descriptive spirit of the preceding chapters from the pronounced prescriptive character of the chapters to follow.

The discipline of design is necessarily Janus-faced. On the one hand the act of design is a cognitive and an intellectual process. Hence any theory of design must, at least in part, view design processes as natural processes that harness the capabilities inherent in, and are in turn harnessed to the limitations imposed by, human nature and intellect. A theory of design must at least in part be a cognitive theory and, therefore, descriptive in nature. Much of Part I was precisely that; in particular, the notion that design is an evolutionary phenomenon is a descriptive, empirical proposition – a consequence of the inherent bounds of our ability to make rational decisions.

INTRODUCTION

‘Classical’ design automation, of course, relied on the use of algorithms. That is, the earliest applications of computing techniques to design problem solving were all based on algorithms for producing designs. We may, therefore, refer to this approach as the algorithmic design paradigm.

A necessary (though not sufficient) condition for the algorithmic paradigm to be applicable is that the design problem be well-structured. Such problems are characterized by the fact that the requirements are all empirical in nature in the sense that one knows exactly how to determine whether or not a given design meets such requirements (see chapter 3, section 3.3). And although most interesting design problems are ill-structured many of their subproblems or components may turn out to be well-structured – in which case, the algorithmic paradigm may apply. Strictly speaking, then, one should think of the algorithmic paradigm as, so to speak, a tool that can be invoked by other more general paradigms such as TPD or even ASE to solve well-structured components of a given design problem.

COMPILING AS AN ALGORITHMIC STYLE

In the domain of computing systems design the algorithmic paradigm is perhaps most well represented by an important family of methods which may be collectively termed compiling. This is a technique or style which is ‘classical’ in that it was invented at a relatively early stage in the history of computer science; and it has been enormously successful as an instance of the algorithmic paradigm in the automation of software, firmware and hardware design.

THE SATISFICING NATURE OF DESIGN DECISIONS

In chapter 3 (section 3.4) I introduced the concept of bounded rationality. As noted there, bounded rationality is a model of rationality proposed by Simon (1976, 1982) that recognizes the severe limits on the cognitive and information processing capabilities of the decision making agent. Such limitations may arise in a variety of ways: the various factors or parameters affecting a decision may be so complex or they may interact in such complicated ways the agent may be unable to decide the best course of action; or the agent may simply not know all the alternative courses of action; or even when all the factors or alternatives are known fully, the cost of computing the best possible choice may be far too prohibitive.

Bounded rationality explains why design problems are so very often formulated in an incomplete manner (see section 3.4, chapter 3). But it has an even more profound consequence for the design process itself, and for the nature of design solutions.

Example 5.1

To understand this, consider a computer architect who has been given a particular set of initial requirements and is required to design a micro-architecture that meets these requirements. A computer's micro-architecture, it will be recalled (see foot-note 6, chapter 3) refers to the internal architecture of the computer as seen by the microprogrammer (see also Dasgupta 1989a, chapter 1).

We shall further assume that the initial requirements, though sparse, are quite precise and complete.

INTRODUCTION

Let us recapitulate some of the very basic features of the design process as articulated in Part I of this book.

1. (a) The requirements constituting the specification of a design problem may (initially) be neither precise nor complete; hence the elaboration of requirements becomes an integral part of the design process. Requirements may, furthermore, be of an empirical or a conceptual nature.

2. (b) A design is an abstract description of the target artifact that serves as a blueprint for implementation, and as a medium for criticism, experimentation and analysis.

3. (c) The designer is constantly faced with the problem of bounded rationality – the fact that designers and their clients are limited in their capacities to make fully rational decisions, or are limited in their ability to grasp the full implications of such decisions.

4. (d) Design decisions are more often than not satisficing procedures.

As a consequence of all of the above design can be naturally viewed as an evolutionary process possessing the following characteristics: at any stage of its development the design is viewed as a tentative or conjectural solution to the problem posed. The designer's task in each evolutionary cycle is to elaborate either the design or the requirements so as to establish or converge towards a fit between the two. Thus, an integral part of each evolutionary cycle is the critical testing of the ‘current’ design against the ‘current’ requirements (see chapter 5, especially section 5.3).

The natural point to begin any discussion of design is its definition – that is, to state succinctly in a single sentence what it is that one does when one designs and what the end product is. Such an enterprise has been attempted in a variety of contexts including architecture, engineering, computer science, and the hybrid discipline of computer-aided design. As might be expected these definitions range from the very prosaic to the very abstract and each reflects quite clearly the specific perspective, tradition, and bias of its author. Invariably, such attempts to capture an entire human (or more recently, human–computer) enterprise within the bounds of a single sentence are unsatisfactory at the very least and fail abysmally at the worst.

One reason why definitions fail is the ubiquity of design as a human activity. As Simon (1981) has pointed out, anyone who devises courses of action to change an existing state of affairs to a preferred one is involved in the act of design. We have all been involved in devising such courses of action; hence from the very experience of living – or at least from the very experience of purposively controlling our lives – we have an intuitive idea of what design is. Thus, any single all embracing definition leaves us dissatisfied as much by what it excludes as by what it contains. For every definition one can point to instances of what is intuitively or experientially felt to be design but which have been excluded from the definition.

Most design theorists including Simon (1981) and Jones (1980) among the more influential agree that, in an ultimate sense, the goal of design is to initiate change in some aspect of the world. We perceive an imperfection in the state of affairs in some specific domain and we conceive or design an artifact which when implemented will, we believe, correct or improve this state of affairs.

There are a number of consequences of this seemingly obvious observation.

DEMARCATING ENGINEERING FROM SCIENCE

I shall use the term engineering here (and throughout the book) as a synonym for the more cumbersome ‘sciences of the artificial’. That is, the term encompasses the activities involved in the production of all useful artifacts – both material, such as buildings, computers and machine tools, and symbolic or abstract such as organizations and computer programs. Clearly, except in the simplest of situations, engineering entails design.

The notion of design as an agent of change appears to establish a firm criterion for demarcating engineering from the natural sciences (such as physics, chemistry, biology or geology). According to conventional wisdom, the latter disciplines are concerned with understanding the natural universe; the engineering disciplines are concerned with its purposeful, artificial alteration or extension.

The tendency to distinguish between the natural sciences (or simply, ‘science’) and engineering has, over the years, assumed almost mythical proportions.

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.