ABSTRACT - WIT Press this paper we present a new approach ... the automatic and consistent generation of decisions with its explanation and the propagation of design specification

Active design documents: From information

archives to design model construction or

making documents useful

A.C. Bicharra Garcia & H.C. Howard

Department of Civil Engineering, Stanford

CV1

ABSTRACT

A new approach to design documentation is presented forincreasing the quality of documents without increasing thedesigner's overhead in creating it. The central idea is to create aninitial design model able to generate and explain standard designdecisions. Instead of recording their decisions, designers adjust theinitial design model. The result is no longer a static record of thedesign, but an active document containing a design model able togenerate explanations for a design. We have implemented asoftware prototype for the active documents approach in the domainof preliminary design of Heating, Ventilation and Air Conditioningsystems (HVAC). The prototype test results indicate that theapproach is feasible. The results also indicate that activedocuments can be used beyond documentation as a tool forstudying design process.

INTRODUCTION

Most CAD systems are designed to assist designers to develop theirprojects. However, those systems do not support documentation ofthe process that originates a design; i.e., they do not register therationale that led to a design. That record is very important to

Transactions on Information and Communications Technologies vol 2, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517

234 Artificial Intelligence in Engineering

explain the design choices made during a design process. Eventhough it is general recognized that strong documentation able toexplain a design is desirable, designers do not have incentive tospend more time improving that documentation, since they do notdirectly benefit from it. In addition, even if designers do a carefuljob in documenting a design, they would still be recording a staticview of the design. Consequently, any question related to a changein design requirements (a very common occurrence [5]) wouldremain unanswered.

In this paper we present a new approach to documentation, theActive Design Documents (ADD) approach, that deals with thedilemma of increasing the quality of design documents withoutincreasing the designers' documentation overhead. According toADD's approach, a document is a design model. Consequently,documenting a design is generating the model of a design. If youcan gather the model that originates a design of a particulardesigner, you can explain it. The documentation overhead does notincrease because the approach requires the existence of an initialdesign model that minimizes the designers' participation in thedocumentation process itself. The new generated documentcontains a dynamic view of the document. This new approachintegrates design and documentation tasks. Therefore, thisapproach influences the way CAD systems should be designed.

Our discussion is divided in four parts. First we present theactive design documents approach. Next, we present animplemented and tested prototype for the domain of heating,ventilation and air conditioning (HVAC) systems. Then wecompare ADD's approach to different design rationale approaches.Finally, we discuss the use of active design documents in differentdomain areas.

ACTIVE DESIGN DOCUMENT APPROACH

We propose an approach to design documentation based on anactive document—active Design documents (ADD). The newdocument contains the design model used to develop a project by adesigner. Therefore, the new document is case and designerspecific. Using such a model produces design rationale that is nolonger simply a fixed recording, but rather an explanation that isgenerated by the design model.


Artificial Intelligence in Engineering 235

The active design document approach considers three agents forcreating, using and revising design documents (documentationlifecycle): an agent for creating, an agent for documenting, and anagent for understanding designs. According to this approach adesign document is a design model. Thus, documenting isexplicitly designing an artifact. The key aspect of this approach isto have a separate documentation agent responsible forunderstanding the design being developed by the designer agent andresponsible for explaining that design to the differentdocumentation user agents.

The documentation agent functions much like a humanapprentice to the designer. It contains a design model able togenerate expectations about the designer's decisions. Its role is toobserve the designer's steps and generate explanations for them.Whenever the documentation agent cannot explain the designer'sdecisions, it probes the designer for more information that wouldmake the documentation agent reach the same solution as proposedby the designer. In such cases, the designer adjusts thedocumentation agent's design model to make it able to generateand, consequently, explain the same design. At the end, thedocumentation agent has created a design model. Thedocumentation agent is able to generate answers for documentationusers' questions based on the model created during design. Figure1 illustrates a documentation model according to the active designdocuments approach.

As a result of this process, documentation is generated with littleor no overhead for designers. In addition, since the document is adesign model, the range of questions that can be answered by thenew document increaseas considerably. Questions such as "whatif or "why not" can be explicitly answered by the active document.

