Design Rationale for Software Maintenance (Doctoral Symposium – Abstract)
Total Page：16
File Type：pdf, Size：1020Kb
Design Rationale for Software Maintenance (Doctoral Symposium – Abstract) Janet E. Burge Artificial Intelligence in Design Research Group Department of Computer Science Worcester Polytechnic Institute 100 Institute Road Worcester, MA 01609 USA 508-831-5006 [email protected] intrusive the capture process, the more designer 1. The Problem resistance will be encountered. Documenting the decisions can impede the design For a number of years, members of the Artificial process if decision recording is viewed as a separate Intelligence (AI) in Design community have studied process from constructing the artifact [3]. Designers are Design Rationale (DR), the reasons behind decisions reluctant to take the time to document the decisions they made while designing. Standard design documentation did not take, or took and then rejected [4]. A real danger consists of a description of the final design itself: is the risk that the overhead of capturing the rationale effectively a “snapshot” of the final decisions. Design may impact the project schedule enough to make the rationale offers more: not only the decisions, but also difference between a project that meets its deadlines and the reasons behind each decision, including its is completed versus one where the failure to meet justification, other alternatives considered, and deadlines results in cancellation [5]. argumentation leading to the decision [1]. This The key to making the capture worthwhile, as well additional information offers a richer view of both the as providing requirements for DR representation, is the product and the decision-making process by providing use for, and usefulness of, the rationale. There are a the designer’s intent behind the decision. DR is number of potential uses for DR. These include: invaluable as an aid for revising, maintaining, • Design verification – using rationale to verify that documenting, evaluating, and learning the design. the design meets the requirements and the Being able to keep track of what decisions were designer’s intent. made, and why, is an important benefit of having • Design evaluation – using rationale to evaluate rationale and would be especially valuable for software (partial) designs and design choices relative to one maintenance. One reason for this is that the software another to detect inconsistencies. lifecycle is a long one. Large projects may take years to • Design maintenance – using rationale to locate complete and spend even more time out in the field sources of design problems, to indicate where being used (and maintained). Maintenance costs can be changes need to be made in order to modify the more than 40 percent of the cost of developing the design, and to ensure that rejected options are not software in the first place [2]. The panic over the “Y2K inadvertently re-implemented. bug” highlighted the fact that software systems often • Design reuse – using rationale to determine which live on much longer than the original developers portions of the design can be reused and, in some intended. Also, the combination of a long life-cycle and cases, suggest where and how it should be modified the typically high personnel turnover in the software to meet a new set of requirements. industry increases the probability that the original • Design teaching – using rationale to teach new designer is unlikely to be available for consultation personnel about the design. when problems arise. • Design communication – using rationale to If rationale has such potential value, then why is it communicate the reasons for decisions to other not in widespread use? One difficulty, despite a good members of the design team. deal of research, is the capture of design rationale. • Design assistance – using rationale to clarify Recording all decisions made, as well as those rejected, discussion, check impact of design modifications, can be time consuming and expensive. The more perform consistency checking and assist in conflict mitigation by looking for constraint violations maintenance by allowing the system to determine the between multiple designers. impact of a change and propagate modification effects. • Design documentation – using rationale to Less work has been done to study the usefulness of document the design by offering a picture of the DR. Field trials were done using itIBIS and gIBIS for history of the design and reasons for the design software development at NCR [4]. Capturing rationale choices as well as a view of the final product. was found to be useful during both requirements Because use is the key behind the value of the analysis and design. In particular, several errors were rationale, the focus of this work is on how rationale can found during design that would not have been be used to assist in software maintenance. uncovered until much later when the code was written. IBIS also helped with team communication by making 2. Relevant Research meetings more productive. A study was also performed using DR documents to evaluate a design [14]. In this How the DR can be used depends on its study, 50% of the designers’ questions were about the representation format and content [1]. Design Rationale rationale behind the design and 41% of these questions representations vary from informal representations such were answered using the recorded rationale. as audio or video tapes, or transcripts, to formal representations such as rules embedded in an expert 3. The Approach system [4]. A compromise is to store information in a semi-formal representation that provides some There are several different types of changes that may computation power but is still understandable by the be made during maintenance. These include correcting human providing or using the information. implementation errors (“bug fixing”), correcting design Semi-formal representations are often used to flaws, and enhancing the system. Design rationale has a represent argumentation. Argumentation notations number of potential uses for documentation, evaluation, provide a structure to indicate what decisions were and assistance during all types of software maintenance made (or not made) and the reasons for and against Design rationale could be generated at any stage of them. Some examples are Questions, Options, and the design process and describe many different types of Criteria (QOC) [6], Issue Based Information Systems decisions: (IBIS) [4], and DRL (Decision Representation • Requirements – rationale could exist for the Language) [7]. existing requirements and for requirements that There are also many different ways to capture DR. were considered but then rejected. There will be One approach is to build the rationale capture into a rationale for the user interface design if the design system used for the design task. One example is RCF was performed during the requirements phase. (Rationale Construction Framework) [8], which • Analysis – rationale could be associated with use- integrates DR capture into an existing design tool. cases and with the partitioning of the problem into DR has a variety of uses. Systems such as JANUS analysis classes and collaboration diagrams. [3], critique the design and provide the designers with • Design – rationale could be associated with any rationale to support the criticism. Others, such as portion of any design artifact. This could include SYBIL [7], verify the design by checking that the reasons behind the choice of the design classes, the rationale behind the decisions is complete. C-Re-CS [9] attributes (including reasons for data types and performs consistency checking on requirements and visibility), the methods, etc. recommends a resolution strategy for detected • Implementation – rationale could describe the exceptions. choice of algorithms, data structures, persistent There has also been work on using design rationale storage, and more. in software design. DRIM (Design Recommendation • Maintenance – rationale could describe both why and Intent Model) was used in a system to augment the modifications were necessary and the reasons design patterns with design rationale [10]. Co-MoKit behind the design and implementation choices [11] uses a software process model to obtain design necessary for the modification. decisions and causal dependencies between them. Figure 1 shows the development phases and the WinWin [12] aims at coordinating decision-making rationale that could be generated during each of them. activities made by various “stakeholders” in the Capturing all this information would present a software development process. Bose [13] defined an significant amount of overhead to the software ontology for the decision rationale needed to maintain developer. We will initially assume that all the the decision structure. The goal was to model the necessary rationale is available. decision rationale in order to support decision hierarchy of reasons for modification that can be PROGRAM RATIONALE used at different levels of abstraction to allow Requirements: “why” for requirements comparisons during inferencing. application specific • -what it must do (F) domain specific Does rationale differ for different types of software -constraints on how customer specific -NFRs, scheduling, re-use alternative or rejected requirements modifications? We believe that rationale will be -User Interface and reasons used and created at different levels of the design process depending on the type of modification. Analysis: why these use-cases • Does maintenance rationale differ from original alternative or rejected use-cases -Use Cases and reasons