Application Of Artificial Intelligence In Architectural Design Ph.D. Dissertation

APPLICATION OF ARTIFICIAL INTELLIGENCE
IN ARCHITECTURAL DESIGN
_________
A Thesis Presented to the Faculty of Engineering
Department of Architecture
Al-Azhar University, Cairo, Egypt.
for the Degree
DOCTOR OF PHILOSOPHY
_________
by
Mohamed-Sherif Tawfik El-Attar
July-1997
_________
Thesis Committee
Dr. Mohamed Zakaria El-Dars (Chair)
Professor at the Department of Architecture, College of Engineering,
Dr. Jens Pohl (Co-chair)
Professor at the College of Architecture and Environmental Design,
California Polytechnic State University, San Luis Obispo, CA, USA.
Dr. Mohamed Abu-El-Magd Mahmoud
Associate Professor at the Department of Architecture, College of Engineering,

ii
TABLE OF CONTENTS
TABLE OF CONTENTS ................................................................................................ ii
LIST OF FIGURES ...................................................................................................... vii
LIST OF TABLES......................................................................................................... ix
AKNOWLEDGMENTS.................................................................................................. x
ABSTRACT.................................................................................................................... 1
INTRODUCTION .......................................................................................................... 3
Research Orientation ....................................................................................................... 5
Goals........................................................................................................................ 6
Problems .................................................................................................................. 6
Propositions ........................................................................................................... 10
Hypothesis.............................................................................................................. 12
Methodology.......................................................................................................... 12
Thesis Organization....................................................................................................... 13
CHAPTER 1: DESIGN AND COMPUTATION........................................................... 15
1.1 Nature of Design ..................................................................................................... 15
1.1.1 Design Problems............................................................................................ 16
1.1.11 Distinction Between Problems............................................................... 17
1.1.12 Characteristics Of Design Problems....................................................... 18
1.1.13 Design Artifacts.................................................................................... 20
1.1.2 Design Experience ......................................................................................... 23

TABLE OF CONTENTS iii
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
1.1.21 Empirical Studies.................................................................................. 23
1.1.22 Features Of Designers Experience......................................................... 29
1.1.23 Cognitive Theories................................................................................ 31
1.2 Models Of Design.................................................................................................... 35
1.2.1 The Intuitive Model ....................................................................................... 36
1.2.2 The Rational Model ....................................................................................... 38
1.2.3 The Participatory Model ................................................................................ 39
1.2.4 The Logical Model ........................................................................................ 40
1.2.5 Computational Models Of Design .................................................................. 42
1.2.51 Problem Solving.................................................................................... 43
1.2.52 Puzzle-Making...................................................................................... 44
CHAPTER 2: REPRESENTATION OF EXPERIENCE............................................... 47
2.1 Fundamental Issues Of AI........................................................................................ 52
2.1.1 Hypotheses Of AI.......................................................................................... 52
2.1.2 Multiple Views Of AI .................................................................................... 55
2.1.21 Systems That Act Humanly................................................................... 56
2.1.22 Systems That Think Humanly................................................................ 57
2.1.23 Systems That Think Rationally.............................................................. 58
2.1.24 Systems That Act Rationally ................................................................. 59
2.2 Representing Experience In AI Systems................................................................... 62
2.2.1 Levels Of Understanding In AI Systems......................................................... 63
2.2.2 Models Of Expertise...................................................................................... 65
2.2.21 Heuristic Models................................................................................... 66
2.2.22 Deep Models ........................................................................................ 67
2.2.23 Implicit Models..................................................................................... 69

TABLE OF CONTENTS iv
2.2.24 Competence Models ............................................................................. 71
2.2.25 Distributed Models ............................................................................... 74
CHAPTER 3: RESEARCH GOALS AND OBJECTIVES ............................................ 77
3.1 Context Of The Problem.......................................................................................... 80
3.1.1 Design Environments..................................................................................... 80
3.1.2 Components .................................................................................................. 81
3.1.3 Role In Design............................................................................................... 82
3.1.4 Required Features Of CBDE.......................................................................... 83
3.2 Research Goals........................................................................................................ 85
3.2.1 Prior Knowledge In Design Environments...................................................... 87
3.2.2 Research Hypothesis...................................................................................... 87
3.2.3 Objectives...................................................................................................... 90
CHAPTER 4: RESEARCH PROBLEMS AND PROPOSITIONS ................................ 92
4.1 Content Of Prior Knowledge ................................................................................... 92
4.1.1 Nearly Decomposable Products - Problem ..................................................... 94
4.1.2 Functional Explication - Problem ................................................................... 95
4.1.3 Activities Are Building Blocks Of The Design Solution - Proposition 4.1....... 97
4.1.31 Content Of Information In An Activity.................................................. 99
4.1.32 Advantages Of The Proposition .......................................................... 100
4.2 Organization Of Prior Knowledge.......................................................................... 101
4.2.1 Knowledge Organization - Concepts............................................................ 101
4.2.11 Design Cases ...................................................................................... 103
4.2.12 Design Prototypes............................................................................... 104
4.2.2 Information Retrieval - Methods .................................................................. 105
4.2.21 Decomposition.................................................................................... 105

TABLE OF CONTENTS v
4.2.22 Case-Based Design ............................................................................. 106
4.2.23 Constraints.......................................................................................... 106
4.2.3 Activities Are Universal In Character - Proposition 4.2 ................................ 107
4.2.31 Activity Prototypes............................................................................. 107
4.2.32 Activity Cases..................................................................................... 110
4.2.33 Implications Of The Proposition.......................................................... 115
4.3 Knowledge-Based Designing ................................................................................. 115
4.3.1 Design Classification.................................................................................... 116
4.3.11 Routine Design ................................................................................... 116
4.3.12 Non-routine Design............................................................................. 116
4.3.2 Knowledge-Based Creativity........................................................................ 119
4.3.3 Using Activities To Describe Spaces - Proposition 4.3 ................................. 121
4.3.31 Routine Space Description.................................................................. 122
4.3.32 Innovative Space Description.............................................................. 122
4.3.33 Creative Space Description ................................................................. 124
CHAPTER 5: IMPLEMENTATION OF RESEARCH PROPOSITIONS.................... 127
5.1 Approach to Architectural Programming................................................................ 128
5.1.1 Process........................................................................................................ 129
5.1.2 Product........................................................................................................ 131
5.1.3 Architectural Programming Environment (APE-1) ....................................... 133
5.1.4 Scenario ...................................................................................................... 135
5.1.41 Case Project........................................................................................ 135
5.1.42 Role Selection..................................................................................... 136
5.1.43 Project Creation.................................................................................. 137
5.1.44 Problem Structuring............................................................................ 137

vi
5.1.45 Problem Formulation .......................................................................... 146
5.1.46 Output of the system........................................................................... 159
5.2 Implementation Design .......................................................................................... 161
5.2.1 Implementation Framework ......................................................................... 161
5.2.11 Knowledge Organization..................................................................... 162
5.2.12 Knowledge Content ............................................................................ 163
5.2.13 Processes............................................................................................ 164
5.2.2 Development Environment........................................................................... 165
5.2.21 Programming Language ...................................................................... 165
5.2.22 Advantages of object-oriented programming....................................... 167
5.2.3 Implementation Architecture........................................................................ 168
5.2.31 Data Store Design............................................................................... 169
5.2.32 System Agents Design ........................................................................ 194
CHAPTER 6: CONCLUSIONS .................................................................................. 211
6.1 Contributions......................................................................................................... 214
6.2 Future Work.......................................................................................................... 216
BIBLIOGRAPHY....................................................................................................... 218
APPENDIX-A: CONSTRAINT MAPPINGS.............................................................. 229
APPENDIX-B: PROGRAMME DOCUMENT SAMPLE........................................... 231
APPENDIX-C: DEFINITIONS................................................................................... 235
APPENDIX-D: AGENT DEMONSTRATIONS......................................................... 241
ARABIC ABSTRACT ................................................................................................ 251

