Bidirectional transformations (bx) are used to maintain the consistency of two or more artefacts as they are concurrently updated, typically by diferent people, often using diferent tools. While there has been active research on bx for some time with numerous examples and industrial case studies from research projects, it is still a valid question if bx is absolutely necessary in practice. Indeed, if productivity and simplicity are most important, perhaps processes and tool chains can be chosen to avoid bx as much as possible. In this experience report, we provide an automotive perspective on the need for and application of bx to traceability maintenance. We share our experiences from relevant projects, focusing on challenges and constraints in the problem domain, and discussing solution strategies we have applied and evaluated. Our aim is to provide a concrete characterisation of bx-related solution strategies to traceability maintenance in practice, which we hope serves as motivation and input for bx researchers.
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Qualification Tests
Architectural Design background, is thus a relevant challenge in this context, especially as the connected models co-evolve.
Bidirectional transformations (bx) have been actively researched for some time as a means
of maintaining the consistency of two or more artefacts [
As depicted in Figure 1, our primary focus in most projects has been in the upper-left corner of the V-model often stipulated by automotive process reference standards for (software) systems engineering. In the diagram, rectangles represent models, while the bidirectional black arrows represent traceability links between model elements. The stacked rectangles for requirements and architectural design indicate that the models we are interested in often comprise multiple layers. E.g., stakeholder, system, and component for requirements, and functional, logical, and physical for architectural design models. Qualification tests are expected to be on the same abstraction level as requirements. Relevant traceability links are mostly between requirements and architectural design, as well as between requirements and qualification tests, and are typically required to be bidirectionally navigable. The goal is often to support a holistic system view without committing prematurely to a purely software-based or hardware-based view of the system. In a few projects, however, we have also addressed the problem of connecting the conceptual, modelling world to the final executable code, especially when the latter is not automatically generated. This focus of projects in the last 3-5 years shapes and limits the automotive perspective we can report on, and does not necessarily reflect other parts of the automotive domain.
To simplify the discussion, we focus in the rest of the paper on the traceability links between requirements and architectural design models. Qualification tests can be handled similarly.
Although some requirements can be generated automatically from parts of the architecture in a few cases, the norm in our projects is that both requirements and architectural design models are created and maintained manually. Similarly, most traceability links between requirements and architectural elements can only be created and checked manually, and represent an explicit documentation of a relationship between the elements, e.g., “realised by”. There is typically no chance to define a formal consistency relation from which, e.g., traceability links can be created or checked automatically as correspondences. The need for some form of automation comes more from the task of maintaining traceability links possibly across tool boundaries while the involved models constantly change. According to our experience, the following requirements for productive traceability maintenance are to be adequately addressed by an acceptable solution, irrespective of the applied solution strategy:
R1 Traceability links between requirements and architectural elements can be created, navigated, versioned, and generally used productively in either the requirements management tool or the architectural modelling tool (or sometimes in both). Convincing end users to use an additional tool solely for traceability maintenance is – in our experience – dificult. R2 Traceability links that are clearly broken by changes that were made to one or both of the models are marked but preserved in a way that they can be reviewed and handled manually.
R3 A set of “suspect” traceability links can be determined for a manual review in some configurable manner (e.g., links connected to elements that have changed). This point is often optional as (R2) already requires a considerable amount of manual work. The problem domain can be further characterised by the following constraints and limitations: The underlying development process must first be clarified: In our experience, developing a feasible solution for traceability maintenance always requires a clear development process defining who changes what when and with which tool. In most projects, however, the development process is usually implicit, unclear, and not yet communicated to and accepted by all relevant stakeholders. Some questions that we investigate include: Why are traceability links required and by whom? Who is going to create and maintain these traceability links when using which tool? What parts of which models can be changed by whom in which tool? A complex combination of diferent concerns: A further challenge is that traceability maintenance must be usually combined with the following intertwined concerns: (i) A flexible versioning of all models is required as diferent engineers work concurrently on diferent releases. This afects traceability as links might have to be created to elements from a particular baseline. The problem here is that many modelling tools support versioning in their own unique way, if they do at all. (ii) Variant management is also a concern as multiple, similar systems are often planned and designed together to promote reuse of certain parts of models. This also afects traceability, however, as a compatible strategy for variant management of traceability links must also be established.
projects, the available technology in the solution domain tends to be fixed or at least severely limited by numerous factors including the set of tools already in use at a company, the tools for which the client’s IT is prepared to obtain and support licenses, and of course budgetary constraints. While we sometimes provide consulting regarding the choice of tools, we also often have to cope with the current tools in use.
No compiler or test suite to validate automated decisions: In contrast to working with executable code or simulations, working with models on a high, conceptual level typically means that one cannot rely on a powerful compiler or an extensive test suite to catch most mistakes and inconsistencies. Indeed, while we strive to implement as many basic validation rules as possible, automated decisions made by a tool, e.g., whether a link between a certain requirement and an architectural model element is still valid after applying a change, must be manually reviewed.
pared to working with code and parser-based systems, most requirements management tools and architectural modelling tools provide unique identifiers for all models elements. While this comes with its own set of challenges, unique identifiers generally simplify numerous tasks including determining changes (deltas) and correspondences (corrs) by simply comparing two models.
As the requirement and architectural models are on a relatively high-level of abstraction, scalability is usually not an issue in this context. Indeed, as numerous manual reviews and expert discussions must still be possible, clarity is more important than completeness.
We now discuss the solution domain describing the most common solution strategies we have seen and applied ourselves in projects. We again restrict the following discussion to requirements management (RM) and architectural modelling (AM).
A common solution strategy is to provide an all-in-one tool that supports both RM and AM (and all else that is required) in an integrated manner. Such a tool has a better chance of supporting versioning, variant management, and traceability maintenance in a compatible manner. Traceability maintenance is typically supported by immediately checking all consequences of a change, and if necessary rejecting it or at least prompting for a confirmation from the user. Although this is attractive, it is also problematic. We have seen this one-size-fits-all strategy fail in practice due to missing acceptance from a group of users. Such a tool tends to become quite complex and unwieldy, e.g., for users only or primarily concerned with RM. Such tools often have a primary focus and end up being, e.g., much better for AM than for RM even though both are supported.
In general, this strategy eventually breaks down as new models are added and have to be maintained using separate tools, resulting in an awkward mix of almost everything in one complex tool and still a number of separate tools added ad-hoc to the mix. Nonetheless, many tools on the market currently take this approach such as Enterprise Architect,1 Capella,2 PREEvision,3 and Cameo systems modeller.4 As points R1 – R3 can be fully addressed by such an integrated solution, we believe this can be a viable solution strategy if the tool is crafted or at least substantially tailored for a specific client and project with a stable set of models.
A flexible solution that still addresses R1 adequately, i.e., allows users to perform traceability maintenance in their own tool, is to identify the parts of diferent models that are relevant for traceability, and to keep this “overlap” synchronised using bx as all models co-evolve.
This strategy is depicted in Figure 2 using notation and terminology from the lens framework
for bx (we refer readers new to lenses to, e.g., Johnson et al. [
An RM tool containing requirement models is to be used together with an AM tool containing architectural design models. The decision has been made in this case to enable traceability maintenance only in the AM tool. To support this, a relevant part of the requirement models must be identified, and then propagated to the AM tool where it has to be represented in some manner. Now users of the AM tool have representatives of relevant parts of the requirements models in their own tool and can create and use traceability links. When the requirement models are changed in the RM tool, however, consistency must be reestablished as follows (the steps are indicated in Figure 2 in small black circles) 1. A user of the RM tool makes changes (Δ ) to the requirement model. 2. The synchronisation starts by extracting the relevant parts of the changed requirements model using the function . 3. To determine what was changed, the same overlap is extracted from the current architectural design model in the AM tool using the function . Assuming a consistent starting point, this is expected to be identical to what would produce when applied to the old requirements model (depicted as a greyed out white arrow in the figure). 1https://sparxsystems.com/products/ea/ 2https://www.eclipse.org/capella/ 3https://www.vector.com/de/de/produkte/produkte-a-z/software/preevision/ 4https://www.3ds.com/products-services/catia/products/no-magic/cameo-systems-modeler/
In our experience, modern RM tools such as Codebeamer5 and Jama6 are well-suited for applying this strategy as they (i) provide a relatively complete (REST-)API for flexible data manipulation, and (ii) are flexible enough to allow new types of model elements to be introduced to represent, e.g., architectural elements or test cases.
A final strategy involves using separate tools that support creating traceability links to proxies in other tools. A proxy in this context is a model element that might or might not exist in another tool. To ensure that R1 is adequately addressed the tool must support creating and navigating such external links to proxies in a native manner.
A separate tool is responsible for resolving these proxies in the background, reporting links that have become broken, and providing candidate elements of a certain type to support/simplify link creation. OSLC7 can be used as a standard for connecting the tools as services via REST APIs. Graph databases such as Neo4j8 can be used to check all proxies and resolve traceability links. All modelling tools push/update periodically a part (basically the overlapping in Figure 2) of their models to the graph database, which can then attempt to resolve proxies by connecting these interface elements and reporting on success/failure. We have seen this strategy successfully implemented for modern, domain-specific tools, which could be implemented from scratch. Reusing current tools on the market, however, makes it dificult to address R1, i.e., to ensure productive traceability maintenance for end users in their favourite tool.
In our experience, it is currently dificult to directly (re)use a bx tool in practice. This is mainly due to the efort involved in connecting the bx tool as required to the actual models and concrete tools, especially when a project poses constraints on the choice of software technology. Usually, bx tools that are developed in academia enforce a specific format for persisting models (e.g., Ecore-compliant XML Metadata Interchange (XMI) files), and do not allow for being used as an all-in-one tool (as other tools are much more suitable for modelling purposes) or as a backend for traceability maintenance (due to inappropriate interfaces). Using an existing bx tool for synchronising a common overlap involves substantial additional implementation eforts, as the bx must react to events that are triggered in one of the modelling tools.
It turns out, therefore, that bx foundations are what can be really transferred to industry and used to investigate new application scenarios as well as organise and communicate implemented solutions. As a consequence, bx could be further promoted by presenting established formal foundations in an accessible manner for practitioners in the application area of (model-based) systems engineering.
Concerning formal bx foundations, it would be helpful to clarify the relationship between bx, version management, and variant management. To the best of our knowledge, there exists no 5https://codebeamer.com/cb 6https://www.jamasoftware.com/solutions/requirements-management/ 7https://open-services.net 8https://neo4j.com unified formal treatment of these three concerns together, even though they often have be to handled in combination in practice. There are diferent ways of handling bx (state-based, deltabased, diferent laws), diferent ways to support versioning (branch-based with a dif+merge, locks, online vs. ofline), and diferent approaches to variant management (composition-based vs. annotation-based) – having a formal framework with unifying definitions and laws covering all these concerns would help master the complexity and confusion in practice.
Concerning bx tooling, we suggest inspecting existing modelling tools that are currently being used in practice by a community of practitioners in a respective ecosystem. To increase the chance of actually using bx-related implementations, the bx community has to provide tool-specific connectors that can be directly used and configured as required.
Finally, we believe it is particularly unrealistic to make too many assumptions about the data stored in tools. Expecting the complete data to be exported to a certain format, manipulated by a bx, and then imported back to the modelling tool is typically unwieldy if not infeasible in practice. We suggest instead developing bx tooling that leaves all data in the respective modelling tools, communicating with the tools via their respective APIs as required.
In this paper, we shared an automotive perspective on traceability maintenance with a primary focus on the upper-left corner of the V-model.
We reported on the main requirements, challenges and constraints of this problem domain.
In our experience, the pivotal requirement is typically that end users want to create and make use of traceability links directly in their modelling tool of choice without too much of a distinction between these links and other “normal” links in the modelling tool.
This perhaps explains some of the solution strategies we discussed, especially the overly ambitious attempt to build an all-in-one tool despite repeated failure in the past.
A viable, pragmatic solution strategy employs bx to propagate parts of models in one tool to other tools, enabling traceability maintenance in the tools at the price of having to keep these parts synchronised.
Finally, we suggested future directions of bx research which would help promote a transfer of bx to industry, especially for model-based systems engineering.