A Rationale-based Analysis Tool

Transcription

1 A Rationale-based Analysis Tool Timo Wolf, Allen H. Dutoit Technische Universität München, Institut für Informatik Boltzmannstr. 3, Garching bei München, Germany Abstract The Rationale-based Analysis Tool (RAT) supports analysts, developers, clients and end users during the objectoriented requirements analysis activity. The tool enables different stakeholders to create, generate and refine a consistent and traceable analysis model, from a use case model. The analysis model consists of UML classes and sequence diagrams. The tool uses traceability links to propagate modifications by automated actions and to enable users to navigate through different models and to detect their interrelations. Moreover, RAT integrates requirements analysis with rationale information to support and capture model negotiations consisting of alternatives, assessments, arguments and justifications. RAT is a location independent multi-user tool that supports synchronous and asynchronous group collaboration. 1 Introduction Object-oriented requirements analysis has become popular due to Jacobson s book Object-oriented software engineering [7] and the Unified Modeling Language [3]. Requirements analysis involves clients, end users, analysts, and developers, in defining a clear, consistent, and complete model of the system under development. First, the interactions between users and the envisioned system are described in natural language as use cases, then represented as a dynamic model with UML sequence diagrams, and finally consolidated into an object model depicted as UML class diagrams [4]. Requirements analysis is an iterative activity in that multiple stakeholders with different goals are involved. End users focus on their daily work requirements whereas clients and managers focus on budget, time and maintenance. During requirements analysis, each stakeholder tries to push his goals. Different models are created, refined, extended and discussed several times. As the understanding of the problem domain and the possible solutions deepens, requirements changes, and much rationale information, such as alternative solutions, assessments, justifications, and arguments [5] is generated. Usually, only the end result of this process, that is, the use case and object model are captured. The rationale information is forgotten. Maintaining consistency and traceability between these models is difficult, as CASE tools usually treat them as separate entities. Moreover, many models (e.g., use cases) are rich in natural language and loosely structured [7]. This paper discusses the tool RAT. It supports multiple stakeholders during the object-oriented requirements analysis activity to create consistent and traceable models in distributed environments. From use cases, RAT supports the creation, generation and refinement of sequence diagrams and classes. The tool supports traceability by the creation and maintenance of links between the different models. The users are able to follow the traces and they are aware of the impact while modifying the models. Moreover, RAT maintains consistency between selected model elements by automated actions (e.g. automated renaming of related model elements). Rationale generated during modeling is captured within RAT and supports model negotiation and knowledge capturing by using an argumentation-based issue model [10], adapted from QOC [8]. Issues can be attached to any kind of model elements, such as use cases, objects, or classes. The traceability links and the containment relations between elements are used to display and propagate the status of open issues in the system models. Therefore, the reasoning and knowledge behind the models is always available. Moreover, the impact of changing decisions, nonfunctional requirements, or criteria is traceable to the related model elements. Section 2 discusses related work. Section 3 provides an overview of RAT and its use. Section 4 evaluates the current implementation and we finish the paper with the conclusion in Section 5.

