An Architectural Framework for Rationale Management

Tool support for rationale has been often viewed as a stand-alone system. A monolithic tool supports the capture, representation, and use of rationale, either as a general-purpose tool such as ibis or a tool specialized to an activity, such as CoMoKit for process enactment. Instead, we view a rationale system as supporting designers in handling designs within framework. An RMS is mostly transparent, appearing as an extension of the design environment, adaptable to the specific project situation.

In system terms, we propose that tool support for rationale should be viewed as a framework of components, each supporting a different activity and able to produce outcomes compatible with other components. In this section, we describe such a framework, its components, its interfaces to the design environment, and the constraints it must satisfy.

Capture Components

An RMS supports rationale acquisition with a number of capture compo-nents for recording rationale from developers, extracting it from artifacts, or inferring it from developer actions. Such components might support:

−Rationale capture by supporting collaboration. Systems such as gIBIS, WinWin, or Sysiphus support project participants for communication and collaboration by providing a structured set of actions and entities for exchanging their opinions and criteria. In effect, the tool structures the collaboration to elicit the rationale to be captured and to reduce the overhead for structuring it. To increase collaboration through the component, many such SER components also provide a complete range of groupware features, such as group awareness, synchronous and asynchronous modes of communication, and support for multimedia.

−Rationale extraction from artifacts. An alternative approach is to extract rationale from communication or design artifacts after the fact. Natural language processing approaches identify key issues and arguments from natural language text, removing the burden from the participants to follow predefined schemas.

−Rationale capture in design reasoning. Systems such as SEURAT provide design support, either on their own or integrated into a larger development environment. This enables the capture of traceability links and inference of knowledge from the actions of the developer.

−Rationale as justification. Developers currently document rationale for decisions that are not obvious or that could impact other decisions. Systems like CoMoKit recognize the need for explicit capture of justifications and relate them with rationale captured or inferred by other components.