Evolving Trace Links across Versions of a
Software System in Safety-Critical Domain
Mona Rahimi , Jane Cleland-Huang
DePaul University
1
Motivation
 Safety Critical Systems and rigorous Safety
analysis
 Trace Link Quality degrades as system evolves
 Maintaining trace links is arduous, error-prone
and costly
 More towards adoption of agile and the big
freeze problem
 Ongoing analysis of the traceability coverage
 Reuse the existing traceability information as
the software evolves
http://enpundit.com/before-andafter-portraits-effects-of-time
 Constantly retain the safety of the system
2
Assurance Case
 To automatically generate:
change
change
1. Using documented artefacts and trace links
between them to automatically construct
candidate assurance cases .
2. Detect the initial impact point and propagate the
change.
A means to structure the
reasoning that the system
is safe.
3. Automatically generate new trace links after the
change and then use to construct the new
assurance case.
4. Decide if the new argument is still convincing for
the safety of the system or not?
3
Calculus of Change
change
change
 Constant debridement of stale links as the change happens.
 Trace Slice vs. Trace Matrix
 Continually having fresh links all time
Jane Cleland-Huang , Mona Rahimi, Patrick Mader: Achieving
lightweight trustworthy traceability. SIGSOFT FSE 2014: 849-852 4
Trace Link Evolver
 Trace Link Evolver(TLE): A solution to
automatically evolve requirements-to-code
trace links.
 Detect change scenarios using 3 open source
tools(srcML, java-callgraph and Refactoring
Crawler), Information Retrieval techniques and
finally our written scripts in Java.
 Each change scenario corresponds to a set of
trace link evolution heuristics.
Mona Rahimi, William Goss, Jane Cleland-Huang: Evolving
requirements-to-code trace links across versions of a software
system. FSE 2015: under revision
5
Detecting Change Scenarios
 Understand change scenario to evolve trace links accurately
 6 different scenarios for a newly added class
Ci 1
in new version
i 1
 Similar scenarios for deleted class, added/deleted/modified method
6
Change
ChangeScenarios
Scenarios
 Focused only on those refactorings:
o would be likely to trigger changes to trace links
o more familiar to the programmers.
 Focused on detecting these 24 scenarios
Mona Rahimi, William Goss, Jane Cleland-Huang:
Evolving requirements-to-code trace links across
versions of a software system. FSE 2015: under
review
7
Heuristics to Determine Change Scenarios
Scenario 1: New class added new functionality
Rule 10
Rule 40
Scenario 3: New class is the merging result of
two old classes
Rule 7
Rule 15
Rule 23
Rule 29
Rule 46
8
Link Evolution Heuristics
 Scenario 1 is detected:
Create trace links to the newly added
requirements which are similar to it.
 Scenario 3 is detected:
Create trace links to the requirements
already linked to the two old merged classes
and debride/decay the links to the two old
classes.
Mona Rahimi, William Goss, Jane Cleland-Huang:
Evolving requirements-to-code trace links across
versions of a software system. FSE 2015: under
9
revision
Evaluation(Controlled Experiment)
 Datasets: 11 revisions of two java application
Domain Analysis App: 237 LOC
DOTS File Generator: 446 LOC
 Baseline: VSM, LDA or LSI
 Metrics: Recall, Precision and F2
Generated Links with VSM: 0.69, 0.35 and 0.55
Evolved Links with TLE: 0.96, 0.92 and 0.95
Mona Rahimi, William Goss, Jane Cleland-Huang:
Evolving requirements-to-code trace links across
versions of a software system. FSE 2015: under
review
10
Evaluation(Open Source Project)
11
Conclusion and Future Work
Conclusion:
 Ultimate goal is to automatically generate safety cases after change is
introduced.
 To achieve this, we propose a calculus of change to update trace links
continually.
 To start, we implemented TLE to evolve trace links between source code and
requirements after change happens.
 We evaluated TLE through a controlled experiment and also across two
versions of Apache Cassandra.
Future Work:
 Using evolutionary algorithms to detect scenarios of change
 TLE over multiple versions of a software.
 TLE against other programming languages.
12