vii
LIST OF FIGURES
Figure 0.1: Utilizing Functional and Structural Decomposition...................................... 11
Figure 1.2: Information-Processing System................................................................... 32
Figure 1.3: The Intuitive Model.................................................................................... 38
Figure 1.4: The Rational Model.................................................................................... 39
Figure 1.5: The Logical Model ...................................................................................... 42
Figure 2.1: Agents Perceive and Act............................................................................. 61
Figure 2.2: Problem Solving Knowledge Ordered by Complexity.................................. 63
Figure 2.3: Task Structure of Design ............................................................................ 72
Figure 2.4: Relationships between Models of Expertise................................................. 76
Figure 3.1: Research goals, scope, and propositions...................................................... 79
Figure 3.2: Process and product integration views ........................................................ 84
Figure 3.3: Research goals map .................................................................................... 86
Figure 3.4: Mapping activities through different space and building types...................... 89
Figure 4.1: Function-behavior-structure relations.......................................................... 96
Figure 4.2: Information in an activity.......................................................................... 100
Figure 4.3: Human and computer in a single cognitive model...................................... 102
Figure 4.4: Case-based reasoning framework.............................................................. 104
Figure 4.5: Design prototype-instance refinement ....................................................... 104
Figure 4.6: Contextual modifiers of an activity............................................................ 110
Figure 4.7: State space of routine and non-routine designs.......................................... 118

LIST OF FIGURES viii
Figure 4.8: Innovative design using activities .............................................................. 123
Figure 4.9: Combination process................................................................................. 125
Figure 5.1: Building Specification (Flowchart)............................................................ 139
Figure 5.2: Building Prototype-Instance Adaptation/Creation ..................................... 141
Figure 5.3: Space Prototype-Instance Adaptation/Creation ......................................... 145
Figure 5.4: Space-Instance Refinement - Constraints Generation phase....................... 150
Figure 5.5: Formatted Programme Document............................................................. 160
Figure 5.6: Programming languages classification ....................................................... 166
Figure 5.7: Implementation Architecture..................................................................... 169
Figure 5.8: Problem Domain Components Classes - Conceptual Schema..................... 171
Figure 5.9: Typification process concepts ................................................................... 175
Figure 5.10: Problem Domain Components (PDC) - OM............................................. 177
Figure 5.11: Distinct notions of a building site ............................................................ 180
Figure 5.12: Building prototype notion ....................................................................... 183
Figure 5.13: Sample CLIPS (6.0) source code - Building Class daemon...................... 184
Figure 5.14: Space prototype notion........................................................................... 189
Figure 5.15: Tabulated example of wall instances noise behavior................................ 189
Figure 5.16: Process of utilizing space user related information................................... 190
Figure 5.17: Activity relationships - object model ....................................................... 191
Figure 5.18: Climate agent - ET diagram .................................................................... 199
Figure 5.19: Noise agent evaluation of site sound pressure level - ET diagram............ 203
Figure 5.20: B.R.S. Simplified Table operation........................................................... 206
Figure 5.21: SKY object representation example......................................................... 208
Figure 5.22: Daylighting agent evaluation of daylighting performance - ET diagram.... 209
Figure 5.23: Example of using B.R.S. Tables.............................................................. 210

LIST OF TABLES ix
Figure 6.1: Mapping constraints.................................................................................. 213
LIST OF TABLES
Table 1.1 :Classifications of types.................................................................................. 27
Table 2.1: Different views of AI ................................................................................... 56
Table 4.1: User modifier............................................................................................. 111
Table 4.2: Time modifier ............................................................................................ 113
Table 4.3: Site modifier .............................................................................................. 114
Table 5.1: Architectural programming data................................................................. 130
Table 5.2: Climate agent general and specific design recommendations features.......... 195

x
ACKNOWLEDGEMENTS
Although the completion of a doctoral research program is recognized as an individual's
achievement, such an accomplishment is only possible with the guidance and support of
faculty, friends, and family. I attempt to acknowledge here those who have provided
guidance, support, and inspiration for this work.
Initially I would like to thank my supervising committee, each of which have played a
major role in the completion of this research: Professor M. Zakaria El-Dars for his
guidance, support, and everlasting encouragement to proceed against the odds. Professor
Jens G. Pohl, for his support, patient guidance and constructive criticism that have
contributed greatly to the completion of this research and dissertation. Dr. Mohamed A.
Mahmoud, who introduced me to this research area and participated in seeding the initial
ideas of this research.
My acknowledgments to Professor Len Myers at the Computer Science Department,
California Polytechnic State University, for allowing me to audit his AI classes, and his
thoughtful comments on my work. Dr. Shehab Gamal-ElDin at the Computer Science
Department, Al-Azhar University who have provided many insightful comments,
questions, and suggestions in discussions over the implementation and its description.
I would like to thank all the faculty, staff members and friends at the Department of
Architecture, Al-Azhar University for carrying my teaching loads and their moral support,
that gave me the time and the driving force to complete this research. Many thanks goes
to my friend and colleague Safwan Aly, currently at Carnegie Mellon University,
Pittsburgh, for initializing my visit to Cal Poly, helping me and my family to settle at San
Luis Obispo, and helping me to learn programming in CLIPS, all of which has saved me a
great deal of time and effort.

ACKNOWLEDGEMENTS xi
Most importantly, is the love and support of my family. My mother who have provided
constant encouragement love and support. My father in-law for his help and support. My
wife Naglaa, and children Yasmin and Abdel-Rahman who have sacrificed their time and
activities so that I might complete this accomplishment.
A great deal of this research has taken place at the CAD Research Center, under the terms
of the Academic Channel Exchange Program between the Department of Architecture, Al-
Azhar University and the College of Architecture and Environmental design, California
Polytechnic State University. Many thanks goes to the Egyptian Ministry of Education for
providing this opportunity for me and others, and for their sponsorship during my visit to
the United States.
Most of all, I thank God for providing all those good people who helped me.
Mohamed-Sherif T. El-Attar
Al-Azhar University, Cairo, Egypt
July 1997

1
ABSTRACT
APPLICATION OF ARTIFICIAL INTELLIGENCE IN
ARCHITECTURAL DESIGN
Mohamed-Sherif T. El-Attar
Department of Architecture, College of Engineering
Al-Azhar University, Cairo, Egypt
Prior knowledge plays a major role in architectural design. This knowledge pertains to the
products and processes of design. Utilizing computers as a design medium requires the
representation of such knowledge for reasoning purposes. The choice of what to represent
from these concepts (i.e., products and processes) is critical in the utilization of
knowledge-based systems in design.
The goals of this research are the enhancement of architectural flexibility and generative
capabilities in design environments. Both goals are largely influenced by the knowledge
represented in design environments. Architectural flexibility pertains to the compositional
diversity required when using this stored knowledge to address the design of different
space and building types. Generative capabilities pertain to the application of design
processes to propose possible solutions, that add to the explication of the problems we are
facing.
The problems of this research pertain to the level and type of decomposition that is applied
on the concepts of architectural design, representation of these concepts, and their
utilization in knowledge-based design systems.
To enhance the flexibility and generation capabilities of design environments, the research
proposes the aggregation of space functions to the set of human activities that will be

ABSTRACT 2
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
performed in them. This functional decomposition provides the basis for refining,
adapting, and creating new space types from existing knowledge about human activities.
Consequently, building types can be refined, adapted, and created from their functional
aggregates (i.e., spaces).
The contributions of this research are based on the ability to represent, manipulate, and
create space functions. Consequently, it is possible to describe and manipulate different
building types. which achieve the goals of this research. Those contributions are
theoretically grounded on cognitive and AI-based design research, and technically
examined through the design and implementation of a knowledge-based experimental
design environment (APE-1), that is intended to support architects in an early stage of
design (i.e., architectural programming).

3
INTRODUCTION
Over the last thirty years there has been growing attention from the general public and
ongoing research in the academic community for applying computational aids to different
aspects of architectural design. In general, the objective of such research efforts is to
shorten the duration of the design cycle through its different stages, to enhance the quality
and accuracy of the resultant products (i.e., documents and designed artifacts), at the same
time to communicate information among the professionals involved in the design through
its life cycle, and most importantly to support and improve the performance of decision
makers.
The word design is generally overloaded with different meanings. It can be interpreted as
the products or the processes of design. As a product, the word design can be understood
as: the representation of an object being designed (e.g., drawing, or model of a building),
and; the designed object after being realized or constructed (e.g., the building itself). As a
process, the word design can be understood as: the phases or steps taken to produce the
representation of the designed object (e.g., analysis, synthesis, and evaluation); or the
intellectual activity of a designer to produce those representations of a designed object
(i.e., design thinking).
The focus of research in computer-aided architectural design has moved back and forth
between supporting design processes and representing its products. This is evident from
attempts to automate the entire design process to partially supporting representation of its
products (e.g., drawings) through drafting tools, from representing design information to
modeling its appearance and visualizing its form (e.g., 3-D modeling, virtual reality), and
from synthesizing design solutions to evaluating different aspects of their performance.

