A Framework for Mapping Traceability Relationships - CiteSeerX

A Framework for Mapping Traceability Relationships Susanne A. Sherba, Kenneth M. Anderson, and Maha Faisal University of Colorado Department of Computer Science Boulder, CO 80309-0430 USA {sherba, kena, faisal}@cs.colorado.edu Abstract Traceability relationships help stakeholders understand the many associations and dependencies that exist between software artifacts created during a software development project. Individual relationships between specific artifacts can be useful in understanding portions of the system. However, these explicit relationships are greatly outnumbered by the implicit relationships that exist between artifacts. This situation adds to the complexity of software development. Stakeholders need a way to understand all the relationships that exist in a software development project. We describe TraceM, a framework for automating the management of traceability relationships. A key contribution of TraceM is its ability to transform implicit relationships into explicit relationships by processing chains of traceability relationships. Thus, our framework has the potential to provide software developers with insight into the state of their software development projects.

1. Introduction Traceability can provide important insight into system development and evolution. Antoniol et al. maintain that traceability assists in both top-down and bottom-up program comprehension [5]. According to Jacobson, Booch, and Rumbaugh, “[t]raceability facilitates understanding and change [13].” Palmer asserts that “[t]raceability gives essential assistance in understanding the relationships that exist within and across software requirements, design, and implementation [18].” There are many different types of relationships that exist between artifacts. For example, the allocation of requirements to components can be traced [9], relationships between requirements and architectures can be captured [11], trace information between design models and implementation can be established [10], and relationships between

source code and natural language documentation can be discovered [5, 14]. However, in isolation, each individual type of relationship provides only limited information. For example, a stakeholder might need to verify that all requirements have been implemented in code. If a trace between requirements and source code has been explicitly created, this is an easy task. However, if only requirements to design and design to code relationships have been created, the question is more difficult to answer. In this case, to answer his question a stakeholder needs to manually follow each relationship from the requirements specification to the design document and then ensure that each portion of the design is linked to a code module. This problem suggests that a requirements traceability tool should be able to derive implicit relationships from the explicit relationships already represented in the system. The user should then be allowed to make these newly discovered relationships explicit. In this way, a synergy is formed. This paper presents the relationship mapping service of TraceM, our traceability management system, and explains how it allows new relationships to be discovered based on existing explicit relationships. The next section describes our conceptual framework. We then present an example of the use of the relationship mapping service to demonstrate the benefits it provides to stakeholders.

2. Approach TraceM uses the generic services of open hypermedia [17] and information integration [2] to enable a new approach to requirements traceability. When customized, we believe that these techniques will be instrumental in solving previously intractable aspects of requirements traceability, such as handling the significant heterogeneity that is encountered in software development projects and automating the discovery of semantic relationships between software artifacts. In this section, we provide a brief overview

of open hypermedia and information integration. We then present our conceptual framework.

2.1. Open Hypermedia Open hypermedia systems [17] enable the creation and viewing of relationships in heterogeneous applications as well as the traversal of those relationships within and between applications. Open hypermedia services allow links (relationships) to be stored separately from an artifact. The open hypermedia data model supports complex relationships such as relationships with multiple anchors (n-ary relationships) and relationships between relationships [3]. Open hypermedia systems also provide services to filter relationships based on type. To take full advantage of open hypermedia services, an application needs to be integrated with an open hypermedia system.1

2.2. Information Integration Information integration [2] provides services to automate the process of discovering, creating, maintaining, and evolving relationships between heterogeneous artifacts. Information integration uses the concept of a data source to model information outside the information integration environment. A data source might be a file, a database, or even a human. Translators are responsible for importing information from data sources into the information integration environment as well as exporting information from the information integration environment. Different translators can be created to import and export information in various formats. For example, a translator might be designed to import information from a requirements specification. Another translator might export relationships in a format suitable for use by an open hypermedia system [1]. Integrators work within the environment to automate the discovery and creation of relationships. Specific integrators can be developed to find different relationships within the environment. These relationships can be between artifacts, other relationships, or collections of artifacts and relationships. In addition, information integration uses contexts to partition its information space in various ways, including time-based and task-based arrangements of a project’s artifacts.

