Capturing Design Rationale in Concurrent Engineering ... - CiteSeerX

Capturing Design Rationale for CE Teams

Mark Klein

Capturing Design Rationale in Concurrent Engineering Teams 1 Mark Klein Boeing Computer Services When an artifact is designed2 nowadays the typical output of this activity includes blueprints, CAD files, manufacturing plans and other documents describing the final result of a long series of deliberations and tradeoffs by the participants of concurrent engineering (CE) teams. The underlying intent and logical support (i.e.therationale ) for the decisions captured therein is usually lost, or is represented at best as a scattered collection of paper documents, project and personal notebook entries as well as the recollections of the artifact’s designers. This design rationale information can be very difficult to access by human agents and is represented such that computers can provide little support for managing and utilizing it. The challenges of intensified global competition and the growing complexity of the artifacts we design 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 help individual 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 decisions becomes available for all team members to critique and augment [5]. Participants affected by design changes can be identified readily [6]. Existing designs which addressed similar requirements can be retrieved, understood and modified to meet current needs [8]. The causes and potential resolutions for conflicts between designers can be identified [3]. Design decisions can be easily documented for new team members, new designers and artifact users [1].

1 To Appear In: IEEE Computer. Special Issue on Computer Support for Concurrent Engineering. January, 1993. 2 In this paper, the word "design" is taken to describe all aspects of an artifacts' description, including the

requirements, geometric definition, materials, manufacturing plan, supporting documentation and so on.

-1-

Capturing Design Rationale for CE Teams

Mark Klein

In order to achieve these benefits, however, significant challenges must be met. The representation we use must allow designers to express their design reasoning in a natural way while at the same time be formal enough to support useful computational services. Since CE teams include multiple participants working on overlapping aspects of the design, concurrent editing must be supported. In addition, the process of describing rationale should impose the minimum possible overhead on the design process. Most existing rationale capture approaches support only individual users and are thus not suited to team contexts (but see [5, 12]). More importantly, most [5, 12, 7, 6] capture the rationale for decision-making in general but not design in particular; they simply add yet another document to the set produced by existing design tools (Figure 1).

Figure 1. Rationale Captured as a Distinct Document. Such approaches have limited expressiveness and therefore limited computational usefulness. The corresponding rationale capture tools face the potential of inconsistency between the rationale and design descriptions as well as spotty capture of design rationale and the tendency to waste time on issues that later prove unimportant; the designers cannot focus their discussion on issues revealed by actual inspection of the evolving design description [2].

-2-

Capturing Design Rationale for CE Teams

Mark Klein

What we really need are systems that allow CE team participants to conveniently describe the dependencies between decisions captured by existing design tools (Figure 2).

Requirements

Product Geometry

Project Schedules

Documentation/ Manuals Manufacturing Plans

Figure 2. Rationale as Decision Interdependencies. The rationale for a product geometry decision, for example, consists of the requirements it attempts to satisfy and the other geometry decisions on which it logically depends. A manufacturing plan decision, similarly, is justified in terms of supporting decisions like project schedule and geometry decisions. While systems that integrate design and rationale representations do exist (e.g. [2]), they use highly domain-specific design representations (e.g. for kitchen design) not easily generalized to other domains. The fundamental challenge, then, is to provide an integrated and generic framework for capturing rationale in team contexts. In this paper we describe a design rationale capture system called DRCS (the Design Rationale Capture System) that was designed to meet this challenge. The rationale language underlying DRCS was built upon previous work on decision rationale capture as well as a generic model of design reasoning and is designed to capture in a natural way all important aspects of design decisions and their inter-relationships. The DRCS system itself explores how design systems can be enhanced to support collaborative editing of designs and their rationale. The DRCS language, the DRCS system and possible directions for future work will be discussed in the sections below.

-3-

Capturing Design Rationale for CE Teams

Mark Klein

