Design by interactive exploration using memory-based techniques

Knowledge-Based 5VSTEMS--ELSEVIER

Knowledge-Based Systems 9 (1996) 151- 161

Design by interactive exploration using memory-based techniques Andr6s G6mez de Silva Garza, Mary Lou Maher Key Centre of Design Computing, Department of Arehitectural and Design Science, University of Sydney, NS W 2006. Australia Received 30 November 1994; revised 2 June 1995; accepted 21 June 1995

Abs~tract

One of the characteristics of design is that designers rely extensively on past experience in order to create new designs. Because of this, memory-based techniques from artificial intelligence which help store, organise, retrieve, and reuse experiential knowledge held in raemory are good candidates for aiding designers. Another characteristic of design is the phenomenon of exploration in the early stages of design configuration. A designer begins with an ill structured, partially defined, problem specification, and through a process of exploration gradually refines and modifies it as his/her understanding of the problem improves. The paper describes DEMEX, an interactive computer-aided design system that employs memory-based techniques to help its users explore the design problems they pose to the system, so that they can acquire a better understanding of the requirements of the problems. DEMEX has been applied in the domain of the structural design of buildings. Ke)words." Computer-aided design; Structural engineering; Memory-based exploration

I. Introduction

C)ne of the characteristics of design is that designers relic extensively on past experience in order to create new designs (see, for example, [1]). The experience may be their own, that is, it may be their experience of specific design problems they have encountered before, or the experience may be the documented experience of others. The ability to use and reuse this experience requires that it be able to be recalled at the appropriate times. Artificial intelligence techniques provide paradigms for the use of experiential knowledge in memory to aid in the solution of problems and the performance of tasks. Because of this, memory-based techniques from artificial intelligence research are good candidates for aiding people in design problem solving. Another characteristic of design is the phenomenon of exploration in the early stages of design configuration. A designer starts with an ill structured and partially defined specification, and, through a process of exploration, the specifications can change and become more detailed. The view of design as problem solving suggests that design can be modelled as a search process. However, as search is typically treated as a goal directed process, there is a need to qualify the model of design as search to allow exploration. In exploration, the goal(s) change as the space is searched. 0950-7051/96/$15.00 © 1996 Elsevier Science B.V. All rights reserved SSD1 0950-7051(95)01016-5

In this paper we combine and elaborate on the concepts of memory-based reasoning and exploration for supporting human designers. Memory-based methods for problem solving are generally subdivided into two classes: case-based reasoning and model-based reasoning. In case-based reasoning, specific experiences stored in memory are used to help solve a new problem, whereas in model-based reasoning it is generalised knowledge that is used. In design problem solving, cases can be the solutions to design problems encountered in the past, i.e. designed artefacts, and models can be classes of artefacts. An example of a designed artefact is the office building at 130 Elizabeth Street, whereas an example of a class of artefacts is medium-rise office

buildings. In both model-based reasoning and case-based reasoning, one of the important subtasks that need to be performed is that of memory retrieval. Algorithms have to be found that will efficiently, flexibly, and intelligently retrieve the 'right' information from memory given a specific problem-solving context. In this paper we describe D E M E X (DEsign by Memory EXploration), an interactive computer-aided design system that employs memory-based techniques to help its users solve design problems. The application domain about which D E M E X contains knowledge is that of the structural design of buildings. In this domain, cases

152

A. G6mez de Silva Garza. M.L. Maher/Knowledge-Based Systems 9 (1996) 151-161

represent the structural designs of specific buildings (or parts of buildings), and models represent classes of structural systems and subsystems used in buildings. This work builds on our previous work on EDESYN [2], a generalised system decomposition approach to design synthesis (i.e. model-based reasoning), CADSYN [3], a constraint satisfaction approach to case-based reasoning, and CASECAD [1,4,5], a multimedia case-based retrieval system. DEMEX differs from these systems in that it focuses on the exploration of memory for defining and elaborating design specifications, using both a model memory and a case memory. The purpose of DEMEX is to help designers use prior knowledge to solve new design problems by using this knowledge to improve the user's understanding of the problems. In order to do this, the system automates several memory-based processes, performing large search processes and identifying potentially critical and additional information, but it allows the user to guide and direct the retrieval of relevant experiences.

2. Representation of models and cases