INTRODUCTION 4
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
In general, computer-aided architectural design (CAAD) has come to have two different
meanings: (1) usage as a drafting/modeling tool; and, (2) usage as a design medium (Gero
1985). Distinction between the two depends on our understanding of the kind of aid or
assistance required when designing. Using computers as drafting tools and for
visualization purposes, although useful in the mechanics of producing drawings and in
visualizing and understanding the designed artifact, does not support the decision-making
process of the designer.
Decision-making is based on reasoning, and any form of reasoning requires the application
of knowledge (Cellier and Lopez 1995). Designers reason with knowledge about real
world objects (e.g., walls, spaces, and buildings) and their relationships within a richly
laden context (e.g., location and culture). Using computers as a design medium requires
the application of similar knowledge for reasoning purposes. Different types of knowledge
(e.g., objects, events, performance, processes) need to be represented in computational
design systems to provide meaningful support to the designer’s decision-making
capabilities. On the other hand, drafting aids rely mainly on primitive representations of
designed objects (e.g., points, lines, polygons, and primitive geometric solids) that do not
contain the necessary information and knowledge for designers or systems to reason
about. Such rich representations are utilized in knowledge-based systems (KBS), is a sub-
field of Artificial Intelligence (AI) that provides a more suitable design medium for
supporting decision-making.
AI is a field of research and applications that can be characterized by attempts to simulate
different forms of human intelligence in a computational medium. However, there are
debates (Bobrow and Hayes 1985) on its classification as a science, or as a technology.
• As a science, AI is essentially concerned with thinking (i.e., a part of Cognitive
Science), with its focus on theories of intelligence and its application to test the
validity of cognitive hypotheses.
• As a technology, AI is essentially concerned with acting, or applying computational
techniques (e.g., heuristic search, or representation methods) that distinguish it from
others in computer science.
AI-based design research is a recent field of investigation that started in the early 1980s.
AI-based design research has taken two similar directions cognitive modeling and
intelligent systems, and a third research orientation that is shared between those two

INTRODUCTION 5
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
directions, namely representation and reasoning. Based on the literature (Smithers 1989,
Coyne et al. 1990, Tham and Gero 1992, Gorti and Sriram 1994) these approaches can be
delineated as:
• Cognitive modeling which is concerned with developing better models of the design
process, and how these models can be applied in computer-based systems to support
designers. This line of research is focused on: the cognitive processes in the minds of
the designers during design; and, the types and sources of knowledge used during
design, and how they are utilized.
• Intelligent systems which attempt to find mechanisms that can perform intelligent tasks
effectively without concerns of how closely they mirror human performance or
cognition. This line of research studies the interaction and coupling of different
reasoning systems (including human designers), which cooperatively try to solve
complex design problems spanning different knowledge domains. In addition, this line
of research can also be seen as attempts to represent and express current models of
the design process in a particular organization of sub-systems.
• Representation and reasoning research is concerned with the development of
techniques for representing and reasoning about design knowledge in ways that can be
used to support different types of design (e.g., routine and non-routine). Within this
line of research different contributions here emphasized: proposals for further
techniques; development of knowledge-based tools that improve the capabilities of
conventional CAD design techniques; and, the development of representations that
expand the reasoning capabilities of design decision support systems.
Research Orientation
This research is concerned with the application of AI techniques as a technology, within
the problem context of knowledge-based design environments, with specific focus on
knowledge representation and reasoning in those systems.
Different types of knowledge are represented in design systems such that reasoning1 can
take place. These representations can generally be described as: (1) representations that
model the context of the design problem and the components from which solutions may be
composed; and, (2) representations of the processes or actions on the design problem
description that transform the problem to a more favorable state. This research focuses
mainly on the representations that model the current design problem, and the components
from which solutions may be composed.
1 Reasoning is the ability to infer new information from existing information (Akin 1982).

INTRODUCTION 6
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
Goals
Generally, a multitude of diverse knowledge is required in a design system due to the
evolving and diverse nature of developing design products and the distinct processes
acting on them. Knowledge-based design systems require the integration of varied
knowledge structures, reasoning mechanisms, and representation techniques to achieve a
degree of flexibility in handling design problems. According to Gorti and Sriram (1994),
the limited success of knowledge-based design systems can be attributed to their lack of
flexibility. Galle (1995), has viewed flexibility in design systems as their capability to deal
with:
• Architectural flexibility: the system should support a broad range of building types,
styles, and construction technologies.
• Life-cycle flexibility: the system should support different phases required for the
creation of a building (i.e., programming, conceptual, and detailed design).
• User and task flexibility: the system should support various operations of different
professionals in the process of creating a building (e.g., architectural, structural,
mechanical, etc.).
The goals of this research pertain to the enhancement of architectural flexibility and
generative capabilities in architectural knowledge-based design systems. Architectural
flexibility within the focus of this research can be defined as the ability to address the
design of many building types. Generative capabilities are defined as the ability to propose
suitable design components that achieve a desired performance, within a given context.
These two goals are complementary in their objectives. Architectural flexibility addresses
the system’s abilities (including those of the designer) to compose and structure the
problems of a design situation, while generative capabilities address the utilization of
design processes that act on those problem structures with the goal of proposing a
solution.
Problems
The research goals bring many issues into consideration, such as: the role and importance
of prior knowledge in design; the content and organization of such prior knowledge in

INTRODUCTION 7
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
design systems; design problems and how they are explicated; and, knowledge-based
design techniques and problem solving processes in design system.
• Prior knowledge plays an important role in architectural design, especially in the early
stages of the design process. Justifications of using prior knowledge in the design
process have their foundations based on: cognitive necessity (Schank 1982);
observations of architects at work (Schon 1988, Darke 1984, Lawson 1984);
postulations on their practicality and their actual use (Colquhoun 1972, Archea 1987);
and, praxis as a method for developing possible design solutions (Lang 1987). Prior
knowledge brings the initial concepts into the consideration of the designers, from
which they proceed to examine the goals and constraints that need to be achieved in a
design description. From this viewpoint the critical selection of the prior knowledge
that initiates the design process is of particular importance in the context of
knowledge-based design environments.
• The content of knowledge in design systems is largely based on the decomposition of
parts that resemble different components of the building. Decomposition denotes the
action of dividing a composed whole into its constituent parts. It is an abstraction
technique that is used in the analysis and synthesis of design solutions. For each
representation of the decomposed parts, different aspects are described (e.g., formal
and behavioral attributes).
The organization of this knowledge is cognitively based on memory structures such as
Rumelhart’s (1980) cognitive schema. In architectural design the organization is
conceptually similar to ‘types’ as generalizations (i.e., functional types), and
specializations (i.e., reference types) (Schon 1988); in computer science Minsky’s
(1975) frames; in computational design prototypes (Gero et al. 1988) and design cases
(Kolodner 1993). The content and organization concepts of design objects bring more
information to the problem under consideration as generalizations and as
specializations of design solutions.
• Design problems have been described as ‘ill-structured’ (Simon 1984) and as ‘wicked
problems’ (Rittel and Webber 1984). Such a description is based mainly on the
incompleteness of design problems at the beginning of the design process. A great deal
of a problem’s solution is based on our understanding of the problem itself. Such an
understanding is mainly achieved by what we already know (i.e., prior knowledge).
Our prior knowledge brings more information to the problem. In design, problems are
defined as a set of constraints, and the problem solver is required to devise a concrete
artifact that solves the constraint problem (Kolodner 1993).
The incompleteness of design problems (Rittel and Webber 1984) at the beginning of
the design process, requires an exploratory behavior on behalf of the designer and the
supporting system, to uncover the requirements (i.e., constraints) of the current
problem. By doing so, propositions, evaluations or modifications of the current design
state description are made possible. In other words, a great deal of the problem facing
the designer and the system is foreseeing the overall required characteristics (or
constraints) of the building (i.e., problem) being designed.
• The processes enacted upon the representation of a design can generally be described
as non-routine and routine design processes. Non-routine design processes include the
adaptation and creation of design prototypes, in which the components of the