2 2 Related Work Egyed [6] presents an automated approach to generate and validate trace dependencies between development artifacts, such as model descriptions, specifications, and source code. The trace dependencies are used to identify the interrelation between these artifacts. The approach assumes to have a running software system, test scenarios, a set of artifacts and some initial trace dependencies between artifacts and scenarios. By accomplishing the test scenarios and observing the code of the running system, new traces are generated and existing ones are validated. We agree to the need of automated generation and validation of traces for existing systems and artifacts, but we also believe that traces between model artifacts are needed and can be created in the early stage of requirements analysis, when no system is available. Therefore, our approach integrates traceability links and artifacts within one tool to support consistency and traceability during the creation of model artifacts. REMAP [9] is a tool to support stakeholders to create design solutions from a set of requirements, using Design Rationale. The rationale is used to capture knowledge and to negotiate over open issues, related to requirements. A decision leads to a constraint, which must be addressed by the design solution. Therefore, REMAP uses rationale to maintain traceability between requirements and design solutions. The use of rationale in REMAP is similar to RAT. In addition, RAT supports a mechanism to create traceability links. We allow to attach issues to all kinds of elements and we integrate rationale within the modeling CASE tool. We belief that the integration of rationale, in developer daily work tools, increases the acceptance, usage, and benefit of rationale. Belkhouche [2] proposes a strategy for object-oriented requirements analysis that automates and assists the refinement of the analysis model, based on a semantic-net representation. In difference to RAT, Belkhouche assumes to have an initial model, created by the analysts. RAT generates an initial set of model elements, which have to be refined by the analysts. REQuest [5] is a web-based tool that supports an integrated process for creating and capturing use case-driven requirements and its rationale. REQuest uses a refinement of QOC [8] to represent rationale. The users are able to create and attach issues to requirement elements and trace from the elements to issues and back. REQuest minimizes the work on capturing rationale by displaying the issue models in the context of the requirements specification. RAT extends REQuest by integrating rationale and object-oriented analysis. RAT is used to create the analysis model based on the requirements and to refine them. The integrated issue model not only supports developers during analysis by capturing rationale, it also supports a communication channel between the different stakeholders involved in requirements elicitation and analysis. 3 RAT The goals of RAT are to support developers in creating and maintaining consistent and traceable object-oriented requirements analysis models, capture, annotate, and cross-reference the generated rationale information with the analysis models, enable multiple stakeholders to collaborate location independent. 3.1 Analysis Activities During object-oriented analysis, developers formalize the requirements specification to produce a model that aims to be correct, complete, consistent and unambiguous [4, 7]. Therefore, the use cases, representing the functional requirements, are examined and participating objects are identified. The use cases can be validated by instantiating scenarios in form of sequence diagrams containing the identified objects. The sequence diagram messages refine the interaction between the user and the system in more detail. Missing objects and object operations can be found. By abstracting from objects and adding taxonomy a class model is created. The classes and their operations can be refined again by using the sequence diagrams. Both, the classes and the sequence diagrams support the refinement of the use case. Natural text heuristics supports analysis activity [1]. Figure 1 provides an overview of the analysis activities. object model development use case model development sequence diagram development Figure 1: The analysis activities (UML activity diagram).

