by Simon Monk, Univ. of Lancaster
Design rationale is the reasoning behind design decisions. It can be thought of as a co-product of the design process that can be used to justify design decisions and should the system evolve to re-examine the old arguments in the light of the new requirements for the system. Design rationale starts with a design question, that is a problem that needs to be solved. There is usually more than one possible solution to the problem and these are enumerated. In addition the problem is often decomposed into a number of sub-goals that the proposed solutions should attempt to satisfy. The evaluation of the best solution can either be qualitative (by inspection of arguments for and against particular alternatives) or quantitative by using a decision matrix. The relative performance of each alternative in satisfying the sub-goals along with the relative importance of each sub-goal are all taken into account to suggest the best alternative.
There is now considerable interest in capturing the design rationale while a design is in progress and various tools have been developed that allow design rationale to be recorded. These tools are in general tied to a specific design rationale notation.
The PPIS (Process and Product Information System) is a general purpose hypertext system developed in the PROTEUS project at Lancaster University. Since the main formalism used in representing design rationale is the node and arc diagram, the PPIS is ideally suited to implementing a system for recording design rationale. Indeed the flexibility of PPIS in allowing the user to define sets of types has made it possible to represent most of the significant existing design representations, such as gIBIS, DRL and Toulmin.
In the figure, (a) shows a section of design rationale concerning PPIS using the DRL representation. Below the argument (b) is a decision table which is generated automatically by the PPIS (the user simply assigns scores for each alternative) and allows a quantitative comparison of the two design alternatives.
The design decision concerns the choice of language for developing the PPIS. The two alternatives are C++ or Smalltalk. Associated with the design decision are two subgoals.
¥That the system should be quick to implement.
¥ that the system should be quick at run time.
These two goals have weights associated with them. Thus being quick to develop is considered more important than being quick at run time because it has a higher weight. Each of the alternatives is then given a score to indicate their relative performance for each sub-goal. The figures in brackets are the weighted scores. The right hand column contains the total of these weighted scores for each alternative. The best alternative is then the one with the highest score (in this case Smalltalk).
Within the PROTEUS project, Matra Marconi Space has been using the PPIS to develop their own model of design rationale. There are three aspects that make this work particularly novel.
¥ Providing a framework for capturing the information. This avoids a problem with previous methods for recording design rationale that simply provide the user with a vocabulary of symbol types which must be arranged to record the design rationale.
¥ Extending design rationale to include risk analysis. Having found the best probable solution, this is then subjected to a risk analysis and may result in another solution being selected if the risk is deemed unacceptable.
¥ Linking the design rationale process to existing design tools. Within the context of PROTEUS, this means integrating the recording of design rationale with the existing object-oriented design environment of HoodNICE. Indeed, the PPIS tool can be launched on a particular design rationale document from within HoodNICE.
Capturing design rationale is accomplished by providing a skeletal design rationale that is completed by the user attaching annotations (c). This makes the process involved in recording the design rationale obvious to the user.
With reference to (c), the process starts with a requirement which is held in a DNP annotation which is associated with a text file which is shared with the HoodNICE system. The user then refines this requirement into a specific problem which again is stored in an annotation. Goals for the requirement and candidate solutions are enumerated.
The Probable Solution is the Candidate Solution that has the best evaluation. This solution is then validated using risk analysis and if the risk associated with that solution proves unacceptable then another solution can be chosen from the Candidate Solutions. A solution may have a number of risks associated with it, each of which can have actions that, if carried out, can reduce the criticality of the risk. Actions that cannot be carried out immediately (for example those requiring a watching brief) are kept in a special entity Remaining Action.
The final result of all this is a Design Element (which implements the requirement) which is again associated with the outside environment of HoodNICE.
In summary, the design rationale framework developed in PROTEUS integrates the recording of design rationale with the HoodNICE object-oriented design tool using the PPIS. The usual model of design rationale is augmented by risk analysis and the process of capturing the design rationale simplified by allowing the user to fill in a pre-defined skeletal design argument.
References. J. M. Pendaries and B. Durin, 'Design Rationale Model', Process & Software Engineering Dept., Matra Marconi Space, FR, PROTEUS ESPRIT project 6086, P-DEL-3.3A-Part I (1993). A paper on this subject has also been submitted to Software Practice and Experience.