Representing Design Rationale to support Reuse Adriana Pereira de Medeiros and Daniel Schwabe Dept. of Informatics, PUC-Rio Rua Marquês de São Vicente 225, 22453-900, Rio de Janeiro - RJ, Brasil {adri, dschwabe}@inf.puc-rio.br ABSTRACT Many engineering areas benefit from design reuse, and it widely accepted that software engineering should be no exception. However, design reuse requires knowledge about the “why” and “how” an artifact, or some part of an artifact, is designed the way it is. Design Rationale provides such information. This paper presents Kuaba, a new design rationale representation approach, and the architecture of an integrated design environment to support recording design rationale, as well as use of design rationale to support reuse of model-based designs, particularly software design. The Kuaba approach uses a formal representation language and takes advantage of the formal semantics of artifacts, as defined by the design methods, for representing design rationale. This representation approach enables a new type of design reuse, where existing artifacts rationales are integrated and re- employed in designing a new artifact. INTRODUCTION Component reuse is at the core of the majority of the design process for engineering disciplines. Nowadays, it is accepted that a similar approach is necessary for software development. Software reuse is essential for augmenting the return of its development costs. Reducing software production and maintenance costs, as well as delivery time, are typically achieved only through systematic software reuse. However, systematic reuse requires a design process that considers how the existing designs can be reused and that explicitly organizes the design in terms of the available software artifacts [15]. Design reuse means reusing the experiences and the knowledge invested in a design, so that the proposed solutions for an artifact can be reused in designing other artifacts. Therefore, for reusing an existing design it is necessary to know “why” and “how” the produced artifacts were designed. Design Rationale (DR) [5] provides such information, since it records the reasons behind the design decisions, including also design alternatives considered and eventually rejected, the tradeoffs evaluated and the argumentation that led to the decisions. Reusing design without understanding DR may cause defects, since the modifications may destroy the carefully elaborated solutions in the existing design. Although DR has a potential value for the design reuse, it has not been very used during software design. One of the reasons, despite much research, is the time consumption and the cost generally required for the capture and representation of DR. Another reason is the lack of a representation approach that enables the development of an integrated tool that can function as the capture, representation and use of design rationale part of the software design process. Software design is a process in which the produced artifacts are abstract models representing different characteristics of software. These models can be seen as a combination of textual and graphical descriptions of the artifacts being designed. Preferably, a model should have precise, non- ambiguous semantics that enables full understanding of the artifact being modeled. For many design domains, particularly in software design, the artifacts (models) are built according to the semantics provided by the meta-model of the modeling language or design method used to guide the design process. We call this special kind of design domain “model-based design”, in which design can be seen as an instantiation process of a meta-model. This meta-model represents the formal models that describe the modeled artifacts and provide semantic descriptions which allow reasoning over the artifacts being produced. An example of such a formal model is the meta- model of the Unified Model Language (UML) [12] used to describe a class diagram. It is fair to say that reuse at the highest abstraction level occurs when rationales are integrated and re-employed when designing a new artifact. This type of reuse can be achieved by a formally defined DR representation, which integrates the formal semantics provided by the meta- model that describes the artifacts being designed. Starting with existing artifacts, the designer can analyze their rationales and decide to integrate or extend them to get a more complete design solution. He can review and extend it, adding new alternatives or making different choices with respect to already defined alternatives, generating a new DR. From this point of view, both software maintenance and evolution can be considered simply as a continuation of a previous design process, captured in a given DR.