| commit | 9b2ceb19fc6864f792bcb8748abc4c6841ee949c | [log] [tgz] |
|---|---|---|
| author | Jan-Philipp Steghöfer <ec@splashstudio.com> | Tue Feb 02 16:20:48 2021 +0100 |
| committer | Jan-Philipp Steghöfer <ec@splashstudio.com> | Wed May 05 16:17:09 2021 +0200 |
| tree | fed920561500f3e9526230ceb74c395d6c198380 | |
| parent | b2785b594ffea7b988e5241cb927881e33d66568 [diff] |
Trace models now differentiate origin and target Eclipse Capra so far did not provide the ability to create unidirectional links, i.e., links that have a defined origin and target. Instead, all links were implicitly bidirectional. This was enforced by only allowing to access the "items" of a link type, i.e., all artifacts that were connected by a trace links were accessed via one collection. This behaviour was problematic since it a) did not allow to implement directed link, i.e., links with a clearly defined origin and target; and b) did not allow typisation of links that connect artifacts of different types. The latter meant that a common super-class (usually EObject) needed to be used and type correctness of the trace model could not be enforced. With this commit, the TraceMetaModelAdapter interface introduces a distinction of origin and target for trace links. This means that trace links can now connect an arbitrary number of origin artifacts of the same type with an arbitrary number of target artifacts of the same type. If a TIM wants to restrict multiplicities, it needs to do so via its TraceMetaModelAdapter implementation. It is worth noting that this commit changes Capra's behaviour with the default TIM as well: while it used to be bidirectional, it now distinguishes origin and target as well. This is reflected in changes in the tests. In particular the traceability matrices now look different and isThereATraceBetween() is also sensitive to the order in which artifacts are provided (origin first, target second). This change will be followed up by others that clean up the API, provide clearer Javadoc, in particular for methods of TraceMetaModelAdapter, and update the UI to be able to differentiate sources and targets when creating links. Change-Id: I5f2c14ec68a141bda57789c8b0fc6ef22cc9ffb8
Eclipse Capra is a configurable and extendable traceability management tool. Eclipse Capra is a traceability management tool. It allows the creation of trace links between arbitrary artefacts, provides features to edit them and keep them consistent, and visualise the relationships between them. This includes traceability matrices and graph visualisations that are helpful for reporting and change impact analysis.
In essence, Eclipse Capra 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. Built-in capabilities allow linking to Office documents and documents hosted by Google Docs. 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.
Please note that the master branch of Eclipse Capra always contains the latest stable release. All development takes place in the develop branch, following a gitflow model.
To build Eclipse Capra, follow these steps:
releng/org.eclipse.capra.releng.target. Open the correct file and set it as the active target platform by opening it and clicking on “Set as Target Platform” in the upper right corner. Eclipse will now download all dependencies. Note that this will take a while. Check the progress in the lower right corner.If compilation errors occur during the first build, check if any of the dependencies above are missing. Cleaning all binaries also often helps resolve issues.
To start Eclipse Capra, follow these steps:
The Eclipse Capra team maintains a number of wiki page that describe how to install and run Eclipse Capra from source code, how to extend Eclipse Capra with a custom traceability model, how to contribute to Eclipse Capra, and how to prepare a release. You can find these pages here:
Eclipse Capra is licensed under EPL 2.0.