Moran, T., Carroll, J. (eds.). Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Hillsdale, NJ, 1996.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....described above, the compliance of a model with CoCons can already be checked at the modelling level. Hence, CoCons are invariants that enable the testing of models in the spirit of unit tests. There used to be a lot of interest in recording the design rationale. Ac Design Rationale cording to [41], the idea was that designers would not only record the results of their design thinking, but also the reasons behind their decision. Thus, they would also record their justification for why it is as it is. CoCons record design decisions that can be automatically checked. They represent certain ....

Thomas P. Moran and John M. Carroll, editors. Design Rationale : Concepts, Techniques, and Use (Computers, Cognition, and Work). Lawrence Erlbaum Associates, Inc., 1996.

....However, often only the selected option is documented in the requirements specification and the discarded options are lost. This information loss leads to costly misunderstandings about the options between the different stakeholders and a lack of support when revising decisions. Rationale methods [9, 10] are used to explicitly capture and manage options, decisions, and their justifications [11] Support for negotiation is needed to make sure all relevant positions are represented and respected. Providing rationale based tools to make decision steps explicit can do this. While such tools have ....

Moran, P. and Carroll J.M. Design Rationale: Concepts, Techniques, and Use, Lawrence Erlbaum Associates, Mahwah, NJ, 1996.

....new versions into a configuration management system or posting a message in a discussion tool. 2. Providing context for activities. Raw events generated by communication and development tools are too low level for a remote observer. We propose that decision making information (i.e. rationale [16]) including issues, alternatives, quality criteria, and decisions be captured and related to other system artifacts. In addition to making issues under discussion visible to other sites, issues can also be used to enrich the context of awareness events. 3. Filtering awareness information. In a ....

T. Moran and J. Carroll. Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Mahwah, NJ, 1996.

....can only assure a high level of customer ownership in combination with the originating business model. Thus, the impact of business cases stands out more clearly by applying a systematic analysis than would otherwise be possible by an ad hoc approach. 5. Related Work A Design Rationale (DR) [4, 19] is a representation of the reasoning behind the design of an artifact. It is concerned with methods and representations for capturing why designers have made the decisions they have made. A wellknown approach to representing design rationale is Design Space Analysis, whose notation is called QOC ....

T.P. Moran and J.M. Carroll, editors. Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Hillsdale, New Jersey, 1994.

....because this paper focuses on using them in models. The integration of CoCons in existing constraint languages, e.g. OCL, and in the UML metamodel is a topic of future research. There used to be a lot of interest in machine processed records of design Design Rationale rationale. According to [16, 18, 22], the idea was that designers would not only record the results of their design thinking, but also the reasons behind their decisions. Thus, they would also record their justification for why it is as it is. Context based constraints are one way of recording design decisions. They represent ....

Thomas P. Moran and John M. Carroll, editors. Design Rationale : Concepts, Techniques, and Use (Computers, Cognition, and Work). Lawrence Erlbaum Associates, Inc., 1996.

....draft in [22] does not permit one constraint for a set of possibly unassociated model elements that share a context. In OCL, there is no concept of refering to the tagged values of a model element. There used to be a lot of interest in machine processed records of design rationale. According to [19], the idea was that designers would not only record the results of their design thinking, but also their rationale. Thus, they would also record their justification for why it is as it is and what other alternatives were considered and rejected. Context based constraints are one way of recording ....

T. P. Moran and J. M. Carroll, editors. Design Rationale : Concepts, Techniques, and Use (Computers, Cognition, and Work). Lawrence Erlbaum Associates, Inc., 1996.

....Consolidate Questions. When reviewing requirements elements, reviewers may raise similar questions. The rationale maintainer consolidates identical questions into single nodes and restructures similar options. 5. Consolidate Arguments. Arguments often constitute the bulk of rationale information [31]. Arguments are usually unstructured and may apply to several options and decisions. The rationale maintainer summarizes verbose or redundant arguments and adds missing links to relevant rationale nodes. 5.3. Integrating requirements and rationale In the previous two subsections, we described ....

T. P. Moran & J. M. Carroll (eds.), Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Mahwah, NJ, 1996.

....from the organisational model. In ConDIL, distribution instructions write down replication requirements. ConDIL can assist policy driven management for distributed systems. There used to be a lot of interest in machine processed records of design rationale. According to the many authors of [10] the idea was that designers would not only record the results of their design thinking using computer based tools, but also the process that they followed while designing. Thus, the software designer would also record a justification for why it was as it was and what other alternatives were ....

