Contents

Software Traceability

Approach

Solution

Download and Use ACTS

Software Traceability

Numerous artifacts are created during the software development life cycle and these artifacts are related to each other in complex ways. Software traceability is the ability to capture and use these relationship in order to support software development. Software traceability aids in system comprehension, impact analysis, and system debugging. Software traceability also enables lower maintenance costs as well as better assessment of product quality.

Despite the benefits, software traceability continues to be difficult to achieve in practice. Factors, such as high overhead in establishing and maintaining traceability links, numerous relationships between artifacts, heterogeneous artifacts and tools, make it difficult to achieve software traceability in practice.

Approach

We take the following approach to address the above difficulties (see a short clip). We center the capture of traces to the architecture, we cater to the different stakeholder requirements, and we use a novel set of techniques to automate the capture and maintenance of trace links. Trace links based on the architecture tend to be more stable than requirements-based traceability and more manageable than code-centric traceability. We cater to the different stakeholders by enabling them to capture and maintain links that are useful to them. The stakeholders may also share their tracelinks with each other.

Figure 1

To automatically capture and maintain trace links, we prospectively capture links, use rules to capture link semantics, and use concepts from open hypermedia to support link navigation across heterogeneous tools. Prospective capture of links simply means that links are captured while users create or edit the artifacts, instead of recovering links from existing artifacts. Rules are used to automatically add link semantics (e.g. type of relationship between artifacts). Finally, open hypermedia enables the traceability across different tools, the modeling of multiple endpoints, and the storage of link semantics in the first class link objects. This set of techniques enables users to trace an architecture to Word documents, graphic files, Powerpoint files, etc. (see Figure 1).

Solution

We built our traceability tool support within the ArchStudio development environment integrated within Eclipse. Since ArchStudio enables multi-level architecture modeling, we also enable tracing artifacts to the various levels of the architecture. Figure 2 below shows a section of the ArchStudio architecture with the related links (see Figure 2).

Figure 2

Trace links may be automatically captured prospectively (see video demo), using the record mode, or retrospectively, using the integrated third party tools such as Lucene and Trac Issue Tracking System. The retrospective capture of links allows users to recover links from existing text files, documents, or repositories using a text matching approach. Users may also manually create links by specifying the URL or the file. These commands are invoked through the buttons in the Tracelink View (see Figure 3)

Figure 3

Once the trace links are captured, the related files or resources are displayed in a table in the Tracelink View. Selecting an element in the architecture (i.e. component or connector) displays the related links, or endpoints, in the table. Additional information about the tracelinks are also stored such as type of trace relationship, timestamp, user, description, and mode of capture. Navigating to the endpoints is as easy as selecting them in the table. Figure 4 shows a related model opened within PowerPoint.

 

Figure 4

 

Report

Users may also view the links in a report. Users can specify the report criteria (see Figure 5).

Figure 5

A report is then generated based on the criteria (see Figure 6).

Figure 6

 

Link Visualization

One can also get a real-time project status based on the linked information. Figure 7 shows the ArchStudio architecture, color-coded according to the component status. Components that have no link to source code have a red outline, while components with bugs have a yellow outline.

Figure 7

One can zoom-in and select a component to view the related links. Figure 8 shows the related links of the Archlight component.

Figure 8

Selecting the BugTrac link from the table opens the bugs that have been reported against the Archlight component (see Figure 9).

Figure 9

Here's a demo of the mashup visualization

 


This research is funded by NSF grants including CCF-0917129

Questions? Contact Hazeline