Thomas R. Gruber and Daniel M. Russell. Design Knowledge and Design Rationale: A Framework for Representation, Capture, and Use. Knowledge Systems Laboratory, Stanford University, 1990.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... of designing the Mozilla software architecture is difficult to abstract because of two important issues: first, the design inherits in part from original Netscape experience, so it was not completely invented in public view; second, because design discussions are inherently difficult to capture[20] and usually have sparse record. According to Mike Shaver and Dan Mosedale, an engineer for Netscape, the original Mozilla design was a direct evolution of the Netscape Navigator 5 architecture. A part of it is still intact from that period: the Javascript engine and NSPR, an abstraction layer ....

Thomas R. Gruber and Daniel M. Russell. Design Knowledge and Design Rationale: A Framework for Representation, Capture, and Use. Knowledge Systems Laboratory, Stanford University, 1990.

....of representational terms for describing design decisions, design requirements, design alternatives, assumptions about the environment in which the designed artifact is to operate, etc. and dependencies among those elements. This work is based on the framework for design knowledge begun last year [Gruber Russell, 1990], the results of last year s Summer Ontology Project [Gruber 92] and examination of the AI and engineering literature. Our evaluation of this ontology will include determining the extent to which it enables representation of the design rationale questions and answers identified by Bonnet for the ....

T.R. Gruber & D. Russell; "Design Knowledge and Design Rationale: A Framework for Representation, Capture, and Use"; Knowledge Systems Laboratory Technical Report KSL 90-45; Computer Science Department, Stanford University; 1990.

....are used and produced in the design. Despite these research efforts, the proposed methods of design rationale capture, even with tool support, are timeconsuming and difficult to maintain. This cost is preventing acceptance of design rationale in software development. As Gruber and Russel state (Gruber 1991), the task of eliciting, recording and organizing design knowledge is difficult. Creating and collecting rationale is even more difficult. Rationales are explanations of the relationships between many different aspects of the design, such as the structure, behavior, artifacts and the ....

Gruber, T. R. and. D. M. R. (1991). Design Knowledge and Design Rationale: A Framework for Representation, Capture, and Use, Knowledge Systems Laboratory.

....invested behind the design of an artifact. Fischer et al. 1991: 395) point out that in their approach design rationale means statements of reasoning underlying the design process that explain, derive, and justify design decisions. Design rationale . is a synonym for argumentation . For Gruber and Russell (1991: 2) A design rationale is an explanation of how and why an artifact, or some portion of it, is designed the way it is. We take the design rationale to be a space of actual and alternative choices, the relations of attack and support between these, with supporting chains of justification and ....

....decisions. At each step in the design process the design model is augmented (or changed) in two ways: the design elements are transformed and the (relevant node in the) design rationale is updated though not necessarily automatically as in Ramesh and Dhar s system (1992; 1994) The literature (Gruber and Russell, 1991; Fischer et al. 1991; Buckingham Shum and Hammond, 1994) abounds in lists of reasons for recording the design rationale. The important points from these can be summarised as follows: The design rationale can record design decisions for a single designer over time or for a team of designers. ....

[Article contains additional citation context not shown here]

Gruber, T.R. and Russell, D.M. Design Knowledge and Design Rationale: A Framework for Representation, Capture, and Use. Technical Report KSL 90-45. Stanford: Knowledge Systems Lab., Computer Science Dept. Stanford University, 1991.

....invested behind the design of an artifact. Fischer et al. 1991: 395) point out that in their approach design rationale means statements of reasoning underlying the design process that explain, derive, and justify design decisions. Design rationale . is a synonym for argumentation . For Gruber and Russell (1991: 2) A design rationale is an explanation of how and why an artifact, or some portion of it, is designed the way it is. We take the design rationale to be a space of actual and alternative choices, with supporting chains of justification, attached to design components or the design as a whole. ....

....to be a space of actual and alternative choices, with supporting chains of justification, attached to design components or the design as a whole. At each step in the design process the design components are transformed and or the (relevant node in the) design rationale is updated. The literature (Gruber and Russell, 1991; Fischer et al. 1991; Ramesh and Dhar, 1992; Buckingham Shum and Hammond, 1994) abounds in lists of reasons for recording the design rationale. The important points from these can be summarised as follows: The design rationale can record design decisions for a single designer or for a team of ....

[Article contains additional citation context not shown here]

Gruber, T.R. and Russell, D.M. (1991). Design Knowledge and Design Rationale: A Framework for Representation, Capture, and Use. Technical Report KSL 90-45. Stanford: Knowledge Systems Lab., Computer Science Dept. Stanford University.

.... [Shema et al. 1990] A fourth approach is to record the history of design choices and provide intelligent indexing into a shared design memory [Mark and Schlossberg, 1990] A fifth approach is to acquire design knowledge in the form of engineering models [Baudin, Sivard, and Zweben, 1989; Gruber and Russell, 1990]. All of these approaches deal with the acquisition of different aspects or abstractions of design knowledge. In this paper I frame design rationale capture as a knowledge acquisition problem, where the task is to elicit, from domain specialists (designers) knowledge that is sufficient to enable ....

Gruber, T. R. and Russell, D. M. (1990). Design knowledge and design rationale: A framework for representation, capture, and use. Stanford Knowledge Systems Laboratory, Technical report KSL 90--45.

....mathematics [13, 35] behavior modelling [6, 10, 30, 36] and the representation of everyday human experience [25] We plan to develop a basic ontological foundation and then extend it in the directions indicated by how it is used in practice by engineers. The initial shade ontology (based on [17] and an informal study of group ontology development) will include classes for behavioral descriptions, constraint expressions, design decisions, dependencies, design criteria, design moves, design parameters, functional descriptions, requirements, and structural descriptions. These classes ....

Thomas R. Gruber and Daniel M. Russell. Design knowledge and design rationale: A framework for representation, capture, and use. Technical Report KSL 90-45, Knowledge Systems Laboratory, Stanford University, 1990.

No context found.

Gruber, T. R., and Russell, D. M.(1991). Design knowledge and design rationale: A Framework for representation, capture, and use, to appear in the special issue of Human Computer Interaction on Design Rationale, Summer 1991.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC