Semi-automated Traceability Maintenance: An Architectural Overview oftraceMaintainer

Patrick Mader1, Orlena Gotel2 and Ilka Philippow1

1Department of Software SystemsIlmenau Technical University, Germany

patrick.maeder|ilka.philippow@tu-ilmenau.de

2Department of Computer SciencePace University, New York, USA

ogotel@pace.edu

Abstract

traceMaintainer is a tool that supports an approach formaintaining post-requirements traceability relations afterchanges have been made to traced model elements. The up-date of traceability relations is based upon predefined rules,where each rule is intended to recognize a development ac-tivity applied to a model element. Little manual effort orinteraction with the developer is required. traceMaintainercan currently be used with a number of commercial softwaredevelopment tools and enables the update of traceability re-lations stored within these tools. This paper provides anoverview of traceMaintainer’s architecture and major com-ponents.

Keywords: Traceability, development activity recogni-tion, rule-based traceability maintenance.

1 IntroductiontraceMaintainer supports the (semi-)automated update

of traceability relations between requirements, analysis anddesign models of software systems expressed in UML ([2],[1]). It can update traceability relations with little manualeffort, a commonly cited barrier to traceability use withinindustry. This is possible by analyzing elementary changeevents that have been captured while working within a third-party UML modeling tool. Within the captured flow ofevents, development activities comprised of several eventsare recognized. These development activities are expressedas predefined rules. Rules consist of masks requiring anevent with certain properties. Once recognized, the corre-sponding rule gives a directive to update impacted traceabil-ity relations to restore consistency.

The traceMaintainer prototype consists of several com-ponents and is designed with the objective of creating animplementation that is as independent as possible from spe-cific CASE tools. The central component, the rule en-gine, handles the activity recognition and computes mainte-nance directives. It provides an interface for receiving new

change events and requires an interface for querying andupdating traceability relations. The change event interfacewill be used by a tool-specific event generator that recog-nizes changes to model elements and collects data about thechanged element in order to create change events for therule engine. The required query and update interface alsohas to be implemented by a tool-specific adapter. Depend-ing on where the traceability relations are stored, the adaptergives access to relations stored within the model or to anexternal relationship repository such as EXTESSY Tool-NET. In the prototype, we have implemented our own trace-STORE repository that stores relations within the tool, butprovides significantly more functionality in terms of trace-ability than the base modeling tool itself.

In addition, a rule engine reads a rule catalog stored inXML format. This catalog can be edited and validated witha specific rule editor. Each of the major components is de-scribed further in this paper.

traceMAINTAINER

Model

Traces

Event GeneratorAdd-in

traceSTOREAdd-in

Rules

Change Events

Link Queries andUpdates

Rule Editor

UML Modeling Tool

Rule Catalog

Rule Engine

LinkUpdateManager

EventCache

OpenActivityCache

EventController

Figure 1. Overview of the traceMaintainercomponents

2 Rule EngineThe rule engine is the main component of traceMain-

tainer. It consists of an EventCache that holds a number oflast incoming change events from the event generator, anOpenActivityCache that holds all partly recognized activi-

ICSE’09, May 16-24, 2009, Vancouver, Canada978-1-4244-3494-7/09/$25.00 © 2009 IEEE Companion Volume425

ties for the events currently held in the EventCache and alink update manager that determines the necessary trace-ability maintenance actions for recognized development ac-tivities. It depends upon the rule catalog for its operation(see Section 4).

The rule engine has a single user interface intended forthe normal user. This is the interaction dialog that automati-cally pops-up in situations where a development activity hasbeen recognized, but not enough information is available tocarry out the traceability update completely automatically(see Figure 2). The dialog provides detailed informationabout the recognized development activity and the neces-sary update.

Figure 2. The user interaction dialog is dis-played in situations where the update cannotbe carried out automatically

The dialog shows two list boxes separating the incomingand outgoing traceability relations involved in the updatecontext. Each row in these boxes represents an existingor potential new traceability relation. The user can decideto keep (stay is the default and preselected action) ordelete existing relations on the source elements. For theevolved elements, the user can decide to create or discardthe relation. A decision on the proposed relations withoutpreselected actions determined is required to be able tocomplete the update, while a change of a preselected actionis made possible in other cases but not required.

3 Event GeneratorThe event generator is created as an add-in to Enterprise

Architect. It observes changes to elements of interest andcaptures a number of properties to the changed element.The types of elements to be observed and their propertiesof interest are defined within an accompanying informationmodel stored in XMI format. The information model caneasily be opened as a regular model in Enterprise Architectto allow the user to customize the generated events in termsof observed elements and collected properties.

4 Rule Editor and Rule CatalogThe rule editor is a stand-alone application that is

intended to help in two usage scenarios. First, it validatesan existing rule catalog upon opening it according tofour categories of possible failures. Second, it providesfunctionality to edit and create all parts of a rule catalogwhilst also validating the changes. For rules, the update andthe description provided within notifications can be defined(see Section 2). To support definition, typical values foreach property can be stored in the information modeland provided within a drop-down box in the rule editor.Each entry made for a property is syntax-checked and alldefined references are checked for their existence withinthe alternative. Failures are indicated by colored values (redmeans syntax mistake and violet means reference mistake.

5 StatustraceMaintainer provides an extensive set of features for

implementing and maintaining traceability between a broadspectrum of UML model element types. Its main compo-nent, the rule engine, has been implemented independent ofa specific modeling tool and supplies a well-defined API.In this paper, we have described tool-specific extensions forthe Enterprise Architect modeling tool to satisfy the APIand also enhance its existing traceability functionality. Ini-tial experimental results have been encouraging ([2], [1])and further industrial case studies are planned.

Since the rules are likely to evolve, we have createda rule editor for their definition and validation. We arecurrently investigating how to semi-automatically definerules by observing a developer performing change activitiesin situ using a rule recorder. We are further investigatinghow to handle the undo function within third-party model-ing tools effectively, whilst still recognizing developmentactivities accurately.

Acknowledgments The authors would like to thankTobias Kuschke, Christian Kittler and Arne Roßmanith forimplementing the prototype.

References[1] P. Mader, O. Gotel, and I. Philippow. Enabling automated

traceability maintenance by recognizing development activi-ties applied to models. In Proceedings of 23rd InternationalConference on Automated Software Engineering ASE2008,L’Aquila, Italy, Sept. 2008.

[2] P. Mader, O. Gotel, and I. Philippow. Rule-based maintenanceof post-requirements traceability relations. In Proceedingsof 16th International Requirements Engineering Conference(RE’08), pages 23–32, Barcelona, Spain, Sept. 2008.

426