3 3.2 Supporting Analysis RAT and REQuest [5] share a repository for all requirements and rationale model elements. RAT starts with the use case model from REQuest. RAT supports developers by offering a clear, structured way from the requirements to the different analysis models and maintains consistency and traceability between the different model types over time. A use case of the requirements model consists of an initiating actor, representing the user of the system and a set of flow steps, describing the interaction between the actor and the system. A flow step is either an actor step or a system step. An actor step describes an interaction from the actor to the system and a system step is the response. The model supports the concept of system services that defines reusable system functionalities. A system step can use a service to accomplish the use case behavior. Generating sequence diagrams and classes RAT can generate an initial set of sequence diagrams and classes from the use case model. A generated sequence diagram consists of an actor object for each actor participating on the use case. The system is represented as a single boundary object and each used service is added as another object. The sequence diagram messages between the actors, the system, and the services are generated from the flow steps of the use case. Figure 2 shows a UML sequence diagram that was generated from a use case. The flow steps of the use case are annotated to the left side and they are displayed as tool tips of the messages. Developers can then refine and augment the sequence diagrams. They can change the labels of the generated messages, while the flow step descriptions stay as tool tips. Additional objects and messages can be added. Moreover, the generation function creates a class for each actor and a class with an operation for each service of the use case. The generated sequence diagram objects are instances of the related classes. Additional, the service messages are mapped to the operations of the service classes. Developers can refine the classes by e.g. adding attributes, operations, associations, inheritance, or changing names. Reusing and sharing objects and messages The sequence diagrams, consisting of objects and threads of messages are scenarios (i.e., instances of use cases). Multiple sequence diagrams represent different flow of events for the same use case in different situations. Therefore, the sequence diagrams differ on small, selected parts and share the redundant parts. Changing a redundant part Figure 2: Screenshot of a sequence diagram generated from a use case. Changing the use case will immediately change the sequence diagram. would force developers to change the same part in all other sequence diagrams. RAT supports the sharing of objects and messages to enable developers to reuse objects and message threads in different sequence diagrams and to compose complex diagrams from small and manageable sequence diagrams. Modifications of shared objects and messages are visible in all related sequence diagrams. Sharing objects and messages results in a larger number of simpler and consistent sequence diagrams. Consequently, it becomes easier for developers to use simple sequence diagrams to communicate with others, while not worrying about checking large numbers of diagrams for consistency. For example, assuming the authentication mechanism of a system is modeled within a sequence diagram, starting with a message authenticate. Another sequence diagram models a system function that requires authentication. Instead of redrawing the authentication mechanism, it is automatically added by reusing the authenticate message. The authentication mechanism is always consistent in both sequence diagrams, independent of any modification. Figure 3 shows a sequence diagram containing the shared message authenticate. RAT indicates shared objects and messages with yellow labels. RAT applies the mechanism of sharing objects and messages when sequence diagrams are generated several times from the same use case. Only the first generation creates the objects and classes as described above. To ensure consistency, following generations reuse and share the existing objects, messages, classes, and operations. Modifications of previous generated diagrams like added objects and messages are included. Moreover, multiple generations create only one class, operation and object for each service of a

4 Figure 3: Screenshot of a sequence diagram containing shared objects and messages, highlighted with a yellow label. use case. The modification of the class or operation is visible in all generated sequence diagrams. In addition to the generation from use cases, RAT enables the users to create sequence diagrams and classes independently of the use case model. New objects and messages can be included in a sequence diagram. The objects can be instantiated of the classes and messages can be mapped to operations. To reduce the amount of work and to ensure consistency, existing objects can be added to sequence diagrams and are shared. Furthermore, existing received messages of objects can be reused again. Therefore, the user defines the sender object and selects an existing received message of the receiver object. The selected message is shared and is sent from different objects to the receiver object. All resulting messages of the shared message are also added into the sequence diagram and shared. Maintaining traceability links The requirements analysis model consists of different and interrelated models that need to be consistent and traceable. The analysis of a use case model leads to the creation of sequence diagrams and classes. Therefore, the use cases represent the reasoning behind the identified models. The developers must be aware of model interrelations to maintain consistency over time. For example, a use case and its sequence diagram instances must be updated to be consistent, when adding new flow steps to the use case or a sequence diagram. RAT supports awareness of interrelating models by creating and maintaining traceability links between model elements. Furthermore, the tool uses the links for a set of automated actions. Traceability links are used between use cases and their generated model elements so that selected changes to the use case are automatically propagated. Similarly, some changes in the generated models are propagated back to the originating use case. For instance, changing the use case flow step descriptions, changes the tool tips of the related sequence diagram messages. Adding or deleting a flow step of the use case will add or delete the related message. All modifications of the services used by an use case, are reflected in the generated sequence diagrams. The generation creates only a link between the service and its operation. The service class is reached through the operation. Thus, the operation can be moved to another class and two services can be merged into one class. The next generation reuses the service operation and the merged class. Furthermore, traceability links between actors, services and classes are used to propagate name changes. Classes can participate in several use cases and be included in several use case diagrams. Being able to visualize how a class is used in different context enables the developer to consolidate requirements from different sources into single classes. Therefore, RAT associates a class diagram with each use case. The class diagrams support the creation of new classes and the addition of existing classes. Traceability links are added between use cases and classes. The links enable developers to navigate from classes to use cases and back, independent of further modifications like renaming or moving classes to other packages. Based on a use case model, RAT offers multiple possibilities to create an analysis model. However, to increase the usability, the tool does not force or restrict developers to any order in the creation of model elements or modeling rules. Users have the option of generating sequence diagrams automatically or manually and can refine automatically generated diagrams. The traceability links can be added manually at any time, by a drag and drop mechanism. 3.3 Supporting Collaboration Multiple stakeholders with different goals and knowledge are involved in the requirements elicitation and analysis activities. Usually, object-oriented methods are well known to analysts and developers whereas the problem domain is not. A user focus on his daily work requirements whereas a client focus on budget, time and maintenance. As the requirements analysis document is the foundation for the system development, each stakeholder wants to push his goals. This leads to negotiating over solutions, alternatives, relevant criteria and assessments of which criteria supports which solution [5]. The stakeholders accomplish knowledge research and knowledge exchange to push their goals. Usually, only the end result of this process, that is, the functional, dynamic, and object models are captured while the reasoning of the decisions called rationale is forgotten. Rationale facilitates negotiation among stakeholders by enabling them to systematically clarify the possible options and their evaluation against well-defined criteria.

