~ in complex tasks,' we decided to. (1) The system should support common design tasks but leave all decisions to

Transcription

1 ndcate makng U A Case Study n Archtectural Desgn Mchael Pearce, Galaxy Scentfc Corporaton Ashok K. Goel, Janet 1. Kolodner, Crag Zmrng, Lucas Sentosa, and Rchard Bllngton, Georga nsttute of Technology facts nvolves a seres of decsons. To desgn an offce buldng, you mght make decsons about applyng abstract desgn concepts and skeletal desgn plans, selectng specfc systems and components, retractng earler decsons, relaxng desgn constrants, acceptng desgn solutons, and so on. How hard t s to make these decsons WE WANTED TO FND OUT WHETHER A LARGE CASE LBRARY COULD SUPPORT HUMAN DECSON MAKNG N A COMPLEX TASK SUCH AS DESGN. WHLE SYSTEM MET MANY OF OUR GOALS, WE LEARNED JUST AS THE ARCHE MUCH FROM TS LMTATONS. decsons. For the offce buldng, we mght but are scattered n fle cabnets, magahave many possble spatal confguratons znes, books, and the memores of other that do not correspond drectly to desgn, desgners. Some large archtectural frms constrants, makng t hard to select among ~ have small lbrares of propretary desgns, them. f the archtect does not have the but typcally they are ndexed wth just a approprate knowledge, poor decsons-, few mnemonc features that do not always and poor desgns-can result. Thus, pro- ~ a past desgn's relevance to a curvdng good decson support for archtects ~ rent desgn problem. and other desgners s a real challenge for To fnd out whether large case lbrares researchers on ntellgent computer-aded can support and mprove human decson desgn. ~ n complex tasks,' we decded to access to doman experts and experence as nave users of offce buldngs. (3) The system should support conceptual as opposed to detaled desgn, because ths s generally the more dffcult and nnovatve part of the process, and becausetheseearlydecsons haveamajor mpact on what follows. We also decded to support desgn proposal and crtqung, two subtasks of conceptual desgn. choces. However, despte the apparent ~ abundance and extensve use of past de- ~ sgns n decson makng, archtects do not always have easy access to approprate cases. They are not organzed n lbrares, (1) The system should support common desgn tasks but leave all decsons to the user. (2) The system should apply to the desgn of offce buldngs, because we had represent, ndex, and retreve archtectural desgn cases, our early work focused on developng a vocabulary for representng and organzng such cases n a lbrary, and on schemes for retrevng those relevant to 14 OXX5/9000/92/ $ EEE ~- -~.. EEE EXPERT

2 0-Goal Group nteracton Very mportant 0-Goal Organzaton type Fgure 1. A desgn case n Arche. a gven desgn task. Whle buldng and usng Arche, we encountered other ssues whose mportance we dd not fully apprecate at frst, but that we are now explorng n two parallel projects: Arche2 and Arche Tutor. lllustra tve examples Arche helps archtects n the hgh-level task of conceptual desgn as opposed to low-level tasks such as drawng and draftng, numercal calculatons, and constrant propagaton. Proposng a desgn. Arche gves archtects access to offce buldng desgns created by other archtects, and ponts to factors that must be consdered n solvng a gven desgn problem. Each case n Arche contans several types of nformaton (see Fgure 1 )?: desgn goals (such as group nteracton) andconstrants (such as a partton heght above eye level): desgn plans that specfy buldng components (such as walls, doors, and furnture) and a satsfactory confguraton; outcomes that descrbe how well the plan satsfes ts goals and constrants (explct and mplct) from a specfc pont of vew (for example, a desgn outcome could be that audtory prvacy was low); and lessons to be learned from the case (not shown), ndcatng n whch stuatons the case wll be useful, provded to the user as text annotatons so they are easy to understand. The goals and outcomes prefxed by 0 n the fgure pertan to the clent organzaton and descrbe the people who use the buldng and ther nteractons wth that buldng. The goals, plans, and outcomes prefxed by C descrbe the core, or permanent aspects, of the buldng. For example, the total area of the desgn descrbed n Fgure s about 14,500 square feet and s lkely to reman the same over tme. Features prefxed by P specfy the buldng parttons, the nonpermanent nteror structures that dvde the space. For example, one changeable aspect ofthe plan n Fgure 1 s that the manager s offce has glass walls. Features prefxed by F represent furnture. For example, one outcome of the desgn n Fgure 1 s that the furnture color was pleasng. A sesson wth Arche begns as a clent outlnes a set of requrements for an offce buldng-let s say offce space for a small accountng frm: Snce customers frequently vst the company offces, the mage projected by the offce space s very mportant. Gven the nature of the work to be done there, the offces need facltes for faceto-face contact and group nteracton. The company s dynamc and growng, so the desgn should allow for future modfcatons. Snce the company mantans paper fles on ts clents, the offces must have a good flng system. The company needs about square feet of space and has budgeted $300,000 for parttons and furnture. The archtect uses Arche s vocabulary to prepare a probe representng the customer s