INTRODUCTION 8
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
prototype are manipulated. Non-routine design tasks apply mainly to the components
constituting a design prototype, when existing prototypes and cases do not conform
with the goal of the designer. On the other hand, routine design processes are based on
the refinement of attribute values so that different components of a design prototype
achieve a given goal in a certain context.
Flexibility and generative qualities are dependent on the system’s resources, especially, its
data store. A data store is a library of product information (i.e., prototypes and cases) that
is used to retrieve and modify relevant information in compliance with the context of a
current design problem.
Architectural flexibility pertains to the utilization of the system’s prior knowledge to
support the composition of new building prototypes that do not exist in the system’s
knowledge base (i.e., to support non-routine design).
Generative capability pertains to the derivation of constraints and the proposition of
suitable parts and attributes that achieve the desired performance. In other words, the
generation of design characteristics is possible when the problem is well-defined through
constraints, and when there is knowledge about the implications of those constraints on
the different elements of the design.
Typically, architectural knowledge about certain building designs has been grouped and
classified according to the type of building and its component spaces. Following the same
line of thought, knowledge-based design environments have also used the same
classification (building and space types) to organize and utilize the portion of design
knowledge, that is related to predicting and evaluating the performance of a design. This
classification and grouping of characteristics has its advantages in describing the "model"
of the end-product and its associations with the activities that are typically performed
inside the end-product.
The knowledge represented in the data store is largely based on the plan used to
decompose the concepts of a problem domain (e.g., architectural design). This
decomposition brings the content and organization of knowledge into operation with the
processes that transform the design state.
The decomposition plan is generally based on a structural decomposition of the building
components (e.g., wall, door, space). In this respect the decomposition facilitates the

INTRODUCTION 9
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
proposition of suitable parts that may constitute a design solution in a given context, and
provides the basis for evaluating this solution’s performance, provided that the design
constraints of the building’s part involved are previously known. In such a case, the
constraints of a design are typically stored within the description of different design
objects (e.g., spaces). For example, in the case of a house building type, the constraints
(e.g., noise level, orientation) for each typical component space in a house (e.g., bedroom,
kitchen, livingroom) are compiled within their representation. This leads to the fixation of
these constraints or requirements for each space type applicable to the building type (e.g.,
house).
This research argues firstly, that these generalized constraints based on space types rarely
comply with the needs of the client, or the occupants of these spaces. Secondly,
compiling those constraints at a space level of description prohibits the creation of new
space types from existing stored knowledge in the system. Creating new space types from
the existing information in the system is essential to the creation of new building types,
which is the main goal of this research.
Constraints are based on the function or goal to be achieved from a space. A function of
an artifact or a design object is the relation between a goal of a human user and the
behavior of the system (Bobrow, 1989:2). In this case the ‘system’ is the space being
designed. A function is the constraint on a design object’s required properties or behavior
(Chandrasekaran 1990).
This research argues for a function decomposition: to facilitate the composition of new
functions from existing knowledge in design systems; and to explicate the ‘needs’ or
‘goals’ to be achieved by a space at an early design stage.
What is needed to complement the structurally-based components of a data store is a
representation that describes the function or goals to be achieved by a space that is as
independent as possible from the precompiled set of constraints bound to the space type.
In addition, the required representation has to be common in its presence across many
space and building types, and effective in its implications on the design elements
constituting spaces.

INTRODUCTION 10
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
Propositions
This research proposes the representation and utilization of space user activities to
describe the functions of architectural spaces in knowledge-based design environments, in
addition to the information classified on the basis of whole/parts (e.g., space, wall, door,
etc.). The propositions of this research are the answers to three questions:
1. WHY SHOULD ACTIVITIES BE USED?
Activities are major building blocks of a space design solution. Therefore, activities
should be used in determining the characteristics of a space description. To enhance the
efficiency of data stores such that multiple building types can be composed from existing
information, the research argues that data stores should be capable of supporting the
composition of new space types, which form the major building blocks of multiple
buildings. To produce new spaces, the structural decomposition of a space is typically
known. What is not readily available is a criterion based on the function of a space that
constrains the attributes of those space elements. Secondly, are the criteria that bind a
space to its surrounding context. Such constraints and criteria can be attributed to the
activities that are present in an architectural space and should represent the function of the
space.
2. HOW CAN ACTIVITIES BE REPRESENTED?
Activities are universal in character for a homogenous group of people. Therefore
activities can be structured using memory-based representation techniques (i.e., as
generalizations or prototypes, and as specializations or cases). By including activities in
the semantic classes that constitute the data store of a design environment, the research
postulates that design systems can achieve a degree of flexibility in composing different
space types and thus different building types. Generation of a space’s characteristics is
dependent on the constraints to be taken into consideration, and the processes that can
fulfill those constraints by selecting and modifying the elements of the space that conform
to the constraints.

INTRODUCTION 11
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
3. HOW CAN ACTIVITIES BE USED?
Activities can be regarded as aggregates of a space function. Since architectural spaces
are designed to provide a habitable environment for a known group of people performing
a set of known activities. The proposed approach is a combination of structural
decomposition complemented with a decomposition of function at the space level (Fig. 0.1
) where new building types evolve from functionally derived space types. This description
of function is utilized to derive the constraints that describe the requirements of a space,
thus providing the means to explicate the constraints problem and the means for proposing
possible solution.
Building Type Space Types Components Types
A
B
C
Functions of Space
Constraints
Modified
Constraints
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
A
A
A
A
A
Constraints
AAAA
AAAA
AAAA
AAAA
AAAA
A
A
A
A
A
Building Instance
Other
building
types
Other space types
1
2
3
n
AAAA
AAAA
AAAA
AAAA
A'
B
C
AAAA
AAAA
AAAA
AAAA
A'
X
C
AAAA
AAAA
AAAA
AAAA
A'
X
Y
A
A
A
AAAA
AAAA
AAAA
AAAA
F
A
A
A
A
A
F
A
A
AAAA
AAAA
AAAA
AAAA
F A
A
A
A
A
F
A
A
A
A
A
F
F
AAAA
AAAA
AAAA
AAAA
Constraints
Constraints
Constraints
Adapted building prototype
Created building prototype
The function of space provide
the constraints that will
determine the parameters and
component elements
A typical function
of a space type
An adapted
function of a
space type
space type
A building type is composed of
a set of space types
A building inst. is refined to
conform with the internal and
external constraints
Space types are the
aggregates of a building type
The modified function of a
space provide new constraints
that will alter previous
parameters and components
An adapted
space type
Space types are customized to
fit additional needs of their
occupants
A new function of a space will
provide the constraints of a
new space type
A new function is
created from
previously known
activities
The aggregates of a building
type has changed
New spaces compose new
building types
New functions define the
constraints of new spaces
Known activities
compose different
functions of spaces
Refined building prototype
components
Figure 0.1: Utilizing functional and structural decomposition of a space to
compose and generate new building prototypes and instances

INTRODUCTION 12
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
Hypothesis
This research postulates that the representation and utilization of space occupants
activities in knowledge-based design systems is beneficial in improving the information
represented in design environments to: achieve a degree of architectural flexibility in the
composition of original space and building types that did not exist in the data stores of a
the design system; enhances the exploration of alternative solutions by defining and
propagating constraints that explicate the requirements of an acceptable solution.
Methodology
The goals of this research are pursued within the context of the following objectives:
1. To explicate the content of an activity representation, and its relationships with the
description of a space.
2. To suggest suitable mechanisms for organizing activity information in compatibility
with other related information.
3. To describe how activity representation can be utilized in deriving space descriptions.
4. To implement the suggested activity representation and test its utility in an
experimental design environment.
5. To assess the utilities and problems that arise from the representation.
The scope of this research investigates the use of activities in the programming stage of
the design, and within this stage the research addresses its implications on space
description. Activities are used to compose and generate a description of an architectural
space in the programming stage of design, (i.e., produce a description of courser
granularity objects from finer granularity objects).
The expected contributions of this research are within knowledge representation and
reasoning to support routine and non-routine design tasks at an early stage of the design
process. These contributions are theoretically grounded on cognitive and AI-based design
research, and technically examined through the design and implementation of a
knowledge-based experimental design environment (APE-1), that is intended to support
architects in the early design stage(i.e., architectural programming). Specifically, the
contributions of this research are centered on:
1. the propositions and their projected utility;