The two main interrelated problems to be addressed by any activedesign document are (1) how to acquire a design model forgenerating rationale and (2) how to deliver design rationale usingthe acquired design model. The interactions between theseproblems were mediated by using the concrete design modelunderlying the two processes. The next section presents animplemented and tested model for building active designdocuments that demonstrate the feasibility of the approach fordealing with the documentation problems in preliminary routinedesign.



design +rationale

DesignerAgent

InitialDesign codes ComponentKB Catalog

Knowledge.Acquisition

KnowledgeRetrieval

Adjusteddesign Design

Case

Documentation Agent

design +rationale

DocumentationUser Agent

Figure 1: An Active Design Document model.

AN ACTIVE DOCUMENT FOR THE PRELIMINARY DESIGNOF HVAC SYSTEMS

Design documents play an important role for communicating theintent of a designed device. Along with describing a designedsystem, a document should be able to reveal the issues consideredby designers when designing an artifact. However, there areusually many questions relevant to subsequent engineeringactivities that are difficult or impossible to answer from availabledocuments. A weakness of design documents is that they areinherently finite and cannot adjust to the needs of documentationusers. Active design document allows designers to create a designmodel instead of a design record; consequently, increasing thepotential of explaining a design.

We developed our research focusing on the documentationproblems of preliminary, routine design. The application domainwas preliminary design of HVAC systems. In this section, wedescribe the creation and use of design documents for HVACpreliminary design, an architecture for implementing activedocuments that should change, and initial results proving thefeasibility of the approach.



Describing the Design TaskBuilding design is usually developed in four phases: conceptualdesign, preliminary design, design development, and constructiondrawings. Even though there are many interactions between designphases, they can be considered as chronologically sequential. Eachdesign stage produces documents that address different issues.During the conceptual design phase, the design team develops thebuilding's concepts and requirements. This phase produces a set ofdocuments containing the set of requirements governing the design.In the preliminary design phase, each design trade develops a set ofalternatives that satisfy the set of design requirements developedduring conceptual design. After negotiation with the other designparticipants and approval by local building code inspectors, thedesign is detailed. Therefore, the document generated duringpreliminary design represents the design that is to be detailed. Thedetailed design drawings developed during design development andapproved by the inspectors are further specified to containconstruction instructions. This last document also needs to beapproved by the inspectors.

Designing an HVAC system is a routine task in which designershave in mind the parameters that need to be instantiated toconfigure the artifact. Besides constraints among the parameters,designers need to consider constraints imposed constantly by theother design trades and the criteria governing the design. A typicalHVAC design is composed of approximately 150 parameters thatinfluence each other. Even for quite ordinary designs, the quantityof information that needs to be included in design documents forsatisfying the different documentation users is large due to thislarge number of parameters. In addition, it is unfeasible during thedesign process to predict exactly which things future documentationusers will need. Also due to the large number of parameters and thedependencies among them, it is not unusual to find explanations oreven decisions that contradict the set of design specifications.

HVAC system design is both routine and based on a well-understood engineering field with much first-principles knowledgeand many heuristic rules that guide design. For this reason, it isfeasible to build an initial design model for maintaining designconsistency and allowing documentation users to question thedesign, which is the basis of the active design document approach.



An Architecture for Implementing an Active DocumentThe architecture we used to develop an active design document forthe preliminary HVAC system design contains the followingelements (see figure 2):

• the interfaces responsible for developing a design, acquiringadjustments on ADD's design models and explaining thedocumented design (the design, justification and explanationinterfaces, respectively);

• the design knowledge base, which contains knowledge aboutthe domain and knowledge about the specific case; and

• the reasoning components responsible for generating designdecisions, comparing those decisions with the designer'sdecisions, querying the user for additional knowledge as needed,preparing design reports, and controlling the documentationprocess (the anticipator, reconciler, knowledge elicitor, rationalegenerator and control, respectively).

As Figure 2 shows, designers retrieve information about theproject through the Design Interface. Designers use the interface todevelop their design. The design process consists of proposingvalues for design parameters, adjusting initial requirements andgenerating more requirements or design parameters.

Whenever a designer selects a parameter for being instantiated,the Anticipator is probed to generate an expectation for the value ofsuch parameter. To make a prediction, the Anticipator uses thedomain knowledge base (the parametric design and engineeringdecision-making models) and information about the specific designcase. It is a constraint-based reasoner; i.e., given some constraintsand a set of evaluation criteria, it is able to generate and analyzealternatives and propose a set of solutions. This module guaranteesthe automatic and consistent generation of decisions with itsexplanation and the propagation of design specification changes.

