Design Rationale Systems: Understanding the Issues
Total Page：16
File Type：pdf, Size：1020Kb
AI IN DESIGN Design Rationale Systems: Understanding the Issues Jintae Lee, University of Hawaii IN THE LAST FEW YEARS, INTEREST OST CURRENT DESIGN RATIONALE SYSTEMS FAIL TO in design rationales has grown. Design ratio- M nales are important tools because they can CONSIDER PRACTICAL CONCERNS, SUCH AS COST-EFFECTIVE include not only the reasons behind a design decision but also the justification for it, the USE AND SMOOTH INTEGRATION. THE AUTHOR IDENTIFIES other alternatives considered, the tradeoffs SEVEN TECHNICAL AND BUSINESS ISSUES AND DESCRIBES evaluated, and the argumentation that led to the decision. The use of a design rationale sys- THEIR IMPLICATIONS. tem—a tool for capturing and making design rationales easily accessible—can thus improve dependency management, collaboration, re- to address all these issues. Some will empha- (future designers and maintainers). The use, maintenance, learning, and documenta- size one thing; others, another. Indeed, these arrows between services indicate that a ser- tion. However, if such systems are to keep pace issues delineate the major dimensions along vice at the end of the arrow (tail) supports the with the growing and changing demands of which a design rationale system is likely to dif- service at the beginning (arrowhead). For design technology, researchers and develop- fer. But if the community can better understand example, using design rationales to support ers must begin to answer certain questions. each of these issues, it will be more equipped dependency management or problem solving In this article I identify seven issues, which to produce design rationale systems that suc- or simulation and diagnosis improves design I have derived from an informal (undocu- ceed in their particular application areas. and maintenance, and supports learning. mented) survey of major existing design Using design rationales to support project rationale systems and discussions with work- management helps support collaboration, shop participants, including those in the 1992 What services to provide requirements engineering, or reuse—any one AAAI Design Rationale Capture and Use of these in turn can result in better design. Workshop.1 The issues identified include The services a design rationale system what services to provide; what parts of the provides will determine almost all other Better design support. Well-structured de- rationale to represent explicitly; how to rep- aspects of its design, such as what to repre- sign rationales can help designers track the resent, produce, and access rationales and sent and how to represent the rationales. issues and alternatives being explored and manage them cost effectively; and how to Figure 1 shows common services classi- their evaluations. This, in turn, clarifies the integrate the design rationale system. fied into four major groups according to the overall structure of the reasoning process and My goal in writing this article is to help user group who benefits: better design supports decision making. In some cases, of researchers and developers of future design (designers), better maintenance (system course, all this information can actually hin- rationale systems understand the available maintainers), learning (new trainee, students, der design activities by imposing unneces- options and tradeoffs. No one system can hope learning programs), and documentation sary overhead or breaking the natural flow 78 0885-9000/97/$10.00 © 1997 IEEE IEEE EXPERT . Better design Better maintenance Learning support Documentation support support of design activities, but in most cases this clarification leads to better design. Theoretically, one design rationale system can support all the services described here Dependency Problem-solving Simulation and both during design and before—for exam- management support diagnostics support ple, during requirements definition. Dependency management. Design can be Collaboration Requirement Reuse support viewed as the process of managing depen- support engineering support dencies to yield a product that honors all Project management dependencies among requirements and the support components that implement them. Design rationales can make explicit dependency rela- tions among design parts, decisions, argu- Figure 1. Services provided by most design rationale systems. Arrows between services indicate support relations. ments, and alternatives so that they work together consistently. Some systems provide dependency management simply by display- arguments evaluating the alternatives. that learn by analogy (see articles by Ashok ing issues that depend on the current issue,2 For reuse to be successful and cost- Goel and Alex Duffy in this issue). while more complex systems actually detect effective, however, the design rationale sys- conflicts among various constraints.3 tem must also make it cost-effective to sort Documentation support. Design rationales out knowledge that is outdated or context- can be used to automatically generate docu- Collaboration/project management. Design sensitive. Without this provision, its sugges- mentation. I mention documentation as a rationales also provide a common founda- tions must be taken with a large grain of salt. category apart from better design because tion when multiple parties are involved. Mary Lou Maher and Andres Gomez de documents help others besides designers. Explicitly represented rationales can provide Silva Garza discuss other problems in the Managers or users can use them to evaluate common vocabulary and project memories, reuse of design knowledge.6 the design. Lawyers can use them to deter- and make it easier to negotiate and reach con- mine if the design is intellectual property. In sensus. In Shared-DRIM,3 for example, Better maintenance support. Because fact, Frank Shipman and Ray McCall,8 who whenever a design agent makes a recom- design rationales explain the design decisions articulate three main perspectives of design mendation, the system checks to see if an made, they can also help maintain the design. rationales—argumentation, communication, existing recommendation might conflict with Most existing systems provide this service and documentation—argue that the docu- it. If so, the system informs all relevant par- in its simplest form: comments documenting mentation perspective has been the most suc- ties about the change made to the object, program codes. EES,7 on the other hand, cessful and should provide a model for the identifies the cause of the change, and looks extracts much richer development rationales design of design rationale systems (see “How for a constraint violation. In this way, inter- and uses them to generate more sophisticated to access rationales”). actions among, say, engineers and contrac- explanations for system maintenance. tors are reduced, which helps design proceed more efficiently. Learning support. Design rationales can What to represent explicitly Design rationales also help designers or help both people and systems learn mutually computational agents track unresolved issues and interactively. Janus,8 for example, pro- It is impossible to represent an entire and their dependencies, train newcomers, vides computational agents, or critics, which design rationale explicitly. Rationales are restore interrupted designs, and support dis- have access to design rationales and monitor embedded not only in formal documents tributed task allocation. human designers. When a critic encounters such as design specifications, meeting ab- a human decision that is suboptimal accord- stracts, and interface documents, but also in Reuse/redesign/extension support. Design ing to its knowledge, it presents the designer informal media such as phone conversations, rationales help reuse in two ways. First, they with an appropriate recommendation along blackboard sketches, and discussions over can serve as indices to past knowledge (sim- with its rationales. The designer can either lunch. In fact, almost anything in a design ilar designs, parts, problems encountered). agree and accept them, thus acquiring a new process may be a part of a design rationale SoftDA,4 for example, supports reuse by piece of knowledge, or disagree and teach as long as it is represented and can be used to acquiring the relationship information about the system by supplying a new piece of trace a reason for some aspect of the design. designs and requirements and using it to knowledge so that the critic knows better Whatever is represented, however, must be index documents and codes. next time. accessible, so it must have some structure. Designers can also reuse the rationales Of course, many learning systems attempt This is why, say, videotaping all designer themselves. For example, the precedent man- to pick up knowledge from past problem- interaction would not be suitable. The agement in Sibyl5 uses the goals from past solving traces. And if you view a problem- unstructured nature of the recording would decision rationales to suggest potentially rel- solving process as the process of designing a make it difficult to access exactly what is evant alternatives, and uses both goals and solution, technically all these systems can be needed and use that information in any quan- alternatives to retrieve potentially relevant design rationale systems, especially those titative way. MAY/JUNE 1997 79 . Functional dependency. As is true for any maximum expected utility). With the evalu- Systems also differ in the richness of the representation, what you represent depends ation layer, the individual