3 ~~~~~~ ~ ~ ~~ ~ ~~ ~ smlar desgn problems, and can combne solutons from several cases to create a hgh-level qualtatve desgn that acheves the clent s goals. For example, the case n Fgure 1 uses an open offce plan to acheve flexblty, face-to-face contact, and group nteracton. An open archtectural plan mples low, movable parttons to separate offce spaces rather than fxed celng-tofloor walls. Snce face-to-face contact and employee nteracton are mportant desgn goals n the current problem, the archtect mght adopt the open offce plan of the prevous case. The archtect copes features from nterestng cases to produce a partally specfed conceptual desgn for the new offce buldng. n ths way, Arche helps archtects branstorm by lettng them explore prevous cases for deas and nspratons. Fgure 2. Probng Arche s case memory. Color shade FGe 3. Model of lghtng qualty. desgn goals and constrants (see Fgure 2) Each box n the fgure represents a feature n the probe The feature s name s on the left, ts balue s on the rght, and the label\ to the rght ot each box descrbe the type ot value t can tdke Fedtures n probes use the same 0, C, and F prefxes that case features use (see Fgure 1) Havng receved a probe, Arche cdlcu- lates a smlarty value for each stored case based on how close each concept value s to specfed values n the probe and on the concept s mportance. t retreves cases whose smlarty value s above a predetermned threshold. Fgure 1 s part of a case retreved by the probe n Fgure 2. Browsng through the retreved cases, the archtect sees how other archtects solved Crtqung a desgn. Wth a partally specfed conceptual desgn n hand, the archtect can now crtque the desgn to locate potental problems. Ths mode of operaton nvolves more focused reasonng: The archtect wants detaled nformaton wthn a narrow context. For example, the archtect may be concerned wth the qualty of lghtng n a proposed offce desgn, and selects one of several qualtatve doman models n Arche that represent the perspectves of dfferent experts on that aspect of the desgn (see Fgure 3). Fgure 4 shows the part of a retreved case that pertans to lghtng, ncludng desgn goals, plan crtques, lessons learned, and so on. Comments on the case are expressed as text annotatons (shown n shaded boxes): Goal comments refer to nteractons among desgn goals, plan comments specfy ndvdual desgn decsons and ther relatons to goals, outcome comments explan the outcomes, and case comments provde general background on the buldng s desgn. The 0-Outcome: Moral lst, enclosed n adouble box. specfes the lessons learned from the case. The C-Outcome: Lghtng Satsfacton- Artfcal feature, also enclosed n a double box, shows that the glare problems that led Arche to retreve ths case were caused by artfcal lghtng. The 0-Outcome: Moral tells the archtect how to modfy the proposed desgn (by usng dffusers over bulbs). After fxng ths aspect of the desgn, the archtect mght smlarly crtque the 16