2.3. Conceptual Framework Our conceptual framework builds on techniques from open hypermedia and information integration. As discussed in the previous two sections, open hypermedia and information integration provide generic services that enable the discovery, creation, maintenance, viewing, and traversal 1 Fortunately, the open hypermedia community has developed techniques to facilitate application integration [7, 20, 21].

of relationships. However, to be useful for requirements traceability, these generic services must be customized. TraceM, our traceability management system, is responsible for this customization and management. In contrast to our approach, most commercial requirements traceability tools (e.g., DOORS [8]) support only the manual creation of traceability relationships. In addition, these tools do not support the creation of new explicit relationships from existing ones. TraceM provides this functionality in six services: registration, scheduling, relationship mapping, evolution, query, and export. The framework is shown in Figure 1. The main elements in our framework are tool, artifact, relationship, and metadata. A tool is something that a stakeholder uses to perform a task. Examples of tools include word processors, UML diagramming tools, integrated development environments (IDEs), mail programs, version control systems, and issue tracking systems. An artifact is produced by a tool. A relationship is a semantic association between artifacts, portions of artifacts, or relationships. Metadata allows a method engineer (or someone familiar with the software project) to describe the artifacts and relationships that are created and used during the project. As can be seen in Figure 1, stakeholders are able to use their original tools. These tools produce heterogeneous artifacts. Artifact and relationship metadata is supplied by a method engineer or someone familiar with the project. This metadata is used by the traceability management system to create and customize the information space. The metadata includes information such as which translators can be applied to specific artifact types or which integrators can be used to find particular relationship types; in addition, the method engineer can indicate which artifacts and relationships are of interest to different stakeholders in the project and at what stages in the project these relationships are needed. With guidance from the traceability management system and based on the metadata, artifacts are translated into the information integration environment. Here integrators can automatically discover and create traceability relationships. These relationships are forwarded to the open hypermedia system which provides services to display the relationships in the tools that originally created the artifacts. Without the services provided by TraceM, using open hypermedia and information integration to support requirements traceability would be a manual and highly tedious process. With TraceM’s services, the enabling technologies of open hypermedia and information integration can be used to their full potential. The registration service allows users to register new artifact and relationship types as well as new translators and integrators. The scheduling service is used to schedule the execution of these translators and integrators. For example,

Stakeholders

Tool A

Tool B

Tool C

Context-specific traceability relationships

Heterogeneous Artifacts

Method Engineer

Method Definition Tool

Artifact and relationship metadata

Traceability Management System Registration

Relationship Mapping

Query

Scheduling

Evolution

Export

Anchors and links

Artifacts

Information Integration Environment

Relationships

Open Hypermedia System

Figure 1. TraceM’s Conceptual Framework. a method engineer might indicate that a translator should be run every time a new version of a file is created in the source control system or that an integrator should only be run when requested by a software developer. In addition, TraceM provides an evolution service to analyze the changes to a set of relationships over time. We believe that this service will give users insight into how a software project has reached its current state. For example, a number of instances relationship might provide insight into module cohesion. If the number of allocated to relationships between a requirements document and a component diagram explodes after an iteration in the design phase, this may indicate that one or more components have lost cohesion. The query service allows filtering of relationships so that different views of the information space can be created based on the needs of various stakeholders. For example, a customer might only be interested in viewing allocated to relationships to determine that all requirements have been allocated to components. However, a software developer might need to delve further by viewing implemented by relationships. Users will be allowed to manually create and delete relationships to further customize their view of the information space. As discussed in Section 2.1, to utilize all open hyperme-

