Mark Klein
Boeing Computer Services
When an artifact is designed nowadays the typical output of this activity includes blueprints, CADfiles, manufacturing plans and other documents describing the final result of a long series ofdeliberations and tradeoffs by the participants of concurrent engineering (CE) teams. Theunderlying intent and logical support (i.e.therationale ) for the decisions captured therein is usuallylost, or is represented at best as a scattered collection of paper documents, project and personalnotebook entries as well as the recollections of the artifact’s designers. This design rationaleinformation can be very difficult to access by human agents and is represented such that computerscan provide little support for managing and utilizing it.
The challenges of intensified global competition and the growing complexity of the artifacts wedesign are making it increasingly critical that design rationale be captured in a highly usable form.The potential benefits of such capture are manifold. Explicitly represented rationale can helpindividual designers clarify their thinking about a design [12, 5, 7, 6]. Perhaps more importantly,rationale capture can support design by CE teams over time. The reasoning behind decisionsbecomes available for all team members to critique and augment [5]. Participants affected by designchanges can be identified readily [6]. Existing designs which addressed similar requirements can beretrieved, understood and modified to meet current needs [8]. The causes and potential resolutionsfor conflicts between designers can be identified [3]. Design decisions can be easily documentedfor new team members, new designers and artifact users [1].
In order to achieve these benefits, however, significant challenges must be met. Therepresentation we use must allow designers to express their design reasoning in a natural way whileat the same time be formal enough to support useful computational services. Since CE teamsinclude multiple participants working on overlapping aspects of the design, concurrent editing mustbe supported. In addition, the process of describing rationale should impose the minimum possibleoverhead on the design process.
Most existing rationale capture approaches support only individual users and are thus not suitedto team contexts (but see [5, 12]). More importantly, most [5, 12, 7, 6] capture the rationale fordecision-making in general but not design in particular; they simply add yet another document tothe set produced by existing design tools (Figure 1).
1 Appears in: IEEE Computer Journal. Special Issue on Computer Support for Concurrent Engineering. January,
1993.
- 1 -
Figure 1. Rationale Captured as a Distinct Document.
Such approaches have limited expressiveness and therefore limited computational usefulness. Thecorresponding rationale capture tools face the potential of inconsistency between the rationale anddesign descriptions as well as spotty capture of design rationale and the tendency to waste time onissues that later prove unimportant; the designers cannot focus their discussion on issues revealedby actual inspection of the evolving design description [2].
What we really need are systems that allow CE team participants to conveniently describe thedependencies between decisions captured by existing design tools (Figure 2).
- 2 -
decision, similarly, is justified in terms of supporting decisions like project schedule and geometrydecisions. While systems that integrate design and rationale representations do exist (e.g. [2]), theyuse highly domain-specific design representations (e.g. for kitchen design) not easily generalized toother domains. The fundamental challenge, then, is to provide an integrated and generic frameworkfor capturing rationale in team contexts.
In this paper we describe a design rationale capture system called DRCS (the Design RationaleCapture System) that was designed to meet this challenge. The rationale language underlyingDRCS was built upon previous work on decision rationale capture as well as a generic model ofdesign reasoning and is designed to capture in a natural way all important aspects of designdecisions and their inter-relationships. The DRCS system itself explores how design systems canbe enhanced to support collaborative editing of designs and their rationale. The DRCS language, theDRCS system and possible directions for future work will be discussed in the sections below.
2. The DRCS Rationale Language
The DRCS rationale language captures design reasoning using a vocabulary of assertionsconsisting of entities like modules, tasks, specifications and versions as well as claims about theseentities. Claims come in two main types. A pre-defined vocabulary of relation claims describesrelationships between assertions. Any claim can serve as part of the rationale for another claim, sowe can make claims about the design (e.g. module-1 has-submodule module-2), claims describingrationale for design decisions (e.g. value-1 is-derived-from procedure-1), claims concerning whywe should believe this rationale (or not) and so on recursively. There is also an all-purpose textclaim used to capture information not otherwise expressible. The net result of describing designsand rationale in this way is a graph of entity and text claim instances connected by relational claims.In the paragraphs below, the vocabulary of claims and entities that make up the DRCS rationalelanguage will be described, followed by several examples. The language will be divided, forexpository purposes, into five components. As we have seen, design reasoning consists ofdefining/tracking design requirements (i.e. evaluation) as well as synthesis. Designers usually havesome intent underlying a given action, as well as supporting arguments for believing that the actionis appropriate. Since there are often multiple options for any decision, designers generally explore aspace of multiple alternatives, or versions. Each of these aspects will be considered separately.2.2.1. Synthesis. The DRCS language synthesis component is responsible for capturing the actionsused to define artifacts and plans. Let us consider artifacts first; the language entities for thispurpose are shown in Figure 3 below:
- 3 -
Is Of TypeConnectionHas InterfaceConnectsHas-SubmoduleHas-SpecializationIs Of TypeIs Of Type
InterfaceModuleHas AttributeAttributeHas ValueConstraintIs Of Type
Has AttributeFigure 3: Artifact synthesis entities and relationships.
In this and the following figures, primitive entities in the DRCS language appear in plain font, whilerelation claims appear as directed arcs with italic labels; the latter signify that the given relationshipcan hold between the entities ate the arc source and target. Entities with the “is-of-type” relationhave an associated type taxonomy that a user can select from.
The basic entities for artifact description include modules, attributes, interfaces and connections.Modules can have submodules or specializations. Attributes can have values, expressed using aconstraint language. Constraint languages are used to express indefinite descriptions, and have beenused extensively in numerous design and planning systems [9]. The DRCS constraint languageprovides a wide range of constructs including “absolute” constraints like inequalities, ranges andsets as well as “relational” constraints such as boolean and mathematical equations.Plan descriptions are captured as follows (Figure 4):
Has PriorityHas Greater Priority ThanHas-SubtaskHas-Temporal-RelationshipIs Of TypeTaskHas PlanModule
Attribute
Constraint
- 4 -
decomposition of a top-level task into temporally ordered subtasks with associated primitiveactions. This is captured using “has-subtask”, “has-action” and “has-temporal-relationship”(e.g. “comes-before”, “comes-after”) claims. Task actions can be any assertion. Plans can havepriorities. For both artifacts and plans, an important kind of attribute is the “uses-resource”attribute. When defining this, one specifies the type of the resource as well as the amount used.Resources can include time, weight, money, tools, people and so on.
2.2.2. Evaluation. The evaluation component of the DRCS rationale language is used to capturedesign specifications as well as how well they have been achieved (Figure 5).
Has SubspecificationIs More Important ThanHas ImportanceIs Of TypeAttribute
Has-SpecificationVersion
Figure 5: Evaluation entities and relationships.
Design and plan specifications are defined as desired values (using the constraint language) fordesign and plan attributes. Attributes and specifications can have different types, priorities andsubsumption relationships. Attributes and specifications can have types. Specification types includeobjectives, requirements and preferences, and differ in how critical they are and thus by implicationhow willing we are to relax them. A design version can be said to achieve a given specification;precisely how is described in the rationale for that claim (see below).
2.2.3. Intent. Whenever a designer takes some kind of design action, he or she is usually pursuing astrategy to find an answer for some problem; i.e. has some intent when taking that action. This iscaptured in DRCS as follows (Figure 6):
- 5 -
and so on. Some decision problems can have greater priority than others. The strategy used toaddress a decision problem is represented as a “has-strategy” link to (the top-level task of a) plan.2.2.4. Versions. The versions model is used to capture how the designer creates and explores thespace of design alternatives (Figure 7).
Decision Problem
Procedure
- 6 -
The DRCS design rationale language is an extension, with substantial modification, of previouswork in decision rationale capture. DRCS’s main contribution is to integrate with the rationalelanguage a generic design description language applicable to a wide range of design domains. Thisapproach offers a number of advantages over previous work.
The DRCS language allows greater expressiveness. In generic decision rationale languagessuch as gIBIS [12] and DRL [5] the requirements, decision problems and options are describedusing natural language text. DRCS, by contrast, captures these using a structured language withexplicit semantics. Requirements are described as a desired attribute value. Decision problems areselected from a pre-enumerated set with known semantics. Design options are described as inter-connected modules and tasks. DRCS can capture design rationale based on “programmatic”concerns (i.e. on issues like keeping the design definition or manufacturing process from being tooresource-intensive), using links between plan resource limits of a plan and design attributes. DRCSalso incorporates a model of intent absent from most decision rationale work; while DRL forexample includes a \"goal\" entity it provides no way to link goals to the strategy used to achievethem and the actions that implement the strategy. The information-theoretic content is thussigificantly higher, but not at the cost of being domain-specific(e.g. as in JANUS [2]).
The more explicit semantics of DRCS makes greater computational support possible. Sincedecision problem and specification semantics are known, for example, it makes it much easier tofetch previous design cases which dealt with similar challenges. We can more easily find thedifferences and similarities between candidate design versions by identifying how the designsdiverged and why. Integrated design/rationale capture supports conflict detection, classification andresolution [3]. One can search for all controversial design decisions underlying a given decision bylooking for underlying claims with many supports and denies claims, determine the consequencesof withdrawing a design choice by deleting all derived decisions without independent support,review the options explored for a given problem by checking all the has-option claims stemmingfrom the decision problem, and so on.
Finally, DRCS is, we believe, more natural than most previous languages for describing designrationale. Rationale can be attached directly to the design aspect (module decomposition, attributevalue etc) it refers to, rather than to a piece of text. In DRL, for example, specifications arerepresented as subgoals of decision problems. A new copy of this subgoal has to be created forevery decision problem affected by the specification. In DRCS specifications are representedsimply as desired values for module attributes.
3. The DRCS System
Current design tools, as noted above, do not in general support rationale capture as an integratedcomponent of their operation, nor do they support groups as opposed to individuals. The DRCSsystem was developed to improve our understanding of how we can augment existing designsystems to do so in the context of CE teams. It is currently implemented in Common Lisp onseveral networked Symbolics workstations.DRCS has the following architecture (Figure 9):
- 7 -
CE Team Member InterfacePrivateScratchpadCE Team Member InterfacePrivateScratchpadNetworkShared Product Data BlackboardFigure 9: The DRCS System Architecture.
Each of the participants in a CE team is given their own interface which allows them to view thedesign and rationale information on the shared blackboard as well as make changes on their privatescratchpads. The contents of these scratchpads can be \"published\" so that the blackboard is updatedwith these changes. Users can have their changes published as they are made, allowing essentiallyreal-time collaborative editing, or can choose to publish more occasionally.
DRCS provides CE team members with a direct-manipulation WIMP (window icon menupointer) graphical interface (Figure 10):
- 8 -
Figure 10: Example of the DRCS interface in use.
Users can create windows that present some desired subset of the design data from many possibleperspectives, each designed to highlight different aspects of the design/rationale description. Onecan create windows, for example, that display the current artifact design as rectangular modules withlines representing connections, show the ordering of tasks in a given plan as PERT charts, reveal theargument structure affecting a given claim as a graph, present the current set of versions as a latticeand so on. These windows dynamically update themselves whenever the subset of the product datathey view changes, so they are continuously up to date. In addition to simply displaying productdata in some pre-defined format, one can create instances of “analysis” windows which presentuseful analyses, such as pointers to circular or incomplete argument structures or questionabledecision choices, that help the designer produce better designs. The topmost window in the displaycontains the menubar; each item in that window produces a menu of options when selected. “File”menu options include saving the current state of the user interface and publishing the user's privatescratchpad. The “Windows” menu allows one to create new perspective windows or cycle throughexisting ones, while the “Special” menu allows one to create analysis windows. In Figure 10 theuser is viewing the versions graph (lower right), the artifact design in one of the versions (upperright), a description of one component in that design (lower left) and a description of the plan usedto produce that component (upper left).
The printed representation of every entity and claim is mouse-sensitive; a menu of options thatmake sense in the current context for that assertion appears when it is clicked on using the pointingdevice. There are two classes of options for any assertion; perspective creation and editing.Perspective creation options create windows that view the assertion from a given perspective. Whenclicking on the top-level task of a plan, for example, one can create windows that view it either astemporally-ordered leaf tasks or as a task decomposition hierarchy. Editing options allow one to
- 9 -
update the design rationale database; for any assertion the menu will include a list of all the types ofclaims one can make about that assertion. To add an attribute to a module, for example, one clickson the module and selects the “Define Attribute” option; the user is then prompted for an attributename and an instance of that attribute connected to the module via a “has-attribute” claim iscreated. To connect two module interfaces, one selects the “Make Connection” option for oneinterface and then selects the interface to connect to. To add support for a claim one selects the “IsSupported By” option for that claim and then either selects an existing claim or creates a new one;the appropriate “supports” relation between these claims is automatically created. Design decisionsand their inter-dependencies (i.e. their rationale) are usually described using a few mouseoperations though text entry is sometimes required.
The DRCS interface builds upon rationale capture systems such as gIBIS [12], SIBYL [5] andJANUS [2] as well as to a lesser extent on hypertext systems without an explicit rationale language(e.g. [11], [4]). The key difference between DRCS and these systems is that DRCS integrates in asingle tool a general approach to both design decision and design rationale capture. Users thus haveno need to switch tools when describing the design as opposed to its rationale, can attach rationaledirectly to the design claims of interest, and can focus their efforts on describing rationale that theevolving design description reveals as critical.
4. Future Directions
DRCS was developed to explore how current rationale capture approaches can be extended toprovide more effective support for the capture of computer-interpretable rationale from multi-function concurrent engineering design teams. It has been used successfully by teams of designersto record rationale for a variety of simple new designs as well as re-represent information frommore complex existing designs. The resulting information has been used to support computationalservices not supportable by generic decision rationale representations. Based on this experience wefeel that the basic viability of this approach has been substantially validated.
There is, however, a rich range of possibilities for future growth. The rationale capture languageneeds to be augmented, e.g. to capture geometric information (by incorporating a feature-basedgeometric representation) and tentative or “fuzzy” argumentation [5]. In addition, better methodsneed to be developed to allow effective display and use of what we anticipate to be large and highlycomplex product data/rationale networks.
Rationale capture systems impose significant overhead on the design process. This isexacerbated by the fact that the people who benefit from rationale capture are often different fromthose who are asked to perform it. The challenge is to ensure that the cost/benefit ratio from theperspective of the individuals asked to enter rationale is an attractive one. While DRCS makeseffective use of a point-and-click interface metaphor to reduce overhead, more needs to be done. Inaddition to the approaches already explored by others, we are considering supporting rationalecapture via English text. This is less daunting than one might imagine because only a limited subsetof English is probably needed to express design rationale, and the current design context can helpreduce the semantic ambiguity of natural language text. The attempt will also be made to maximizeDRCS's ability to provide useful services to its users.
DRCS is currently realized as a standalone research prototype; to have significant impact thetechnology needs to be realized as an augmentation of design decision capture tools actually usedby CE team participants. For this to happen advances need to be made on several fronts. Currentproduct data and/or inter-application link standards need to be augmented include a design rationalerepresentation. This will involve both adding rationale description primitives not present in currentstandards as well as defining the mapping between the existing and DRCS product datarepresentations. CE team member interfaces must be updated to allow users to collaboratively view,
- 10 -
edit and link different kinds of shared product data. One approach is to enhance existing designtools so they can provide additional product data display formats (e.g. add displays formanufacturing data to a CAD tool) as well as allow linkage among this data. Another approach is toprovide support at the operating system level, extending in effect the cut-and-paste metaphor used inthe Macintosh operating system to support creation of cross-application rationale links. We arecurrently evaluating both approaches for viability in Boeing's computing context.
References
[1] Balzer, R. Capturing the Design Process in the Machine. In Rutgers Workshop on Knowledge-Based Design Aids, 1984.[2] Fischer, G., Lemke, A.C., McCall, R., and Morch, A.I. Making Argumentation Serve Design.Journal of Human Computer Interaction (1991).[3] Klein, M. Supporting Conflict Resolution in Cooperative Design Systems. IEEE Systems Manand Cybernetics 21, 6 (December 1991).[4] Lakin, F., Wambaugh, J., Leifer, L., Cannon, D., and Sivard, C. The Electronic Design
Notebook: Performing Medium and Processing Medium. Visual Computer 5, 4 (1989) Pps.214-226.[5] Lee, J. and Lai, K.Y. What's In Design Rationale?. Human-Computer Interaction (1991).[6] MacLean, A., Young, R., Bellotti, V., and Moran, T. Questions, Options and Criteria: Elementsof a Design Rationale for User Interfaces. Journal of Human Computer Interaction: SpecialIssue on Design Rationale (1991).[7] McCall, R. PHIBIS: Procedurally Heirarchical Issue-Based Information Systems. InProceedings fo Conference on Planning and Design in Architecture, 1987.[8] Mostow, J. and Barley, M. Automated Reuse of Design Plans. In Proceedings ICED, IEEE,August 1987, Pps. 632-647.[9] Stefik, M.J. Planning With Constraints (Molgen: Part 1 & 2). Artificial Intelligence 16, 2(1981) Pps. 111-170.[10] Tong, C. AI In Engineering Design. Artificial Intelligence in Engineering 2, 3 (1987) Pps.130-166.[11] Uejio, W.H. Electronic Design Notebook for the DARPA Initiative in ConcurrentEngineering. Tech. Report GE Corporate Research and Development, 1991.
[12] Yakemovic, K.C.B. and Conklin, E.J. Report on a Development Project Use of an Issue-BasedInformation System. In CSCW 90 Proceedings, 1990, Pps. 105-118.
Sidebar 1: The Design Reasoning Model
Underlying the DRCS rationale language is a model of how designers think. Rationale is essentiallya record of the reasoning process an individual used to reach certain conclusions. If a rationaledescription language is expressed in terms that accurately mirror the individuals reasoning process,it will be easier to use. A rationale language for the medical domain, for example, would be much
- 11 -
less useful if it did not include terms like “hypothesis”, “evidence”, “symptom” and so on, sincethese are entities used in medical reasoning. We discuss the DRCS design model below.
A central aspect of a design reasoning model is, of course, how the design itself is representedand refined. This includes both the physical artifact produced and the plans (temporal artifacts)followed to define and actually produce the artifact. In DRCS, physical artifacts are viewed ascollections of modules, which can represent entire systems, subsystems or their components, eachwith characteristic attributes, whose interfaces (with their own attributes) are connected byconnections of a given type. The resources used by a module (e.g. cost, weight) are representedusing a special class of attribute (Figure 11).
ConnectionInterfaceAttributes - 12 -
InterfaceAttributesModuleAttributesModuleAttributesModuleSpecializeConstrainAttributeValueModuleModuleDecomposeConnectModuleSpecializeDecomposeModuleModuleConnectModuleFigure 12: The design refinement process.
If we were designing an airplane, for example, we might decompose the top-level “airplane”module into wing, tail and body section modules as well as electrical, hydraulic and mechanicalsubsystem modules. Interactions between modules (e.g. physically connected components) arerepresented as connections between module interfaces.
Plans are viewed as (perhaps partially) temporally ordered collections of tasks with associatedattribute constraints (Figure 13). An artifact production plan would thus be represented as asequence of tasks corresponding to operations such as machining, inspection and the like. Everytask includes one or more primitive actions that actually implement the task.
Task 4aTask 1Task 2Task 3Task 4bFigure 13. A plan description.
Plans, like artifacts, are defined in an iterative least-commitment manner. The essential difference isthat the basic entity is a task rather than a module, and tasks are temporally ordered rather thanconnected via interfaces. For both physical and temporal artifacts, DRCS provides a constraintlanguage that allows indefinite descriptions and thus least-commitment design, a commonly-usedapproach that supports conflict avoidance and early conflict detection [9], [3].
In parallel with the iterative refinement of the design description is evaluation of the design withrespect to how well it achieves the specifications. Based on this analysis we may choose to selectone design option over another or modify a given option in order to address an identifieddeficiency. The stages of specification identification, design option definition, evaluation andselection/modification can be interleaved arbitrarily throughout the design process.
Task 5- 13 -
Designers, in addition to reasoning about the design itself (i.e. at the domain level), also reasonabout the process they use to define the design (at the meta-level) [9]. A designer may have a planfor how the design itself will be created, made up of tasks like “collect requirements”, “developoptions”, “perform trade study” and so on. If several design options are available, a designer mayreflect on which option to select. If a conflict between two or more design goals and actions occurs,a fix for the conflict needs to be found. The design reasoning process is generally goal-driven, inthe sense that actions are taken as part of strategies intended to achieve goals such as meeting aspecification, refining a design option, making a control choice, resolving a design conflict and soon.
This generic model of design reasoning is based on classical Systems Engineering work as wellas AI models of artifact design [10], [3] and planning [9]. These models have been appliedsuccessfully to a wide variety of domains including electrical, electronic, hydraulic and mechanicalsystems as well as software.
Sidebar 2: Examples of DRCS in Use
Imagine some designers are working on the preliminary design for a new airplane (Figure 14). Thedesigners want the final airplane to cost less than 10 million dollars, have a turning radius of lessthan 180 feet and so on. They have made some initial commitments; the plane will be made out ofeither aluminum or graphite, have a passenger capacity that is a given function of its length, andconsists of inter-connected wing and body submodules. The plane will be manufactured by aprocess that should take no more than 3 months per plane and consists of partially orderedsubtasks including “acquire outsource components” etc.
- 14 -
Airplanehas-attributehas-attributehas-attributehas-attributehas-attributehas-attributeCosthas-specificationPainthas-specification(< 10,000,000 dollars)(or blue red)(< 180 feet)Turninghas-specificationRadiusMaterialhas-valueLength(or aluminum graphite)Passengerhas-valuehas-submoduleCapacityWinghas-interfacehas-submoduleBodyhas-interfacehas-production-plan(* (the length of airplane) 3)wing mountis-connected-tobody mountbuild airplanehas-attributeuses resource