5 Tracking history RAT is a multi-user tool that enables different stakeholders to collaborate on the same set of models from different locations. Changes to the models are visible immediately to all users, thus enabling synchronous and asynchronous collaboration. To increase the quality and effectiveness of distributed collaboration, each user is able to figure out, which model elements are new or modified by other users. Therefore, RAT tracks the history of each model element by storing the author, modification date and the last read date for each user. By using the history information, the tool supports different lists to present new or modified model elements. Rationale integration RAT supports rationale by integrating the analysis models with an argumentation-based issue model [10], adapted from QOC [8]. The issue model is shared with RE- Quest [5]. It consists of issues, proposals, resolutions, comments, and criteria, which represent nonfunctional requirements. Occurring rationale information can be captured and associated with the individual model elements (e.g. objects, classes, use cases, etc.). The graphical presentations of the model elements are enriched with rationale indicators. Figure 4 presents a part of a class diagram and the model navigation tree of RAT, annotated with rationale indicators. Open issues are represented with red dots, closed issues with green ones. Moreover, the model elements in the navigation tree are annotated with red crosses to hint that a subelement has open issues. Selecting an indicator will display all issues related to the selected model element. All issues of a model element and its subelements can be requested by using the navigation tree of RAT. For instance, requesting all issues on a package, lists all package issues and all issues of the subelements like classes, class attributes, operations, and its subpackages. Moreover, the traceability links are used to list the issues of related model elements. Therefore, issues of use cases are propagated to participating objects and classes, thus enabling developers to identify the impact range of issues to the interrelated models. Furthermore, RAT enables developers to list and search through the rationale information. Each issue can be visualized with its description, proposals, criteria, comments, and its related model elements. The users are able to trace from an issue back to the related model elements. Additional model elements can be added to an issue. The integration of the issue model within the same context as the analysis model helps developers in their daily work. For instance, the refinement of a class model could lead to multiple clarification issues. RAT enables develop- Figure 4: Screenshots of the rationale indicators within a UML class diagram and the navigation tree of RAT. ers to create the issues within the class diagrams. Noticing the appearing rationale indicators, another user can resolve the issues. The created rationale knowledge remains traceable from the class model and is available to all stakeholders. Assuming multiple stakeholders negotiate over alternative solutions to resolve design problems. The issue model supports and captures the justification behind each alternative by assessing criteria, such as nonfunctional requirements. RAT presents the assessment in form of a proposalcriterion matrix (see figure 5). Therefore, the reasoning why an alternative is chosen for a specific set of model elements is captured. The traceability between issues and model elements enables the awareness of the impact and interrelation between models and changing criteria. Figure 5: Screenshot of the proposal-criterion matrix of RAT. The proposals are listed in the first column and annotated with yellow bulbs. The issue related criteria are listed in the first row. The assessment of the criteria to the proposals is done within the matrix. Issue-based inspections Enriching the analysis model with rationale can facilitate reviews and inspections of the requirements analysis document. The issues can build the foundation for meeting agendas, as they reflect the current state and open questions to resolve. RAT implements different issue filters to support issue-based agendas for individual teams as well