dia services, a tool will need to be integrated with the open hypermedia system. If a tool is not integrated with the open hypermedia system, the user will be able to use the export service to request an HTML summary of the artifact’s relationships. The relationship mapping service will allow users to analyze relationships currently known to the system and to “chain” explicit relationships together to form new relationships.2 This service will be implemented by a generic integrator that takes as parameters a chain of relationship types (rel1→rel2→. . . →relN) and the name of the type assigned to the derived relationship. By invoking this integrator, the user will be able to create new explicit relationships. For instance, assume that implemented by relationships between design documents and source code and tested by relationships between source code and test cases have already been captured. Then this integrator could produce validated by relationships between the design documents and test cases. In particular, if design artifact A is implemented by source code file B which is tested by test cases C and D, then this integrator produces two new validated by relationships that directly link A with C and A with D. Our current approach to chaining relationships is based on the intersection of anchors in different relationships. (An 2 Huang

[12] calls this an indirect or transitive dependency.

anchor represents a specific location in an artifact.) Relationships and thus the anchors they contain are discovered and created by integrators. Anchors that integrators discover and create can be arbitrarily complex. Integrators can employ various methods such as information retrieval techniques [4] or runtime analysis [10] to discover relationships. At this point in our work, the task (and thus the complexity) of locating and creating anchors is delegated to integrators that perform relationship discovery. This approach greatly simplifies both the specification and implementation of the relationship mapping integrator. Our initial approach to a relationship mapping integrator uses binary relationships in which one anchor is the source anchor and the other is the destination anchor. If R1 and R2 are relationships and R1.destinationAnchor = R2.sourceAnchor, we can create a new explicit relationship R3 such that R3.sourceAnchor = R1.sourceAnchor and R3.destinationAnchor = R2.destinationAnchor. However, in the future we plan to develop more complex relationship mapping integrators. For example, an integrator might be created to perform chaining with relationships that contain more than one source or destination anchor. Another integrator might find potential matches based on the intersection of anchors and then actually create relationships only if certain conditions are met in the artifact and/or relationship metadata. For instance, a developer might impose a constraint that relationships can be chained only between artifacts that belong to a particular configuration of a software system. Once these integrators are developed, it is a simple task to incorporate them into the information integration environment and the TraceM framework. The user will also be able the view the relationships currently known by the system to identify possible mappings. For example, a user might query the system to see if it currently knows about relationships between a requirements specification and source code. The system might determine that those relationships exist implicitly and suggest that they can be created by chaining together allocated to relationships and implemented by relationships. The user can then invoke the relationship mapping integrator to create a new explicit representation of the implicit relationships. The advantage of chaining relationships is that the addition of a single new relationship type has the potential of creating many new relationships because it may form new chains with previously existing relationship types. This forms a powerful synergy of relationships that does not exist when relationships are viewed only as isolated instances. An example of this synergy is presented in the next section.

Requirements Specification

Source Code

allocated_to

elaborated_by

UML Class Diagram

Mailing List Archive

Figure 2. Initial Explicit Relationships.

3. Example This section describes an example of how the addition of explicit relationships along with the chaining of relationships can lead to the discovery of new relationships. It first describes two separate projects in which relationships between different types of artifacts were discovered. It then illustrates how the addition of a single new explicit relationship produces a synergism that is not found when the relationships are viewed individually. The first project was concerned with finding relationships between source code and messages in the archive of a development mailing list. Mailing lists, especially those used in open source projects, can provide valuable insight into a project’s development and evolution. These lists contain a variety of information including historical information (rationale) as well as information about current defects, issues, and changes. However, the sheer volume of postings on these lists makes finding relevant information difficult, if not impossible. (One of the authors recently subscribed to the user mailing list of an open source project that had over 500 postings in one month [16].) For our prototype, we chose simply to use method names from the source code to create relationships with the messages posted to the mailing list. The mailing list itself was partitioned based on posting date. This allowed us to create a loose correspondence between messages and specific releases based on date. A translator was created to extract the date, author, subject, and content for each message from the mailing list archive. Another translator was created to extract method names and locations (start and end line numbers) from the source code. The Code2MailingList integrator was then able to find relationships between the source code and mailing list for a given development period.

