Centrum voor Wiskunde en lnformatica
Centre for Mathematics and Computer Science
H. Takeda, T. Tomiyama, H. Yoshikawa, P.J. Veerkamp

Mode ling design· processes

Computer Science/Department of Interactive Systems

Report CS-R9059 October

The Centre for Mathematics and Computer Science is a research institute of
the Stichting Mathematisch Centrum , which was founded on February 11,
1946, as a nonprofit institution aiming at the promotion of mathematics, computer science, and their applications. It is sponsored by the Dutch Government through the Netherlands Organization for the Advancement of Research(N.W.O .).

Copyright O Stichting Mathematisch Centrum, Amsterdam

Modeling Design Processes
Hideaki Takeda, Tetsuo Tomiyama, and Hiroyuki Yoshikawa
Department of Precision Machinery Engineering
Faculty of Engineering, The University of Tokyo
Hongo 7-3-1, Bunkyo-.ku, Tokyo 113, Japan

Paul Veerkamp
Department of Interactive Systems
Centre for Mathematics and Computer Science
P.O.Box 4079, 1009 AB Amsterdam, The Netherlands

This article aims at building a computable design process model which is a prerequisite
tor realizing intelligent CAD systems. First, we discuss design processes seen from atheoretical point of view, i.e. we introduce General Design Theory from which a
descriptive model of design processes is derived. In this model, the concept ofmetamodels plays a crucial role to describe the evolutionary nature of design. Second,
we examine design processes from a cognitive viewpoint. We show a cognitive design
process model obtained by observing design processes using a protocol analysis method.
Then, we discuss a computable model that can explain most parts of the cognitive modeland that also can interpret the descriptive model. In the computable model, a design
process is regarded as an iterative logical process realized by abduction, deduction, andcircumscription. We implemented a design simulator that can trace design processes inwhich design specifications and design solutions are progressively revised as the design
proceeds.
CR Categories and Subject Descriptors: D.3, F.4.1, J .6.
Key Words & Phrases: intelligent CAD, design theory, design process model , meta-model,
abduction, deduction, circumscription.

1. Introduction
One of the major problems in developing so-called intelligent CAD (Computer Aided Design)
systems [ 19] is the representation of design knowledge which is twofold; the representation ofdesign objects and design processes. We believe that intelligent CAD systems will be fully
realized only when these two types of representations are integrated together. Progress is madein the former as can be observed for instance in geometric modeling, while there is almost no
significant result in the latter. This implies that we need a design theory to formalize design
processes. Some design theories have been already proposed, but they vary on their aims,
domains, and so on.
According to Finger and Dixon [8], design process models can be categorized into a
descriptive model which explains how design is done, a cognitive model which explains thedesigner's behavior, a prescriptive model which shows how design must be done, and acomputable model which expresses a method by which a computer may accomplish a task. A
design theory for intelligent CAD is not useful merely to be descriptive or cognitive, but also to
be computable. We need a general model of design to clarify and define what design is from a
Report CS-R9059
Centre fo r Mathematics and Computer Science
P .O. Box 4079, 1009 AB Amsterdam. The Netherlands

2

Hideaki Takeda, et al.

