Design by Interactive Exploration UsingMemory-Based TechniquesAndr�es G�omez de Silva GarzaMary Lou MaherKey Centre of Design ComputingDepartment of Architectural and Design ScienceUniversity of Sydney NSW 2006AustraliaAbstractOne of the characteristics of design is that designers rely extens-ively on past experience in order to create new designs. Becauseof this, memory-based techniques from arti�cial intelligence, whichhelp store, organise, retrieve, and reuse experiential knowledge heldin memory, are good candidates for aiding designers. Another charac-teristic of design is the phenomenon of exploration in the early stagesof design con�guration. A designer begins with an ill-structured, par-tially de�ned, problem speci�cation, and through a process of explor-ation gradually re�nes and modi�es it as his/her understanding of theproblem improves. In this paper we describe demex, an interactivecomputer-aided design system that employs memory-based techniquesto help its users explore the design problems they pose to the system,in order to acquire a better understanding of the requirements of theproblems. demex has been applied in the domain of structural designof buildings. 1

1 IntroductionOne of the characteristics of design is that designers rely extensively on pastexperience in order to create new designs (eg., see [Maher, Balachandran, andZhang 1995]). The experience may be their own, that is, speci�c design prob-lems they have encountered before, or the experience may be the documentedexperience of others. Being able to use and reuse this experience requiresthat it be recalled at the appropriate times. Arti�cial intelligence techniquesprovide paradigms for the use of experiential knowledge in memory to aidin the solution of problems and the performance of tasks. Because of this,memory-based techniques from arti�cial intelligence research are good can-didates for aiding people in design problem solving.Another characteristic of design is the phenomenon of exploration in theearly stages of design con�guration. A designer starts with an ill-structuredand partially de�ned speci�cation, and through a process of exploration,the speci�cations can change and become more detailed (eg., see [Corne,Smithers, and Ross 1993]). The view of design as problem solving suggeststhat design can be modelled as a search process. However, as search istypically treated as a goal directed process, there is a need to qualify the2

model of design as search to allow exploration. In exploration, the goal(s)change as the space is searched.In this paper we combine and elaborate on the concepts of memory-basedreasoning and exploration for supporting human designers. Memory-basedmethods for problem solving are generally subdivided into two classes: case-based reasoning and model-based reasoning. In case-based reasoning, speci�cexperiences stored in memory are used to help solve a new problem, whereasin model-based reasoning it is generalised knowledge that is used. In designproblem solving, cases can be the solutions to design problems encounteredin the past, ie., designed artefacts, and models can be classes of artefacts.An example of a designed artefact is the o�ce building at 130 Elizabeth St,whereas an example of a class of artefacts is medium-rise o�ce buildings.Both in model-based reasoning and in case-based reasoning, one of theimportant subtasks that need to be performed is that of memory retrieval.Algorithms have to be found that will e�ciently, exibly, and intelligently re-trieve the \right" information from memory given a speci�c problem-solvingcontext.In this paper we describe demex (DEsign by Memory EXplora-tion), an interactive computer-aided design system that employs memory-3

based techniques to help its users solve design problems. The applicationdomain about which demex contains knowledge is that of structural designof buildings. In this domain, cases represent the structural designs of speci�cbuildings (or parts of buildings), and models represent classes of structuralsystems and subsystems used in buildings. This work builds on our previouswork on edesyn [Maher 1987], a generalised system decomposition approachto design synthesis (ie., model-based reasoning); cadsyn [Maher and Zhang1993], a constraint satisfaction approach to case-based reasoning; and case-cad [Maher and Balachandran 1994a, 1994b] [Maher, Balachandran, andZhang 1995], a multimedia case-based retrieval system. demex di�ers fromthese systems because it focuses on the exploration of memory for de�ningand elaborating design speci�cations, using both a model memory and a casememory.The purpose of demex is to help designers use prior knowledge to solvenew design problems by using this knowledge to improve the user's under-standing of the problems. In order to do this, the system automates severalmemory-based processes, performing large search processes and identifyingpotentially critical and additional information, but allows the user to guideand direct the retrieval of relevant experiences.4