The second project concentrated on relationships between a requirements specification and a UML class diagram. Again, we focused on the simple case of finding relationships between a UML class diagram and the requirements specification based on class name. For example, a “Person” class in a UML class diagram was linked to all occurrence of the word “person” in the requirements specification. Finding these relationships can be enhanced by the use of information retrieval techniques (see, for example, [5]). In this project, our requirements specification was written in Microsoft Word [15]. We were able to extract the text from the Word document using the WordReqs translator. The class diagram artifact was created in ArgoUML [6]. ArgoUML saves its model information in XML Model Interchange (XMI) format [22]. Thus, an XMI translator was used to extract class names from the diagram. Once these two artifacts had been translated, a Class2Reqs integrator was able to discover relationships between the class diagram and the requirements specification. Figure 2 shows the initial state of the artifacts and relationships in these two projects. As can be seen in the figure, there are two disjoint sets of artifacts. Taken individually, the relationships between the requirements specification and the UML class diagram as well as the relationships between the source code and mailing list archive provide useful insight into the project. However, there is no way to connect the artifacts in one set with those in the other. If we can find a way to relate the two disjoint sets of artifacts, we can gain a deeper understanding of the system. Several researchers have written about finding relationships between class diagrams and source code [4, 10]. Thus, we propose that by finding relationships between class diagrams and source code using one of these methods, we can join the two disjoint sets. This is illustrated in Figure 3. Now that our disjoint sets have been connected, we are able to gain more insight into the system. However, it is still not easy to answer many questions. For example, a stakeholder might want to view all messages that are related to a specific requirement. With our current information, he would need to first follow relationships from the requirements specification to the UML class diagram. As shown in Figure 4, the requirement in question might be related to several classes. From there he would need to trace relationships from each of these classes to their implementation. Even if we have a one-to-one correspondence between design classes and implementation classes, our stakeholder is still left having to keep track of three separate relationships. From the source code, he must trace to the messages in the mailing list archive to find an answer to his question. Manually tracing these relationships can easily become confusing and cumbersome. Our proposed relationship mapping service will simplify this task. Using a relationship viewing tool, the user can


Newly created explicit relationship

allocated_to

Source Code

elaborated_by implemented_by

UML Class Diagram


Figure 3. Additional Explicit Relationship Connecting the Two Disjoint Sets.


Source Code

UML Class Diagram


Figure 4. Manually Tracing from a Requirement to Related Messages.


Source Code

discussed_by allocated_to

elaborated_by

implemented_by UML Class Diagram


Figure 5. Creating an Explicit Relationship from an Implicit Relationship.

query the system about existing explicit relationships to determine if any explicit relationship between requirements and messages in the mailing list exist. As Figure 3 shows, the system will inform that user that the requested relationship does not exist explicitly but can be derived by chaining together three relationships: the allocated to relationship between the requirements specification and the design, the implemented by relationship between design and code and the elaborated by relationship between source code and messages. In this example, there is only one chain of relationships that connects the requirements specification and the mailing list archive. However, in some cases several distinct paths between artifacts may exist. The system will show the user the different chaining options available. The user will then be able to indicate that a specific chain of relationship types should be used to form a new explicit relationship type. In this specific example, the user might indicate that the relationships allocated to→implemented by→elaborated by should be chained together to form a new discussed by relationship. This newly created relationship is shown in Figure 5. Once this new relationship has been created, it becomes easy for a stakeholder to view all messages that are related to a specific requirement, since it is now possible to traverse directly from the requirements specification to the mailing list archive.

4. Evaluation To evaluate the feasibility of our approach, we are currently building a proof-of-concept prototype of our conceptual framework. We will use this prototype to evaluate the

interaction of our framework with the open hypermedia and information integration systems as well as external tools; in addition, we will assess TraceM’s ability to manage the activities of translators and integrators. The prototype will also allow us to perform a preliminary evaluation of TraceM’s user interface. We will engage 2–5 computer science graduate students to perform several tasks (e.g., invoking translators and integrators, displaying different types of relationships, exporting information, etc.). This preliminary evaluation will help us detect useability problems so that they will not influence later evaluation. In the next phase of our evaluation, we will conduct a comparative study using artifacts from a small software development project. We will ask test subjects to answer questions using three different approaches: 1. No explicit traceability links represented—test subjects are free to use any tools with which they are familiar (e.g., grep and find) 2. Traceability links created and represented in a commercial tool 3. Traceability links generated by TraceM and represented in the tools that originally created the artifacts We plan to normalize the data between the commercial tool and TraceM so that the quality of the traceability information captured does not influence the test. We will ask questions such as “Which test cases are related to this requirement?” and “Which requirements are implemented by this code module?” We will use post-evaluation surveys to record the test subjects’ experiences in using the different tools and to solicit their opinions on the various approaches. In the final phase of our evaluation, we plan to apply our approach to the artifacts of an open source project. This will help us determine if our approach can successfully be scaled to a larger project. It will also allow us to evaluate our approach using “real world” data. In addition, we will attempt to develop a characterization of the information space by defining the types of relationships that we can capture and manage.

