It is now possible to define derived attributes in YT. The only thing you need to do is to specify the derivation rule in the form of a query. Together with the above-mentioned support for database transformations, this gives you a powerful support for analyzing the traceability of your project. The following example shows how feed an attribute with the number of test cases that are linked to a stakeholder requirement.
We have improved the display of the YT dashboard – we added scrollbars for those cases where it is zoomed „small”.
When executing YAKINDU Traceability in batch mode it is now possible to set custom parameter values which are not defined in the configuration and set those in the snapshot instead. The parameter --forceConfigParameter was added to the interface.
It is now possible to create reports during a batch run. The report creation is started after all queries are executed. If for some reason the report creation fails, the entire batch run is terminated and the error code ‚2’ will be returned. It is possible to configure the report creation by providing command-line parameters as described here
When using query inferred links, the query language editor will inform the user, whenever a query inferred linktype is referenced to create a query inferred linktype. This prevents unexpected query results and potentially circular dependencies amongst queries.
With YT’s batch mode, it is easy to export the entire graph of traceability data into a relational database schema. To import large graphs of data for any YT configuration, the underlying database schema is of generic structure.
This sometimes makes it a bit difficult to parse the data, for example you need a database join or two. An explicit DB schema is much easier to analyze. So why not let YT convert the data in the generic schema to an explicit schema?
The only thing you need to do is to define the actual mapping.
If you create a YT-Query that has e.g. artifacts as results, the display of the corresponding column was diffent in YT’s result table and in an exported CSV:
In YT, the name of the artifact was shown. In CSV, a String-representation of the artifact was stored. Not, the CSV also contains the name.
(You still can add the
toString
function call to your query if you want to see the String-representation)
When multiple Dataaccess for Modelviewer were activated, Libraries were included as artifacts for all of them, if at least one references subsystems.
Doors supports an option that prevents using the auto declare feature for variables, when DXL scripts are executed. There was an error causing runtime exceptions, if this feature was disabled by the Doors client configuration. This has been fixed!
For very small traceability graphs (i.e. only a small number of artifacts & links), data extraction in batch mode failed in some cases. The underlying reason was that the export was faster than the license check, so YT refused to export the data because of a (supposed) missing license. We have fixed this.