2 Representation of Models and CasesIn demex, the objects that the system has in its memory are of two types:cases, which describe the designs of speci�c structures, and models, whichdescribe generalised classes of structures. One of the cases that demexknows about, for example, describes the design of the o�ce building foundat 130 Elizabeth Street in Sydney, and one of the models that demex knowsabout describes high-rise o�ce buildings in general. An important issue tobe addressed when we choose to employ memory-based techniques in orderto perform a given task is: what information is used to describe each objectin memory, ie., how is a model or a case represented?In any design domain, design objects (such as cases or models) can bedescribed by a set of design variables. In the domain of structural design,these variables include features such as the material, the intended use, andthe shear stress of a building or class of buildings. Design variables candescribe structural, functional or behavioural aspects of a case or model.This characterisation follows from research on the representation of designknowledge as prototypes, as described in [Gero 1990]. The use of function,behaviour, and structure attributes assists in de�ning the design experience5

beyond the description of the solution, since function and behaviour capturesome of the intent and/or semantics of the design, not just the physicalcharacteristics captured by structure.Speci�c designs have speci�c values associated with the attributes thatare used to describe them. For instance, in order to describe a speci�c build-ing, we specify what material it is made of by associating a value such as\prestressed concrete" to the attribute \material." The following example isa small part of one of demex's cases (describing the structural design of thebuilding at 370 Pitt St., Sydney):FunctionSupport-building-type: o�ceSupport-grid-geometry: rectangularBehaviourNet-area-of-useable-space: 15000 m2StructureOverall-height: 70 mLocation-of-core: eccentricFloor-system-type: beam-slabClasses of designs, being general descriptions of types of structural sys-tems, might have more than one value associated with a particular feature.For instance, the attribute \support-building-type" of the class high-risebuildings, can take any of the following values: \hotel," \o�ce," \educa-tion," \residential," etc. As another example, the acceptable values for the6

attribute \overall-height" of the same class of buildings in demex can bebetween 61 and 300 m. In other words, in the description of a model therecan either be a �nite list of acceptable values associated with any given at-tribute, or the value of the attribute, to be acceptable, can be de�ned to fallwithin a given range of values. For example, the following is a small part ofthe model in demex for medium-rise o�ce buildings:FunctionSupport-building-type: o�ceSupport-grid-geometry: (rectangular circular)BehaviourNet-area-of-useable-space: (8000 ... 25000 m2)StructureOverall-height: (10 ... 60 m )Location-of-core: (exterior central eccentric)Floor-system-type: ( at-plate beam-slab)Cases and models in memory are related by the fact that cases (designsof speci�c buildings) are instances of models (generic classes of structures).For cases, the value given to the attribute \instance-of" is the name of themodel that the case belongs to. For models, the values given to the attribute\instances" are the cases that are speci�c instances of the class of structuresdescribed by the model. If, for a given attribute, a speci�c structure has avalue that does not correspond to the value(s) given in the description of agiven model, then that structure can't be an instance of the class of structures7

de�ned by the model. For the 370 Pitt St. case shown above, all attributevalues match the values in the de�nition of the model for medium-rise o�cebuildings, also shown above; therefore, the building at 370 Pitt St. can beconsidered to be a medium-rise o�ce building.In summary, a case in demex is represented by a set of attribute-valuepairs, and a model is represented by a set of associations between attributesand one or more values (which are de�ned using a list or a range of validvalues). A new design problem is speci�ed to demex in the same way:the problem speci�cation consists of a set of attribute-value pairs that theuser wants to be satis�ed by the design that will result from solving thedesign problem. In addition, cases and models can have internal structureprovided by the categorisation of their attributes (into function, behaviour,and structure as discussed above), and by partitioning the attributes of eachcase or model into hierarchically de�ned subcases and submodels. Both thecategory and hierarchical partitions (supported by the attributes \part" and\part-of") help make demex's memory storage and retrieval more exible[Maher and Zhang 1993] [Maher and Balachandran 1994b].8

3 Memory OrganisationAnother important issue needs to be addressed in systems that performmemory-based reasoning: how are the objects in the system's memory or-ganised? The memory organisation scheme employed must enable e�cientand exible access to the objects in memory, and e�cient and exible waysof adding or deleting memory objects.The purpose of storing cases and models in memory is to be able to re-trieve and reuse them when it appears that they can help to solve a newdesign problem. In order to achieve this goal, an appropriate memory organ-isation scheme will re ect the way that design problems, cases, and modelsare described, and will facilitate the comparison between the description ofa design problem and the description of a memory object. Memory organ-isation should also be dynamic [Schank 1982], in the sense that the memoryshould be able to reorganise itself, without altering the contents of its ob-jects, when the need arises to incorporate new memory objects into it, or toremove old memory objects from it. 9

