Rule-Based Maintenance of Post-Requirements Traceability Relations

Patrick Mader1, Orlena Gotel2 and Ilka Philippow1

1Department of Software SystemsIlmenau Technical University, Germanypatrick.maeder|ilka.philippow@tu-ilmenau.de

2Department of Computer SciencePace University, New York, USA

ogotel@pace.edu

Abstract

An accurate set of traceability relations betweensoftware development artifacts is desirable to supportevolutionary development. However, even where aninitial set of traceability relations has been established,their maintenance during subsequent developmentactivities is time consuming and error prone, whichresults in traceability decay. This paper focuses solelyon the problem of maintaining a set of traceabilityrelations in the face of evolutionary change, irrespec-tive of whether generated manually or via automatedtechniques, and it limits its scope to UML-drivendevelopment activities post-requirements specification.The paper proposes an approach for the automatedupdate of existing traceability relations after changeshave been made to UML analysis and design mod-els. The update is based upon predefined rules thatrecognize elementary change events as constituentsteps of broader development activities. A prototypetraceMaintainer has been developed to demonstratethe approach. Currently, traceMaintainer can be usedwith two commercial software development tools tomaintain their traceability relations. The prototypehas been used in two experiments. The results arediscussed and our ongoing work is summarized.

Keywords: Change; Post-requirements traceability;Rule-based traceability; Traceability maintenance.

1 Introduction and problem statement

Traceability relations articulate the dependenciesbetween artifacts created during a software systems de-velopment project. These relations help stakeholders toundertake many development tasks, such as: (a) veri-fying the implementation of requirements; (b) analyz-ing the impact of changing requirements; (c) retrievingrationale and design decisions; and (d) supporting re-

gression testing after changes have been made. To en-sure that such benefits accrue, it is necessary to havean accurate (i.e., representative and up-to-date) set oftraceability relations between the artifacts, establishedat a level of granularity that is suitable for the projectat hand. This requires not only the creation of the re-lations during the initial development process, but alsothe maintenance of these relations after changes havebeen made to the associated artifacts. The number ofpotential traceability relations, even for small softwaresystems, demands effective method and tool support.

The need to manually establish and maintain trace-ability relations, and the difficulty to achieve thesetasks automatically as a by-product of developmentactivities, is a recognized reason for the limited useand effectiveness of traceability in industrial projects(Ramesh and Jarke [16], Arkley et al. [3]). Muchof the recent academic research has focused on thefirst aspect of this problem through the automatedgeneration of traceability relations. The majority ofthese approaches apply text mining and informationretrieval techniques to identify candidate relations andhave been producing promising results (Alexander [1],Antoniol et al. [2], Marcus and Maletic [14], HuffmanHayes et al. [12]). However, they often require man-ual effort to ensure correct relations have been identi-fied. One way to address this issue is for competingtechniques to vote and reach consensus [8]. Researchaddressing the maintenance aspect of the problem hasbeen less extensive. Spanoudakis et al. [19] describerules based on information retrieval for the automatedcreation and subsequent maintenance of traceability re-lations. Cleland-Huang et al. [5] describe an approachfor maintenance which informs the owner of artifactsabout relevant changes to requirements so they cantake action. Related work is discussed in Section 6.

The approach described in this paper focuses exclu-sively on the maintenance of traceability relations dur-ing the evolution and refinement of structural UMLmodels. The initial creation of the traceability rela-

16th IEEE International Requirements Engineering Conference

1090-705x/08 $25.00 © 2008 IEEE

DOI 10.1109/RE.2008.24

23

tions between these artifacts could be established man-ually or automatically. Whichever way, the approachis concerned with sustaining the investment that hasbeen made in creating the initial set. The approachrevolves around the monitoring of elementary changesthat take place to UML model elements within a CASEtool and the generation of change events based uponthese, using a set of rules to help recognize these eventsas constituent parts of intentional development activi-ties. This is in recognition that the process of refiningan analysis model towards a final design model, andany evolution of these models resulting from chang-ing requirements, comprises a number of recurring de-velopment activities. Once these activities have beenidentified, traceability relations related to the changingmodel elements can be updated automatically.

The remainder of the paper is structured as follows.In Section 2, we present an overview of our approach.In Section 3, we discuss the rules used to maintaintraceability relations. In Section 4, we describe theprototype developed to implement our approach. InSection 5, we present the results of two experiments toprovide preliminary validation. In Section 6, we givean account of related work and discuss the contribu-tion of our work. Finally in Section 7, we highlightoutstanding issues that are the subject of future work.

2 Approach

For traceability to realize its promise of developmenttask support, it is necessary to have an accurate set oftraceability relations for a project. Due to the rela-tively low precision of the candidate relations gener-ated by automated techniques, and the manual inter-vention often required to prune these, it is not viableto regenerate traceability relations automatically everytime either a change is made or they need to be used.The ultimate vision would be the ability to establishand maintain traceability relations concurrently withdevelopment activities in an automated manner so theyare always ready to use.

