logseq/pages/@Senate%3A Policy-Driven Change Management in Model-Based Systems Engineering.md

tags:: #zotero date:: 2017 title:: @Senate: Policy-Driven Change Management in Model-Based Systems Engineering item-type:: journalArticle original-title:: Senate: Policy-Driven Change Management in Model-Based Systems Engineering language:: en library-catalog:: Zotero links:: Local library, Web library

• Abstract
  • Model-Based Systems Engineering uses models for designing and validating complex systems. Different models for large systems are synchronized via transformations, but current Model Management (MoM) approaches lack mechanisms to control or audit changes propagation. Managing such changes is very challenging, especially when the propagated modifications are unauthorized or rejected by downstream teams.

• Attachments

  • PDF {{zotero-imported-file IC97Z8ZT, "2017 - Senate Policy-Driven Change Management in Model-Based Systems Engineering.pdf"}}

• Notes

  • I'm reviewing a research paper and I took the following notes:

    Annotations

    (17/09/2025, 23:00:37)

    • “current Model Management (MoM) approaches lack mechanisms to control or audit changes propagation.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #e56eee

    • “Managing such changes is very challenging, especially when the propagated modifications are unauthorized or rejected by downstream teams.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #e56eee

    • “This paper introduces Senate, a declarative policy framework for controlling changes propagation in Federated MoM” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “FACE-to-AADL transformations and validate it using representative scenarios such as role-based access control.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “MoM context” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “Safety-critical systems such as those in avionics, automotive applications, medical, robotics, and energy infrastructures, are becoming increasingly complex and resource-intensive to develop.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “issues introduced during earlier stages of development are often only identified during V&V, making them costly and time-consuming to resolve.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “a software mismatch between the tool versions used by different development teams caused design data transfer failure across fuselage sections, leading to wiring harnesses that were too short, which contributed to a two year delivery delay and an estimated extra cost of $6.1B 1.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #e56eee

    • “? ]” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #ff6666 Missing reference

    • “Model Management (MoM) techniques support global interactions across multiple models [6] and facilitate tasks such as synchronization, V&V, and system-wide analysis, enabling what is often referred to as ‘modeling in the large’. MPM thus plays a key role in enabling and structuring effective MoM techniques.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “On the systems engineering level, often systems integrators define constraints on the overall system that are dispatched to the domain engineers” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “This is a hurdle in implementation of generalized access control in collaborative modeling, which is desired but currently not well-supported by MoM and collaborative modeling environments [9].” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 1) #5fb236

    • “This paper introduces Senate, a declarative policy framework for controlling change propagation that alleviates this problem and provides the foundation for change management in MoM.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #5fb236

    • “All implementations of IMT are realized as a sequence of operations or edits to a model which can be recognized as deltas and reverted by applying the opposite behaviors at the target. Thus, we can separately capture the operations in the source and target models irrespective of their dissimilarities.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #5fb236

    • “Integration” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #2ea8e5

    • “Unification” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #2ea8e5

    • “Federation” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #2ea8e5

    • “Model integration approaches simplify the consistency management by requiring all the models to be built from the union language.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #5fb236

    • “Such union language can be difficult to design based on the various paradigms and semantics used.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #5fb236

    • “Similarly, changes in the formalism for any of the domains requires changes in the formalism and the tooling for all the models.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #a28ae5

    • “Thus, integration approaches improve global operations at the cost of slow or difficult evolution of the formalism.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #a28ae5

    • “Model unification reduces the drawbacks of integration by only requiring the shared information to be modeled in the pivot” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #e56eee

    • “However, this comes at the complexity of maintaining the bidirectional transformations, the pivot model, and their tooling” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 2) #e56eee

    • “Federated Model Management (FMoM) does not require a union or pivot language, and each language can use its tools, which can be independently developed.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #a28ae5

    • “In this paper we focus on FMoM approaches due to the difficult change propagation. However, our approach can also be applied to the multi-pivot unification approaches as a case of FMoM with the pivot models being considered as ordinary models.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #ffd400 Not clear yet the novelty.1

    • “The FACE metamodel explicitly describes the sub-components of the given software, namely the Portable Components (PCs) and their Platform-Specific Components (PSCs). These components contain their own threads, as well as the data format and connections for inter-component communication” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #5fb236

    • “The mapping relevant to the subset of the language used for this example is shown in Fig. 1” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #5fb236

    • “. The deadlines in the FACE threads can be incompatible with the AADL th” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #5fb236

    • “For timing analysis of an avionics real-time system, the FACE model needs to be converted to an AADL model.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #a28ae5

    • “A software team called FACEDev develops FACE compliant software S. This model is converted into an AADL model M with the communication details added by the AADLDev team, which builds two hardware platforms modeled as A and B that run the software.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #5fb236

    • “Each team is made up of specialists that are allowed to make changes only on their own models.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 3) #5fb236

    • “Incorrect Synchronization Operations.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #2ea8e5

    • “The AADLDev team would like to prevent creation or deletion of systems in their models, unless done by an AADLDev” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #5fb236

    • “Incorrect Thread Deadline in S.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #2ea8e5

    • “Obfuscation and Reviews.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #2ea8e5

    • “Forbidden Patterns.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #2ea8e5

    • “a less constrained formalism such as ecore, where cyclical references are allowed” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #5fb236

    • “Three EObjects, X , Y and Z can create cyclical references such that X references Y , Y references Z and Z references X , forming a cycle. In EMF, the ecore models can be used to generate Java code.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #5fb236

    • “While such constraints could also be specified with a language such as OCL and be part of the validation of the model, instead of waiting for validation, we would like to prevent such patterns from ever being created.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “method to specify what changes are undesirable in order to provide restrictions based on role, element types, specific elements, or patterns of elements.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #ffd400 There are many sync languages and tools. What's the novelty here?

    • “The propagation of an undesired change to a given model can be considered a failure. As such, we need a method that allows management of the change propagation and makes the FMoM framework robust against such failures in synchronizations.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “RQ1 How to specify policies that can specify change propagation control independent of the transformations?” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “RQ2 How to define change propagation that is robust against rejected changes?” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “RQ3 Can change policies be non-intrusive to the models and transformations used?” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “Section” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #ff6666

    • “change policies and the timeline of their evaluation during change propagation.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #e56eee

    • “how the decisions of change policies interact with change propagation, especially in cases where the change propagation fails.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “Domain-Specific Language (DSL) that is used to specify change policies, including the specification of its inputs and evaluation” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “The systems integrators and domain engineers can create policies in Senate to specify which changes can be directly applied to a model, which changes should stop propagating, and which changes are disallowed.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #a28ae5

    • “The specification and evaluation of a policy on a model is discussed in detail in Section 5.3.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #5fb236

    • “Permit Allow the change to propagate through the model.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 4) #ffd400 To see how propagation is performed. I guess the Permit means apply the transformation to the target model.

    • “Halt Apply the delta to the current model but do not propagate further.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “However, in the case shown in Fig. 4 the failing node is inaccessible to the original user and thus requires involvement of the integration team for any and all issues” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “Some errors are simple and can be resolved by FACEDev team at S, such as if elements common to FACE and AADL (e.g. Threads) are modified. In this case, the responsibility to fix the error should be delegated back to the FACEDev team by propagating the failure backwards. Thus, if the change is rejected by a downstream node such as A or B, the default behavior is to consider the change to be rejected by M as well.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “If the propagation fails as shown in Fig. 4 the failure back-propagation is stopped at TMA and the change propagates normally to B. The inconsistency can later be fixed by the integration team and the AADLDev team.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “In other cases, S can be impossible to propagate correctly without external modification to M” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “In order to propagate deltas correctly, an IMT requires that the models are consistent before a change.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “However, if the source is reverted without the target, the IMT does not behave correctly.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “Thus, in order to ensure correct propagation, any reverts must be in the reverse direction of propagation and always lead to an intermediate state shown in Fig. 3.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “fine-grained conditions on the operation, changed element, the role of the user making the change, and any patterns such as cycles being found.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 5) #5fb236

    • “The policies are required to be non-intrusive to the model and transformation, thus, we cannot store the access rights within the model itself.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #a28ae5

    • “change policy” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #2ea8e5

    • “role-related access” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #2ea8e5

    • “Policy DSL” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #2ea8e5

    • “Policies have three inputs: The set of deltas, the set of patterns changed, and the set of markers.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #5fb236

    • “Listing 1: EBNF grammar for the Policy DSL” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #ffd400 I don't think the grammar is useful here. It's better to show the language and describe its peculiar parts by means of examples.

    • “Marker Model” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #2ea8e5

    • “If there are any instances with the action Update in the set cannotUpdate, then the policy is triggered to disallow the change.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #ffd400

    • “Pattern Matching.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #2ea8e5

    • “The PM defines the patterns using VQL, which are then used to identify the changes at the pattern level. pattern parent ( obj : EObject , parentObj : EObject ) { EObject . eContainer ( obj , parentObj ) ; } pattern findCycle ( obj : EObject ) { find parent ∗( obj , obj ) ; / / ∗ is t r a n s i t i v e closure” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #5fb236

    • “Policy Evaluation” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 6) #2ea8e5

    • “Thus, the $input variable is just the set of events that are sourced from this built-in pattern.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “A policy to deny all changes to System Instances except by AADLDev” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #f19837

    • “AADL developers.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #f19837

    • “However, to achieve the global behavior discussed in Section 5.2, the order in which the changes are propagated is important.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “an MoM approach using Senate must construct the Transformation Chain (TC) and provide it to the TC Executor” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “Transformation Chain (TC)” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #a28ae5

    • “If a node does not have any next nodes to be executed due to not existing or a revert or halt, the returned decision is converted to the final result which is a boolean stating success or failure.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “The TC Executor keeps a trace of the execution of MT. When a policy in the TC returns a failure and requires rollback, each previously visited MT in the TC is undone. T” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #ffd400

    • “6 VALIDATION” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #ffd400 *This is a very important section, which needs revision. My main concerns is about the lack of details on the granularity of deltas and consequently the granularity of the managed changes. Changes can occur at different levels including packages, classes, and structural features. It is not clear if for instance in case of only some changes of structural features are not allowed, the whole class changes are not propagated. Moreover, there are many works in the MDE community about change propagations, management of model differences, bidirectional transformations, etc. which are completely neglected and that instead should be considered and potentially considered as baseline to show the strenghts and the limitations of the proposed approach. Such limitations have been also mentioned in the short threats to validity section even though the authors have not discussed how they have mitigated them. 

    overall even though this is an interesting and relevant work, it requires major revision to properly present the strenghts and liitations with respect to the extensive research on collaborative modeling, model diferences, incremental model transformations, and bidireactional transformations, and change propagations of model differences.*

    • “correctness of the revert handling due to failure cases, and by comparing the behavior of the Senate prototype with the control required by the scenarios in Section 3.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #ffd400 Why showing the correctness of the revert handling to validate the whole approach?

    • “For ease of experimentation, the MoM framework is simulated by directly providing Senate the requisite Transformation Chain (TC) as an input.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “However, as Senate only depends on recognizing the delta within the models, we could have used any IMT tool to write the transformation. Similarly, batch transformations can be supported by replacing the incremental pattern matcher with a state-based pattern matcher.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “the Senate policy language interpreter only supports propagation control based on pattern recognition.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “failure propagation and failure handling” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “the reverts in the model must be in the reverse direction of propagation, and always stop at an intermediate state.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 7) #5fb236

    • “table” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 8) #ff6666

    • “we show that the final propagation is independent of the order in which the nodes are evaluated.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 8) #ffd400 This is strange and needs to be further elaborated.

    • “We also show that all the states at which the propagation stops are valid intermediate states in some ordering of the evaluations.” (“Senate: Policy-Driven Change Management in Model-Based Systems Engineering”, 2017, p. 8) #5fb236

    COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant sentences. Please pay attention instead to the notes that are tagged with #ffd400. Those that are tagged with #ff6666 are typos or errors. Could you please draft a review by organizing it as follows:

    SUMMARY: Just a few sentence to summarize the work

    STRENGHTS:

    WEAKNESSES:

    COMMENTS: Organize the notes with respect to the following criteria:

    Novelty

    Rigor

    Relevance (of the contribution)

    Verifiability and Transparency

    Presentation

    And then add a Detailed Comments section to report the notes that contain issues or typos. Can you also formulate three explicit questions by considering the comments above?