3.1 demex's Memory SchemeIn demex, there are three dynamic memories: (1) an associative memorythat relates categories with design variables, (2) a model memory, and (3)a case memory. These three memories are shown in Figure 1. The associ-ative memory relates attributes with their categories: function, behaviour,or structure. This memory provides a mapping from a category to a set ofattributes, and the inverse mapping from an attribute to its category. Themodel memory is a collection of models, where each model forms a functionalaggregation of attributes. The case memory is a collection of subcases, whereeach 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 demex are interrelated. To begin with, all three aredesigned around the same attribute-value ontology described in the previoussection. Additionally, each model in the model memory contains a pointerto all of the cases that are instances of that model. The converse is also true:every case in the case memory contains a pointer to the model of which it isan instance. As a consequence, even though conceptually di�erent types ofknowledge are stored in separate memory entities, the relationships between10

the di�erent types of knowledge allow exible and e�cient traversal betweenone memory entity and another.Both the model memory and the case memory in demex are indexingtrees. Figure 2 shows the case organisation scheme used in demex (themodel memory organisation is analogous). A root-node serves as the originof several branches. Each of the �rst-level branches corresponds to one of theattributes that have been used to describe the cases or models in the system'smemory, and each one points to an attribute-node. Each of these attribute-nodes in turn serves as the origin of several more branches. These second-level branches correspond to the di�erent values that have been associated,in the descriptions of the cases or models in the system's memory, to thedi�erent 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 inthe system's memory that have that value-node's value for the attributecorresponding to the attribute-node that points at the value-node. In themodel memory, an equivalent structure is re ected, except that \value-nodes"can actually represent either single values or value ranges.The case and model memories are indexing trees because the �rst-levelbranches index a case or model according to di�erent attributes, and the11

second-level branches index a case or model according to di�erent values fora given attribute, as shown in Figure 2. Relevant cases and models canthus be rapidly retrieved at any time using a two-step comparison, given amemory probe, ie., an index. At worst, adding a new case or model to one ofthese memories implies adding new attribute and value branches and nodes,plus pointers to the new case or model; deleting an old case or model impliesremoving attribute and value branches and nodes, and removing pointersto the old case or model. Since memory modi�cations are highly localised,in neither scenario are the other cases or models in memory, or the overallorganisation of the memory, a�ected.3.2 E�ciency, Flexibility, and Robustness of MemorySchemeThe category-attribute associative memory is kept separate from the two in-dexing trees because the information it provides distinguishes di�erent typesof attributes, a capability that is used in the retrieval of models and in theretrieval of cases from memory. Integrating the information held in thisassociative memory into the case and model memories would only result in12

duplicating it unnecessarily, as attributes always belong to the same categoryirrespective 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 casesor models, instead of pointing at the cases or models themselves. This isbecause each case or model will appear N times in the indexing tree, where Nis 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 thecontents of the case/model, whereas pointing at the name of the case/modelrequires making N copies of the name but only one copy of the contents.Again, unnecessary redundancy in memory is avoided.Figure 2 shows two occurrences of Case 4 and Case 5 in memory. The factthat each case/model can be accessed by traversing several paths from theroot of the corresponding memory means that retrieval is exible: the samecase/model can be found in memory given several di�erent memory probes.The fact that the two-level indexing tree organisation re ects the attribute-value scheme used to describe design problems, cases, and models, meansthat retrieval is e�cient: it is easy to detect the relevance, or \nearness," ofa case/model in memory to the current context (which is given to the systemin the form of a problem description that is used as a memory probe).13

4 Memory Retrieval StrategiesIn order to allow design exploration to occur, retrieval strategies need to bede�ned that provide more than a single step search of case/model memory.We de�ne design exploration as a process during which the goals of the designchange as the process proceeds. De�ning memory retrieval strategies thatuse search at a low level rather than as the main process can start to allowdesign exploration. In this section we present two retrieval strategies: model-based index elaboration and case-based index revision. Model-based indexelaboration uses the model memory to help identify critical and additionalinformation relevant to the initial design speci�cation. Case-based indexrevision provides an iterative search of case memory to allow the initial designspeci�cations to shift in response to retrieved cases. demex can help its usersimprove their understanding of their design problems by using either of thetwo strategies to explore the experiential knowledge held in the system'smemory that is relevant to the problems. The idea is that an improvedproblem description can then be used to perform a �nal memory retrieval ofcases that can be used as starting points for solving the design problem; thisreuse of the �nal retrieved case(s) is left to the user in demex.14

4.1 Model-Based Index ElaborationIn a recent analysis of design, Goel and Pirolli [1989] de�ne what makesdesign di�erent from other cognitive activities, and what makes design acrossa variety of problem-solving domains the same cognitive activity, by identify-ing invariant features of the design task and the design problem environment.As Goel and Pirolli, and others, have observed, one of the invariants of thedesign task is that the speci�cations for a design problem are usually notstatic entities that cannot change, but that instead they generally evolveduring the solution of the problem. Said a di�erent way, design problemsare generally underspeci�ed at the inception of the design process; the ini-tial, conceptual, phase of design helps to elaborate on the problem [Kolodner1984] to identify important aspects of the problem that were not captured inthe original speci�cation.One source of knowledge that helps perform this problem reformulationis generic knowledge about the domain of the problems that are being solved.Because in demex we are using previous cases to suggest solutions to newproblems, the subtask of case retrieval needs to be a�ected by this kindof situation assessment if we are to propose a realistic model of the design15

process. So we must ask ourselves how generic domain knowledge can help inunderstanding a design problem better before we actually perform a retrievalof past design cases for proposing solutions to new problems.In general there are two types of modi�cations that can be performed onthe speci�cation of a design problem: (1) more speci�cations can be addedto the problem description, and (2) those parts of the problem speci�cationthat are critical can be identi�ed (and the rest removed). A third possibilitywould be that some information in the speci�cation be replaced by di�erentinformation, but this can be seen as a combination of the �rst two: a removalfollowed by an addition.In demex's representation, a problem description consists of a list ofattribute-value pairs. Generic domain knowledge can allow us to reformu-late a problem both by adding new, relevant, attribute-value pairs to theproblem speci�cation, and by eliminating non-critical attribute-value pairsfrom the problem description. This has led to the proposal of a methodfor problem reformulation that sets up the two subtasks of expansion andpruning of design problem descriptions and uses generic domain knowledge,in the form of models, for this purpose. Because the resulting speci�cationis used as an index into the design case memory for the retrieval of relevant16

past experiences, this strategy for problem reformulation has been termed\model-based index elaboration."The algorithm for model-based index elaboration as implemented in de-mex is illustrated in Figure 3. In the Figure, dashed lines indicate subtasksthat can be performed by either the user or demex, dotted lines indicate sub-tasks that have to be performed by the user, whereas the remaining subtaskshave been fully automated in the system. Model-based index elaborationhas 4 subprocesses: model retrieval, model selection, addition of attributesto a speci�cation, and identi�cation of critical attributes in a speci�cation.In the �gure, the progression of these subprocesses is shown as small arrows,and the input and output of each of these subprocesses are shown as largearrows.In the following example we show how generic domain models can playa role in improving the description of a design problem, either by helping toadd relevant information to the problem description or by identifying criticalaspects of the problem description. Let's assume the user is interested indesigning a medium-rise o�ce building, and speci�es the following designproblem to the system: 17