2. The DRCS Rationale Language The DRCS rationale language captures design reasoning using a vocabulary of assertions consisting of entities like modules, tasks, specifications and versions as well as claims about these entities. Claims come in two main types. A pre-defined vocabulary of relation claims describes relationships between assertions. Any claim can serve as part of the rationale for another claim, so we can make claims about the design (e.g. module-1 has-submodule module-2), claims describing rationale for design decisions (e.g. value-1 is-derived-from procedure-1), claims concerning why we should believe this rationale (or not) and so on recursively. There is also an all-purpose text claim used to capture information not otherwise expressible. The net result of describing designs and 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 rationale language will be described, followed by several examples. The language will be divided, for expository purposes, into five components. As we have seen, design reasoning consists of defining/tracking design requirements (i.e. evaluation) as well as synthesis. Designers usually have some intent underlying a given action, as well as supporting arguments for believing that the action is appropriate. Since there are often multiple options for any decision, designers generally explore a space 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 actions used to define artifacts and plans. Let us consider artifacts first; the language entities for this purpose are shown in Figure 3 below:

-4-

Capturing Design Rationale for CE Teams

Is Of Type

Mark Klein Has-Submodule Has-Specialization Is Of Type

Connection

Is Of Type

Has Interface

Connects Interface

Module Has Attribute

Has Attribute Attribute

Is Of Type

Has Value Constraint Figure 3: Artifact synthesis entities and relationships. In this and the following figures, primitive entities in the DRCS language appear in plain font, while relation claims appear as directed arcs with italic labels; the latter signify that the given relationship can hold between the entities ate the arc source and target. Entities with the “is-of-type” relation have 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 a constraint language. Constraint languages are used to express indefinite descriptions, and have been used extensively in numerous design and planning systems [9]. The DRCS constraint language provides a wide range of constructs including “absolute” constraints like inequalities, ranges and sets as well as “relational” constraints such as boolean and mathematical equations. Plan descriptions are captured as follows (Figure 4):

-5-

Capturing Design Rationale for CE Teams

Mark Klein

Has Priority Has Greater Priority Than Has-Subtask Has-Temporal-Relationship Is Of Type

Assertion

Has Action

Task

Has Plan

Module

Has Attribute Attribute

Has Value

Constraint

Figure 4: Plan synthesis entities and relationships. The basic entities here are tasks. Plans to produce an artifact are related to the artifact’s top-level module via a “has plan” claim. Every plan is represented, as we have seen, as the hierarchical decomposition of a top-level task into temporally ordered subtasks with associated primitive actions. 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 have priorities. 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 capture design specifications as well as how well they have been achieved (Figure 5).

Specification

Achieves

Attribute

Has-Specification

Is Of Type Has Subspecification Has Importance Is More Important Than Is More Important Than Has Importance Has-SubAttribute Is Of Type

Figure 5: Evaluation entities and relationships.

-6-

Version

Capturing Design Rationale for CE Teams

Mark Klein

Design and plan specifications are defined as desired values (using the constraint language) for design and plan attributes. Attributes and specifications can have different types, priorities and subsumption relationships. Attributes and specifications can have types. Specification types include objectives, requirements and preferences, and differ in how critical they are and thus by implication how 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 a strategy to find an answer for some problem; i.e. has some intent when taking that action. This is captured in DRCS as follows (Figure 6):

Decision Problem

Has Strategy

Assertion

Raises Issue

Has Priority Has Greater Priority Than

(Top-Level Task for) Strategic Plan

Figure 6: Intent model entities and relationships. Any assertion in a design description can raise a decision problem. There is, in fact, a preenumerated set of decision problem types; one for every relation defined for a given assertion type. There is, for example, a decision problem for the “Has Submodule” relation on modules (where the problem is determining how to decompose the module), a decision problem for the “Has Value” relation on attributes (where the problem is determining what the attribute value should be) and so on. Some decision problems can have greater priority than others. The strategy used to address 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 the space of design alternatives (Figure 7).

-7-

Capturing Design Rationale for CE Teams

Mark Klein

Decision Problem Has Option Is The Best Option For Abandoned Suspended Conflict

Has Status

Version

Has Priority Has Greater Priority Than

Resolved By Figure 7: Versions model entities and relationships. New versions are created whenever tentative decisions and/or exploration of multiple alternatives occurs, i.e. when defining options for a decision problem. Every option for a given decision problem is asserted in a different version. The versions storing the options can have differing priorities as well as statuses. If a given version has the status “conflict”, we can indicate which alternate version resolves that conflict. The preferred option for a decision problem is represented using an “is the best option for” claim. 2.2.5. Argumentation. The purpose of the argumentation model is to allow one to describe the reasons for and against believing claims (Figure 8):

Has Answer Question

Claim RaisesQuestion

Has-Result

Supports Qualifies Denies Presupposes

Procedure

Is Of Type Has-Subprocedure

Has-Input Figure 8: Argumentation model entities and relationships. The basic entities include claims (both relation and text claims) as well as procedures and questions. Claims can support, qualify, deny or presuppose one another. One can use the “hasresult” and “has-input” claims to link claims to the procedures used to derive them and the inputs to those procedures; procedures can be mathematical equations or more unstructured information such as textual reference sources, handbooks, catalogs, standard engineering tables and so on. An individual can raise “questions” about the validity of a claim and assert that given claims answer

-8-

Capturing Design Rationale for CE Teams

Mark Klein

these questions. Any synthesis, evaluation, intent, versions or argumentation claim can itself be the subject of argumentation claims. The DRCS design rationale language is an extension, with substantial modification, of previous work in decision rationale capture. DRCS’s main contribution is to integrate with the rationale language a generic design description language applicable to a wide range of design domains. This approach offers a number of advantages over previous work. The DRCS language allows greater expressiveness. In generic decision rationale languages such as gIBIS [12] and DRL [5] the requirements, decision problems and options are described using natural language text. DRCS, by contrast, captures these using a structured language with explicit semantics. Requirements are described as a desired attribute value. Decision problems are selected from a pre-enumerated set with known semantics. Design options are described as interconnected 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 too resource-intensive), using links between plan resource limits of a plan and design attributes. DRCS also incorporates a model of intent absent from most decision rationale work; while DRL for example includes a "goal" entity it provides no way to link goals to the strategy used to achieve them and the actions that implement the strategy. The information-theoretic content is thus sigificantly 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. Since decision problem and specification semantics are known, for example, it makes it much easier to fetch previous design cases which dealt with similar challenges. We can more easily find the differences and similarities between candidate design versions by identifying how the designs diverged and why. Integrated design/rationale capture supports conflict detection, classification and resolution [3]. One can search for all controversial design decisions underlying a given decision by looking for underlying claims with many supports and denies claims, determine the consequences of withdrawing a design choice by deleting all derived decisions without independent support,

-9-

Capturing Design Rationale for CE Teams

Mark Klein

review the options explored for a given problem by checking all the has-option claims stemming from the decision problem, and so on. Finally, DRCS is, we believe, more natural than most previous languages for describing design rationale. Rationale can be attached directly to the design aspect (module decomposition, attribute value etc) it refers to, rather than to a piece of text. In DRL, for example, specifications are represented as subgoals of decision problems. A new copy of this subgoal has to be created for every decision problem affected by the specification. In DRCS specifications are represented simply 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 integrated component of their operation, nor do they support groups as opposed to individuals. The DRCS system was developed to improve our understanding of how we can augment existing design systems to do so in the context of CE teams. It is currently implemented in Common Lisp on several networked Symbolics workstations. DRCS has the following architecture (Figure 9):

CE Team Member Interface

CE Team Member Interface

Private Scratchpad

Network

Shared Product Data Blackboard Figure 9: The DRCS System Architecture.

- 10 -

Private Scratchpad

Capturing Design Rationale for CE Teams

Mark Klein

Each of the participants in a CE team is given their own interface which allows them to view the design and rationale information on the shared blackboard as well as make changes on their private scratchpads. The contents of these scratchpads can be "published" so that the blackboard is updated with these changes. Users can have their changes published as they are made, allowing essentially real-time collaborative editing, or can choose to publish more occasionally. DRCS provides CE team members with a direct-manipulation WIMP (window icon menu pointer) graphical interface (Figure 10):

Figure 10: Example of the DRCS interface in use. Users can create windows that present some desired subset of the design data from many possible perspectives, each designed to highlight different aspects of the design/rationale description. One can create windows, for example, that display the current artifact design as rectangular modules with lines representing connections, show the ordering of tasks in a given plan as PERT charts, reveal the argument structure affecting a given claim as a graph, present the current set of versions

- 11 -

Capturing Design Rationale for CE Teams

Mark Klein

as a lattice and so on. These windows dynamically update themselves whenever the subset of the product data they view changes, so they are continuously up to date. In addition to simply displaying product data in some pre-defined format, one can create instances of “analysis” windows which present useful analyses, such as pointers to circular or incomplete argument structures or questionable decision choices, that help the designer produce better designs. The topmost window in the display contains 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 private scratchpad. The “Windows” menu allows one to create new perspective windows or cycle through existing ones, while the “Special” menu allows one to create analysis windows. In Figure 10 the user is viewing the versions graph (lower right), the artifact design in one of the versions (upper right), a description of one component in that design (lower left) and a description of the plan used to produce that component (upper left). The printed representation of every entity and claim is mouse-sensitive; a menu of options that make sense in the current context for that assertion appears when it is clicked on using the pointing device. 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. When clicking on the top-level task of a plan, for example, one can create windows that view it either as temporally-ordered leaf tasks or as a task decomposition hierarchy. Editing options allow one to update the design rationale database; for any assertion the menu will include a list of all the types of claims one can make about that assertion. To add an attribute to a module, for example, one clicks on the module and selects the “Define Attribute” option; the user is then prompted for an attribute name and an instance of that attribute connected to the module via a “has-attribute” claim is created. To connect two module interfaces, one selects the “Make Connection” option for one interface and then selects the interface to connect to. To add support for a claim one selects the “Is Supported 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 decisions

- 12 -

Capturing Design Rationale for CE Teams

Mark Klein

and their inter-dependencies (i.e. their rationale) are usually described using a few mouse operations though text entry is sometimes required. The DRCS interface builds upon rationale capture systems such as gIBIS [12], SIBYL [5] and JANUS [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 a single tool a general approach to both design decision and design rationale capture. Users thus have no need to switch tools when describing the design as opposed to its rationale, can attach rationale directly to the design claims of interest, and can focus their efforts on describing rationale that the evolving design description reveals as critical. 4. Future Directions DRCS was developed to explore how current rationale capture approaches can be extended to provide more effective support for the capture of computer-interpretable rationale from multifunction concurrent engineering design teams. It has been used successfully by teams of designers to record rationale for a variety of simple new designs as well as re-represent information from more complex existing designs. The resulting information has been used to support computational services not supportable by generic decision rationale representations. Based on this experience we feel 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 language needs to be augmented, e.g. to capture geometric information (by incorporating a featurebased geometric representation) and tentative or “fuzzy” argumentation [5]. In addition, better methods need to be developed to allow effective display and use of what we anticipate to be large and highly complex product data/rationale networks. Rationale capture systems impose significant overhead on the design process. This is exacerbated by the fact that the people who benefit from rationale capture are often different from those who are asked to perform it. The challenge is to ensure that the cost/benefit ratio from the perspective of the individuals asked to enter rationale is an attractive one. While DRCS makes effective use of a point-and-click interface metaphor to reduce overhead, more needs to be done. In - 13 -

Capturing Design Rationale for CE Teams

Mark Klein

addition to the approaches already explored by others, we are considering supporting rationale capture via English text. This is less daunting than one might imagine because only a limited subset of English is probably needed to express design rationale, and the current design context can help reduce the semantic ambiguity of natural language text. The attempt will also be made to maximize DRCS's ability to provide useful services to its users. DRCS is currently realized as a standalone research prototype; to have significant impact the technology needs to be realized as an augmentation of design decision capture tools actually used by CE team participants. For this to happen advances need to be made on several fronts. Current product data and/or inter-application link standards need to be augmented include a design rationale representation. This will involve both adding rationale description primitives not present in current standards as well as defining the mapping between the existing and DRCS product data representations. CE team member interfaces must be updated to allow users to collaboratively view, edit and link different kinds of shared product data. One approach is to enhance existing design tools so they can provide additional product data display formats (e.g. add displays for manufacturing data to a CAD tool) as well as allow linkage among this data. Another approach is to provide support at the operating system level, extending in effect the cut-and-paste metaphor used in the Macintosh operating system to support creation of cross-application rationale links. We are currently 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 Man and 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).

- 14 -

Capturing Design Rationale for CE Teams

Mark Klein

[6] MacLean, A., Young, R., Bellotti, V., and Moran, T. Questions, Options and Criteria: Elements of a Design Rationale for User Interfaces. Journal of Human Computer Interaction: Special Issue on Design Rationale (1991). [7] McCall, R. PHIBIS: Procedurally Heirarchical Issue-Based Information Systems. In Proceedings 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 Concurrent Engineering. 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 IssueBased Information 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 essentially a record of the reasoning process an individual used to reach certain conclusions. If a rationale description 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 less useful if it did not include terms like “hypothesis”, “evidence”, “symptom” and so on, since these 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 represented and 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 as collections of modules, which can represent entire systems, subsystems or their components, each with characteristic attributes, whose interfaces (with their own attributes) are connected by connections of a given type. The resources used by a module (e.g. cost, weight) are represented using a special class of attribute (Figure 11).

- 15 -

Interface Attributes

Module Attributes

Mark Klein

Connection

Module Attributes

Interface Attributes

Capturing Design Rationale for CE Teams

Figure 11. The design description scheme. A computer, for example, can be described as a set of VLSI chip modules with attributes describing their functionality, power consumption and so on. The modules’ interfaces (pins) are connected to each other via (electrical) connections realized as deposited wires. At another level, we can view an entire board as a module connected to the bus and indirectly to other boards. The interfaces and connections at this level describe the data and control protocols connecting these systems. Hydraulic systems, similarly, can be viewed as collections of pipe, switch, tank and pump modules inter-connected via hydraulic connections (e.g. threaded pipe). Artifact descriptions, in the DRCS model, are refined using an iterative least-commitment synthesize-and-evaluate process. An artifact description starts as one or more abstract modules representing the desired artifact (e.g. “airplane”, “computer” or “software application”) with specifications represented as desired values on module attributes (e.g. “passenger capacity should be > 350”). This is refined into a more detailed description by constraining the value of module attributes, connecting module interfaces (to represent module interactions), decomposing modules into sub-modules and specializing modules by refining their class (Figure 12).

- 16 -

Capturing Design Rationale for CE Teams

Mark Klein

Module

Specialize Module

Constrain Attribute Value

Decompose Connect

Module

Decompose

Specialize

Module

Module

Module

Connect

Module

Figure 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 mechanical subsystem modules. Interactions between modules (e.g. physically connected components) are represented as connections between module interfaces. Plans are viewed as (perhaps partially) temporally ordered collections of tasks with associated attribute constraints (Figure 13). An artifact production plan would thus be represented as a sequence of tasks corresponding to operations such as machining, inspection and the like. Every task includes one or more primitive actions that actually implement the task. Task 4a Task 1

Task 2

Task 3

Task 5 Task 4b

Figure 13. A plan description. Plans, like artifacts, are defined in an iterative least-commitment manner. The essential difference is that the basic entity is a task rather than a module, and tasks are temporally ordered rather than connected via interfaces. For both physical and temporal artifacts, DRCS provides a constraint

- 17 -

Capturing Design Rationale for CE Teams

Mark Klein

language that allows indefinite descriptions and thus least-commitment design, a commonly-used approach 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 with respect to how well it achieves the specifications. Based on this analysis we may choose to select one design option over another or modify a given option in order to address an identified deficiency. The stages of specification identification, design option definition, evaluation and selection/modification can be interleaved arbitrarily throughout the design process. Designers, in addition to reasoning about the design itself (i.e. at the domain level), also reason about the process they use to define the design (at the meta-level) [9]. A designer may have a plan for how the design itself will be created, made up of tasks like “collect requirements”, “develop options”, “perform trade study” and so on. If several design options are available, a designer may reflect 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 goaldriven, in the sense that actions are taken as part of strategies intended to achieve goals such as meeting a specification, refining a design option, making a control choice, resolving a design conflict and so on. This generic model of design reasoning is based on classical Systems Engineering work as well as AI models of artifact design [10], [3] and planning [9]. These models have been applied successfully to a wide variety of domains including electrical, electronic, hydraulic and mechanical systems 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). The designers want the final airplane to cost less than 10 million dollars, have a turning radius of less than 180 feet and so on. They have made some initial commitments; the plane will be made out of either aluminum or graphite, have a passenger capacity that is a given function of its length, and consists of inter-connected wing and body submodules. The plane will be manufactured by a