Thomas P. Moran and John M. Carroll, editors. Design Rationale : Concepts, Techniques, and Use (Computers, Cognition, and Work). Lawrence Erlbaum Associates, Inc., 1996.

....considers a plan to be a specialized type of design [Tate, 1996a] Given this viewpoint, we can incorporate design rationale research by managing a plan or plan fragment as a designed artifact. A rich corpus of methods, representations, notations, etc. from the design research community [Moran and Carroll, 1996] can be drawn upon to e ectively and eciently utilize this knowledge. This decision rationale is complementary to the dependencies and causal rationale that is maintained in most AI planners today. We recently completed a review of these aspects of planning rationale [Polyak and Tate, 1998] In ....

Moran, T.P. and J.M. Carroll, J.M. (eds.) Design Rationale: Concepts, Techniques, and Use, Lawrence Erlbaum Associates, Mahwah, New Jersey, 1996.

....from the organisational model. In ConDIL, distribution instructions write down replication requirements. ConDIL can assist policy driven management for distributed systems. There used to be a lot of interest in machine processed records of design rationale. According to the many authors of [10] the idea was that designers would not only record the results of their design thinking using computer based tools, but also the process that they followed while designing. Thus, the software designer would also record a justi cation for why it was as it was and what other alternatives were ....

Thomas P. Moran and John M. Carroll, editors. Design Rationale : Concepts, Techniques, and Use (Computers, Cognition, and Work). Lawrence Erlbaum Associates, Inc., 1996.

....been much work done on both plan process causality and dependencies, there has been correspondingly less research into plan decision rationale. 17 We proposed a design space analysis (DSA) approach to plan decision rationale [24] which was based on research from the design rationale (DR) field [22, 20]. If we envision the i n ova approach, which CPO has adopted, as describing a space of behaviour we can also consider a space of decisions which is navigated in creating this behavioural specification. It is possible then to augment a process description with the rationale that went into ....

T.P. Moran and J.M. Carroll, editors. Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, 1996.

....discusses related work from two perspectives: research that focuses on representations serving for problems rather than solutions, and research that uses twodimensional positioning as a representational medium. 6.1. Representations for Strategic Knowledge A line of research in design rationale [13] has focused on representation for strategic knowledge. Design rationale is typically a textual description of what alternatives should be taken and arguments that support or negate each alternative. Although such design rationale mechanisms provide powerful cognitive representations for designers ....

Moran, T. P., & Carroll, J. M. (Ed.). (1996) Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Inc, Hillsdale, NJ.

.... of logins to automatically track who changed what, when, at the field level in the system; one could incorporate a digital history of data modifications that tracks not only all previous values but also why each value was changed, when, by whom, and with what authority [19, 25] Design rationale [29], which serves a similar role in software development, should be used as inspiration in developing systems with lightweight features to record this additional contextual information. Such history enriched digital data could allow advanced systems to provide visualizations that track processes and ....

Moran, T.P. and Carroll, J.M. (eds.). Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Mahwah, NJ, 1996.

No context found.

Moran, T., Carroll, J. (eds.). Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Hillsdale, NJ, 1996.

No context found.

Moran, T., Carroll, J. (ed.). Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Hillsdale, NJ.

No context found.

Moran, T., Carroll, J. (eds.). Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Hillsdale, NJ, 1996.

No context found.

Moran, T., Carroll, J. (ed.). Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Hillsdale, NJ.

No context found.

T. Moran and J. Carroll (Eds.), Design Rationale: Concepts, Techniques, and Use. Hillsdale, NJ: Lawrence Erlbaum Associates, 1996.

No context found.

T. P. Moran & J. M. Carroll (eds.), Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Mahwah, NJ, 1996.

No context found.

T.P. Moran and J.M. Carroll, Design rationale : concepts, techniques, and use, Computers, cognition, and work, Mahwah, N.J.: L. Erlbaum Associates, 1996.

No context found.

Moran, T. P., and Carroll, J. M., Eds. Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates, Mahwah, NJ, 1996.

No context found.

T.P. Moran & J.M. Carroll (Eds.), Design Rationale: Concepts, Techniques, and Use, Lawrence Erlbaum Associates, NJ, 1996.

No context found.

.

No context found.

Moran, T.P. and Carroll, J.M., (Ed.) Design Rationale: Concepts, Techniques, and Use. Lawrence Erlbaum Associates: Hillsdale, NJ, 1996 [ISBN 0-8058-1566-X].

First 50 documents

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