SEKE 2012 Proceedings - Knowledge Systems Institute

Figure 1.
Figure 1 shows an overview of the process of prospectively
capturing traceability links—numbers denote steps, triangled
steps denote user actions, a nd circled steps denote autom ated
tool support. A user may select which rules to apply prior to
any recording session (Step A). The user initiates a recording
session in the trace tool (1). The trace tool invokes appropriate
tool-specific recorders (2, brown arrows) whenever the user
opens specific artifacts. As the user perform s development
tasks and accesses, generates, or edits artifacts (3), each
recorder captures the user interaction eve nts. Each e vent
captured is associated with the resource path and perha ps a
location within the resource. When the user ends the recording
session of the trace tool (4), the adapters output the ca ptured
events to a common event log (5, green arrows). The trace tool
orders the events sequentiall y. Rules may be autom atically
applied to transform the event log into traceability links (6).
Finally, the new traceability links are added to the linkbase (7).
IV. TOOL SUPPORT
We implemented ACTS within ArchStudio, an
architecture-centric development environment integrated with
Eclipse [10] 1 . We focused on relating artifacts to the structural
representation of the architecture and we de signed our system
to achieve the goals of supporting stakeholder-driven
traceability and prospectively capturing links ac ross
heterogeneous artifacts. Detailed usage scenarios are in [7].
A. Using Open Hypermedia Concepts
A main difficulty with current traceability approac hes is
tracing across heterogeneous artifacts and tools [14]. Previous
efforts to integrate off-the-shelf (OTS ) software development
tools required the framework to adjust to the assumptions of the
OTS tools [25] or required OTS developers to adhere to the
environment's framework [1]. In contrast, our approach
loosely integrates existing independently developed tools into a
traceability framework via open hypermedia techniques such as
adapters and first class traceability links (see [7]).
To support us er-customized link capture, we designed the
tool to have an explicit ex tension point for incorporating
custom adapters. The adapters, which utilize a third party tool's
API, are external to the trace tool and are i ndependent of each
Prospectively capturing traceability links
other. In addition to the concept of rendering adapters that are
used in a hypermedia system [3], we cre ated recording and
maintenance adapters. Recording ada pters capture user
interactions within the context of the tools. Rendering adapters
render the artifacts within th e context of the third-pa rty tool
when a link is navigated. Finally, maintenance adapters detect
if a traced artifact has been deleted, modified, or moved.
Capturing links across heteroge neous artifacts is supported
through tool-specific recorders. The following tools are
supported: Eclipse, Mozilla F irefox, MS Office (Word, Excel,
Powerpoint), and Adobe Acrobat. Currently, only the artifacts
launched within these tools can be prospectively captured;
however, adapters can also be implemented for other tools.
To support queries and upda tes, we use first class n-ary
traceability links. We currently use a xADL file [28] whi ch is
an XML-based architecture descri ption language to store our
linkbase; xADL was extende d with a traceability schem a. A
traceability link consists of a set of two or more endpoints that
share a common relationship.
B. Using Rules
We use rules to analyze a potentially la rge set of user
interaction events and to aut omate the capture of traceability
links. Rules are used to filter noise by ignoring user
interactions based on a criterion (e.g., “ignore files
*ProjectX*”, “ignore Save events”). Rules are also used to
transform the user interactions to traceability links by using a
criterion (e.g., patterns of events or primary trace artifact). To
decouple heuristics from the trace tool, rul es are external to
ACTS. Rules are im plemented as XSL Transformations
(XSLT) on XML, and Xalan-Java acts as our rule engine. A
rule is usually represented by a single XSLT file.
Rules may be applied in the background or interactively. To
apply rules in the background, the user selects the rules prior to
a recording se ssion. The rules are automatically applied after
each recording session. To apply rules interactive ly, ACTS
prompts the user to select a rule after each recording session.
The status of link transformation is displayed and additional
rules may be applied. In both cases, traceability links are added
to the linkbase after the rule application.
1 For info on the tool, see http://faculty.washington.edu/hazeline/acts/
414