Our work supports part of this vision by focusingon maintaining traceability as a by-product of changesmade to structural UML models during object-orientedsoftware development. An assumption of our approachis that development activities that are part of this pro-cess are undertaken within a Computer Aided SoftwareEngineering (CASE) tool. We focus on structural UMLmodels and in maintaining post-requirements traceabil-ity [11] as this a common scenario in industry. Our ap-proach also assumes the pre-existence of an initial setof traceability relations established between the mod-els. Given these preconditions, we support the follow-

ing scenarios: (i) the change of a model within the samelevel of abstraction (e.g., evolving the analysis model),typically to align the model as a result of changing ornew requirements; and (ii) the change of a model intoa more detailed level of abstraction (e.g., refining theanalysis model into the design model), typically to ex-plore requirements realization.

Our approach consists of three stages:

1. capturing changes to model elements and generat-ing elementary change events (Section 2.1);

2. recognizing the wider development activity appliedto the model element, as comprised several elemen-tary change events (Section 2.2); and

3. updating the traceability relations associated withthe changed model element to maintain accuracyof the set (Section 2.3).

Figure 1 illustrates these stages using an examplethat replaces an unspecified association in a UML de-sign model with two unidirectional associations. Thisactivity is undertaken as most programming languagesare not able to implement bidirectional associations [4],so is done for requirements realization (scenario (ii)above). The resulting two associations are semanticallyequivalent to the preceding single association, mean-ing that all original traceability relations should be re-established at both resulting elements. Stage 1 on theright hand side of Figure 1 shows a flow of elementarychange events: deleting an unspecified association be-tween class Order and class Customer, creating a uni-directional association between class Order and classCustomer and creating a unidirectional association be-tween class Customer and class Order. These changesallow for recognizing the refinement development ac-tivity shown in stage 2. This triggers the update of theexisting and single traceability relation by copying itto the resulting two elements in stage 3.

2.1 Capturing elementary change events

Some CASE tools allow the capture of changes toUML models as change events. For our approach, wefocus on the UML classifiers and relations that estab-lish the structure of the system as model elements ofinterest: class, component, package, attribute, method,association, dependency, inheritance and stereotypes ofthese (e.g., aggregation, composition, association classand interface). We distinguish three types of change tothese elements: add, delete and modify.

We also maintain information about the propertiesof those model elements that the changes are appliedto (e.g., name and identifier). For the addition of an el-ement, these properties only exist after the creation of

24

Order Customer Order Customer

Order Customer Order CustomerOrder Customer

Stage 1: Capture changes to model elements and generate change events

Stage 2: Recognizedevelopment activities within the �ow of change events

Stage 3: Updatetraceability relationsaccording to recognizeddevelopment activity

AddClass

DeleteAssociation

AddAssociation

AddAssociation

ModifyComponent

Order Customer

«trace»

Order Customer

«trace»«trace»

Development activity

Traceability relationupdate

Captured change events

Create Order Create Order

Figure 1. Stages of the approach as visualized by the example of refining an association

the element, and for deletion they only exist before de-struction. For the modification of an element, both preand post modification properties are required for anal-ysis. We define four elementary change events: ADD,DEL, preMOD and postMOD. Stage 1 of our approachcaptures the change type applied to a model elementand generates the corresponding change event(s) withall the necessary properties of the changed element.

2.2 Recognizing development activities

It is not possible to maintain traceability relationsby only examining elementary change events. Stage 2of our approach has to recognize the overarching de-velopment activity that is realized by a collection ofelementary change events. We therefore search for pre-defined patterns within a flow of change events whileworking with a CASE tool. These correspond to theconstituent steps of development activities that can becarried out while changing a UML model. The taskof recognizing these involves challenges that are han-dled by the approach. (a) Several elementary changeevents can relate to one activity. The type of a changeand the impacted model element do not offer enoughinformation to relate changes to each other. It is neces-sary to compare additional properties. For the exam-ple of Figure 1, the replacing associations have to bedirected, in opposite directions and between the sameclasses as the original. (b) The same development ac-tivity can be achieved by different elementary changes.For Figure 1, rather than deleting the unspecified asso-ciation and adding two new unidirectional associations,it could be modified to a directed association. (c) Thesame development activity can be achieved by the sameelementary changes in different sequences. For Figure1, the replacing unidirectional associations could be es-tablished before the deletion of the existing association.

2.3 Maintaining traceability relations

Stage 3 of our approach brings the set of traceabil-ity relations back into an accurate state by performingtraceability updates related to the development activ-ity undertaken. During the recognition of developmentactivities, we are careful to pinpoint those changes thatare purely atomic (i.e., the addition of a totally newelement, the deletion of an element, or simple modifi-cation that does not destroy, enhance or move an ele-ment). To differentiate these from wider activities inwhich they may play a role, we assume that a developerwill complete a composite activity within a number ofelementary changes and so introduce the concept of de-lay. This is discussed in more detail in Section 3.4.