INTRODUCTION 13
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
2. the design and implementation of the representation;
3. the utilization of the representation in different scenarios;
4. the assessment of the advantages and disadvantages of the propositions; and,
5. the validation of the propositions and their utility.
Thesis Organization
The thesis is divided into six chapters, from which the first two chapters are dedicated to
literature reviews on computational design and linkage to AI.
The goal of Chapter 1 is to establish background information regarding the relationship
between AI and architectural design in the field of computer-aided architectural design
(CAAD). It is divided into two sections: The first section, discusses the nature of design
through the problems facing designers and the reasons behind their complexity, and the
role played by designers’ experience and their strategies to subdue this complexity. The
second section reviews several design models that evolved in the past three decades and
distinguishes those pertaining to computational design.
The goal of Chapter 2 is to introduce the concepts to be used in describing the context of
the research problem that is, AI-based design systems. It is divided into two sections. The
first section, overviews fundamental issues of artificial intelligence through, its major
hypotheses and the different views pertaining to AI as a field of inquiry and application,
and the orientation of this research. The second section, focuses on experience and prior
knowledge representation as the link that binds the intellectual faculties of designers with
the intelligent support required from computer-based programs.
The goal of Chapter 3 is to state the goals and objectives of this research. It describes the
context of the problem, states the problem, and then proposes the contribution of this
research study. It is divided into two major sections. The first section, describes the
context of the problem through an overview of design environments, their required
features, and their components. On this basis, the research identifies the goals from the
required features, and selects the design environment’s component that is responsible for
achieving the goals. The second section, establishes the problems pertaining to the goals,

INTRODUCTION 14
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
lists a set of solution objectives, suggests propositions, and defines the scope of the
research.
The goal of Chapter 4 is to explicate the problems and propositions of this research. It is
divided into four sections. The first section, discusses the content of information in data
stores and some of its deficiencies as viewed by the research and found in literature, and
proposes a type of information that overcomes those deficiencies. The second section,
discusses the organization concepts of information in data stores, and its feasibility to the
proposed information. The third section, reviews design techniques using knowledge-
based concepts, and the relevancy of the proposed information to these techniques. The
fourth section, summarizes the problems and states scope of using the researches
propositions.
The goal of Chapter 5 is to describe an experimental implementation that demonstrates the
concepts and propositions of the research. The objectives of this implementation are: (1)
to model the research propositions; (2) to experiment with the implications and usage of
the proposed representation; and, (3) to exhibit the possible utility of the proposed
representation. Chapter 5, is divided into three sections. The first section: outlines the
stage of design intended for the implementation; outlines the general features of the
experimental system (APE-1); and, illustrates the utilization of APE-1 through a
hypothetical scenario that requires flexibility in using the system’s knowledge. The second
section, outlines the framework that is used to describe the implementation. The third
section, describes the implementation design through the description of the development
environment, and implementation architecture.
Chapter 6, contains the conclusions of the thesis.

15
CHAPTER 1
DESIGN AND COMPUTATION
The goal of the following review is to establish the relationship between AI and
architectural design in the field of computer-aided architectural design (CAAD).
This chapter is divided into two Sections. The first Section, discusses the nature of design
through the problems facing designers and the reasons behind their complexity, and the
role played by designers’ experience and their strategies to subdue this complexity. The
second Section reviews several design models that evolved in the past three decades and
distinguishes those pertaining to computational design.
1.1 Nature of Design
There are many different approaches and attempts to define design in general, and
architectural design in particular, but design has long resisted such a definition, because of
its unpredictable and intangible character, marked by moments of insight, imagination and
"flights of fancy" (Ledewitz 1985). However, any attempt to research and study design,
should either provide a fresh understanding, or present its particular characterization of
design. This research will present its understanding viewpoint of design that facilitates the
formalization of meaningful assistance within a computational environment.
The word ‘design’ is ambiguous and can be ascribed several meanings: the designed
artifact or object; the set of instructions or description necessary to produce the artifact;
the act of designing on behalf of the designer; and, lastly the mental or cognitive processes
of the designer (Lansdown 1985:120). Although design may mean all those things
combined, this research is mainly concerned with the set of instructions and steps

CHAPTER 1 16
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
necessary to transform an incomplete set of information regarding the required artifact
(e.g., building, space) to a desired state which satisfies some predefined design constraints.
Simon (1968) has described design in the most general sense as an intellectual activity or
intelligent behavior on behalf of the designer or being to change an existing situation or
environment into a preferred one. Intelligence can be ascribed to everyone who devises
courses of action aimed at changing existing situations into preferred ones, whether these
activities produce an artifact (in the case of an architect or an engineer), or prescribes
remedies for a sick patient, or devises a new sales plan for a company. He construed
design as the core of all professional training and the mark that distinguishes between the
sciences and professions. Architectural design is considered an area of human experience,
skill and understanding that reflects man's concern with the material culture, and with
making and doing; that is with appreciation and adaptation of his surroundings in the light
of his material and spiritual needs. In particular, though not exclusively, it involves
configuration, composition, meaning, value and purpose in man made phenomena (Olsen
1989).
Simon’s definition points out the issues to discuss about the nature of design, from the
human standpoint and from the environment and/or artifacts standpoint. The first
addresses the human capabilities and limitation within issues such as, problem solving,
experience, and information handling and manipulation. While, the second provide insights
on the nature of the problems addressed during deign.
1.1.1 Design Problems
The following will review the characteristics of problems in general, and discusses what
makes architectural design problems especially difficult to handle.
A problem consists of three components: the given state, the goal state, and the obstacles
that block the movement from the given state to the goal state (Mayer 1989:39-40). An
implication of the above definition is that the problem exists relative to the problem solver.
This indicates the significance of experience in every problem domain, since experienced
humans tend to solve complicated problems within their area of expertise.

CHAPTER 1 17
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
Problem solving can be broadly defined as a cognitive process that is directed toward
solving a problem. The definition has three components as stated by Mayer (1983): (1) A
cognitive act that occurs in the mind or cognitive system. (2) A process in that operators
are applied to knowledge in memory to transform the state of the problem. (3) A goal
directed cognitive activity which has a target to be satisfied.
1.1.11 Distinction Between Problems
There are distinctions between problems in general (not only in design), such as well-
defined and ill-defined problems. Well-defined problems have a clearly specified given
state, goal state, and the operators that may be applied to the problem states. An ill-
defined problem lacks a clear specification of one or more of the components of the
problem (i.e., given state, goal state, and the operators). Another distinction can be made
between routine and non-routine problems.
According to Mayer (1989), routine problems are familiar problems that, although not
eliciting an automatic memorized answer, can be solved by applying a well known
procedure. In such problems the problem solver does not know the answer, but he does
know how to arrive at an answer. Non-routine problems on the contrary, are unfamiliar
problems for which the problem solver does not have a well-know solution procedure and
must generate a novel procedure. He related that Gestalt psychologists have pointed out
that routine problems require ‘reproductive thinking’ (i.e., applying already known
solution procedures to the initial problem state), while non-routine problems require
‘productive thinking’ (i.e., generating a creative or novel procedure.)
Several categories of problems, other than the above mentioned distinctions, are also
treated in the literature. These are concerned with non-adversary problems2, 3:
2 Adversary problems involve competition between two problem solvers, such as a game of chess.
Nonadversary problems do not involve competition, such as curing a disease and designing.
3 In transformation problems an initial state is given and the problem solver must determine the proper
sequence of operators to apply in order to transform the given state through a series of mid states into the
goal state. In arrangement problems all the elements of the problem are given and the problem solver
must determine how to organize the givens to saticfy the goal. In induction problems a series of instances
is given and the problem solver ust induce the a rule or pattern that describes the structure of the problem.
In deduction problems premises are given and the problem solver must apply the appropriate rules to draw

