Files
logseq/pages/ICSE2026-paper1356.md

35 lines
4.3 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: Senate: Policy-Driven Change Management in Model Based Systems Engineering (MBSE)
date-start:: [[17-09-2025]] - 23:02
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Senate: Policy-Driven Change Management in Model-Based Systems Engineering]]
parent::
todoist:: https://app.todoist.com/app/task/1356-senate-policy-driven-change-management-in-model-based-systems-engineering-m-6cVHmvQ33PC6XXV8
- ### [[Comments]]
- #.tabular
- ### Paper summary
- This paper presents Senate, a domain-specific language to specify policies guiding the propagation of model changes in contexts characterized by different and potentially heterogenous models, which are managed by different teams in a collaborative and distributed modeling scenarios. The approach has been validated by discussing its application in a setting characterized by FACE and AADL specifications.
- ### Strengths
- + Relevant problem in Model Based Software Engineering
- + Interesting DSL for specifying governance constraints in collaborative modeling settings
- ### Weaknesses
- - The novelty of the proposed DSL with respect to existing approaches in change propagation, bidirectional transformations, and model synchronization is not clearly presented.
- - Prior work in the MDE community on collaborative modeling, model differencing, incremental synchronization, and consistency management is not considered and only superficially mentioned in the limitation and related work sections of the paper.
- The evaluation is underdeveloped: critical details are missing about the granularity of changes (e.g., are structural features handled separately from classes?) and how different levels of model abstraction are affected by policy enforcement.
- ### Detailed comments for authors
- Novelty: The concept of policy-driven change management in FMoM is potentially novel, but the authors do not discuss Senate with respect to existing synchronization languages or bidirectional transformation frameworks. The DSL for specifying change propagation constraints could be interesting, but the paper does not highlight what makes it unique compared to other policy or transformation languages. Thus, the paper require a major revision to make a clear contribution statement, explicitly clarifying what is new in Senate vs. existing IMT tools, pattern matching systems, or role-based modeling constraints.
- Rigor: The policy semantics are underexplained, especially regarding the granularity of collaborative changes: e.g., what happens if a subset of a classs structural features violates a policy? Does the whole class delta get discarded? Senate DSL should be compared with existing approaches managing the collaborative editing of modeling artifacts.
- Relevance: The work is highly relevant to collaborative and federated modeling, particularly in safety-critical domains. However, the relevance of the proposed approach is compromised by the lack of discussion and comparison of Senate with prior work. Without showing how Senate improves over or complements existing tools, its difficult to assess practical impact.
- Verifiability & transparency: The paper refers to [Anonymized Repository - Anonymous GitHub](https://anonymous.4open.science/r/senate-icse-EDED) which contains the EMF based implementation of the approach. However, no details are given on the performed experiments, successfull cases, encountered limitations, etc.
- Presentation: Overall, the paper is well structured, even though it requires major rewriting to improve the readability of the paper by giving concrete examples and experiments by comparing the proposed approach with existing techniques. It is not clear what are the strenghts and the limitations of Senate with respect to existing approaches manageing collaborative modeling.
- Questions:
- Q1: How does Senate improve over existing synchronization languages and transformation frameworks for managing change propagation across heterogeneous models?
- Q2: What is the level of granularity supported by the Senate framework when changes are partially valid (e.g., some attributes allowed, some forbidden within the same class)? How are composite changes handled?