The Anticipator's expectation and the designer's value for aparameter are compared by the Reconciler for similarity. Bysimilar, we mean values that are either identical or in the samerange.



Hti"

^ | HVAC systemi designer

JustificationInterface

1 ADD's^Design

VvX,jX.¥-

Changes

----Model | Elicitor

ADD's value/rationaleUser's value

MatchDiagnosisi

User ModelArtifact Model

Domain HeuristicsDecision-Making ModelComponent Database,

Design Model

_

(CONTROLLER)

DesignCase

c

DesignCase

Design Cases

| Anticipator

ADD'svalue/

rationale

Topic

Design Changes

Design Model

Design Case

ExplanationInterface

DesignCase

rationaleI

RationaleGenerator

J

! Design '.

Documentation User •••-"." — .'.'::.'.' i ! .' question'.

Figure 2: Architecture for Implementing the Active DesignDocumentation model



When a mismatch between the Anticipator's and the designer'svalues is diagnosed, the Controller activiates the KnowledgeElicitor to gather more information from the designer. TheKnowledge Elicitor module works closely with the JustificationInterface, guiding the user in the model acquisition process. Thismodule interprets the information provided by the designer.

The Justification Interface aids the Knowledge Elicitor inpresenting the system's rationale for its expectation and allowingthe user to change the data and the rules guiding the design process.

The Controller supports the overall interaction cycle inanticipatory design. The Controller defines ADD's sequence ofactions, but not the order of designer's actions. It is often in idle

mode.

The design can be probed at any time by using the ExplanationInterface. The Explanation Interface allows the user to retrieveinformation, as well as, to change design specification to check theimpact on the design. In this last case, the Anticipator andReconciler are activated too. The Rationale Generator isresponsible for producing and selecting the information to bedisplayed to documentation users.

ADD's reasoning components using the knowledge base are theactive elements in the "active design document approach" and arelargely responsible for generating documentation automaticallywith very little support from designers. In addition, thesecomponents allow documentation users to better explore the designspace without the high overhead of maintaining consistent thedesign. This last feature is completely impossible for any otherstatic-based documentation approach.

The next section shows the results of initial tests using ADD fordocumenting and using real HVAC system projects. In addition, itpresents metrics for evaluating the documentation overhead interms of time to document a project.



Results from Empirical Testing of the HVAC Active Document

The successful implementation of an active design document andour experience with the test cases shows that the approach isfeasible. We invited two experienced HVAC system designers topropose designs for a 5-story office building in the San FranciscoBay Area. They use the active document to develop and documenttheir designs.

During these sessions, each designer was given an initial set ofspecifications—including the building blue prints, design criteria,the list of design participants, and the owner's requirements for thedesign. They were asked to prepare a preliminary design meetingthese specifications.

In both cases, all modules of ADD were activated, suggestingthat our architecture fits the needs of a documentation system. Thedesigners were able to develop and document successfully thedesign. In both cases, ADD could correctly anticipate most of thedesigners' decisions. The correct expectation was extremelyimportant for guaranteeing low overhead in the documentationprocess. Equation 1 shows us the importance of the highpercentage of right expectation for the success of the approach.

7V = 77i*r+77*(l-r) (1)

where:

Te is the time to enter rationale;

Th is the time to document a parameter automatically;

TI is the interaction time—the time spent adjusting ADD's

design model to match the user's decision; and

r is the anticipator's hit ratio.

Equation 1 tells us that the expected time depends on theanticipator's hit ratio. If ADD's model is very close to the user's,then r is approximately 1. In this case, the second term is nearlyzero and the expected time—the weighted average—isapproximately the same as the time for automatic generation (Th),which is very small. The exact values for these terms depend onthe knowledge base being used. If the knowledge base is tuned to



the user's practice, then r is close to 1. In such cases, ADD'sapproach imposes very little overhead on the designer. In our testcases, even though the initial design model was not tuned, theanticipation hit ratio was very high. This suggests that domain ismature and that the strategies used for designers do not have asignificance variance.