Example 1: Problem Speci�cations Version 1FunctionSupport-building-type: o�ceSupport-grid-geometry: rectangularStructureNumber-of-storeys: 30Overall-width: 23 mdemex uses this problem speci�cation as a probe into its model memory.Several models can match these speci�cations, in which case the user can in-spect the resulting models in order to choose the one that seems most appro-priate to the problem, or the system can choose the model that matches thegreatest number of speci�cations (which presumably should be the \most ap-propriate"). For this example, the best match in the system's model memoryis a model for medium-rise o�ce buildings, parts of which are shown here:Model: Medium-rise-o�ce-buildingsFunctionSupport-building-type: o�ceResist-wind-load: between 1.3 and 1.7 kPaSupport-grid-geometry: rectangular, circular, ...BehaviourNet-area-of-useable-space: (8000 ... 25000 m2)StructureNumber-of-storeys: between 15 and 30Height-to-width-ratio: between 2 and 13Overall-width: between 20 and 100 mFloor-to- oor-height: between 3 and 4.5 mMaterial: steel, reinforced-concrete, ...18

Floor-system-type: at-plate, at-slab, ...Wind-system-type: core, rigid-frame, ...Location-of-core: exterior, central, ...Number-of-storeys: between 15 and 30Etc.If we analyse the values given to the attributes in the problem speci�c-ation, we can see that all of them �t within the values assigned to the thesame attributes in the de�nition of the above model. This means that theretrieved model perfectly matches the input speci�cation. Because of this,we could retrieve (and show to the user) all of the cases in memory thatare instances of the retrieved model, as all of them are candidate designsthat match the input speci�cation. Any one of these cases could potentiallyprovide a starting point to the designer for solving the problem. However,there won't always be a perfect match between the problem description andthe best of the retrieved models, and even if there is, before cases are re-trieved we can try to improve the user's understanding of the problem asfollows.As can be seen above, the retrieved model is described by more attributesthan those that were given by the user in his/her design problem speci�ca-tion; for example, some of these additional attributes are \location-of-core,"19

\material," \height-to-width-ratio," etc. If the user knows the value for anythese attributes, and adds it to the problem description, it helps increasethe accuracy of any subsequent memory retrieval (ie., the relevance to thecurrent problem of any model/case retrieved with the augmented problemspeci�cation is increased). Let us assume that the new problem speci�cationgiven by the user, with relevant attributes (and their values) added, is now:Example 1: Problem Speci�cations Version 2FunctionSupport-building-type: o�ceSupport-grid-geometry: rectangularStructureNumber-of-storeys: 30Overall-width: 23 mFloor-to- oor-height: 2.5 mLocation-of-core: centralIf we now go on to perform case retrieval, because of the addition ofinformation to the problem speci�cation not all of the cases that are instancesof the model for medium-rise o�ce buildings might end up being retrievednow, and some cases that are not instances of this model might also end upbeing retrieved. Speci�cally in the example, the fact that a value of 2.5 mfor the \ oor-to- oor-height" attribute is outside of the valid range de�nedin the model for medium-rise o�ce buildings means that any case in memorythat matches this value will be retrieved (apart from all the cases that are20

instances of medium-rise o�ce buildings). It is useful for such a case to alsobe retrieved because it can provide information to the user about how to dealwith such a low spacing between oors that otherwise wouldn't be availablein the other retrieved cases. In the example, the knowledge provided by theretrieved model helped the user modify the description of the design problemin a way that increased the utility of the overall case-based design paradigm.Now let's trace through a di�erent example. Let's assume that the inputproblem speci�cation given by the user is the following (quite similar to theone given above: only the value of the attribute \overall-width" has beenchanged):Example 2: Problem Speci�cations Version 1FunctionSupport-building-type: o�ceSupport-grid-geometry: rectangularStructureNumber-of-storeys: 30Overall-width: 15 mAs in the above example, the model in demex's memory that best matchesthis problem description is the one that describes medium-rise o�ce buildingsin general (shown above). The di�erence with the previous example is thatnot all of the attribute-value pairs in the problem speci�cation have valuesthat match those in the de�nition of the retrieved model. Speci�cally, 15 m is21

below the minimum acceptable width given to the attribute \overall-width"in the description of the model (which is 20 m). What this means is thatthis attribute is critical in the current design problem: it makes the problemnot match any of the known classes of buildings perfectly. What we can nowdo is to eliminate the other parts of the problem speci�cation, since we havealready identi�ed the critical parts of it, before performing case retrieval.The problem speci�cation resulting at the end of this last example is thefollowing:Example 2: Problem Speci�cations Version 2StructureOverall-width: 15Again, as in the �rst example, the generic knowledge provided by themodel helps the user improve his/her understanding of the design problembeing solved. In e�ect, what is happening is that by identifying criticalattributes (and \throwing away" the rest) we are focussing on the attributesthat can retrieve the most relevant cases rather than retrieving all cases thathave a partial match with any of the speci�cations.In Figure 3 it can be seen that, in general, both adding relevant attrib-utes (and their values) and identifying critical attributes can be performedon any one problem description. The relative order between these two sub-22

tasks is important, because an added attribute might turn out to be critical(so identifying critical attributes should be performed after adding relevantones). In addition, this basic cycle can be repeated inde�nitely until the useris satis�ed with the description of his/her design problem.As we have shown, generic design knowledge helps to perform both vari-eties of index elaboration, adding relevant attributes and identifying criticalattributes, which involve reformulating the description of the design problem.Any one of these two subtasks, or both of them together, can help improvethe quality of the cases that the system can subsequently retrieve from itsmemory to help solve the design problem.4.2 Case-Based Index RevisionGeneric knowledge of a domain does not have to be the only source of inspir-ation for the reformulation of the description of a design problem: situation-speci�c knowledge can also play a role. Some features of the solution to anold design problem that was retrieved, because it initially seemed close to thecurrent problem, can provide inspiration for changing the original problemspeci�cation. The new speci�cation might suggest in a subsequent memory23