If an element is deleted, it can mean that this partof the model is not needed anymore, in which case itis necessary to delete the associated traceability rela-tion(s). The developer will be prompted to confirmthis action and the previous state will be versioned.It is equally possible that this deletion is part of awider activity resulting in new elements. In this case,it would be necessary to transfer the traceability re-lation(s) from the original element to the resulting el-ement(s) to keep the traceability set accurate. Like-wise, if an addition cannot be related to any meaning-ful wider activity, the enhancement of the model by anew element is assumed. The element is highlightedand tagged because human input is still required whenelements are originated. If a wider activity has beenrecognized and the impacted element was related bytraceability relations, these relations can be maintainedafter the completion of the activity. For elements thatevolve as part of a development activity, we maintainthe traceability relations in two ways. First, all discon-nected relations of an evolving element will be recon-nected to the evolved element or composite of elementsafter the change. Second, if during the modification ofan element its replacement or one of its enhancementsbecomes part of a new parent element, the developer

25

has the option to move or copy each of the traceabilityrelations on the old parent to the new parent.

To support change propagation, we distinguish thetraceability relations of an element into two groups, in-coming relations from dependent elements and outgo-ing relations to independent elements. To minimize themanual effort, we propagate change only to dependentelements, because we assume a change to a dependentelement will not impact the independent one (forwardengineering). For example, if a design class is beingmodified, the change would be propagated to depen-dent test cases validating the class, but not to the inde-pendent requirements defining the class. When changeis propagated, all traceability relations of a changingelement incoming from dependent objects receive thestatus suspect and are tagged with the description ofthe recognized change. By this mechanism, we propa-gate change to all dependent elements and their mod-els, and give support to manually resolve a possible in-consistency. If the dependent object belongs to a modelwe support (currently only structural UML models) ourapproach can also maintain the traceability relations ofthe dependent element while resolving this.

3 Traceability maintenance rules

The approach is built upon rules that allow for therecognition of development activities within a flow ofelementary change events. These rules provide a direc-tive to update traceability relations in predefined ways.In this section, the definition of these rules, their rep-resentation and their application is presented.

3.1 Rule definition

The viability of our approach depends upon the abil-ity to catalog and capture all developmental activitiesthat have traceability implications for the artifacts wehandle. The activities we focus upon are those thatrecur for most software development practices basedupon UML modeling, though obviously depend uponthe particular process used, the capabilities of the tar-get programming language and the intended domain.

To catalog representative development activities, westudied several methodologies as well as practice on in-dustrial projects and collected traceability relevant ac-tivities that typically occur during the analysis and de-sign of systems or due to later changes. Forward en-gineering processes we consulted included the UnifiedProcess [13] and we support the development activi-ties that Arlow suggests for refining an analysis modelinto a design model [4]. Also, we consulted Fusion [7],Quasar [18], the V-Model [17] and Refactoring [10]. We

obtained a list of 38 development activities with impacton traceability (12 apply to associations, 6 to inheri-tance, 3 to attributes, 1 to methods, 6 to classes, 5 tocomponents and 5 to packages). Development activi-ties that apply to relations include: refining an unspec-ified association into one or two directed associations(as per Figure 1); refining an association to aggregationor composition; resolving one to many associations; re-solving many to many associations; and resolving as-sociation classes. Development activities that apply toclassifiers include: moving an attribute, method, classor package; splitting a class, component or package;merging a class, component or package; converting aclass to a component; and converting an attribute to aclass (see Figure 4).

All the activities identified to date have been cap-tured by 21 rules with 67 alternative ways of occurring.Some are captured by more than one rule (e.g., movingan attribute) and some are only traceability relevant ifthe impacted model element is being deleted and a newelement created, instead of modifying the existent ele-ment (e.g., refining association to aggregation).

3.2 Rule representation

Rules have been defined to recognize developmentactivities and are stored in the open XML format.These capture all valid sequences of changes that couldcomprise the activity as well as information about thenecessary update to traceability relations.

The syntax of a rule is given by a self-defined XMLSchema Definition (XSD). Each rule is focused on onedevelopment activity performed on one type of modelelement. The head of a rule consists of a distinct <RuleID>, a description of the development activity it isable to recognize and the type of the model elementthe activity focuses upon. The rule then consists ofone or more <Alternative> sections. These sectionsreflect different sequences of change events to accom-plish the same activity (see Sections 2.2 and 3.3). Eachalternative is composed of a <ChangeSequence> and a<LinkUpdate>. The <ChangeSequence> section con-sists of a definition of all expected elementary changeevents to recognize the sequence. The <LinkUpdate>section defines all source elements impacted by the ac-tivity and all target elements that have been impacted,created or modified during the activity and require up-date of traceability relations (see Section 3.5).

3.3 Definition of change sequences

A special notation is used to define so-called eventmasks that are compared with incoming change events

26

to recognize them. These masks are similar to an event,but include enhanced options to compare event proper-ties. Every event mask has a unique ID which is used toreference properties of other events during mask defini-tion. There is one special trigger event ID=“T” withineach sequence that allows the rule engine to recognizethe development activity (see also Section 3.4). Theremaining events are numbered starting with ID=“1”.To be able to recognize several elementary changes asone activity, it is necessary that the element is beingmodified or deleted, so the trigger event reflects thatelementary change that is modifying or destroying theimpacted model element. Only an incoming triggerevent allows the recognition of a new development ac-tivity. To find related change events belonging to oneactivity, the properties of the trigger event will be com-pared with those of the surrounding events.

3.4 Rule application

Figure 2 illustrates the rule application process. Onthe arrival of a new change event, the rule engine per-forms the following three tasks:

1. The event is put in an EventCache (a first in, firstout buffer for the last n incoming events). If full,the oldest event will be deleted, along with its oc-currence within all OpenRules (rules to which atleast the trigger event has been recognized, butwith events missing to complete it).

2. The event is assigned to all OpenRules with a miss-ing event equivalent to the incoming event.

3. The RuleCatalog (predefined rules) is searched forrules with TriggerEvents (one characteristic eventwithin each alternative sequence of change events)matching the type and properties of the incom-ing event. All matching rules are established asnew OpenRules and the EventCache is searchedfor matching events to complete the OpenRules.

If during task two or three an OpenRule is com-pleted, its events will be deleted from all other Open-Rules and will be disabled within the EventCache.Subsequently, the predefined traceability update forthe elements defined within the rule is performed. Thisaction restores the traceability. For most of the devel-opment activities, it is possible to do this in a fully au-tomated manner. Where it is not, we show a dialoguebox within the CASE tool to let the developer choosethe correct alternative. Note that in rare situations oneevent contributes simultaneously to many developmentactivities. This is being addressed in ongoing work.

To handle elementary change events that do not im-pact traceability, as well as unfinished development ac-tivities and the addition and deletion of elements that

on new event

put event in EventCache

delete oldest event from EventCache and all OpenRules

browse RuleCatalog for rules with matching TriggerEvent

Rule

Catalog

try to completeOpenRules

T12 ...

3 ...[if rule is completed]

do link update;delete events from all OpenRules and inactivate events in EventCache

[on match]create new OpenRule

[on new OpenRule]search EventCachefor additional matching events

Figure 2. Rule application process

are not part of a wider development activity, the Event-Cache has a configurable size. This mechanism reflectsthe assumption that the developer would complete anactivity within a certain time frame. The developmentactivities we identified comprise a minimum of 2, amaximum of 6 and an average of 3.54 events, so forthe evaluation in Section 5 we used a delay (Event-Cache size) of 30 events. This allows a developer toundertake several activities in parallel while mitigatingthe risk of recognizing activities incorrectly.

3.5 Update of traceability relations

After a development activity has been recognizedas completed, the traceability update incorporates twoparts: the update of the relations on the element itselfand the update of the relations on the parent object ofthe element. If a user interaction is necessary duringthe update, we provide a detailed description aboutthe recognized activity and the situation the user hasto resolve. In any other situation the update will becarried out automatically in the background.

To update an element’s own relations, all links onall update sources (defined within the rule) will be col-lected and, if not already existent, re-established on allupdate targets (defined within the rule). We could ex-tract possible update sources and targets automaticallyfrom the defined change sequence and save the defini-tion of these, but we found it more convenient to beable to customize the update for each rule alternative.

For the update of the relations on the parent of theimpacted element, we compare the parent of the sourcewith all parents of the targets. For any two differentparents, we let the developer decide which relations onthe source parent will be copied or moved to the updatetarget. These situations occur, for example, if a classis being moved from one package to a different packageand these packages are related by different links.

27

3.6 Status of the rule set

We developed an initial set of rules for working withstructural UML elements based on the development ap-proaches mentioned in Section 3.1. This set of rules hasbeen subject to test and now delivers good results, bywhich we mean they are able to recognize the activitiesof developers in our studies with high accuracy and per-form the required traceability maintenance (see Section5). The rule set provides for a good starting point andextension is the subject of our ongoing investigations.

4 traceMaintainer prototype

To evaluate our approach, we have developed a pro-totype. This has been implemented in Visual Studio.Net and uses the Microsoft XML Parser. It supportsthe following activities: (a) the analysis of a flow of ele-mentary change events according to a set of predefinedrules it imports from an XML file; (b) the specifica-tion of new rules; and (c) based on a match betweenevents and rules, it restores traceability. The proto-type applies rules defined using XML according to ourXML Schema Definition (XSD). The use of open andstandardized techniques to define our rules ensure theirreadability by humans as well as provide a simple andsmall engine for their interpretation and the generationof update directives for the traceability relations.

UML-CASE tool (ARTiSAN RtS,Sparx EA)

traceMaintainer

Elementary change events

Link update

traceMaintainerElementary change events

Link update

RE tool (e.g. Telelogic DOORS)

EXTESSY ToolNet

Scenario 1: Coupling with UML-CASE tool

Scenario 2: Heterogenous environment, traceability relations managed by ToolNet

Toolspecific event generator and link updater