In addition to checking the feasibility of acquiringdocumentation, we also check the feasibility of delivering it. Weinvited two typical documentation users to verify the designdeveloped in the previous experiment. The sessions lasted from 1to 2 hours each. Even though they asked questions about thedesign, they were mostly fascinated by the ability to change designspecifications and check the design.

RELATED WORK

Many researchers in the area of design rationale have studied waysto support design documentation over the last few years. Threemajor approaches to design rationale have been proposed: to recordthe sequence of actions (history-based rationale), to record thearguments and issues raised during design (argumentation-basedrationale), and to record the device behavior model (device model-based rationale). However, these approaches are intended to bedomain-independent. Our experience suggests that a modestknowledge base of domain information can substantially improvethe documentation process Below, we evaluate the threeapproaches for dealing with the problems in documents ofpreliminary routine designs.

Models following the history-based rationale approach (e.g., [7]and [6]) propose to record the sequence of actions during a designsession as the sufficient material to reconstitute and, therefore, tounderstand a design. Even though this approach offers extremelylow overhead for constructing a document, it requires extremelyhigh overhead for understanding those records. In addition, there isno guarantee that the sequence of events can explain a design.

The argumentation-based approach (e.g., [2], [3], [8], and [9])offers more structured and logical organization of the information.However, designers are heavily engaged in the documentationprocess. They need to learn a framework to document their



discussion of the issues raised during the design. The documentgenerated is still a static view of the design.

The device model-based rationale approach (e.g., [4] and [1])proposes to capture the device model for explaining a design. Thisapproach captures a dynamic view of the process. However, sinceit starts with no knowledge of the process, it requires an enormouseffort from designers to provide the model. Also, the model beingcaptured is incomplete since the information about form, functionand behavior of a device is insufficient to explain a design. A fullydesigned model containing a decision-making model is necessary toformulate hypotheses to explain a device.

FINAL REMARKS

In this paper we presented a new approach for documenting design.The active design document approach uses a separate agentworking with the designer to create and retrieve design documents.This agent frees designers from the documentation activity andprovides a systematic way of checking the design consistency. Webelieve that this approach can decrease the designer'sdocumentation overhead if it is practical to build a design modelthat covers a significant range of the decisions, leading to a highanticipation hit ratio.

In addition to improving design documents, active documentsoffer a media for studying the design process itself. By using activedocuments, design methods can be compared through the samemetrics, design strategies can be observed and new design methodsmight be proposed.

REFERENCES

1. Baudin, C, Sivard, C, & Zweben, M, Using device models anddesign goals for design rational capture,. NASA AmesResearch Center, Technical Report M.S. 244-17, 1989.

2. Conklin, J. & Begeman, M. L., "gffilS: A hypertext tool forexploratory policy discussion," pages 140-152, Proceedings ofthe 1988 Conference on Computer Supported Cooperative Work(CSCW-88), Portland, Oregon, 1988.



3. Fischer, G., Lemke, A. C, McCall, R., & Morch, A. L, "MakingArgumentation Serve Design," Human-Computer Interaction,Vol. 6, No. 3/4, 1991.

4. Gruber, T. R. and D. M. Russell, "Generative design rationale:Beyond the record and replay paradigm," in Design Rationaleed. Erlbaum, L., 1992.

5. Guindon, R., "Designing the Design Process: ExploitingOpportunistic Thoughts," Human-Computer Interaction, Vol. 5,pp. 305-344, 1990.

6. Karinthi, R., "Capturing Design Rationales for Use in aConcurrent Engineering Environment," AAAI '92 Workshop inDesign Rationale Capture and Use, San Jose, CA, 1992.

7. Lakin, F., Wambaugh, H., Leifer, L., Cannon, D., & Sivard, C.,"The electronic design notebook: Performing medium andprocessing medium," Visual Computer: International Journal ofComputer Graphics, Vol. 5, No. 4, pp. 214-226, 1989.

8. Lee, J., "Incremental Acquisition and Formalization of DesignRationale," AAAI '92 Workshop on Design Rationale Captureand Use, San Jose, CA, 1992.

9. MacLean, A., R. Young, et al., "Questions, Options, andCriteria:Elements of A Design Rationale for User Interfaces,"Human Computer Interaction, Vol. 6, No. 3/4, 1991.