CHAPTER 1 18
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
transformation problems, arrangement problems, induction problems, deduction problems,
and divergent problems.
1.1.12 Characteristics Of Design Problems
In design, the identification of the problem’s structure is in itself a serious problem. Design
problems are immense in terms of the number of variables that must be determined. The
functional, logical or aesthetic relationships that must be satisfied between the variables
are dense (Eastman 1982:246).
1.1.12.1 General
Several characteristics pertain to design problems and stem from the nature of the
designed artifacts. Their features generally include: they contain other problems; their
definition is incomplete; the solution of the problem is inseparable from the problem itself;
changing the current state of the problem often highlights unforeseen criteria and
relationships to the attention of the problem solver; sub-parts of a problem usually serve
many purposes (i.e., design decisions may have results other than those intended, and
therefore different criteria4 often guide design decisions); and they have no inherent
structure (i.e., the problem acquires a structure during solution). The evolving problem
structure reflects the designer’s understanding of the functional dependencies within the
problem (Logan 1985). Such characteristics are marks of the ill-defined nature of
architectural design.
1.1.12.2 Wicked-Problems Of Design
Furthermore, Rittel and Webber (1984) have asserted that planning problems are
inherently different from the problems that scientists and perhaps some classes of
engineers deal with. They termed these problems as ‘wicked’ problems (i.e., extremely ill-
defined) and signified the properties associated with wicked problems as:
a conclusion. In divergent problems—the problem solver is given some situation and asked to generate as
many possible solutions as possible (Mayer 1989).
4 Many considerations are accounted for during design (e.g., user needs, climatic conditions, owners
expectations, structural system, lighting conditions, acoustics, etc.) each of which influence one another
(Myers et al. 1991).

CHAPTER 1 19
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
1. Problem definition is incomplete, due to sub-problems and the inseparability of the
sub-problems from a solution to that problem. No understanding of the problem is
possible without understanding the context and the solution concept to the problem.
2. Problem solutions have no stopping rules to end the improvement of the evolving
design. There are no criteria to indicate that a solution has been reached, since the
process of solving is the same for understanding the problem as in (1). The designer
stops according to external constraints to the problem (such as running out of time, or
money, or patience).
3. Problem solution are good or bad (i.e., not true or false assessments of a solution),
typically based on subjective judgment. A good solution for one group of persons
might be a bad solution for another, (i.e., rarely, if at all does there exist a standard
that everyone will agree upon). This characteristic stem from the fact that an
evaluation or assessment of a problem solution is built upon an understanding of the
problem and its context which in itself is based on a preconceived concept of a
solution as in (1).
4. Problem solutions have no immediate and no ultimate test, nor one can clearly define
the universe over which the problem solution has effects, and consequently one cannot
evaluate those effects and compare them to the objectives of the design. In wicked-
problems the universe of effects is not completely defined, due to the composite nature
of the designed objects and the rich relationships that exist between the parts of the
problem. It seems almost impossible to follow the side effects of a projected solution
over the universe of aspects to be affected.
5. Problem solutions are very costly to experiment with, and usually it is a one chance
operation to avoid paying a high price. Faulty solutions to wicked-problems results in
complicating the original problem and propagating new problems, (i.e., faulty solutions
leave traces that cannot be undone and which are in themselves wicked-problems) and
every attempt to correct or to reverse previous mistakes, faces the same dilemma.
6. Problems have an innumerable set of potential solutions. There is no well-described set
of permissible operations that may be incorporated into the plan. Because they are not
completely defined as in (1), we can never be sure that we have enumerated or listed
all the possible potential solutions. Accordingly, we can never be sure that we have
selected the right solution to implement.
7. Each problem is unique. In tame problems we can define classes of problems that share
essential characteristics, and we can also define solution types that solve a certain class
of problems. In wicked-problems, classes of problems do not that share solution types
despite their similarities. This can be attributed mainly to the contextual influences
acting on these problems.
8. Every problem can be considered to be a symptom of another problem. If problems
were to be described as inconsistencies between how things are and how they ought to
be, problem solving would consist of determining the cause of the inconsistencies and
later in finding a process to eliminate them. In wicked-problems the removal of cause
generally poses another problem of which the original problem is a symptom. This new
problem is a higher level problem. This characteristic of wicked problems can be
attributed to the relationships between problems, and the level of granularity at which
we are trying to solve the problem. The level at which we are trying to solve the
problem is essentially related to how the problem was decomposed in order to solve it.

CHAPTER 1 20
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
9. The choice of explanation determines the nature of the problem’s resolution.
Generally, there are many causes that one can think of that explain the discrepancy that
generates the problem. The choice of one cause will determine a set of actions to
eliminate that discrepancy different from the actions determined by the choice of some
other cause. In other words, how we understand the problem will influence the way
we deal with it. This characteristic highlights the subjectivity of the problem solver and
the influence of his/her experience in removing those discrepancies.
10. The planner has no right to be wrong. In science, solutions to problems are only
hypotheses offered for a refutation. This is based on the insight that there are no
proofs to hypotheses, only potential refutations. The more a hypothesis withstands
attempts to refute it, the better its acceptance is considered to be. Consequently, the
scientific community does not blame its members for hypotheses that are later refuted.
On the other hand, planner are liable for the consequences of their actions, since their
actions influence the lives of other people.
Most of the problems listed above stem from the first property, that the definition of the
problem is incomplete. This leads to an exploratory behavior on behalf of the designer, in
which, partial solution are suggested according to the designer’s understanding of the
problem. By doing so, other parts of the problem becomes apparent, which may lead to
generating another solution, or modifying the current solution state. That is to say, a great
deal of the problem lies within foreseeing the overall characteristics of the designed
artifacts or objects.
1.1.13 Design Artifacts
The task of designer’s is to create and/or predict a specification of an artifact (i.e.,
object/system), given a set of functional requirements to be achieved in a given
environment. Designers search and select from their previous experience and knowledge
of the most promising concepts that would fulfill these functions, according to their
judgment. Judgment of such concepts are mainly subjective since, problems and their
solution are almost inseparable.
Artifacts are the end product of a design (e.g., building), they are supposed to meet and
fulfill the objectives that they were constructed for. A characteristic of these artifacts is
complexity, which prevents designers from judging and anticipating all concepts in detail
(MacCallum and Duffy 1987).

CHAPTER 1 21
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
The complexity of design artifacts, stem from two factors that are innate to these objects.
First is their composite nature, and second is the relationships that exist between the parts,
and between the parts and their effects on performance.
1.1.13.1 Composite Nature Of Design Artifacts
Composite objects, such as a building comprise other systems of objects. Each of the sub-
component objects have its own set of characteristics, which is different from that of its
parent. The collective characteristics of the components, whether they are simple objects
or systems of objects, govern the overall performance of the design. Characteristics of the
component objects cannot be considered in isolation from one another as they are
interrelated in different ways.
1.1.13.2 Relationships In Design Artifacts
Design relationships reflect the physics of a component, the objectives of the component
and the limitations on the acceptable design (Colburn and Rinderle 1990). Relationships
are considered the major reason for the complexity of design problems, since the
prediction of a suitable concept is dependent on an understanding of these relationships.
There are as many types of relationships as there are many problems, that exist within
designed objects. Two general classes of relationships facilitate the prediction of the
design artifact, namely form-function relationships and constraints relationships.
• Form-function or parameterized relationships5 relates the characteristics or behaviors
of a certain object to the form and function of this object. For example, the
relationship between the thickness (i.e., form or structural parameter) of a solid
masonry wall and one of its expected behaviors (e.g., long term thermal retention) and
its usefulness in the built environment (e.g., slow thermal transfer).
5 The notion of a parametrized relation this is based on Gero’s et al. (1988) and Coyne’s et al. (1990)
notion of design protoypes, in which the later refer the basis of their view (in design computation) on the
following references: Aikins, J. S. (1979). Prototypes and the production of rules: an approach to
knowledge representation for hypothesis formulation, [IJCAI-79, Tokyo, Japan]. Bobrow, D. G., T.
Winograd (1977). Experience with KRL-0, one cycle of a knowledge representation language, [IJCAI-77,
Cambridge, Massachusetts]. Osherson, D. N., E. E. Smith (1981) On the adequacy of prototype theory as
a theory of concepts, Cognition 9(1) (pp. 35-58).