6 as for development phases. Reviews and inspections can be accomplished by using RAT or in a traditional meeting. Therefore, the tool supports a printable version of the requirements analysis document that includes a list of issues, cross-referenced to the model elements within the document. 4 Evaluation About 30 students of the Software Engineering project course 2003/2004 at the chair Applied Software Engineering, Technische Universität München, developing a prototype forecasting system for the Wacker chemical company used RAT to create the analysis model and generate the requirements analysis document. The requirements analysis document turned out to be one of the primary client deliverable for this project and will be used by the Wacker IT department to realize a production version of the system under development. The created application demonstrates the feasibility of using RAT for object-oriented analysis. Although the students had no experience in software engineering and rationale, they understood the concepts of RAT intuitively. Comparing the project with previous project courses that where accomplished without RAT, the communication and knowledge sharing between individual teams increased dramatically. By using RAT, each team was always aware of other team activities and could clarify questions by creating issues to related model elements. Therefore, the students did not only focus on their team related tasks and the global system domain knowledge was higher. 5 Conclusion This paper introduces the main concepts of RAT, a rationale-based analysis tool. The tool facilitates different stakeholders during object-oriented requirements analysis. It supports the creation and maintenance of consistent models, model-centered communication and negotiation, as well as capturing knowledge. Our approach includes the generation of sequence diagrams and classes from use cases, the maintenance of traceability links, and the capture of rationale together with the analysis model. We showed how traceability links can help maintaining consistency among models and how integrated rationale can support stakeholder collaboration. While initial results are encouraging, more studies are necessary to evaluate the tool and demonstrate its usefulness. We plan more studies in project courses and research projects to gather feedback from end users and address any usability issues. Furthermore, we plan to extend the tool in multiple directions. First, RAT should support developers to map the analysis model into a detailed object design, integrated with design pattern support. Second, we are planning to integrate concepts of project task management, so that each user is always aware of his current tasks and the project time line. Moreover, we made some experiences in writing IDE plug-ins to support rationale during coding and to synchronize source code and its issues with the class model and its issues from RAT. A first version of document generation is already implemented an should be extended. References [1] R. Abbott. Program design by informal english description. Comm. of the ACM, 26(11):82 94, [2] B. Belkhouche and A. M. Gamino. Object-oriented analysis through a knowledge-based system. Journal of Object-Oriented Programming, 11(7):52 59, [3] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, [4] B. Bruegge and A. H. Dutoit. Object-Oriented Software Engineering Using UML, Patterns, and Java. Prentice Hall, 2nd edition, Sep [5] A. H. Dutoit and B. Paech. Rationale-based use case specification. Requirements Engineering Journal, [6] A. Egyed. A scenario-driven approach to trace dependency analysis. IEEE Trans. Softw. Eng., 29(02): , [7] I. Jacobson, M. Christerson, P. Jonsson, and G. Övergaard. Object-Oriented Software Engineering A Use Case Driven Approach. Addison Wesley Longman Ltd., [8] A. MacLean, R. M. Young, V. Bellotti, and T. Moran. Questions, options, and criteria: Elements of design space analysis. Human-Computer Interaction, 6(11): , [9] B. Ramesh and V. Dhar. Supporting systems development by capturing deliberations during requirements engineering. IEEE Trans. Softw. Eng., 18(6): , [10] S. B. Shum and N. Hammond. Argumentation-based design rationale: what use at what cost? Int. J. Hum.- Comput. Stud., 40(4): , 1994.