4 ~~ ~ ~~~ ~ ~~ ~~~ ~~~ ~ ~ ~~~~~~~. ~~~~~ ~~~~~~ ~ *Desgn for a wde varety of users *All offces have fxed parttons, no *Not much nteracton wth workers nformaton technology modular furnture used except n outsde workgroup Goal Plan secretary bays Outcome Easy to adjust workgroup sze comments comments Central hallway wth offces on comments both sdes (managers on outsde) *Hodgepodge of furnture systems gure 4. Case features assocated wth lghtng qualty. -~ desgn from other perspectves. Ths process of retrevng, crtqung, and adaptng contnues untl the archtect s satsfed wth the desgn. System mplementaton We bult Arche usng Remnd, Cogntve Systems case-based knowledgeengneerng shell. The tool lets programmers desgn a case representaton, enter case nformaton, set up a retreval mechansm, and desgn a presentaton format. Remnd ncludes a graphcal functon edtor for dynamcally computng features, a drect manpulaton edtor for desgnng ~. case dsplays, and a retreval explanaton edtor. All the fgures n ths artcle are based on Arche screens that were produced usng Remnd. Cases n Arche descrbe specfc buldng desgns. We collected about 20 cases from three sources. Some are based on our experences n the offce buldngs where we (one or more ofthe authors) have worked. We also used professonal archtectural journals, whose artcles typcally deal wth a specfc aspect of a buldng such as aesthetcs, furnture systems, lghtng systems, and so on. Fnally, we used postoccupancy evaluatons wrtten by archtects and researchers who were tryng to dentfy the sources of a buldng s problems and suggest ways (based on cost and effort) to fx them. Thus, the qualty and completeness of nformaton n Arche s cases vary wdely. Knowledge organzaton. Arche contans three knds of knowledge: prmtve concepts, doman models, and desgn cases. Prmtve concepts refer to the prmtve objects, relatons, and parameters of offce buldngs, and form part of the language for representng and ndexng cases. Doman models capture the causal relatonshps among case concepts. Cases n Arche are represented as flat, statc frames, each wth more than 150 possble features Features can be concepts, text, ntegers, real numbers, or functons Most features are concepts, wth some numbers and text Arche s features orgnated from three wurces From our analyss of offce buld- ngs, we developed features that dfferentate one buldng from another, ncludng descrptons of users, rooms, equpment,, and users lkes and dslkes. Other fea-, tures came from the doman models that descrbe outcomes. For example, the color of the walls, floor, and furnture all affect the amount of glare n a offce, so these features were added to the representaton 1 language. Fnally, some features developed from usablty ssues. Understandng a case by readng the concept features n ts descrpton can be dffcult because of the large number of features. Snce users must understand the ponts a case s tryng to make but don t have to understand Arche s representaton scheme, we added textual features to create a more natural nterface. The number of features n Arche grew rapdly as we analyzed the frst few cases, but then stablzed after about 10 cases. Case retreval. Remnd gves Arche two mechansms for retrevng cases: nearest-neghbor matchng and model-based clusterng. These mechansms are used n the branstormng and focused-problem- ~~ 17

5 Fgure 5. A partal concept herarchy. solvng modes of operaton, respectvely, whch we descrbed earler. Prmtve concepts and nearest-neghbor matchng. Arche uses nearest-neghbor matchng and prmtve concepts to retreve buldng desgns that satsfy a problem s goals and constrants. The concept features that form Arche s representaton language are organzed herarchcally to specfy the goals, plans, and outcomes of desgn cases. Concept slots are the most mportant features for case retreval because they represent classes of objects and ther partal orderngs. Some of Arche s concepts pertan to doman objects such as lghtng devces; others are more abstract, such as lghtng qualty. Fgure 5 shows a small subset of these concepts. Concept nodes wth squares n ther boxes have subnodes that can be expanded nto the values that the concept can take. For exam- ple, Arche knows that lghtng devces can be fluorescent, halogen, or ncandescent. The < relaton n the fgure ndcates partally ordered concepts. Doman models and model-based clusterng. Arche s second retreval method uses smple doman models to cluster cases n memory. These models represent Arche s doman knowledge about offce buldng desgn. For example, accordng to Arche s causal model of lghtng (see Fgure 3), satsfacton wth lghtng depends on the qualty of lght and the glare ntensty (the nodes wth rounded corners). The lower half of the model captures knowledge about the factors that lead to glare n an offce: the shade of the wall color, the shade of the floor color, and so on. The nodes on the far left n the fgure are case features. The postve (and negatve) sgns ndcate that as the value of a case feature ncreases, the value of the feature beng ponted to ncreases (or decreases). For example, as the shade of the wall color ncreases from lghter to darker shades, the glare ntensty decreases, whch ncreases the overall satsfacton wth the lghtng. To crtque a proposed desgn s lghtng qualty, an archtect mght select the lghtng model shown n Fgure 3. Arche uses ths model to cluster cases by the features that affect the lghtng outcome, and the resultng classfcaton tree s shown n Fgure 6. The rectangular boxes specfy the tree s parttonng nodes and the names of correspondng features from the lghtng model. The boxes wth rounded corners represent case clusters, and the text descrbes the outcomes of the cases. Arche retreves the approprate cases and predcts the outcome of new desgns based on ths tree. For example, the rounded box wth the text 1 Glare Case and ts placement n the classfcaton tree ndcate that Arche has only one case wth low lghtng qualty and hgh glare ntensty. f the features of the current desgn lead Arche to predct ths outcome, the system retreves 1 Glare Case and dsplays t to the archtect. n ths way, Arche s models help archtects crtque proposed desgns. lessons learned n developng Arche, we learned several practcal lessons about buldng large 1 No control over level Case 1 Fgure 6. Clusterng of cases based on the lghtng model. 18 EEE EXPERT

6 case-based systems to support real-world decson makng. Lesson 1: Real-world cases are ncomplete. Whle the doman of archtectural desgn contans an abundance of cases, t s not easy to fnd well-documented cases of offce buldng desgns. Drawngs and pctures are readly avalable, but ther case analyses are often ncomplete, and justfcatons for the archtect s desgn decsons and outcomes are generally not known. Even the desgn goals and constrants are often unclear. Ths severely lmts the usefulness of past cases n makng new desgn decsons. t s also one of the reasons why Arche contans only about 20 cases. So how do we acqure well-documented cases? Or, how do we use ncomplete cases to support decson makng? The best practcal soluton mght be to settle for many semdocumented cases rather than a few fully documented ones. Ths approach wll requre robust reasonng procedures that can process ncomplete and possbly nconsstent case descrptons. t mght, for example, requre procedures to combne nformaton from multple cases n a way that detects nconsstences. Lesson 2: Real-world cases are large. Arche needs a large vocabulary to capture enough nformaton about a case to make t useful n dfferent stuatons. A welldocumented case mght contan a huge amount of potentally useful nformaton about clents, desgn goals and constrants, desgners, desgn hstory, the desgn plan, post-occupancy feedback and analyss, and so on. The large sze of cases s another reason why Arche contans only about 20 cases: Much effort s requred to gather ths much nformaton. Ths presents problems for buldng a case-based decson-support system, ncludng how to represent case content and ndex and dsplay cases. For example, there s a large gap between the gran sze of avalable cases and the gran sze of decsons the archtect needs to make. t s not easy to extract fne-graned nformaton from Arche s large-gran cases. n Arche 2,4 we are tryng to organze large cases nto case-subcase h er arc he^.^ However, ths soluton rases several more complex ssues, ncludng the dmensons nto whch a case can and should be decomposed. For example, the Jula system OCTOBER 1992 ~ structurally decomposes meals to desgn menus.6 The Krtk system, whch desgns electrcal and mechancal devces, decomposes devces functonally and structurally. We could do the same wth offce spaces. For example, we could structurally decompose an offce buldng nto floors, and the floors nto offces, corrdors, and so on; we could also decompose the same buldng functonally nto dfferent types of offces and other spaces. The organzaton of case-subcase herarches rases another ssue: how to present nformaton about a case s nternal organzaton so that a user can easly navgate through subcases. The format must enable navgaton both wthn and across cases. Lesson 3: Systems must offer users multple types of knowledge. Snce our ntal goal was to nvestgate the role of case-based reasonng n desgn, Arche provdes only an external memory of desgn cases; archtects cannot access the doman models themselves. However, as the project progressed, we realzed that access to the models mght be useful, especally because archtects often use multple types of knowledge when desgnng buldngs. Access to both models and cases mght be especally useful for archtecture students, because they are creatng explct nteractons among doman objects and processes. n Arche Tutor, we are nvestgatng how to represent desgn cases and rules as well as doman models, and how to gve archtects access to all three knds ofknowledge. Dfferent types of knowledge wll need to be cross-ndexed, so that the user can navgate from one type to another; for example, from a desgn case to a doman model that explans some porton of the case, to a desgn rule abstracted from the model, to another case that llustrates the rule. Krtk provdes a scheme for crossndexng desgn cases and causal models7 AskJef, whch helps software engneers desgn human-computer nterfaces, provdes a scheme for cross-ndexng desgn cases and desgn rules.8 Such drect access to dfferent types of knowledge requres a taxonomy of decsons and decson contexts that the prospectve user mght face. t also requres an ndexng scheme that maps classes of decsons and ther contexts nto the dfferent types of stored knowledge. Lesson 4: Systems must present rele- vant nformaton. Arche uses a set of statc forms (the same ones for proposng and crtqung desgns) to present nformaton. Each form corresponds to a vew of the system (such as the lghtng model) and specfes a subset of case features and an arrangement for dsplayng them. Presented wth achoce of forms, the archtect selects one relevant to the task at hand. Snce the forms are statc, nether the archtect nor the system can dynamcally restructure the nterface to make mportant nformaton more salent. However, snce Arche s cases are used for both proposng and crtqung, dfferent chunks of nformaton are more or less mportant n dfferent phases of the desgn process. Also, snce our early work focused on representaton, we desgned the nterface more for knowledge engneerng than for use by archtects. t soon became obvous that the nterface was too panful to use by anyone other than a knowledge engneer. Even f Arche had many well-documented cases, t would not be usable untl t could present nformaton n a quckly and easly understood format. We are now explorng usablty ssues, especally how to best present large amounts of knowledge to user^.^^^ A RCHE goes beyond supportng archtects n desgn proposal and crtqung. t acts as a shared external memory that supports two knds of desgn collaboraton. Frst, by ncludng enough knowledge about the goals, plans, outcomes, and lessons of past cases, t lets the desgner access the work of prevous archtects. Second, by provdng access to the perspectves of doman experts va the doman models, Arche helps archtects antcpate and accommodate experts vews on evolvng desgns. The system accomplshed many of the goals we had n mnd when we started the project. ts vocabulary s stable and expressve enough to represent and ndex both exstng and new cases. However, the current verson of Arche s only partally successful n supportng archtectural desgn. ndeed, some of the most mportant contrbutons of the Arche experment are the lessons we learned from ts lmtatons.

