Maintaining Traceability Between UML Models and Source Code

Student: Banko Banov
Supervisor: AllenDutoit
Project type: SEP

Summary

Software systems have to deal with two main chalenges: complexity and change. The complexity of the system is described explicit in the project documentation, including RAD, SDD and the code itself. These documents capture a snapshot of the system at some stage of its development and do not represent the evolution of the system in time. Moreover, they only describe the developer's understanding of the application domain (RAD) and its mapping onto the solution domain (SDD and code), leaving the design rationale beyond the scope. Redesigning the system without knowing the rationale of the decisions already made is often difficult and inefficient.

The problem of keeping the rationale of the system explicit is well-known. One way to manage it is to model and store the issues and their criteria, proposals and resolution for future reference. This approach is implemented in the BBoard system at the chair, allowing developers to communicate over and archive the issues. Without underestimating the importance of issues in the developers communication, we would like to integrate this issues model in an UML development tool, assuming that this is the context, where the issues arise, proposals are matched against criteria and resolutions are being implemented. The UML tool we choose for that purpose is the RAT, developed at the chair. Our goal will be to implement template mechanism that allows connecting issues to any part of the UML model and storing them in the code comments for future revision. The best place to keep the issues is, in our opinion, the souce code, since it is the part of the system, that is most exposed to changes and will allow visualisation of the issues in the context of the development tool. The visualisation of the issues in the development tool will be done by parsing the comments of the code.

A further aspect of the project may be to organise and cross-reference issues, which address contigous parts of the model. That will make it easier to keep the overview of the systems design rationale and will give the developer better view of the side-effects that a change at certain part of the model may have.

Objectives

• Develop/reuse an incremental code generator that takes a RAT analysis model and produces class templates.
• The code generator should be incremental in that it can be invoked again if the analysis model changes without overwriting code that has already been written.
• The code generator should be based on templates, so that both Objective-C and Java source code can be supported
• The code generator should maintain links between UML elements (classes, operations, fields), source code elements, and their corresponding issues. For example, given a Java class it should be possible to query the issues associated with the corresponding UML class. * To demonstrate the traceability between source code classes and issues, a plug-in for the JEdit editor should be developed so that issues can be browsed from source code.

Tasks

Develop hello world client to connect to the element store (DONE).

To become familiar with RAT and the element store, develop a simple client that connects to the element store and retrieves the analysis model.

Develop one way generator without associations.

Refine the simple client to display a list of projects to select from, and once a project is selected, to display a tree of packages that are available. The user can select one or more packages and specify a directory on the local disk. The one way generator will then create java code files and package directories (if they do not exist yet) corresponding to the selection. The code generator should generate the package and import statements, the class header, the field declaration, and the methods declaration with empty bodies. Any description associated wtih the fields and operations should be used in the comments before the corresponding field and methods. The id of the element store element being generated should be stored in the comment for later use by the JEdit plugin. In this first generator, the associations between classes are not considered. Existing java files are overwritten.

Language independence is achieved with the Builder pattern (p. 97 in the Gamma Design Patterns book). The traversal of the element store package and class hierarchy is done with a Director class while the low level code generation is done by a JavaBuilder class, implementing a Builder interface that declares one method for each code element to be generated (e.g., generateClassHeader(packageName, imports, className), generateField(name, type, initialValue), generateMethod etc.).

Potential issues:

• The parameter string in the operation needs to be parsed so that the UML type declaration (e.g., a:int) is translated into a Java declaration (int a).

Deal with associations in the one way generator

Refine the one way generator to generate associations. Three cases should be considered:

• one-to-one associations
• one-to-many associations
• many-to-many associations

The code should use the client and supplier roles (if specified) as the name of the private field holding the state of the association. Methods for traversing, creating, or deleting associations should be generated automatically. The code generator can initially assume that the multiplicity string is either empty, "1", or "*".

Potential issues: * RAT does not place any constraints on the multiplicity string.

Develop initial JEdit plugin (display links to issues)

Develop an initial JEdit plugin to display the generated code together with any links to issues from the displayed elements. If there are issues linked to an element (e.g., a method), the user should be able to display a list of the issues with names. The purpose of this task is to become familiar with the JEdit API and to check that the code generator includes sufficient information in the generated code.

Develop incremental generator

Refine the one-way generator so that it can deal with existing java files that were previously generated. The incremental generator should parse any existing java file, save the comments and code added by the user, merge them with the newly generated file, and save the new file.

Potential issues:

• The code generator should not loose any code from the user. It should make a backup of any original file.
• Consider adding markers in the java file to make the parsing easier or to identify what changed.

Add issue editor to JEdit plugin

Reuse the code from RAT for creating and editing issues/operations/assessments/criteria and refine the initial JEdit plugin so that the user can enter issues either from RAT or the JEdit plugin.

Decisions

• Develop generator from scratch. After looking at several code generation libraries, the decision was to develop a simple generator from scratch. The argument was that, even reusing an existing library, we would have had to develop a generator taking the element store classes as an input and producing an XML or XMI file as output, which would have been almost the same amount of work.
• Test the code generator from a simple client first, integrate with RAT later when the generator is done. The justification for this decision is that the RAT code is still being revised and that the coupling between RAT and the code generator should be minimal.
• Builder pattern as a solution for language independence.