UML-CASE tool (ARTiSAN RtS,Sparx EA)

Toolspecific event generator

Figure 3. Two possible tool usage scenarios

The prototype has been designed to be independentof specific CASE tools (see Figure 3). The intentionis for it to be deployable with every UML-CASE toolthat allows for capturing the necessary change eventsto model elements and that allows the manipulation oftraceability relations from outside the tool. It is onlynecessary to write an adapter for each tool that is to beconnected to our prototype, so the prototype basicallyaugments the existing functionality. We have devel-oped adapters to ARTiSAN Studio and to Sparx En-terprise Architect. The main purpose of these adaptersis the generation of events and the collection of elementproperties in order to provide the rule engine with stan-dardized elementary change events (see Section 2.1).

The adapters are also used to allow the rule engine toupdate traceability relations kept within the develop-ment tool. Furthermore, it is possible to use the pro-totype in heterogeneous settings of requirements andsoftware engineering tools. In these settings, the soft-ware development tool is used to capture the neces-sary change events. The directives for the necessarytraceability updates are sent to a different tool, likeEXTESSY ToolNet [9], that holds the traceability in-formation. We developed an adapter to ToolNet anduse it to hold all our traceability relations even forprojects with model elements within only one tool. Thereason is its ability to link every element of a model.

AudioSystem

- version: enum

1•3 «isLinked»Order

- audioSystem: bool

1•3

Step 1: Change of a traced requirement

New Class1•3 «isLinked»

Order

- audioSystem: bool

1•3

Step 2: ADD a new class

AudioSystem

- version: enum

1•3 «isLinked»Order

- audioSystem: bool

1•3

Step 3: MOD - rename new class and add additional properties

1•3 «isLinked»Order

- audioSystem: bool

1•3

Step 4: ADD association between class Order and audioSystem

1•3 «isLinked»Order

1•3

Step 5: DEL original attribute audioSystem

1•3 «isLinked»Order

1•3 1•3 «isLinked»AudioSystem

- version: enum

1•3

Step 6: Traceability relations have been updated automatically

«isLinked»0•1

«isLinked»

View Order List

0•3

User

uc: car order

Create Order«trace»

Figure 4. traceMaintainer updates traceabilityrelations as a user converts attribute to class

Figure 4 depicts a usage scenario for traceMain-tainer. In the scenario, the analysis model of a carorder system has to be changed because of a changerequest relating to a use case. Step 1 shows the initialsituation. The use case Create Order is realized by aclass Order. To show the link between both model ele-ments, a traceability relation exists between them. Theclass has an attribute audioSystem. The customer re-quests a change of the use case Create Order to supportdifferent audio system options during the creation of anorder. This change in the use case requires a structuralchange to the system’s UML analysis model, which in

28

turn requires the maintenance of its traceability rela-tions. The attribute audioSystem has to be convertedinto a class. Step 2 to Step 5 show how the developercould carry out the required change. A class New Classis created and renamed AudioSystem. An associationbetween class Order and class AudioSystem is created.As a last step, the original attribute audioSystem isdeleted. traceMaintainer recognizes the completion ofthe development activity and shows the depicted di-alogue before it updates the traceability relation thathas been impacted automatically. For this example,update means copying the existing relation on classOrder to the new class AudioSystem as both classesnow fulfill the use case Create Order. Step 6 shows thenewly created traceability relation on class AudioSys-tem. Within the scenario, only one way to convert theattribute into a class has been discussed, though trace-Maintainer can handle different ways to accomplish anactivity if pre-specified in its rule set.

5 Preliminary validation

We performed two experiments using the prototypeto explore the following research questions:

1. Is the approach capable of maintaining traceabil-ity relations at a level of accuracy comparable tomanual maintenance during the evolution and re-finement of UML models?

2. How much manual effort can be saved by using au-tomated maintenance and how dependent is thatsaving on the kind of modeling undertaken?

The goal of the first experiment was to evaluate thecompleteness and correctness of a project’s set of trace-ability relations after refining UML models. We usedthe analysis models of two software systems. The firstwas abstracted from a wiper control system for a car,created for Volkswagen AG, and the second was a li-brary management system developed by students of theTechnical University of Ilmenau. Sparx Enterprise Ar-chitect was used as the CASE tool and the traceabilityrelations were managed by EXTESSY ToolNet.

The documentation for the wiper system included:a document with 26 requirements statements related toa UML analysis model; an initial UML analysis classmodel composed of 21 classes, 35 attributes, 23 associ-ations/generalizations and 28 methods; and an initialset of 105 traceability relations. The documentationfor the library system included: a requirements modelwith 21 use cases related to a UML analysis model;an initial UML analysis class model with 17 classes,20 attributes, 27 associations/generalizations and 18methods; and an initial set of 59 traceability relations.