- 18 -

Capturing Design Rationale for CE Teams

Mark Klein

process that should take no more than 3 months per plane and consists of partially ordered subtasks including “acquire outsource components” etc. Airplane has-attribute

Cost has-specification

(< 10,000,000 dollars)

has-attribute

Paint

has-attribute

Turning has-specification Radius

has-attribute

has-specification

Material has-value

(or blue red) (< 180 feet)

(or aluminum graphite)

has-attribute Length has-attribute Passenger has-value has-submodule Capacity Wing has-interface has-submodule Body has-interface

(* (the length of airplane) 3) wing mount is-connected-to body mount

has-production-plan build airplane has-attribute uses resource has-subtask has-subtask has-subtask has-specification acquire outsource components

build assemble parts comes-before comes-before

(< 3 months)

Figure 14: Example of initial design specs and commitments. As the design process continues the designers begin to address achieving the turning radius specification. One possible strategy is to use folding wings (Figure 15).

- 19 -

Capturing Design Rationale for CE Teams

Mark Klein

Airplane has-attribute

Turning Radius

has-specification

(< 180 feet) raises-issue achieved-by? has-strategy Use folding wings

has-submodule wing has-specialization

action-of

folding-type wing Figure 15: Rationale for folding wing tips. The language captures this reasoning by indicating that the designers raised the decision problem of figuring out how to achieve the turning radius specification, proposed a strategy to do so, and took actions (in this case specializing the wing module) with the intent of implementing this strategy. The specification concerning the airplane turning radius, however, turns out to be controversial and produces a line of argumentation captured as follows (Figure 16): Airplane turning-radius (< 180 feet) Raises Question What is the turning radius of existing big planes? Has Answer About 200 feet.

Denies

Supports We don't need to do better than 200 feet

Figure 16: Argumentation concerning the turning radius specification. A designer wondered what the turning radius of existing big planes was; he goes on to claim that since existing big planes have as much as a 200 feet turning radius, this new plane need not do any better. Should this specification be replaced by a less stringent one, the designers can use the

- 20 -

Capturing Design Rationale for CE Teams

Mark Klein

rationale graph to determine what derived decisions, such as the choice of folding wings, potentially need to be re-considered. DRCS can also represent the rationale for meta-level decision making, e.g. deciding to try a particular option at a choice point or to resolve a conflict in a particular way. In both these cases, an assertion representing the decision problem (e.g. resolved-by? for conflicts or is-the-best-optionfor? for choice points) is linked via a strategy to the actions (e.g. creating a new design options for conflicts, or choosing an existing one for choice points) that address the decision problem.

- 21 -