In DEMEX, the objects that the.system has in its memory are of two types: cases, which describe the designs of specific structures, and models, which describe generalised classes of structures. One of the cases that DEMEX knows about, for example, is the design of the office building at 130 Elizabeth Street in Sydney, Australia, and one of the models that DEMEX knows about consists of high-rise office buildings in general. An important issue to be addressed when we choose to employ memory-based techniques in order to perform a given task is that of what information is used to describe each object in memory, i.e. how a model or a case is represented. In any design domain, design objects (such as cases or models) can be described by a set of design variables. In the domain of structural design, these variables include features such as the material, the intended use, and the shear stress of a building or class of buildings. Design variables can describe structural, functional or behavioural aspects of a case or model. This characterisation follows from research on the representation of design knowledge as prototypes, as described in [6]. The use of function, behaviour, and structure attributes assists in defining the design experience beyond the description of the solution, since function and behaviour capture some of the intent and/or semantics of the design, and not just the physical characteristics captured by structure. Specific designs have specific values associated with the attributes that are used to describe them. For instance, in order to describe a specific building, we specify what material it is made of by associating a

value such as 'prestressed concrete' with the attribute 'material'. The following example is a small part of one of DEMEX's cases (describing the structural design of the building at 370 Pitt Street, Sydney, Australia). Function."

Support-building-type: Support-grid-geometry:

office rectangular

Behaviour."

Net-area-of-useable-space:

15000m 2

Structure."

Overall-height: Location-of-core: Floor-system-type:

70 m eccentric beam-slab

Classes of designs, being general descriptions of types of structural systems, may have more than one value associated with a particular feature. For instance, the attribute 'support-building-type' of the class of highrise buildings can take any of the following values: 'hotel', 'office', 'education', 'residential' etc. As another example, the acceptable values for the attribute 'overallheight' of the same class of buildings in DEMEX can be between 61 m and 300 m. In other words, in the description of a model, either a finite list of acceptable values can be associated with any given attribute, or the value of the attribute, to be acceptable, can be defined to fall within a given range of values. For example, the following is a small part of the model in DEMEX for mediumrise office buildings. Function."

support-building-type: support-grid-geometry:

office (rectangular circular)

Behaviour."

Net-area-of-useable-space: (800 ... 25 000m 2) Structure."

Overall-height: Location-of-core: Floor-system-type:

(10 ... 60 m) (exterior central eccentric) (flat-plate beam-slab)

Cases and models in memory are related by the fact that cases (designs of specific buildings) are instances of models (generic classes of structures). For cases, the value given to the attribute 'instance-of' is the name of the model that the case belongs to. For models, the values given to the attribute 'instances' are the cases that are specific instances of the class of structures described by the model. If, for a given attribute, a specific structure has a value that does not correspond to the value(s) given in the description of a given model, then that structure cannot be an instance of the class of structures defined by the model. For the 370 Pitt Street case described above, all the attribute values match the values in the definition of the model for medium-rise office

A. G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151-161 Category-attribute associative memory