retrieval that a di�erent previous solution is now \more appropriate" in help-ing to solve the new problem. This process can repeat itself inde�nitely untilthe designer is satis�ed with a given problem speci�cation.After each cycle of memory access, the indices (ie., the problem descrip-tion) used to perform the retrieval can be modi�ed based on the retrievedcases. 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 currentproblem-solving context. Case adaptation is left to the user (or to anothersystem) in demex.Figure 4 illustrates the algorithm for the case-based index revision pro-cess. The dotted lines indicate subtasks that must be performed by the user,whereas the other subtasks are performed autonomously by demex. Case-based index revision has 3 subprocesses: case retrieval, analysis of retrievedcases, and selecting an interesting case. In the �gure, the progression of thesesubprocesses is shown as small arrows, and the input and output of each ofthe subtasks are shown in large arrows.After performing case-based index revision, the new indices might incor-porate attributes from di�erent parts of several previously retrieved design24

cases, or they might be drawn from only a part of one previous solution.Figure 5 illustrates these two possibilities.In the following example we show how speci�c design cases can play a rolein improving the user's understanding of a design problem. Let's assume theuser is interested in designing a building and has only had experience withusing rigid frames to provide wind resistance in structures, and thereforespeci�es the following design problem to demex:Example 3: Problem Speci�cations Version 1FunctionResist-wind-load: 1.5 kPaStructureWind-system-type: rigid-frameNumber-of-bays: 2Bay-width: 6 mWhen this problem speci�cation is used as a probe into demex's casememory, the following case (among others) is retrieved:Case 1:FunctionResist-wind-load: 1.5 kPaStructureHeight: 150 mNumber-of-panels: 2Wind-system-type: vertical-trussPanel-width: 7 mSupport-building-type: o�ceEtc. 25

As can be seen, the retrieved case suggests that it is possible to usevertical trusses in order to achieve wind resistance in structures, and not justthe rigid frames that the user originally speci�ed. The designer can decide tomodify his/her problem speci�cation given the information in the retrievedcase to come up with the following revised problem description:Case 3: Problem Speci�cations Version 2FunctionResist-wind-load: 1.5 kPaStructureWind-system-type: vertical-trussNumber-of-panels: 2Panel-width: 6 mIn making the analogy between the rigid frame and the truss, the at-tributes \Number-of-bays" and \Bay-width" in the speci�cation of the rigidframe become \Number-of-panels" and \Panel-width" in the next version ofthe speci�cations, since these attributes re ect the change in the user's ex-pectations of what would make a case relevant. If the new problem speci�ca-tion is now used as a memory probe, the cases retrieved can be di�erent fromthe results of using the original speci�cation, thus expanding the amount ofinformation that the user has access to during memory exploration, while stillmaking sure of the relevancy of the retrieved data to the designer's problem.The conditions under which the iterative process described above should26

end are subjective and context-dependent, so it is up to the user to decidewhen to stop. The computer environment can help by clearly indicatingand explaining the possible options, and prompting the user to choose fromamong relevant options at the right times, but fully automating the processwould make it in exible. An interactive system such as demex automatesthe tedious and routine aspects of experience-based design (eg., cataloguingpast cases, or matching new situations with old ones), but lets the user makethe �nal creative decisions (eg., combining di�erent parts of past cases toproduce a new solution, or modifying the speci�cations of a design problem).5 ImplementationAll of the examples shown above show cases and models that are containedin demex's knowledge base, and all of them illustrate capabilities that havebeen implemented in the system. The cases and models in demex are repres-ented using the Framekit frame representation language, compatible withCommon LISP. In Framekit a frame can have multiple slots, and each slotcan have many facets. A special facet is the \value" facet, which is generallyused to store the value(s) of a slot. Many times slots should have di�erent27

values in di�erent contexts, and because of this each facet in Framekit canhave many \views." This means that many values can be associated to a slotby de�ning many views (contexts) for its value facet. The following showsthe 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 StructuresThe pair of dynamicmemories which organise the cases and models in demexwas also implemented using Framekit. Each of these two memories isrepresented as a di�erent frame which serves as an indexing tree as discussedin Section 3. Figure 6 shows the organisational scheme of the case memory indemex (note that the names of the cases shown in this �gure don't actuallycorrespond to the cases stored in demex's memory; they are used here forillustrative purposes only). 28

In the Framekit implementation of these memories, the slots in eachframe correspond to the attributes that are used to describe the cases ormodels in the corresponding memory. The views of the value facet of eachof these slots are de�ned to be the values that the attribute correspondingto the slot can have.In models, attributes can have values or ranges of values. In theFramekitimplementation of the model memory, the special keyword \range" is re-served as the name of the view that holds the information about di�erentvalue-ranges (as opposed to values) for a particular attribute. Finally, theinformation that is associated to each view in the Framekit implementation(ie., the values given to the view) is the list of cases/models that in demexhave the attribute value represented by the view. The following shows aportion of the Framekit implementation of the case memory in demex:(Demex-case-memory(Support-building-type(Value(Office 130Elizabeth 370Pitt)(Residential TheHuntington)Etc.))(Location-of-core Etc.)Etc.)The result is a pair of two-level indexing trees, one for cases and one for29