theoretical point of view, which is a role of the descriptive model. But descriptive models are
not necessarily helpful directly to derive either the architecture of intelligent CAD or theknowledge representation for intelligent CAD. For this purpose, we need a computable design
process model that should coincide, at least to some extent, with a cognitive model which
explains actual design activities.
In this article we discuss our attempt to establish a logical computable framework to
represent design processes. This framework is not proposed merely for computability. It has
foundation on discussions about our descriptive and cognitive models.
We start this article with the descriptive model. We present our descriptive theory called
G<'neral Design Theory. It is a mathematical formulation of design processes and explains how
design is conceptually preformed in terms of knowledge manipulation. Next, we show a more
concrete descriptive model called c1•0/utionary design process model. It is based on General
Design Theory and shows how the design object is manipulated in the design process in an
intelligent CAD environment. We then analyze design processes based on experimental results.
We conducted design experiments to extract the features of design processes which a cognitive
design model is derived from.
These discussions lead to a logical formalization of design processes in terms of a design
process model which is not only coherent with the descriptive and cognitive models but also
expected to be computable. In this model, a design process is regarded as a logical process inwhich both the theory (i.e. axioms) and the goal are revised gradually as the design proceeds,
using deduction, abduction, and circumscription. Abduction is used to expand the designer's
thought, deduction is used when the designer wants to get all obtainable facts from currently
available design knowledge, and design object descriptions, and circumscription is applied tosolve an inconsistency found during deductive reasoning. We illustrate a desi[?n simulator todemonstrate that this model is computable and also appropriate to represent design processes.
An example is shown, in which, given design knowledge and specifications, the design simulator
logically simulates a design process based on protocol data obtained by a real design experiment.
In the last chapter, we discuss the relationship between the descriptive, cognitive, andcomputable design process models.

2. General Design Theory
We have developed General Design Theory (GOT) (20, 30] and its major achievements are amathematical formu lation of the design process and a justification of knowledge representation
techniques in a certain situation. GOT is a descriptive model that tries to explain how design isconceptually performed in terms of knowledge manipulation. In GOT, a design process isregarded as a mapping from the function space onto the attribute space both of which are definedon the entity concept set. Based on axiomatic set theory, we can mathematically deriveinteresting theorems which can well explain a design process. (Interested readers may refer to[20, 30] for more precise discussions. In this paper we present the theorems without proof tolimit the paper's size.)Modeling Design Processes

3

2.1. Design in the ideal knowledge
GDT deals with concepts that exist only in our mental recogrnt1on. In this sense, GDT is an
abstract theory about knowledge. We make a distinction between an enrity and an entity
concepr. The former is a concrete existing thing, while the latter is its abstract mental impression
conceived by a human being. An entity concept might be associated with its properties, such ascolor, size, function, place, etc. These properties are called abstract concepts and include
attributes.
Axiom 1 (Axiom of recognition)
Any enrity can be recognized or described hy affrihutes and/or other ahsJracr concepts.
Axiom 2 (Axiom of correspondence)
The entity set S' and rhe set of entity concepts (ideal) S ha\·e one-to-one correspondence.
Axiom 3 (Axiom of operation)
The set of abstract concepts is a topology of the set of entity concepts.
Axiom 2 guarantees the existence of a superman who knows everything. In other words, it
defines an ideal, ultimate state at which our knowledge should aim. Axiom 3 signifies that it is .
possible to operate abstract concepts logically, as if they were just ordinary mathematical sets.
Accordingly, we get set operations, such as intersection, union, negation, etc.
Then, we can introduce ideal knowledge which knows all of the elements of the entity set
and that can describe each element by abstract concepts without ambiguity. Theorem 1
describes mathematically this situation.

Theorem 1
The ideal knowledge is a Hausdorff space.
In GDT, a design specification is given as an abstract concept that the design solution must
belong to. Thus, the specifications can be given by describing an entity with only abstract
concepts (e.g. functionally). The function space is the entity concept set with a topology offunctions, while the attribute space is the one with a topology of attributes. Therefore, a design
specification is a point in the function space, while a design solution is a point in the attributespace. The most significant result of having the ideal knowledge which can be further provenfrom those three axioms is that design as a mapping from the function space to the attributespace successfully terminates when the specifications are described.

Theorem 2
In the ideal knowledge, the design solution is obtained immediately after the specifications
are described.
Since we perfectly know everything in the ideal knowledge, when we complete describing thespecifications these converge into a point in the function space. Because the function space andthe attribute space are built on the same entity concept set, this point (i.e. an entity concept) can
also be considered in the attribute space. The ideal knowledge is perfect also to describe anentity concept in the attribute space. Thus, the design solution will be fully described byattributes. This means that design in the ideal knowledge is a mapping process from the function
space to the attribute space (see Fig. I).

4

Hideaki Take da, et al.

Design as
MappingFunction Space

Attribute Space

Fig. l. Design process in the idea l knowledge

2.2. Design in the real knowledge
The situation in the ideal knowledge is not the case in the real design and we need to take thefollowing characteristics into consideration:( l) Design is not a simple mapping process but rather a stepwise refinement process where thedesigner seeks the solution satisfying constraints.
(2)

The concept of function is difficult to formalize objectively, because it includes sense ofvalue which can be d ifferent from person to person. Instead, we use behavior to deal withfunction.

(3) The ideal knowledge does not take physical constraints into consideration and it may
produce design solutions such as perpetual machines.
These restrictions are considered in the real knowledge where design is regarded as a processthat the designer builds the goal and tries to satisfy the specifications without violating physicalconstraints. In order to formalize the real knowledge, we first define a physical law as a
description about the relationship between physical quantit ies of entities and the field. The
concept of physical laws is one of the abstract concepts formed when one looks at a physicalphenomenon as manifestation of physical laws. Physical laws constrain entities in the realworld; in other words any feas ible entity must be explicable by physical rules. This fact can beproven as a theorem.

Theorem 3
The set of physical law concepts is a base of the attribute concept topology of the set of(feasible) entity concepts.
This theorem states that attributes can be measured by using physical laws. An interesting fact
about the real knowledge is that we can prove finiteness or boundedness of our knowledge byhaving the following hypothesis.

Hypothesis
There exist finite subco1•erings for any coverings of the set of feasible entity concepts madeofsets chosen from the ser of physical law concepts.
Basically, this hypoLhesis says that a feasible entity is explicable not by an infinite number but afinite number (as small as possible) of physical laws. From this hypothesis, we can prove aninteresting theorem which explains that an attribute has a value, if it is possible at all to measureModeling Design Processes5

the distance. Mathematically speaking, we can also prove the following theorems.
Theorem 4
The real knowledge is a compact Hausdorjf space.
Theorem 5
In the real knowledge, if i-re can produce a directed suhsequence ji"om the given design
spec ifica1ions, this subsequence converges to a single point.

Theorem 5 indicates that in the real knowledge a design process can be regarded ~s aconvergence process, if we can pick up some (but not necessarily all) spec ifkations that seem toyield meaningful solutions.
2.3. Evolutionary design process model

The next step is to formalize design processes in the real knowledge. For this purpose, theconcept of metamodels is fonnally introduced, where a metamodel is a finite set of attributes andthe metamodel set is the set of all metamodels. Such a metamodel can be evolved; by to <.Toh·e,
we mean to increase the number of attribute concepts.
Theorem 6
If we evolve a metamodel, we get an entity concept as the limit of evolution.

Theorem 6 is a corollary of Theorem 5 and it does not guarantee that we obtain a design solution
as the result of this evolution. However, if we restrict ourselves to consider function only interms of behavior, the following theorem can be proven.
Theorem 7
If we choose concepts that can be explained by physical laV\>concepts as the metamodel, we
can describe the desi{?n specifications by the topology of metamodel, and there exists thedesign solution which is an element of this metamodel.

Theorem 7 guarantees that we are able to design as far as specifications are given in terms of(physical) behaviors and solutions are described in terms of attributes that can be measured byphysical laws. Furthermore, solutions contain only those which can be realized physically; inother words we are not allowed to consider objects that contradict to physical laws. Fig. 2
depicts a design process in the real knowledge in which we design, in fact, physical behaviors ofthe design object.
At the same time, Theorem 6 indicates that a design process is a stepwise, transformation
process and solutions are obtained in a gradual refinement manner, because the metamodel canbe evolved only by increasing the number of attributes. In the ideal knowledge, design is· adirect mapping process from the function space to the attribute space, while ih the realknowledge, design is a stepwise, evolutionary transformation process. This will be elaborated in
the next chapter.

3. Descriptive Design Process ModelIn this chapter we present a descriptive design process model which shows design as a gradualtransformation from the function space onto the attribute space. This model is used to build aframework which directs the design process to be implemented in an intelligent CAD system.

Hideal<I Takeda, et al.

6

Design as a
Stepwise
Refinement
Process

Function Spacein terms of
Physical Phenomena

Attribute Space
measurable byPhysical Rules

Metamodel Space(Physical Phenomenon Space)
as Physical Features

Fig. 2. Design process in the real knowledge

Knowledge about the design process is embedded in the framework. Thus, the system is always
informed about the current stage of the design process and the current state of the design object[ 1]. Therefore, the descriptive design process model is described by using a more systemo riented terminology.
The knowledge about how to perform the design process and which tools are applicable at a
certain instant is denoted by means of scenarios. These scenarios represent design schemes
which describe what kind of actions must be carried out at a specific phase o f the design process[9, 11]. For each phase of the design process there is a different set of scenarios.
The descriptive model is used as a basis to develop an intelligent CAD syste m, while thecomputable model, d iscussed later, simulates the reasoning aspect of design. Both of them are
implementable on a computer; however, the former is meant to be a guide to discuss thearchitecture of an intelligent CAD system. The latter is more interesting for illustrating thatdesign as a reasoning process can be performed by a computer.

3.1. From specification to solution
We use GOT as a basis for giving a descriptive design process model. The basic ideas behind thedescriptive design process model are derived from the evolutionary design process model asfollows:•
From the given functional spec ifications a candidate for the design solution is selected andrefined in a stepwise manner until a complete solution is obtained, rather than by trying to
get the solution directly from the specifications. The latter is not possible in a non-trivial
design problem, since it involves a very complex object with a multitude of parts.

Modeling Design Processes

7•

The design process is regarded as an evolutionary process which transfers the model of thedesign object from one state to another, gradually obtaining a more detailed description.
The number of attributes grows as the design process proceeds and a growing number of thefunctional specifications is met.

•

To evaluate the current state of the design object model, various interpretations of thedesign object model need to be derived in order to see whether the object satisfies the
specifications or not.

We cam those interpretations of the design object model contexts and they can be regarded asinterpretations of the design object observed from certain points of view. Contexts allow adesigner to model the current state of the design object in a certain environment, i.e . they
represent an aspect model. More information albout the design object is obtained through thesecontexts and hence the number of attribute grows. Contexts are created by means of scenarios
which contain design knowledge and data necessary to build an aspect model. Scenarios performthe reasoning about a context and they lead the dialogue with the designer.

3.2. Stepwise refinement of metamodel
Considering GDT, a designer starts with the functional specification of a design object andcontinues the design process until a design solution is obtained. During this process the design
object model is refined in a stepwise manner. The central description of the design object iscalled a metamodel. It is called metamodel, because it is used during the design process as acentral model from which aspect models are derived .
Note that, although here the definition of the metamodel is different from that of theprevious chapter, the principle is the same. A metamodel in GOT is a set of attributes that include
descriptions concerning physical phenomena. Here we show the use of the metamodel tointegrate several aspect models.
A metamodel is a description of the design object which is independent of a context. It
contains all entities the design object is composed of, and it includes the relationships anddependencies among these entities. Data which is used in one of the contexts derived from themetamodel is stored apart from the metamodel. For instance, geometric data of the design object
is not to be found in the metamodel, but in a geometric aspect model. An example of ametamodel is shown in Fig. 3. It contains four entities and several relationships among these
entities. Note that there are relationships which take effect on only a single entity. Other
relationships take effect on several entities. During the course of design, the metamodel isrefined in a stepwise manner, gradually obtaining a more detailed description.
The stepwise refinement process shown in Fig. 4 behaves as follows: at a certain stage ofthe design process the metamodel M;_, is the current, incomplete description of the design object.
In order to get a more detailed description an aspect model is derived from the metamodel.
Through this aspect model some new information about the design object is obtained. After thisrefinement the new information from the aspect model is merged into the metamodel Mi-1 . If themerge is successful, i.e. the new information is consistent with the current M;_1 , then the result of
the merge is a new state of the metamodel, M;. This process continues, obtaining M;+1 , etc., until
the design object model becomes finally a complete and satisfactory description of the desired8

Hideaki Takeda, et al.

Metamodel

e Entity

Q
Q

Property
RelationshipFig. 3. Example of metamodel

artifact. We stress that here ·complete' has the meaning of satisfying all initial requirements. Asa matter of fact a des ign can never be complete; there is always something which can be
improved, or which can be made cheaper. In this context complete has a rather subjective
meaning.
DesignSolutionFig. 4. Stepwise refinement of the metamodel

In Fig. 5 an example of this process is depicted. It shows several stages of the design of anlinear m otion mechanism. In Fig. 5(a) the state of design is at the conceptual design phase. The
metamodel consists of an abstract anatomical description of the design object. Some states laterthe design is arrived at the fundamental design phase (see Fig. 5(b)). The metarnodel is aconcrete anatomical description of the design object with out detail, i .e there are someinconsistencies between the geometric and the kinematic representations. The stroke achieved by
the geometric representation is not the desired stroke. The detail is present in Fig. 5(c) when thedesign is at the detailed phase. Here, the metamodel consists of an exact anatomical description
which is almost complete. Inconsistencies caused by results from different aspect models are
removed. A more elaborated version of this example can be found in [25, 28].
strokestroke~- ~ li.~-~~E~9.~!9.~.~d1rectrona. Conceptual Phasestrokeol l..___00........1
b. Fundamental Phasec. Detailed Phase

Fig. 5. Example of stepwise refinement

Modeling Design Processes

93.3. Multiple representations
The design process as described above deals with the ideal situation in which the stepwise
refinement process is a linear process from functional specifications straight to the design
solution. lt can be regarded as a sketch of the design process in retrospect. In practice, it ismerely a process of trial and error, rather than the straightforward process shown in Fig . 4. The
designer might not be satisfied with a certain state of the design and wants to redo it from acertain point. But he keeps in mind the things which were useful and which were not, and theredesign will therefore be more efficient. In another occasion the designer might like to regard
the design object from different points of view at the same time, i.e. he wants to create multiple
aspect models concurrently in order to compare the outcome from different experts.
During the course of the design, an occasion frequently occurs that the designer is notsatisfied with the current state of design. Instead of redesigning everything from scratch, thedesigner wants to preserve part of the results. The designer restarts the design from a previous
design state which still met his demands. The implication for the design process model is that it
must be possible to withdraw the current metamodel and perform some backtracking to aprevious one. In consequence, each individual state of the metamodel must be maintained as thedesign proceeds. On top of that, when the design is continued from a prior metamodel, it must
be prevented from taking the direction which led to the unwanted result. Thus not only themetamodel states, blllt also the design process history must be maintained.
In Fig. 6 an example of the backtracking process is shown. For some reasons, themetamodel Mi does not fulfill the designer's requirements, so he decides to redesign from a priorstate. In this case, he backtracks to the previous metamodel Mi_ 1 • The design is resta11ed fromthis sta!te taking a different direction. The design now proceeds to metamodel M;, and so forth.

Fig. 6. Backtracking to a previous metamodel

3.4. Metamodel evolution scheme
The descriptive design process model, as we have introduced so far, gives a global outline of thedesign process, without going into details. We now focus on how to transfer from o.ne state of
the metamodel to the next; i.e. how do we perform a design step? Here we elaborate on theconcept of a context. Through the creation of a context the designer provides an interpretation ofmetamodel in a certain environment, i.e. he generates an aspect model. For each design step
there exists an associated scenario that creates a context which the design object is modeled in.
The scenario contains the design knowledge which is applicable for its context, and it knows
how to derive new data from the context and the current state of the metamodel. In a context
new information about a design object is obtained. The current metamodel together with the new
information form the next metamodel.

Hideaki Takeda, et al.

10

The design process is a continuous manipulation of the design object model. A certain
aspect of the artifact is highlighted and some properties about the design object are c hanged.
This highl ighting is done by contexts. By applying a context, the attention is focussed on a
specific part of the design object model. A context embodies a part of the metamodel with theaddition of aspect data. design procedures. and design rules. Aspect data is information about
the design object specific to a certain context. e.g. geometric information. It describes thecontext dependent properties of the design object. An example of a context is shown in Fig. 7.
A context is an interpretation of the metamodel focusing on a certain aspect of the design object.
It is used to derive new properties or to update uncertain or unknown properties abo ut themetamodcl in order to get a more detailed description . The new properti,e s about the design
object. which are derived in a context, are merged with the original metamodel when themodel ing is completed.
Meta·model.'r--------------- -- - -- -------~

Design scenarior---- --- ---- - ----------: Design rules'
I

I:111111I... :Design procedures- . __ ~- . __ -~- . __ -~d_a~a~
t~sp~ct
I

-

1
I

-

-

·=
-

- -

- -

-

- -

- -

-

. . . . . . ..

-

=== ·
-

,
I

------------- ------------ ----

I
I
I----- ------ -- --- ------ -Fig. 7. Example of context

Here. we discuss the application of the metamodel mechanism [21, 24, 26]. A design step isperformed by the execution o f a design scenario. A scenario consists of design proced ures anddesign rules which describe the procedural and declarative design knowledge respectively. The
rules and procedures are applied to the metamodel and to the aspect data. In such a manner wecreate a context which consists of (a pa rt of) the metamodel together with knowledge about thedesign object being valid in that particular context. The designer can interact with the context
and change its contents. After the session the contents of the co ntext being evaluated is mapped
to the next state of the metam odel. The mapping is performed by the metamodel evolution
mechanism presented below.
An example of such a context is a geometric representation of the des ign object. A part ofthe metamodel is collected and processed in a context with geometrical knowledge in order togenerate a n image of that part of the design object. In other words, there ex ists a scenario which
creates a geometr ic aspect model. The aspect data of the model consist of the geometricattributes of the design object. T he design procedures in the scenario describe geom etricalfunctions. and the design rules describe geometric knowled ge. Such a context descr ibes theModeling Design Processes

11

mapping of the metamodel onto a description suitable for the generation of a geometric model.
Hence. the metamode l allows the designer to model the geometric aspects of the design object
and therefore obtaining a more precise representation.
We can now give a definition of the mechanism which constitutes metamodel el'olution.
i.e. the metamodel mechanism. The metamodel m echanism is applied to per fonn a design step.
It transfers the metamodel from its cuJTent state to the next, according to the stepwise refinement
model. The mechanism is driven by scenarios. The designer selects a design scenario which isappropriate for the current state of the metamodel M;. The scenario is executed in a context c; andperforms in dialogue with the designer some action on the context. The execution of a scenariocontinues as long as new information can be obtained in the context. The acquisition of new
information is accompl ished through the design procedures and the design rules in a scenario.
The contents of a context is evaluated, when the execution of its scenario is completed.
The evaluation checks the context c; for consistency w ith the metamodel Mh i.e. there are nofacts that contradict each other and all constraints over the design object model are met. The
metamodel M ; is transfeITed to M ;+i, if the evaluation succeeds. In case of failure, all results of c;are discarded and the process will restart from M (see Fig. 8). This backtracking is performed indialogue with the designer, so that the next attempt can be made more successful.
1

T

M

M
i+1

F
M : meta-model
Backtracke : evaluationc : context

Fig. 8. Metamodel evolution
A consecutive application of the metamodel evolution m echanism enables the designer toperform a design job. Hence, the design process consists of the execution of a series of design
scenarios. For each state of the metamodel, there exists an appropriate scenario. The descriptive
design process model presented here, is derived from GOT. providing a framework wh ich allows
for design process representation. The metamodel mechanism is part of this framework anddepicts the evolutionary nature of the design process, i.e. it represents a design step. The design
process can therefore be modeled as a stepwise refinement process.
In this and the previous chapters, starting with discussing design theory from a theoretical
viewpoint, we obtained a descriptive design process model. This model clarifies therepresen tation of the design object that changes dynamically. We also suggested a way to apply
this model to building intelligent CAD systems. It seems to be reasonably interesting to extend
this descriptive model to a computable model that can clarify the reasoning process during thedesign process. But we do not only discuss design processes from a theoretical viewpoint.
Since not only the design object but also the designer plays a crucial important role in design, we
have to consider anotner viewpoin t, i.e, a cognitive viewpoint, which is presented in the next
chapter.

Hideaki Takeda, et al.

12

4. Design Experi ment and a Cognitive Design Process Model
used anIn this chapter, we discuss design processes from an experim ental point of view. We
ogicalexperim ental method called design experim ent [ 17. 29, 31 J. It is a kind of psychol
ations.
experim ent in which designer s are asked to design an artifact from a given set of specificTheres.
methodanalysislprotocoby
The whole designin g session is video-taped and analyzed
only in task
are various differences between the experiment in psychol ogy and one in design not
to obtain
prepared
be
must
ent
but also in environm ent and so on. We discussed how the experim[18]. This
useful results and perform ed several experim ents based on this discussi on
and Goelexperim ental approac h is also studied by e.g. Ullman. Dieneri ch, and Stauffer [23].
and Pirolli llOJ.
designOne of our major results obtained from the experim ents is a cognitiv e model of
This
17).
[
processes when examini ng a design process from a point of view of problem solving
model is construc ted from unit design cycles (see Fig. 9).

Development
Evaluation

Fig. 9. Design Cycle

A design cycle consists of five subprocesses as follows.
ng the object under(l) Awaren ess of the problem to pick up a problem by compari
consider ation and the specifications.
(2) Suggest ion to suggest key concepts needed to solve the problem .
various(3) Developmem to construc t candidates for the problem from the key concept s usingng
somethitypes of design knowledge. When developing a candida te, if somethi ng is foundunsolve d, it become s a new problem that should be solved in another design cycle.
tion,(4) Evaluat ion to evaluate candida tes in various ways, such as structur al computa
on,simulation of behavio r, cost evaluation, etc. If a problem is found as a result of evaluati
it becomes a new problem to be solved in another design cycle.
ions of the(5) Conclus ion to decide which candidate to adopt so as to modify the descript
object.
cycle isUtteranc es in the protoco l data are categorized into these subprocesses and then a design, andcompos ed of these subproces~e~. Basically a single design cycle solves one problem
onsuggestithesometimes new problem s that must be solved in other design cycles are arisen in
and evaluati on subproc esses.

13Modeling Design Processes

We can distinguish two levels in the design process when we consider the designer's mental
activity. One is the object !e1•e! on which the designer thinks about design objects themselves,e.g. what properties the design object has. how it behaves in a certain condition. and so on. The
other is the action !e1·e! on which the designer thinks about how 10 proceed her/his design. i.e,
what she/he should do next. T he designer seems to perform her/his design using these two typesof thinking mutually. When looking at design cycles with this aspect, they also contain these
two levels (see Fig. 10). The development and evaluation s ubprocesses are only present on theobject level, while the awareness-of-prob lem, evaluation, and conclusion subprocesses are
divided between these two levels. In the first two s ubprocesses, the designer has only to beconcerned with the design object. On the other hand, in other subprocesses. the designe r s hould
not only take the des ign object but also the design process itself into cons ideration. In case thedesigner encounters a pro blem that cannot be solved due to e .g. lack of in formation, she/he may ·suspend solving it until she/he receives s ufficient information or even try to abandon thatparticular design cand idate. Action level decision s are needed for dealing with such occasions.
In this c hapte r we presented the cognitive model of design processes. In the next chapter.
we will look at the reasoning aspect of the cognitive and descriptive models , which will result in.
the computable design process model.
. - - - - - - - Action Level-----.....

- -- - Object Level -----.....

Decision on a problem to be solved

Suggestion
Development---·--Evaluation -·~r~~""""I~~~~~~~~~~.....,~~=====:9!:======:;;::"-' ' ' '' ' '' ' ' 'Evaluation to confirm the solution

Conclusion

F ig. 10. T wo levels in the design cycle

5. A Logical and Computable Model of the Design Process
We try to reconstruc t the cognitive and descriptive mode ls into a computable model in _thischapter. Logic is a useful framework for this purpose, because it is developed from humanthought, and it is a lso closely related to infere nce. Some results towards understanding design inlogic are discussed in [3, 22] but they are concerned w ith design processes only at the conceptual
level but ne ither at the decision making level nor the computable level. In othe r words, they e ndup with just showing a possibility of logical formalization.

14

Hideaki Takeda, et al.

5.1. T he logical foundation for the computable model
In describing design processes logically, it is reasonable to assume the follow ing s imple model
as a first step:

Su K ~ Ds
where S, Kand Ds are a set of formulae that denote the specifications, knowledge used in design,and the design solutions. respectively. The solutions are derived from the specifications andknowledge as the results of deduction. We took this approach in [ 17]. and Forlog [4, 6] also
used this approach. However, this approach has three difficulties in interpreting the whole of thedesign process.
First. design is not always performed with complete information. The above assumption
requires complete descriptions for specifications. Although there are some domains such as
VLSI design in which all the required specifications are given before the beginning of design,
this cannot be applied to domains such as mechanical des ign where refinement of thespecifications is a crucial part of the design process to obtain complete specifications fromincomplete ones. This implies that refinement of specifications and designing of objects are
perfom1ed mutually in des ign; i.e. refinement of specifications recall next designing processes
and res ults of designing objects request to refine specifications. We employ not only deduction
but also abduction [5] for the formalization of design processes to refine the specifications.
Second, knowledge in the above assumption is concerned with how to design objects, i.e.
what the designer should consider the given specifications. A typical example is, "if there is a
specification S,. then use a design object D 1 ''. Although it may be useful for routine design, it is
not appropriate to more flexible and creative designs in which knowledge about object properties
and behaviors plays an important role. We believe that knowledge on object properties andbehaviors is more primary than knowledge about how to design, because a designer can design
even when she/he faces a task to design a new product using such knowledge on object
properties and behaviors.
The third problem, which is related to the second, is incompleteness and inconsistency of
the knowledge. W hen the designed object does not satisfy the specifications, ir should be
regarded that the knowledge base was initially incomplete rather than incons istent. Therefore,
we need to deal with a method to make an incomplete knowledge base complete.
In this article, we regard design solutions and knowledge as the premise and thespecification as the conclusion. Coyne and Treur also adopted this approach [3, 22]. Based on
this approach, we formalize design processes as bidirectional and iterative processes as follows:~
Dsu Ko I- P~
where Ds is a set of logical formulae describing a design solution which the desig ner wants toobtain (we call it a design candidate because it is not yet a solution of the design), Ko is
knowledge on object prope rties and behavior, and P are properties which the design candidate
has. Required specifications are included in P. Given design knowledge Ko and the required
properties P as the specifications, the designer tries to obtain a candidate which is expected tosatisfy the specifications by using abduction. Then deduction is performed (i) to see what

Modeling Design Processes

15

properties the candidate has and (ii) to see whether the candidate does not contradict with thegiven constrai nts including the specifications. because abduction merely proposes literally
candidates. This results in that the obtained candidate should be detailed by getting its complete
descriptions. If the candidate does not satisfy the spec ifications. the designer either tries analternat ive candidate or modifies the design knowledge and the specifications. This recalls
furthe r abductive or deductive processes, and finally complete descriptions of the solution andthe specifications are obtained. If there is no more way to explore, the design process
terminates.
We can solve the first and the second problems in this formalism, but we still ought to deal
with an incomplete k nowledge base, which is the third problem. We introduce circumscription[ 14] for this problem. We assume that every piece of knowledge is valid only when it is used incertain situations; i.e. a contradiction occurs, not because knowledge as a set of logical fomrnlae
contains contradicting information, but because it is not used in an appropriate situation.
However, it is not an easy task to explicitly describe applicable situations for every knowledge inadvance. We can only identify the applicability of knowledge when detecting a contradiction.
For a given set of logical formulae, circumscription can be used to compute exceptions that .
caused the contrad iction and to formulate them explicitly as a new situat ion. By doing so, theoriginal knowledge is modified and able to handle incompleteness.

5.2. The computable model
In the previous section, we discussed the idea of employing three different types of reasoning,i.e. deduction, abduction, and circumscription, for formalizing design processes. In this section,
we show a computable model of design processes based on these three types of reasoning and
we interpret the cognitive model in terms of the computable model.
Let us assume the following situation. We consider that a design process changes its state
step by step. In each state, the following three types of descriptions hold. The first one is thedescription of the current design candidate, that consists of either the identifiers of the current
design candidate or the propenies which are necessary to idenrify the current candidate. In thefollowing discussion it is denoted by Dsc. The second one is the description of properties of thecunent design candidate, Pc. It consists of all kinds of properties of the current design candidate.
The third one indicates the kind of knowledge that is available at the current state, Koc. These
descript ions are kept consist by satisfying the following formula:
Dsc U Koc I- Pc.
Now we try to make a computable model by interpreting the cognitive model in ~he logicalframework d iscussed! above. First we concentrate on the object level.
The suggestion subprocess is a process where the designer tries to find a feasible candidate.
This means that the purpose of this subprocess is to obtain Dsc from Pc a nd Koc and it can be
regarded as an abduction process. Peirce introduced abduction as an ampliative reasoning, i.e. it
augmen ts the knowledge. Since Peirce's abduction is considered logical reasoning from a
consequent to an antecedent, it commits an error of the fallacy of affirming the consequent. In
this sense, abduction is weak reasoning.

Hideaki Takeda, et al.

16

In our model, abduction is represented as follows;
Ds2=abduction(Ds1 • K 1 )where
Ds1 c Dsc.

K1 c Kc, andDs2 u K1

r Ds 1 •Ds1 , which is a pa11 of (or the whole of) the current design candidate, is replaced by Ds2 using

knowledge K1 . T he new description of the current design candidate is
Ds' = (Dsc - Ds,) u Ds2.
Ds' is expected to satisfy Pc with Koc, but there is no certainty because it is not the role ofabduction to check the consistency of the entire object description in our model.
On the other hand, both the development and the evaluation process are regarded as
deduction. In these subprocesses, the designer applies her/his knowledge to the candidates andobtai111s what is known at the current state. This is suitable for deduction, w hich is called
explicative reasoning by Peirce. The difference between those two subprocesses lies in the kindof knowledge which is applied. The development subprocess uses knowledge to find out what
properties the des ign object has, whereas the evaluation subprocess uses knowledge to compare
those properties obtained in the development subprocess with expectations. The purpose of
these two processes is to obtain P from Ds and Ko:
Dsc u Koc f- P'.
P' may be different from Pc if and only if Dsc or Koc changes. Dsc changes as the result of
abduction and Koc changes as the result of circumscriptio n which is discussed below.

While the designer is developing or evaluating, she/he sometimes en counters a difficulty
about the candidate and defines a new problem in order to solve it. It is a jump from adevelopment or evaluation subprocess to an awareness-of- problem s ubprocess. We interpret it
as circumscriptio n.
In the logical framework the continuation of the design process may be disturbed by two
reasons. One is lack of information, which will be dealt with by the meta-level reason ing. The
other is the occurrence of a contradiction in the theory. As mentioned in the previous section,
the contradiction does not happen because the knowledge contains false information but because
it is incomplete; i.e. some pieces of knowledge are used in the situation where they must not.
We can avoid this by defining exceptions for these pieces of knowledge using circumscripti on.
If a contradiction is detected in the theory, we gather formulae which cause thecontradiction. Then we add literals that arc composed of abnormal predicates to them andcircumscribe these abnormal predicates with the theory. We obtain modified formulae in which
their abnormal predicate are substituted by non-empty formulae. As the result, the contradiction
is removed from the theory. For example, suppose the theory is

I A~s. A~....c, ....c~_,s, A }.
Since this theory is inconsistent, we add an abnormal predicate to each formula as follows;Modeling Design Processes

17

I An-.ab, -+B, A-+n-.ab2-+- .C, -.Cn-.ab3-+-.B. A } .
When we circumscribe ab1 , ab2 and ab3 with the theory. one of the results is a set of substitutions
for abnonn.al predicates such as ab1 =-.C, ab2=false and ab3.=false. The formulae are then modi tiedas
{ AnC-+B. A-+-.C, -.C-+-.B, A } .

Circumscripti on modifies the knowledge currently used; it is expressed as follows:
Ko'= circumscription(Koc. Dsc. Pc)·

Since the formu lae are modified, we cannot always derive the formulae that represent therequired specifications from the current design candidate. Some new fonnulae must be added lo
the design candidate to satisfy the specifications . In this process, the contradiction creates a new
problem, i.e. the awareness-of- process subprocess. In the example above, we can avoid thecontradiction, but on the other hand we cannot conclude B, which is not satisfactory. One
possibility to derive B is to state a new problem C to be solved first.
Now we can discuss the action level of the logical framework. One of the problems that
occurs on the action level is how the awareness-of- problem subprocess becomes apparent.
Although we discussed a jump from the development and the evaluation subprocess to theawareness-of- problem s ubprocess, we have not mentioned how to start a design cycle. This is
one of the problems of logical reasoning, or rather a problem how to prepare the theory before
starting to reason. Therefore, we introduce meta-level operations to deal with this problem.
Metal-level architectures for reasoning are suggested by many researchers. For example,
Weyhrauch [27] proposed FOL which is a meta-level reasoning system based on first-order logic.
In our approach, operations on building theories and on how to perform reasoning are introduced
as meta-level operations including:setting-up of Os,
setting-up of P,
setting-up of Ko,
revision of Ds by abduction on P and Ko.
revision of P by deduction on Ds and Ko, andrevision Ko by circumscripti on on Ds. P and Ko.
Starting the design cycle is interpreted as execution of setting-up of P and setting-up of Ko
operations. Similarly, we can interpret the suggestion, the development and the evaluatiqn
subprocess as the executions of these operations. Knowledge about how to design can be
represented as a sequence of the operations on this level.
Reasoning on the action level is, therefore, to obtain a sequence of the operations on theobject leve l. This reasoning is performed by using the status of the object level and knowledge
about how to design. The status of the object level is determined by what kind of information is
obtained on the object level and how this information is obtained. Knowledge about how todesign, which is menlioned in the previous section, is only used on this level and includes
procedural knowledge about how to proceed design, design strategy, and so on. It is possible todiscuss reasoning on the action level in the same way we did for the object level. However,Hideaki Takeda, et al.

18

actually only deduc tive reasoning such as rule-based reasoning is needed because most of thistype of knowledge is procedural.
We do not interpret the conclusion subprocess within the logical framework . It is a
decisio n making process by considering all information obtained by other types of reasoning andtherefore it seems a reasoning higher than those types of reasoning. We leave this subprocess
unformalized.
Fig. 11 summaries the discussion, i.e. it shows the correspond ence between the
subprocesses and these types of reasoning in the logical framework .

Operation ofknowledge& Goal

Evaluation

Deduction
Conclusion

Circumscription

Fig_ 11. Reasoning on the design cycle

6. The Design Simulator
We implemente d a prototype of design simulator that realizes the inference discussed above.
We call it the design simulator, because it is designed to track the design processes performed bydesigners.

6.1. The architectu re
The design simulator consists of two main parts; i.e. the action level inference system and theobject level inference. The object level inference consists of furthermore workspace Ds, P, andKo, and three infe rence subsystems , i.e. deduction, abduction and circumscrip tion subsystems(see Fig. 12).
The meta-level inference is performed by a rule-based system. Knowledge used o n thislevel is about how to desig n, for example, knowledge about selecting a knowledge base andscheduling reasoning according to the condition of the object level. Results of this deduction isa sequence of operations on the object level which are described in the previous chapter.
The object level inference is performed by abduction, deduction, and circumscrip tion to theworkspace that modify the current state of Ds, P, and Ko. Ko contains knowledge as Hom clause,and P and Ds contain objects and their properties as atom formulae that have only a literal. The
inference on the object level modifies the contents of Ds, P, or Ko and sometimes causes
contradictions, which are reported to the meta-level as a condition of the object level.

Modeling Design Processes

19

Design Simulator - - - - -- - - - - - - - - Knowledge Base about• o•wAsignof-n--l-e-ve_1_1-'n'--fe_r_e_n_ce+----"\....oill. ._ _..._ hti...
Ac......
Operations

LJ,-

Workspace_

Conditions

Object-level Inference

abduction deduction circumscription

Knowledge Baseon objects~iilMl~ili.. ~-- ~-- i...---LJ
.....

...

Fig. 12. The design simulato r

Abductive reasoning and circumscription are realized as follows. There is some work on
abductive reasoning, e.g. the RESIDUE system [7] and the work by Cox and Pietrzykowski [21.
They a re based on t he resolution principle in order to perform abductive reasoning. Abductivc
reasoning can be regarded as a process deriving a theory from formulae which denote knowledge
and possible assumptions. Suppose G is a goal, K is a set of formu lae representing knowledge.
and A is a set of formulae representing all possible assumptions. We find a subset A to prove Gby
KU A1 f- G

where A 1 c A. Then A 1 is obtained by abduction of G using K. This idea is shown by Poole [ 16J
as the theory of default reasoning, but it can also be applicable to abductive reasoning. We
implemented th is abductive reasoning by modifying the algorithm of Prolog [ 13] to have two
sets of clauses. One is the definition clause set which is K in the above formula and contains
program clauses, and the other is the assumption clause set which is A and contains only unit
clauses. Given a goal, the system resolves it until an empty clause is found as Prolog does,
except tha t we first use clauses in the definition clause set. The clauses in the assumption clauseset are used, if and only if there is no clause to be applied in the definition clauses. This process
corresponds to findiing A1 from A in the above explanation. This matching s trategy is provided toobtain deeper assumptions. Here, set of assumptions A1 is deeper than set of assumptions A2 , if
and o nly if A1 u K f- A2.
The circumscription system is implemented using the a lgorithm proposed by Nakagawa andMori [15). They developed an algorithm for computing circumscription [12J on clausal forms.
Their basic idea is to use the technique of program transformation such as u11fo/di11g wheneliminating variable predicates and abnormal predicates .
The design simulator accomplishes a reasoning process by using abduction, deduction andcircumscription repeatedly. The order of them are specified by the action level, and it asks theusers when there are some alternatives. This system is implemented in Allegro Common L isp
and Xl 1 on Sun-4.

Hideaki Takeda, et al.

20

6.2. Example
We s imulate a des ign process composed of protocol data obtained by a design experiment.
Fig. 13 shows a snapshot of the design simulator solving this example. The task is to design aweighing scale and a part of the protocol data is shown in Fig. 14. To simulate design processesby the design simulator, we prepare data as follows. Observing the protocol data, we represent
the designer's thought as a set of formulae shown in Fig. 15 (numbers in this figure correspond toones in the protocol data in Fig. 14). We also translate the required specifications into logicalform. We set the specifications to P, and the design simulator executes abduction and deduction
when new knowledge is added and the candidate and its properties are revised.

Fig. 13. A snapshot of the design simulator
We illustrate a short session of the reasoning that corresponds to a part of the actual design
session. At the beginning of the process, there exits only the specifications in P and nothing in
Ds (see Fig. l 7(a)). The formulae corresponding to the protocol (1 )-(7) are added to Ko, andusing by P and Ko, the content of Ds, which prepresents the current design candidate, is revised
as in Fig. 17(b). And the content of P, which represents properties of the current candidate, isalso revised as in Fig. l 7(b). Since Ds contains the specifications, it satisfies the specifications. A
contradiction is detected when adding knowledge of the protocol (8); the designer notices that aneasy mechanism is needed for the machine in the human process. This contradiction occurs,
because formula (2a) derives scale(*s) and formula (8a) derives not(scale(*s)). Thencircumscription is executed, and as a result formula (2a) and (8a) are modified as shown in
Fig. 16. The literal is_easy_mechanism added to formula (2a) is used in the next abduction, andthe new formula is added to Ds. Fig. l 7(c) shows the revised contents of Ds and P.

Modeling Design Processes21( l ) What mechanism docs a standard scale use?
(2) It measures the weight like this Fig. A).
(3) If we can use rack and pinion {Fig. 8 ). we can measure the weightbecause the displacement is in proportion to the weight.
(4) Anyway. we think about the indicator first.
(5) When it translates 5mm of the displacement to the l OOkg weight.
the displacement is 0.05mm/kg.
(6) It is possible to realize it with Fig. B.
(7) If we don't mind the accuracy. it is possible by using many gears.
(8) But a standard scale must use a more simple mechanism.

Fig.A

3L
Fig. B

Fig. 14. The protocol data
~ Ko ~~~~~~~~~~~~~~~~~~~~~~~~~-'(2a) scale(*s) f- can_measureCs *w) /\ support(*x ·w)(2b) support("s *w) f- has(*s spring)(2c) can_ measure(*s *w) f - translate(*s *w *d) /\ has(*s pinion)(3a) translate(*s *w *d) f- is_in_proportion(*s *w *d)I(3b) is_in_proportion(*s ·w *d) f- has(*s rack) /\ has(*s pinion)(6) translate(*s 1 OOkg 5mm) f- has(*s indicator!) /\ has(indicatorl many_gears)(8a) not(weighing_ machine(*s)) f- has(*s indicator1 ) /\ not(is_ easy_ mechanism(indicator1)) I___)(8b) not(is_ easy_mechanism(indicator1)) f- has(indicator1 many_gears)

1I

Fig. 15. T he contents of Ko· ··Ko'(2a)' scale(*s) f - can_ measure(*s *w) /\ support(*x *w) /\ is_easy_mechanism(indicator1) \(8a) not(scale(*s)) f- has(*s indicator1) /\ not(is_easy_mechanis_:1(indicator1 )) /\ true

J

Fig. 16. Modified formulaeThis example demonstrates that the designer simulation is capable of replaying design
sessions by tracking protocol dat~ obtained by design experiments. This indicates that thecomputable model presented in this chapter shows the same operational aspects as the cognitivemodel. It is also justified crucial to employ different types of reasoning for implementing design
subprocesses of the cognitive model as a computable model.

Hideaki Takeda, et al.

22

~ P1

scale(*s)

j l 'anslate("s100kg 5mm)(a ) Before start of designing/ - Ds ·-- -p ~~~~~ ~~~~-~~~~~~~~~~~---

has(indicator1 many_gears)
has(*s spring)has(*s indicator1)~~s(*s rack)j~as(*sp-in_i_o_n)~~~~-~~~-

scale(*s)
can_measure(*s *w)
translate("s 1OOkg 5mm)
support(*s 100kg)
is_in_proportion(*s *w *d)has(indicator1 many_gears)
has(*s spring)has(*s indicator1)
has(*s rack)has(*s pinion)(b) Before protocol (8)- Ds -~~~--~~~--~-

p ~~~--~~~~~~~~~~~--~~~~--

many_gears)
I has(*s spring)I has(*s indicator1)
I has(*s rack)
I has(*s pinion)is_easy_mechanism(indicator1)has(indicator1 many_gears)
scale(*s)
has(*s spring)
can_measure("s *w)
translate(*s 100kg 5mm)
has(*s indicator1)
has(*s rack)
support(*s 1OOkg)
has(*s pinion)
is_in_proportion(*s *w *d)"' is_easy_mechanism(indicator1)~as(indicator1l(c) After protocol (8)Fig. 17. Transition of the contents of Ds and P

7. Discussion
In this article we presented three different models, viz. a descriptive model, a cognitive model,
and a computable model. In the descriptive design process model we illustrated a generalframework of the design process as an evolutionary refinement process of the metamodel. Since
we put emphasis on the representation of the design object and the design process rather than on
reasoning aspects in the discussion of the descriptive model, the mechanism of reasoning indesign did not become clear. These aspects are highlighted for the discussion on the cognitive
design process model. We examined the design processes of the designers, and presented how
the designer proceeds her/his design.
Reasoning in design processes is shown as repetition of the design cycle on two levels, i.e.
the object level and the action level. Repetition of the design cycle corresponds to the stepwise
refinement process presented in the descriptive model. A unit design cycle corresponds to a
design step in the descriptive model. Furthermore, the design cycle clarifies different kinds ofreasoning that should be done in design processes. The computable design process: model
realizes these two models by logical reasoning. The framework of the computable model is theevolutionary process of the design object discussed in the descriptive model, i.e, we realized it asModeling Design Processes

23

a rev1s10n process of the theory in logic. This revision process of the theory is perfonned bylogical reasoning, i.e. abduction. deduction. and c ircumscriptio n. and it is realization ofreasoning discussed in the cognitive model. Thus we succeeded in integrating the descriptive
and cognitive models using a logical framework, and the result of the integration is shown by thecomputable mode l.
Furthermore. based on this computable model we implemented a system called the design
simulator. By comparing the sessions performed by the design simulator and those performedby the designer, we obtained information such as what knowledge should be prepared or whatkind of reasoning is missing. This information is indispensable to develop the computablemodel and it also contributes to improve the architecture or inte lligent CAD systems.

8. Conclusions
We presented a logical formalization of des ign processes to establish a computable des ign
process model. The formalization uses both deduc tive and abductive reasoning, and design isviewed as a process where both of the theory a nd the goal are gradually enhanced. Furthermore,
we introduced circumscription through which a contradictory situation of the current design
candidate is removed by modifying the theory. This model is proven computable by the design
simulator and it also turned out appropriate for a design process model.
W e discussed the relationships among the descriptive, the cognitive, and the computablemodels. The computable model uses the framework of the descriptive model, while thereasoning in the computable model is an interpretation of the cognitive model. Thus, the model
we proposed as a computable model is a realization of both the cognitive model and thedescriptive model of design processes.
We showed various approaches to model the design process from a pure theoretical one to acomputable one. These approaches are related with each other and they provide an appropriate
framework to construct an intelligent CAD system whose behavior is in correspondence w ith thedesigner's.

Acknowledgements
We would like to thank Paul ten Hagen for various discussions on des ign process models,
Kazuto Hayash i and Jan Treur for useful discussions on log ical formalization, and Juro Baba forcontributing to the implementation of the design simulator.

ReferencesI.

2.

V. Akman , P.J.W. ten Hagen, J. Rogier, and P.J. Veerkamp, "Knowledge Engineering in
Design," Knowledge-Based Systems, vol. 1, no. 2, pp. 67-77, 1988.
P.T. Cox and T. Pietrzykowski, "Causes for Events: Their Computation and Applications,"in Lecture Notes in Computer Science 230, pp. 608-621, Springer- Verlag, 1986.

3.

R. Coyne, Logic M odels of Design, Pitman Publis hing, L ondon, 1988.

4.

T.H. Dietterich and D.G. U llman, "FORLOG: A Logic-based A rchitecture for D esign,"
Re p. No. 86-30-8, Computer Science Department, Orego n State University, 1987.

24

Hideaki Takeda, et al.

5.

K.T. Fann, Peirce' s Theory of Abduction, Martinus Nijhoff, The Hague, The Netherlands,
1970.

6.

N.S. Fann, T.G. Dietterich, and D.R. Corpron, "Forward Chaining Logic Programmingwith the ATMS,'' in Sixth National Conference on Artificial lntellif!,ence, pp. 24-29,
American Association for Artificial Intelligence, 1987.

7.

J.J. Finger and M.R. Genesereth, "RESIDUE: A Deductive Approach to Design
Synthesis," Technical Report Stan-CS-85-1035, Stanford University, 1985.

8.

S. Finger and J .R. Dixon, "A Review of Re.search in Mechanical Engineering Design. Part
I: Descriptive, Prescriptive, and Computer-Based Models of Design Processes," Research
in Enp,ineering Design, vol. I, no. I , pp. 51-67, 1989.

9.

M .J. French, Conceptuaf Design for Engineers, Springer-Verlag, Berlin, 1985.

10. V. Goel and P. Pirolli, " Motivating the Notion of Generic Design within Informationprocessing Theory: The Design Problem Space," Al ma[;azine, vol. 10, no. 1, pp. 18-47,
1989.
11. V. Hubka, Principles of Engineering Design, Springer-Verlag, Berlin, 1987.
12. V. Lifschitz, ''Computing Circumscription," in Proceedings of Ninth International Joint
Conference on Artificial Intelligence, Los Angles, CA, pp. 121 - 127, 1985.
13. J.W. Lloyd, Foundations of Logic Programming, Springer-Verlag, Berlin, 1984.
14. J. McCarthy, "Circumscription - A Form of Non-Monotonic Reasoning, " Artificial
lntellif!,ence, vol. 13, pp. 27-39, 1980.
15. H. Nakagawa and T . Mori, "Computable Circumscription in Logic Programming,"
Transactions of Information Processing Society of Japan, vol. 28, no. 4, pp. 330-338, 1987.
In Japanese
16. D. Poole, "A Logical Framework for Default Reasoning," Artificial Intelligence, vol. 36,
pp. 27-47, 1988.
17. H. Takeda, T . Tomiyama, and H_ Yoshikawa, "A Logical Formalization of Design
Processes," in Intelligent CAD, II, ed. H. Yoshikawa, and D. Gossard, North-Holland,
Amsterdam, 1990.
18. H. Takeda, S. Hamada, T. Tomiyama, and H. Yoshikawa, "A Cognitive Approach of theAnalysis of Design Processes," in The Second ASME Design Theory and Methodology
Conference, 1990. Forthcoming.
19. P.J.W. ten Hagen and T. Tomiyama, i ntelligent CAD systems I: Theoretical andMethodological Aspects, Springer-Verlag, Berlin, 1987.
20. T. Tomiyama and H. Yoshikawa, "Extended General Design Theory," in Design Theory
for CAD, Proceedings of the JFIP Working Group 52 Working Conference 1985 (Tokyo),ed. H. Yoshikawa, and E.A. Warman, pp. 95-130, North-Holland, Amsterdam, 1987.
21. T . Tomiyama, D. Xue, and Y. Ishida, "An Experience with Developing a Design
Knowledge Representation Language," in Intelligent CAD Systems Ill - Practical
Experience and Evaluation, ed. P.J. Veerkamp, and P.J.W. ten Hagen, Springer-Verlag,
Berlin, 1990. Forthcoming.

Modeling Design Processes

25

22. J. Treur, "A Logical Framework for Design Processes," in lmelli?,elll CAD Systems II/ Practical Experience and E\·aluation. ed. P.J. Veerkamp. and P.J.W. ten Hagen, SpringerVerlag, Berlin, 1990. Forthcoming.
23. D.G. Ullman, T.G. Dietterich, and LA. Stauffer. "A Model of the Mechanical Design
Process Based on Empirical Data: A Summary," in Artificial lmelligence in Engineering
Design, ed. J.S. Gero, pp. 193-215, Elsevier, Amsterdam, 1988.
24. P.J. Veerkamp, R.S.S. Pieters Kwiers, and P.J.W. ten Hagen, " Design Process
Representation in ADDL," in Intelligent CAD Systems III - Practical Experience andE11aluatio11, ed. P.J. Veerkamp, and P.J.W. ten Hagen, Springer-Verlag, Berlin, 1990.
Forthcom ing.
25. P.J. Veerkamp, T. Kiriyama, D. Xue, and T. Tomiyama, •· Representation and .
Implementation of Design Knowledge for Intelligent CAD - Theoretical Aspet:Ls, · ·Proceedings of the Fourth Eurographics Workshop on l ntelligent CAD - The Added Valueof Intelligence, Compiegne, 1990.
26. B. Veth, "An Integrated Data Description Language for Coding Design Knowledge," in .
Intelligent CAD Systems I - Theoretical and Methodological Aspects, ed. P.J.W.
ten Hagen, and T. Tomiyama, pp. 295-3 l 3, Springer-Verlag, Berlin, 1988.
27. R.W. Weyhrauch, " Prolegomena to a Theory of Mechanized Formal Reasoning," Artificial
Intelligence, vol. 13, pp. 133-170, 1980.
28. D. Xue, T. Kiriyama, P.J. Veerkamp, and T. Tomiyama, .. Representation and
Implementation of Design Knowledge for Intelligent CAD - Implementational Aspects,''
Proceedings of the Fourth Eurographics Workshop on Intelligent CAD - The Added Valueof Intelligence, Compiegne, 1990.
29. H. Yoshikawa, E. Arai, and T . Goto, "Experimental Design Theory," Journal of the Japan
Society of Pecision Engineering, vol. 47, no. 7, pp. 830-835, 1981. In Japanese
30. H. Yoshikawa, "General Design Theory and a CAD System," in Man-Machine
Communication in CAD/CAM, Proceedings of the IFIP Working Group 5.2 Working
Conference 1980 (Tokyo), ed. T. Sata, and E.A. Warman, pp. 35-58, North-Holland,
Amsterdam, 1981.
31. H. Yoshikawa, "CAD Framework Guided by General Design Theory," in CAD Systems
Framework, Proceedings of IFIP Working Group 5.2, ed. K. Bo, and E.M. Lillehagen, pp.
241 -253, North-Holland, Amsterdam, 1983.