CHAPTER 1 22
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
• A constraint relationship6 on the other hand limits possible solutions to a certain set
or a group of possible objects from which we can choose. A constraint is a conceptual
idea about a design and the expression of a necessary property it must satisfy (Yoon
1992), such as the relationship between the overall cost of a building and the
construction system and the finishing materials that are to be used.
According to Sapossnek (1991), there is a debate regarding which class of relationships is
more suitable for implementation in computational environments. Others view
parameterized relationships or form-function relationships as a subset of the latter, since
functions are constraints on the behavior or properties of an artifact, however,
Chandrasekaran (1990) states that it is useful to distinguish between functions and other
constraints, since functions are the primary reason that an artifact or a device is desired.
Both relationships are used during the design process since, in the early stages of design
where there are the least details, designers use only the parameters that have the greatest
influence on the overall design performance. In later stages the designer operates within
the constraints of previously defined parameters (MacCallum and Duffy 1987).
Many researchers7 agree that those classes of relationships are the basis for the two
approaches to computational design models as will be reviewed in (1.2.5 Computational
Models Of Design). In both approaches a search is conducted to find a promising solution.
In the first approach which is termed data-oriented, the search process itself shapes the
criteria by which the solution is judged. This approach relies on precedents, symbols, and
metaphors for guidance (Archea 1987). The second approach is termed goal-oriented, and
assumes that the characteristics of the desired solution (in terms of its objectives and
constraints) can be formulated independently and prior to engaging in the process of
seeking a solution that meets them (Gross et al. 1987).
6 The notion of a constraint-based relation this is based on Simon’s (1968) view of design as a constraint
satisfying process, Gross et al. (1987a) refer to several references as the basis to their work (in design
computation), namely: Friedman, G. J., C. Leondes (1969) Constraint Theory, Parts I, II, III. IEEE
Transactions on Systems Science & Cybernetics Vol. SSC-5(1, 2, and 3). Sussman, G. J., G. L. Steele
(1980) CONSTRAINTS–A language for expressing almost-hierarical descriptions, Artificial Intelligence
14(1) (pp. 1-39). Gross, M. (1985). Design as Exploring Constraints'; [Doctoral Dissertation, MIT] MIT:
Cambridge, MA.
7 Such as (Majkowski and Kalay 1987, Colburn and Rinderle 1990, Coyne et al. 1990; Kalay et al. 1990,
Sapossnek 1991, Carrara et al. 1992).

CHAPTER 1 23
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
1.1.2 Design Experience
There are several opinions about the expertise of the architect as reviewed in (Akin
1988b). Some attribute the architect’s expertise to his skill for representation, others see
expertise in terms of prescriptive methodologies, yet others strive to explain expertise
within the framework of information processing. A great deal of this expertise is evident
especially in the early stages of design, in which operations are most difficult to describe
with any degree of precision.
1.1.21 Empirical Studies
Several studies have been conducted aiming to reveal how architects solve their problems.
These studies are typically based on methods adapted from psychology and cognitive
science, which have their limitations in studying what goes on in somebody’s head (e.g.,
introspection), however, they provide very rich data that carry reflections of real-world
designing (Cross 1984). Based on several experiments found in literature, the following
text attempts to point out the main features that distinguish architects’ expertise and the
ways in which architects solve problems.
• Framing to reduce variations: After conducting interviews with several architects who
had designed various housing schemes, Darke (1984) pointed out that architects do
not start designing by listing all the constraints, but instead they impose upon
themselves a particular generating concept (i.e., framing), or identify a limited set of
objectives. This ‘primary generator’ helps the designer to bind the gap between the
problem information and a solution concept. She concluded that it is an important feat
of the design process, that designers ‘have to’ find a way to reduce the variety of
potential solutions to a small class of solutions that are cognitively manageable. The
solution class is further narrowed by proposing one particular solution concept ‘a
conjecture’ which is then tested against the requirements and the constraints of the
problem, thus contributing a fuller understanding to the problem.
It should be noted that this conclusion suggests that designers initially limit themselves to
predefined objectives and/or solutions, and then start refining. This observation also points
to the importance of previous solutions that match the conceived problem structure.

CHAPTER 1 24
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
• Reflectivity and discovery: Schon (1983), and Schon and Wiggins (1992) describe
architectural designing as a kind of experimentation, that consists of a reflective
‘conversation’ with the materials of a design situation. Due to the complex nature of
the problems designers face, there are more variables8 than can be represented in a
finite model. He considers design as an interaction of making and seeing, doing and
discovering. In the references mentioned above (which are based on protocol analysis),
he explained that because of the problem’s complexity, the designer’s ‘moves9’ tend to
produce consequences other than those intended. When this happens, the designer may
take account of the unintended changes he/she has made in the situation by forming
new appreciation and understanding by making new ‘moves’. In other words, the
designer shapes the situation according to his initial appreciation of it, he ‘see’ the
consequences of his making and responds to it, and then again assesses what was done
(seeing-moving-seeing).
Issues arising from the collective studies of Schon and Wiggins, point mainly to the
subjectivity of designers, when they reason within different normative design domains10.
Other, is the importance of the representations (i.e., drawings, 3D models) which
designers are dealing with within some medium (e.g., paper, computer), since these
representations convey information and are the objects that designers manipulate to obtain
a better understanding of the problem/solution.
• Solution oriented: Lawson (1984) experimented with two groups (fifth year of
architectural students and fifth year science students). The objective of the experiment
was to investigate the cognitive strategies in architectural design. In his experiment he
compared the performance of the two groups, the mean performance scores of the
groups were very similar, however, their performance were very different. In his
analysis of the differences in problem-solving, he discovered that the procedures
8 Kinds of possible moves, norms or standards, and interrelationships of these.
9 A ‘move’ is a change in the configuration of the problem or the evolving solution, in which there is a
change or transformation in the configuration according to criteria.
10 Programme use, siting, building elements, organization of space, form, structure/ technology, scale,
building character, scale, cost, precedent, representation, and explanation. For more details refer to
(Schon 1983; Schon and Wiggins 1992:142).

CHAPTER 1 25
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
employed by science students were aimed at uncovering the problem structure, whilst
the procedures employed by the architecture students were aimed at generating
solutions until one is acceptable. He suggested that the strategies of the science
students were ‘problem-focused’ and for the architecture students were ‘solution-
focused’. The implications of this experiment as reported by Lawson, are that it
supported the “wicked-problems” view of design, and showed that it is not possible to
completely analyze the problem before attempting to find a solution (i.e., synthesis).
Accordingly, designers should devise methodologies that do not depend on the
completion of problem analysis before synthesis can begin.
While the previous citations supported the notion that architects’ strategies depend on
imposing upon themselves ‘a solution’ and then modifying and refining it (Darke 1984),
and on ‘generating solutions’ and selecting from them (Lawson 1984), the following
provides a perspective on the ‘general solutions’ that architects refer to when they are
working.
• Use of previous knowledge: The objective of Schon’s study (1988) was to explore
what professional practitioners ‘know’, and how they ‘reason’ in situations of
uncertainty, uniqueness, and conflict. He conducted a protocol analysis on a group of
seven designers most of them design instructors. The designers were presented with a
simple and realistic exercise to be completed in an hour or two. Schon confirmed the
utilization of types and rules by the designers, and suggested the notion of design
worlds11.
Rules are derivative constructs that enable designers to obtain new information from given
ones. Rules are derived from types, and are used in design reasoning. Designers use rules
as premises to derive conclusions. Different participants in Schon’s study made use of
different rules (some overlapped) leading them sometimes to similar conclusions, and
sometimes to different ones. Appealing to the same rules, designers made different
11 “Design worlds” are environments entered into and inhibited by designers when designing. They
contain particular configurations of things, relations and qualities, and they act as holding environments
for design knowledge.

