Case ID
Source
Primary
Secondary
Domain
Views
Artefacts
Quotes
Summary
HLI19-1
JongelingDocSymp2019
C1
—
industrial MBSE (SysML/Simulink)
SysML block diagram // Simulink model
expected subsystem/block correspondence
"We could […] detect if the Simulink model is missing a subsystem that was expected in the SysML block diagram, indicating a probable inconsistency between the two models."
A lower-level model omits a subsystem required by the higher-level architectural view. // Cause: missing correspondence under a refinement relation. // As a result, likely incompleteness or incorrect realisation of the higher-level design.
RCM05-1
Wehrheim2005
C1
C2
model-driven development // formal multiview refinement
static class model A // corresponding refined class model C
attribute buffer // operation choose // class-level data semantics
"In class A attribute buffer is of type set […] and choose chooses just any element of this set, whereas in C buffer is of type […] sequence and choose always chooses the first element in the sequence." // "Is every behaviour of C a behaviour of A?"
A lower-level class changes a buffer from an unordered set to an injective sequence, thereby changing how choose behaves. // Cause: a data-type transformation changes the semantics of state and operations across refinement levels. // As a result, the refined model may preserve representation but alter observable behaviour unless a valid refinement relation is established.
RCM05-5
Wehrheim2005
C1
C2
model-driven development // formal multiview refinement
class model A // extended class model C
methods get/put in A // get/put/full in C
"The classes model buffers with methods put and get, and class C in addition with a method full querying the contents of the buffer." // "Can a user of A use C as if it were A?"
A refined class adds a new operation full, raising a substitutivity (“Can a user of A use C as if it were A?”) question for clients expecting only the abstract interface. // Cause: model extension adds new operations at the lower level, so refinement becomes a subtype-compatibility problem rather than simple behaviour preservation. // As a result, the extended model is only consistent if new operations do not interfere with the behaviour and state assumptions inherited from the abstract class.
RCM05-2
Wehrheim2005
C1
C3
model-driven development // formal multiview refinement
higher-level protocol state machine A // lower-level protocol state machine C
open/close/read/write protocol states and transitions
"The state machine of A belongs to a higher-level model, it is nondeterministic and also models the case where the file to be opened is non-existent. […] In C the nondeterminism has been resolved, possibly by ensuring applicability of open on existing files only." // "Is every behaviour of C a behaviour of A?"
A lower-level protocol removes the higher-level nondeterministic case in which open may target a non-existent file. // Cause: protocol refinement tightens behavioural assumptions relative to the abstract view. // As a result, behavioural possibilities differ across abstraction levels; refinement must be checked to ensure the lower-level behaviour is still permitted by the higher-level one.
RCM05-3
Wehrheim2005
C1
C3
model-driven development // formal multiview refinement
static class model A // refined class model C
operation send in A // operations prepare and transmit in C
"While class A contains a single operation send, class C uses two operations for one send, the first one being responsible for preparing the message for sending […] and the second one for actual transmission." // "Has every behaviour of C a corresponding behaviour in A?"
A single abstract send operation is split into prepare and transmit in the refined class model. // Cause: an operation is decomposed into a sequence of lower-level steps, introducing the risk of intermediate states and new execution paths. // As a result, the refined model can admit behaviours not present in the abstract one unless continuation and proper-starting conditions are enforced.
RCM05-4
Wehrheim2005
C1
C3
model-driven development // formal multiview refinement
dynamic protocol model A // refined protocol model C
send transition in A // prepare/transmit transitions in C
"Sending is split into preparation and transmission. […] After a trace of C in which prepare has occured but transmit not, transmit may not be refused. There are no traces in C in which transmit occurs without a prior prepare." // "Has every behaviour of C a corresponding behaviour in A?"
A send transition is split into prepare and transmit in the protocol state machine, with extra ordering constraints needed to avoid spurious behaviour. // Cause: behavioural refinement introduces intermediate protocol states that must still correspond to one abstract transition. // As a result, without the extra constraints, the refined protocol can exhibit traces that the abstract protocol never allowed.
RCM05-6
Wehrheim2005
C1
C3
model-driven development // formal multiview refinement
behaviour model A // extended behaviour model C
original put/get protocol // added parallel full transition
"A state machine is extended with a parallel component independently executing the method full. […] Execution of full in C may not interfere with the “old” behaviour modelled in A." // "Can a user of A use C as if it were A?"
A dynamic model is extended with a parallel full action that must remain non-interfering with the existing put/get behaviour. // Cause: behavioural extension introduces new transitions running alongside the original protocol. // As a result, consistency depends on substitutivity: the extended model must preserve the old behaviour under interleaving with the new action.
DHI19-3
Feldmann2019
C1
C5
automated production systems // project + discipline models
project documentation // discipline-specific model
documentation item // refined common/model element // refinement link
"Inconsistency for refinement between project documentation and discipline-specific model."
A documentation artefact does not properly refine or correspond to the intended discipline-specific model element. // Cause: refinement relation is ill-formed or points to a mismatched artefact. // As a result, breakdown of abstraction linkage between management/documentation and engineering views.
FER94-2
NuseibehKF1994
C1
C5
requirements engineering // viewpoint-based specification
tabular collection view // agent hierarchy view
source/destination entry in tabular collection diagram // named agent in hierarchy
"Every Source or Destination in a tabular collection diagram has a corresponding agent with the same name in the agent hierarchy" // "Two Viewpoints may be partially overlapping, with a partial specification in one related to a partial specification in the other." // "For example, CORE requires that a source agent in a tabular collection diagram is a named agent in the agent hierarchy."
A source or destination named in a tabular collection diagram has no matching named agent in the hierarchy, or the names diverge. // Cause: cross-view correspondence constraint between partial requirements views is violated. // As a result, the same domain participant is represented inconsistently across views, weakening integration between decomposition and flow-oriented descriptions.
DSS22-1
JongelingFCCC2022
C1
C6
industrial model-code consistency
system model // code repositories/folders
system components // Git repositories // folders with public_include
"According to domain experts, the top-level code components should be Git repositories, and hence each system component in the model […] should be matched to a Git repository." // "Soon, exceptions to this rule appeared, because in some cases multiple system components were included in a single repository."
The intended one-to-one mapping between model components and code containers fails in practice. // Cause: real code organisation does not obey the assumed architectural correspondence rule. // As a result, initial consistency rule is invalid or too rigid; matching heuristic and rule must be revised.
IMM98-2
GrundyHM1998
C1
C7
software development environments // UML-like OO design
OO design view // textual code view(s)
method call connection in design model // affected textual code views
"Adding a method call connection in an OO design view cannot be automatically added to the appropriate textual code view(s) affected by this change, so the code views become inconsistent."
A design-level call relation is added, but the implementation view is not updated accordingly. // Cause: refinement/correspondence relation exists, but automatic propagation is unavailable because the mapping to implementation details is underdetermined. // As a result, implementation no longer reflects the design; manual repair is required.
CCM19-1
JongelingSATToSE2019
C1
C7
industrial MBSE (SysML/Simulink, automotive ABS example)
high-level SysML diagrams // lower-level Simulink model
SysML internal block/activity/parametric diagrams // Simulink refinement model
"In our running example, this indeed happens, the system model is changed, requiring some changes in the Simulink model." // "In the running example, not updating the Simulink model of the ABS might result in its incorrect implementation."
A change in the high-level system model is not reflected in the refining Simulink model. // Cause: evolution of the abstract model without co-evolution of the lower-level model. // As a result, incorrect implementation of the affected function; need to tolerate temporarily but eventually repair.
ARC22-3
JongelingCCC2022
C1
C7
industrial continuous model-based development
high-level system/architecture models // implementation
system models // implementation artefacts // feedback links
"It is accepted by engineers that the models are not fully consistent with the eventual implementation, so the initial impact of an inconsistency is small. Nevertheless, it is required that the eventual implementation conforms to the requirements."
Engineers temporarily accept mismatch between high-level models and implementation, but lack of feedback makes the mismatch persist. // Cause: asynchronous development and missing feedback loop between abstraction levels. // As a result, implementation may drift from the intended design and engineers lose model-based overview.
DHI19-2
Feldmann2019
C2
C1
automated production systems // electrics models
inter- and intra-model electrical interface descriptions
connectors // electric interfaces // bus interfaces
"Connector does not point from input to output interface or vice versa" // "Connector does not point from bus interface to compatible bus interface"
A connector links interfaces in the wrong direction or between incompatible interface kinds. // Cause: interface compatibility and direction constraints are violated. // As a result, invalid integration relation between connected elements.
DHI19-4
Feldmann2019
C2
C1
automated production systems // SysML-Simulink alignment
top-level Simulink model // SysML/UML property model
Simulink Constant // SysML/UML Property // equivalence link
"Inconsistency for equivalence between top-level MATLAB/Simulink Constant and UML Property" ("…and SysML Property" inside the figure)
Two elements explicitly marked equivalent carry different values across models. // Cause: value disagreement between corresponding elements under an equivalence relation. // As a result, equivalent artefacts cease to agree semantically, requiring repair or tolerance.
IMM98-3
GrundyHM1998
C2
C1
software development environments // UML-like OO design
multiple design and implementation views
method calls // argument lists // class methods
"Inconsistency detection is needed after one view is edited in order to detect: […] semantic inconsistencies in specifications (e.g., a type mismatch between method calls or a nonexistent method is called); […]."
Two related artefacts agree enough to connect, but disagree on call signature or method existence. // Cause: semantic/interface constraints between linked elements are violated. // As a result, incorrect or impossible interaction between components/classes; manual correction required.
CCM19-2
JongelingSATToSE2019
C2
C3
industrial MBSE (SysML/Simulink, automotive ABS example)
system model // Simulink model
shared parameter/value for total car mass
"If the system model and Simulink model assume a different total mass of the car, this inconsistency could result in an incorrect ABS."
Corresponding models use conflicting values for the same physical quantity. // Cause: shared parameter value diverges across views. // As a result, behaviour of the implemented function may be incorrect despite local plausibility of each model.
BCM23-1
KrauterKRLS2023
C3
C1
behavioural multi-modelling // traffic management
UML state machine traffic-light model // BPMN T-Junction controller model
traffic light states A/B/C // global safety property over combined models
"For the T-Junction, unsafe traffic occurs if traffic light A is green or amber and traffic light B is green or amber simultaneously. In addition, the same state combinations are forbidden for traffic lights B and C." // "Unsafe traffic occurs only in these situations since green and amber mean that cars are allowed to pass,
while red (red-amber) means cars are not (not yet, respectively) allowed to pass."
Two behavioural views jointly admit a globally unsafe combination of light states. // Cause: global property over interacting behavioural models is violated even though each local model may be plausible on its own. // As a result, unsafe system behaviour; traffic participants may be allowed to pass simultaneously on conflicting directions.
BCM23-2
KrauterKRLS2023
C3
C2
behavioural multi-modelling // traffic management
BPMN bus controller model // UML/BPMN traffic-light/T-Junction behaviour
Pass Junction activity // corresponding traffic-light states
"We want to check that they [busses] cannot pass when their traffic light is red or red-amber. Concretely, this means the Pass Junction activity should not execute while the corresponding traffic light is red or red-amber."
The bus behavioural model allows progress that is inconsistent with the traffic-light state in the coupled controller model. // Cause: interaction semantics between models are insufficiently constrained or incorrectly coordinated. // As a result, behavioural safety violation during execution.
BCM23-4
KrauterKRLS2023
C3
C6
behavioural multi-modelling // traffic management
interacting behavioural models in a configured multi-model
traffic-light instances // T-Junction controller // buses // global properties
"We face the problem that the models are not independent." // "If we were to run the models independently in parallel, the properties would be violated."
Locally sensible models become globally inconsistent when composed without the required coordination semantics. // Cause: behavioural dependence among views is ignored during composition/execution. // As a result, violations of global behavioural properties that span models.
FER94-1
NuseibehKF1994
C4
C1
requirements engineering // viewpoint-based specification
agent hierarchy view // tabular collection view(s)
agent in hierarchy // corresponding TC ViewPoint instance
"For each agent in the agent hierarchy there must be one ViewPoint instantiated from a TC template"
An agent exists in the higher-level decomposition, but no corresponding tabular-collection ViewPoint is created for it. // Cause: a required successor specification view is missing, so the decomposition is not elaborated into the next required requirements view. // As a result, the requirements description is incomplete across views; downstream checks and refinements cannot be carried out for that agent.
DHI19-5
Feldmann2019
C4
C2
automated production systems // planning + Simulink
planning property model // top-level Simulink display model
Planning Property // Simulink Display // satisfies link
"Inconsistency for satisfaction between top-level MATLAB/Simulink Display and Planning Property"
A displayed/implemented value violates the property it is supposed to satisfy, either by being unequal or out of range. // Cause: satisfaction relation exists, but checked property bounds or expected value are violated. // As a result, supposedly satisfied planning/property constraint is not actually met.
FER94-3
NuseibehKF1994
C4
C2
requirements engineering // viewpoint-based specification
tabular collection views for different agents
output of one agent // Input of another agent
"The Output produced by one agent in a tabular collection diagram must be consumed as an Input in the tabular collection diagram [by] another agent"
An output declared by one agent is not consumed as an input by any other related agent view. // Cause: inter-view coverage/completeness rule on information flow is violated. // As a result, the requirements model contains an unfulfilled or dangling flow of information between agents.
ABB09-1
AbborsTL2009
C4
C6
model-based testing in telecommunications
requirements model (SysML) // UML system models // QML/Qtronic test specifications // test reports
requirement elements and links // traced UML elements // propagated QML requirement tags // generated tests // failed-test back-traces
"Ultimately, since requirements are traced to model elements, it facilitates the identification of which functionalities of SUT are not in sync with the model, and hence with the requirements." // "Traceability of requirements can help in depicting missing tests, i.e. when critical requirements are not traced to any tests."
Some critical requirements may end up uncovered because they are not traced through the requirements-model-specification-test chain to any generated test. // Cause: trace links must be propagated across several modelling and testing steps; the paper notes that requirements change over the lifecycle, trace upkeep becomes tedious, and only requirements attached to state-machine transitions are currently propagated to Qtronic. // As a result, there are missing tests and incomplete requirement coverage; failed tests can be back-traced to linked model elements; omissions and requirement misinterpretations surface early in modelling.
FER94-4
NuseibehKF1994
C4
C6
requirements engineering // viewpoint-based specification
Z schema ViewPoint // associated textual description ViewPoint
formal schema // companion textual description
"Two Viewpoints may be non-overlapping, but there is some existential relationship in which the existence of one depends in some way on the existence of the other." // "For example, the Z method requires that for each Z schema (Viewpoint), there is an associated textual description (Viewpoint)."
A formal schema exists without its required associated textual description view. // Cause: an existential inter-view dependency is not satisfied; one required companion requirements view is missing. // As a result, the specification is incomplete and loses the paired descriptive context required by the method.
MME21-1
StunkelKRL2021
C4
C6
general multi-model management
requirements model // code model // test model
mandatory requirement // realising method // associated test case
"Every method, which realizes a requirement must have an associated test case and for every mandatory requirement there has to be at least one test case."
A new mandatory requirement is introduced without adding or linking a corresponding test. // Cause: a consistency rule spanning requirements, implementation, and tests is broken by partial co-evolution. // As a result, the multi-model set becomes invalid under the stated coverage/satisfaction rule.
ARC22-2
JongelingCCC2022
C4
C7
industrial continuous model-based development
design models // tests // implementation models
test cases/scripts/models // models under test
"When tests are consistent with the design models, it is meant that not only the test cases pass, but also that the test cases appropriately cover the models, i.e., test the correct things." // "Inconsistency caused by, e.g., a drop in test coverage is much more subtle to detect than test case failure."
Tests still run, but no longer cover the intended model elements or behaviours after evolution. // Cause: co-evolution of tests lags behind changes in design/implementation models. // As a result, passing tests may become misleading or meaningless as evidence for the model.
DHI19-1
Feldmann2019
C5
—
automated production systems // heterogeneous engineering models
inter-model vocabulary alignment
properties across linked models
"Naming inconsistency for elements (common vocabulary)" // "Naming inconsistency for properties (common vocabulary)" // "Naming inconsistency for elements (mechatronics vocabulary)" // "Naming inconsistency for properties (mechatronics vocabulary)"
Linked properties across models use inconsistent names. // Cause: equivalent elements lack aligned terminology. // As a result, correspondence establishment and interpretation become harder; repair action is naming-related.
DSS22-3
JongelingFCCC2022
C5
C1
industrial model-code consistency
system model // code
matched element names under architectural guidelines
"This puts a requirement on following a specific naming convention. Not everybody does this."
Model-code correspondence depends on naming conventions that are not uniformly followed. // Cause: informal naming discipline is relied upon for correspondence but is not socially enforced consistently. // As a result, reduced precision/usefulness of consistency checks and disagreement over enforcement strictness.
IMM98-1
GrundyHM1998
C5
C7
software development environments // UML-like OO design
OOA/D design view // other design diagrams // code // documentation // analysis diagrams
class interface // related diagrams // derived code // documentation artefacts
"Inconsistency detection is needed after one view is edited in order to detect: structural inconsistencies between views (e.g., class attributes added in one view aren’t in another); […]." // "Renaming a class in an OO design view means all other analysis, design, implementation and documentation views become inconsistent unless the class name is changed in these views."
A class is renamed in one design view, but the corresponding name is not propagated to related views and artefacts. // Cause: local edit to a shared conceptual element is not propagated across redundant or corresponding representations. // As a result, cross-view disagreement; developers may overlook the inconsistency; downstream artefacts no longer refer to the same concept consistently.
ATD11-1
BuchgeherWeinreich2011
C6
—
Architecture decisions and implementation traceability
Requirements/design decisions // architecture // implementation
Traceability relationships among decision, architecture, and code artefacts
"Manual discovery and recovery of tracing information by studying documents, architecture documentation and implementation is time-intensive, costly, and may miss important information not found in the analyzed artifacts."
Architectural-decision traces are incomplete or missing when recovered manually from artefacts after the fact. // Cause: manual, retrospective trace recovery is error-prone and incomplete. // As a result, important relations can be missed, weakening architecture-related activities and reasoning.
BCM23-3
KrauterKRLS2023
C6
C3
behavioural multi-modelling // traffic management
traffic-light state machine // T-Junction model // bus models
behavioural relations/interactions between models
"The traffic light model is currently not related to the T-Junction and bus models while the T-Junction is supposed to control the traffic lights, for example, when it switches between the two traffic phases."
The intended control relation exists conceptually, but is absent from the multi-model as an explicit relation. // Cause: missing inter-model linkage/interaction specification. // As a result, global behavioural requirements cannot be checked reliably until the relationship model is introduced.
MBT12-1
GeorgeFHKBA2012
C6
C4
model-based testing
requirements model // design model // test model
relationships among requirements, design, tests, and executable tests
"Relationships between the different models will help to navigate from one model to another, and trace back to the respective requirements and the design model when the test fails."
When a test fails, missing cross-model relationships prevent reliable backward navigation to the responsible requirement/design elements. // Cause: gaps between requirements, design, and test models are not bridged by explicit relations. // As a result, failed tests are harder to diagnose; inconsistencies in requirements elicitation and tests are harder to localise.
ITC16-1
DemuthKEM2016
C6
C7
automation engineering // electrical models and controller software
electrical model // corresponding software controller
engineer-defined links and consistency rules across tools
"We discuss experiences […] in maintaining the consistency between electrical models and the corresponding software controller when both are subject to continuous change."
Electrical and controller views co-evolve, but their cross-tool relations drift unless maintained through explicit links and rules. // Cause: concurrent cross-domain evolution in heterogeneous engineering tools. // As a result, change impact becomes erroneous unless consistency checking notifies engineers.
OAT18-1
JavedMZ2018
C6
C7
software traceability evolution
versions of a software project // traceability links between artefacts
existing trace links across versions/releases
"After the painstaking process of traceability construction, a substantial evolution of a software system, such as a new major version leads to the decay of traceability links."
Trace links that were valid in one project version become stale after major-version evolution. // Cause: substantial system evolution without synchronised update of stored trace links. // As a result, trace set loses validity and requires maintenance/evolution support.
ATM12-1
MaderG2012
C6
C7
requirements traceability // UML-based development
requirements // analysis models // design models
traceability relations between lifecycle artefacts
"To ensure that the anticipated benefits […] can be realized, it is necessary to have an up-to-date set of traceability relations between the established artifacts. This goal requires the creation of traceability relations during the initial development process." // "Furthermore, the goal also requires the maintenance of traceability relations over time as the software system evolves in order to prevent their decay." // "Maintaining traceability means to prevent its decay while related artifacts evolve."
Trace links that were once valid become stale as related artefacts evolve. // Cause: artefact evolution without commensurate maintenance of trace links. // As a result, dependencies become unreliable and development tasks lose the expected benefits of traceability.
CAE08-1
MurtaHW2008
C6
C7
architecture-to-implementation traceability
software architecture // implementation code
versions of architectural elements // versions of source code configuration items // trace links
"A traditional obstacle in the use of multiple representations is the need to maintain traceability among the representations in the face of evolution. […] Specifically, the task is to relate versions of architectural elements to versions of source code configuration items, and to update those relations as new versions of the architecture and source code are produced."
Architecture-to-code links must survive concurrent version evolution on both sides. // Cause: trace links are tied to evolving versions of both architecture and code artefacts. // As a result, without continuous evolution of traces, architecture and implementation lose synchronisation.
ARC22-1
JongelingCCC2022
C7
C1
industrial continuous model-based development
software design models // generated+manually modified implementation code
generated code // models intended to document implementation
"To customize this code for different operational environments, the generated code, rather than the model, is modified, leading to inconsistency between the code and the model." // "This inconsistency mainly impacts the maintainability of the code, since the models can no longer be used as accurate documentation of the implementation."
Code is customised after generation, but the originating model is left behind. // Cause: manual post-generation evolution of code without reverse synchronisation to the model. // As a result, model ceases to be a trustworthy description of the implementation; maintainability suffers.
IMM98-4
GrundyHM1998
C7
C5
collaborative software development
alternative versions of shared views
class method across parallel versions
"Inconsistency detection is needed after one view is edited in order to detect: […] inconsistencies between specifications at different levels of abstraction (e.g., system requirements and design conflict); and inconsistencies between the work of multiple developers (e.g., when any inconsistency is caused by different developers working concurrently)." // "While alternate versions of a view are being modified independently, inconsistencies between these views may easily result. For example, a class method modified by one developer may be deleted or renamed by another."
Parallel edits on different versions produce conflicting states for the same method. // Cause: concurrent evolution without immediate reconciliation. // As a result, merge/conflict situation across versions; synchronisation and repair become necessary.
DSS22-2
JongelingFCCC2022
C7
C6
industrial model-code consistency
system model // implementation code
model elements and corresponding code elements
"Now, things are improved in the code and then forgotten about. Then six months later, you see that the model is not at all updated. So some reminder is needed to show that the model is not correct anymore."
Code evolves, but the system model remains stale for long periods. // Cause: long lag between code updates and model maintenance. // As a result, stale model, loss of trust, and need for reminders/checks to surface skew.