Research Assistant

P. Nguyen


Richard N. Taylor


CCF 0917129, National Science Foundation


Capturing Custom Links across Heterogeneous Artifacts, Asuncion, H., Taylor, R.N., Software and Systems Traceability, Springer-Verlag. To appear.

Hazeline U. Asuncion, Arthur U. Asuncion, and Richard N. Taylor. Software Traceability with Topic Modeling . In 32nd International Conference on Software Engineering (ICSE), May 2010, Acceptance Rate: 13.7%.

Hazeline Asuncion and Richard N. Taylor. Capturing Custom Link Semantics among Heterogeneous Artifacts and Tools. In 5th Int’l Workshop on Traceability in Emerging Forms of Software Engineering. Vancouver, British Columbia, May 2009.

Hazeline Asuncion. Towards Practical Software Traceability. In ICSE Companion ’08: Companion of the 30th International Conference on Software Engineering. Leipzig, Germany, May 2008, Acceptance Rate: 25%.

Hazeline Asuncion, Frederic Francois, Richard N. Taylor. An End-To-End Industrial Software Traceability Tool. In Proc. of the Sixth Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE). Dubrovnik, Croatia, September 2007, Acceptance Rate: 16.7%.

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.


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.

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).


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).

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).

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.


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

A report is then generated based on the criteria (see 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.

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

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

Here’s a demo of the mashup visualization.


Comments are closed