Traceability allows creating and using links between system and software development artifacts. For instance, this allows connecting the origin of a requirement with its specification and development throughout the software lifecycle. These connections are called trace links and link a source artifact to a target artifact. Artifacts can be of different types, such as a requirement, a model element, a line of code, or a test case. Traceability management is the planning, organization, and coordination of all activities related to traceability, including the creation, maintenance, and use of trace links.
Many domains have strict requirements on software traceability through existing quality and safety standards. In the automotive domain, e.g., ISO 26262 and ASPICE both require companies to show that requirements are covered by test cases. The standard technique to ensure this is to create a form of trace link between the requirement and the respective test cases. A common practice in the industry is to use manually updated spread sheets or other forms of one-off, manual work to satisfy the standards. A traceability management tool embedded in the development environment and accessible throughout the entire development lifecycle would greatly alleviate the effort to create the traceability links and would enable other advantages such as change impact analysis, a better documentation of dependencies, and more transparency of design decisions.
Capra is one of the results of the ITEA-funded project "Amalthea4public". Making it available as an individual Eclipse project is an attempt to make the tool visible independently of the research project and establish a community around it that will ensure its development after the project ends. While there are close ties to Eclipse APP4MC, the other outcome of Amalthea4public, Capra is independent of Eclipse APP4MC and useful in areas that are not directly addressed by Eclipse APP4MC.
Capra is a dedicated traceability management tool that allows the creation, management, visualisation, and analysis of trace links within Eclipse. Trace links can be created between arbitrary artefacts, including all EMF model elements, all types of source code files supported by the Eclipse Platform through specialised development tools, tickets and bugs managed by Eclipse Mylyn, and all other artefacts for which an appropriate wrapper is provided. Capra is highly configurable and allows users to create their own traceability meta-model.
Compared to other similar projects such as Eclipse ReqCycle which may have similar features, Capra is not a modelling tool or a tool for requirements management. All functionality is focused on providing traceability capabilities, i.e., the ability to create and visualize links between artefacts modelled in different domain-specific languages. This allows the architecture to be highly modular and the tool to be extremely customisable as described below.
Capra provides traceability features. In essence, it allows the creation of trace links between arbitrary artefacts, as long as an adapter for these artefacts is available. This way, a trace link can be created between EMF model elements, source code files supported by the Eclipse Platform (e.g., Java, C, Python), or tasks from an issue tracking system supported by Eclipse Mylyn. External artefacts for which the Eclipse Platform does not offer built-in support can also be linked if a fitting adapter is provided. Through its EMF adapter, Capra currently supports elements from UML, SysML, AADL, EAST-ADL, or AUTOSAR models created in, e.g., Eclipse Papyrus, Eclipse EATOP, or ARTOP. The same adapter allows tracing from and to requirements modelled in ProR. Furthermore, adapters for test case executions managed by a continuous integration server like Hudson or Jenkins can be traced to.
Once these trace links are established, Capra offers features to manage them. If a model element that is linked to is moved, e.g., Capra will notify the user and allow changing the link accordingly. The same support is given for model elements that are deleted or renamed. Quick fixes are available to fix most isses in a semi-automatic fashion.
Capra also offers a visualisation of the trace links that allows developers to traverse the relationships established through the links and understand how the different artefacts are connected. This is helpful when assessing the impact a change has (e.g., which design artefacts need to be adapted when a requirement has changed?) or when trying to understand how the design artefacts in a complex development project are connected. In addition, Capra can display traceability matrices, as requested by standards like ISO 26262.
The tool is highly extensible. The meta-model used for the traceability links can easily be adapted to a specific end-user's needs. Capra's modular architecture allows exchanging the persistence, the visualisation, and the management modules easily. New adapters for additional artefacts can easily be added without re-compilation. This allows end-users to customise almost every aspect of the tool if needed. At the same time, we provide sensible defaults that will allow the majority of users to use Capra out of the box without extensive configuration.
Some of the code in the current version of Capra has been developed by students at the University of Gothenburg. We have their written consent to include that code in an open source distribution.
The Eclipse Platform and Eclipse-based projects are in heavy use in the automotive and embedded systems industry. These industries have regulatory requirements (such as ISO 26262 or ASPICE) that make it necessary to establish traceability, e.g., between requirements and test cases. Capra leverages existing Eclipse technology to provide an integrated traceability framework that allows to seamlessly trace between EMF models regardless of their origin (e.g., UML or SysML models created in Eclipse Papyrus, AADL models created in Osate, EAST-ADL models created in Eclipse EATOP) as well as other artefacts either directly supported by existing Eclipse tools or supported through specialised adapters. In addition, it is of interest for existing Eclipse projects such as Eclipse APP4MC.
Features that will most likely not be part of the initial contribution are an adapter for artefacts that are accessible through OSLC and a versioning solution. The OSLC adapter will allow interfacing with tools such as IBM Rational Doors without the need to export the information from such tools and import it in Eclipse Platform thus avoiding inconsistencies in the data. The versioning solution will allow storing the traceability information in a version control system (either a multi-purpose VCS like Git or a specialised one like EMF Store or CDO) and enable a host of collaborative features.
We base the features we plan to develop on our research work with industrial partners, mainly from the automotive industry. It is important to note that Capra will actively seek to increase its committer base outside of academia by directly engaging with potential end-users. Our presentation at EclipseCon France was a first step in this direction.
Since the initial contribution already constitutes a working prototype, we expect to make development builds available as soon as the project is accepted. After that, we expect a new stable version every two to three months.
- University of Gothenburg
- University of Paderborn
- rt-labs
- Robert Bosch GmbH
- Behr-Hella Thermocontrol GmbH (BHTC)
The initial code will contain the core of the tool which provides four extensions through extension points. The four extension points are as follows:
- Traceability Metamodel extension: For adding a custom traceability metamodel, which defines the link types.
- Persistance Handler extension: For adding a persistance extension, which defines where the traceability model should be stored.
- Artifact Handler extension: For adding artfact handlers, which define which artefacts can be used to create traceability links.
- Priority Handler extension: For deciding which artefact handler to be used when there is more than one available.
The core also defines interfaces that can be used to access traceability data for visualization purposes.
Along with the core of the tool, the initial codebase also contains default extensions for each of the three extension points: one for the traceability metamodel; one for the persistance metamodel; and six for the artefact handler that allow linking to EMF models, Java code, C/C++ code, Files (e.g., .doc or .pdf), Eclipse Mylyn tasks and tests from Hudson build servers. Visualisation of traceability links is also provided through two views, one based on PlantUML and one based on Eclipse Zest.
Dependencies to other Eclipse Plugins
The core of Capra is only dependent on Xcore for the definition of EMF models such as the traceability metamodel and the artefact wrapper model. The rest of the dependencies are determined by whether the end user will use all the extensions provided. The extensions offered by the initial code base are dependent on the following plugins which are all avilable under the Eclipse Public Licence:
- PlantUML: Only used to visualise trace links.
- EclipseZest
- Eclipse Mylyn
- Eclipse C/C++ Development Tools
- Eclipse Java Development Tools
- Log in to post comments