5. Related Work TraceAnalyzer [10] is a tool that establishes trace information between design model elements and implementation. Test scenarios are executed on a running software system and execution information (such as code lines executed) is obtained by using a monitoring tool. This information is then used to establish a footprint for the scenario. The footprint information is combined into a footprint graph; this process is referred to as atomizing. Once the footprint

graph has been created, relationships to model elements can be generalized and refined. This approach differs from ours in that a running system must exist before trace information can be obtained. Also, some initial information about potential relationships between model elements and scenarios must be hypothesized manually. The tool assumes that this information is correct until a contradiction is found. Our relationship mapping service focuses on explicit relationships already known to the system and the new relationships that can be derived from these existing ones. TraceAnalyzer focuses on finding relationships between artifacts in a specific portion of the information space. Our focus is on managing relationships throughout a software development project. Huang describes an event-based approach to traceability [12]. In this approach, dynamic links are maintained as publish/subscribe relationships. Dependent objects subscribe to the requirements on which they depend. The emphasis is on maintaining an accurate traceability scheme. The author includes a discussion of indirect or transitive dependencies and how they influence the accuracy of the traceability scheme. Both optimistic and pessimistic methods for updating indirect dependencies are presented. In the pessimistic scheme a dependent object is notified immediately; in the optimistic scheme notification is delayed until an actual query is performed in hopes that the inconsistency is resolved before the query occurs. Our approach is not directly concerned with updating inconsistencies although this could be accomplished by an integrator. Rather, in the relationship mapping service we focus on the discovery of new relationships based on the explicit relationships currently known to the system. Zisman et al. [23] describe an approach that automates the discovery of traceability relationships between requirements artifacts. Their approach focuses on three specific types of documents: a commercial requirements specification (CRS), a functional requirements specification (FRS), and a requirements object model (ROM). Their process is “driven by the requirements object model.” It first finds traceability relationships between both the CRS and ROM and the FRS and ROM. Based on these relationships, relationships between the CRS and FRS are created. Our relationship mapping approach is more generic. Instead of creating relationships based on specific artifacts, our approach allows the user to indicate which relationships should be chained based on relationship type. Relationships are then chained based on common source and destination anchors. This allows relationship chaining to be applied to any relationship type known to the system. In our approach, the complexity of creating relationships and anchors is contained in the information integration integrators that discover and create relationships, not the relationship mapping service itself.

TOOR [19] employs a three phase approach to traceability: definition, registration, and extraction. In the definition phase, a system administrator defines the objects and relationships of interest to the project. During the registration phase, users are able to manually register objects and relations of interest by filling in templates. Relations in TOOR are binary and contain the notion of a source and a target object. The extraction phase allows traceability relationships to be computed and viewed. “Indirect” or transitive relations can be computed by the system; there is no need to represent these implicit relations explicitly. TOOR also allows the creation of new relationships through the writing of axioms; the axioms specify new relation types based on existing relation types. TOOR is similar to our framework in that it supports user-defined relationships and composition of those relationships. TOOR’s registration phase is similar to the metadata used by our framework. Our approach differs in that, through the use of information integration techniques, we plan to automate the creation of explicit relationships. These relationships can then be composed (chained) based on type.

6. Conclusion In this paper we have described an approach to automating the management of traceability relationships. We have presented our conceptual framework as well as an example of the use of our relationship mapping service. Traceability relationships provide valuable insight into a system. They allow stakeholders to answer questions such as “Which messages are related to this requirement?” or “Which test cases cover this code module?” However, if these relationships are not captured explicitly, it becomes the responsibility of each individual stakeholder to manually trace through a set of explicit relationships to find answers to these questions. Thus, these implicit relationships contribute to the complexity of software development. Our relationship mapping service allows stakeholders to view the explicit relationships in a system and to chain these relationships together to make previously implicit relationships explicit. In addition, since these implicit relationships are being made explicit within the context of a comprehensive requirements traceability framework, they now can be explicitly managed, tracked, and analyzed as the software project evolves. This research is still in its early stages. We are currently building a prototype of our traceability management system to evaluate the feasibility and utility of our approach. We have integrated Microsoft Word [15] and ArgoUML [6] with the Chimera open hypermedia system [3]. Integrations with a web browser, an integrated development environment (IDE), a testing tool, and an issue tracking system