models. The highest-level branches of each tree, implemented as Framekitslots, index by attribute name, and the second-level branches, implementedas views of the Framekit value facet, index by attribute values or valueranges. The leaves of the trees, implemented as values of the views, arethe cases/models known to demex. These are dynamic memories becausememory objects (cases or models) can be added (ie., learned) or deleted (ie.,forgotten) without disrupting the rest of the memory structure or contents,using simple demex functions that employ Framekit primitives.5.2 User InteractionThe retrieval strategies discussed in Section 4 operate on these two dynamicmemories and have been integrated into an interactive cycle of communica-tion between the user and demex. Figure 7 shows the types of informationinterchanged between demex and its users while the system is in operation.An additional memory structure is used to associate attributes with theircategories (Function, Behaviour, or Structure). This memory structure isimplemented as a LISP association list. If attribute categories are import-ant for a given memory retrieval, the associative memory that de�nes the30

categories of attributes is accessed �rst, and then those branches of the caseor model memory that don't correspond to attributes that have the \right"category can be ignored, while only the others need to be searched duringretrieval. The e�ciency and exibility of the retrieval of cases or modelsremains.A user's interaction with demex begins with the speci�cation of a designproblem, represented as a list of attribute-value pairs. The designer is ableto choose at all times whether he/she wants to perform model retrieval orcase retrieval using the problem speci�cation as a memory index. Whena memory retrieval �nds that several memory objects match the problemspeci�cation in some way, the user can either browse through the retrievedobjects to choose one to continue working with, or demex can determinewhich object matched the speci�cations the most (measured by countingthe number of attribute-value pairs from the speci�cation that match thevalue(s) or value range given for the attribute in the memory object). Thisbest-matching model or case is then selected automatically for subsequentprocessing. The rest of the model-based index elaboration and case-basedindex revision strategies have been automated as described in Section 4, andas shown in Figures 3 and 4. 31

6 DiscussionSome issues that needed to be resolved in the implementation of these strategiesas two separate approaches to exploration are:� Level of abstraction of initial memory access: Is general know-ledge of the domain or situation-speci�c knowledge accessed �rst (ie.,models or cases)?� Number of retrieved objects that play a role in subsequentmemory accesses: Is knowledge from the best matching memoryobject used, exclusively, or do all the objects that result from a probeinto memory contribute information? Note that the issue of rankingretrieved objects becomes important here.� Relative importance of the problem speci�cations: Are all ofthe attributes and/or all of the values present in the memory probe(initially assumed to originate from the user) treated in the same fash-ion, or do some play a larger role in retrieval (eg., because of di�erencesin their categories)? Note that the issue of ranking the components ofthe input to memory comes into play here.32