The models for both systems were given to two de-velopers (not authors of this paper). Developer A had4 years of industrial experience in model-based, object-oriented software development and developer B had 2years of experience. Both had university-level educa-tion on the topic. The task for each developer wasto refine the analysis model of the system into a de-sign model that could be implemented. Each devel-oper spent 2 hours on the task and the status of thetraceability relations were maintained by traceMain-tainer behind the scenes. After finishing the task, thedevelopers manually updated the traceability for thejust created design model to the requirements model,in consultation with a version of the initial relationsbetween the requirements and analysis model. Thissecond task took 1 hour. Each developer undertookthis task for the wiper control system and then for thelibrary management system.

Table 1. Traceability relations after task exe-cution in experiment 1

Number of links Pre- Re- tMDev tM D∩tM cision call wrong

WiperDev A 147 149 140 0.94 0.95 0.16Dev B 138 132 128 0.97 0.93 0.20

LibraryDev A 94 92 88 0.96 0.94 0.13Dev B 98 99 96 0.97 0.98 0.70

The number of traceability relations existing afterthe completion of the developers’ activities for eachsystem are depicted in Table 1 in column Dev. Thesefigures were compared with those provided automat-ically by traceMaintainer in column tM. The num-ber of correct relations in the tM set (i.e., those alsoidentified by the developer) are listed in the columnD ∩ tM. Precision is a percentage measure for thenumber of relations that have been correctly main-tained by traceMaintainer in relation to all the re-lations existing after the automated maintenance –or: truePositives/(truePositives + falsePositives).Recall is a percentage measure for the number ofrelations that have been correctly maintained bytraceMaintainer in relation to all correct relations –or: truePositives/(truePositives + falseNegatives).Column tM wrong gives the percentage of missing orwrong changes in relation to all the changes performedby traceMaintainer. The figure of up to 20% was foundto be due to incorrect or missing rules, illustrating thatthe rule set needs to be improved iteratively. From fur-ther experiments, this set is now converging.

29

Although provisional, this provides encouraging ev-idence about the ability of our approach to automatethe maintenance of traceability relations at accuracylevels approaching that attained via manual effort.Given that 50% of the task time was spent restoringtraceability, this is a considerable saving in effort. A setof 32 rules applied to 7 different types of UML modelelement were used during this experiment.

To answer our second research question in more de-tail, we used one part of the refinement activities ofdeveloper A on the library system. We analyzed thechanges the developer had applied to the model andassembled them into a detailed flow of changes. Wethen defined two possible paths of execution in termsof elementary changes to accomplish the same overar-ching development activities. These each have differingimpact on and requirements for the maintenance of theassociated traceability relations. To compare the man-ual effort that can be saved by using traceMaintainerit is necessary to examine these differences.

To explore the greatest differences, we defined andexecuted the scenario in the most optimistic way withthe least impact on traceability and in the most pes-simistic way with the maximum impact on traceabil-ity. Table 2 gives some statistics on the elements andtraceability relations of the model for the scenario in-dependent of the execution path.

Table 2. Number of elements and relationswithin the model of experiment 2

Before scenario After scenarioCount Links Count Links

Classes 23 67 35 86Associations 30 25 47 43Attributes 63 0 66 0Methods 27 0 27 0

After executing the scenario for the first time andencountering similar results in terms of recall and pre-cision as those in Table 1, we analyzed all the issuesand were able to adjust our rules accordingly. We werethen able to maintain the relations in the same waythey have been maintained manually by developer A.

Dependent on the execution path chosen, either 127or 176 elementary change events occurred taking 65and 82 minutes respectively to perform manually (seeTable 3). These changes belong to 35 and 49 traceabil-ity relevant development activities respectively. Thesurprising result was that the necessary time for themanual maintenance of relations ranged from 62 to 116minutes after the modeling period. The results showhow immense the effort required for manual traceabil-

ity maintenance actually is and how much it dependson how a modeling activity is executed. A developer’sdesign freedom is possibly lost with awareness of thefuture work a development strategy choice is likely tocost them. By using traceMaintainer within the samescenario the developers’ time required for traceabilitymaintenance could be reduced by 71% to 84%. It con-sists of user decisions on unclear link updates and ad-ditional links created on new elements during design.

After seeing how much effort is necessary to keeptraceability in order even for a relatively small scenario,one could question the necessity to maintain traceabil-ity at all. To demonstrate what would have happened ifthe developer had not maintained the traceability rela-tions, we give the Recall and Precision metrics for bothpaths of execution without traceability maintenance.For the optimistic path, we computed 65% Recall and91% Precision after all changes and no maintenance.For the pessimistic path, we computed 39% Recall and54% Precision. The metrics show that, independentof the way a development scenario is undertaken, thetraceability relations within the model erode and main-tenance is highly desirable for future viability and use.

The results from these experiments are preliminaryand there are threats to validity. Given a small set ofdevelopers, their tracing activities may not be repre-sentative of a wider population. They could have pro-duced poor sets of relations which were not a suitablebaseline for comparison with those of the approach.The researchers also discussed traceability with the de-velopers to come to an agreement about traceable el-ements and when to forge traceability relations, andboth traceMaintainer and the <LinkUpdate> sectionof the rules were customized to reflect this agreement.