[•

153

the comparison between the description of a design problem and the description of a memory object. Memory organisation should also be dynamic [7], in the sense t;hat the m e m o r y should be able to reorganise itself, without altering the contents of its objects, when the need arises to incorporate new m e m o r y objects into it, or to remove old memory objects from it.

Function attributes Behaviour attributes Structure attributes

/

3.1. D E M E X ' s memory scheme @@@

000

@0

O0

Models Model memory

Cases

Case memory

Fig. 1. Three dynamic memories in D E M E X .

buildings also described above; therefore, the building at 370 Pitt Street can be considered to be a medium-rise office building. In summary, a case in D E M E X is represented by a set of attribute-value pairs, and a model is represented by a set of associations between attributes and one or more values (which are defined using a list or a range of valid values). A new design problem is specified to D E M E X in the same way: the problem specification consists of a set of attribute-value pairs that the user wants to be satisfied by the design that will result from solving the design problem. In addition, cases and models can have internal structure provided by the categorisation of their attributes (into function, behaviour, and structure, as discussed above), and by the partition of the attributes of each case or model into hierarchically defined subcases and submodels. Both the category and hierarchical partitions (supported by the attributes 'part' and ' p a r t - o f ' ) help make D E M E X ' s m e m o r y storage and retrieval more flexible [3,5].

3. Memory organisation Another important issue needs to be addressed in systems that perform memory-based reasoning: how are the objects in the system's m e m o r y organised? The memory organisation scheme employed must allow efficient and flexible access to the objects in memory, and efficient and flexible ways of adding or deleting memory objects. The purpose of storing cases and models in m e m o r y is to be able to retrieve and reuse them when it appears that they can help to solve a new design problem. In order to achieve this goal, an appropriate m e m o r y organisation scheme will reflect the way in which design problems, cases, and models are described, and it will facilitate

In D E M E X , there are three dynamic memories: (a) an associative m e m o r y that relates categories with design variables, (b) a model memory, and (c) a case memory. These three memories are shown in Fig. 1. The associative memory relates attributes to their categories: function, behaviour, or structure. This memory provides a mapping from a category to a set of attributes, and the inverse mapping from an attribute to its category. The model memory is a collection of models, where each model forms a functional aggregation of attributes. The case memory is a collection of subcases, where each subcase is an instance of a model in model memory. Despite being stored as separate entities in their own data structures, the three memories in D E M E X are interrelated. To begin with, all three are designed around the same attribute-value ontology described in the previous section. Additionally, each model in the model memory contains a pointer to all of the cases that are instances of that model. The converse is also true: every case in the case m e m o r y contains a pointer to the model of which it is an instance. As a consequence, even though conceptually different types of knowledge are stored in separate m e m o r y entities, the relationships between the different types of knowledge allow flexible and efficient traversal between one memory entity and another. Both the model memory and the case memory in D E M E X are indexing trees. Fig. 2 shows the case organisation scheme used in D E M E X (the model memory organisation is analogous). A root node acts as the origin of several branches. Each of the first-level branches corresponds to one of the attributes that have been used to describe the cases or models in the system's memory, and each one points to an attribute node. Each of these attribute nodes in turn acts as the origin of several more branches. These second-level branches correspond to the different values that have been associated, in the descriptions of the cases or models in the system's memory, with the different attributes, and each one points to a value node. In the case memory, each of the value nodes points to a list containing the names of the cases in the system's memory that have that value node's value for the attribute corresponding to the attribute node that points at the value node. In the model memory, an equivalent structure is reflected, except that 'valuenodes' can actually represent either single values or value ranges.

154

A. G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151-161

Rool-

y

At buteB _

ValueA1/Value,~ ~ u e A 3

ValUn!°de~:; 1 IC~ e2 IC; e3

C~e4 Case5 Case6

e--

~____~ 3 [Case4 ~Case5

Fig. 2. DEMEX's case memory organisation scheme. The case and model memories are indexing trees, because the first-level branches index a case or model according to different attributes, and the second-level branches index a case or model according to different values for a given attribute, as shown in Fig. 2. Relevant cases and models can thus be rapidly retrieved at any time using a 2-step comparison, given a memory probe, i.e. an index. At worst, adding a new case or model to one of these memories implies the addition of new attribute and value branches and nodes, plus pointers to the new case or model. Deleting an old case or model implies the removal of attribute and value branches and nodes, and the removal of pointers to the old case or model. Since memory modifications are highly localised, in neither scenario are the other cases or models in memory, or the overall organisation of the memory, affected.

3.2. Efficiency, flexibility and robustness of memory scheme The category-attribute associative memory is kept separate from the two indexing trees, because the information it provides distinguishes different types of attributes, a capability that is used in the retrieval of models and in the retrieval of cases from memory. Integrating the information held in this associative memory into the case and model memories would only result in duplicating it unnecessarily, as attributes always belong to the same category, irrespective of the type of memory item they are being used to describe. The value nodes in the two indexing trees point at lists of names of cases or models, instead of pointing at the cases or models themselves. This is because each case or model appears N times in the indexing tree, where N is the number of attribute-value pairs in the description of the case or model. Thus, pointing at the case/model itself

would require storing N copies of the contents of the case/model, whereas pointing at the name of the case/ model requires making N copies of the name but only one copy of the contents. Again, unnecessary redundancy in memory is avoided. Fig. 2 shows two occurrences of cases 3, 4 and 5 in memory. The fact that each case/model can be accessed by traversing several paths from the root of the corresponding memory means that retrieval is flexible; the same case/model can be found in memory given several different memory probes. The fact that the 2-level indexing tree organisation reflects the attribute-value scheme used to describe design problems, cases, and models means that retrieval is efficient. It is easy to detect the relevance, or 'nearness', of a case/model in memory to the current context (which is given to the system in the form of a problem description that is used as a memory probe).

4. Memory retrieval strategies In order to allow design exploration, retrieval strategies need to be defined that provide more than a single step search of case/model memory. We define design exploration as a process during which the goals of the design change as the process proceeds. Defining memory retrieval strategies that use search at a low level rather than as the main process can start to allow design exploration. In this section we present two retrieval strategies: model-based index elaboration, and casebased index revision. Model-based index elaboration uses the model memory to help identify critical and additional information relevant to the initial design specification. Case-based index revision provides an iterative search of case memory to allow the initial design specifications to shift in response to retrieved cases. D E M E X can help its users to improve their understanding of their design problems by using either of the two strategies to explore the experiential knowledge held in the system's memory that is relevant to the problems. The idea is that an improved problem description can then be used to perform a final memory retrieval of cases that can be used as starting points for solving the design problem; this reuse of the final retrieved case(s) is left to the user in DEMEX. 4.1. Model-based index elaboration In a recent analysis of design, Goel and Pirolli [8] define what makes design different from other cognitive activities, and what makes design across a variety of problem-solving domains the same cognitive activity, by identifying invariant features of the design task and the design problem environment. As Goel and Pirolli, and others, have observed, one of the invariants of the

A. G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151 161

_1 Initial S p e c i f i c a t i o n s ~

ModelMemory j /

Model

[ Retrieval I

"~ /

I RetrievedModel©

" N ) . ~ , Select Best/ ', x-N Initial Specification~ \ t , Selected M o d e l .t ~ e. m. e v. e ~. a, . l o. o e t s // / ' ' .C. .l.o s e s t M a t c h '' /

/

\ :......... 11.21 Initial Specification% ::Add Attributes Specs~ ! WithKnown Augmented SelectedModel / / i ~.'Va[}le.s ...... " \ A u g m e n t e d Specs. xx,N Selected M o d e l

/

/

No +

Identify Critical Attributes

R e d u c e d Specs.

Yes

"~ )

1

Case Retrieval Fig. 3. Algorithm for model-basedindex elaboration. design task is that the specifications for a design problem are usually not static entities that cannot change. Instead, they generally evolve during the solution of the problem. Stating the above in a different way, design problems are generally underspecified at the inception of the design process; the initial, conceptual, phase of design helps in the elaboration of the problem [9] to identify important aspects of the problem that were not captured in the original specification. One source of knowledge that helps in this problem reformulation is generic knowledge about the domain of the problems that are being solved. Because in DEMEX we use previous cases to suggest solutions to new problems, the subtask of case retrieval needs to be affected by this kind of situation assessment if we are to propose a realistic model of the design process. Therefore, we must ask ourselves how generic domain knowledge can help a designer to understand a design problem better before he/she actually performs a retrieval of past design cases to identify solutions to new problems. In general, there are two types of modification that can be carried out to the specification of a design problem: (a) more specifications can be added to the problem description, and (b) those parts of the problem specification that are critical can be identified (and the rest removed). A third possibility would be that some information in the specification could be replaced by different information, but this can be seen as a combination of the first two options: a removal followed by an addition.

155

In DEMEX's representation, a problem description consists of a list of attribute-value pairs. Generic domain knowledge can allow us to reformulate a problem both by adding new, relevant, attribute-value pairs to the problem specification, and by eliminating noncritical attribute-value pairs from the problem description. This has led to the proposal of a method for problem reformulation that sets up the two subtasks of expansion and pruning of design problem descriptions and uses generic domain knowledge, in the form of models, for this purpose. Because the resulting specification is used as an index into the design case memory for the retrieval of relevant past experiences, this strategy for problem reformulation has been termed 'model-based index elaboration'. The algorithm for model-based index elaboration as implemented in DEMEX is illustrated in Fig. 3. In Fig. 3, broken lines indicate subtasks that can be performed by either the user or DEMEX, and dotted lines indicate subtasks that have to be performed by the user; the remaining subtasks have been fully automated in the system. Model-based index elaboration has four subprocesses: model retrieval, model selection, the addition of attributes to a specification, and the identification of critical attributes in a specification. In Fig. 3, the progression of these subprocesses is shown by small arrows, and the input and output of each of these subprocesses are shown by large arrows. In the following example, we show how generic domain models can play a role in improving the description of a design problem, either by helping to add relevant information to the problem description or by identifying critical aspects of the problem description. Let us assume that the user is interested in designing a medium-rise office building, and that he/she specifies the following design problem to the system.

Example 1: problem specifications version 1: Function: Support-building-type: Support-grid-geometry:

office rectangular

Structure." Number-of-storeys: Overall-width:

30 23 m

DEMEX uses this problem specification as a probe into its model memory. Several models can match these specifications, in which case the user can inspect the resulting models in order to choose the one that seems most appropriate to the problem, or the system can choose the model that matches the greatest number of specifications (which presumably should be the 'most appropriate'). For this example, the best match in the system's model memory is a model for medium-rise office buildings, parts of which are given below.

156

A. G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151 161

Model: medium-rise-office-buildings." Function." Support-building-type: Resist-wind-load: Support-grid-geometry:

office between 1.3 and 1.7 kPa rectangular, circular, ...

Behaviour." Net-area-of-useable-space:

(8000 ... 25 000 m 2)

Structure: Number-of-storeys: Height-to-width-ratio: Overall-width: Floor-to-floor-height: Material: Floor-system-type: Wind-system-type: Location-of-core: Number-of-storeys: Etc.

between 15 and 30 between 2 and 13 between 20 and 100 m between 3 and 4.5 m steel, reinforced-concrete, ... flat-plate, flat-slab, ... core, rigid-frame . . . . exterior, central . . . . between 15 and 30

If we analyse the values given to the attributes in the problem specification, we can see that all of them fit within the values assigned to the same attributes in the definition of the above model. This means that the retrieved model perfectly matches the input specification. Because of this, we could retrieve (and show to the user) all of the cases in memory that are instances of the retrieved model, as all of them are candidate designs that match the input specification. Any one of these cases could potentially provide a starting point to the designer for solving the problem. However, there will not always be a perfect match between the problem description and the best of the retrieved models, and even if there is, before cases are retrieved we can try to improve the user's understanding of the problem as follows. As can be seen above, the retrieved model is described by more attributes than those that were given by the user in his/her design problem specification; for example, some of these additional attributes are 'location-ofcore', 'material', and 'height-to-width-ratio'. If the user knows the value for any of these attributes, and adds it to the problem description, this helps to increase the accuracy of any subsequent memory retrieval (i.e. the relevance to the current problem of any model/case retrieved with the augmented problem specification is increased). Let us assume that the new problem specification given by the user, with relevant attributes (and their values) added, is as follows.

Example 1." problem specifications version 2." Function: Support-building-type: Support-grid-geometry:

office rectangular

Structure:

Number-of-storeys:

30

Overall-width: Floor-to-floor-height: Location-of-core:

23 m 2.5 m central

If we now go on to perform case retrieval, because of the addition of information to the problem specification, not all of the cases that are instances of the model for medium-rise office buildings may now end up being retrieved, and also some cases that are not instances of this model may end up being retrieved. Specifically, in the example, the fact that a value of 2.5 m for the 'floorto-floor-height' attribute is outside the valid range defined in the model for medium-rise office buildings means that any case in memory that matches this value will be retrieved (in addition to all the cases that are instances of medium-rise office buildings). It is useful for such a case to also be retrieved because it can provide information to the user about how to deal with such a small spacing between floors that otherwise would not be available in the other retrieved cases. In the example, the knowledge provided by the retrieved model helped the user to modify the description of the design problem in a way that increased the utility of the overall case-based design paradigm. Now let us trace through a different example. Let us assume that the input problem specification given by the user is the following. (This is quite similar to the one given above. Only the value of the attribute 'overallwidth' has been changed.)

Example 2: problem specifications version 1: Function." Support-building-type: Support-grid-geometry:

office rectangular

Structure." Number-of-storeys: Overall-width:

30 15 m

As in the above example, the model in DEMEX's memory that best matches this problem description is the one that describes medium-rise office buildings in general (shown above). The difference from the previous example is that not all of the attribute-value pairs in the problem specification have values that match those in the definition of the retrieved model. Specifically, 15 m is below the minimum acceptable width defined for the attribute 'overall-width' in the description of the model (which is 20 m). What this means is that this attribute is critical in the current design problem: it makes the problem not match any of the known classes of buildings perfectly. What we can now do is to eliminate the other parts of the problem specification, since we have already identified the critical parts of it, before performing case retrieval. The resulting problem specification at the end of this last example is the following.

A. G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151 161

.+,0.c__ '> -. / Reh'ievcdCas¢~ > \\ ~~ " ImtlalSpecifications Re,,ase i--NewSpecificatiom Se ectr~ Case : .-Spectflcatlo~s / [ : x, RetrievedCas~ > MatclungAttributes / :

[ Analyze { i Remeved :: Matctung A~--A-~ i Cases i " "................ ;...... ~ I! ........ :: Select ,,) :: Interesting Selected C~e Care / .....................

No

Fig. 4. Algorithm for case-based index revision.

Example 2." problem specifications version 2." Structures." Overall-width:

15 m

Again, as in the first example, the generic knowledge provided by the model helps the user to improve his/her understanding of the design problem being solved. In effect, what is happening is that, by identifying critical attributes (and 'throwing away' the rest), we are focusing on the attributes that can lead to the retrieval of the most relevant cases rather than retrieving all the cases that have a partial match with any of the specifications. In Fig. 3, it can be seen that, in general, both the addition of the relevant attributes (and their values) and the identification of critical attributes can be performed for any one problem description. The relative order between these two subtasks is important, because an added attribute might turn out to be critical (and thus the identification of critical attributes should be performed after the addition of relevant ones). In addition, this basic cycle can be repeated indefinitely until the user is satisfied with the description of his/her design problem. As we have shown, generic design knowledge helps in the performance of both varieties of index elaboration, the addition of relevant attributes and the identification of critical attributes, which involve reformulating the description of the design problem. The carrying out of either of these subtasks, or both of them, can help in the improvement of the quality of the cases that the system can subsequently retrieve from its memory to help solve the design problem.

4.2. Case-based index revision Generic knowledge of a domain does not have to be

157

the only source of inspiration for the reformulation of the description of a design problem; situation-specific knowledge can also play a role. Some features of the solution to an old design problem that has been retrieved because it initially seemed close to the current problem can provide inspiration for changing the original problem specification. The new specification might suggest in a subsequent memory retrieval that a different previous solution is now 'more appropriate' in helping to solve the new problem. This process can be repeated indefinitely until the designer is satisfied with a given problem specification. After each cycle of memory access, the indices (i.e. the problem description) used to perform the retrieval can be modified on the basis of the retrieved cases. Because of this, the algorithm is called case-based index revision. When index revision terminates, it is because a case that is 'good enough' has been found, and the next step can be to adapt that case to the current problem-solving context. Case adaptation is left to the user (or to another system) in DEMEX. Fig. 4 illustrates the algorithm for the case-based index revision process. The dotted lines indicate subtasks that must be performed by the user, and the other subtasks are performed autonomously by DEMEX. Case-based index revision has three subprocesses: case retrieval, the analysis of retrieved cases, and the selection of an interesting case. In Fig. 4, the progression of these subprocesses is shown by small arrows, and the input and output of each of the subtasks are shown by large arrows. After the performance of case-based index revision, the new indices may incorporate attributes from various parts of several previously retrieved design cases, or they may be drawn from only a part of one previous solution. Fig. 5 illustrates these two possibilities. In the following example, we show how specific design cases can play a role in improving the user's understanding of a design problem. Let us assume that the user is interested in designing a building, and has only had experience with using rigid frames to provide wind resistance in structures, and therefore specifies the following design problem to DEMEX.

Example 3: problem specifications version l: Function." Resist-wind-load:

1.5 kPa

Structure." Wind-system-type: Number-of-bays: Bay-width:

rigid-frame 2 6m

When this problem specification is used as a probe into DEMEX's case memory, the following case (among others) is retrieved.

158

A. G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151-161

lndtx rtvisioa can take inspiratim frem eat part of n pc¢viees ¢xperienc¢:

Remev~lcase(s): Indices:

Z~>

Revised ln~ices;

Index revislen can rtsult from ¢onadtring parts of many past cases:

Retrieved c~eIs): RevisedIndices:

Fig. 5. Varioussourcesof inspiration for producingan improvedproblem description.

in the user's expectations of what would make a case relevant. If the new problem specification is now used as a memory probe, the cases retrieved can be different from the results of using the original specification, thus expanding the amount of information that the user has access to during memory exploration, while still ensuring the relevance of the retrieved data to the designer's problem. The conditions under which the iterative process described above should end are subjective and contextdependent, and so it is up to the user to decide when to stop. The computer environment can help by clearly indicating and explaining the possible options, and prompting the user to choose from among relevant options at the right times, but full automation of the process would make it inflexible. An interactive system such as D E M E X automates the tedious and routine aspects of experience-based design (e.g. the cataloguing of past cases, or the matching of new situations with old ones), but it lets the user make the final creative decisions (e.g. combining different parts of past cases to produce a new solution, or modifying the specifications of a design problem).

Case 1: Function: Resist-wind-load:

5. Implementation

1.5 kPa

Structure: Height: Number-of-panels: Wind-system-type: Panel-width: Support-building-type: Etc.

150 m 2 vertical-truss 7m office

As can be seen, the retrieved case suggests that it is possible to use vertical trusses in order to achieve wind resistance in structures, and not just the rigid frames that the user originally specified. The designer can decide to modify his/her problem specification given the information in the retrieved case to come up with the following revised problem description. Case 3." problem specifications version 2: Function: Resist-wind-load:

1.5 kPa

Structure: Wind-system-type: Number-of-panels: Panel-width:

vertical-truss 2 6m

In making the analogy between the rigid frame and the truss, the attributes 'number-of-bays' and 'bay-width' in the specification of the rigid frame become 'number-ofpanels' and 'panel-width' in the next version of the specifications, since these attributes reflect the change

All of the examples above show cases and models that are contained in D E M E X ' s knowledge base, and all of them illustrate capabilities that have been implemented in the system. The cases and models in D E M E X are represented using the Framekit frame representation language, which is compatible with Common LISP. In Framekit, a frame can have multiple slots, and each slot can have many facets. A special facet is the 'value' facet, which is generally used to store the value(s) of a slot. In many cases, slots should have different values in different contexts, and, because of this, each facet in Framekit can have many 'views'. This means that many values can be associated with a slot by the definition of many views (contexts) for its value facet. The following shows the basic structure of a framekit frame: ( < Frame-name > ( < Slot-name- 1 > (Facet-name- 1 > (View-name-1 > < Value for View-name-1 > ) (View-name-2 > < Value for View-name-2 > ) Etc.) ( < Facet-name-2 > Etc.) Etc.) ( < Slot-name-2 > Etc.) Etc.) 5.1. Memory structures The pair of dynamic memories which organise the

A, G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151 161

159

Cases/Models

TM OO0

.

.

.

.

.

" ' "

I IBM B" ~ n

on the Park

User

DEMEX

Problem Specifications

[ Student Ce_ntr.e

......... KEY: Fig. 6. D E M E X ' s case m e m o r y .

cases and models in D E M E X were also implemented using Framekit. Each of these two memories is represented as a different frame which acts as an indexing tree as discussed in the third section. Fig. 6 shows the organisational scheme of the case memory in D E M E X . (Note that the names of the cases shown in Fig. 6 do not actually correspond to the cases stored in D E M E X ' s memory; they are used here for illustrative purposes only.) In the Framekit implementation of these memories, the slots in each frame correspond to the attributes that are used to describe the cases or models in the corresponding memory. The views of the value facet of each of these slots are defined to be the values that the attribute corresponding to the slot can have. In models, attributes can have values or ranges of values. In the Framekit implementation of the model memory, the special keyword 'range' is reserved as the name of the view that holds the information about different value ranges (as opposed to values) for a particular attribute. Finally, the information that is associated with each view in the Framekit implementation (i.e. the values given to the view) consists of the list of cases/models that have the attribute value represented by the view in D E M E X . The following shows a portion of the Framekit implementation of the case memory in D E M E X : (Demex-case-memory (Support-building-type (Value (Office 130Elizabeth 370Pitt) (Residential TheHuntington) Etc.)) (Location-of-core Etc.) Etc.)) The result is a pair of 2-level indexing trees, one for cases and one for models. The highest-level branches

Princess Control Information Data

Fig. 7. C o m m u n i c a t i o n s between D E M E X and its users ( - - - : process control information, - - - : data).

of each tree, implemented as Framekit slots, index by attribute name, and the second-level branches, implemented as views of the Framekit value facet, index by attribute values or value ranges. The leaves of the trees, implemented as values of the views, are the cases/models known to DEMEX. These are dynamic memories because memory objects (cases or models) can be added (i.e. learned) or deleted (i.e. forgotten) without disrupting the rest of the memory structure or contents, using simple D E M E X functions that employ Framekit primitives.

5.2. User interaction

The retrieval strategies discussed in the fourth section operate on these two dynamic memories, and they have been integrated into an interactive cycle of communication between the user and D E M E X . Fig. 7 shows the types of information interchanged between D E M E X and its users while the system is in operation. An additional memory structure is used to associate attributes with their categories (function, behaviour, or structure). This memory structure is implemented as a LISP association list. If attribute categories are important for a given memory retrieval, the associative memory that defines the categories of attributes is accessed first, and then those branches of the case or model memory that do not correspond to attributes that have the 'right' category can be ignored, while only the others need to be searched during retrieval. The efficiency and flexibility of the retrieval of cases or models remains. A user's interaction with D E M E X begins with the specification of a design problem, represented as a list of attribute-value pairs. The designer is able to choose at all times whether he/she wants to perform model retrieval or case retrieval using the problem specification

160

A. Gdmez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151-161

as a memory index. When a memory retrieval finds that several memory objects match the problem specification in some way, either the user can browse through the retrieved objects to choose one to continue working with, or D E M E X can determine which object matches the specifications most closely (this is measured by counting the number of attribute-value pairs of the specification that match the value(s) or value range given for the attribute in the memory object). This best-matching model or case is then selected automatically for subsequent processing. The rest of the model-based index elaboration and case-based index revision strategies have been automated as described in the fourth section and as shown in Figs. 3 and 4.

6. Discussion Some issues that needed to be resolved in the implementation of these strategies as two separate approaches to exploration are as follows: • Level of abstraction of initial memory access: Is general knowledge of the domain or situation-specific knowledge accessed first (i.e. models or cases)? • Number of retrieved objects that play a role in subsequent memory accesses." ls knowledge from the best matching memory object used exclusively, or do all the objects that result from a probe into memory contribute information? Note that the issue of ranking retrieved objects becomes important here. • Relative importance of the problem specifications: Are all of the attributes and/or all of the values present in the memory probe (initially assumed to originate from the user) treated in the same fashion, or do some play a larger role in retrieval (e.g. because of differences in their categories)? Note that the issue of ranking the components o f the input to memory comes into play here. • Perfect versus partial match." Does the memory object have to match all of the specifications in the memory probe (AND matching), or is it considered to be relevant if any of its features match some of the input specifications (OR matching)? • Termination condition: How do we determine the number/type/direction of iterations of memory search performed? • Role o f original specifications: Are the attributes in the original problem specification augmented and/or replaced by the information provided by the retrieved memory object? According to these issues, the retrieval strategies presented in the fourth section can be summarised as follows: • Model-based index elaboration (expansion of problem

specification with derived attributes plus identification and elimination of noncritical attributes)." * The initial type of knowledge retrieved from memory is general knowledge in the form of models. o Out of the retrieved models, the one that matches best is the one that provides the information required for subsequent processing. o The attributes of the problem specification are treated as having the same relative importance. o All models that match at least one attribute in the problem specifications are retrieved. o A problem can be reformulated more than once before the retrieval of situation-specific knowledge, i.e. several iterations can be performed. o The problem specification is augmented and/or reduced by the process. • Case-based index revision: o This strategy begins with the probing of the case memory, and so initial access is to situation-specific knowledge. o Information from one case only is used for further processing. o All the attributes in the problem specification have the same relative importance in matching. o All models that match at least one attribute in the problem specifications are retrieved. o After the initial probe into case memory, a cycle of index revision followed by case-memory access begins, and it is terminated by the user, i.e. many iterations can be performed. o The attributes in the problem specification can be changed, as well as the values of some of the attributes. In conclusion, we have introduced, developed, and considered the use of two iterative retrieval strategies. The strategies as presented assume that cases are described by attribute-value pairs grouped into three categories. As part of a design aid, models and cases may include constraints, images, drawings etc. as well. The attributevalue pairs comprise the memory indices, and the retrieval strategies operate on these indices. The remaining information in a case is retrieved with the indices, and it is the basis of the presentation of the case to the human designer and a starting point for case adaptation. The contribution of the work reported here is to make the retrieval strategies explicit as an approach to supporting the exploration of memory for improving the user's understanding of a design problem.

References [1] M.L. Maher, B. Balachandran and D.M. Zhang, Case-Based Reasoning in Design, Lawrence Erlbaum, 1995.

A. G6mez de Silva Garza, M.L. Maher/Knowledge-Based Systems 9 (1996) 151-161

[2] M.L. Maher, Engineering design synthesis: a domain independent representation, Artificial Intelligence for Engineering Design, Analysis, and Manufacturing 1 (1987) 207-213. [3] M.L. Maher and D.M. Zhang, CADSYN: a case-based design process model, Artificial Intelligence for Engineering Design, Analysis, and Manufacturing 7 (1993) 97-110. [4] M.L. Maher and B. Balachandran, Multimedia approach to casebased structural design, Journal of Computing in Civil Engineering, 8 (1994) 359-376. [5] M.L. Maher and B. Balachandran, Flexible retrieval strategies for case-based design, in Proc. 3rd Int. Conf. Artificial Intelligence in Design, 1994, pp. 163 180.

161

[6] J. Gero, Design prototypes: a knowledge representation schema for design, AI Magazine, 1990, pp. 26-36. [7] R. Schank, Dynamic Memory: A Theory of Learning in Computers and people, Cambridge University Press, 1982. [8] V. Goel and P. Pirolli, Motivating the notion of generic design within information processing theory: the design problem space, AI Magazine (1989) 18-36. [9] J.L. Kolodner, Retrieval and Organizational Strategies in Conceptual Memory: A Computer Model, Lawrence Erlbaum, 1984.