� Perfect vs partial match: Does the memory object have to matchwith all of the speci�cations in the memory probe (AND matching), oris it considered to be relevant if any of its features matches with someof the input speci�cations (OR matching)?� Termination condition: How do we determine the number/type/directionof iterations of memory search performed?� Role of original speci�cations: Are the attributes in the originalproblem speci�cation augmented and/or replaced by the informationprovided by the retrieved memory object?According to these issues, the retrieval strategies presented in section 4can be summarised as follows:� Model-based index elaboration (expansion of problem spe-ci�cation with derived attributes + identi�cation and elim-ination of non-critical attributes):{ The initial type of knowledge retrieved from memory is generalknowledge in the form of models.33

{ Out of the retrieved models, the one that matches best is the onethat provides the information required for subsequent processing.{ The attributes of the problem speci�cation are treated as havingthe same relative importance.{ All models that match at least one attribute in the problem spe-ci�cations are retrieved.{ A problem can be reformulated more than once before retriev-ing situation-speci�c knowledge, ie., several iterations can be per-formed.{ The problem speci�cation is augmented and/or reduced by theprocess.� Case-based index revision:{ This strategy begins by probing the case memory, so initial accessis to situation-speci�c knowledge.{ Information from one case only is used for further processing.{ All attributes in the problem speci�cation have the same relativeimportance in matching. 34

{ All models that match at least one attribute in the problem spe-ci�cations are retrieved.{ After the initial probe into case memory, a cycle of index revisionfollowed by case-memory access begins and is terminated by theuser, ie., many iterations can be performed.{ The attributes in the problem speci�cation can be changed, aswell as the values of some of the attributes.In conclusion, we have introduced, developed, and considered the use oftwo iterative retrieval strategies. The strategies as presented assume casesare described by attribute-value pairs grouped into three categories. As partof a design aid, models and cases may include constraints, images, drawings,etc., as well. The attribute-value pairs comprise the memory indices and theretrieval strategies operate on these indices. The remaining information ina case is retrieved with the indices and provides a presentation of the casefor the human designer and a starting point for case adaptation. The contri-bution of the work reported here is to make the retrieval strategies explicitas an approach to supporting the exploration of memory for improving theuser's understanding of a design problem.35

7 References[Gero 1990] J. Gero. Design Prototypes: A Knowledge Representation Schemafor Design. AI Magazine, 26-36. Winter 1990.[Goel and Pirolli 1989] V. Goel and P. Pirolli. Motivating the Notion ofGeneric Design within Information Processing Theory: The Design ProblemSpace. AI Magazine, 18-36. Spring 1989.[Kolodner 1984] J.L. Kolodner. Retrieval and Organizational Strategies inConceptual Memory: A Computer Model. Lawrence Erlbaum Associates.1984.[Maher 1987] M.L. Maher. Engineering Design Synthesis: A Domain In-dependent Representation. Arti�cial Intelligence for Engineering Design,Analysis, and Manufacturing, 1(3), 207-213. 1987.[Maher and Balachandran 1994a] M.L. Maher and B. Balachandran. Multi-media Approach to Case-Based Structural Design. Journal of Computing inCivil Engineering, Vol. 8 No. 3, 359-376, July 1994.[Maher and Balachandran 1994b] M.L. Maher and B. Balachandran. Flex-ible Retrieval Strategies for Case-Based Design. In Proceedings of the 3rdInternational Conference on Arti�cial Intelligence in Design, 163-180, Au-gust 1994.[Maher, Balachandran, and Zhang 1995] M.L. Maher, B. Balachandran, andD.M. Zhang. Case-Based Reasoning in Design. Lawrence Erlbaum Associ-ates. 1995.[Maher and Zhang 1993] M.L. Maher and D.M. Zhang. CADSYN: A Case-Based Design Process Model. Arti�cial Intelligence for Engineering Design,Analysis, and Manufacturing, 7(2), 97-110. 1993.[Schank 1982] R. Schank. Dynamic Memory: A Theory of Learning in Com-puters and People. Cambridge University Press. 1982.36

F

B

S

Function attributes

Behaviour attributes

Structure attributes

Models Cases

Case memory

Category-attribute associative memory

Model memoryFigure 1: The three dynamic memories in demex.37

Value A1

Attribute C

Case 3

Case 4

Case 5

Value A2

Case 5

Case 6

Case 4Case 1

Case 2

Case 3

Value B2Value B1

Attribute A Attribute B

Value A3

Attribute-

nodes:

Value-

nodes:

Root-

node:

Figure 2: demex's case memory organisation scheme.38

Model Memory

Initial Specifications

Retrieved Models

Initial Specifications

Add AttributesWith Known

Values

Finished?

ModelRetrieval

Closest Match

Select Best/

Retrieved Models

Selected Model

Initial Specifications

Selected Model

IdentifyCritical

Attributes

Augmented Specs.

Augmented Specs.

Selected ModelReduced Specs.

No Yes

Retrieval

CaseFigure 3: The algorithm for model-based index elaboration.39

SelectInteresting

Case

Retrieved Cases

Matching Attributes

Retrieved Cases

Retrieved Cases

Retrieval

CaseInitial Specifications

Case Memory

Revise

SpecificationsNew Specifications

AnalyzeRetrieved

CasesMatching Attributes

Selected Case

Finished?No Yes

Case

Adaptation

Initial Specifications

Selectred Case

Figure 4: The algorithm for case-based index revision.40

Indices:

Indices:

CASE

MEMORY

Retrieved case(s):Revised Indices:

Index revision can take inspiration from one part of a previous experience:

CASE

MEMORY

Retrieved case(s):

Revised Indices:

Index revision can result from considering parts of many past cases:

Figure 5: Di�erent sources of inspiration for producing an improved problemdescription. 41

WidthNo. of floors Core location

10 30 50

100 300

Hyatt Hotel

IBM Building

Bus Terminal

Bus TerminalStudent Centre

Student CentreInn on the Park

Inn on the ParkQantas BuildingFigure 6: demex's case memory.42

User DEMEX

Problem Specifications

Cases/Models

Commands/Choices

Alternatives

Process Control Information

DataKEY:Figure 7: Communication between demex and its users.

43