6 Related work

Spanoudakis et al. [19] present a rule-based ap-proach for the automatic generation of traceability re-lations between documents which specify requirementstatements and use cases (in structured natural lan-guage) and analysis object models. Requirement-to-object-model rules, and a technique based on infor-mation retrieval, are used to establish traces. Thesecond kind of rule analyzes the relations betweenrequirements and object models to recognize intra-requirements dependencies and establishes relations.The approach requires the export of all supported arti-facts into XML and the rules generate traceability rela-tions for the exported state of the models. Due to theuse of information retrieval there is uncertainty withinthe recognized relations and limited support for devel-opers with false recognition. The approach, in its cur-

30

Table 3. Results of experiment 2Changes Activities Modeling Manual maintenance traceMaintainer Saved with tM

Optimistic execution 127 35 64,5 min 62,0 min 18,2 min 71%Pessimistic execution 176 49 82,2 min 115,8 min 18,2 min 84%

rent form, does not appear to support the maintenanceof traceability relations following artifact evolution.

Cleland-Huang et al. [5] present an approach calledevent-based traceability. The authors link require-ments and other artifacts of the development processthrough publish-subscribe relationships. Changes torequirements are categorized by seven kinds and eventsare raised according to kind. These events are pub-lished to an event server that sends notifications aboutchange to subscribers of a changed requirement. Thenotification contains information to support the updateprocess of the dependent artifacts to facilitate manualmaintenance. The approach also maintains traceabil-ity between requirements after predefined changes torequirements [6]. There are similarities between theapproach and that proposed in this paper. The au-thors also capture changes to a model (requirements)as events, their model contains one type of element(requirement) with properties of interest, they identifyseven possible change activities to requirements andthey deal with compound change events by trackinglower level tasks. The authors do not discuss how torecognize the elementary change actions and how torelate them to a compound activity in depth though.For changes to complex models created using UML, therecognition of change becomes crucial, as described andmore specifically addressed within this paper.

Olsson and Grundy [15] describe an approach inwhich they extract key information from different arti-facts (requirements specifications, use cases and tests)into abstracted representational models. The developercan then create explicit relations between the abstractelements. Some implicit relations can be defined auto-matically (e.g., consistently named users within differ-ent artifacts). Through this mechanism, changes canbe propagated. Some changes can be resolved auto-matically (e.g., changing the name of a user). Forothers, developers are informed so they can take ap-propriate action. In comparison to the work of Olssonand Grundy, we also propagate the change of a tracedmodel element. Additionally, we are able to maintainthe traceability relations of evolving model elementsin some cases automatically and in others with limiteduser interaction. In contrast, we do not need to extractthe data from the models first and provide the propa-gated information about change within the model.

Traceability is also supported by many commercial

requirements management tools, enabling the tracingof requirements to other artifacts in the software devel-opment life cycle. One example, IBM’s RequisitePro,allows developers to relate requirements kept withinthe tool to other tools in the product suite, such asRational Software Modeler. While these tools supportUML explicitly, there is limited support for the auto-mated creation or maintenance of traceability relationsat fine-grain levels. To integrate the approach of thispaper, it would be necessary to write a tool-specificadapter to generate the necessary events, and to beable to create and delete the traceability relations.

There are a number of ways to support a devel-oper in terms of traceability maintenance, from guidingthem through a predefined set of permissible activitiesthat result in traceability to attempting to recognizeactions and their implications. Our approach is basedupon the latter strategy. The problem of developers do-ing surprising and unanticipated things may result andincur need for manual intervention, but we assume thisis more desirable than removing a developer’s freedomto create. The main contribution of our approach is,therefore, that it addresses the lack of effective supportfor the automated maintenance of traceability relationsin UML-based development tools as a by-product ofwork carried out within them. It uses a rule-based ap-proach to do this based on the modeling of developmenttasks. The motivation is unique in the desire to sustaininitial investment in a project’s traceability.

7 Conclusions and future work

In this paper, we have presented an approach thatsupports the automatic maintenance of traceability re-lations between requirements, analysis and design mod-els of software systems expressed in UML. The ap-proach analyses elementary change events generatedwhile working within a CASE tool. Within the cap-tured flow, sequences of events are sought that corre-spond to predefined rules. These rules represent vari-ous ways in which recurring development activities canbe undertaken. Once a sequence has been recognized,the corresponding rule gives directives to update im-pacted traceability relations and, by these actions, re-stores the set back to an accurate state. We achievedencouraging results in two early experiments. Severalissues were recognized during the experiments which

31

have led to an improved version of the approach.Limitations of the approach are that only predefined

activities can be recognized at present and these are un-likely to reflect all possible development approaches, soit might be necessary to customize the rules to projectspecifics. Whereas there is an initial cost in identifyingdevelopment activities and formulating rules, the ruleset is proving reusable within this restricted scope ofUML-based object-oriented software engineering. It isa future exercise to gain more statistical data on thecost/benefit trade-off, costs in terms of initially defin-ing the rules and benefits in terms of the time saved onmanual maintenance across all projects using the rules.