are planned. We have also written several sets of translators and integrators for the InfiniTe information integration environment to use in evaluating our information integration techniques [2] and are currently evaluating how these generic information integration techniques can be applied to the problems of requirements traceability.

References [1] K. M. Anderson and S. A. Sherba. Using Open Hypermedia to Support Information Integration. In OHS-7/SC-3/AH-3, pages 8–16, 2001. [2] K. M. Anderson, S. A. Sherba, and W. V. Lepthien. Towards Large-Scale Information Integration. In Proceedings of the 24th International Conference on Software Engineering, pages 524–535, Orlando, FL, USA, May 2002. [3] K. M. Anderson, R. N. Taylor, and E. J. Whitehead, Jr. Chimera: Hypermedia for Heterogeneous Software Development Environments. ACM Transactions on Information Systems, 18(3):211–245, July 2000. [4] G. Antoniol, G. Canfora, G. Casazza, and A. De Lucia. Maintaining Traceability Links during Object-Oriented Software Evolution. Software—Practice and Experience, 31:331–355, 2001. [5] G. Antoniol, G. Canfora, G. Casazza, A. De Lucia, and E. Merlo. Recovering Traceability Links between Code and Documentation. IEEE Transactions on Software Engineering, 28(10):970–983, October 2002. [6] ArgoUML. http://argouml.tigris.org. [7] H. C. Davis, S. Knight, and W. Hall. Light Hypermedia Link Services: A Study of Third Party Application Integration. In Proceedings of the Sixth ACM Conference on Hypertext, pages 41–50, Edinburgh, Scotland, September 1994. [8] DOORS. http://www.telelogic.com/products/doorsers/doors/. [9] M. Dorfman and R. F. Flynn. Arts—An Automated Requirements Traceability System. Journal of Systems and Software, 4:63–74, 1984. [10] A. Egyed. A Scenario-Driven Approach to Traceability. In Proceedings of the 23rd International Conference on Software Engineering, Toronto, Ontario, Canada, 2001. [11] J. Han. TRAM: A Tool for Requriements and Architecture Management. In Proceedings of the Australasian Computer Science Conference, Gold Coast, Queensland, Australia, 2001. [12] J. Huang. Robust Requirements Traceability for Handling Evolutionary and Speculative Change. PhD thesis, University of Illinois at Chicago, Chicago, Illinois, 2002. [13] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison-Wesley, 1999. [14] A. Marcus and J. I. Maletic. Recovering Documentation-toSource-Code Traceability Links using Latent Semantic Indexing. In Proceedings of the 25th International Conference on Software Engineering, Portland, Oregon, USA, 2003. R R http://www.microsoft.com/office. [15] Microsoft Word

. [16] ObJectRelationalBridge (OJB). http://db.apache.org/ojb/. [17] K. Østerbye and U. K. Wiil. The Flag Taxonomy of Open Hypermedia Systems. In Proceeding of the Seventh ACM Conference on Hypertext, pages 129–139, Washington, DC, USA, 1996.

[18] J. D. Palmer. Traceability. In R. H. Thayer and M. Dorfman, editors, Software Requirements Engineering, Second Edition, pages 412–422. IEEE Computer Society Press, 2000. [19] F. A. C. Pinheiro and J. A. Goguen. An Object-Oriented Tool for Tracing Requirements. IEEE Software, pages 52– 64, March 1996. [20] E. J. Whitehead, Jr. An Architectural Model for Application Integration In Open Hypermedia Environments. In Proceedings of the Eighth ACM Conference on Hypertext, pages 1–12, Southhampton, UK, April 1997. [21] U. K. Wiil and J. J. Leggett. The HyperDisco Approach to Open Hypermedia Systems. In Proceedings of the Seventh ACM Conference on Hypertext, pages 140–148, Washington DC, USA, March 1996. [22] XML Metadata Interchange (XMI). http://www.omg.org/technology/documents/formal/xmi.htm. [23] A. Zisman, G. Spanoudakis, E. P´erez-Mi˜nana, and P. Krause. Tracing Software Requirements Artefacts. In Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP’03), Las Vegas, Nevada, USA, 2003.