CHAPTER 1 26
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
judgments which led to different decisions. Rules were treated as contingent and
contextual, held consciously and always allowing and admitting exceptions.
Types function as a reference for the designer, to transform a design situation to match it,
or to be transformed by the situation. Schon noted several kinds of types that were used,
which he called functional, reference, spatial gestalt, and experiential types. Types are
used to make the design situation coherent, to frame it so that the designer can reason
about it. They also provide a basis for challenging and correcting rules. In this sense types
are holding environments for contextual knowledge that is retrieved from them.
1. Functional types consist of kinds or classes of building, or physical environments, or
parts of buildings or environments. Examples include, suburban site, school, entrance,
and door. These types serve as a sources of information, that supply premises in chains
of design reasoning. That is, they are used as a generic organization of information,
which pertain to a group of similar objects.
2. Reference types are specific instances of objects. Such as, a particular building ‘Falling
Water House by Wright’. They function as a specific guide to designing, and are used
to generate or justify an ‘idea’ that triggers a sequence of ‘moves’ or provides an
example to avoid.
3. Spatial gestalt types are abstract shapes that are perceived by different designers in
different ways. They are the figures (i.e., one of the representations) that designers
reason about. These types are not explicitly invoked, but rather, designers lock on to
their configuration, then proceed implicitly to work from them.
4. Experiential types are images of experienced objects or settings in the built
environment, such as, a cave, moving from light to dark to light. These types are
usually expressed in a metaphor, such as a U-shaped entrance is inviting. They
function as generative images that supply major premise for design reasoning. It is
worth noting that designers working with these types are in a felt-path mode (i.e., they
position themselves through the space feeling what it would be like).
The importance of previous knowledge (e.g., types) and the role they play in design, have
been supported by other researchers such as:
Colquhoun (1972:394-5), argued against the significance of free intuition in
architectural design, based upon anthropological findings (Structuralist theories of
Levi-Strauss), and turned to the much maligned tradition of “building typologies” as a
source of design solutions. He defined building typologies as “.. sociospatial
organizational schemata, which through time have yielded forms appropriate for
sheltering human activities”.

CHAPTER 1 27
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
Rowe (1992) has viewed typologies as a kind12 of heuristic13 used to constrain a
problem space during design.
Pohl et al. (1994) in conformity with Gero et al. (1988) suggested that the more expert
human decision makers are, the more they tend to rely on prototypical knowledge in
the solution of complex problems. They classified prototypes based on their
knowledge content, bearing on their use in knowledge-based design environments.
Table 1.1 summarizes the classification of types according to the view of each of the
aforementioned authors.
Table 1.1: Classifications of types
Classification as a heuristic Classification derived from
empirical observations
Classification based on knowledge
content
Models
that represents characteristics
worthy of emulation
References types
which may be a particular or
kinds of buildings, which works
as rules to guide, generate, or
justify an idea
Exemplar prototypes
knowledge bases that describe a
specific instance of an artifact type or
solution
Functional types
consist of types of buildings or
physical environments, or parts
of buildings or environments,
which are used as sources of
information.
Vertical prototypes
knowledge bases that contain typical
object descriptions and relationships
for complete artifact type. (i.e.,
building type)
Elemental types
prototypes for solving general
classes of design problems
Horizontal prototypes
knowledge bases that contain typical
solutions for sub-problems (e.g.,
water proofing considerations)
Organizational types
serve as framework, reference, and rules to solve problems
Domain prototypes
knowledge bases that contain guide-
lines for developing solutions within
contributing narrow domains (e.g.,
acoustic and structural domains)
Experiential archetypes
images of experienced objects
or settings, metaphors that
function as generative images
Experiential knowledge bases
represent the factual prescriptions,
strategies and solution conventions
employed by the designer in solving
similar kinds of design problems.
Such knowledge bases are typically
rich in methods and procedures (e.g.,
a specific memorable experience.)
12 Other kinds of heuristics are; anthropometric analogies; literal analogies; environmental relations; and
formal languages.
13 Heuristics allow the application of knowledge about past solutions to related architectural problems

CHAPTER 1 28
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
Classification as a heuristic Classification derived from
empirical observations
Classification based on knowledge
content
Spatial gestalt types
the way in which designers
perceive a shape as a coherent
object with special meaning and
the reasoning that is associated
with it
Sources: (Rowe 1992), (Schon 1988), and (Pohl et al. 1994).
• Problem structuring: Two studies14 comparing architects to laymen have shown
contradicting results15. Akin (1988a) attempted to explain this apparent contradiction
by suggesting that the key is found in the term “ill-defined”, since experienced
architects know how to proceed through problem-structuring. The architect’s main
advantage is his ability to restructure the problem in ways that enable him/her to
handle complexity. This is accomplished by knowing how to decompose the problem
into simpler problems, how to resolve these simpler problems, and how to reassemble
these partial solutions into a general solution for the entire problem.
Problem structuring occur within the following design process as described by Akin
(1988a): (1) the designer describes what needs to be accomplished, and with what
elements and resources it must be accomplished (with a clear understanding of the
functions of these elements’); (2) the designer starts developing solutions or partial
solutions that begin to meet some of the requirements of the initial problem, such solutions
are comprehensively evaluated; (3) the designer starts altering the structure of the problem
in order to attain more successful results, by adding/deleting problem constraints16 or
14 Citations after (Akin, 1988a): Henrion, M. (1974) “Notes on the Synthesis of Problems: An Exploration
of Problem Formulation Used by Human Designers and Automated Systems,” Master’s Thesis, Royal
College of Art, London. Foz, A. (1973) “Observations on designer behavior in the parti,” (in) Proceedings
of Design Activity International Conference, London.
15 Henrion (1974), has shown that in solving well-defined problems, remarkable similarities exist between
architects and laymen, as both work toward satisfying predefined constraints.
Foz (1973), reported that architects performed better than other untrained people for the following
reasons: (1) they examine the problem in breadth before selecting an approach to the solution; (2) they
sketch thoroughly as they consider ideas; (3) they debate the full implications for even unprecedented
ideas before they discard them; (4) they avoid adapting any solution until after a number of strong
alternatives are considered; and, (5) they use solutions known from previous experience, to develop new
ones.
16 According to protocol analysis conducted by the aforementioned author and according to his
examination he found that the design constraints in the final proposed solution were related to at least one

CHAPTER 1 29
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAA
AA
partial solutions to/from the initial problem description; (4) as each partial solution is
developed the designer realizes new requirements that must be met, and priorities that
must exist between these requirements (as he incorporates these new priorities, he in effect
restructures the problem by setting new sub-problems to solve); (5) cycling between
different problem structures leads him eventually to the best set of requirements and
responses that he can develop.
1.1.22 Features Of Designers Experience
Based on the previous literature review, the following features capture the essence of the
designer’s experience:
1. Designers are subjective, and generate solutions according to their past knowledge and
understanding of the problem at hand (Darke 1984, Schon and Wiggins 1992).
2. Design experience consists of retrieving structured information from memory of
solution concepts; and, selecting representations that are appropriate for the design
problem at hand (Darke 1984, Akin et al. 1986, Schon 1988).
3. Designers limit the scope of their problems by imposing a predefined solution concept
or identifying a limited set of objectives (Darke 1984, Schon 1988).
4. Designers are solution oriented, creating a solution that satisfies the problem and not
necessarily the optimum solution (Lawson 1984).
5. Designers employ their knowledge to search for solutions in a goal-directed manner.
They search for a solution that fulfills a set of criteria that they are given or they
establish. To arrive at a solution designers search for solutions and evaluate them
against relevant criteria. The process does not entail an exhaustive search but it is
heuristic in nature (Akin et al. 1986).
6. Designers use two kinds of search as found in protocols of designers; namely methods
and rules. By method is meant a ‘plan-like’ procedure or a systematic way such as,
generate-and-test, means-ends-analysis, hill-climbing, depth-first search, breadth-first
search, and back-tracking. Rules fall in the category of heuristic search and are mostly
tools for ad hoc decision situations.(Akin 1989:166).
7. Expertise in design grows by experience that provides the designer with solution
concepts (i.e., types and their associated rules). This form of information guides the
designer in his search for a solution (Darke 1984, Akin et al. 1986, Schon 1988).
8. Designers restructure their problems when conflicts are detected in a proposed
solution or partial-solution. Restructuring is performed through constraints
modification (Akin et al. 1986).
of five general categories: zoning of functions; efficiency of use; privacy of use; circulation and control of
flow; and, use of windows.

Application Of Artificial Intelligence In Architectural Design Ph.D. Dissertation

Application Of Artificial Intelligence In Architectural Design Ph.D. Dissertation

Recommended

Recommended

More Related Content

Similar to Application Of Artificial Intelligence In Architectural Design Ph.D. Dissertation

Similar to Application Of Artificial Intelligence In Architectural Design Ph.D. Dissertation (20)

More from Claire Webber

More from Claire Webber (20)

Recently uploaded

Recently uploaded (20)

Application Of Artificial Intelligence In Architectural Design Ph.D. Dissertation