The findings from the initial experiments high-lighted future directions for this work and are inform-ing a planned industrial case study. More empiricalstudies are needed to evaluate the effectiveness of therule matching. Addressing the situation where eventsmay participate in many rules simultaneously in an in-terleaved manner is a research issue and it would bedesirable to extend the support to other kinds of de-velopment model. The necessary preconditions wouldbe models with a limited number of discrete elementsand sufficient properties to be able to recognize mean-ingful development activities. This requires a strongerrelation between traceMaintainer and the developmentproject’s traceability meta-model to be able to cus-tomize the artifacts that can be related to each other.There may also be some scope to support the defini-tion of rules semi-automatically and to use the rules forchecking the consistency of change activities.

Preliminary results show that the approach de-scribed in this paper is capable of reducing the effort(and so cost) in maintaining traceability quite dramat-ically and at a high level of precision. The approachis intended as a complement to those approaches thatinitially create a set of traceability relations using au-tomated techniques. Further, given the attention thata number of these automated techniques place on es-tablishing traceability between design and code, theapproach can potentially fulfill an intermediary role insustaining the overall traceability picture.

Acknowledgments This work is partly funded byDeutsche Forschungsgemeinschaft (DFG) id Ph49/7-1.The authors would like to thank Tobias Kuschke andChristian Kittler for implementing the prototype.

References

[1] I. Alexander. Toward automatic traceability in indus-trial practice. In Proc. 1st Int’l Workshop on Trace-

ability in Emerging Forms of Software Engineering,pages 26–31, Edinburgh, UK, Sept. 2001.

[2] G. Antoniol, G. Canfora, G. Casazza, A. D. Lucia,and E. Merlo. Recovering traceability links betweencode and documentation. IEEE TSE, 28(10):970–983,2002.

[3] P. Arkley, P. Mason, and S. Riddle. Position paper:enabling traceability. In Proc. 1st Int’l Workshop onTraceability in Emerging Forms of Software Engineer-ing, pages 61–65, Edinburgh, UK, Sept. 2001.

[4] J. Arlow and I. Neustadt. UML 2 and the Unified Pro-cess Second Edition: Practical Object-Oriented Anal-ysis and Design. Addison-Wesley, 2005.

[5] J. Cleland-Huang, C. K. Chang, and M. J. Chris-tensen. Event-based traceability for managing evolu-tionary change. IEEE TSE, 29(9):796–810, 2003.

[6] J. Cleland-Huang, C. K. Chang, and Y. Ge. Support-ing event based traceability through high-level recog-nition of change events. In COMPSAC, pages 595–602.IEEE Computer Society, 2002.

[7] D. Coleman. Object-Oriented Development: The Fu-sion Method. Prentice-Hall, 1994.

[8] A. Dekhtyar, J. Hayes, S. Sundaram, A. Holdbrook,and O. Dekhtyar. Two heads are better than one, ortoo many cooks in the kitchen? Technique integra-tion for requirements assessment. In Proc. 15th Int’lRequirements Eng. Conf., pages 69–83, Oct. 2007.

[9] Extessy AG. ToolNET. www.extessy.com.[10] M. Fowler. Refactoring: Improving the Design of Ex-

isting Code. Addison Wesley, 1999.[11] O. C. Z. Gotel and A. C. W. Finkelstein. An analysis

of the requirements traceability problem. In First In-ternational Conference on Requirements Engineering(ICRE’94), pages 94–101. IEEE CS Press, 1994.

[12] J. H. Hayes, A. Dekhtyar, and J. Osborne. Improvingrequirements tracing via information retrieval. In RE,page 138. IEEE Computer Society, 2003.

[13] I. Jacobson, J. Rumbaugh, and G. Booch. The UnifiedSoftware Development Process. Object Technology Se-ries. Addison-Wesley, Reading/MA, 1999.

[14] A. Marcus and J. I. Maletic. Recoveringdocumentation-to-source-code traceability links usinglatent semantic indexing. In Proc. of the 25th Int’lConf. on Software Eng. (ICSE-03), pages 125–137,Piscataway, NJ, May 3–10 2003. IEEE CS.

[15] T. Olsson and J. Grundy. Supporting traceability andinconsistency management between software artefacts.In Int’l Conf. Software Eng. and Appl., Nov. 2002.

[16] B. Ramesh and M. Jarke. Toward reference models ofrequirements traceability. IEEE Trans. Software Eng,27(1):58–93, 2001.

[17] V. Schuppan and W. Rußwurm. A CMM-based eval-uation of the V-model 97. In R. Conradi, editor,EWSPT, volume 1780 of LNCS, pages 69–83, 2000.

[18] J. Siedersleben. Moderne Software-Architektur.Dpunkt Verlag, August 2004.

[19] G. Spanoudakis, A. Zisman, E. Perez-Minana, andP. Krause. Rule-based generation of requirementstraceability relations. JSS, 72(2):105–127, 2004.

32