7 Acknowledgments Sambasva Bhatta, Thomas Hnrchs, Al Malkaw, and Danel Wllham worked on the orgnal Arche system. The Arche 2 team ncludes Rchard Bllngton, Joshua Bleer, Erc Domeshek, Janet Kolodner, Anna Zacherl, and Crag Zmrng. The Arche Tutor team ncludes Ashok Goel, Km Lu, Al Malkaw, and Mchael Pearce. The AskJef group ncluded John Barber, Sambasva Bhatta, Ashok Goel. Mark Jacobson, Mchael Pearce, Louse Penberthy, Mural Shankar, Robert Smpson, and Elen Stroula. Work on Arche has been supported by agrant from the US Defense Dept. s Advanced Research Projects Agency, montored by the Ar Force Offce of Scentfc Research under contract F c References 1. J. Kolodner, mprovng Human Decson Makng Through Case-Based Decson Adng, A Magazne, Vol. 12, No. 2, 1991, pp A. Goel et al., A Case-Based Tool for Conceptual Desgn Problem Solvng, Proc. Thrd DARPA Workshop on Cuse-Bused Reasonng, Morgan Kaufmann, San Mateo, Calf., 1991, pp Case-Based Retreval Shell Users Manual, Cogntve Systems, Boston, Jan E. Domeshek and J. Kolodner, A Case- Based Desgn Ad for Archtecture, Proc. Second nt l Conf on A n DesRn, Kluwer Academc Publshers. pp , Norwell, Mass., 1992, 5. M. Redmond, Dstrbuted Cases for Case- 1 Based Reasonng: Facltatng Use of Mul-, tple Cases, Proc. Eghth Nut Con$ Artfcal ntellgence (AAA1 90). Morgan 1 Kaufmann, San Mateo, Calf., 1990, pp T. Hnrchs, Problem Solb ng n Open 1 Worlds: A Case Sfudy n Desgn, doctoral dssertaton, College of Computng, Georga nsttute of Technology, Atlanta, A. Goel, A Model-Based Approach to Case Adaptaton, Proc. 13th Annual ConJ: Cogntve Scence Soc., Lawrence Erlbaum, Hllsdale, N.J., 1991, pp J. Barber et al., AskJef ntegraton of Case-Based and Multmeda Technologes for nterface Desgn Support, Proc. Second nt l Conf. A n Desan. Kluwer Academc Publshers, Norwell, Mass., 1992,, pp Mchael Pearce s a software engneer at Galaxy Scentfc Corporaton, where he bulds ntellgent tutorng systems. He receved hs MS n nformaton and computer scence from the Georga nsttute of Technologyn 1991.Hs current research nterests nclude man-machne nterface desgn, ntegrated tranng and job-adng systems, theory of desgn, and the learnng of robot navgaton. He can be reached at Galaxy Scentfc Corp., nformaton Dvson, 3210ParklakeDrve, Sute 325, Atlanta, BA Ashok K. Goel s an assstant professor n the College of Computng at the Georga nsttute of Technology. Hs research focuses on plannng and desgn problem solvng, qualtatve modelng and model-based reasonng, and cased-based reasonng and learnng. He receved hs MS n physcs and hs PhD n computer and nformaton scence from Oho State Unversty. He chars the Artfcal ntellgence Techncal Commttee of the EEE Systems, Man, and Cybernetcs Socety. Janet 1. Kolodner s a professor of computer scence n the College of Computng at the Georga nsttute of Technology She receved her PhD n computer scence from Yale Unversty n Havng poneered the development of case-based reasonng, she s concentratng on applyng that method to desgn, and on the Crag Zmrng s assocate professor of archtecture and psychology at the Georga nsttute of Technology. He receved hs PhD n envronmental psychology from the Unversty of Massachusetts at Amherst. Hs research focuses on studyng and developng collaboratve desgn and evaluaton tools and processes for buldng plannng, desgn, and evaluaton. He s a member of the Envronmental Desgn Research Assocaton and the nternatonal Assocaton of People and Ther Physcal Settng. Lucas Sentosa s a doctoral canddate n archtecture at the Georga nsttute of Technology. He receved hs Master of Archtecture degree from the Unversty of Colorado at Boulder. Hs research nterests nclude envronment behavor studes and computer-asssted space management n archtecture. Hs photograph was not avalable R...mrd Bllngton s a research scentst at the Georga nsttute of Technology and vce presdent of the Assocaton of Lsp Users. He receved hs MS n nformaton and computer scence from the Unversty of Pennsylvana. Readers can reach the authors n care of 9. A. Goel et al., Arche: A Case-Based Ar- mplcatons of CBR for decson adng, edu- Ashok Goel, College of Computng, Georga chtectural Desgn System, Tech. Report caton, and creatve problem solvng. She s nsttute of Technology, 801 Atlantc Drve, GT-CC-9 1/18, College of Computng, edtor-n-chef of The Journal ofthe Learnng Atlanta, CA 30332, or by e-mal at Georgalnst. oftechnology, Atlanta, ~ Scences. _ - ~ - ~ ~ ~ ~ ~ ~ ~ - ~ _ ~ F EEE EXPERT ---~~~ ~ ~ ~ ~- ~ ~ ~ 1