ddiruscio/logseq
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[logseq-plugin-git:commit] 2025-12-27T19:07:25.270Z

Browse Source
This commit is contained in:
Davide Di Ruscio
2025-12-27 20:08:10 +01:00
parent 1c76754387
commit a578313353
624 changed files with 11511 additions and 4361 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pages/@A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems.md
+133
View File
@@ -0,0 +1,133 @@
tags:: [[#zotero]]
date:: 2017
title:: @A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems
item-type:: [[journalArticle]]
original-title:: A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/RRJ2HC5J), [Web library](https://www.zotero.org/users/1039502/items/RRJ2HC5J)
- [[Abstract]]
- Smart Human-centric Ecosystems (SHEs), such as smart cities, emerge from the interaction among independently-owned systems and humans, who are active components and not mere users of the ecosystems. While smart cities and more generally SHEs are becoming common in our society, their verification remains a critical challenge, as traditional testing methods cannot adequately capture the emergent, adaptive and sometime conflicting behavior arising from human, digital and physical components.
- ### Attachments
- [PDF](zotero://select/library/items/382QWRQF) {{zotero-imported-file 382QWRQF, "2017 - A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotations
(18/09/2025, 00:29:35)
- “interaction among independently-owned systems and humans, who are active components and not mere users of the ecosystems” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “their verification remains a critical challenge, as traditional testing methods cannot adequately capture the emergent, adaptive and sometime conflicting behavior arising from human, digital and physical components.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #a28ae5
- “Multi-Agent Architectural approach for digital twins of SHEs” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “Multi-Agent Architecture Digital Twin of San Francisco,” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “virtual systems-of-systems” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #2ea8e5
- “ultra-large-scale systems” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #2ea8e5
- “continuous evolution, and the contradicting requirements of the systems in the ecosystem” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “autonomy of the systems that dynamically enter and exit the SHE” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “implicit interactions among human and systems that adapt to evolving human behaviors and scenarios that emerge in the cyber-physical environment” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “intrinsic contradictions that can lead to unavoidable SHE failures even when all systems behave according to their specifications” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “defined a new concept of health, that captures the intuitive concept of quality of SHEs in the absence of precise specifications of the SHE as a whole.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “challenge of verifying such ecosystems remains largely underexplored.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #a28ae5
- “Failures may still occur, not because of faults within any single component, but due to unforeseen interactions among components that respond and adapt to human behavior in unpredictable ways” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #a28ae5
- “For example, in a smart city, even if traffic lights, ride-sharing platforms, and public transportation systems are individually tested, their combined response to a spontaneous large-scale event (for instance, an unpredictably large flash mob or an extremely urgent stadium evacuation) may produce emergent congestion patterns that no single component anticipates.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #a28ae5
- “new verification strategies that support continuous observation, behavioral simulation, adaptive analysis, and predictive reasoning. In this context, the Digital Twin (DT) paradigm offers the foundation technology for modeling and reasoning about the state and evolution of human-centric ecosystems, enabling real-time monitoring, exploratory simulation, and predictive diagnostics [27, 42].” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #a28ae5
- “DTs with centralized architectures badly adapt to SHEs [7, 33]. The definition of a suitable architectural approach of DTs for SHE is still a largely open problem” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 1) #5fb236
- “Current DTs architectures model humans as static parameters or passive data providers, rather than as autonomous, adaptive and goal-oriented elements within the SHEs, and largely miss the sociotechnical interactions that are fundamental in SHEs” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #a28ae5
- “state-of-the-art approaches lack the expressiveness needed to model the complexity of SHEs, ultimately limiting their utility for effective monitoring, analysis and testing” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #e56eee
- “Multi-agent Architectural approach for Digital Twins” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #5fb236
- “MAD, a Multi-agent Architectural approach for Digital Twins that addresses the decentralized, dynamic and heterogeneous nature of SHEs.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #5fb236
- “To the best of our knowledge, this is the first concrete architectural solution in which agents form the structural foundation of the DT itself.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #5fb236
- “Our approach integrates both human and cyber agents, capable of perceiving their physical counterpart, reasoning about their goals, and acting within a context-aware environment.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #ffd400
*Ok, not clear yet what's the novelty with respect to autonomous systems and CPS in general.*
- “responsiveness, fidelity, adaptability and robustness of MADSF .” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #5fb236
- “decentralized, dynamic, and autonomous nature” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #5fb236
- “The Data Exchange, Digital Model, Service, and Data Management composite components comprise the DT, while the Smart Human-centric Ecosystem (SHE composite component in the figure) is the actual ecosystem augmented with the DT.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #5fb236
- “SHE Smart Human-Centric Ecosystem The cyber-physical systems, the humans and the environment in which they operate are the main parts of the Smart Humancentric Ecosystem to be digitally twinned. A SHE can be formally defined as: SHE = ⟨C, H, E⟩ (1) where (i) C is the set of Cyber-Physical systems, including digital platforms and sensorized infrastructures (for instance, traffic monitoring systems, transport control units, utility platforms of a smart city), (ii) H is the set of Humans, whose behaviors and decisions influence and are influenced by the SHE (for instance, citizens, taxi drivers, and tourists in a smart city), and (iii) E is the Environment, that is, the infrastructural context comprising physical spaces and networks where digital and human entities interact (for instance, roads, pa” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 2) #5fb236
- “Belief-Desire-Intention (BDI) paradigm [47], where belief represents the agent’s knowledge or perception of the current world state, desire denotes the goals of the agent, and intention defines the plans and strategies to achieve its goals.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 3) #e56eee
- “MADSF , Multi-agent Architecture Digital Twin of San Francisco, a prototype implementation of a DT that we develop to validate the responsiveness, fidelity, adaptability, and robustness of MAD,” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 4) #ffd400
*This sentence is a bit strange. IN Figure 1 you present an architecture, which is an abstract representation of a system consisting of different components. How can you validate properties that refer to the way the architectures is implemented, deployed, etc.? How can you assess the responsiveness of an architecture? What can you say about the robusteness of fidelity of an architecture? Please, clarify and make this concrete!*
- “since it does not devise any feedback generation toward the physical SHE” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 4) #ffd400
*So it means, we are talking about a simplification of Fig 1, because we have monodirectional connections, i.e., from physical to cyber worlds.*
- “Responsiveness” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 6) #ffd400
*But this depends on the implemention and not on the architecture per se. Isn't it?*
- “RQ2. Fidelity: Does MAD accurately model the behavior of SHE? Rationale: Accurately reflecting the behavior of the SHE is critical for reliable analysis, detection and prediction. Metrics: We assess MAD fidelity by computing both the accuracy and GEH7 values for vehicular traffic flow, passenger pick-ups and drop-offs of MADSF , and compare them with SUMO baseline. RQ3. Adaptability: Does MAD adapt to the evolving nature of SHE? Rationale: As the SHE continuously evolves, maintaining adaptive alignment is essential to keep the DT effective. Metrics: We evaluate the adaptability of MAD in terms of the impact of a new agent entering MADSF both statically on the structure of the DS and dynamically on the responsiveness and fidelity of the DS. RQ4. Robustness: Does MAD sustain increasing or abnormal workload conditions? Rationale: Given the evolving nature of SHE, MAD should remain stable even during unexpected workload peaks to ensure continuous effectiveness and resilience. Metrics: We evaluate the robustness of MAD by measuring how responsiveness and fidelity degrade under anomalously high workload peaks.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 6) #ffd400
*I'm confused. Are we discussing the implementation of the architecture? The research questions are about a concrete implemenation!?!?!*
- “RQ1 Findings: MAD keeps aligned with SHE over time, significantly reducing total execution time compared to real-world constraints. It maintains consistent simulation speed across increasingly long intervals, staying in synchronization with the SHE.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 8) #ffd400
*How these findings are related to the architecture shown in Fig 1 and/or to the implementation you have done of it? What are the general aspects that can be applied to other implementations/applications?*
- “RQ2 Findings: MAD accurately replicates the SHE, with over 99% fidelity for traffic flow, passenger pick-ups and drop-offs, and GEH values are consistently under 5.0 threshold.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 8) #ffd400
*Again, this depends on the way you have implemented the prototype. The same comment applies also to the other RQ findings.*
- “RQ3 Findings: MAD adapts to the evolutions of the agents in the SHE with minimal impact on fidelity and responsiveness.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 8) #ffd400
- “RQ4 Findings: MAD demonstrates strong robustness under high workload and disruptive scenarios. Responsiveness of MAD remains consistently below real-time threshold, and fidelity remains high across all conditions.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 9) #ffd400
- “There is a huge literature on Digital Twins in various domains [35]. Here, we overview the most relevant studies on Digital Twins for SHE and multi-agent approaches for DTs. Digital Twins for SHE Some recent conceptual studies explore the requirements for DTs in complex and evolving socio-technical environments [7, 13, 17, 33]. Michael et al. [33] emphasize the need of the DT to co-evolve with the SHE to be relevant. David et al. [13] propose a taxonomy that identifies some critical capabilities for DT evolution, such as, runtime model reconciliation and system reconfiguration. Bonetti et al. [7] focus on the socio-technical nature of SHEs and advocate for model-driven engineering to better integrate human and technological dimensions. Several studies discuss the benefits of DTs for ecosystems in domain-specific applications: healthcare DTs for predictive diagnostics [14], smart grids DTs for fault detection [39], smart buildings DTs for energy optimization [23], smart cities DTs for urban mobility, transportation management, and planning [46]. The current approaches for DTs propose centralized architectures that miss the distinctive characteristics of SHEs as ecosystems that emerge from the sometimes implicit interactions between humans and independently-owned systems. Wang et al. [44] propose a mobility DT that integrates humans, infrastructure, and vehicles, however they model humans merely as traffic data points. Dembski et al. [16] incorporate citizens feedback into participatory urban planning, however they consider humans as external participants. Xu et al. [49] and Irfan et al. [26] design traffic DTs driven by centralized analytics without modeling human interactions. Biagiola et al. [6] focus on testing autonomous vehicles, and exclude human-system dynamics. Michael et al. [33] explicitly address the co-evolution of human and technological systems, yet their work remains at a conceptual level and falls short of delivering practical engineering solutions. Architectural proposals that claim to support ecosystem-wide DTs [8, 29, 30] focus on isolated or domain-specific subsystems, often under centralized control. As a result, current works on DTs for SHEs fall short of supporting new behaviors, conflicting goals, and continuous co-evolution between humans, cyber-systems and environment. Multi-Agent Approaches for DTs Recent research increasingly studies multi-agent modeling as a promising strategy for addressing the engineering challenges of DTs for SHEs. However, the work presented so far remains narrowly scoped and does not adequately address the architectural concerns of SHEs. Current agent-based DT solutions are typically applied to single-domain and well-structured systems. Pretel et al.’s MAS4DT framework [37] provides a rigorous mapping between DTs properties and multi-agent constructs, but it is designed for centralized cyber-physical systems with uniform stakeholders. Hussein and Challenger’s MADTwin [25] approach synchronizes physical and digital agents within a smart warehouse context. While it confirms the operational feasibility of agent-based DT, it does not support the modeling of diverse agent behaviors. Pretel et al.’s systematic review [36] confirms the limitations of both agent-based systems that act as consumers of DT services and agent-based systems in which agents constitute the structural foundation of the DT. We address the limitations of current approaches by proposing MAD, a multi-agent DT architecture that explicitly models both cyber and human entities as agents. MAD agents perceive, reason, and act according to their beliefs and goals, and operate within a shared digital environment that enables decentralized coordination and supports the co-evolution of autonomous components.” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 10) #ffd400
*The novelty of your approach is not clear with respecto to what already existing. Moreover, since you are also talking about autonomous systems, it is important to refer peculiar architectural patterns, like the MAPE-K that are completely nelected in the paper.*
- “We validate MAD with MADSF , a level-2 DT of ride-hailing ecosystems that we instantiate on the city of San Francisco” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 10) #ffd400
*When you say "validate" you have actually implemented a DT by following the proposed architecture, and the findings are related to that specific implementations. It is not clear what are the take-away messages or general insights that can be applied to any other potential implementations of the proposed architecture.*
- “We provide a comprehensive usage guide, data and code to run MADSF in our replication package, along with the experiments’ results.11” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 10) #5fb236
- “Replication package available at https://anonymous.4open.science/r/sfdigitalshadow” (“A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems”, 2017, p. 10) #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?
pages/@A kNN-Based Recommender System for Test Case Reuse in Agile Software Development.md
+345
View File
@@ -0,0 +1,345 @@
tags:: [[#zotero]]
date:: 2026
title:: @A kNN-Based Recommender System for Test Case Reuse in Agile Software Development
item-type:: [[journalArticle]]
original-title:: A kNN-Based Recommender System for Test Case Reuse in Agile Software Development
language:: en
authors:: [[Anonymous Author]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/NUL9BMH7), [Web library](https://www.zotero.org/users/1039502/items/NUL9BMH7)
- [[Abstract]]
- Context: Agile testing poses unique challenges, including short development cycles, evolving requirements, and the need to rapidly execute and update test suites. Efficient reuse of test cases can help address these demands, but remains difficult due to fragmented documentation and evolving repositories. Objective: This study proposes a Recommender System (RecSys) to support test case reuse in agile development contexts by leveraging historical user stories and a domain-specific taxonomy. Method: We implemented a K-Nearest Neighbors (KNN)-based RecSys to retrieve user stories similar to a given target and recommend their associated test cases. The algorithm’s transparent logic enables traceable and interpretable recommendations. The evaluation followed a multi-method design: first, an offline experiment with 217 user stories and 1077 test cases from two companies identified the best configuration based on recall, precision, and F-measure. Then, this configuration was applied in an online case study involving two agile projects to assess real-world impact on test reuse and suite completeness. Results: The best offline configuration achieved a recall of 67.5%, precision of 37.8%, and F-measure of 51.0%. In the online phase, 65.09% of the developed test cases aligned with existing assets, and the RecSyS increased the projects’ test suites by 38.78%. Conclusion: These results indicate that our taxonomy-based RecSyS effectively supports test case reuse in agile settings, achieving solid results both offline and in practice. Its transparent logic, minimal infrastructure needs, and alignment with agile workflows make it a lightweight and practical alternative to more complex reuse solutions.
- ### Attachments
- [PDF](zotero://select/library/items/SM9JG55B) {{zotero-imported-file SM9JG55B, "Author - 2026 - A kNN-Based Recommender System for Test Case Reuse in Agile Software Development.pdf"}}
- ### Notes
- # Annotations
(18/09/2025, 01:58:43)
- “Agile testing poses unique challenges, including short development cycles, evolving requirements, and the need to rapidly execute and update test suites.” (Author, 2026, p. 1) #5fb236
* *
- “Efficient reuse of test cases can help address these demands, but remains difficult due to fragmented documentation and evolving repositories” (Author, 2026, p. 1) #e56eee
* *
- “This study proposes a Recommender System (RecSys) to support test case reuse in agile development contexts by leveraging historical user stories and a domain-specific taxonomy” (Author, 2026, p. 1) #e56eee
* *
- “We implemented a K-Nearest Neighbors (KNN)-based RecSys to retrieve user stories similar to a given target and recommend their associated test cases.” (Author, 2026, p. 1) #5fb236
* *
- “first, an offline experiment with 217 user stories and 1077 test cases from two companies identified the best configuration based on recall, precision, and F-measure.” (Author, 2026, p. 1) #5fb236
* *
- “this configuration was applied in an online case study involving two agile projects to assess real-world impact on test reuse and suite completeness.” (Author, 2026, p. 1) #5fb236
* *
- “These results indicate that our taxonomy-based RecSyS effectively supports test case reuse in agile settings, achieving solid results both offline and in practice.” (Author, 2026, p. 1) #5fb236
* *
- “developers must navigate increasingly complex information spaces—often spending disproportionate time seeking relevant artifacts at the expense of value-generating work” (Author, 2026, p. 1) #5fb236
* *
- “Recommender Systems (RecSys) for software engineering have emerged as tools that assist developers with various tasks—ranging from code reuse to effective bug reporting—and aim to reduce cognitive load and improve productivity [” (Author, 2026, p. 1) #5fb236
* *
- “reusing validated test cases offers a promising way to improve test coverage and efficiency without increasing effort” (Author, 2026, p. 1) #5fb236
* *
- “When organizations accumulate substantial testing knowledge across features or projects, test reuse can reduce redundancy and accelerate software testing.” (Author, 2026, p. 1) #a28ae5
* *
- “Industrial test repositories often suffer from inconsistent documentation, lack of structure, and frequent changes” (Author, 2026, p. 1) #a28ae5
* *
- “However, these techniques often require complex infrastructure—semantic models, embeddings, or deep learning pipelines, and typically operate at the code level or support regression testing, rather than proactive reuse at the user story level in agile workflows.” (Author, 2026, p. 1) #5fb236
* *
- “we developed a RecSys tailored to agile environments, particularly for early sprint planning and user story development.” (Author, 2026, p. 1) #5fb236
* *
- “The system leverages two underutilized resources: structured taxonomies and historical user stories.” (Author, 2026, p. 1) #5fb236
* *
- “referred to as offline validation in RecSys” (Author, 2026, p. 2) #5fb236
* *
- “First, we used the data from 13 industrial projects from one organization, encompassing 217 user stories and 1077 distinct test cases, to identify the most effective RecSys configuration.” (Author, 2026, p. 2) #5fb236
* *
- “in-situ case study in two projects of the same organization to assess the RecSys’s practical impact on agile test case development” (Author, 2026, p. 2) #5fb236
* *
- “test cases linked to semantically similar user stories in agile development.” (Author, 2026, p. 2) #e56eee
* *
- “textual similarity between requirements implies similarity in downstream artifacts (e.g., code and tests).” (Author, 2026, p. 2) #ffd400
*This is a crucial assumption that can give place to some threats to validity. It's ok if it is mentioned in that section. *
- “Abbas et al. [2] provide empirical support for this assumption. Their study evaluated six NLP models—ranging from lexical to deep learning-based approaches—and found a moderately positive correlation between the similarity of requirements and the similarity of their associated software components” (Author, 2026, p. 2) #a28ae5
*That's important. *
- “that semantically similar user stories are likely to be associated with reusable test cases.” (Author, 2026, p. 2) #e56eee
* *
- “This assumption is further supported by broader work in requirements traceability and retrieval [24, 55], which shows that requirements labeled with semantic metadata—such as purpose, stakeholder, or behavior—can be more effectively retrieved. Collectively, these studies justify our design choice to use structured user story similarity as a proxy for identifying reusable test cases.” (Author, 2026, p. 2) #5fb236
* *
- “Web Information Systems (WIS)” (Author, 2026, p. 2) #5fb236
* *
- “Module, Operation” (Author, 2026, p. 2) #5fb236
* *
- “. Each user story can be labeled with one or more such pairs, enabling multi-label classification and more expressive comparisons across stories.” (Author, 2026, p. 2) #5fb236
* *
- “Any structured labeling scheme that enables meaningful comparison across requirements, especially with respect to the type of feature involved, can support our approach. This flexibility allows adaptation to other domains or evolving taxonomies.” (Author, 2026, p. 2) #5fb236
* *
- “These solutions require mature projects with rich defect histories and focus on prioritization rather than early-stage reuse” (Author, 2026, p. 3) #e56eee
* *
- “LLMs represent a more recent shift from reuse to generation.” (Author, 2026, p. 3) #e56eee
* *
- “Empirical evaluations show that models like GPT-4 and Gemini can generate high-coverage unit tests given source code and examples” (Author, 2026, p. 3) #5fb236
* *
- “However, these black-box approaches raise reproducibility and traceability concerns and do not capitalize on validated, existing test assets within an organization.” (Author, 2026, p. 3) #e56eee
* *
- “We propose a RecSys that classifies User Stories using a validated taxonomy and applies a transparent similarity metric to retrieve reusable test cases, before coding begins.” (Author, 2026, p. 3) #5fb236
* *
- “The RecSys receives as input a target requirement and produces a list of potential test cases to be reused by testers through the data analysis from previously executed projects or ones under execution.” (Author, 2026, p. 3) #5fb236
* *
- “we assumed that test cases are requirements-driven and that, if the requirements are similar, the test cases are also similar, following the findings of Abbas et al. [2].” (Author, 2026, p. 3) #5fb236
* *
- “In particular, we employed the WIS taxonomy proposed by Dilorenzo et al. [15], detailed in Section 2.1. For instance, if we have the set of user stories given by U = {U S1, U S2, · · · , U Sk }, where k is the total number of user stories, and that each U Sk ∈ U are of the type (Authentication, First login), we can infer that they are all similar, even if they have different descriptions.” (Author, 2026, p. 3) #ffd400
*This is a strong assumption. Similar user stories have similar tests is strong for me. Even minor variations of code implementing similar user stories can make tests different. It is interesting to see, what's the usage of the recommended tests. Are they used as starting point or as reference implementation to look at while developing the actual test cases? *
- “Acceptance Criteria (AC)” (Author, 2026, p. 3) #e56eee
* *
- “Let f be a utility function that measures the usefulness of a test case t to a user story u, i.e., f : U × T −→ R,” (Author, 2026, p. 3) #e56eee
* *
- “Recommender: responsible for analyzing characteristics vectors, generated by the data transformer, calculating the similarity between target User Story and retrieved User Stories, and recommending test cases developed for the most similar User Stories ranked by their relevance.” (Author, 2026, p. 3) #5fb236
* *
- “uses the collaborative filtering based on user attributes [23], and performs the recommendation of test cases from the nearest neighbors, to the target User Story.” (Author, 2026, p. 4) #ffd400
* *
- “K Nearest Neighbors (KNN) algorithm” (Author, 2026, p. 4) #5fb236
* *
- “We validated the proposed Recommender System using a multimethod design that combined a retrospective experiment using historical project data (offline validation) and a pilot in situ deployment in industry projects (online validation). This strategy allowed us to examine both the internal performance of the algorithm under controlled conditions and its practical usefulness in real-world agile teams.” (Author, 2026, p. 5) #5fb236
*This is important and well motivated. *
- “After identifying the best-performing configuration, we proceeded to the online phase, where we deployed the RecSys in two ongoing software projects at an industrial partner.” (Author, 2026, p. 5) #5fb236
* *
- “We did not include a comparative evaluation with existing test case recommenders such as those proposed by Bera et al.[9] or Ge and Liu[20], as these approaches rely on fundamentally different infrastructures, including structured requirement modeling, collaborative filtering, and knowledge graphs. Our method depends on a domain-specific taxonomy and requires semantic labeling of user stories, making direct comparisons non-trivial and potentially misleading. Furthermore, no benchmark dataset exists that would support a controlled comparison under equivalent conditions. Instead, we focused on assessing the internal effectiveness of our approach through multiple configurations and evaluating its external utility through industrial deployment.” (Author, 2026, p. 5) #ffd400
*Ok even though this is a potential bias that needs to be discussed. *
- “4.1.1 Training Dataset Definition” (Author, 2026, p. 5) #2ea8e5
* *
- “The lack of RecSys users (User Stories) and items (test cases) data problem is called User Cold-Start and Item Cold-Start, respectivel” (Author, 2026, p. 5) #5fb236
* *
- “we collected User Stories data, AC, and test cases from project databases of two software development companies that execute projects with Scrum” (Author, 2026, p. 5) #5fb236
* *
- “4.1.2 Experiment Design.” (Author, 2026, p. 5) #2ea8e5
* *
- “support Scrum teams in reusing test cases and enhancing the projects’ test suites.” (Author, 2026, p. 6) #5fb236
* *
- “RQ” (Author, 2026, p. 6) #ff6666
*RQ_on *
- “RQon1: To what extent does the test cases recommender increase the test suite completeness for agile projects?” (Author, 2026, p. 6) #ffd400
*In contrast to the situation when no support is used? What's the baseline? *
- “RQon2: To what extent does the test cases recommender enable the test cases reuse for agile projects?” (Author, 2026, p. 6) #ffd400
* *
- “RQon1, we wanted to identify whether the test suite resulted from the recommendations and test cases developed by the project testers are more complete than the original test suite,” (Author, 2026, p. 6) #5fb236
* *
- “RQon2, our goal was to identify if the RecSys provides testers with test cases that they would develop, that is, if it anticipates test cases that would be developed and, thus, allow the tester to reuse them.” (Author, 2026, p. 6) #5fb236
* *
- “two projects under development from one organization” (Author, 2026, p. 6) #ffd400
*Can you say something more on the selected projects and on the organization? (business domain, kinds of projects, etc) *
- “hen, we compared the recommended test cases with the ones created by the project’s testers. After RecSys execution, we discussed the results with the project’s testers and classified the test cases as follows:” (Author, 2026, p. 6) #ffd400
*This was a qualitative comparison, isn't it? *
- “Accepted” (Author, 2026, p. 6) #ffd400
*Acepted how? I'm not sure it can be used as it is recommended. I guess some refinements/changes were required, isn't it? *
- “a higher number of neighbors, whereas the recall value does not present a significant change.” (Author, 2026, p. 7) #5fb236
* *
- “he configuration Euclidean distance, K = 3, heuristic = yes outperformed all 59 alternatives (p < 0.05, Nemenyi post-hoc). It achieved 67.5 % recall, 37.8 % precision, and an F2 score of 0.510. This setting is therefore carried forward to the online deployment.” (Author, 2026, p. 7) #5fb236
* *
- “Additionally, we analyzed the relevance of the accepted test cases, based on the testers’ perception, to identify the tool’s efficiency. Thus, Figure 5 shows the relevance percentages.” (Author, 2026, p. 8) #5fb236
* *
- “Figure 5: Accepted test cases relevance.” (Author, 2026, p. 8) #ffd400
*This is not very good, isn't it? It seems that among the accepted tests, those with low relevance was 47.5% and only 25.4% was considered to be highly relevant... *
- “It is worth noting that the percentage of test cases reused is not directly related to the percentage of effort reduction for the development of these reused test cases” (Author, 2026, p. 8) #5fb236
* *
- “Hence, two-thirds of manually authored tests could have been reused with minor adaptation effort.” (Author, 2026, p. 8) #5fb236
* *
- “Impact on test reuse and suite completeness. Across 41 User Stories, the RecSys recommended 334 test cases. Of these, 132 matched tests already written by the testers (i.e., reused), and 79 were accepted as new, valuable additions—resulting in a 38.8% increase in the test suite.2 Altogether, approximately 63% of the recommended test cases were considered useful, showing that the system can meaningfully support reuse and enrich coverage with minimal overhead.” (Author, 2026, p. 9) #5fb236
* *
- “Limitations and failure cases. Despite its benefits, the RecSys was not without limitations. The most common reason for rejection (86% of rejected cases) was incompatibility with implicit or project-specific business rules not captured by the taxonomy. This highlights an important improvement opportunity: augmenting user stories with additional semantic tags or rule-level metadata could help filter out false positives and improve recommendation relevance.” (Author, 2026, p. 9) #5fb236
* *
- “Applicability and generalization. Although the evaluation was conducted in the context of Web Information Systems, the approach depends primarily on the availability of a domain-specific taxonomy. Substituting this taxonomy for others—tailored to different application domains—requires minimal adaptation effort. Our findings support the broader claim that lightweight, taxonomy-guided kNN-based recommenders can effectively promote early-stage test reuse in agile development, without requiring complex infrastructure or large-scale data.” (Author, 2026, p. 9) #5fb236
* *
- “7 THREATS TO VALIDITY This section discusses the potential threats to the validity of our study, structured according to the categories proposed by Wohlin et al. [53]. Conclusion Validity. Although the offline dataset contains 217 user stories and 1 077 test cases, some taxonomy categories (e.g., Authentication) are under-represented. When a category appears fewer than K times in a fold, the RecSys cannot identify the required neighbors. We mitigated this by discarding such folds and reporting the effective sample size, but the reduced counts lower statistical power for those categories. Further, we compared 60 algorithm configurations, increasing the risk of Type-I error. We therefore applied the Friedman test followed by a post-hoc Nemenyi procedure and interpreted results at α = 0.05. Nonetheless, borderline-significant differences should be interpreted with caution. Finally, data Normality was rejected by Shapiro–Wilk, justifying non-parametric analysis, but other assumptions (e.g., independence of folds) remain. Cross-validation folds can be correlated if neighboring user stories share many test cases; future work could use nested cross-validation to reduce this risk. Internal Validity.User stories were manually mapped to taxonomy categories by the first author and later double-checked by two co-authors. Disagreements (6 %) were resolved by discussion. Nevertheless, latent bias may persist. A kappa statistic was not calculated; future work will involve independent raters and report inter-rater reliability. Additionally, during the online study, the Scrum team adopted a new test-management plug-in that automatically duplicates certain test cases. We controlled for this by excluding auto-generated duplicates from reuse counts, yet residual confounding is possible. Finally, testers may become more proficient over successive sprints, independently improving reuse. Because the pilot lasted only seven sprints (41 stories) and no time–series analysis was performed, maturation effects cannot be fully ruled out. Construct Validity. We relied on precision, recall, and F-measure (β = 2) for offline evaluation, assuming they correlate with tester utility. However, these metrics do not account for the effort required to inspect false positives or adapt reused tests. Complementary measures such as Mean Reciprocal Rank or time-to-acceptance could provide a richer picture. Further, we evaluated only kNN with six distance functions for viability reasons. Other families of RecSys (e.g., matrix factorization, BERT/LLM embeddings) were not explored. This limits construct coverage; future replications should vary the underlying model. Finally, similarity is computed on binary vectors derived from our taxonomy. If two stories are semantically similar but fall into different categories, similarity is underestimated. Conversely, stories in the same category but semantically dissimilar may inflate similarity. Introducing textual embeddings or hierarchical weights could alleviate this threat. External Validity. Training data came from two Brazilian software vendors; the online pilot ran in one of them. Both organizations develop information systems for web/mobile platforms. Results may differ in safety-critical domains (e.g., avionics) or where test documentation is richer/poorer. Further, uur dataset size (1 077 tests) is modest compared with repositories maintained by large enterprises. kNN’s computational cost is O (nK); additional engineering (e.g., ANN indexing) may be required for million-scale test suites. Additionally, the approach presumes (i) user stories conform to the chosen taxonomy, (ii) each story links to at least K = 3 test cases in the historical repository, and (iii) similar wording or semantics persist across projects. Organizations lacking these conditions may observe lower recall or face a cold-start problem. Finally, both pilot teams already emphasized test automation and collective ownership of test artifacts. In cultures where testers and developers work in silos, the willingness to reuse peer artifacts might differ.” (Author, 2026, p. 10) #ffd400
*Overall, I liked the paper. It presents a simple even though effective approach to support the discovery and reuse of testing. The performed experiments are encouraging even though additional investigations need to be n order to support developers in adopting the retrieved test. The efforts required to use the recommended test need to be further investigated. *
pages/@AI-Assisted Modeling%3A DSL-Driven AI Interactions.md
+89
View File
@@ -0,0 +1,89 @@
tags:: [[#zotero]]
title:: @AI-Assisted Modeling: DSL-Driven AI Interactions
item-type:: [[journalArticle]]
original-title:: AI-Assisted Modeling: DSL-Driven AI Interactions
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/LNN2PAY5), [Web library](https://www.zotero.org/users/1039502/items/LNN2PAY5)
- [[Abstract]]
- AI-assisted programming greatly increases software development performance. We enhance this potential by integrating transparency through domain-specific modeling techniques and providing instantaneous, graphical visualizations that accurately represent the semantics of AI-generated code. This approach facilitates visual inspection and formal verification, such as model checking.
- ### Attachments
- [PDF](https://icse2026-larc.hotcrp.com/doc/icse2026-larc-paper70.pdf) {{zotero-imported-file IJWV5JTZ, "AI-Assisted Modeling DSL-Driven AI Interactions.pdf"}}
- ### Notes
- I’m doing a review for a workshop paper and these are the notes that I took while reading the paper.
# Annotazioni
(7/12/2025, 15:56:09)
“We enhance this potential by integrating transparency through domain-specific modeling techniques and providing instantaneous, graphical visualizations that accurately represent the semantics of AI-generated code.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“visual inspection and formal verification, such as model checking.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“Visual Studio Code extension for the Lingua Franca language” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“This is achieved by adapting the code generator of the modeling language to produce structured prompt templates that allow LLMs to generate implementation code for dedicated purposes that is automatically integrated in the overall system.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“we enhance AI-assisted programming with domainspecific modeling techniques and providing instantaneous, graphical visualizations that accurately represent the semantics of AIgenerated code as a basis for visual inspection and formal verification, such as model checking.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“AI-assisted programming” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“Conceptually” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“Pragmatically” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“Background” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“it remains difficult to control and steer effectively.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“s. Moreover, classical modeling workflows frequently depend on graphical representations, which are not easily generated by current AI systems” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“We combine” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“(i) state-of-the-art DSL modeling techniques with instantaneous automatic visualizations,” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“(ii) AIassisted programming to enable iterative and interactive support for DSL development.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 1)
“generating graphical models via AI is more technically demanding” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“we propose increasing the number of observation and interaction points throughout the modeling process” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“They allow modelers to inspect intermediate results, guide refinements, and provide feedbacksupporting more flexible, iterative workflows that move beyond rigid one-shot prompting” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“we decompose the program/model refinement process into distinct stages, allowing for incremental progress and improved controllability during model development” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2) The authors should clarify if the approach is for supporting modeling activities first or code development. In some sentences it seems that the approach is for assisting modeling activities, in some other parts of the paper it seems that the goal of the proposed approach is for supporting the development activities and in parallel a graphical visualization of the code being generated is given. Both directions are indeed important, but it is necessary to be clear on what's the goal of the paper.
“Contribution” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“visual verification tailored to DSL development” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2) What kind of verification do you support?
“reliability and controllability” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“Finally, we outline how parts of this extension may themselves be generated via AI in the future, further streamlining the development process.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“approach to AI-assisted modeling,” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“Building on these developments, this work investigates how similar forms of assistance can be applied to domainspecific modeling, with the goal of enabling a more natural and interactive modeling experience” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“Instead of treating model generation as a one-shot task, our approach introduces a dialog-driven workflow that facilitates clarification, program/model refinement, and visual feedback throughout the process.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“The Concept.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 2)
“Add a reactor named compute that multiplies the input by three and link them both.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 5) That's interesting, int the sense we need a way to define the abstraction of the model and understand the target artifact that will container what the prompt is asking. Here the multiplier function is in the code and not in the model, who decided that?
What if I change the final model source? Is this considered in the process? This manual intervention should be also used to update the model accordingly.
“From here create an alternative of the compute reactor that multiplies the input by five.” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 5) Here there is the decision to where the new reactor should be connected to
“Figure 4:” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 5) It is important to clarify that this is the modeling phase, the "configuration" step is not shown in the example. The settings related to the definition of the Lingua Franca language is important and not shown in the Figure.
“Listing 2: Current timer definintion in the Lingua Franca grammar” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 6) The efforts required to define the API that is specific for the language at hand is not clear. I gues that for each language, corresponding tools need to be defined. This phases should be more elaborated i the paper in order to substantiate it also with respect to the complexity of the target modeling language.
“we explored how similar refinement workflows can be extended to the development of domain-specific languages” (“AI-Assisted Modeling: DSL-Driven AI Interactions”, p. 7) The process presented in this paper is more on the modeling phase and not on the modeling language definition.
Consider that the comments tagged with #5fb236 are just highlights, while those tagged with #e56eee and #a28ae5 are important 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:
COMMENTS:
Please, avoid the typical ChatGPT dash character, and do not write in bullet points,
pages/@Bridging the gap between industry and academia%3A sustainability in LLM-assisted software engineering.md
+14
View File
@@ -0,0 +1,14 @@
tags:: [[#zotero]]
date:: 2026
title:: @Bridging the gap between industry and academia: sustainability in LLM-assisted software engineering
item-type:: [[journalArticle]]
original-title:: Bridging the gap between industry and academia: sustainability in LLM-assisted software engineering
language:: en
authors:: [[Maja H Kirkeby]], [[Pepijn de Reus]], [[Ana Oprescu]], [[Kalle Pronk]], [[Qin Zhao]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/LNXBP7BF), [Web library](https://www.zotero.org/users/1039502/items/LNXBP7BF)
- [[Abstract]]
- The advent of Large Language Models in software engineering brings both academic research and industry to the cutting edge of uncharted territory, breaking the typical division of roles, and inviting a new type of symbiosis between academia and industry. Drawing on insights from the SILAS workshop, this paper examines sustainability in LLM-assisted software engineering. It identifies key gaps between academic and industrial approaches to methods and metrics, accessibility of systems, and efficiency tradeoffs. We outline key considerations for shaping research agendas that emphasize standardized, outcome-oriented frameworks linking reproducibility with real-world sustainability.
- ### Attachments
- [Bridging the gap between industry and academia: sustainability in LLM-assisted software engineering](https://icse2026-greens.hotcrp.com/doc/icse2026-greens-paper27.pdf) {{zotero-imported-file EQ4SQVBI, "Kirkeby et al. - 2026 - Bridging the gap between industry and academia sustainability in LLM-assisted software engineering.pdf"}}
pages/@Determining Application Test Results Using Adaptive JSON.md
+123
View File
@@ -0,0 +1,123 @@
tags:: [[#zotero]]
date:: 2026
title:: @Determining Application Test Results Using Adaptive JSON
item-type:: [[journalArticle]]
original-title:: Determining Application Test Results Using Adaptive JSON
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/PIWLIAUZ), [Web library](https://www.zotero.org/users/1039502/items/PIWLIAUZ)
- [[Abstract]]
- JSON has become the most popular data exchange format for APIs, especially with the rise of both REST and GraphQL APIs. However, conventional techniques for writing and updating API tests remain laborious and time-consuming. Recent API testing solutions, such as Snapshot Testing and Traffic Mirroring Testing, attempt to address these challenges by leveraging a new data-driven testing method where each JSON API response is compared directly against a baseline. Unlike conventional testing methods, where the expected results and comparison logic are stored together in the test code, this new approach separates them. However, issues such as dynamic data or frequently changing yet irrelevant fields can still cause tests to fail unexpectedly, leading to high maintenance costs. This paper introduces the Adaptive JSON Comparison process, a novel methodology for creating flexible, stable, and maintainable tests for validating JSON API responses. It presents Skeleton JSON, a structural abstraction of the API response, and Adaptive JSON, a hybrid format that selectively combines JSON nodes with Skeleton JSON nodes. The transformation is controlled by a declarative data structure, Adaptation Set, which allows engineers to define precisely which parts of an API response to validate by value and which by structure, while systematically ignoring irrelevant or dynamic sections. Furthermore, a flexible JSON Comparison Filter enables the application of customized comparison logic to specific JSON nodes. We implemented and applied the Adaptive JSON Comparison method to both Snapshot Testing and Traffic Mirroring Testing scenarios. Our evaluation of a suite of APIs at a global e-commerce company demonstrates a marked reduction in spurious test failures and a significant decrease in the manual effort required to maintain test suites. By addressing key challenges in JSON-Driven Testing, our work streamlines quality assurance and makes automated testing more practical and scalable.
- ### Attachments
- [PDF](zotero://select/library/items/8AEAME62) {{zotero-imported-file 8AEAME62, "2026 - Determining Application Test Results Using Adaptive JSON.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotations
(14/09/2025, 17:59:08)
- “writing and updating API tests” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #a28ae5
- “Recent API testing solutions, such as Snapshot Testing and Traffic Mirroring Testing, attempt to address these challenges by leveraging a new data-driven testing method where each JSON API response is compared directly against a baseline.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #5fb236
- “Unlike conventional testing methods, where the expected results and comparison logic are stored together in the test code, this new approach separates them.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #a28ae5
- “This paper introduces the Adaptive JSON Comparison process, a novel methodology for creating flexible, stable, and maintainable tests for validating JSON API responses.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #a28ae5
- “Skeleton JSON, a structural abstraction of the API response, and Adaptive JSON, a hybrid format that selectively combines JSON nodes with Skeleton JSON nodes.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #5fb236
- “Adaptation Set, which allows engineers to define precisely which parts of an API response to validate by value and which by structure, while systematically ignoring irrelevant or dynamic sections” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #a28ae5
- “In recent years, Representational State Transfer (REST) has become the most popular API style.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #5fb236
- “JavaScript Object Notation (JSON) has become the most popular data exchange format for APIs.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #5fb236
- “However, conventional techniques for writing and updating API tests, where the expected API responses and the comparison logic are stored together in the test code, remain laborious and timeconsuming.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #a28ae5
- “a new data-driven testing (DDT) method, herein referred to as JSON-based data-driven testing (JSON-DDT), which leverages JSON as data sources, has emerged.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #a28ae5
- “g[” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #ff6666
*missing space*
- “g[” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #ff6666
*Missing space. Many occurrences of this problem.*
- “[14],” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #ffd400
*References contains many items from the gray literature even for supporting critical aspects of the paper. Instead of referring medium.com or postman.com posts, I suggest refer instead peer-reviewed papers.*
- “By separating the test environment settings, the test input parameters, and the expected API responses from the comparison logic, and by making the comparison logic a standard sharable library, a lot of manual steps to write test code are avoided in this new method, therefore makes the tests easy to write and friendly for humans to understand.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #5fb236
- “However, JSON-DDT has its own limitations and challenges, since the flexibility of using customizable test code to define and compare the expected results is largely reduced.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 1) #ffd400
*The mentioned limitation is not evident and properly stressed. Authors introduce that the paper is going to address challenges that are not clear at this very early point of the work.*
- “is resilient to insignificant changes” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ffd400
*What does it mean?*
- “JSON Schema” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ffd400
- “distinct advantages for the specific context of automated API testing” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ffd400
*Such advantages need to be clarified. For instance, what's new with respect to 10.1016/j.knosys.2016.03.020 and 10.1109/MODELS50736.2021.00033 ?*
- “Skeleton JSON is designed with simplicity and test automation as its primary goals. It is lightweight,” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ffd400
*Ok saying that at Section 2, but I expect to see some validation later in the paper supporting such mentioned strengths of Skeleton JSON.*
- “An Adaptive JSON object can be: (1) a direct subset of the original JSON; (2) a complete skeleton derived from all or part of the original JSON; or (3), most powerfully, a hybrid containing a selection of both original and skeletonized nodes.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ffd400
*Quite vague.*
- “,” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ff6666
- “The core principle of Adaptive JSON is selective abstraction. Engineers can choose to preserve the exact values for stable fields while converting volatile or irrelevant fields to their Skeleton JSON type representation.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ffd400
*What are the requirement that have driven the definition and development of "Adaptive Json"*
- “• The price field, which may fluctuate or be irrelevant to a specific test case, is abstracted to its type, "number".” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #5fb236
- “This targeted approach allows engineers to create robust validation rules that are resilient to insignificant data changes, directly addressing a primary cause of brittleness in automated testing.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #a28ae5
- “This design separates the testing logic (the consumer) from the core comparison engine (the provider)” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #5fb236
- “The Adaptive JSON Comparison Provider is the core component, responsible for executing the comparison. It contains two primary internal modules: • Automated Generation: The Adaptive JSON Conversion Module, which takes a raw JSON object and an Adaptation” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 2) #ff6666
*This can be removed because it's not updated with respect to the content of Fig. 3. The next paragraph seems to be updated.*
- “To implement the concepts of Adaptive JSON, we designed a modular system based on a consumer-provider architecture, as illustrated in the teaser Figure 3. This design separates the testing logic” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 3) #ffd400
*This is a repetition in the text.*
- “**Adaptive JSON Comparison Provider**” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 3) #ffd400
*The usage of ** ** seems to be related to MD syntax for making the text bold.*
- “In this paper, we addressed the critical challenge of brittleness in modern data-driven API testing. We identified that naive comparisons of JSON responses in techniques like Snapshot Testing and Traffic Mirroring lead to high maintenance costs due to frequent, spurious failures from dynamic or irrelevant data variations.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 7) #ffd400
*This requires to be substantiated with some concrete and motivational example.*
- “Our core contributions include the concepts of Skeleton JSON and the hybrid Adaptive JSON format, which are controlled by a declarative Adaptation Set. This approach allows engineers to precisely define which parts of an API response to validate by value and which by structure. As demonstrated in our case studies, applying this method to Snapshot Testing and Traffic Mirroring effectively filters out irrelevant data noise, significantly reducing false positives and making these powerful testing techniques more practical and robust in real-world environments.” (“Determining Application Test Results Using Adaptive JSON”, 2026, p. 8) #ffd400
*The strenghts of the Skeleton Json and Adaptive JSON is not presented with respect to existing approaches that are able to retrieve JSON schema out JSON documents.
The proposed approach is not compared with any API testing techniques.
THe paper is not always well written. There are repeated text. THe authors can use additional papges to properly present the strenghts and uthe limtiations of the proposed approach.*
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?
pages/@Generation of Unit Tests for Test-Driven Development using Large Language Models.md
+126
View File
@@ -0,0 +1,126 @@
tags:: [[#zotero]]
title:: @Generation of Unit Tests for Test-Driven Development using Large Language Models
item-type:: [[journalArticle]]
original-title:: Generation of Unit Tests for Test-Driven Development using Large Language Models
language:: en
authors:: [[Nathanael Yao]], [[Juergen Dingel]], [[Ali Tizghadam]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/2FPNV3ZR), [Web library](https://www.zotero.org/users/1039502/items/2FPNV3ZR)
- [[Abstract]]
- Test-Driven Development (TDD) is a process that has been shown to reduce software defects yet is not always adopted in industrial software. Case studies on industrial teams have shown up to a 50% reduction in defect density when using TDD compared to ad-hoc unit testing. TDD can also reduce the cost of debugging software by finding code defects earlier and can contribute to better software design. In this paper, we present our ongoing work on an approach that uses generative AI to generate unit tests to facilitate test-driven development. Given a high-level goal, the approach generates formalized requirements in the form of a goal model, which is then used to generate unit tests in a test folder. We describe a current prototype implementation and show initial results for example high-level goals provided by our industrial partner.
- ### Attachments
- [PDF](zotero://select/library/items/IU5ZGYX4) {{zotero-imported-file IU5ZGYX4, "Yao et al. - Generation of Unit Tests for Test-Driven Development using Large Language Models.pdf"}}
- ### Notes
- # I'm reviewing a research paper and I took the following notes:
# Annotations
(30/7/2025, 12:06:11)
- “Test-Driven Development (TDD) is a process that has been shown to reduce software defects yet is not always adopted in industrial software.” (Yao et al., p. 1) #5fb236
- “50% reduction in defect density when using TDD compared to ad-hoc unit testing.” (Yao et al., p. 1) #5fb236
- “cost of debugging software by finding code defects earlier and can contribute to better software design.” (Yao et al., p. 1) #5fb236
- “ongoing work on an approach that uses generative AI to generate unit tests to facilitate test-driven development” (Yao et al., p. 1) #e56eee
- “goal model,” (Yao et al., p. 1) #a28ae5
- “which is then used to generate unit tests in a test folder.” (Yao et al., p. 1) #a28ae5
- “During Test-Driven Development (TDD), developers start by creating a failing test that matches the given goals for the implementation.” (Yao et al., p. 1) #e56eee
- “When the implementation code is written, developers write the minimum amount of code to pass the unit tests written in the previous step.” (Yao et al., p. 1) #e56eee
- “Unit tests are a form of software testing that evaluates individual components or functions in isolation to ensure their correctness.” (Yao et al., p. 1) #5fb236
- “unit tests are often written after the implementation code, using TDD can be more effective in reducing software defects.” (Yao et al., p. 1) #5fb236
- “However, despite its benefits, a small subset of developers choose to not write tests [2].” (Yao et al., p. 1) #5fb236
- “Using Large Language Models (LLMs) to generate unit tests offers an approach that may be less time consuming for developers.” (Yao et al., p. 1) #5fb236
- “use of LLMs for the generation of unit tests from user-given goals to facilitate TDD.” (Yao et al., p. 1) #5fb236
- “ongoing work on an approach and prototype for the generation of unit tests for TDD.” (Yao et al., p. 1) #a28ae5
- “many diverse user-given goals, but the development of our prototype was heavily focused on generating unit tests for the network domain” (Yao et al., p. 1) #a28ae5
- “We did not conduct an extensive evaluation, instead relying on manual checks and feedback from our industry partner.” (Yao et al., p. 1) #ffd400
*This is ok for a workshop paper.*
- “II. UNIT TESTS IN TEST-DRIVEN DEVELOPMENT” (Yao et al., p. 1) #5fb236
- “During Test-Driven development (TDD), unit tests are created based on requirements for new functionality before any implementation code is written” (Yao et al., p. 1) #5fb236
- “Red-Green-Refactor: developers write a few failing unit tests (red), then write implementation code to pass the test cases (green) and refactor the code, making sure all the tests still pass (refactor).” (Yao et al., p. 1) #5fb236
- “Unit tests are added incrementally as new features are added, and all previous unit tests must pass as new unit tests and implementation code are added.” (Yao et al., p. 1) #a28ae5
- “Moreover, unit tests in TDD can also help reveal issues with the requirements.” (Yao et al., p. 1) #5fb236
- “The purpose of writing unit tests is to be able to isolate a unit and verify its correctness.” (Yao et al., p. 1) #a28ae5
- “R1: Given input that identifies the high-level goal g that the user is planning to write implementation code for, the approach and prototype implementation should for any goal g: a) refine the high-level goal g into a set of sub-goals and b) generate unit tests of sufficient quality for goal g using the refined requirements. R2: The approach should represent the requirements in a way that generates good quality unit tests. R3: The approach should work for arbitrary user goals g.” (Yao et al., p. 2) #ffd400
*Section 5 that presents the approach is not effective in explaining how these steps work. In particular, it is not clear how the human involvement is managed, how the iterative nature of the process is supported, how human feedback is considered by the subsequent steps of the test driven process.*
- “Most recent work on test generation uses the implementation code as input. For instance, Amazon Q developer [6] and GitHub Copilot [7] provide a chatbot that allows users to generate unit tests with appropriate mocks for specified methods,” (Yao et al., p. 2) #a28ae5
- “TESTPILOT, which used the function signature as well as other available information such as documentation and usage examples to generate unit tests with GAI” (Yao et al., p. 2) #5fb236
- “A previous study found correctness issues in some unit tests generated by ChatGPT but finds that the correct tests are of comparable quality to tests written by developers [3]” (Yao et al., p. 2) #5fb236
- “Our approach differs from these works as it does not use the implementation code as input and can be used to support TDD.” (Yao et al., p. 2) #5fb236
- “The MAPE-K loop mechanism has been used to assist in LLM-based goal model generation by continuously adding goals during the loops.” (Yao et al., p. 2) #5fb236
- “process assigns different roles to the LLM, allowing it to act as different domain experts when performing different tasks within the MAPE-K loop” (Yao et al., p. 2) #5fb236
- “This also showed promising results, but included steps that required human decision making” (Yao et al., p. 2) #5fb236
- “GAI has been used as a collaborative tool for developers during TDD showing promising results but requiring developer supervision.” (Yao et al., p. 2) #5fb236
- “Many techniques are used to try and improve the quality of LLM-generated answer” (Yao et al., p. 2) #5fb236
- “Our approach is novel, as it allows for few-shot examples of unit tests to be given in our unit test generation step that are aligned with the basic actions selected in the generated goal models.” (Yao et al., p. 2) #e56eee
- “Our industrial partner tasked us with creating a tool that generates unit tests from user-defined goals.” (Yao et al., p. 2) #5fb236
- “Generating a goal model skeleton” (Yao et al., p. 2) #2ea8e5
- “filling in the values in the goal model skeleton using GenAI” (Yao et al., p. 2) #2ea8e5
- “unit test generation” (Yao et al., p. 2) #2ea8e5
- “1) Pool of Basic Actions” (Yao et al., p. 2) #2ea8e5
- “Fig. 1: Algorithm for generating unit tests” (Yao et al., p. 3) #ffd400
*I'm not sure this algorithm as presented in the paper is effective in the presentation. I would find an alternative way to present the process that in the end consists of three main steps.*
- “Fig. 2: Snippet of the pool of basic actions used to build our goal models” (Yao et al., p. 3) #ffd400
*Who defines them? Are they domain/application specific?*
- “It contains two template variables: a goal g representing the user-defined goal” (Yao et al., p. 3) #ffd400
*Are goal models written in a specific syntax/format?*
- “3) Querying the LLM: Next, the LLM is queried using the goal model skeleton prompt and few shot examples to generate a goal model skeleton (line 2 in Figure 1).” (Yao et al., p. 3) #ffd400
*This is not clear. The LLM is queried with a goal model skeleton prompt to generate a goal model skeleton. Different parts of the paper are affected by presentation issues that reduce the readability of the work. It is not clear what is general and what is application specific that is valid only for the application at hand and made working with ad-hoc steps.*
- “validate, get, return” (Yao et al., p. 3) #5fb236
- “C. Unit Test Generation 1) Few Shot Examples: The list of chosen basic actions generated in the previous step will be used to select example unit tests to aid in unit test generation (line 9 of Figure 1). Each basic action in our pool has a corresponding set of example requirements and unit tests. We tried to include at least two few-shot examples of requirement and unit test pairs for each basic action in our pool. Figure 7 is a snippet of a few-shot example for the ’lookup’ basic action (Jinja2 statements are shown in blue).” (Yao et al., p. 4) #ffd400
*This step is not clear neither. First of all it is necessary to clarify that the work is Python specific. Then, it is not clear how unit tests for the basic actions can be "composed" to generate unit tests that are specific for the application at hand. Moreover, what's the granularity of the wanted unit tests?*
- “However, it struggled with more complex examples and on examples where the high-level goals were less well defined.” (Yao et al., p. 5) #ffd400
*This is not surprising to me. I'm really missing in the approach a clear specification of the granularity of the unit tests, what they are supposed to test, etc.*
- “Our approach takes a high-level goal, refines it into a goal model constructed using a pool of basic actions, and generates unit tests based on the subgoals in the goal model” (Yao et al., p. 5) #5fb236
- “Despite the mixed results, our approach is novel as it is able to provide few-shot examples of relevant unit tests for many different high-level goals.” (Yao et al., p. 5) #5fb236
- “Chain-of-thought prompting could be used to attempt to improve the LLMs reasoning capability.” (Yao et al., p. 5) #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 COMMENTS: Organize the notes especially those that contain issues or typos. Please do not make an extrause of bullet points. Make the comments fluent without being too verbose
######
pages/@Graphical Interface Model for Empowering Web Application Users to Make Sustainable Choices%3A a Technology Acceptance Study.md
+109
View File
@@ -0,0 +1,109 @@
tags:: [[#zotero]]
date:: 2018
title:: @Graphical Interface Model for Empowering Web Application Users to Make Sustainable Choices: a Technology Acceptance Study
item-type:: [[journalArticle]]
original-title:: Graphical Interface Model for Empowering Web Application Users to Make Sustainable Choices: a Technology Acceptance Study
language:: en
authors:: [[Giuliano M Bonazzi]], [[Jacopo Ammendola]], [[Eduardo M Guerra]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/C3JFD69L), [Web library](https://www.zotero.org/users/1039502/items/C3JFD69L)
- [[Abstract]]
- Different from other products, in which the user knows about their energy consumption and can make more sustainable options, in web applications, the user has no control or information regarding how it could be more sustainable. For instance, a specific user might not need the information in a given panel or might choose a lower update rate for a chart or table. To fill this gap, this work aims to propose a graphical user interface model to promote digital sustainability in web applications. The model, named LEAFS, was constructed based on a literature review on digital sustainability, technology acceptance models, and persuasive design theories. An interactive prototype of the model applied in a fictional web application from the finance sector was developed using Figma. In this paper, we present a technology acceptance study with potential users to validate the model, using a structured instrument based on UTAUT 2. The results revealed a good acceptance from the users regarding the possibility of configuring a web application to more sustainable options, and also pointed to some improvement points to be considered before its implementation. As a consequence, this work evaluates an original idea that considers user choices in the implementation of web applications’ sustainability, creating a new dimension to reduce energy consumption.
- ### Attachments
- [PDF](https://icse2026-greens.hotcrp.com/doc/icse2026-greens-paper28.pdf) {{zotero-imported-file 2F7LTX29, "Bonazzi et al. - 2018 - Graphical Interface Model for Empowering Web Application Users to Make Sustainable Choices a Techno.pdf"}}
- ### Notes
- # Annotazioni
(23/11/2025, 19:15:42)
“in web applications, the user has no control or information regarding how it could be more sustainable.” (Bonazzi et al., 2018, p. 1)
“graphical user interface model to promote digital sustainability in web applications.” (Bonazzi et al., 2018, p. 1)
“In this paper, we present a technology acceptance study with potential users to validate the model, using a structured instrument based on UTAUT 2.” (Bonazzi et al., 2018, p. 1)
“As a consequence, this work evaluates an original idea that considers user choices in the implementation of web applications’ sustainability, creating a new dimension to reduce energy consumption.” (Bonazzi et al., 2018, p. 1) How is it possible to validate the resulting energy consumption is consistent with the user choices/requirements?
“The declaration sheds light on the growing negative externalities of digital habits on the environment while also pointing out that digital innovations can enable systemic effects in reducing greenhouse gas emissions [17].” (Bonazzi et al., 2018, p. 1)
“Green IT” (Bonazzi et al., 2018, p. 1)
“Although the area has been constantly evolving, a significant body of literature focuses on rethinking software engineering processes and hardware energy efficiency, with emerging but still limited attention to the role of software usage and feature customization by end-users.” (Bonazzi et al., 2018, p. 1)
“Users naturally have different perceptions, purposes, and skills while using an interface that cannot be fully anticipated.” (Bonazzi et al., 2018, p. 1)
“enabling more advanced customization options for users to change the behavior of an application would represent a viable strategy to promote sustainability by configuring feature functionality and rearranging interface and functional components.” (Bonazzi et al., 2018, p. 1)
“propose and evaluate the user acceptance of a pluggable graphical interface model aiming to empower website end users to customize web applications in order to reduce their environmental impact while also enhancing understanding of configurable options and promoting environmental awareness through educational content.” (Bonazzi et al., 2018, p. 1)
“component that could be plugged into any site with minimal configuration and adjustments to reach a broader public and thus, greater impact.” (Bonazzi et al., 2018, p. 1)
“Figma” (Bonazzi et al., 2018, p. 1) Figma: The Collaborative Interface Design Tool
Put a footnote
“UTAUT 2” (Bonazzi et al., 2018, p. 2) what's that? Please add a reference
“Based on the answers, we performed a quantitative analysis of the closed-ended question and a qualitative analysis of the open-ended questions.” (Bonazzi et al., 2018, p. 2)
“Performance Expectancy, Effort Expectancy, and Learning Value.” (Bonazzi et al., 2018, p. 2)
“difficulties in associating environmental metrics with real-world adherence.” (Bonazzi et al., 2018, p. 2) Yes, that's an important point (see one of my comments above).
“green software and persuasive interfaces” (Bonazzi et al., 2018, p. 2)
“proposed graphical interface model;” (Bonazzi et al., 2018, p. 2)
“research method for the technology acceptance study” (Bonazzi et al., 2018, p. 2)
“results and findings of the study” (Bonazzi et al., 2018, p. 2)
“how to measure software energy efficiency” (Bonazzi et al., 2018, p. 2)
“field is still immature.” (Bonazzi et al., 2018, p. 2)
“consumes more energy than a system without it.” (Bonazzi et al., 2018, p. 2)
“reducing energy consumption by allowing users to customize the software based on their usage profile, aiming to reduce the waste generated by unnecessary features.” (Bonazzi et al., 2018, p. 2) That's an interesting proposal. Of course, I see several limitations in its actual implementation, but still it can be interesting!
“Without their awareness of how to use such resources in a sustainable manner, there will be a significant waste of resources in the usage of such applications.” (Bonazzi et al., 2018, p. 2)
“The interface proposed in this work has as its main vision to stimulate users’ digital environmental impact awareness and sustainable actions through the mediation of functional and engaging interactions.” (Bonazzi et al., 2018, p. 2)
“ons. The interface model concept advocates for universal applicability in the web context to achieve influence over the reduction of digital environmental impacts. In this sense, it intends to be flexible enough to provide various implementation alternatives or a strategy framework for developing customization features internally as a means to foster wide adoption by website owners and IT specialists.” (Bonazzi et al., 2018, p. 2) Already said. Sometimes the paper is repetitive.
“two distinct entities” (Bonazzi et al., 2018, p. 3)
“fictional website representing a potential model use case” (Bonazzi et al., 2018, p. 3)
“materialization of the model into an actionable interface” (Bonazzi et al., 2018, p. 3)
“The impact visualization translates individual results into graphical, real-world metaphors to strengthen their significance” (Bonazzi et al., 2018, p. 3)
“The last two screens relate to the possibility of alternating between the available profile options and the profile details screen, and to the advanced customization of website features.” (Bonazzi et al., 2018, p. 3) Is this always possible for any web application? I have some doubts about this. How to define profiles? How to check their correctness? (removing some elements of the page, can have some ripple effects with those that instead are intended to be shown).
“investigate how different factors can influence the intention to use the model by end users as a means to prove its validity and relevance.” (Bonazzi et al., 2018, p. 3)
“brief presentation video introducing the model and prototype was embedded before the UTAUT2 dimensions section in the questionnaire.” (Bonazzi et al., 2018, p. 3)
“eight dimensions for acceptance evaluation: Behavioral Intention, Performance Expectancy, Effort Expectancy, Social Influence, Facilitating Conditions, Hedonic Motivation, Learning Value, and Habit and Experience.” (Bonazzi et al., 2018, p. 4)
“we recreated the video, changing not its content but its format, to make it more interesting to the viewers.” (Bonazzi et al., 2018, p. 4)
“inductive coding approach.” (Bonazzi et al., 2018, p. 4)
“The second phase and third phase represented consecutive refinements of both the prototype and its presentation video, carried out in response to feedback gathered in each preceding phase.” (Bonazzi et al., 2018, p. 4)
“This combination suggests a sample that is both highly educated and mature, factors that may influence their engagement, digital abilities, and professional experience.” (Bonazzi et al., 2018, p. 4)
“This paper proposed an approach to empower the users of web applications to make configurations that can reduce energy consumption. We created a user interface prototype using Figma and evaluated its acceptance through a technology acceptance study based on UTAUT2.” (Bonazzi et al., 2018, p. 8) I'm wondering to what extent this can be really made general for any kinds of application.
“showing that this is a promising path for energy saving that can be pursued in the future.” (Bonazzi et al., 2018, p. 8)
“o the best of our knowledge, no previous work in the literature has explored the participation of users in choices to avoid energy waste before, so the contribution of this work opens a new dimension that can be explored in the implementation of more sustainable web applications.” (Bonazzi et al., 2018, p. 8)
“. Additionally, some participants expressed uncertainty about the real-world significance of the environmental metrics displayed.” (Bonazzi et al., 2018, p. 8) Exactly, I agree!
“pluggable web component and integrated into existing web applications to evaluate the required effort for its implementation.” (Bonazzi et al., 2018, p. 8)
“an experiment with a real application can provide more information regarding user adoption and the potential for energy savings.” (Bonazzi et al., 2018, p. 8)
pages/@Incarichi di ricerca.md
+10
View File
@@ -0,0 +1,10 @@
tags:: [[#zotero]]
title:: @Incarichi di ricerca
item-type:: [[webpage]]
access-date:: 2025-11-18T07:32:02Z
original-title:: Incarichi di ricerca
url:: https://www.univaq.it/include/utilities/blob.php?table=regolamento&id=205&item=file
links:: [Local library](zotero://select/library/items/H6XB4AE2), [Web library](https://www.zotero.org/users/1039502/items/H6XB4AE2)
- ### Attachments
- [PDF](https://www.univaq.it/include/utilities/blob.php?table=regolamento&id=205&item=file) {{zotero-imported-file 7ZTPLJQC, "blob.php.pdf"}}
pages/@Incarichi post-doc.md
+10
View File
@@ -0,0 +1,10 @@
tags:: [[#zotero]]
title:: @Incarichi post-doc
item-type:: [[webpage]]
access-date:: 2025-11-18T07:30:48Z
original-title:: Incarichi post-doc
url:: https://www.univaq.it/include/utilities/blob.php?table=regolamento&id=203&item=file
links:: [Local library](zotero://select/library/items/4T5MDQIA), [Web library](https://www.zotero.org/users/1039502/items/4T5MDQIA)
- ### Attachments
- [PDF](https://www.univaq.it/include/utilities/blob.php?table=regolamento&id=203&item=file) {{zotero-imported-file 3NYMMVBB, "blob.php.pdf"}}
pages/@LLM-assisted configuration of model-driven business process families.md
+108
View File
@@ -0,0 +1,108 @@
tags:: [[#zotero]]
title:: @LLM-assisted configuration of model-driven business process families
item-type:: [[journalArticle]]
original-title:: LLM-assisted configuration of model-driven business process families
language:: en
authors:: [[Daniel Calegari]], [[Andrea Delgado]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/9T42DIJ7), [Web library](https://www.zotero.org/users/1039502/items/9T42DIJ7)
- [[Abstract]]
- Business processes often include variations driven by specific business requirements, leading to the concept of a business process family. The management of such families can be streamlined using the Model-Driven Engineering (MDE) approach, which involves defining metamodels to express the process family and applying transformations to support the required management activities, such as the configuration process of a specific process variant. The vast range of potential variants within a BPF introduces several challenges, including the need for mechanisms to assist users in configuring specific process variants. In this article, we explore how an MDE-based business process family management approach could be combined with Large Language Models (LLMs) to define questionnaires that support the configuration of process variants. Although the results are promising and in line with previous findings on the use of LLMs for MDE, several aspects must be considered to bring their application to a reliable industrial environment.
- ### Attachments
- [PDF](zotero://select/library/items/9ZEW774P) {{zotero-imported-file 9ZEW774P, "Calegari e Delgado - LLM-assisted configuration of model-driven business process families.pdf"}}
- ### Notes
- # I'm reviewing a research paper and I took the following notes:
# Annotations
(30/7/2025, 14:43:25)
- “model-driven business process families” (Calegari general-and Delgado, p. 1) #5fb236
- “specific business requirements, leading to the concept of a business process family” (Calegari general-and Delgado, p. 1) #a28ae5
- “In this article, we explore how an MDE-based business process family management approach could be combined with Large Language Models (LLMs) to define questionnaires that support the configuration of process variants.” (Calegari general-and Delgado, p. 1) #5fb236
- “This process is configurable, meaning that some elements are variable, and a configuration process must be carried out to derive a process variant.” (Calegari general-and Delgado, p. 1) #5fb236
- “It requires using techniques such as questionnaires [9] to guide users in developing a configuration, which can then be used to generate the variants automatically.” (Calegari general-and Delgado, p. 1) #5fb236
- “This article explores the integration of LLMs within an MDE-based proposal for managing BP families.” (Calegari general-and Delgado, p. 1) #e56eee
- “The LLM would assist in developing questionnaires for end-users based on the information contained in the BP family model.” (Calegari general-and Delgado, p. 1) #e56eee
- “These questionnaires are connected to the many configuration options of the BP family.” (Calegari general-and Delgado, p. 1) #5fb236
- “Once a questionnaire is answered, a model transformation utilizes this configuration to generate a specific process instance.” (Calegari general-and Delgado, p. 1) #5fb236
- “Questionnaires are based on an existing proposal from [9], but have been technologically updated and adapted to the MDE-based approach defined in [3].” (Calegari general-and Delgado, p. 1) #ffd400
*It is necessary to expand this statement with more details.*
- “BUSINESS PROCESS FAMILIES MANAGEMENT” (Calegari general-and Delgado, p. 1) #5fb236
- “a metamodel conceptualizing key elements for BP families” (Calegari general-and Delgado, p. 1) #2ea8e5
- “a high-level management process supported by the Business Process Family Manager (BPFM) tool” (Calegari general-and Delgado, p. 1) #2ea8e5
- “Business Process Family Manager (BPFM) tool [12].” (Calegari general-and Delgado, p. 1) #ffd400
*The last commit to the tool seems to be done 4 years ago.*
- “A business process family (BPFamily) groups multiple process variants (ProcessVariant) that share a common base process (BaseProcess) while allowing variations (VariationPoint) on activities, routing nodes, or process fragments. These variation points determine where different variants (Variant) can be applied based on the context (Context), which defines context requirements (ContextRequirement) for variant selection. A specific process variant is derived by defining a configuration (Configuration) that satisfies these requirements.” (Calegari general-and Delgado, p. 2) #ffd400
*To make the proposal more convincing and less abstract it is important to give earlier in the paper some illustrative examples of variants related to business process families. Can you make some explanatory examples?*
- “Figure 1: BP families metamodel (from [3])” (Calegari general-and Delgado, p. 2) #ffd400
*The metamodel come from paper [3], another paper from the authors. It is important to stress the novelties of this paper in comparison with what was presented in [3]*
- “The BPFM tool supports this process by allowing the management of variability approaches that can co-exist within the tool in a homogenized way” (Calegari general-and Delgado, p. 2) #5fb236
- “Within this approach, BP family languages and configurations must be expressed using metamodels to generate variants using model-to-model transformations, leveraging user-defined configurations.” (Calegari general-and Delgado, p. 2) #5fb236
- “In [9], the authors propose an approach to capture system variability based on questionnaire models.” (Calegari general-and Delgado, p. 2) #5fb236
- “The approach depicts variability independently of specific languages through facts representing the space of possible answers to a set of questions.” (Calegari general-and Delgado, p. 2) #5fb236
- “Questions and facts can be connected through precedence or order dependencies, and facts may have domain” (Calegari general-and Delgado, p. 2) #ffd400
*It is important to give some examples of questions to make the presentation concrete and help the reader to grasp the message.*
- “The configuration process is captured through a series of actions.” (Calegari general-and Delgado, p. 2) #5fb236
- “C-EPC” (Calegari general-and Delgado, p. 2) #ffd400
- “The tool not only allows the selection of the most pertinent questions based on the current state of the configuration, but also makes use of a logical expression manipulation application to verify in real-time that the answers comply with the domain constraints, avoiding inconsistent or invalid configurations.” (Calegari general-and Delgado, p. 3) #5fb236
- “Additionally, its automatic variant generation process is tied to a specific language for BP family modeling” (Calegari general-and Delgado, p. 3) #5fb236
- “QML for questionnaires” (Calegari general-and Delgado, p. 3) #2ea8e5
- “DCL for specifying configurations.” (Calegari general-and Delgado, p. 3) #ffd400
*What are the configurations that are needed? Can you explain what's the usge of the elements given in the DCL metamodel in Fig. 4.b?*
- “LLM-ASSISTED GENERATION OF QUESTIONNAIRES” (Calegari general-and Delgado, p. 3) #5fb236
- “LLM uses it to derive a questionnaire model that conforms to the QML metamodel depicted in Figure 4a.” (Calegari general-and Delgado, p. 3) #5fb236
- “The prompt is composed of three parts, as detailed in Table I:” (Calegari general-and Delgado, p. 3) #ffd400
*I would include illustrative examples for each of the three parts.*
- “Task Description. A” (Calegari general-and Delgado, p. 3) #2ea8e5
- “Input Requirements.” (Calegari general-and Delgado, p. 4) #2ea8e5
- “Output Requirements.” (Calegari general-and Delgado, p. 4) #2ea8e5
- “(A) to assess the degree to which the LLM could resolve the problem using a zero-shot strategy, without any feedback loop;” (Calegari general-and Delgado, p. 4) #2ea8e5
- “(B) to compare the results with those of other available LLM solutions and their reasoning capabilities;” (Calegari general-and Delgado, p. 4) #2ea8e5
- “(C) to determine whether it is possible to improve the results based on a conversational interaction with the LLM, closer to the usual way of working in a real environment with domain experts.” (Calegari general-and Delgado, p. 4) #2ea8e5
- “A. Zero-shot experiment” (Calegari general-and Delgado, p. 4) #ffd400
*This section is verbose and is missing some concrete examples. It's difficult to follow without them.*
- “Metrics are based on a semantic equivalence between questions, facts, and dependencies of the ground-truth model and the derived ones.” (Calegari general-and Delgado, p. 5) #ffd400
*How was the semantic equivalence assessed?*
- “It presents a method where LLMs assist in generating useroriented questionnaires that support the configuration of process variants based on a metamodel-driven framework.” (Calegari general-and Delgado, p. 10) #ffd400
*How are these configurations "consumed"?*
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 COMMENTS: Organize the notes especially those that contain issues or typos. Please do not make an extrause of bullet points. Make the comments fluent without being too verbose
pages/@Modeling AI-Driven Workflows for Ecosystem Resilience Prediction.md
+439
View File
@@ -0,0 +1,439 @@
tags:: [[#zotero]]
title:: @Modeling AI-Driven Workflows for Ecosystem Resilience Prediction
item-type:: [[journalArticle]]
original-title:: Modeling AI-Driven Workflows for Ecosystem Resilience Prediction
language:: en
authors:: [[Tiago Sousa]], [[Nicolas Guelfi]], [[Benoit Ries]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/IWLHMQSC), [Web library](https://www.zotero.org/users/1039502/items/IWLHMQSC)
- [[Abstract]]
- Engineering AI-driven workflows to predict ecosystem resilience is increasingly important for responding to rapid environmental change. As climate variability intensifies, leveraging artificial intelligence to support ecological decision-making has become a common approach. However, prevailing approaches to engineering these prediction systems are often ad-hoc and difficult to reproduce, lacking a systematic methodology to ensure coherence between ecological requirements, data, and AI engineered components. To address this gap, this paper introduces a model-driven engineering methodology to support the systematic development of Ecosystem Resilience Prediction Systems (ERPS). We propose an adaptive workflow that formalizes our development process, based on two core metamodels: EcoSys, for structuring the ecological problem domain by defining its measurable properties as resilience indicators, and PredSys, for defining the AI and dataset solution domains. This approach ensures that AI architectures and datasets are co-designed to predict these properties, formally linking them to ecological requirements. The workflow’s flexible design accommodates goal-driven, datadriven, and model-driven entry points. We demonstrate the methodology’s applicability by retrospectively modeling two realworld case studies from the literature: one on forest carbon stock estimation and another on coastal fisheries management.
- ### Attachments
- [PDF](zotero://select/library/items/Y4XBT2Y6) {{zotero-imported-file Y4XBT2Y6, "Sousa et al. - Modeling AI-Driven Workflows for Ecosystem Resilience Prediction.pdf"}}
- ### Notes
- # Annotations
(29/7/2025, 15:12:27)
- “AI-Driven Workflows for Ecosystem Resilience Prediction” (Sousa et al., p. 1) #5fb236
* *
- “As climate variability intensifies, leveraging artificial intelligence to support ecological decision-making has become a common approach” (Sousa et al., p. 1) #5fb236
* *
- “model-driven engineering methodology to support the systematic development of Ecosystem Resilience Prediction Systems (ERPS).” (Sousa et al., p. 1) #ffd400
*What do you mean with ecosystem resilience? *
- “This approach ensures that AI architectures and datasets are co-designed to predict these properties, formally linking them to ecological requirements.” (Sousa et al., p. 1) #5fb236
* *
- “one on forest carbon stock estimation” (Sousa et al., p. 1) #5fb236
* *
- “nother on coastal fisheries management.” (Sousa et al., p. 1) #5fb236
* *
- “ecosystem resilience” (Sousa et al., p. 1) #ffd400
*natural ecosystems? what? you need to define it early in the paper. *
- “While modern ecological monitoring generates vast and heterogeneous datasets from automated sensors and large-scale data acquisition [3], applying advanced AI to this data is essential to enabling the repeatable ecosystem assessments needed to track environmental shifts and inform policy” (Sousa et al., p. 1) #5fb236
* *
- “despite the potential of AI, the primary engineering barrier is the overall workflow rather than individual models.” (Sousa et al., p. 1) #5fb236
* *
- “This absence of systematic and reproducible workflows slows scientific progress and the development of scalable solutions” (Sousa et al., p. 1) #5fb236
* *
- “Ecosystem Resilience Prediction Systems (ERPS)” (Sousa et al., p. 1) #5fb236
* *
- “The methodology is founded on two core, formally defined metamodels that structure the problem and solution domains.” (Sousa et al., p. 1) #5fb236
* *
- “Ecosystem metamodel (EcoSys” (Sousa et al., p. 1) #2ea8e5
* *
- “Prediction System metamodel (PredSys)” (Sousa et al., p. 1) #2ea8e5
* *
- “AI architectures (PredSys-AI) and dataset characteristics (PredSys-Dataset)” (Sousa et al., p. 1) #2ea8e5
* *
- “workflow that accommodates goal-driven, data-driven, and model-driven design processes” (Sousa et al., p. 1) #2ea8e5
* *
- “modeling of bidirectional links between ecosystem requirements, data constraints, and AI capabilities” (Sousa et al., p. 1) #5fb236
* *
- “coherent” (Sousa et al., p. 1) #ffd400
*what do you mean? Data constraints on what? *
- “ecosystem science and prediction systems engineering” (Sousa et al., p. 1) #5fb236
* *
- “A central problem in modern ecosystem science is the transition from creating isolated models to engineering integrated, end-to-end workflows.” (Sousa et al., p. 2) #ffd400
*It is necessary to give some explanatory examples early in the paper just to clearly state what's the focus/context of the work. *
- “A major concern is ensuring that as AI becomes more powerful, systems remain transparent, accountable, and subject to expert oversight.” (Sousa et al., p. 2) #a28ae5
* *
- “While this highlevel, strategic perspective calls for a formal, human-driven design process, it does not prescribe a concrete methodology for achieving it, which is a primary motivation for our work.” (Sousa et al., p. 2) #5fb236
* *
- “Another key challenge is the automation and standardization of the data-to-model lifecycle.” (Sousa et al., p. 2) #5fb236
* *
- “They highlight the need for automation but do not provide a formal design methodology to specify what these automated pipelines should do and why.” (Sousa et al., p. 2) #5fb236
* *
- “This gap is further evidenced by the proliferation of specific, applicationoriented workflows, for instance, for monitoring nocturnal insects [12], managing coastal fisheries [13], and assessing algal blooms [14].” (Sousa et al., p. 2) #ffd400
*Only at this point you understand that the paper is about natural ecosystems. *
- “prediction system” (Sousa et al., p. 2) #5fb236
* *
- “This allows for precise structural descriptions but offers less support for specifying the model’s requirements or expected behavior” (Sousa et al., p. 2) #5fb236
* *
- “De la Vega et al. [18] present a DSL to automate the transformation of structured data into a format suitable for prediction systems.” (Sousa et al., p. 2) #5fb236
* *
- “a posteriori documentation of existing datasets” (Sousa et al., p. 2) #5fb236
* *
- “few provide the level of detail and guidance needed to model the specific activities, roles, and dependencies involved in engineering prediction systems.” (Sousa et al., p. 2) #a28ae5
* *
- “tool concept that provides step-by-step support for explicitly modeling ML application integration in BPMN business processes.” (Sousa et al., p. 2) #a28ae5
* *
- “a DSL to model AI engineering processes, covering the needs for such processes as described in academic and industry proposals” (Sousa et al., p. 2) #e56eee
* *
- “DSL for modeling ML engineering processes, including activities, their orchestration, roles, resources, and artifacts.” (Sousa et al., p. 3) #5fb236
* *
- “Although comprehensive, their approach remains primarily descriptive, supporting the documentation and execution of workflows but lacking mechanisms to enforce consistency between the generated artifacts through verifiable means.” (Sousa et al., p. 3) #5fb236
* *
- “In contrast to prior work, we emphasize the formal alignment between problem specification and model design, the derivation of AI and dataset requirements from domain-level concerns, and a prescriptive process model that enforces consistency across artifacts.” (Sousa et al., p. 3) #e56eee
* *
- “AIdriven workflows for ecosystem resilience prediction.” (Sousa et al., p. 3) #a28ae5
* *
- “Ecosystem metamodel (EcoSys)” (Sousa et al., p. 3) #2ea8e5
* *
- “Prediction System metamodel (PredSys)” (Sousa et al., p. 3) #2ea8e5
* *
- “AI models and datasets.” (Sousa et al., p. 3) #2ea8e5
* *
- “adaptive model-driven workflow.” (Sousa et al., p. 3) #5fb236
* *
- “The section concludes with three detailed scenarios that showcase the adaptability of our approach in real-world contexts.” (Sousa et al., p. 3) #5fb236
* *
- “A. Metamodeling Requirements, Data, and AI Components” (Sousa et al., p. 3) #2ea8e5
* *
- “ERPS” (Sousa et al., p. 3) #5fb236
* *
- “Ecosystem metamodel (EcoSys)” (Sousa et al., p. 3) #5fb236
* *
- “Prediction System metamodel (PredSys)” (Sousa et al., p. 3) #5fb236
* *
- “1) Ecosystem metamodel (EcoSys)” (Sousa et al., p. 3) #2ea8e5
* *
- “Our ecosystem metamodel (EcoSys), inspired by the DREF framework [5], adapts foundational resilience concepts from software engineering to natural ecosystems (see Figure 1).” (Sousa et al., p. 3) #5fb236
* *
- “s :” (Sousa et al., p. 3) #ff6666
* *
- “Evolution axes define how these entities or the ecosystem health change over an ordered dimension (e.g. time).” (Sousa et al., p. 3) #5fb236
* *
- “resilience patterns” (Sousa et al., p. 3) #ffd400
*you need to give some examples. What do you want predict? *
- “2) Prediction System metamodel - AI part” (Sousa et al., p. 4) #2ea8e5
* *
- “Furthermore, since neural networks contain multiple components in its structure, either in a linear or non-linear order, we define clEdge and clOrdering classes to allow precise specification over the network’s structure composition.” (Sousa et al., p. 4) #5fb236
* *
- “This model is associated with a clArchitecture of a recurrent neural network composed of multiple clLayer instances, which are represented as clStructuralComponent elements.” (Sousa et al., p. 4) #5fb236
* *
- “The structural composition is further detailed using clEdge and clOrdering to capture the sequential or non-linear arrangement of components.” (Sousa et al., p. 4) #5fb236
* *
- “numerical prediction (e.g., surface area in hectares).” (Sousa et al., p. 4) #5fb236
* *
- “We define the training of the model with a clTrainingProcess, which relies on a clLossFunction (e.g., mean squared error) to guide optimization, and a clOptimizer (e.g., Adam) to update model parameters.” (Sousa et al., p. 4) #5fb236
* *
- “clHyperParameter” (Sousa et al., p. 4) #5fb236
* *
- “3) Prediction System metamodel - Dataset part:” (Sousa et al., p. 4) #2ea8e5
* *
- “Moreover, as data typically requires preprocessing and transformation before being used directly with neural networks, we support the definition of such transformations. Additionally, given that ecosystem data can be very limited for specific tasks, we also support generative transformations for data augmentation purposes.” (Sousa et al., p. 4) #5fb236
* *
- “annual surface area observations.” (Sousa et al., p. 4) #5fb236
* *
- “from high-level goals to a fully specified and generated software product.” (Sousa et al., p. 5) #5fb236
* *
- “Intent task” (Sousa et al., p. 5) #a28ae5
* *
- “Assisted Intent Recognition” (Sousa et al., p. 5) #5fb236
* *
- “Observer Elicitation” (Sousa et al., p. 5) #2ea8e5
* *
- “EcoSys model” (Sousa et al., p. 5) #5fb236
* *
- “This model serves as the semantic foundation that informs and constrains all subsequent decisions in the workflow.” (Sousa et al., p. 5) #5fb236
* *
- “Acquire and Prepare Data:” (Sousa et al., p. 5) #2ea8e5
* *
- “validating them against the requirements” (Sousa et al., p. 5) #ffd400
*How are data validated against the requirements given in the EcoSys models? *
- “Select and Configure AI” (Sousa et al., p. 5) #2ea8e5
* *
- “To support users who may not have their own datasets or AI models, the workflow is designed to be generic, modular, and interoperable. It may interface with external registries that provide curated and validated artifacts, such as model hubs or open data portals, enabling the integration of existing resources into the design process, even when user-specific artifacts are unavailable. The workflow triggers final system generation once all validated artifacts are available in a shared System State Context (SSC).” (Sousa et al., p. 5) #ffd400
*It is necessary to clarify how this model will be used. Is there any running environment to execute the specified models? Are there any code generation steps? Who is the main user of the proposed approach? What are the roles that are involved in the show process? How are they intended to collaborate? *
- “This structured approach prevents design mismatches, such as collecting incompatible data or selecting an unsuitable neural network model, by explicitly modeling dependencies between components.” (Sousa et al., p. 5) #5fb236
* *
- “Predict the yearly evolution of vegetation surface in Mersch Forest.” (Sousa et al., p. 5) #5fb236
* *
- “The ERPS metamodels (EcoSys and PredSys) are interdependent and their consistency must be managed all over the workflow.” (Sousa et al., p. 5) #5fb236
* *
- “This explicit representation prevents critical mismatches, such as defining prediction goals that remain unsupported even after preprocessing and augmentation, or selecting AI architectures misaligned with the data’s structure or semantics.” (Sousa et al., p. 5) #5fb236
* *
- “ResilForest” (Sousa et al., p. 7) #2ea8e5
* *
- “model introduces vegetation dryness as a key property.” (Sousa et al., p. 7) #5fb236
* *
- “ffective methodologies should support diverse modeling approaches, enabling not only goal-driven design but also data-driven and technologydriven exploration.” (Sousa et al., p. 7) #5fb236
* *
- “The workflow is designed to adapt and guide the user from their intent to a complete and consistent ERPS specification” (Sousa et al., p. 7) #5fb236
* *
- “Observer Elicitation” (Sousa et al., p. 7) #5fb236
* *
- “Model-Driven” (Sousa et al., p. 8) #ffd400
* *
- “”What kind of ecosystem resilience properties can I predict with this model?”” (Sousa et al., p. 8) #5fb236
* *
- “The Classify intent task within the Assisted Intent Recognition pool would classify the intent as to start the Select and Configure AI pool and the workflow execution would be:” (Sousa et al., p. 8) #ffd400
*I understand, this needs to be abstract being a workshop paper. However, the paper stays disconnected with the real execution environments and technologies. It is not clear how the presented models and processes are actually used in practice further than the given abstract specifications. *
- “2) Prediction System Modeling (PredSys)” (Sousa et al., p. 8) #ffd400
*Where are the features of interests are specified? Where the prediction goals are given? *
- “By structuring domain knowledge within the EcoSys metamodel, it provides a direct pathway for developing testable and robust predictive systems from established ecological principles.” (Sousa et al., p. 9) #a28ae5
*That's interesting and I can agree with this. *
- “from highlevel requirements to a fully specified system.” (Sousa et al., p. 10) #ffd400
*I'm missing the link with the realy system that will execute what you have specified with the proposed approach. *
pages/@Multi-Agent LLM Collaboration for Enhancing Unit Test Generation Using Repository-Aware Knowledge Graphs.md
+13
View File
@@ -0,0 +1,13 @@
tags:: [[#zotero]]
date:: 2018
title:: @Multi-Agent LLM Collaboration for Enhancing Unit Test Generation Using Repository-Aware Knowledge Graphs
item-type:: [[journalArticle]]
original-title:: Multi-Agent LLM Collaboration for Enhancing Unit Test Generation Using Repository-Aware Knowledge Graphs
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/5P5PNFFW), [Web library](https://www.zotero.org/users/1039502/items/5P5PNFFW)
- [[Abstract]]
- Recently, the emergence of Large Language Models (LLMs) has spurred a surge of research into automated unit test generation, demonstrating impressive performance and reducing manual effort. However, existing LLM-based approaches still suffer from two major limitations: (1) they rely on rule-based context extraction, which fails to capture fine-grained code dependencies, limiting LLMs’ ability to understand program semantics and derive test requirements; (2) they follow rigid, procedural workflows that underutilize the autonomous reasoning potential of LLMs, making it difficult to dynamically adapt testing strategies based on real-time feedback. In this paper, we propose TestAgent, an LLM-based test generation approach that addresses the above limitations by emulating the human testing practice via a multi-agent collaboration mechanism. Particularly, TestAgent designs three specialized agents, i.e., requirement planner, test generator, and test reviewer, to simulate how developers understand, construct, and validate unit tests. Moreover, to unleash the autonomous capabilities of LLMs, we equip TestAgent with a set of tool APIs that can be invoked dynamically by LLMs in an on-demand and adaptive manner. Furthermore, to support repository-level context retrieval and reasoning, TestAgent integrates a repository-aware knowledge graph that provides a structured representation of large-scale codebases and captures fine-grained dependency relations through graph edges. Experimental results show that TestAgent achieves 97.46% execution rate, 92.34% line coverage, 90.24% branch coverage, and 83.69% mutation score on six Java projects, significantly outperforming search-based and LLM-based baselines. We also adapt TestAgent Python projects with 88.85% line coverage and 78.89% branch coverage, demonstrating its generalizability beyond the Java ecosystem. Moreover, the results on three industrial projects and a controlled user study demonstrate the practical applicability and usability of TestAgent in real-world development scenarios.
- ### Attachments
- [PDF](zotero://select/library/items/L3AMMAVS) {{zotero-imported-file L3AMMAVS, "2018 - Multi-Agent LLM Collaboration for Enhancing Unit Test Generation Using Repository-Aware Knowledge Gr.pdf"}}
pages/@Recommending Relevant Classes for Infrequent API Classes.md
+275
View File
@@ -0,0 +1,275 @@
tags:: [[#zotero]]
date:: 2026
title:: @Recommending Relevant Classes for Infrequent API Classes
item-type:: [[journalArticle]]
original-title:: Recommending Relevant Classes for Infrequent API Classes
language:: en
authors:: [[Anonymous Author]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/9I4Q6XAZ), [Web library](https://www.zotero.org/users/1039502/items/9I4Q6XAZ)
- [[Abstract]]
- Although libraries (e.g., J2SE) provide many reusable Application Programming Interfaces (APIs) and are widely used, calling an API class often implements only simple functionalities. As there are many API classes, it is challenging to identify relevant API classes for a given API class. For frequent API classes, various mining approaches, code search engines, and LLMs can help. However, more than 80% of API classes are infrequently called in real projects. The problem is inherent and relevant. If code samples are unavailable or too few, existing approaches are ineffective.
- ### Attachments
- [PDF](zotero://select/library/items/7PARQGX2) {{zotero-imported-file 7PARQGX2, "Author - 2026 - Recommending Relevant Classes for Infrequent API Classes.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotations
(17/09/2025, 11:44:16)
- “Although libraries (e.g., J2SE) provide many reusable Application Programming Interfaces (APIs) and are widely used, calling an API class often implements only simple functionalities.” (Author, 2026, p. 1) #5fb236
- “As there are many API classes, it is challenging to identify relevant API classes for a given API class.” (Author, 2026, p. 1) #ffd400
*Bad written. Not clear.*
- “However, more than 80% of API classes are infrequently called in real projects.” (Author, 2026, p. 1) #e56eee
- “If code samples are unavailable or too few, existing approaches are ineffective.” (Author, 2026, p. 1) #e56eee
*We are referring bias issues here.*
- “APIrel, can predict relevant classes, even if such patterns do not appear in documents or source files.” (Author, 2026, p. 1) #a28ae5
- “APIrel uses mined patterns as seeds and compares API documents to build labeled data.” (Author, 2026, p. 1) #ffd400
*What is mined? When?*
- “Based on labeled data, APIrel then builds a model by observing the documents of API classes with and without patterns” (Author, 2026, p. 1) #a28ae5
- “Given the documents of two API classes, our trained model can predict whether they are relevant.” (Author, 2026, p. 1) #ffd400
*For what? What kind of documents are given as input?*
- “As introduced in Section 7,” (Author, 2026, p. 1) #ffd400
*It's a too far forward reference.*
- “inferring from documents” (Author, 2026, p. 1) #2ea8e5
- “mining from clients.” (Author, 2026, p. 1) #2ea8e5
- “As specifications define the rules of calling APIs, it is feasible to identify relevant API classes from mined specifications. However, both research lines have inherent limitations” (Author, 2026, p. 1) #ffd400
- “s.F” (Author, 2026, p. 1) #ff6666
- “a templates” (Author, 2026, p. 1) #ff6666
- “For instance, API documents rarely mention relevant API classes, especially when such classes are infrequent.” (Author, 2026, p. 1) #ffd400
*Sentences like this require some examples, they are not clear!!*
- “As a result, the prior approaches are unlikely to infer many relevant infrequent API classes from documents. The limitation is inherent.” (Author, 2026, p. 1) #ffd400
*Can you show some explanatory example?*
- “For instance, researchers use Apriori algorithms to mine the relevant libraries.” (Author, 2026, p. 1) #ffd400
*This is not clear.*
- “They report that only LibSeek [31] can recommend relevant infrequent libraries, but its effectiveness is unsatisfactory. In particular, its precision and recall are only 21.1% and 69.4% in the best scenario, and they drop to 3.1% and 0.9% in the worst scenario.” (Author, 2026, p. 1) #5fb236
- “95% of API classes are called by less than 10% of clients,” (Author, 2026, p. 1) #a28ae5
- “hiding 88% of API classes do not affect 75% of clients.” (Author, 2026, p. 1) #a28ae5
- “As most API classes are infrequent, existing approaches can work for only a small set of frequent API classes.” (Author, 2026, p. 1) #e56eee
- “APIrel. It is the first approach that infers relevant classes from documents without predefined templates.” (Author, 2026, p. 1) #ffd400
*What kind of documents? We are almost at the end of the introduction and this is not clear.*
- “Although most API classes are infrequent, it is feasible to mine some specifications from clients. We use them as the seeds to infer more rules. Although documents seldom explicitly define rules, e.g., relevant classes, API documentations provide documents for most APIs” (Author, 2026, p. 1) #ffd400
*What kind of rules are referring to?*
- “In our new direction, we mine seen API patterns from source files and use such patterns to label data” (Author, 2026, p. 1) #ffd400
*Why is this different from existing approaches?*
- “predicted relevant API class” (Author, 2026, p. 2) #ffd400
*How is the prediction done? What does the prediction, when?*
- “API” (Author, 2026, p. 2) #ffd400
- “can train a model to predict unseen patterns based on a small portion of frequent API classes” (Author, 2026, p. 2) #ffd400
*This is obscure!*
- “Given the documents of two API classes, the trained model predicts whether they are relevant.” (Author, 2026, p. 2) #ffd400
*For what?*
- “popular API classes, we conduct a tenfold cross-validation. In each fold, the training set provides API documents and the labels to train a model, and the testing set feeds API documents to the trained model. As the trained model takes only API documents as its input, it works for new API classes without any samples. The f-score values of our prediction vary from 70% to 80%.” (Author, 2026, p. 2) #ffd400
*Not clear!*
- “https://anonymous.4open.science/r/apirel.” (Author, 2026, p. 2) #ffd400
*Tried to visit the link but the following message is obtained while trying to access the content:
"The requested file is not found."*
- “2 ILLUSTRATING EXAMPLE” (Author, 2026, p. 2) #ffd400
*The paper should be improved by clearly distinguishing the presentation of the problem to be solved and the proposed solution. These are mixed in many parts of the paper, which is not effective in presenting the problem and the limitations of existing approaches. Unfortunately, the motivation part of the paper relies on some examples based on the SearchCode system, which seems is no longer active and online.*
- “the document of HSSFWorkbook.” (Author, 2026, p. 2) #ffd400
*The document?*
- “From the clients” (Author, 2026, p. 2) #ffd400
*What's the client you are referring to?*
- “HSSFSheet is frequently called with HSSFWorkbook.” (Author, 2026, p. 2) #ffd400
*How can you see that from Fig. 1?*
- ““See Also” titles often ignore many relevant APIs, since it takes too much effort to manually write all of them.” (Author, 2026, p. 2) #5fb236
- “Many mined relevant classes are not defined in documents” (Author, 2026, p. 2) #a28ae5
- “Using these instances as its training data, APIrel builds a classification model that can predict unseen API patterns.” (Author, 2026, p. 2) #5fb236
- “prior approaches” (Author, 2026, p. 2) #ffd400
*which one?*
- “As a comparison, the prior approaches can mine relevant classes only for frequent APIs. In Section 4, we split the labeled instances into ten groups. In each fold, we use nine groups to train our model, and use the remaining group to test our model. We switch the testing group, and test our model for all possible labels. The results show that APIrel achieves around 70% f-score values even if it infers from only documents. APIrel can infe” (Author, 2026, p. 2) #ffd400
*This is something related to the evaluation. WHy mentioning here at section 2 of the paper when the details of the approach are not given yet?*
- “it infers that HSSFBorderFormatting and HSSFWorkbook are relevant” (Author, 2026, p. 2) #ffd400
*with respect to what? How relevance is assessed?
How is relevance defined?*
- “SearchCode” (Author, 2026, p. 2) #ffd400
*No longer available.*
- “Although the two API classes are relevant, the prior approaches are unlikely to infer this pattern since its code samples are too few.” (Author, 2026, p. 2) #ffd400
- “It is infeasible for the prior approaches to mine patterns from only one observation.” (Author, 2026, p. 2) #5fb236
- “Table 3 s” (Author, 2026, p. 2) #ffd400
*It should be Table 1*
- “To handle the problem, from each code sample of a library, our tool extracts all its called API classes and methods, and removes samples whose called classes or methods are not declared by the latest versions.” (Author, 2026, p. 2) #ffd400
*When it extracts? What does it mean?*
- “A small set of API classes are intensively called by most clients, while most API classes are used by less than 10% of clients. Based on the findings, a learning-based approach can work for only a few critical frequent APIs.” (Author, 2026, p. 3) #5fb236
- “However, if we use the mined patterns as labels, we can train models that work for many more APIs” (Author, 2026, p. 3) #ffd400
*This is not clear!*
- “Definition 1. The relevant API classes of an API class are classes that can be called together to implement functionalities.” (Author, 2026, p. 3) #ffd400
*What does it mean "called together"? What does it mean call a class?*
- “As infrequent APIs have documents, it is feasible to infer relevant classes for infrequent APIs.” (Author, 2026, p. 3) #ffd400
*What does it mean that infrequent APIs have documents? Also the second part of the sentence is not clear to me.*
- “To infer hidden patterns, we reduce the inference of infrequent relevant API classes into a classification problem. For example, taking the documents of two classes (d1 and d2) as inputs, a solution to our problem is to train a model, f (d1, d2) ⇝ l, that predicts whether d1 and d2 are relevant. After paired API classes are predicted, they can be merged into larger sets” (Author, 2026, p. 3) #ffd400
*Paragraphs like this require some explanatory example. It's not clear what do you  want to do in practice here.*
- “As API documents seldom mention relevant classes, it is quite challenging to construct the labels from documents.” (Author, 2026, p. 3) #ffd400
- “To handle the problem, we use mined patterns as the gold standard, and propose a new research direction that infers unknown knowledge from known knowledge.” (Author, 2026, p. 3) #ffd400
*mmmmmm can you give some examples? This is very vague!*
- “, our tool uses its full name to build the query.” (Author, 2026, p. 3) #ffd400
*"Our tool" which tool, when is the query created? How is the tool supposed to be installed/used/....
The paper requires a serious revision to improve the presentation and the writing in general.*
- “PPA [19] is a library for analyzing partial code, and we build APIrel on PPA. After the trees are built, APIrel traverses them to collect the called API classes of each method. Our tool collects the full list of API classes for each library. For each method, APIrel extracts its directly dependent API classes (e.g., API classes in cast expressions), and its indirectly dependent API classes (e.g., resolving the types of variables). APIrel merges the two sets of classes to build the used API classes of a method.” (Author, 2026, p. 3) #ffd400
*I think some parts of the paper can be reduced to gain some space to be used for presenting some examples to explain technical sentences like these ones.*
- “Table 2: Our features” (Author, 2026, p. 4) #ffd400
*It should be moved to sec 3.*
- “A transaction database, T DB, is a set of transactions. Given a transaction database T DB, the support of an itemset X , denoted as sup (X ), is the number of transactions in T DB that contain X . An itemset X is a closed itemset, if there exists no itemset X ′ such that (1) X ′ is a proper superset of X , and (2) if a transaction contains X , it also contains X ′.” (Author, 2026, p. 4) #ffd400
*Example is needed otherwise this is unreadable.*
- “itemset contains the API classes that are frequently called in a method.” (Author, 2026, p. 4) #e56eee
- “APIrel mines that CellStyle, HSSFSheet, and HSSFWorkbook are frequently called in a method. Many API classes are less popular and do not appear in collected source files. As Yen et al. [70] mine frequent itemsets, their approach cannot mine unseen relevant API classes, and their mined API patterns cover only a small set of API classes.” (Author, 2026, p. 4) #ffd400
*OK, I can start from this. The rest is still obscure to me. I hope the next sections clarify.*
- “comparing mined API patterns with API documents (Section 3.3.1), and trains a classification model” (Author, 2026, p. 4) #5fb236
- “3.3.1 Extracting positive and negative instances” (Author, 2026, p. 4) #2ea8e5
- “Line 1 builds a dictionary from mined patterns. This dictionary contains all the API classes that appear in SET .” (Author, 2026, p. 4) #ffd400
*Can you make some concrete examples by referring to the running motivating example?*
- “Line 6 checks whether the c1 and c2 classes appear in our dictionary. If one of them does not appear in the dictionary, we conclude that their patterns cannot be observed from the mined API patterns.” (Author, 2026, p. 4) #ffd400
*This step requires more elaboration by referring to the motivating example shown in Figure 1.*
- “Feature 1. The number of overlapped verbs and nouns in class descriptions.” (Author, 2026, p. 4) #2ea8e5
- “Feature 2. The frequencies of class names.” (Author, 2026, p. 4) #2ea8e5
- “Feature 3. The distance between two classes in their super types.” (Author, 2026, p. 4) #2ea8e5
- “Feature 4. The number of overlapped interfaces.” (Author, 2026, p. 4) #2ea8e5
- “Feature 5. The number of overlapped subclasses.” (Author, 2026, p. 4) #2ea8e5
- “Feature 6. The number of overlapped references.” (Author, 2026, p. 4) #2ea8e5
- “Feature 7. The number of fields whose type is the other class.” (Author, 2026, p. 5) #2ea8e5
- “Feature 8. The links of method parameters.” (Author, 2026, p. 5) #2ea8e5
- “Feature 9. The number of methods whose return type is the other class.” (Author, 2026, p. 5) #2ea8e5
- “Feature 10. The frequencies of the other class name in a method description.” (Author, 2026, p. 5) #2ea8e5
- “Feature 11. The frequencies of the other class name in the thrown exceptions from the methods of a class.” (Author, 2026, p. 5) #2ea8e5
- “Feature 12. The number of methods that refer to the other class.” (Author, 2026, p. 5) #2ea8e5
- “Feature 13. The number of methods that are specified in the other class.” (Author, 2026, p. 5) #2ea8e5
- “Feature 14. The links of constructor parameters.” (Author, 2026, p. 5) #2ea8e5
- “4 EVALUATION ON CORRECTNESS This section explores the he following RQs: (RQ1) How accurate are our approach (Section 4.3)? (RQ2) What are the key features (Section 4.4)? (RQ3) What is the impact of labels (Section 4.5)?” (Author, 2026, p. 6) #ffd400
*The main problem that I had so far with the previous section is about presentation. The paper is not effective in presenting the problems and the solution. Many sentences are unclear and I had to go through them to try catching the meaning or the technical details that should be made explicit by referring for instance to a running example.
Let's see if the Evaluation improves the situation.....*
- “API documents in Table 3” (Author, 2026, p. 6) #ffd400
*This is not clear. Table 3 list the same labries listed in table 4 and does not include API documents.*
- “All the libraries are shipped with their API documents.” (Author, 2026, p. 6) #5fb236
- “The repository of SearchCode has millions of projects. By default, SearchCode retrieves 100 samples per page. Each sample is a source file that calls the queried API. For some popular API classes, it retrieves thousands of pages. As it is impractical to download all samples, we limit the analysis scope of our tool to the top 20 pages, i.e., the top 2,000 samples per API class.” (Author, 2026, p. 6) #ffd400
*What's the role of SeachCode in this paragraph*
- “4.2 No Baseline Statement” (Author, 2026, p. 6) #ffd400
*This seems to be an appendix of the related work section, why not merging this with the related work section and move after the introduction by extending with some motivating examples clearly presenting all the different concepts and motivating the paper?*
- “As introduced in Section 7,” (Author, 2026, p. 6) #ffd400
*Since it is referred many times in previous sections, why not moving section 7 after the introduction section.*
- “The first line of approaches analyzes documents with templates. As documents rarely mention relevant classes, these approaches may not infer many relevant classes. We do not compare with them since the improvement is explicit. The second line of approaches mines relevant classes from clients.” (Author, 2026, p. 6) #ffd400
*The distinction between document analysis and clients should make more clear by means of some explanatory examples.*
- “The accuracy” (Author, 2026, p. 7) #ffd400
*it's not clear what this accuracy is about. Is it on the capability of the approach of detecting relevant classes? I think human in the loop should be considered.*
- “Predicting more complicated infrequent API patterns” (Author, 2026, p. 9) #5fb236
- “To improve the completeness of API patterns, in this paper, we propose a new direction for inferring infrequent API patterns.” (Author, 2026, p. 10) #5fb236
- “Our basic idea is to learn a model from API documents and already mined frequent patterns. Mimicking how programmers infer from documents, we proposed APIrel to infer relevant API classes for long-tail and new APIs.” (Author, 2026, p. 10) #5fb236
- “We evaluated APIrel on five popular libraries. Our results show that our predicted unseen relevant classes are reasonably accurate (fscores around 80%). Based on our positive results, our new direction has the potential to be extended for predicting more complicated API patterns.” (Author, 2026, p. 10) #ffd400
*I think it is necessary to revise the evaluation by involving developers!*
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?
pages/@SRC-Retrieval%3A Semantic-Based GitHub Repository and Code Retrieval.md
+243
View File
@@ -0,0 +1,243 @@
tags:: [[#zotero]]
title:: @SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval
item-type:: [[document]]
original-title:: SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval
links:: [Local library](zotero://select/library/items/NH39F2BD), [Web library](https://www.zotero.org/users/1039502/items/NH39F2BD)
- ### Attachments
- [PDF](zotero://select/library/items/MWXK9CXR) {{zotero-imported-file MWXK9CXR, "icse2026-paper3125.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotations
(16/09/2025, 16:05:09)
- “Semantic-Based” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #5fb236
- “existing search methods on GitHub and general search engines like Bing often fail to capture the semantic intent behind developers' queries, so the retrieved repositories may not satisfy developers’ requirements.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #a28ae5
- “Moreover, the search results of current methods are at the repository level rather than at the level of individual code ;iles, making it challenging for beginners to locate speci;ic code implementations.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #ffd400
*Do you actually need to do so via existing search engines like Bing when we have the availability of advanced technologies like ChatGPT and Copilot?*
- “high-level functional requirements and concrete code implementations.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #a28ae5
- “A transformer-based retrieval model leverages text embeddings to recommend not only relevant repositories but also speci;ic code ;iles aligned with the user’s intended functionalities” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #5fb236
- “A common use case involves searching for repositories that implement specific functionalities, such as “user authentication” or “data visualization”, to serve as references for their own software projects.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #5fb236
- “GitHub’s search mainly relies on keyword matching, which often fails to capture the semantic intent behind developers’ queries.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #5fb236
- “While general-purpose search engines offer alternative solutions [1], they also typically lack a nuanced understanding of the semantic relationship between queries and repositories, often returning broad and imprecise results.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #e56eee
- “As a result, even when developers find a relevant repository, locating the exact code snippets they need can be difficult, especially for those who are new to programming.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #ffd400
- “we propose SRC-Retrieval, a GitHub repository and code retrieval method that semantically aligns developers’ functional requirements with relevant repositories and specific code files.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #ffd400
*Intersting to see later, what do the author mean with semantic alignment and the corresponding granularity.*
- “Text embeddings are leveraged to represent both user queries and repositories, as they effectively capture contextual and semantic information and have been widely applied in various tasks such as semantic search, question answering, and document classification” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 1) #a28ae5
- “code search is an important research topic in software engineering.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #5fb236
- “Large Language Models (LLMs) may generate code containing hallucinations, which can mislead beginners lacking the expertise to assess correctness. Based on these considerations and supported by our experimental results, we adopt transformer-based encoders for embedding generation.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #a28ae5
*This is a good point!*
- “Unlike existing tools that primarily recommend repositories, our approach identifies specific code files within repositories that directly implement the queried functionality, providing beginners with coding references.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #a28ae5
- “We propose a semantic retrieval method that aligns user queries with repository functionalities.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #ffd400
*"repository functionality" is a good point, even though tricky to mange and sustain. I guess it is based on README information, isn't it?
Let's go ahead with the reading and let's see.*
- “BERT-based model to link functional requirements to specific code files” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #ffd400
*How functional requirements are defined? Are they automatically created from README files? What else? Who create such links?*
- “To the best of our knowledge, this is the first approach to semantically match user requirement to both repositories and source code files, providing practical references for software development” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #ffd400
*I think so, even though the created of the training data is crucial here! Not clear yet how the dataset has been created.*
- “Experimental results of 3 tasks demonstrate that our method consistently outperforms the baseline methods in metrics such as precision, recall, MRR and repository and code success rate.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #5fb236
- “open-source software repository retrieval and recommendation” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #2ea8e5
- “API recommendation” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #2ea8e5
- “requirementto-code traceability link recovery” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #2ea8e5
- “their” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 2) #ff6666
*the*
- “While API recommendation provides more fine-grained assistance than repository-level retrieval or recommendation, developers searching for references on implementing specific functionalities often require concrete code examples to understand how these functionalities are implemented in practice.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #ffd400
*These two options are not exclusive. API recommendation is still valid even when developers have found a reference GitHub repository.*
- “This paper solves this problem by proposing a method for recommending specific code files that directly demonstrate the implementations of desired functionalities.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #ffd400
*See my previous comment. I would smooth this point.*
- “a technique that automatically refines coarsegrained requirement-to-class traces into method-level links.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #5fb236
- “On GitHub, issues often contain valuable descriptions of desired functionalities, effectively serving as high-level requirements that developers aim to implement. As such, they are well-suited for application of traceability link recovery techniques.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #5fb236
- “While existing methods like BTLink and PromptLink focus on linking issues to commits, they fall short of establishing direct connections between issues and the corresponding code files” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #5fb236
- “In this paper, we propose a novel model that extends existing methods by identifying issues that represent specific functionalities and mapping them directly to relevant code files.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #a28ae5
- “Then, functionalities are extracted from the README files and issues of the repositories” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #5fb236
- “Figure 1: The architecture of the GitHub repository and code retrieval method” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 3) #ffd400
*The link creation between Issue and code is more intuitive than that between readme and code. The latter seems to be more coarse grained. Not enought details are available to link specific parts of the code base with a functionality description that should be in the readme file.*
- “collect all other repositories starred by that user.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #ffd400
- “their starred repositories are likely related to software development as well.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #ffd400
*what kind of relation do you expect? What do you want to do with such a relation?*
- “we apply a filtering criterion that remains only repositories with at least 150 stars. This results in a refined dataset comprising over 180,000 repositories.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #5fb236
- “we identify and select 40,133 repositories tagged with the top 50 most frequently used topics, ensuring that our dataset reflects both emerging trends and well-established areas within the software development ecosystem.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #5fb236
- “In this section, we present our approach to extracting functionalities from GitHub repositories.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #5fb236
- “identify feature request entries,” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #ffd400
*So, you considered only closed issues. But in some cases it can be that the issues is closed not because the functionality has been actually implemented, but because it is no longer interesting to implement, or something similar.*
- “3.2.1 Functionalities in README Files.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #2ea8e5
- “repository descriptions inherently reflect a repository’s functionalities.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #a28ae5
- “Therefore, we use repository descriptions to identify functionalities in README files.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #ffd400
*This step is not clear at all!*
- “For negative samples, we randomly select sentences from README files that do not match any predefined requirement patterns.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 4) #ffd400
*This is also unclear!*
- “s[” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 5) #ff6666
*missing space*
- “improve the accuracy of functionality extraction from README files, by capturing the semantic relationships between the text and the repository’s intended functionalities.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 5) #ffd400
*Since readme files and repository descriptions play a key role in the model training phase, does it make sense to impose come constraints on the length or structure of README files and/or repository descriptions?*
- “After training, the classifier is applied to the candidate sentences, resulting in the extraction of 570,978 functionalities from README files.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 5) #ffd400
*To make things clear, it would be great to have a representative example of README file and corresponding text with the retrieved functionalities. Currently such a mapping is vague.*
- “3.2.2 Functionalities in Issues.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 5) #2ea8e5
- “2. A feature request issue must be marked as “closed” with the status “completed”. On GitHub, when closing an issue, collaborators can categorize it as “completed”, “not planned” or “duplicate”, with “close as completed” being the default option. In contrast, an open issue indicates that the feature hasn’t yet been implemented in the repository.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 5) #5fb236
- “In some cases, although an issue may not be explicitly linked to a commit, contributors may confirm that the feature has been accepted by the issue’s comments.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 5) #ffd400
*how frequent is this case. How many of this case have you managed during the data preparation phase?*
- “To automate this verification process, we train a classifier to assess whether a feature request issue has been accepted, based on the comments provided by the contributors. This classifier helps ensure that only genuinely accepted and implemented feature requests are considered as functionalities of the repository.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 5) #ffd400
*does it introduce some bias in the data creation phase? I'm not sure about this automation step.*
- “We fine-tune a BERT-based classifier on this dataset, enabling the model to learn to distinguish between accepted and rejected feature requests.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #5fb236
- “After training, the classifier is applied to feature request issues that are marked as “closed” with the status “completed”, identifying 350,413 issues as accepted. These accepted issues, along with the 22,270 issues that are directly linked to milestones or commits, are considered as valid functionalities in the repositories. To represent these functionalities, we use the titles of the issues, as they concisely express the main functionality described in the issue.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #ffd400
*The creation of the dataset by means of the classifier, can introduce some noise. Have you investigated the effects of not correctly classified issues to the creation phase of the dataset?*
- “specific code files that are likely to implement those requirements.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #a28ae5
- “establish direct links between the extracted functionalities and the concrete code files within each repository, which enables developers to not only discover repositories that align with their requirements but also quickly pinpoint the precise code files that serve as useful references for their own implementations” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #5fb236
- “GitHub issues are more closely related to implementation than README files, as commits that implement features often reference the original issues requesting those features.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #ffd400
*It is necessary to add such a clarification early in the paper. In the previous section, README files and issues are considered similar for the sake of functionality characterization of repositories.*
- “identify connections between feature request issues and the specific code files that implement the requested functionalities.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #5fb236
- “issuecommit pairs” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #5fb236
- “To construct negative samples, we randomly select commits that do not reference any issue in the positive set.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #5fb236
- “ce 8” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #ff6666
- “the classifier is applied to identify issuecommit links within repositories.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #5fb236
- “However, a single commit may address multiple features, making it inappropriate to assume that all modified code files are relevant to the linked issue.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #e56eee
- “design a secondary classifier to determine whether a specific code file implements the feature described in a given issue.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 6) #ffd400
*Another classifier? Too many and their impact/contribution to the whole process is not discussed at this stage, See my previous comments on the effect of the error propagation through the whole process.*
- ““You are a data tagger who needs to read a GitHub issue describing a specific feature and a code file to decide whether the code is related to the issue, meaning the code implements (or partially implements) the feature. Use 1 for related and 0 for not” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #a28ae5
- “e resulting labeled dataset is then used to finetune a BERT-based classifier, further improving the model's ability to accurately link issues to relevant code files.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #ffd400
*I would improve figure 4 to make more explicit the different steps including a graphical representation of the process constructing the different datasets.*
- “source code features of a code file as the concatenation of method names, class names, variable names, and comments found within the code.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #5fb236
- “For each issue-code pair in the dataset, the issue text and the extracted source code features are concatenated, and the combined sequence is tokenized into individual tokens.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #5fb236
- “To optimize model performance, we use Cross Entropy as the loss function to train the model, with the Adam optimizer employed for optimization. The learning rate is set to 1 × 10!" to ensure stable and effective convergence. The model is based on the bert-base-uncased varian” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #ffd400
*This has been repeated four times. It's better to say once and refer the different steps where such an optimization has been operated.*
- “After fine-tuning, this model is applied to all issue-code pairs to identify the links between issues and the corresponding code files that implement them. This approach allows us to efficiently establish the relevant connections between issues and the code that addresses them, helping developers quickly locate the most relevant code files for specific functionalities.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #ffd400
*Repeated.*
- “We randomly select 1,000 README functionalities from different repositories and pair them with relevant code files from the same repository, resulting in a dataset of 48,107 functionality-code pairs.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #ffd400
*The granularity of README files vs functionality vs code is questionable. Not convincing at this stage.*
- “Use 1 for related and 0 for not.” The model temperature is set to zero.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #5fb236
- “dataset generated by DeepSeek is then used to fine-tune a BERT model, enhancing its ability to accurately capture the relationships between high-level README functionalities and the code that implements them.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #ffd400
*This is not clear. A README file can be linked to several lines of code and potentially to the entire repository. This kind of link is not clear to me.*
- “For every README functionalitycode file pair in the dataset, the README functionality and the extracted code features are concatenated and tokenized into individual tokens. Following the BERT architecture, special tokens [CLS] and [SEP] are added at the beginning and end of the token sequence, respectively. The tokenized sequence is passed through the encoding layer, and the resulting embeddings are fed into a fully connected layer followed by a sigmoid layer for classification. Cross Entropy is used as the loss function during training, and the Adam optimizer is applied to optimize the model. The learning rate is set to 1 × 10!" to ensure stable and effective convergence. The model is based on the bert-base-uncased variant from Hugging Face and is implemented using PyTorch.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #ffd400
*Again, this is repeated many times.*
- “To enable efficient and accurate search, we use the Software Entity Recognition (SER) model proposed by Nguyen et al. [39] to identify software entities in the extracted functionalities. Additionally, we use Sentence-BERT [40] to generate embeddings for all the functionalities.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #5fb236
- “We then match the software entities against those in the functionality dataset and calculate the cosine similarity between the query embedding and all functionality embeddings in the database” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 7) #5fb236
- “This hierarchical fusion approach ensures that the top 20 most relevant functionalities are ranked and returned.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 8) #5fb236
- “specifying their software requirements, and the tool will retrieve the top 20 related repositories, along with the corresponding code files that implement the requested functionalities for reference” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 8) #a28ae5
- “This paper presents a GitHub repository and code retrieval method that extracts functionalities from GitHub repositories, establishes links between these functionalities and the corresponding code files, and retrieves repositories and code files based on user queries” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 8) #ffd400
*This paragraph is not needed at this stage. You have already said what the paper is about. In any case, you are not presenting a GitHub repository in the end, isn't it?*
- “RQ1: How effective is our method in extracting functionalities from README files and issues to support the functionality extraction component of the method?” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 8) #ffd400
*I'm curious to see the contribution of README files in the overall process. An ablation study would help here. I'm not convinced that README files contribute in a significant manner.*
- “two baseline models for comparison.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 8) #ffd400
*The considered baselins are not appropriate in my opinion. Authors should compare the proposed approach with technologies like Copilot or alike.
Moreover, it's not clear how the two baselines have been applied and compared with the proposed approach. 
How have you validated that the lines of code that have been retrieved starting for user requests are correctly retrieved and meet the user requirements?*
- “Keyword-Driven Hierarchical Classification of GitHub Repositories,” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 11) #5fb236
- “[3] Y. Zhang, D. Lo, P. S. Kochhar, X. Xia, Q. Li, and J. Sun, “Detecting similar repositories on GitHub,” in 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), Feb. 2017, pp. 13–23. doi: 10.1109/SANER.2017.7884605.” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 11) #5fb236
- “Approaching code search for python as a translation retrieval problem with dual encoders,” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 11) #ffd400
*This might be a related work to compare with, isn't it?*
- “Information Retrieval Approaches Applied to Requirements Trace Recovery,” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 11) #5fb236
- “TraceRefiner: An Automated Technique for Refining Coarse-Grained Requirement-toClass Traces,” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 11) #5fb236
- “Extracting Requirements Patterns from Software Repositories” (“SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval”, p. 11) #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?
pages/@Senate%3A Policy-Driven Change Management in Model-Based Systems Engineering.md
+234
View File
@@ -0,0 +1,234 @@
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](zotero://select/library/items/2G6WZQPU), [Web library](https://www.zotero.org/users/1039502/items/2G6WZQPU)
- [[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://select/library/items/IC97Z8ZT) {{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?
pages/@TOSEM-2025-0885.md
+179
View File
@@ -0,0 +1,179 @@
tags:: [[#zotero]]
title:: @TOSEM-2025-0885
item-type:: [[webpage]]
access-date:: 2025-11-04T21:29:58Z
original-title:: TOSEM-2025-0885
url:: https://mc.manuscriptcentral.com/tosem?DOWNLOAD=TRUE&PARAMS=xik_A6HrXFapMx4UPvbFpZJ9Bp5ACAjbXJdr8Tqfj7rfGcRb16MAr5sRcLvKm8uq1i5BLxiFUmZ4tUsb1gnpp7UZSr1qnv6jF4uSH4doDZxpnmVjPXPSJe6oq5tkRc58UdNCqRhqHhxfSeS2exS5FTRbqhGHMLaFJTMkkifhr7VAsSnpHEWH7XSggqbRqZxcnDjBp619F
links:: [Local library](zotero://select/library/items/DZ4BAU9Y), [Web library](https://www.zotero.org/users/1039502/items/DZ4BAU9Y)
- ### Attachments
- [PDF](https://mc.manuscriptcentral.com/tosem?DOWNLOAD=TRUE&PARAMS=xik_A6HrXFapMx4UPvbFpZJ9Bp5ACAjbXJdr8Tqfj7rfGcRb16MAr5sRcLvKm8uq1i5BLxiFUmZ4tUsb1gnpp7UZSr1qnv6jF4uSH4doDZxpnmVjPXPSJe6oq5tkRc58UdNCqRhqHhxfSeS2exS5FTRbqhGHMLaFJTMkkifhr7VAsSnpHEWH7XSggqbRqZxcnDjBp619F) {{zotero-imported-file Y7963XLS, "TOSEM-2025-0885.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(18/11/2025, 06:59:04)
“Visual Impairments w” (“TOSEM-2025-0885”, p. 1)
“visual impairments” (“TOSEM-2025-0885”, p. 2)
“review on how MDE addresses accessibility for vision impairments.” (“TOSEM-2025-0885”, p. 2)
“30 primary studies met the inclusion criteria.” (“TOSEM-2025-0885”, p. 2)
“we report the results of a Systematic Literature Review (SLR) to identify the current state-of-the-art of addressing accessibility needs with MDE based on the concrete example of vision impairments.” (“TOSEM-2025-0885”, p. 3)
“To give an example from practice: When selecting the menu for lunch or reading a bus schedule, users with low vision or blind users have specific requirements for the technical applications used, e.g., showing larger text sizes and having more contrast for people with low vision or enabling the reading of texts with screen readers for blind users.” (“TOSEM-2025-0885”, p. 3)
“engineering of socio-technical systems” (“TOSEM-2025-0885”, p. 3)
“For people with visual impairments, inclusive GUIs facilitate equal access to information, promote independence, and social inclusion.” (“TOSEM-2025-0885”, p. 3)
“Accessibility as a non-functional requirement, however, is challenging to realize in a software system because its effects are widespread across the entire system” (“TOSEM-2025-0885”, p. 3)
“On top of MDE [24], low-code development platforms have moved MDE from research to practice, providing methods for supporting additional stakeholder groups [5, 23]. Even though” (“TOSEM-2025-0885”, p. 3)
“how is it used to improve applications for visually impaired users?” (“TOSEM-2025-0885”, p. 3)
“arch focused on visual impairments only.” (“TOSEM-2025-0885”, p. 4)
“The objective of this research is to identify those studies that address a combination of both, or more specifically, the design and implementation of software systems that address the needs of people with visual impairments using MDE methods.” (“TOSEM-2025-0885”, p. 5)
“evaluation of the capabilities of approaches to capture accessibility (visual impairment) needs,” (“TOSEM-2025-0885”, p. 6) I expect to see some precise definition of visual impairment
“advantages offered by the model-driven development of accessible software?” (“TOSEM-2025-0885”, p. 6)
“disadvantages in the context of model-driven development of accessible software?” (“TOSEM-2025-0885”, p. 6)
“Which trends exist” (“TOSEM-2025-0885”, p. 7)
“What visual impairments” (“TOSEM-2025-0885”, p. 7)
“How” (“TOSEM-2025-0885”, p. 7)
“work” (“TOSEM-2025-0885”, p. 7)
“How” (“TOSEM-2025-0885”, p. 7)
“evaluated” (“TOSEM-2025-0885”, p. 7)
“challenges” (“TOSEM-2025-0885”, p. 7)
“3.4 Study Selection Procedure” (“TOSEM-2025-0885”, p. 8)
“The search query was tested and refined with a series of pilot runs” (“TOSEM-2025-0885”, p. 8)
“Table 1. Quality Assessment (QA) scoring system” (“TOSEM-2025-0885”, p. 9) I guess such quality critiera have been defined by the authors and not inherited from other existing works. In this respect, I would spend just a dedicated paragraph to explain how they have been defined. If a structured process was followed by the authors.
“Our initial literature search was performed in February 2023 and repeated in January 2024 and we performed an additional forward snowballing in October 2025” (“TOSEM-2025-0885”, p. 9) Mmmm this is suspicious. It means that the paper has been resubmitted several time, nothing wrong. Just saying that it's probable that the paper has been subject of different revisions.
“Research into MDE approaches that address visual impairment needs started late, trends downward, and has yielded a low output to date.” (“TOSEM-2025-0885”, p. 11) Why is it important to know? The fact the interest around the topic has decreased over the year, what does it mean? Is it an indication of something? is it because the problem is difficult to be addressed with MDE technologies? is it because if completely out of scope for MDE, what else? Having only these numbers is not relevant to me. Some qualitative discussion is needed in my opinion.
“The impact in the MDE community to date is low. None of the selected studies appeared in a high ranked MDE venue. Generally low citation counts indicate that most of the studies did not create interest beyond a small community of collaborating author.” (“TOSEM-2025-0885”, p. 12) Why? Then? See my previous comment.
“bstract nature of these keywords indicates that - just like the other 24 studies - these 6 primary studies do not consider the true nature and complexities of visual impairments in detail. Finally only one study (S17) provides basic definitions for common visual impairments” (“TOSEM-2025-0885”, p. 13)
“The large majority of studies provides generic approaches improving accessibility without studying human-centric aspects of visual impairments in detail. We argue in favor of considering accessibility and in the concrete context of this SLR, visual impairments, as first-class citizens and consider them beyond the technical domain when addressing it.” (“TOSEM-2025-0885”, p. 13)
“Most primary studies consider different functional roles to represent anticipated users of their MDE-based approach, and identify beneficiaries of improved accessibility. However, they often overlook or briefly address the specific needs of these audiences, neglecting the human and social aspects of socio-technical systems. This shortcoming may hinder understanding of how effectively the tools address accessibility needs or whether they tackle real-world accessibility issues.” (“TOSEM-2025-0885”, p. 14) What's the usage of modeling techniques and tools in the MDE-based approaches that have been analyzed?
“accessibility challenges” (“TOSEM-2025-0885”, p. 15) What does it mean in practive? What do the author expect by using MDE for deising and impleenting software that mitigate visual impariment issues? it is important to clarify what is the ideal usage of MDE (if any) that authors expected to see.
“(see Figure 4),” (“TOSEM-2025-0885”, p. 15) This figure is too far, it's page 29, whereas it is referred in the text the first time at page 15.
“urprisingly, none of the DSLs modeled accessibility aspects explicitly, but rather focused on the basic structure of user interfaces.” (“TOSEM-2025-0885”, p. 19)
“these solutions are not reusable for other MDE projects as the detailed accessibility requirements, modeling requirements and adaptation rules are provided by giving some examples only.” (“TOSEM-2025-0885”, p. 20) What does it mean reusable solutions for the considered problem that is very specific to the particular case/application/context/user, isn't it?
“accessibility guidelines should be validated and tested” (“TOSEM-2025-0885”, p. 21) How? What would you exect?
“Lack of awareness and attention by developers as well as insufficient tools and methods are the most frequently used aspects to motivate research work.” (“TOSEM-2025-0885”, p. 23)
“Only one [6] of 30 studies took a human-centric approach and motivated the presented research with real-world impact for disadvantaged people.” (“TOSEM-2025-0885”, p. 23)
“Only one study directly aimed to help disadvantaged users, and just two considered the needs of visually impaired users” (“TOSEM-2025-0885”, p. 23)
“By creating high-level abstractions of software, these methods provide a comprehensive way to address accessibility requirements while reducing complexity.” (“TOSEM-2025-0885”, p. 23) This is not obvious. We might reduce the development complexity by means of MDE methods. However, the link with accessibility requirements is not direct.
“The most common are limited evaluation and scope,” (“TOSEM-2025-0885”, p. 25)
“ack of real-user testing,” (“TOSEM-2025-0885”, p. 25)
“low applicability to real-world projects.” (“TOSEM-2025-0885”, p. 25)
“(1) Introducing accessibility:” (“TOSEM-2025-0885”, p. 25)
“incorporation of accessibility features into the user interface” (“TOSEM-2025-0885”, p. 25)
“(2) Improving accessibility coverage” (“TOSEM-2025-0885”, p. 25)
“(3) Technical / maintenance challenges” (“TOSEM-2025-0885”, p. 25)
“benefits of concepts and methodologies for the model-based development of accessible applications.” (“TOSEM-2025-0885”, p. 25)
“The large majority of studies focused on open gaps and challenges from the accessibility perspective, not from the MDE perspective. We see this focus as one of the reasons why none of the primary studies were published at main MDE venues” (“TOSEM-2025-0885”, p. 26) I can understand this.
“analysis of the 30 selected primary studies reveals several shortcomings and areas where further research is needed.” (“TOSEM-2025-0885”, p. 26)
“While the reviewed studies offer valuable insights and innovative methodologies, certain limitations and ambiguities in their approaches restrict reproducibility and broader applicability to related use cases.” (“TOSEM-2025-0885”, p. 26)
“By addressing the identified issues and building on existing methodologies, future research can contribute to more robust, transparent, and generalizable solutions.” (“TOSEM-2025-0885”, p. 26) There are many sentences like this that is vague, too abstract and not to the point. Robust with respect what? Whta aspect is requiring transparency?
“diverse ßhuman” (“TOSEM-2025-0885”, p. 27)
“Limitation 2: High-level Description of Approaches. A significant number of studies (S4, S10, S15, S18, S20, S21, S28, S27)” (“TOSEM-2025-0885”, p. 27)
“Limitation 3: Generalisability and Reproducibility of Approaches.” (“TOSEM-2025-0885”, p. 27)
“Limitation 1: Measuring Achieved Accessibility.” (“TOSEM-2025-0885”, p. 27)
“Limitation 4: Evaluation with Key Target User Groups.” (“TOSEM-2025-0885”, p. 27)
“The studies often either discuss the benefits for the user (e.g. enhanced user experience) or the benefits for the developer (e.g. higher efficiency during development).” (“TOSEM-2025-0885”, p. 27)
“Limitation 5: Lack of MDE Details and Reusability.” (“TOSEM-2025-0885”, p. 27)
“Evaluate guideline coverage for vision-related needs and include visually impaired participants early in the development” (“TOSEM-2025-0885”, p. 28)
“Limitation 6: Accessibility as a Prerequisite Competence. T” (“TOSEM-2025-0885”, p. 28)
“Although the presented approaches include many automation aspects, all of them still rely highly on the developer to provide accessibility expertise” (“TOSEM-2025-0885”, p. 28)
“automation of accessibility related tasks in the development process” (“TOSEM-2025-0885”, p. 28) What do you mean? It's not clear on how this can be possible, considering that are several impairement situations, cases etc. Addressing all the them automatically by means of some MDE approach is not clear,.
“Limitation 7: Coverage of Accessibility Needs and Guidelines.” (“TOSEM-2025-0885”, p. 28)
“Integrate visual impairment requirements with generic requirements.” (“TOSEM-2025-0885”, p. 28)
“Map visual impairment requirements to commonly used requirements modeling approaches” (“TOSEM-2025-0885”, p. 28)
“Reuse design models” (“TOSEM-2025-0885”, p. 29) The reuse aspects are mentioned in several parts of the paper, even though it is not clear to what extent this is possible. As mentioned in one of my comments above, applications can be different, in different contexts and different users. What could you reuse? What are the envisioned reusability possibilities?
“Develop or extend modeling languages to cover needs of visually impaired users.” (“TOSEM-2025-0885”, p. 29)
“Evaluate and enhance or develop modeling languages to better represent specific accessibility needs, i.e., annotating color-independent interactions, providing alternative modalities, tagging semantic description of UI elements, or dependencies on screen readers, in software design. By adapting and extending existing modeling languages, developers can more effectively articulate and document accessibility requirements within their designs” (“TOSEM-2025-0885”, p. 29)
“Leverage genAI to create impairment-focused models and represent different levels of vision loss.” (“TOSEM-2025-0885”, p. 29) This comes out of the blue!
“Provide reusable RTE components that incorporate vision accessibility” (“TOSEM-2025-0885”, p. 30) See my previous comment about reusability.
“Develop reusable generators and templates incorporating the visually impaired needs.” (“TOSEM-2025-0885”, p. 30) This is very related to one  of my previous comment about reusability concerns
“Create and refine reusable transformation rules for covering sight-related accessibility features by default.” (“TOSEM-2025-0885”, p. 30) Idem, see my previous comment. This is the main concern of this work!
“While accessibility needs for visually impaired persons are often overlooked in developing socio-technical systems, an MDE approach should provide the needed developer support to incorporate them systematically and consistently throughout the complete application. This study presents a systematic literature review of 30 primary studies on the application of model-driven engineering for visual impairments selected from an initial pool of 447 papers. We have analyzed existing trends regarding timing, output, impact, and nature of the reported approaches, and what visual impairments they address. We investigated the MDE approaches and their development steps and evaluations in detail, and gave an overview of the reported strengths, limitations, gaps, and challenges. Key findings are that most studies to date operate at a high abstraction level, mainly rely on WCAG, and rarely provide reproducible pipelines or working software artifacts.” (“TOSEM-2025-0885”, p. 31)
“Only a small number of studies provide concrete modeling approaches for accessibility requirements,” (“TOSEM-2025-0885”, p. 31)
“functioning implementations, and evaluations with visually impaired end users. This limits reuse, hinders independent verification of the results and constrains the impact for practical adoption. Only a few approaches target MDE methods, languages, transformations, code generators, or further tooling as the object of innovation and rather use MDE as an instrument. This might explain why contributions are often rather conceptual, short on implementation details, and underrepresented at core MDE venues. Consequently, the analysis has shown limited research outputs and low visibility. This calls for technically grounded work that treats accessibility as a first-class concern. The applied methods are mixed: While WCAG is used by most of the approaches, and models commonly capture the UI, interactions, and navigation, only five studies consider modeling accessibility requirements (without being specific enough to enable reproduction). Evaluations are sparse: 10 studies have no evaluation, and only 6 conducted user studies, whereas only 3 of them involved visually impaired participants. None provided additional evaluation data packages to support replication of the evaluation. Measuring the achieved accessibility of applications remains challenging, as only using automated checkers is not sufficient and conducting user studies is time-intensive. Using our results, we have sketched some possible research topics in analysis, design, implementation, and testing of accessible applications using MDE. Promising research directions include (i) analysis and design techniques that make accessibility requirements explicit, traceable and verifiable at the model level, (ii) reusable model transformations, code templates, code generators and runtime components that include accessibility, and (iii) testing approaches increasing the level of automation and checking for compliance with accessibility requirements. Exploring the interplay with methods from AI and generative AI provides additional possible research directions. Advancing the field will require publishing more implementation details and replication packages. In summary, the current state-of-the-art demonstrates potential for improving accessibility of software applications with MDE methods. Providing more reusable artefacts on model, template, and code level and transparent evaluations with relevant user groups, the MDE community can improve development methods for accessibility for visual impairments, delivering an important impact on society” (“TOSEM-2025-0885”, p. 32)
Consider that those that are tagged with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are important sentences.
Please pay attention 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
COMMENTS: Organize the notes especially those that contain issues or typos.
Please avoid overstatements and minimize bullet points. The comments have to be fluent, informative.
pages/@TraceCoder%3A A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code.md
+214
View File
@@ -0,0 +1,214 @@
tags:: [[#zotero]]
date:: 2026
title:: @TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code
item-type:: [[journalArticle]]
original-title:: TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/XP7SMW8I), [Web library](https://www.zotero.org/users/1039502/items/XP7SMW8I)
- [[Abstract]]
- Large Language Models (LLMs) often generate code with subtle yet critical bugs, particularly for complex tasks. Existing automated methods for repairing LLM-generated code are limited by their reliance on superficial outcomes, such as simple pass/fail results. This “black-box” approach offers little insight into the program’s internal dynamics, hindering precise error localization. Furthermore, the absence of a mechanism to learn from past failures leads to inefficient repair cycles that often repeat the same mistakes. To address these limitations, we introduce TraceCoder, a collaborative multi-agent framework that mimics the observe-analyze-repair process of human experts. The framework first instruments the code with diagnostic print statements to capture fine-grained runtime traces, providing deep visibility into its internal execution. It then conducts causal analysis on these traces to accurately identify the root cause of the error. This process is further enhanced by a novel Historical Lesson Learning Mechanism, which distills insights from prior failed repair attempts to inform subsequent correction strategies and prevent recurrence of similar mistakes. To ensure stable convergence, a Rollback Mechanism enforces that each repair iteration constitutes a strict improvement toward the correct solution. Comprehensive empirical evaluations demonstrate that TraceCoder achieves up to a 34.43% relative improvement in Pass@1 accuracy over state-of-the-art baselines. Ablation studies verify the significance of each system component, with the iterative repair process alone contributing a 65.61% relative gain in accuracy. Furthermore, TraceCoder significantly outperforms leading iterative methods in terms of both accuracy and cost-efficiency.
- ### Attachments
- [PDF](zotero://select/library/items/LU4KFAS8) {{zotero-imported-file LU4KFAS8, "2026 - TraceCoder A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotations
(17/09/2025, 15:04:04)
- “A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “Existing automated methods for repairing LLM-generated code are limited by their reliance on superficial outcomes, such as simple pass/fail results” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “the absence of a mechanism to learn from past failures leads to inefficient repair cycles that often repeat the same mistakes.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “TraceCoder, a collaborative multi-agent framework that mimics the observe-analyze-repair process of human experts.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “It then conducts causal analysis on these traces to accurately identify the root cause of the error” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #e56eee
- “Historical Lesson Learning Mechanism” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “Rollback Mechanism enforces that each repair iteration constitutes a strict improvement toward the correct solution” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #a28ae5
- “Comprehensive empirical evaluations demonstrate that TraceCoder achieves up to a 34.43% relative improvement in Pass@1 accuracy over state-of-the-art baselines” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “. Despite their impressive capabilities, LLMs often generate code that contains subtle yet critical bugs—particularly in complex or logic-intensive scenarios” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “This challenge has given rise to an emerging research direction focused on the automated repair of LLM-generated code, aiming to improve the reliability, correctness, and usability of LLM-assisted development” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “Recent work in this emerging area has explored diverse strategies for repairing LLM-generated code.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “However, most existing self-correction methods operate as “blackboxes”, relying solely on pass/fail feedback from a test suite. This approach, which lacks insight into the program’s internal execution, suffers from significant limitations.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “To address these challenges, we propose TraceCoder, a multiagent collaborative self-debugging framework that emulates the human debugging process of iterative observation, analysis, and repair.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “TraceCoder decomposes the complex debugging task into three specialized agents to enhance modularity, reliability, and control. Specifically, the Instrumentation Agent captures fine-grained runtime traces by injecting diagnostic statements into the program. The Analysis Agent performs causal reasoning over these traces, guided by a novel Historical Lesson Learning Mechanism (HLLM), which distills insights from past failures to generate effective repair plans. The Repair Agent then translates these plans into concrete code modifications.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #a28ae5
- “Rollback Mechanism (RM)” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 1) #5fb236
- “This structured workflow—where the Analysis Agent integrates runtime evidence and historical insights to guide the Repair Agent—establishes a cohesive and interpretable debugging loop with a clear separation of concerns.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #e56eee
- “Second, it facilitates experienceinformed repair decisions through historical learning, and ensures a robust repair trajectory via integrated rollback and replanning mechanisms.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #5fb236
- “We evaluated TraceCoder on several representative datasets, including BigCodeBench and ClassEval, using diverse LLM backends.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #5fb236
- “Notably, TraceCoder improves the success rate of repairing LLM-generated code, reduces redundant repair attempts, and enhances cost-efficiency—especially on complex programming tasks where LLMs are most prone to failure.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #e56eee
- “TraceCoder, a modular, multi-agent framework that emulates the human debugging workflow to enable automated repair of LLM-generated code” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #5fb236
- “a novel HLLM that learns from past failures to guide future repairs and avoid repeated mistakes.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #5fb236
- “Evaluations show that TraceCoder significantly outperforms SOTA methods, improving repair accuracy from baseline levels by up to 34.43% in relative terms on challenging class-level code generation benchmarks.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #5fb236
- “Empirical investigations, such as DevGPT [24], reveal that LLM-generated code is often used for prototyping or conceptual illustration, rather than deployment.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #5fb236
- “Despite these advances, postgeneration repair remains underexplored—LLMs frequently produce subtle logic bugs that existing generation pipelines cannot correct.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #5fb236
- “We address this gap by proposing a trace-driven framework designed to diagnose and repair LLM-generated code.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 2) #a28ae5
- “Zhang et al. [49] emphasize that despite advances in learning-based repair, runtime-aware introspection and memory-guided strategies remain underexplored.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #a28ae5
- “However, most methods lack such introspective capabilities and do not systematically incorporate lessons from failed attempts, limiting their effectiveness in complex debugging scenarios.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #e56eee
- “To address these gaps, we propose a self-debugging approach that combines fine-grained runtime introspection with historical error learning, enabling targeted and repeat-aware code repair” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #5fb236
- “most MAS frameworks focus on task decomposition and static role allocation, with limited support for integrating dynamic runtime feedback or leveraging historical debugging context” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #5fb236
- “causal planning with collaborative repair to support runtime-aware, self-corrective debugging” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #5fb236
- “Instrumentation Agent inserts diagnostic probes to collect runtime traces” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #ffd400
*Does it mean that it changes the previously generated code?*
- “Analysis Agent performs causal reasoning over these traces to localize faults” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #2ea8e5
- “Repair Agent synthesizes and applies candidate patches.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #2ea8e5
- “When initial code fails its test suite, the agents are activated and iterate until all tests pass or a termination condition is reached.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #a28ae5
- “the agent inserts diagnostic print statements into the code to expose internal state transitions and control flow.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #a28ae5
- “These runtime insights serve as essential evidence for downstream causal analysis by the Analysis Agent.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #a28ae5
- “resulting instrumented code (Cinst) strictly preserves the original computational semantics but emits context-aware debug logs during execution, providing valuable insights into the program’s dynamic behavior” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #a28ae5
- “The Instrumentation Agent employs a dedicated prompt to guide the LLM in inserting diagnostic probes.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #ffd400
*This is a critical point. Is it sure that the instrumentation agent does not wrongly add statements that change the semantics of the code?*
- “with strategically placed print statements that reveal execution flow and key variable states” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #ffd400
*Only print statements are added then.*
- “The agent must not modify computational logic, comment out code, or introduce new variables—thus preserving semantic integrity.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 3) #ffd400
*This is crucial. How do you ensure that?*
- “It records the entire output stream during execution and monitors for any runtime errors or uncaught exceptions.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #5fb236
- “The result is a structured runtime trace that combines test results, debug outputs, and error and exception details.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #a28ae5
- “This trace is then forwarded to the Analysis Agent as a key input to support subsequent fault diagnosis and repair planning.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #a28ae5
- “a repair plan for the Repair Agent” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #5fb236
- “targeted instrumentation suggestions for the next debugging cycle.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #5fb236
- “Lesson Record (Lrecord). A structured log of all failed repair attempts for the current problem, used to reflect on prior reasoning and avoid repeated mistakes.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #5fb236
- “Diagnosis and Reflection.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #2ea8e5
- “Strategy Formulation” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 4) #2ea8e5
- “This prompt defines the LLM’s role, clarifies the repair objectives, and guides it to reason through the task in a systematic and controlled manner.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “Repair Agent follows a structured three-step workflow:” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #2ea8e5
- “allowed to make minimal adjustments” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #ffd400
*This is also important because it is related to the convergence of the refinement process. How can you define such "minimal" adjustments?*
- “Repair Agent can be modeled as a function that maps the given context and the repair plan from the Analysis Agent to the final repaired code (Crepaired).” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #e56eee
- “his process embodies its core responsibility of executing the repair: (Dprob, Cfaulty, Ferror, Prepair) → Crepaired” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “The communication among TraceCoder’s agents follows a structured, sequential pattern, mediated by shared artifacts rather than direct message passing.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #ffd400
*So, no dedicated MAS framework has been used. This is important to motivate, because there are dedicated frameworks that take care of the communication and orchestration of agents collaborating to achieve a given goal.*
- “Analysis Agent integrates” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #ffd400
*How agents are orchestrated?*
- “a detailed repair plan” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “set of instrumentation suggestions to guide the Instrumentation Agent in collecting more targeted traces in subsequent iterations.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #ffd400
*Is it always necessary?*
- “This updated version is re-entered into the testing process, where its success or failure becomes the basis for the next iteration.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “Although the agents maintain independence and do not communicate directly, the flow of artifacts creates an implicit yet effective feedback mechanism: test results indirectly inform the Analysis Agent of the effectiveness of its prior diagnosis.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #ffd400
- “This sequential, artifactmediated communication model ensures that each agent operates with well-structured, contextually relevant information, avoiding uncoordinated interactions and promoting stable convergence.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #ffd400
*Can we be sure about that?*
- “HLLM, which addresses the limitations of stateless repair by enabling the system to learn from past failures.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “This allows the Analysis Agent to avoid previously ineffective reasoning paths and refine its diagnostic approach across repair cycles.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “Lesson Record.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #2ea8e5
- “Each time an iterative repair attempt fails to pass all predefined test cases, the system automatically captures key contextual information.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “Lesson Feedback.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #2ea8e5
- “Before generating a new repair plan, the Analysis Agent prompts the LLM to analyze the Lesson Record, which contains all failure records for the current problem instance.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 5) #5fb236
- “Lesson-Informed Deliberation and Planning” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 6) #2ea8e5
- “. By doing so, RM prevents the repair trajectory from deteriorating across iterations and anchors the search process around the best-known solutions.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 6) #5fb236
- “Key State Recording.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 6) #2ea8e5
- “Progress Evaluation and Decision-Makin” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 6) #2ea8e5
- “This section introduces four research questions addressed by TraceCoder and details the experimental setup, including datasets, baselines, evaluation metrics, and implementation details” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 6) #5fb236
- “RQ1: How effective is TraceCoder in repairing LLM-generated code compared to SOTA automated repair methods?” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 7) #2ea8e5
- “RQ2: How do TraceCoder’s key hyperparameters affect its repair performance and stability?” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 7) #2ea8e5
- “RQ3: What is the contribution of each core component to TraceCoder’s overall effectiveness?” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 7) #2ea8e5
- “RQ4: What are TraceCoder’s API usage characteristics and what are the most frequent failure types during repair?” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 7) #2ea8e5
- “BigCodeBench offers a diverse set of realistic functionlevel tasks that emphasize complex instruction following and API usage” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 7) #ffd400
*Strange sentence. Maybe "following an API usage" ?*
- “Answer to RQ1: TraceCoder consistently outperforms baseline methods across all benchmarks and model settings. Its advantage is particularly notable on complex benchmarks such as ClassEval and BigCodeBench, where it achieves a relative improvement of up to 34.43% over the strongest baselines.” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 7) #ffd400
*Readers are not provided with details to read these numbers in a convincing manner. Can you give some examples to give some hints on the different results provided by the different tools including TraceCoder? Morever, the experiment settings should be better presented. No details are given concerning the problem description, the corresponding source code (if it is a method, a class, a full project) and no details are given concerning the coverage of the generated test cases. With the given descriptions, many questions arise that require further details. Even the application of the baselines is not clear, the same questions about the experimental setup arise.*
- “This paper presented TraceCoder, a trace-driven, multi-agent framework that emulates expert debugging behavior to automatically repair LLM-generated code. By leveraging runtime instrumentation, coordinated agent collaboration, and iterative refinement, TraceCoder enables precise error diagnosis and targeted correction. Its HLLM prevents redundant failures by reusing past insights, while the RM stabilizes progress by preserving successful intermediate results. Extensive evaluations across multiple benchmarks and foundation models demonstrate TraceCoder’s significant improvements in repair accuracy, particularly on complex tasks. Further analysis highlights its superior efficiency among iterative methods and reveals that the remaining challenge lies in addressing subtle semantic flaws. Future work will explore strategies to improve token efficiency and extend TraceCoder’s language coverage. A key direction is enhancing the HLLM by incorporating structured knowledge representations and task-level learning mechanisms, enabling agents to generalize from prior repair attempts across tasks and domains” (“TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code”, 2026, p. 10) #ffd400
*This is a very interesting paper. The presented approach is novel. Themain problem is on RQ1 and on the presentation of how the tool can be used in practice. In particular, the granularity of the problem specification that is given to LLMs to generate source code is not clear. It is not clear also the code that is generated, is it methods, classes, etc. What's the role of test cases in driving the initial code generation?*
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?
pages/A Research Assistant Team.md
+12
View File
@@ -0,0 +1,12 @@
- **Use case**: a *“research assistant team”*:
- **Researcher** agent → searches the web / literature and gathers info
- **Writer** agent → turns notes into a clean answer
- **Critic** agent → reviews the draft and tightens it up
- **Supervisor** agent → decides which specialist to call and when
- Setup
- ```
python -m venv venv
.\venv\Scripts\Activate.ps1
pip install -U "langchain>=1.0" langchain-openai langchain-community
export OPENAI_API_KEY="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"
```
pages/AVA3.md
+3
View File
@@ -0,0 +1,3 @@
tags:: [[SERVICES/PHDICT]]
- {{embed ((68584ed7-1a9f-42ba-85b0-9cd778066ea7))}}
pages/Assicurazione della Qualità di Corsi di Studio e di dottorato e Dipartimenti - Audizione del 21 novembre 2025.md
+24
View File
@@ -0,0 +1,24 @@
tags:: #todoist-task, [[SERVICES/PHDICT]] , #AVA3
date:: [[06-10-2025]] - 15:53
progress:: {{renderer :todomaster}}
- [[Resources]]
- Linee guida e moduli: [https://www.univaq.it/section.php?id=2223](https://www.univaq.it/section.php?id=2223)
- ![Convocazione-Audizione-2025.pdf](../assets/Convocazione-Audizione-2025_1759759982455_0.pdf)
- ![UNIVAQ_LG_audizioni_DOTTORATO_Agg_AVA3_febb_2025.pdf](../assets/UNIVAQ_LG_audizioni_DOTTORATO_Agg_AVA3_febb_2025_1759759493525_0.pdf)
- ![RELAZIONE_Nucleo_2024.pdf](../assets/RELAZIONE_Nucleo_2024_1759759962335_0.pdf)
- ### Tasks
- TODO Aggiornare dati su NOTION
- DONE Decidere studenti da coinvolgere
id:: 68e76ae4-b361-4812-85ba-d7c07be80b1c
:LOGBOOK:
CLOCK: [2025-11-11 Tue 22:43:35]--[2025-11-11 Tue 22:43:36] => 00:00:01
:END:
- DONE Aggiornare sito web con dati dal documnto di presentazione
id:: 69190e77-3111-4845-b9ae-792f9f3382e6
- DONE Lavorare su questionario / Allegato
id:: 68e76ae4-ab11-47e1-81fc-f2973dab9f1a
- DONE Altri documenti?
-
- ### Notes
- [AUDIZIONE NUCLEO DI VALUTAZIONE](onenote:https://d.docs.live.net/a33324427a144a54/Documenti/Blocco%20appunti%20di%20Davide/Services/PHD-ICT.one#AUDIZIONE%20NUCLEO%20DI%20VALUTAZIONE§ion-id={607EE243-9302-4ECB-A218-93C9F0FD3C89}&page-id={21AB324D-4121-420B-94EA-FEDC58AABFD0}&object-id={BB882772-384E-067B-259A-2FB5232CFFA1}&12)  ([visualizzazione Web](https://onedrive.live.com/view.aspx?resid=A33324427A144A54%21464&id=documents&wd=target%28Services%2FPHD-ICT.one%7C607EE243-9302-4ECB-A218-93C9F0FD3C89%2FAUDIZIONE%20NUCLEO%20DI%20VALUTAZIONE%7C21AB324D-4121-420B-94EA-FEDC58AABFD0%2F%29&wdpartid=%7b252131B6-EB60-054A-24A3-0383FAEC354A%7d%7b1%7d&wdsectionfileid=A33324427A144A54!1784))
pages/Assicurazione della qualità dei corsi di Dottorato di Ricerca – AVA3 – Calendario delle scadenze. Presentazione relazione di fine ciclo (RC.PHD).md
+10
View File
@@ -0,0 +1,10 @@
tags:: #todoist-task, [[SERVICES/PHDICT]], #AVA3
date:: [[24-11-2025]] - 18:40
progress:: {{renderer :todomaster}}
- *"Il calendario delle scadenze per la produzione dei documenti di programmazione, monitoraggio e riesame, viene approvato dal PQA entro il 31 dicembre di ogni anno, su proposta da parte della struttura organizzativa di Ateneo del dottorato (responsabile del settore dottorati, assegni e borse di ricerca), di intesa con le coordinatrici e i coordinatori dei corsi di dottorato e con il referente di Ateneo".*
- ![Calendario scadenze_Coordinatori.pdf](../assets/Calendario_scadenze_Coordinatori_1764006171407_0.pdf)
- [Relazione Fine Ciclo RC.PHD_2025.docx](../assets/Relazione_Fine_Ciclo_RC.PHD_2025_1764006190602_0.docx)
- [Linee Guida AQ Dottorati_marzo 2025 FINALE.pdf](https://www.unitn.it/sites/default/files/2025-05/Linee%20Guida%20AQ%20Dottorati_marzo%202025%20FINALE.pdf?__cf_chl_tk=mV7AQTTxWiMcoc2Xmcr9fZD6Ed8.rjv9e95e_jsVAOk-1764004635-1.0.1.1-pCc2G1KbuZG6ngZqe.qVPvueWoMzTalI5OTdUnrrAhs)
- TODO GAQ: Gruppo di Assicurazione della Qualità
-
pages/BRAINSTORMING.md
+2
View File
@@ -2,6 +2,8 @@ icon:: 🧠
- ![BOOX Notes - BRAINSTORMING](../assets/../../onyx/TabUltraCPro/Notepad/BRAINSTORMING.pdf)
- [[Writing Challenges]]
- ## Previsione
- Architecting Green and Ethical Quantum Computing-based Agents :-) [[people/HenryMuccini]]
- ## RESEARCH
- Some fortcoming research efforts can be devoted to aspects relatedo to trustworthiness of LLMs in Software Engineering. The recently accepted [[David Lo]] project goes in that direction (see the interview at [[Omnivore/30-11-2023/Realising synergy for bots and engineers - Office of Research]] )
- The paper [[Omnivore/16-12-2023/Breaking the Silence- the Threats of Using LLMs in Software Engineering]] is full of hooks we could consider to define a short and medium term research plan.
pages/Benchmarking framework.md
+1
View File
@@ -0,0 +1 @@
alias:: [[Benchmarks]]
pages/Benchmarks.md
+6
View File
@@ -0,0 +1,6 @@
tags:: [[PROJECTS/MOSAICO]], [[P1]]
- In one of the ICSE papers that I reviewed [[ICSE2026-paper1656]] there is this reference to look at:
- >[21] René Just, Darioush Jalali, and Michael D. Ernst. 2014. **Defects4j: A Database of Existing Faults to Enable Controlled Testing Studies for Java Programs**. In International Symposium on Software Testing and Analysis, ISSTA ’14, San Jose, CA, USA - July 21 - 26, 2014. ACM, 437–440.
- It made me think that when benhmarking AI agents, we need to follow something similar with what we did with Jesus ([ModelXGlue: a benchmarking framework for ML tools in MDE | Software and Systems Modeling](https://link-springer-com.univaq.idm.oclc.org/article/10.1007/s10270-024-01183-z))
- In particular, this concept of database of existing subjects to be investigated should be made explicit in the language for specifying benchmarks.
pages/COLA-D-24-00156.md
+1
View File
@@ -13,6 +13,7 @@ parent::
todoist:: https://app.todoist.com/app/task/cola-d-24-00156-6Wxx76rWx3QQ6r88
- ### [[Highlights]]
collapsed:: true
- *# Annotazioni  *
(6/3/2025, 14:47:58)
pages/CV Empower.md
+5 -2
View File
@@ -5,8 +5,11 @@ icon:: 🔥
#+END_PINNED
- ## [[Writing Challenges]]
- ## [[AI Playground]]
- [[Agentic AI]]
-
- [[Agentic AI]]
- [[Conda and LangChain Playground]]
- [[LLMs-from-scratch: Implement a ChatGPT-like LLM in PyTorch from scratch, step by step]]
- [[LLM-based Planner]]
- [[A Research Assistant Team]]
- ## Documentazione tecnica
- [[OpenAI examples]]
- [debanjandhar12/logseq-anki-sync: An logseq to anki syncing plugin. (github.com)](https://github.com/debanjandhar12/logseq-anki-sync)
pages/Call per posizioni MOSAICO.md
+56 -45
View File
@@ -1,51 +1,62 @@
tags:: #todoist-task [[PROJECTS/MOSAICO]]
icon:: 🎉
page-type:: [[PROJECTS/MOSAICO]]
progress:: {{renderer :todomaster}}
- ### TASKS
- {{query (and [[Call per posizioni MOSAICO]] (task TODO DOING) (not [[GOALS-TODOIST]]) (not [[TODOIST-LOGSEQED]]))}}
query-table:: true
- TODO Preparare documento con lista di espressioni di interesse ricevute
-
- DONE Studiare [[@Regolamento per il conferimento di contratti di ricerca]]
id:: 6839cd22-cd1c-4541-bea1-50c655611104
:LOGBOOK:
CLOCK: [2025-05-30 Fri 18:04:12]--[2025-05-30 Fri 18:04:13] => 00:00:01
:END:
- ((6839d240-e828-4ebd-861e-2f97e1adb987))
- ### **Stima dei costi**
| Voce | Importo (€) |
| ---- | ---- | ---- |
| Compenso lordo ricercatore | 36.000,00 |
| Oneri previdenziali e assistenziali a carico ente | 10.800,00 |
| IRAP (8,5% stimato) | 3.200,00 |
| **Totale annuo lordo omnicomprensivo** | **50.000,00** |
- Due anni ((6839d6ee-b985-41b9-8edf-5180e3fd947c))
- DONE Cercare bandi di contratti già banditi
id:: 6839ce19-2f24-43d2-a1ab-b615a34bd92f
:LOGBOOK:
CLOCK: [2025-05-30 Fri 18:00:10]--[2025-05-30 Fri 18:00:11] => 00:00:01
:END:
- |PDF | Data | Oggetto|
|![1-002816498-UNAQCLE-dbebcbc9-8f9d-41df-8ee1-5b88cc589f0b-000.pdf](../assets/1-002816498-UNAQCLE-dbebcbc9-8f9d-41df-8ee1-5b88cc589f0b-000_1748620269018_0.pdf) | [[17-04-2025]] | Bando|
|![4-002826659-UNAQCLE-f92544ff-4400-4b1c-9ae5-77b4286ac1eb-000.pdf](../assets/4-002826659-UNAQCLE-f92544ff-4400-4b1c-9ae5-77b4286ac1eb-000_1748620283248_0.pdf) | [[28-04-2025]] | Ammissione candidati|
|![2-002822473-UNAQCLE-966af140-6fbc-4417-a65d-d0116dd57854-000.pdf](../assets/2-002822473-UNAQCLE-966af140-6fbc-4417-a65d-d0116dd57854-000_1748620274481_0.pdf) | [[28-04-2025]] | Nomina commissione dal Rettore su Delibera del MESVA|
|![3-002826136-UNAQCLE-f9b7a036-213f-4774-923d-4cfb96a14a00-000.pdf](../assets/3-002826136-UNAQCLE-f9b7a036-213f-4774-923d-4cfb96a14a00-000_1748620278810_0.pdf) | [[05-05-2025]] | Verbale preliminare|
|![5-002830430-UNAQCLE-f2913083-d9a9-4e67-9e11-6d0df4c94f40-000.pdf](../assets/5-002830430-UNAQCLE-f2913083-d9a9-4e67-9e11-6d0df4c94f40-000_1748620288090_0.pdf) | [[09/05/2025]] | Valutazione titoli|
|![6-002831992-UNAQCLE-70709d32-0a56-4fb7-aabf-18f471f5ed0c-000.pdf](../assets/6-002831992-UNAQCLE-70709d32-0a56-4fb7-aabf-18f471f5ed0c-000_1748620297008_0.pdf) | [[12-05-2025]] | Orale|
|![7-002832007-UNAQCLE-5ca08ba8-2c0b-460a-8ffc-3b4421f18e62-000.pdf](../assets/7-002832007-UNAQCLE-5ca08ba8-2c0b-460a-8ffc-3b4421f18e62-000_1748620314246_0.pdf) | [[13-05-2025]] | Approvazione atti e graduatoria|
- TODO Vedere CFP di altri contratti di ricerca banditi da altre università
- [All. 1_Decreto DG 140-2025_Bando 2_2025_Contratti di ricerca_1.1-signed.pdf](https://www.inrim.it/sites/default/files/2025-05/All.%201_Decreto%20DG%20140-2025_Bando%202_2025_Contratti%20di%20ricerca_1.1-signed.pdf)
- Qui il compenso annuale loro e' di euro 38986.47
- [Bando MUR PNRR - 4 CdR_EN.pdf](file:///C:/Users/david/Nextcloud/WIN/Downloads/Bando%20MUR%20PNRR%20-%204%20CdR_EN.pdf)
- DOING Fare scouting
:LOGBOOK:
CLOCK: [2025-06-14 Sat 11:05:25]
:END:
- DONE Fare post linkedin
:LOGBOOK:
CLOCK: [2025-06-14 Sat 11:04:58]--[2025-06-14 Sat 11:04:58] => 00:00:00
CLOCK: [2025-06-14 Sat 11:05:07]--[2025-06-14 Sat 11:05:10] => 00:00:03
CLOCK: [2025-06-14 Sat 11:05:15]--[2025-06-14 Sat 11:05:16] => 00:00:01
:END:
- Anche se generico, chiedere a chi fosse interessato ad un post-doc di approcciarmi via private message of via email.
- TODO Rivedere bene e prendere una decisione in merito a ((69190e46-c217-4afb-866d-454ef610384a))
- DONE Preparare documento con lista di espressioni di interesse ricevute
id:: 6860e8a1-9d1e-4c28-8936-65e07c1023c4
:LOGBOOK:
CLOCK: [2025-07-30 Wed 18:01:24]--[2025-07-30 Wed 18:01:25] => 00:00:01
:END:
- DONE Studiare [[@Regolamento per il conferimento di contratti di ricerca]]
id:: 6839cd22-cd1c-4541-bea1-50c655611104
collapsed:: true
- ((6839d240-e828-4ebd-861e-2f97e1adb987))
- ### **Stima dei costi**
| Voce | Importo (€) |
| ---- | ---- | ---- |
| Compenso lordo ricercatore | 36.000,00 |
| Oneri previdenziali e assistenziali a carico ente | 10.800,00 |
| IRAP (8,5% stimato) | 3.200,00 |
| **Totale annuo lordo omnicomprensivo** | **50.000,00** |
- Due anni ((6839d6ee-b985-41b9-8edf-5180e3fd947c))
- ![image.png](../assets/image_1758806339815_0.png)
- DONE Cercare bandi di contratti già banditi
id:: 6839ce19-2f24-43d2-a1ab-b615a34bd92f
collapsed:: true
:LOGBOOK:
CLOCK: [2025-05-30 Fri 18:00:10]--[2025-05-30 Fri 18:00:11] => 00:00:01
:END:
- |PDF | Data | Oggetto|
|![1-002816498-UNAQCLE-dbebcbc9-8f9d-41df-8ee1-5b88cc589f0b-000.pdf](../assets/1-002816498-UNAQCLE-dbebcbc9-8f9d-41df-8ee1-5b88cc589f0b-000_1748620269018_0.pdf) | [[17-04-2025]] | Bando|
|![4-002826659-UNAQCLE-f92544ff-4400-4b1c-9ae5-77b4286ac1eb-000.pdf](../assets/4-002826659-UNAQCLE-f92544ff-4400-4b1c-9ae5-77b4286ac1eb-000_1748620283248_0.pdf) | [[28-04-2025]] | Ammissione candidati|
|![2-002822473-UNAQCLE-966af140-6fbc-4417-a65d-d0116dd57854-000.pdf](../assets/2-002822473-UNAQCLE-966af140-6fbc-4417-a65d-d0116dd57854-000_1748620274481_0.pdf) | [[28-04-2025]] | Nomina commissione dal Rettore su Delibera del MESVA|
|![3-002826136-UNAQCLE-f9b7a036-213f-4774-923d-4cfb96a14a00-000.pdf](../assets/3-002826136-UNAQCLE-f9b7a036-213f-4774-923d-4cfb96a14a00-000_1748620278810_0.pdf) | [[05-05-2025]] | Verbale preliminare|
|![5-002830430-UNAQCLE-f2913083-d9a9-4e67-9e11-6d0df4c94f40-000.pdf](../assets/5-002830430-UNAQCLE-f2913083-d9a9-4e67-9e11-6d0df4c94f40-000_1748620288090_0.pdf) | [[09/05/2025]] | Valutazione titoli|
|![6-002831992-UNAQCLE-70709d32-0a56-4fb7-aabf-18f471f5ed0c-000.pdf](../assets/6-002831992-UNAQCLE-70709d32-0a56-4fb7-aabf-18f471f5ed0c-000_1748620297008_0.pdf) | [[12-05-2025]] | Orale|
|![7-002832007-UNAQCLE-5ca08ba8-2c0b-460a-8ffc-3b4421f18e62-000.pdf](../assets/7-002832007-UNAQCLE-5ca08ba8-2c0b-460a-8ffc-3b4421f18e62-000_1748620314246_0.pdf) | [[13-05-2025]] | Approvazione atti e graduatoria|
- DONE Vedere CFP di altri contratti di ricerca banditi da altre università
id:: 68584e9a-3433-49a6-b66e-3f365c4b0713
:LOGBOOK:
CLOCK: [2025-07-30 Wed 18:01:36]--[2025-11-23 Sun 09:41:27] => 2775:39:51
:END:
- [All. 1_Decreto DG 140-2025_Bando 2_2025_Contratti di ricerca_1.1-signed.pdf](https://www.inrim.it/sites/default/files/2025-05/All.%201_Decreto%20DG%20140-2025_Bando%202_2025_Contratti%20di%20ricerca_1.1-signed.pdf)
- Qui il compenso annuale loro e' di euro 38986.47
- [Bando MUR PNRR - 4 CdR_EN.pdf](file:///C:/Users/david/Nextcloud/WIN/Downloads/Bando%20MUR%20PNRR%20-%204%20CdR_EN.pdf)
- DONE Fare scouting
id:: 68584e9a-7058-4550-bcde-ecae1dec7e70
:LOGBOOK:
CLOCK: [2025-06-14 Sat 11:05:25]--[2025-11-23 Sun 09:41:08] => 3886:35:43
:END:
- DONE Fare post linkedin
:LOGBOOK:
CLOCK: [2025-06-14 Sat 11:04:58]--[2025-06-14 Sat 11:04:58] => 00:00:00
CLOCK: [2025-06-14 Sat 11:05:07]--[2025-06-14 Sat 11:05:10] => 00:00:03
CLOCK: [2025-06-14 Sat 11:05:15]--[2025-06-14 Sat 11:05:16] => 00:00:01
:END:
- Anche se generico, chiedere a chi fosse interessato ad un post-doc di approcciarmi via private message of via email.
pages/Clip.md
+2
View File
@@ -1 +1,3 @@
icon:: 📎
-
pages/Conda and LangChain Playground.md
+39
View File
@@ -0,0 +1,39 @@
- Installation [Installing Miniconda - Anaconda](https://www.anaconda.com/docs/getting-started/miniconda/install#macos-linux-installation:manual-shell-initialization)
- **LangSmith** is here to support you at every step of your development journey with tools for observability, evaluation, and prompt engineering.
- As you start building your agent, you may need to debug unexpected outputs or performance bottlenecks. That’s where **tracing** in LangSmith comes in.
- Tracing can help you pinpoint issues and track how each part of your agent contributes to the output. You can also share traces with your team for seamless debugging – here’s [an example](https://track.pstmrk.it/3s/smith.langchain.com%2Fpublic%2F2f75dddd-fa65-4dd1-a9c7-09c11032b267%2Fr/Tpyp/a8W-AQ/AQ/fdde9c53-e164-482b-99dd-eeea3c2a9a20/1/L6vVzrWDEB).
- Ready to log your first trace in LangSmith? 🤓 Watch this quick 5-minute video to get started, and follow along with the code [here](https://track.pstmrk.it/3s/github.com%2Fxuro-langchain%2Feli5/Tpyp/a8W-AQ/AQ/fdde9c53-e164-482b-99dd-eeea3c2a9a20/2/OCP0-lehao).
- https://track.pstmrk.it/3s/www.youtube.com%2Fwatch%3Fv%3DfA9b4D8IsPQ/Tpyp/a8W-AQ/AQ/fdde9c53-e164-482b-99dd-eeea3c2a9a20/3/9ETeFMFTSD
- If you need a hand getting started, our [Quick Start](https://track.pstmrk.it/3s/docs.smith.langchain.com%2Fobservability/Tpyp/a8W-AQ/AQ/fdde9c53-e164-482b-99dd-eeea3c2a9a20/4/1-h5s_hKG0) and [Tracing docs](https://track.pstmrk.it/3s/docs.smith.langchain.com%2Fobservability%2Fhow_to_guides%23tracing-configuration/Tpyp/a8W-AQ/AQ/fdde9c53-e164-482b-99dd-eeea3c2a9a20/5/BFX-Zbfit0#tracing-configuration) have you covered 🥳
- Over the next 5 emails in our onboarding series, we’ll dive into LangSmith’s core features and show you how to use them. I’ll be back soon with more on the LangSmith Playground!
- [[Conda]] is a package and environment manager, originated from Python even though it is language agnostic.
- While pip is excellent for managing Python-only packages, Conda can manage dependencies for projects that require non-Python libraries and complex dependency trees
- Conda environments can be exported to a YAML file, which permits to recreate the exact same environment, ensuring reproducibility for collaboration and deployment
- I think it's a kind of Maven or Gradle framework even though it is not specific to only one language
- Conda is a popular choice for data scientists and AI developers
- Conda can manage different environments [Getting started with conda — conda 25.7.1.dev23 documentation](https://docs.conda.io/projects/conda/en/latest/user-guide/getting-started.html) es
- ```
conda create -n <env-name>
```
- [[Anaconda]] and [[Miniconda]] are software distributions, which means they are collections of pre-built tools specifically designed for data science.
- Coda is included in Anaconda and Miniconda
- Init commands
- ```bash
source <PATH_TO_CONDA>/bin/activate
conda init --all
conda init --reverse bash
```
- Then
- ```bash
conda create -n langchain-book python=3.11
```
- From VS code I opened a Jupyter notebook of the book and I selected the langchain-book environment.
- I executed
- ```bash
pip install -r requirements.txt
```
- To execute python code outside Jupyter it is necessary to select the correct interpreter
- [Python environments in VS Code](https://code.visualstudio.com/docs/python/environments#_manually-specify-an-interpreter)
- CTRL+SHIFT P
- ![image.png](../assets/image_1755872606461_0.png){:height 867, :width 1154}
-
pages/DESKTOP.md
+2 -4
View File
@@ -5,19 +5,17 @@ title:: DESKTOP
- #+BEGIN_QUOTE
⛅️ This page is just for flushing Notes about things that must be done.
#+END_QUOTE
-
- ### **WEEK FOCUS**
- Per la settimana del [[09-06-2025]] il focus e' su queste macro attività
- DONE [[Preparazione Intervento PINKAMP]] #todoist-task #SERVICES/PINKAMP
id:: 68584e9a-9403-4a2a-87b9-70d3260ead58
- [[Linee guida afferenza Collegio dottorato ICT]] #[[todoist-task SERVICES/PHDICT]]
id:: 68584e9a-9403-4a2a-87b9-70d3260ead58
- [[Linee guida afferenza Collegio dottorato ICT]] #[[todoist-task]] #[[ SERVICES/PHDICT]]
- [[Aggiornamento uso fondi progetti]] #todoist-task #ADMIN #PROJECTS
- [[Progettazione Offerta Formativa]] #SERVICES/PHDICT #todoist-task
- [[PAPERS/MOSAICO-Technical-Report]] #[[PAPERS]] #[[todoist-task]]
- Questo deve essere il main focus per le prossime settimane.
- #.tabular
- ### **TASKS**
collapsed:: true
- {{embed [[Tasks]]}}
- ### **BRAINSTORMING**
collapsed:: true
pages/DONE.md
+265 -132
View File
@@ -21,135 +21,268 @@ icon:: ✅
- ✔️ [[10-05-2025]] *23:07* :LOGBOOK:
CLOCK: [2025-05-10 Sat 23:07:09]--[2025-05-10 Sat 23:07:11] => 00:00:02
:END:
- ✔️ [[May 21st, 2025]] *09:04* ((65c8d43c-9e5e-455f-9c48-cb6d035417fc))
- ✔️ [[May 24th, 2025]] *19:02* ((6831961e-c3a3-4890-99ae-ffda429333c8))
- ✔️ [[May 24th, 2025]] *20:47* ((6659d0ed-b485-4423-9c75-a8f5d715b31f))
- ✔️ [[May 24th, 2025]] *22:02* ((6832257a-63a4-4c89-8353-25f0e94caa51))
- ✔️ [[May 24th, 2025]] *22:02* ((6832257a-4373-4560-a7e2-79fba9f4c9e6))
- ✔️ [[May 24th, 2025]] *22:02* ((682ecc99-b356-4086-9ff8-4e4736018009))
- ✔️ [[May 25th, 2025]] *15:49* ((66e80dfd-0f7c-4020-aa87-906662c9eebd))
- ✔️ [[May 25th, 2025]] *19:26* ((6832257a-f98d-4f5e-850c-ddf8ffd0b5fb))
- ✔️ [[May 25th, 2025]] *19:26* ((6832257a-85cb-46bd-9018-855f59070a41))
- ✔️ [[May 25th, 2025]] *19:27* ((68331e69-7914-4696-8f2e-9ff4e9878686))
- ✔️ [[May 25th, 2025]] *19:29* ((6832257a-7e7e-4ed8-abf8-dd88c6643863))
- ✔️ [[May 25th, 2025]] *19:30* ((6832257a-cbb8-4881-ab20-bebcda629999))
- ✔️ [[May 25th, 2025]] *19:31* ((6832257a-eea4-45f9-ab9f-98dbc36328cf))
- ✔️ [[May 25th, 2025]] *22:49* ((65c8d46e-6599-4319-9683-4f86396c7e29))
- ✔️ [[May 25th, 2025]] *22:49* ((65c8d45b-9775-4e19-88ed-c5d1895df182))
- ✔️ [[May 26th, 2025]] *11:19* ((68342adf-8309-40bf-a38e-5dab74b7a5ea))
- ✔️ [[May 26th, 2025]] *11:20* ((68342adf-0b33-4470-aae1-a3741a2d5432))
- ✔️ [[May 26th, 2025]] *11:22* ((68342adf-7c9d-4937-8d81-7ce37d084360))
- ✔️ [[May 26th, 2025]] *13:23* ((68342adf-daa1-480c-813c-48be1ba86b71))
- ✔️ [[May 26th, 2025]] *13:31* ((68342adf-3362-4bb4-9082-f6050f8cf63c))
- ✔️ [[May 26th, 2025]] *13:45* ((6834435e-3184-483a-a02c-271995950996))
- ✔️ [[May 26th, 2025]] *13:45* ((6834435d-21d2-492c-aac2-21053aba25e1))
- ✔️ [[May 26th, 2025]] *13:47* ((68342adf-d123-444d-b7a2-c4bedd4042dd))
- ✔️ [[May 26th, 2025]] *14:11* ((68342adf-ecdc-4812-ad4f-d5240a2d5fa9))
- ✔️ [[May 26th, 2025]] *15:19* ((68344d8e-d83d-4c7c-b4aa-56ad71f53ddf))
- ✔️ [[May 26th, 2025]] *20:22* ((683481be-df12-4c94-a56b-fbf9712c96e4))
- ✔️ [[May 26th, 2025]] *21:58* ((6831933e-7f38-436a-91f0-abf1292e15a2))
- ✔️ [[May 26th, 2025]] *21:58* ((68319354-327c-48d4-a6f8-47c04409e98a))
- ✔️ [[May 26th, 2025]] *21:58* ((68331a74-24ed-48d3-9a7f-df9101d3ef5f))
- ✔️ [[May 26th, 2025]] *21:58* ((683481c8-e3cd-462a-8a93-4d19b7e3db3e))
- ✔️ [[May 26th, 2025]] *22:11* ((6831991d-62c9-4091-b3e9-af451051d642))
- ✔️ [[May 26th, 2025]] *22:16* ((65c8d477-cade-4b0b-a8b4-2756a6b98e6e))
- ✔️ [[May 26th, 2025]] *22:16* ((65c8d477-2c6c-4548-9e72-09cee84bec35))
- ✔️ [[May 26th, 2025]] *22:17* ((65c8d455-6e80-4f1e-b650-813a243b696c))
- ✔️ [[May 26th, 2025]] *22:18* ((65f2aaa6-64f6-42e8-8b2c-2a22f8538b30))
- ✔️ [[May 26th, 2025]] *22:18* ((65f2aaa6-690e-4bdc-962a-7c0ddf212f11))
- ✔️ [[May 26th, 2025]] *22:19* ((668e3747-dff2-4f1a-84b2-1d75cbd83aa1))
- ✔️ [[May 26th, 2025]] *22:19* ((668e3747-62ba-4218-8d0e-57effaa7f795))
- ✔️ [[May 26th, 2025]] *22:19* ((6673db54-3eb8-48ba-a840-cbe1ba29b2ff))
- ✔️ [[May 26th, 2025]] *22:19* ((6673db1d-f835-4eb5-9182-9e4a56a85e18))
- ✔️ [[May 26th, 2025]] *22:19* ((6673db98-f12a-4d48-b1ec-281082dfec1f))
- ✔️ [[May 26th, 2025]] *22:19* ((666d40df-e520-45bc-be26-dd4af89767e5))
- ✔️ [[May 26th, 2025]] *22:19* ((65d89628-a424-4291-ad37-c95ed68c7fdd))
- ✔️ [[May 26th, 2025]] *22:20* ((65c9f0a4-861b-4f8e-9738-9e19488e259d))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43b-046c-4682-a958-a14787d04e22))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43c-3e62-4a44-aaf8-ad1f7b0e15c4))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43c-b2de-4ad6-9282-e2d67a0cb6b9))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43d-0487-4c5e-a8ae-cae113812690))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43d-09c9-416b-a127-a865e0fd3b08))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43d-2358-46ad-acf0-3396607b2ace))
- ✔️ [[May 26th, 2025]] *22:20* ((660178c2-5901-423e-976a-dba8a52916c5))
- ✔️ [[May 26th, 2025]] *22:21* ((65d8963d-149e-44b2-a70d-9cee907047ad))
- ✔️ [[May 26th, 2025]] *22:21* ((65c8d477-b5c3-45c1-986d-9daf3563a1d1))
- ✔️ [[May 26th, 2025]] *22:21* ((65d8963d-5b6c-48da-bd21-21e3ffe41570))
- ✔️ [[May 26th, 2025]] *22:21* ((65c8d45b-545c-4ca4-acc3-b35ef663757f))
- ✔️ [[May 26th, 2025]] *22:21* ((65c8d45b-3974-4a0e-ac6e-7dbc798340ab))
- ✔️ [[May 26th, 2025]] *22:21* ((65c35633-d1fd-4840-a6bc-ee79a2db5ffa))
- ✔️ [[May 26th, 2025]] *22:22* ((65c8d45b-1a21-40d2-9003-5b9c13d08e01))
- ✔️ [[May 26th, 2025]] *22:22* ((65d8963d-f00b-44a0-97c3-10f5510ab44e))
- ✔️ [[May 26th, 2025]] *22:22* ((683432dd-8909-4466-b7ec-c4861aaf2fe0))
- ✔️ [[May 26th, 2025]] *22:23* ((65c8d46f-f70f-4d0f-9fce-14c2ab11ab68))
- ✔️ [[May 26th, 2025]] *22:23* Coprire anche aspetti di collaborative modeling
- ### [[2025/06]]
- ✔️ [[02-06-2025]] *23:42* ((6836208c-cf9d-4d40-9f87-db1045f739e1))
- ✔️ [[03-06-2025]] *16:05* ((683f0108-c7ac-41ae-a6bd-b9c02829e6fc))
- ✔️ [[03-06-2025]] *16:07* ((683ee6f2-7304-4ea7-8000-46b4106b3ef5))
- ✔️ [[03-06-2025]] *21:54* ((683620b6-dd45-402c-80d5-0eb8facf914d))
- ✔️ [[04-06-2025]] *11:29* ((683f0792-8597-4118-9816-7f7e48227b97))
- ✔️ [[04-06-2025]] *16:43* ((683f0792-8597-4118-9816-7f7e48227b97))
- ✔️ [[04-06-2025]] *17:08* ((5aecbefd-0816-4ac9-92f7-61d18bdcfa4c))
- ✔️ [[04-06-2025]] *17:38* ((68405bba-69d5-49a4-b785-d058a3d14a27))
- ✔️ [[04-06-2025]] *23:40* ((68405baf-941e-4ee8-9e35-96211c54303f))
- ✔️ [[05-06-2025]] *10:44* ((68414fa8-136d-4af0-b0f0-f91a893374c8))
- ✔️ [[05-06-2025]] *11:53* ((68414f9a-830f-45a2-bded-93014df5d58e))
- ✔️ [[05-06-2025]] *16:51* ((68414fa7-671f-43f2-9bca-3a6e0208567e))
- ✔️ [[05-06-2025]] *23:27* ((683620b6-076a-40c2-a39e-ed6e6b6b38d0))
- ✔️ [[05-06-2025]] *23:27* ((683620b6-807d-4a7b-833c-08a95c81bc76))
- ✔️ [[05-06-2025]] *23:30* ((683620b6-4510-470b-90ef-d8ec1122471c))
- ✔️ [[06-06-2025]] *09:53* ((683e08c8-82e3-4e52-8c5d-16a3c15ba341))
- ✔️ [[06-06-2025]] *10:05* ((683e08c8-c3b2-4f6b-b62f-fc1cd4c1767b))
- ✔️ [[06-06-2025]] *10:06* ((68429a60-0890-4c30-894d-75d34710c00d))
- ✔️ [[06-06-2025]] *13:53* ((6842bc27-d67d-486f-8b13-1d8b1d3616c6))
- ✔️ [[06-06-2025]] *16:52* ((68429a93-62d6-433e-a867-99b90dd5d32d))
- ✔️ [[06-06-2025]] *16:52* ((68429a83-f76a-4f2e-93f9-1d56dc1b3b62))
- ✔️ [[10-06-2025]] *14:39* ((68435147-3695-4233-9c59-30eec6c7bc12))
- ✔️ [[10-06-2025]] *14:40* ((6843518f-f8a7-4629-b184-1ef230d8c645))
- ✔️ [[10-06-2025]] *14:42* ((6843518f-b30c-484e-aba0-97ae9328b3f3))
- ✔️ [[10-06-2025]] *14:43* ((6843518c-4984-4ec8-ac40-c6fba1517d03))
- ✔️ [[11-06-2025]] *14:24* ((684350a8-08ce-44ba-ac20-7512a49e598d))
- ✔️ [[18-06-2025]] *13:14* ((685266e9-3b29-401d-a2de-b8aad90054b7))
- ✔️ [[18-06-2025]] *15:06* ((6852b2bb-9757-4ab4-8661-fdda350c9647))
- ✔️ [[19-06-2025]] *13:06* ((6852f4e6-5a49-40a5-9807-72cafcb3fbc5))
- ✔️ [[19-06-2025]] *15:51* ((68540a72-f93d-4413-9b74-79d3e5716758))
- ✔️ [[19-06-2025]] *16:46* ((6853f169-1d30-4e3e-8bd6-d795d2f01914))
- ✔️ [[19-06-2025]] *18:57* ((d4b795f4-21e9-408f-a6c2-3aadc10c3468))
- ✔️ [[20-06-2025]] *11:45* ((6855230d-2cce-40a9-87b4-d99207252a6b))
- ✔️ [[20-06-2025]] *11:45* ((68552317-3e34-4889-8d03-7671dd9239d7))
- ✔️ [[20-06-2025]] *11:55* ((6855232a-08da-43da-9147-2012a583dc21))
- ✔️ [[20-06-2025]] *11:57* ((93ba52d0-ca92-4181-84c3-f85f7ad67810))
- ✔️ [[20-06-2025]] *12:29* ((68553095-9110-4f54-a545-dd186fa92e2d))
- ✔️ [[21-06-2025]] *11:11* ((68435168-0fca-49d3-b735-8363d04c92ff))
- ✔️ [[21-06-2025]] *22:12* ((e7272b30-e96e-4b85-918e-20c89e27647b))
- ✔️ [[22-06-2025]] *23:25* ((68584e9a-9403-4a2a-87b9-70d3260ead58))
- ✔️ [[23-06-2025]] *14:44* ((6858534a-5eed-4fdc-ab47-ea1bb731df12))
- ✔️ [[23-06-2025]] *17:34* ((68597089-bcc4-49a9-8316-fc9b643c01d6))
- ✔️ [[23-06-2025]] *17:34* ((685970dc-7da2-4c2d-84fe-309f8f827c16))
- ✔️ [[24-06-2025]] *11:52* ((68597072-81a5-4071-801c-b670f12cd482))
- ✔️ [[24-06-2025]] *11:52* ((685970ba-924c-46fe-b831-768ba57cfcca))
- ✔️ [[24-06-2025]] *14:18* ((685a93d1-a8e0-4f42-8a60-8e41eec6c5d6))
- ✔️ [[24-06-2025]] *18:37* ((68584f65-1fb3-44d5-8df6-eff29bbb2ed1))
- ✔️ [[25-06-2025]] *23:44* ((68584f65-4d07-49c4-bbe3-3eac2e4c2435))
- ✔️ [[28-06-2025]] *12:37* ((685f9805-3d35-4797-90e0-4f848ae0fff7))
- ✔️ [[29-06-2025]] *09:30* ((685e49d2-2419-400e-99ae-66426632b820))
- ✔️ [[29-06-2025]] *09:31* ((68584f65-059e-497a-b44b-fbe9081c7b12))
- ✔️ [[29-06-2025]] *15:29* ((c13cae3e-c86c-44b2-9e16-ff89bc12b750))
- ### [[2025/07]]
- ✔️ [[02-07-2025]] *12:55* ((6860dc1b-a2e8-449c-b4e9-f8db54775637))
- ✔️ [[02-07-2025]] *12:56* ((685e499f-4a03-4928-aa8c-ca53263084a5))
- ✔️ [[02-07-2025]] *12:56* ((6858534a-0896-4252-b629-dd6be7fd6be3))
- ✔️ [[02-07-2025]] *12:56* ((6858534b-a36d-412e-9cee-356a6787e0b4))
- ✔️ [[02-07-2025]] *12:56* ((68584e74-0640-44c4-8805-dcadc064aedb))
- ✔️ [[02-07-2025]] *12:57* ((68584e9f-280a-4a6a-afab-e3a5172e1586))
- ✔️ [[02-07-2025]] *12:58* ((68584f65-2e7c-411e-ab67-9159bf073567))
- ✔️ [[02-07-2025]] *12:58* ((68584ec9-3c3f-4ea3-8e31-cb2e6f469bef))
- ✔️ [[02-07-2025]] *17:29* ((6860dc1b-1039-4aff-a908-74f088f170fd))
- ✔️ [[13-07-2025]] *09:51* ((9b0b13f5-4a31-4b9a-81cd-ae678dccdd3d))
- ✔️ [[13-07-2025]] *12:24* ((687351ee-8dbd-4ca4-8ca2-895cfc84715d))
- ✔️ [[13-07-2025]] *21:36* ((68735256-da89-4baa-9f39-76f60ab77e24))
- ✔️ [[13-07-2025]] *21:37* ((686e52cd-0003-4306-936b-f4756724680f))
- ✔️ [[14-07-2025]] *22:08* ((68751c94-e11d-4e71-b78e-fdf51f8f1622))
- ✔️ [[14-07-2025]] *23:07* ((687351fd-8069-4119-85b6-54f93729bde4))
- ✔️ [[15-07-2025]] *08:51* ((6875e9a7-eeaa-484c-ae02-c79c27e13344))
- ✔️ [[May 21st, 2025]] *09:04* ((65c8d43c-9e5e-455f-9c48-cb6d035417fc))
- ✔️ [[May 24th, 2025]] *19:02* ((6831961e-c3a3-4890-99ae-ffda429333c8))
- ✔️ [[May 24th, 2025]] *20:47* ((6659d0ed-b485-4423-9c75-a8f5d715b31f))
- ✔️ [[May 24th, 2025]] *22:02* ((6832257a-63a4-4c89-8353-25f0e94caa51))
- ✔️ [[May 24th, 2025]] *22:02* ((6832257a-4373-4560-a7e2-79fba9f4c9e6))
- ✔️ [[May 24th, 2025]] *22:02* ((682ecc99-b356-4086-9ff8-4e4736018009))
- ✔️ [[May 25th, 2025]] *15:49* ((66e80dfd-0f7c-4020-aa87-906662c9eebd))
- ✔️ [[May 25th, 2025]] *19:26* ((6832257a-f98d-4f5e-850c-ddf8ffd0b5fb))
- ✔️ [[May 25th, 2025]] *19:26* ((6832257a-85cb-46bd-9018-855f59070a41))
- ✔️ [[May 25th, 2025]] *19:27* ((68331e69-7914-4696-8f2e-9ff4e9878686))
- ✔️ [[May 25th, 2025]] *19:29* ((6832257a-7e7e-4ed8-abf8-dd88c6643863))
- ✔️ [[May 25th, 2025]] *19:30* ((6832257a-cbb8-4881-ab20-bebcda629999))
- ✔️ [[May 25th, 2025]] *19:31* ((6832257a-eea4-45f9-ab9f-98dbc36328cf))
- ✔️ [[May 25th, 2025]] *22:49* ((65c8d46e-6599-4319-9683-4f86396c7e29))
- ✔️ [[May 25th, 2025]] *22:49* ((65c8d45b-9775-4e19-88ed-c5d1895df182))
- ✔️ [[May 26th, 2025]] *11:19* ((68342adf-8309-40bf-a38e-5dab74b7a5ea))
- ✔️ [[May 26th, 2025]] *11:20* ((68342adf-0b33-4470-aae1-a3741a2d5432))
- ✔️ [[May 26th, 2025]] *11:22* ((68342adf-7c9d-4937-8d81-7ce37d084360))
- ✔️ [[May 26th, 2025]] *13:23* ((68342adf-daa1-480c-813c-48be1ba86b71))
- ✔️ [[May 26th, 2025]] *13:31* ((68342adf-3362-4bb4-9082-f6050f8cf63c))
- ✔️ [[May 26th, 2025]] *13:45* ((6834435e-3184-483a-a02c-271995950996))
- ✔️ [[May 26th, 2025]] *13:45* ((6834435d-21d2-492c-aac2-21053aba25e1))
- ✔️ [[May 26th, 2025]] *13:47* ((68342adf-d123-444d-b7a2-c4bedd4042dd))
- ✔️ [[May 26th, 2025]] *14:11* ((68342adf-ecdc-4812-ad4f-d5240a2d5fa9))
- ✔️ [[May 26th, 2025]] *15:19* ((68344d8e-d83d-4c7c-b4aa-56ad71f53ddf))
- ✔️ [[May 26th, 2025]] *20:22* ((683481be-df12-4c94-a56b-fbf9712c96e4))
- ✔️ [[May 26th, 2025]] *21:58* ((6831933e-7f38-436a-91f0-abf1292e15a2))
- ✔️ [[May 26th, 2025]] *21:58* ((68319354-327c-48d4-a6f8-47c04409e98a))
- ✔️ [[May 26th, 2025]] *21:58* ((68331a74-24ed-48d3-9a7f-df9101d3ef5f))
- ✔️ [[May 26th, 2025]] *21:58* ((683481c8-e3cd-462a-8a93-4d19b7e3db3e))
- ✔️ [[May 26th, 2025]] *22:11* ((6831991d-62c9-4091-b3e9-af451051d642))
- ✔️ [[May 26th, 2025]] *22:16* ((65c8d477-cade-4b0b-a8b4-2756a6b98e6e))
- ✔️ [[May 26th, 2025]] *22:16* ((65c8d477-2c6c-4548-9e72-09cee84bec35))
- ✔️ [[May 26th, 2025]] *22:17* ((65c8d455-6e80-4f1e-b650-813a243b696c))
- ✔️ [[May 26th, 2025]] *22:18* ((65f2aaa6-64f6-42e8-8b2c-2a22f8538b30))
- ✔️ [[May 26th, 2025]] *22:18* ((65f2aaa6-690e-4bdc-962a-7c0ddf212f11))
- ✔️ [[May 26th, 2025]] *22:19* ((668e3747-dff2-4f1a-84b2-1d75cbd83aa1))
- ✔️ [[May 26th, 2025]] *22:19* ((668e3747-62ba-4218-8d0e-57effaa7f795))
- ✔️ [[May 26th, 2025]] *22:19* ((6673db54-3eb8-48ba-a840-cbe1ba29b2ff))
- ✔️ [[May 26th, 2025]] *22:19* ((6673db1d-f835-4eb5-9182-9e4a56a85e18))
- ✔️ [[May 26th, 2025]] *22:19* ((6673db98-f12a-4d48-b1ec-281082dfec1f))
- ✔️ [[May 26th, 2025]] *22:19* ((666d40df-e520-45bc-be26-dd4af89767e5))
- ✔️ [[May 26th, 2025]] *22:19* ((65d89628-a424-4291-ad37-c95ed68c7fdd))
- ✔️ [[May 26th, 2025]] *22:20* ((65c9f0a4-861b-4f8e-9738-9e19488e259d))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43b-046c-4682-a958-a14787d04e22))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43c-3e62-4a44-aaf8-ad1f7b0e15c4))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43c-b2de-4ad6-9282-e2d67a0cb6b9))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43d-0487-4c5e-a8ae-cae113812690))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43d-09c9-416b-a127-a865e0fd3b08))
- ✔️ [[May 26th, 2025]] *22:20* ((65c8d43d-2358-46ad-acf0-3396607b2ace))
- ✔️ [[May 26th, 2025]] *22:20* ((660178c2-5901-423e-976a-dba8a52916c5))
- ✔️ [[May 26th, 2025]] *22:21* ((65d8963d-149e-44b2-a70d-9cee907047ad))
- ✔️ [[May 26th, 2025]] *22:21* ((65c8d477-b5c3-45c1-986d-9daf3563a1d1))
- ✔️ [[May 26th, 2025]] *22:21* ((65d8963d-5b6c-48da-bd21-21e3ffe41570))
- ✔️ [[May 26th, 2025]] *22:21* ((65c8d45b-545c-4ca4-acc3-b35ef663757f))
- ✔️ [[May 26th, 2025]] *22:21* ((65c8d45b-3974-4a0e-ac6e-7dbc798340ab))
- ✔️ [[May 26th, 2025]] *22:21* ((65c35633-d1fd-4840-a6bc-ee79a2db5ffa))
- ✔️ [[May 26th, 2025]] *22:22* ((65c8d45b-1a21-40d2-9003-5b9c13d08e01))
- ✔️ [[May 26th, 2025]] *22:22* ((65d8963d-f00b-44a0-97c3-10f5510ab44e))
- ✔️ [[May 26th, 2025]] *22:22* ((683432dd-8909-4466-b7ec-c4861aaf2fe0))
- ✔️ [[May 26th, 2025]] *22:23* ((65c8d46f-f70f-4d0f-9fce-14c2ab11ab68))
- ✔️ [[May 26th, 2025]] *22:23* Coprire anche aspetti di collaborative modeling
- ### [[2025/06]]
- ✔️ [[02-06-2025]] *23:42* ((6836208c-cf9d-4d40-9f87-db1045f739e1))
- ✔️ [[03-06-2025]] *16:05* ((683f0108-c7ac-41ae-a6bd-b9c02829e6fc))
- ✔️ [[03-06-2025]] *16:07* ((683ee6f2-7304-4ea7-8000-46b4106b3ef5))
- ✔️ [[03-06-2025]] *21:54* ((683620b6-dd45-402c-80d5-0eb8facf914d))
- ✔️ [[04-06-2025]] *11:29* ((683f0792-8597-4118-9816-7f7e48227b97))
- ✔️ [[04-06-2025]] *16:43* ((683f0792-8597-4118-9816-7f7e48227b97))
- ✔️ [[04-06-2025]] *17:08* ((5aecbefd-0816-4ac9-92f7-61d18bdcfa4c))
- ✔️ [[04-06-2025]] *17:38* ((68405bba-69d5-49a4-b785-d058a3d14a27))
- ✔️ [[04-06-2025]] *23:40* ((68405baf-941e-4ee8-9e35-96211c54303f))
- ✔️ [[05-06-2025]] *10:44* ((68414fa8-136d-4af0-b0f0-f91a893374c8))
- ✔️ [[05-06-2025]] *11:53* ((68414f9a-830f-45a2-bded-93014df5d58e))
- ✔️ [[05-06-2025]] *16:51* ((68414fa7-671f-43f2-9bca-3a6e0208567e))
- ✔️ [[05-06-2025]] *23:27* ((683620b6-076a-40c2-a39e-ed6e6b6b38d0))
- ✔️ [[05-06-2025]] *23:27* ((683620b6-807d-4a7b-833c-08a95c81bc76))
- ✔️ [[05-06-2025]] *23:30* ((683620b6-4510-470b-90ef-d8ec1122471c))
- ✔️ [[06-06-2025]] *09:53* ((683e08c8-82e3-4e52-8c5d-16a3c15ba341))
- ✔️ [[06-06-2025]] *10:05* ((683e08c8-c3b2-4f6b-b62f-fc1cd4c1767b))
- ✔️ [[06-06-2025]] *10:06* ((68429a60-0890-4c30-894d-75d34710c00d))
- ✔️ [[06-06-2025]] *13:53* ((6842bc27-d67d-486f-8b13-1d8b1d3616c6))
- ✔️ [[06-06-2025]] *16:52* ((68429a93-62d6-433e-a867-99b90dd5d32d))
- ✔️ [[06-06-2025]] *16:52* ((68429a83-f76a-4f2e-93f9-1d56dc1b3b62))
- ✔️ [[10-06-2025]] *14:39* ((68435147-3695-4233-9c59-30eec6c7bc12))
- ✔️ [[10-06-2025]] *14:40* ((6843518f-f8a7-4629-b184-1ef230d8c645))
- ✔️ [[10-06-2025]] *14:42* ((6843518f-b30c-484e-aba0-97ae9328b3f3))
- ✔️ [[10-06-2025]] *14:43* ((6843518c-4984-4ec8-ac40-c6fba1517d03))
- ✔️ [[11-06-2025]] *14:24* ((684350a8-08ce-44ba-ac20-7512a49e598d))
- ✔️ [[18-06-2025]] *13:14* ((685266e9-3b29-401d-a2de-b8aad90054b7))
- ✔️ [[18-06-2025]] *15:06* ((6852b2bb-9757-4ab4-8661-fdda350c9647))
- ✔️ [[19-06-2025]] *13:06* ((6852f4e6-5a49-40a5-9807-72cafcb3fbc5))
- ✔️ [[19-06-2025]] *15:51* ((68540a72-f93d-4413-9b74-79d3e5716758))
- ✔️ [[19-06-2025]] *16:46* ((6853f169-1d30-4e3e-8bd6-d795d2f01914))
- ✔️ [[19-06-2025]] *18:57* ((d4b795f4-21e9-408f-a6c2-3aadc10c3468))
- ✔️ [[20-06-2025]] *11:45* ((6855230d-2cce-40a9-87b4-d99207252a6b))
- ✔️ [[20-06-2025]] *11:45* ((68552317-3e34-4889-8d03-7671dd9239d7))
- ✔️ [[20-06-2025]] *11:55* ((6855232a-08da-43da-9147-2012a583dc21))
- ✔️ [[20-06-2025]] *11:57* ((93ba52d0-ca92-4181-84c3-f85f7ad67810))
- ✔️ [[20-06-2025]] *12:29* ((68553095-9110-4f54-a545-dd186fa92e2d))
- ✔️ [[21-06-2025]] *11:11* ((68435168-0fca-49d3-b735-8363d04c92ff))
- ✔️ [[21-06-2025]] *22:12* ((e7272b30-e96e-4b85-918e-20c89e27647b))
- ✔️ [[22-06-2025]] *23:25* ((68584e9a-9403-4a2a-87b9-70d3260ead58))
- ✔️ [[23-06-2025]] *14:44* ((6858534a-5eed-4fdc-ab47-ea1bb731df12))
- ✔️ [[23-06-2025]] *17:34* ((68597089-bcc4-49a9-8316-fc9b643c01d6))
- ✔️ [[23-06-2025]] *17:34* ((685970dc-7da2-4c2d-84fe-309f8f827c16))
- ✔️ [[24-06-2025]] *11:52* ((68597072-81a5-4071-801c-b670f12cd482))
- ✔️ [[24-06-2025]] *11:52* ((685970ba-924c-46fe-b831-768ba57cfcca))
- ✔️ [[24-06-2025]] *14:18* ((685a93d1-a8e0-4f42-8a60-8e41eec6c5d6))
- ✔️ [[24-06-2025]] *18:37* ((68584f65-1fb3-44d5-8df6-eff29bbb2ed1))
- ✔️ [[25-06-2025]] *23:44* ((68584f65-4d07-49c4-bbe3-3eac2e4c2435))
- ✔️ [[28-06-2025]] *12:37* ((685f9805-3d35-4797-90e0-4f848ae0fff7))
- ✔️ [[29-06-2025]] *09:30* ((685e49d2-2419-400e-99ae-66426632b820))
- ✔️ [[29-06-2025]] *09:31* ((68584f65-059e-497a-b44b-fbe9081c7b12))
- ✔️ [[29-06-2025]] *15:29* ((c13cae3e-c86c-44b2-9e16-ff89bc12b750))
- ### [[2025/07]]
- ✔️ [[02-07-2025]] *12:55* ((6860dc1b-a2e8-449c-b4e9-f8db54775637))
- ✔️ [[02-07-2025]] *12:56* ((685e499f-4a03-4928-aa8c-ca53263084a5))
- ✔️ [[02-07-2025]] *12:56* ((6858534a-0896-4252-b629-dd6be7fd6be3))
- ✔️ [[02-07-2025]] *12:56* ((6858534b-a36d-412e-9cee-356a6787e0b4))
- ✔️ [[02-07-2025]] *12:56* ((68584e74-0640-44c4-8805-dcadc064aedb))
- ✔️ [[02-07-2025]] *12:57* ((68584e9f-280a-4a6a-afab-e3a5172e1586))
- ✔️ [[02-07-2025]] *12:58* ((68584f65-2e7c-411e-ab67-9159bf073567))
- ✔️ [[02-07-2025]] *12:58* ((68584ec9-3c3f-4ea3-8e31-cb2e6f469bef))
- ✔️ [[02-07-2025]] *17:29* ((6860dc1b-1039-4aff-a908-74f088f170fd))
- ✔️ [[13-07-2025]] *09:51* ((9b0b13f5-4a31-4b9a-81cd-ae678dccdd3d))
- ✔️ [[13-07-2025]] *12:24* ((687351ee-8dbd-4ca4-8ca2-895cfc84715d))
- ✔️ [[13-07-2025]] *21:36* ((68735256-da89-4baa-9f39-76f60ab77e24))
- ✔️ [[13-07-2025]] *21:37* ((686e52cd-0003-4306-936b-f4756724680f))
- ✔️ [[14-07-2025]] *22:08* ((68751c94-e11d-4e71-b78e-fdf51f8f1622))
- ✔️ [[14-07-2025]] *23:07* ((687351fd-8069-4119-85b6-54f93729bde4))
- ✔️ [[15-07-2025]] *08:51* ((6875e9a7-eeaa-484c-ae02-c79c27e13344))
- ✔️ [[18-07-2025]] *18:13* ((68584e7c-bb5f-40fe-876d-21fe8d87565f))
- ✔️ [[19-07-2025]] *12:10* ((686e52d5-3bc5-4420-8cdc-b589ceb2dc04))
- ✔️ [[19-07-2025]] *12:15* ((6873c94d-06e6-466f-a125-f321b20c39fb))
- ✔️ [[23-07-2025]] *13:29* ((685e49d2-2419-400e-99ae-66426632b820))
- ✔️ [[23-07-2025]] *15:30* ((f2b64850-c185-41e8-b5fd-56f2f425379a))
- ✔️ [[30-07-2025]] *09:03* ((68874dfe-bd98-41ce-8216-3663c2439bc2))
- ✔️ [[30-07-2025]] *17:01* ((688a33c3-76cc-4772-8f84-9248e6d96027))
- ✔️ [[30-07-2025]] *18:00* ((6858534b-8fe7-4b13-8739-b45d7ac5ea75))
- ✔️ [[30-07-2025]] *18:01* ((6860e8a1-9d1e-4c28-8936-65e07c1023c4))
- ### [[2025/08]]
- ✔️ [[01-08-2025]] *15:38* ((688cc320-7b06-4594-943f-f302da78f521))
- ✔️ [[01-08-2025]] *16:56* ((688b9643-5053-49b9-b9ed-b559e7bf653c))
- ✔️ [[07-08-2025]] *09:11* ((6884f13b-60da-48da-abe9-8a522cde5d29))
- ✔️ [[07-08-2025]] *15:40* ((68584ec9-a2a1-4685-b559-141f96bb61f2))
- ✔️ [[07-08-2025]] *16:13* ((6894a6d1-0613-4b32-ac49-0c3a3fd0753d))
- ✔️ [[07-08-2025]] *17:10* ((6894a6a2-bbab-4ec6-bcf4-1821588feb0f))
- ✔️ [[08-08-2025]] *12:45* ((6895c9fa-c1e6-4f9b-a4b4-f53c7eefa296))
- ✔️ [[08-08-2025]] *15:22* ((68584ea7-8fde-4a5e-9367-f7054ced2f88))
- ✔️ [[08-08-2025]] *15:43* ((6895c9da-572c-48e2-8d71-80a61f7e0c81))
- ✔️ [[08-08-2025]] *15:53* ((6873c94d-06e6-466f-a125-f321b20c39fb))
- ✔️ [[18-08-2025]] *01:35* ((6864fa38-39bb-42b6-94f5-ba9bccfc4f04))
- ✔️ [[19-08-2025]] *14:43* ((68960139-341c-40fa-9a35-04c20f74ad14))
- ✔️ [[19-08-2025]] *14:45* ((6863b98d-74e6-435a-8631-c03155c89300))
- ✔️ [[19-08-2025]] *18:03* ((68653364-55e9-4d49-85e1-0c8a9f186e8e))
- ✔️ [[19-08-2025]] *18:04* ((6863a4ff-c366-4708-8009-34f6b34fedbb))
- ✔️ [[19-08-2025]] *18:06* ((6863a692-e9b0-4b8f-ba41-a9d4a1043651))
- ✔️ [[19-08-2025]] *18:07* ((686503c5-75e8-45ab-9237-aa9eb32c63cc))
- ✔️ [[19-08-2025]] *18:08* ((6863a8b5-35d5-492e-a8cf-2549750d9965))
- ✔️ [[20-08-2025]] *16:11* ((68960139-c4ea-441c-9d45-89381bddcfb9))
- ✔️ [[21-08-2025]] *16:42* ((68960139-1246-4fb7-a933-cc75804483b7))
- ✔️ [[25-08-2025]] *16:26* ((68ac6e66-ba4e-41e7-9637-5fe847dfc8ba))
- ✔️ [[26-08-2025]] *23:05* ((689467c8-88b1-45b0-b58c-99fa0d0b73a8))
- ✔️ [[26-08-2025]] *23:06* ((68960139-bbd3-44c1-a39a-5f0782e5bfad))
- ✔️ [[31-08-2025]] *11:47* ((68ac6e54-e572-42f4-8116-625b4d85d757))
- ✔️ [[31-08-2025]] *11:52* ((68960139-34fc-4ac4-8745-f8a2bb7cb6e9))
- ### [[2025/09]]
- ✔️ [[01-09-2025]] *00:04* ((68b4c69b-fa0b-41c1-9633-b87c6cf6ab33))
- ✔️ [[01-09-2025]] *00:04* ((68b4c69b-7fdf-4663-89af-ac6df65d88af))
- ✔️ [[01-09-2025]] *12:08* ((68b4c69b-4d77-4192-9cff-d9f87cb200f4))
- ✔️ [[02-09-2025]] *10:06* ((68946800-a5fe-4f75-af64-8b2509daf7fd))
- ✔️ [[02-09-2025]] *10:20* ((68b6a403-1ce2-4fe5-9668-54e32ac0e222))
- ✔️ [[02-09-2025]] *11:28* ((68b598e8-992a-433f-b685-5318c5ba0f4d))
- ✔️ [[02-09-2025]] *11:29* ((68b57381-292d-4e53-8b79-b0378d3ddcca))
- ✔️ [[02-09-2025]] *11:29* ((68b6a86a-0914-4535-b10a-d81519358f6a))
- ✔️ [[02-09-2025]] *15:48* ((6895c9da-572c-48e2-8d71-80a61f7e0c81))
- ✔️ [[03-09-2025]] *10:30* ((68b6f4f4-a42f-4e0a-a42d-427d478a4423))
- ✔️ [[03-09-2025]] *15:05* DONE Regolamento Corsi Dottorato
:LOGBOOK:
CLOCK: [2025-09-03 Wed 15:05:52]--[2025-09-03 Wed 15:05:52] => 00:00:00
:END:
- ### [[2025/09]]
- ✔️ [[08-09-2025]] *12:58* Check attività formativa
:LOGBOOK:
CLOCK: [2025-09-08 Mon 12:58:23]--[2025-09-08 Mon 12:58:24] => 00:00:01
:END:
- ✔️ [[08-09-2025]] *12:58* DONE Scrivere a Alessandro Celi per Portatili
:LOGBOOK:
CLOCK: [2025-09-08 Mon 12:58:48]--[2025-09-08 Mon 12:58:48] => 00:00:00
:END:
- ✔️ [[09-09-2025]] *15:02* ((68bfdd58-6374-44fb-a187-ef25e180e2b1))
- ✔️ [[09-09-2025]] *15:38* ((68a423d6-ddac-4f6f-b162-51318a682db6))
- ✔️ [[15-09-2025]] *13:05* DONE Check studente Giordano
- ✔️ [[15-09-2025]] *13:36* DONE **Verbale ultimo collegio**
- ✔️ [[20-09-2025]] *16:40* ((68946800-1268-43e8-8971-44b6c0d2ce9c))
- ✔️ [[24-09-2025]] *14:57* ((68d3ea95-45ab-43bb-86c6-506a00ca5420))
- ✔️ [[24-09-2025]] *16:01* ((68d3ea95-6c8a-40f9-93ff-5d930e6a7174))
- ✔️ [[24-09-2025]] *16:01* ((68d3ea95-2936-4efb-8e99-d9282435fff9))
- ✔️ [[24-09-2025]] *16:01* ((68d3ea95-f822-42f4-a4f6-6da2d5adfb75))
- ✔️ [[25-09-2025]] *11:47* ((68d3ea95-7a33-412c-a9e0-effaf3e484a0))
- ✔️ [[25-09-2025]] *11:52* ((68d3ea95-b046-49bf-9509-651f1e88b06e))
- ✔️ [[25-09-2025]] *12:42* ((68d3ea95-00ff-47d6-b92f-0243f944f2c0))
- ✔️ [[25-09-2025]] *16:38* ((68d3ea95-8858-468b-9c3a-4895f500a9f9))
- ✔️ [[26-09-2025]] *11:45* ((68584ec4-baa8-4664-ab02-cb70ee11bad5))
- ✔️ [[26-09-2025]] *18:20* ((68d3ea95-f018-4b23-9c51-b0ee94287661))
- ✔️ [[28-09-2025]] *17:55* DONE **14:30 - 16:30** - [[TEACHING]] - Pianificazione didattica
- ✔️ [[28-09-2025]] *18:41* DONE **16:30 - 17:30** Titolo per talks MODELS e ASE
- ✔️ [[28-09-2025]] *18:41* DONE **7:00 - 10:00** : Personal
:LOGBOOK:
CLOCK: [2025-09-28 Sun 18:41:28]--[2025-09-28 Sun 18:41:28] => 00:00:00
:END:
- ✔️ [[28-09-2025]] *21:48* DONE **10:00-12:00** - [[Deliverable D2.1]] #todoist-task #PROJECTS/MOSAICO
:LOGBOOK:
CLOCK: [2025-09-28 Sun 21:48:01]--[2025-09-28 Sun 21:48:02] => 00:00:01
:END:
- ✔️ [[28-09-2025]] *22:01*
- ✔️ [[30-09-2025]] *21:33* ((68584ec9-e757-4b59-adae-09b0616243c2))
- ### [[2025/10]]
- ✔️ [[02-10-2025]] *11:07* ((68dc3033-9770-4fd0-b2ea-87025e587615))
- ✔️ [[02-10-2025]] *14:19* ((68584ec9-a8ef-4798-a441-6ee772d7e22b))
- ✔️ [[08-10-2025]] *15:23* ((68df8e5d-3e7c-4377-8a9c-151d1a6f97ae))
- ✔️ [[08-10-2025]] *15:23* ((68df8e5d-e7d8-4964-9f1a-765fdd2a28e3))
- ✔️ [[13-10-2025]] *21:53* ((68bac2ea-d21f-45cb-b0b0-b7ba4bde8bf8))
- ✔️ [[13-10-2025]] *21:54* ((68bac2ea-edb2-4b78-b0eb-182a010233ec))
- ✔️ [[19-10-2025]] *14:22* DONE Aggiornare mailing list collegio
:LOGBOOK:
CLOCK: [2025-10-19 Sun 14:22:27]--[2025-10-19 Sun 14:22:28] => 00:00:01
:END:
- ✔️ [[19-10-2025]] *15:38* DONE Finalizzare OdG
:LOGBOOK:
CLOCK: [2025-10-19 Sun 15:38:53]--[2025-10-19 Sun 15:38:53] => 00:00:00
:END:
- ✔️ [[19-10-2025]] *16:01* DONE Convocare studenti nuovo ciclo
- ✔️ [[19-10-2025]] *20:58* DONE Convocazione prossimo collegio
:LOGBOOK:
CLOCK: [2025-10-19 Sun 20:58:34]--[2025-10-19 Sun 20:58:35] => 00:00:01
:END:
- ✔️ [[29-10-2025]] *18:30* DONE Questione tabella Excel dottorandi
:LOGBOOK:
CLOCK: [2025-09-03 Wed 15:05:41]--[2025-10-29 Wed 18:30:23] => 1347:24:42
:END:
- ### [[2025/11]]
- ✔️ [[05-11-2025]] *15:38* ((68e76ae4-ab11-47e1-81fc-f2973dab9f1a))
- ✔️ [[11-11-2025]] *22:43* DONE Tania scrive ai titolari dei corsi precedenti chiedendo se vogliono continuare ad erogare il corso come da offerta formativa 24/25 [[people/TaniaDiMascio]]
:LOGBOOK:
CLOCK: [2025-10-23 Thu 15:17:36]--[2025-11-11 Tue 22:43:15] => 463:25:39
:END:
- ✔️ [[11-11-2025]] *22:43* ((68e76ae4-b361-4812-85ba-d7c07be80b1c))
- ✔️ [[21-11-2025]] *15:23* DONE [[Assicurazione della Qualità di Corsi di Studio e di dottorato e Dipartimenti - Audizione del 21 novembre 2025]] #todoist-task #SERVICES/PHDICT
- ✔️ [[21-11-2025]] *16:24* DONE [[Progettazione Offerta Formativa]] #SERVICES/PHDICT #todoist-task
:LOGBOOK:
CLOCK: [2025-11-21 Fri 16:24:40]--[2025-11-21 Fri 16:24:41] => 00:00:01
:END:
- ✔️ [[22-11-2025]] *21:36* ((69221dd6-8d69-4210-b1f7-d3afa44ac65b))
- ✔️ [[23-11-2025]] *09:38* ((69190e77-3111-4845-b9ae-792f9f3382e6))
- ✔️ [[23-11-2025]] *09:41* ((68584e9a-7058-4550-bcde-ecae1dec7e70))
- ✔️ [[23-11-2025]] *09:41* ((68584e9a-3433-49a6-b66e-3f365c4b0713))
- ✔️ [[Nov 30th, 2025]] *20:50* ((68df8e5d-3f53-4e39-bb5c-c0dbe9368211))
- ✔️ [[Nov 30th, 2025]] *20:50* ((68df8e5d-fbdf-4070-ba1e-3a748f11766a))
- ### [[2025/12]]
- ✔️ [[Dec 9th, 2025]] *14:13* :LOGBOOK:
CLOCK: [2025-12-09 Tue 14:12:29]--[2025-12-09 Tue 14:13:07] => 00:00:38
:END:
- ✔️ [[Dec 16th, 2025]] *09:55* ((6938231c-2456-474f-b723-54a14064632f))
pages/Deliverable D2.1.md
+535
View File
@@ -0,0 +1,535 @@
tags:: #todoist-task, [[PROJECTS/MOSAICO]]
date:: [[25-08-2025]] - 08:38
progress:: {{renderer :todomaster}}
- ### References
- [Explore models in AI Toolkit](https://code.visualstudio.com/docs/intelligentapps/models)
- [AI Toolkit for Visual Studio Code - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=ms-windows-ai-studio.windows-ai-studio)
- [Specification - Agent2Agent (A2A) Protocol](https://a2a-protocol.org/latest/specification/#554-agentskill-object)
- {{embed ((6863b98d-74e6-435a-8631-c03155c89300))}}
- ### Tasks
- TODO Guardare i TODOs da [[Missione ROMA Mosaico]] #todoist-task #PROJECTS/MOSAICO #meeting
- DONE Finalizzare revisione di Section 3 - [[07-08-2025]]
id:: 6894a6d1-0613-4b32-ac49-0c3a3fd0753d
- DONE Rivedere Section 5 - [[07-08-2025]]
id:: 6894a6a2-bbab-4ec6-bcf4-1821588feb0f
- DONE Da finalizzare Tabella 4 con lista di marketplace e agent repositories.
id:: 68a423d6-ddac-4f6f-b162-51318a682db6
:LOGBOOK:
CLOCK: [2025-09-09 Tue 15:38:36]--[2025-09-09 Tue 15:38:36] => 00:00:00
:END:
- DONE Raffinare il metamodello in Section 6 - [[08-08-2025]]
id:: 68960139-341c-40fa-9a35-04c20f74ad14
:LOGBOOK:
CLOCK: [2025-08-19 Tue 14:43:06]--[2025-08-19 Tue 14:43:07] => 00:00:01
:END:
- DONE Aggiornare il metamodello guardando quanto da Antonio ne suo deliverable di WP1
id:: 68960139-34fc-4ac4-8745-f8a2bb7cb6e9
- [imtatlantiquefr.sharepoint.com/sites/MOSAICO/Shared Documents/Forms/AllItems.aspx?id=%2Fsites%2FMOSAICO%2FShared Documents%2FWork Packages%2FWP1%2FD1%2E1%2F20250801 draft - only Sections 2 and 3%2Epdf&parent=%2Fsites%2FMOSAICO%2FShared Documents%2FWork Packages%2FWP1%2FD1%2E1](https://imtatlantiquefr.sharepoint.com/sites/MOSAICO/Shared%20Documents/Forms/AllItems.aspx?id=%2Fsites%2FMOSAICO%2FShared%20Documents%2FWork%20Packages%2FWP1%2FD1%2E1%2F20250801%20draft%20%2D%20only%20Sections%202%20and%203%2Epdf&parent=%2Fsites%2FMOSAICO%2FShared%20Documents%2FWork%20Packages%2FWP1%2FD1%2E1)
- Da guardare particolarmente e' [Agntcy](https://docs.agntcy.org/#vision)
- DONE Inserire in Section 7 una prima bozza dell'architettura del Repository
id:: 68960139-bbd3-44c1-a39a-5f0782e5bfad
:LOGBOOK:
CLOCK: [2025-08-19 Tue 18:09:34]--[2025-08-26 Tue 23:06:08] => 172:56:34
:END:
- Partire da qualche slide in WP5?
- DONE Scrivere le conclusioni
id:: 68960139-c4ea-441c-9d45-89381bddcfb9
- DONE Lavorare su capitolo 4 a partire dal contenuto del paper EMSE
id:: 68960139-1246-4fb7-a933-cc75804483b7
:LOGBOOK:
CLOCK: [2025-08-19 Tue 18:09:37]--[2025-08-21 Thu 16:42:09] => 46:32:32
:END:
- DONE Rimuovere dalla bib tutte le occorrenze univaq
id:: 68ac6e66-ba4e-41e7-9637-5fe847dfc8ba
:LOGBOOK:
CLOCK: [2025-08-25 Mon 16:26:24]--[2025-08-25 Mon 16:26:24] => 00:00:00
:END:
- DONE Ripassata finale prima di mandare ai revisori
collapsed:: true
- ### Notes
id:: 689467c8-88b1-45b0-b58c-99fa0d0b73a8
- Review di Antonio Garcia ( ![D2_1-InternalReview_version_20250827-agd220250907.pdf](../assets/D2_1-InternalReview_version_20250827-agd220250907_1758720457899_0.pdf) )
- DONE Quick note about the English: I see a lot of "agents monitoring" which should be "agent monitoring", for example. In general, when you have "noun verb-ing", "noun" tends to be singular.
id:: 68d3ea95-45ab-43bb-86c6-506a00ca5420
- DONE Did you not consider LangGraph for Ch3? If so, why? (It's a big player, so this was somewhat surprising - did you run into issues with the license, or did you not consider it as a MAS framework?)
id:: 68d3ea95-6c8a-40f9-93ff-5d930e6a7174
:LOGBOOK:
CLOCK: [2025-09-24 Wed 16:01:00]--[2025-09-24 Wed 16:01:02] => 00:00:02
:END:
- DONE Figure 3 doesn't really explain the notation used.
id:: 68d3ea95-7a33-412c-a9e0-effaf3e484a0
- DONE For FC3.3 (continual evolution), have you considered options like Letta or MemGPT for self-improving agents?
- DONE For the METAGENTE study: in the optimisation loop, do you evaluate the new prompt based on how it does across a population of repositories, or is it only against one repository? The latter sounds like it could have a risk of over-fitting.
id:: 68d3ea95-2936-4efb-8e99-d9282435fff9
:LOGBOOK:
CLOCK: [2025-09-24 Wed 16:01:22]--[2025-09-24 Wed 16:01:23] => 00:00:01
:END:
- DONE Figure 13(a) has an odd "5" before "ROUGE-1".
- DONE In Section 4.3.4, besides doing the Wilcoxon paired test for statistical significance, I'd also suggest looking at effect sizes. My intuition is that even if the differences are statistically significant, the effect sizes will be very small.
id:: 68d3ea95-00ff-47d6-b92f-0243f944f2c0
- TODO In Figure 9, it feels like each spider chart has its own axis limits. They should all be using the same axis limits, so that the spider charts can be compared to each other.
- DONE The report never defines what PTM stands for (used in Ch5).
id:: 68d3ea95-f822-42f4-a4f6-6da2d5adfb75
- DONE Given the talk we attended from Barahona at LLMA4SE 2025 on the various levels of "openness" of LLMs, your discussion of AI Agent List [77] sounds like this marketplace may be oversimplifying things. It may be worth mentioning the need for more nuance in that regard?
id:: 68d3ea95-8858-468b-9c3a-4895f500a9f9
- ((68bac2bb-1db8-41cb-81ed-7ef7f76e1491))
- DONE Please take a close look at my comments on Figure 24. I think the metamodel should be expanded in a number of ways. For example, in OpenTelemetry, spans are organised into a tree - this doesn't seem to be reflected in TelemetryRecord.
id:: 68d3ea95-f018-4b23-9c51-b0ee94287661
:LOGBOOK:
CLOCK: [2025-09-26 Fri 18:20:20]--[2025-09-26 Fri 18:20:21] => 00:00:01
:END:
- TODO I also think that Figure 25 needs some improvements: it should stay closer to UML object diagram notation, and it may be best to split it into static parts (about the agents themselves and their relationships) and dynamic parts (about the traces for specific executions of those agents). In fact, I would divide the trace for the separate phases, and I'd suggest expanding further the instantiation (making it more detailed and using all the types in the taxonomy).
- TODO For the MOSAICO agent repository architecture: would it make sense to integrate some type of vector database to allow for semantic search over the descriptions of the agents? It's quite likely that we will leave it up to the LLM in the reference agent to invoke your MCP tool for finding the most relevant agents, and that will most likely require semantic search.
- DONE Incidentally, I don't think MCP is documented via OpenAPI: MCP is JSON-RPC based rather than REST.
id:: 68d3ea95-b046-49bf-9509-651f1e88b06e
- TODO For telemetry dashboards, you mention Grafana. That's good for metrics, but can it display traces as well, or should we use LangFuse for that?
- Da considerare anche il prompt?
- {{renderer :mermaid_68668a24-ce43-472e-b787-a53b895f7c75, 3}}
collapsed:: true
- ```mermaid
classDiagram
class Agent {
id
name
version
owner
}
class Capability {
domain
taskType
supportedLanguages
inputFormats
outputFormats
}
class PerformanceKPI {
accuracy
latencyMs
resourceConsumption
robustnessMetrics
}
class Governance {
license
dataResidency
GDPRCompliance
auditTrailAvailable
}
class FairnessEthics {
biasDetected
fairnessConstraints
explanationCapabilities
}
class RuntimeEnvironment {
runtime
requiredLibraries
hardwareAcceleration
}
class Provenance {
trainingDataSources
modelLineage
lastUpdated
}
class ContactInfo {
maintainerEmail
documentationUrl
}
class AgentRepository {
<<service>>
}
Agent --> Capability : has
Agent --> PerformanceKPI : provides
Agent --> Governance
Agent --> FairnessEthics
Agent --> RuntimeEnvironment
Agent --> Provenance
Agent --> ContactInfo
AgentRepository --> Agent : manages
```
- Agents should be also marked if they keep information or not for IP purposes.
-
- <img src="https://www.plantuml.com/plantuml/png/VLNTRzem47_tNs7rfT8agcsFqJILKagHw42GIdkhJ78b5ewT-OCERVlVTuuXSKB42zZd-_ZTtUykbDuRoxHrfI2tT2fT2PfPhgGXW1Vw191lMRPFZnNGFuJIwS_LOZwPftYSlvoE_qXGVe5IwMEZkdbUhjEtTBf-mSjY-MCMpcVj50IKOFLnwMpbR6soMCxmDrsF9rFyVnZFPkFPr5lSqedIG45QRZaOaWbc31tlK50RpXyJogN5asGb9DHOpUKEhwNAGKoOpcCP6CDsC57IedtqK21qNJ6DBYpew2672cGECiFOIGZhKGKK6oMSBzaG6bw7yFNiU3DSGopn9TvOB5uagxGgA-kh6Gcr4ksrGJ1HGh2j2fqRWf752YjcCJkPqDCXoiHX_WTk1hr4qQG1QPovefCoiwzVU7x6W5bdcbSUGPGGbzZxwAvgCbocc2ebhdTwl9g_xU5uQHfesJEsTLrRndg0syWRszNKQ5fzIsVgWCLYCWFAP4wTfz0fmagh0yz1rp4wi1eGhrxzMWADvXensRwgqw9BZJfUqaHkpHSgO_rA5SZ_3wPX3RySCg-CMTyOZh-EqPjLMQ_GTVBJ0nEkPa-TVAaaHxfw-s3yWBDHb4plUv5na5ZEB8l0lmEpBgP_r2WKPDUxR0iqBPH0MkNARGL453alb4SCs6ytqYTfDJRAwGmQkZqfNJARz5VIWEjWECpvPrSoULwO_VuPqEtj_QIKTFPhgFGQH5Z01QyC2IFsxUzer5qpySFbz7VCUZFTjOmdcPoUHgFlzERBtTsdcp362MLPXhj8S5E0YPK-1oK_cWc5tvLGt9fBBwS1J9270-OjTT17e1daT7li-BbfPomvqx-l5Do5GKjynGU2nIHFQCWA3FtWjY2aHT81NvFIjouJ3fSOwVBCgyOf-5KBcKz1oG7LBaayiV6xPaXNx1K3zBOaXeJCwiQ57H5Bwh4dv1u_K_vRJiX_" />
{{renderer :plantuml_wqrztfdo}}
- ```plantuml
@startuml
' Enumerations
enum FeedbackType {
EXPLICIT
IMPLICIT
}
enum MemoryType {
SHORT_TERM
LONG_TERM
}
enum TelemetryOutput {
LOG
TRACE
BAGGAGE
}
' Core entities
class Agent {
ID: int
name: string
modelCard: string
messageContent: string
hyperparameter: string
dependencies: Agent
}
class SolutionAgent {
ID: int
intentions: string
desires: string
backStory: string
promptType: string
role: string
}
class CollaborationAgent {
ID: int
collaborationPattern: Pattern
}
class SupervisionAgent {
ID: int
}
class ConsensusAgent {
ID: int
}
class Task {
id: int
description: string
input: string
output: string
}
class Tool {
ID: int
name: string
API_key: string
}
class Memory {
ID: int
type: MemoryType
db: string
agent: Agent
}
' Governance and usage
class Provider {
name: string
}
class Usage {
ID: int
name: string
}
class Remote {
ID: int
url: string
provider: Provider
}
class Local {
ID: int
hardwareRequirement: string
}
class A2AProtocol {
ID: int
}
' Evaluation and monitoring
class Benchmark {
ID: int
metadata: string
features: string
}
class Metric {
ID: int
name: string
threshold: double
}
class TelemetryData {
ID: int
tool: TelemetrySource
outputFormat: TelemetryOutput
}
class TelemetrySource {
ID: int
}
class HumanFeedback {
ID: int
userID: int
feedback: FeedbackType
}
' Relationships
Agent <|-- SolutionAgent
Agent <|-- CollaborationAgent
Agent <|-- SupervisionAgent
Agent <|-- ConsensusAgent
Agent --> "1..*" Task : accomplishes
Agent --> "0..*" Tool : exploits
Agent --> "1..*" Memory : has
Agent --> "0..*" Benchmark : evaluated by
Agent --> "1" Provider : provided by
Agent --> "0..*" Usage : uses
Agent --> "0..*" A2AProtocol : complies with
Benchmark --> "1..*" Metric : includes
TelemetryData --> Benchmark : collected on
TelemetryData --> HumanFeedback : stores
HumanFeedback --> Agent : evaluates
Usage <|-- Remote
Usage <|-- Local
@enduml
```
- <img src="https://www.plantuml.com/plantuml/png/jLZDSkCs4hxhAL2QgiourhGbPhmxovItGiaSZJRwAv5EAhce81AIk2O9BW0grhgcAjUSznNoP7cID02I8YdAzcHhv-2HWA-RNpSQtP-8lkK2Cv754UhoB8un2_-3HKWJGn3ixmWpkCW2aWY3FE8uZKYtqtcBRjK_v7e_JXpqZgRI04UNYECDGO8YHcAw9nSvhhCB0u9Y8dOquFeB5uGHAWufuHt-42OfPZX6V8S3-dEORD46HvnKTbBiF-0jSSKX8k3T5pZPHbM07s7EqLC7eG50juncIJ2a4MNeXrqeY5odB21ChmqY07K-L-pf-b_WzNzma511MitVVFpxH_lZeE7WZNFZ_CqPW8jZEeVsmXwC9sFlH_GLMYpdtdmudnGvp0aESOhNOHIAmygj7XV277MFcnQgxNOLip10y133lPzEuLj0kCz2TNImt1sHX30CCVWqyKDEBX7s_Kojv7L1EA8R98Y_Iq8VH_3fKNJ14S_Ib391WWaSIWQdnAK_PtQ9nbvN1fXJNp0gwChJPUNggbAqnmbK0_Ob4uNnQMIX7FVxB_yjeFk-3eEdnBzdaNp8JeYKMzVNUMrUKRQzJgKBVjqetsujqzxI7i_6in5QVB9TfqXnNcIewp4S9h8C5plCILUIB9SaWpoWdAAjWd2pbB1zo248UmiFB2D0jgQDqFWEEDk6rrVV4XmJ6KFXfQjM6OtKAYGYJWLo7bEe5iBqfdvkk2VL0xk6KnJXlpE2KctZuoG80zZXqWh2RX8Ul41uq2HijX4Uj18UIZ9-2rtNXpWGK8FhkmcJWkq9nm59_9tAjcAflaBrFLXewTXtKwTUsEYTWbxK60yCTRvg0V80HoYMP2D9R7S68pY8YI6acQQPvZNtFM4ylmpzgrwJrtUByMf9CoWFIMj1s8Qo62S-WGtWDhyVETqwUk0ilLQmt53fQ1XCi6Z5mpfauT2ji9bgBds5dnB1GXyzoGEwLKoC_YNAab3SSlcOpzqJmyavmybvmpAUcbaPp7d38gwQNHvKRXNppzNmxZdSGtMoEa9Le6hHqZTncILl-iMXYp0cCCNY58xEx9atHk-3qRln-ZshRrgzta-w46GlW-ETokxquRtPKwi-vGA-zwxwvibTYOX7QNGiHRa2GumTv7BEWx09tMxXpZof4nEt_tJdishqqcX9_1Oli0hp03t110bkeM27Zax1MoJzStLLOfYZx80oJW84zY9lGXNt05tAj98za53-5Rax6iii5Jj5fd0cTbCrXsMLsuin-euSz2s0SqjrvvOtH5T_-HZNcv8uFqF5w4cExbltqtpfhJndERtKzhVso9bvrVWdxPQJ-MnKCtG_sKldxX85wzizs55sDoZICGcJ1uv-3iMkdeAo_Hh6FyxFHGkHnvHoq1desF--r48_evvi1OjeA4uylupJ_dHMBGH3fkcYTKjRJSvRLRUQPgtJrog6zuchb-1IpXmxjOgwU1e4lCTH9WVGMTJWUTInsLfm1p3Fs3cKQaelWMG3gc6E_YMaRAOMN38_WbZFOYQd6CL0Gt8o3O1ykjxNFCfjsAyskaOIiUnvwbYgZKY2gaOMjB0eWXl3Mw6rzcF9KHTaldwq4gmitEw4b7KLdweTB9fQGbSn8u6bzWqf8FIj8R8rVOquq8NK4tvrTTKjCE1cB_K-1aNlYmnK8rvp8SLUYNA5zAhkDrB3WwDtQXPTotHUN068G2kKTEiQpd6zPoGSJ8I6WijNAW8khsizOrmQPU8eXihecD5lw26tBk0gI3iF3ZHFNHtPQHeTq1eevBgdHI4jzE4K0hpCc9RVXwOWoScRBv0tc-JDS-ITn_y_zxTmFKi_HJdMPXjwLrG8h4Deu57-q81VZAfC0Ac7uaLLCdAHr-jh1ytd8Yl1Mj8lHewbmbnfUYiIhqaG0ASp8bL6yZgD2iWJYGhb-xn21QC_9L1NtgibAZIaC-XISvuenvNt9xJZyK5VAW8X2oqQ45Qb17IVrO1zq-lVME_Vjsl0ctwleG5x7-ggfoHWdYTWleB0JJk1zr-V4FZhEH5Qb5f3Wm85-TnNQj0obUqQT38VdR4olqovbd9LTzowMXr5b7De2HMnwX5_LootAzKPJKXJfgRPEjA_D5N6obx-QcrNDj0ljT3Fg7ITGepLF9xVxvSgiKn6JIJMtBm8wxzItjMylbhUoS9JWhHuM9jkQu3CPq7LFjKYtAemtJNQbTlAg-coLRlmAb65grFnfMv58yH2UrKwG2E-4tLMyAuuRTTc9q3p1M3j-bOqtFDGyrcvTonETQkgGvaJoGHky0Q-Ltzl8Jd8cY_bYjbqeMLXNHJ-_kjl5Lru2M322TiJ1Iqr0YCRmXJY6uJtD0pK6xuiKlTFYSHM_JUSprndvjwxw2iqcd_lB6VsREY0V02v4ahji17G4_CUTD5yZKeJhb-PmWUIy8mtb9D-1rxkwhQKIwYXr7-5W2eXHoKbtpNcpndHlNeC_4zO8gVhWaBNEbZ8LczN_OFnCMGmw9L_baMwjorKJieCWGRY8LUZ4ab7QCt87bhLD_83Ve3P0sRh0yh7i7hNgIAKDI4fGDtBzwCnXCYFExM2tpAoLJg_bFmdGFCSi5ClBca7qTZg83Xgnewmpw2V0QBqK7d5hAgkO7Pjoh8om6ESOaQA0D5VYjH04X0FjmcEk0AwgdZXnqIIG9go982_gNwgIcwdBANEj_0nYwCEwlm1" />
collapsed:: true
{{renderer :plantuml_ickelqar}}
- ```plantuml
@startuml "summarization-teacher-student-example"
' ====== STYLE (optional, safe to remove) ======
hide methods
hide stereotypes
skinparam shadowing false
skinparam packageStyle rectangle
skinparam class {
BackgroundColor White
BorderColor Black
}
skinparam object {
BackgroundColor White
BorderColor Black
}
skinparam note {
BackgroundColor #F9FAFB
BorderColor #E5E7EB
}
' ====== CAPABILITY & PROTOCOL ======
object Capability_Summarization as "Capability: Summarization" {
id = C-SUMM
description = "Generate concise, accurate summaries of technical text"
supportedLanguages = "EN, IT"
}
object Proto_TeacherStudent as "InteractionProtocol: Teacher–Student v1" {
specUrl = "https://example.org/protos/teacher-student"
}
' ====== TRAINING PHASE ======
package "Training Phase" as Training {
object TeacherA as "SupervisionAgent: Teacher A" {
ID = A-T1
name = "TeacherA"
role = "Prompt Explorer"
objective = "Generate/critique prompt candidates"
}
object TeacherB as "SupervisionAgent: Teacher B" {
ID = A-T2
name = "TeacherB"
role = "Prompt Critic"
objective = "Score and refine prompts"
}
object BenchTrain as "Benchmark: README Summarization (Train)" {
ID = B-TRAIN
datasetRef = "gh-readme-train"
protocolVersion = "1.0"
}
object KPI_Rouge as "PerformanceKPI: ROUGE"
object KPI_BERT as "PerformanceKPI: BERTScore"
object KPI_Lat as "PerformanceKPI: Latency"
object M_Rouge1 as "Metric {name=ROUGE-1, unit=score}"
object M_RougeL as "Metric {name=ROUGE-L, unit=score}"
object M_BERT as "Metric {name=BERTScore, unit=score}"
object M_Lat as "Metric {name=Latency, unit=ms}"
object UsageTrain1 as "AgentUsage: TrainRun#1" {
timestamp = 2025-08-05T10:12:00Z
durationMs = 8420
cost = 0.12
}
object TeleToolTrain as "TelemetryTool: TrainerLogger {format=JSON}"
object TeleRecTrain as "TelemetryRecord {kind=TRACE}"
' Tools and memory used in training
object ToolRetriever as "Tool: DomainRetriever" {
authMethod = "API Key"
scopes = "read"
}
object STMem as "Memory {type=SHORT_TERM, scope=AGENT}"
object LTMem as "Memory {type=LONG_TERM, scope=SHARED, db=vectorDB}"
' Links within training
TeacherA --> Capability_Summarization : exposes
TeacherB --> Capability_Summarization : exposes
TeacherA --> ToolRetriever : exploits
TeacherB --> ToolRetriever : exploits
TeacherA --> STMem : has
TeacherB --> STMem : has
TeacherA --> LTMem : has
TeacherB --> LTMem : has
TeacherA --> Proto_TeacherStudent : supports
TeacherB --> Proto_TeacherStudent : supports
BenchTrain --> TeacherA : evaluates
BenchTrain --> TeacherB : evaluates
BenchTrain --> KPI_Rouge : measures
BenchTrain --> KPI_BERT : measures
BenchTrain --> KPI_Lat : measures
KPI_Rouge --> M_Rouge1 : includes
KPI_Rouge --> M_RougeL : includes
KPI_BERT --> M_BERT : includes
KPI_Lat --> M_Lat : includes
UsageTrain1 --> TeacherA : agent
TeleToolTrain --> UsageTrain1 : collects
TeleToolTrain --> TeleRecTrain : produces
note right of UsageTrain1
Prompt candidates explored:
- "Summarize in 3 sentences..."
- "Provide a factual abstract..."
Stored with scores (ROUGE/BERT).
end note
}
' ====== TESTING PHASE ======
package "Testing Phase" as Testing {
object Student1 as "SolutionAgent: Summarizer-1" {
ID = A-S1
name = "Summarizer-Abstractive"
role = "Apply best prompt"
objective = "Produce concise factual summary"
}
object Student2 as "SolutionAgent: Summarizer-2" {
ID = A-S2
name = "Summarizer-Extractive"
role = "Apply best prompt"
objective = "Produce concise factual summary"
}
' Best prompt produced in training (abstracted as context stored in memory)
object BestPrompt as "Memory {type=LONG_TERM, scope=SHARED}" {
db = "vectorDB: best_prompt_embeddings"
}
object BenchTest as "Benchmark: README Summarization (Test)" {
ID = B-TEST
datasetRef = "gh-readme-test"
protocolVersion = "1.0"
}
object KPI_Rouge_T as "PerformanceKPI: ROUGE"
object KPI_Lat_T as "PerformanceKPI: Latency"
object M_RougeL_T as "Metric {name=ROUGE-L, unit=score}"
object M_Lat_T as "Metric {name=Latency, unit=ms}"
object UsageTest1 as "AgentUsage: TestRun#S1" {
timestamp = 2025-08-12T15:44:00Z
durationMs = 5100
cost = 0.08
}
object UsageTest2 as "AgentUsage: TestRun#S2" {
timestamp = 2025-08-12T15:45:00Z
durationMs = 4300
cost = 0.06
}
object TeleToolTest as "TelemetryTool: RuntimeLogger {format=JSON}"
object TeleRecTest1 as "TelemetryRecord {kind=LOG}"
object TeleRecTest2 as "TelemetryRecord {kind=TRACE}"
' Tools used in testing
object ToolGlossary as "Tool: TechGlossary" {
authMethod = "None"
scopes = "public"
}
Student1 --> Capability_Summarization : exposes
Student2 --> Capability_Summarization : exposes
Student1 --> BestPrompt : has
Student2 --> BestPrompt : has
Student1 --> ToolGlossary : exploits
Student2 --> ToolGlossary : exploits
Student1 --> Proto_TeacherStudent : supports
Student2 --> Proto_TeacherStudent : supports
BenchTest --> Student1 : evaluates
BenchTest --> Student2 : evaluates
BenchTest --> KPI_Rouge_T : measures
BenchTest --> KPI_Lat_T : measures
KPI_Rouge_T --> M_RougeL_T : includes
KPI_Lat_T --> M_Lat_T : includes
UsageTest1 --> Student1 : agent
UsageTest2 --> Student2 : agent
TeleToolTest --> UsageTest1 : collects
TeleToolTest --> UsageTest2 : collects
TeleToolTest --> TeleRecTest1 : produces
TeleToolTest --> TeleRecTest2 : produces
note right of BestPrompt
Best prompt selected from training
(Teacher–Student protocol):
"Summarize in ≤3 sentences, preserve
factual references; avoid speculation."
end note
}
' ====== CONSENSUS & GOVERNANCE (applied after testing) ======
object Cons as "ConsensusAgent: Summarization-Consensus" {
ID = A-C1
name = "ConsensusSummarizer"
}
object Gov as "GovernancePolicy: Accuracy-First" {
rules = "Prefer factual consistency over brevity; break ties by ROUGE-L"
}
Cons --> Gov : implements
Cons --> Student1 : aggregates candidate
Cons --> Student2 : aggregates candidate
note right of Cons
Applies GovernancePolicy across
candidate summaries from Student1/2:
- Compare ROUGE-L + factuality signals
- Select winner under policy rules
end note
@enduml
```
pages/Deliverable D3.1.md
+8
View File
@@ -0,0 +1,8 @@
tags:: #todoist-task, [[PROJECTS/MOSAICO]]
date:: [[25-09-2025]] - 11:17
progress:: {{renderer :todomaster}}
- ### Tasks
-
- ### Notes
-
pages/EditoringChairing___IEEE_Software_SW-2025-10-0161.md
+66
View File
@@ -0,0 +1,66 @@
type:: [[REVIEWS]]
tags:: [[EditoringChairing]]
year:: 2026
venue:: [[IEEE SOFTWARE]]
full-title::
date-start:: [[23-12-2025]] - 16:08
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: ![SW-2025-10-0161_Proof_hi.pdf](../assets/SW-2025-10-0161_Proof_hi_1766502869265_0.pdf)
parent::
todoist:: https://app.todoist.com/app/task/editor-assignment-ieee-software-sw-2025-10-0161-6f5jF5CVMvpVQ49g
- ### [[Comments]]
- FINAL DECISION (MAJOR)
- While all three reviewers recommend a minor revision, my assessment is more critical. In my view, the issues raised, particularly those highlighted in my comments, are substantive and require significant changes to the manuscript. Addressing them goes beyond polishing or clarification and calls for a more thorough revision of the paper. For this reason, I recommend a major revision.
-
- Reviewers find the paper well written and suitable for IEEE Software. However, several issues have been identified that can be summarized as follows:
- The user study is small and should be framed as a proof of concept rather than making strong assumptions about reducing development time or cognitive load.
- Early in the paper, the authors motivate the work by referring to the need for explainability, especially in the context of AI systems. Unfortunately, the paper lacks a specific, practical AI-based application, weakening its novelty and relevance. It is necessary to delineate the coverage of the pattern by improving the evaluation scenarios.
- A clear justification for the use of AOP is also needed. It is necessary to demonstrate how the pattern can be generalized beyond AOP-centric environments and languages.
- To summarize, a serious and major revision is needed to make the paper convincing beyond the application of the proposed idea to toy examples that are not representative of complex systems, as claimed at the beginning of the paper.
-
- Preliminary comment
- The three reviewers are largely aligned in judging the paper as **sound, well written, and suitable for IEEE Software**, but they consistently identify a set of **minor yet substantive weaknesses** that need addressing. The main criticality concerns the **evaluation and claims**: the user study is small, affected by ordering bias, and should be framed strictly as a *proof of concept*, avoiding strong claims about development-time reduction or cognitive load. A second recurring issue is **scope and positioning**: although the motivation targets AI-based systems and explainability, the paper lacks a **concrete, realistic AI-based application**, relying instead on generic or dummy scenarios, which weakens both novelty and relevance. Reviewers also ask for a **clearer justification of Aspect-Oriented Programming**, including why it was chosen and how the pattern could generalize beyond AOP-centric environments and languages. Finally, some **clarifications and minor fixes** are needed: better delineation of what the pattern does and does not cover (e.g., where explanations should be placed and based on which criteria), improved description of evaluation scenarios, and small presentation and reproducibility improvements (e.g., archiving supplementary material in a long-term repository). Overall, the issues are coherent, bounded, and addressable with a focused minor revision.
- > [[gpt3]]
The reviewers find the paper suitable for IEEE Software but point out some minor yet important weaknesses. They highlight concerns about the evaluation and claims made in the paper, suggesting that the user study should be considered a proof of concept rather than making strong assertions about reducing development time or cognitive load. Additionally, they note that the paper lacks a specific, practical AI-based application, weakening its novelty and relevance. Reviewers also seek a clearer justification for the use of Aspect-Oriented Programming and suggest improvements in delineating the pattern's coverage and enhancing evaluation scenarios. Overall, the issues raised are specific and can be addressed through a focused minor revision.
-
- **R1** / Minor
- Paper Summary:
This paper presents a design pattern for the integration of explanations using aspect-oriented programming (AOP) with the goal of standardizing and facilitating the development process of explanations, similar to what has been previously done for logging.
The authors implement a plugin for Visual Studio Code that supports the implementation of the pattern and preliminarily evaluate it by conducting an experiment involving seven participants. Results of the evaluation reveal benefits in terms of both development time and cognitive load.
- Strengths:
- The authors investigate a relevant and timely topic, i.e., providing a structural solution to manage explanations.
- The paper is very well-written, and it is also very easy to follow and understand.
- To present the pattern, the authors rely on the standard design pattern template.
- The manuscript comes with a link to a GitLab repo providing a sample implementation of the Explainer design pattern.
- I appreciate the presence of the threats to the validity section, where the authors admit as threats both the limited sample size and the ordering bias affecting the evaluation results.
- Points to Address:
- Due to the admitted threat of ordering bias, I would suggest stressing less the improvement in terms of development time and cognitive load. The evaluation should be viewed primarily as a proof of concept, without making any strong claims about the practical impact of adopting the pattern in real development scenarios.
- Since the Aspect-Oriented Programming is not standard in all modern development environments or languages, it would be good to motivate the reason why the authors focused on this paradigm, and the authors must discuss more the feasibility of extending this pattern to be used in different environments/languages.
- Overall Summary: This manuscript presents a novel solution to the integration of the explanations issue within complex software systems. While the evaluation is preliminary, the design is sound, and the accompanying tooling makes it a practical contribution for the IEEE Software audience. However, there is a need to work a little bit more on the writing by smoothing the results of the evaluation and by justifying the use of AOP more effectively, as well as explaining how it can be adapted to different environments and languages.
- **R2** / Minor
- Overall merit
- The proposed pattern is well-described and implemented in a Visual Studio Code plugin. However, the presented scenarios are somehow disconnected compared to the original motivation of the paper, i.e., assisting developers for AI-based systems. In this respect, the paper misses a concrete example of an AI-based application and how the proposed design pattern can concretely help developers. In addition, the pilot applications used in the user study are vaguely described. While the proof-of-concept is suitable to showcase a generic usage of the pattern, I strongly recommend authors to present a concrete AI-based application in which the Explainer Pattern can be used.
- Novelty
- While the proposed pattern can be helpful in practice, the paper does not present a concrete example applied to an actual AI-based project. In addition, existing challenges are not mentioned, and the authors should discuss which benefits the AOP pattern can bring to developers.
- Soundness
- Although the user study is small, it is adequate as a proof-of-concept. However, the scenario application is not reported, and, by looking in the provided repo, it seems limited to dummy projects. As mentioned, the authors should present a concrete example in an AI-based project, as it is the target domain of the approach. Concerning the evaluation metrics, only the required time is reported, although it might be useful to report how practitioners perceive the usefulness of the generated explanations.
- Relevance
- This paper proposes a novel design pattern with a minimal tool-based implementation. Therefore, it is relevant to the journal’s aims and scope.
- Verifiability
- The replication package is available on the GitLab repository, thus fostering the reusage of the tool.
- Presentation
- The paper is overall well-written and easy to follow.
- **R3** / Minor
- The paper addresses the scattered nature of code explanations and the need for a unifying structure, a relevant problem. The proposed design pattern is well motivated, follows established pattern description guidelines, and is likely to be actionable for practitioners. The evaluation reports promising initial results.
- The evaluation, however, is limited in scope. It considers only the integration of explanations using the pattern, and does not address the retrieval or use of these explanations. In addition, the study is small-scale (7 participants), with most participants being students or trainees, which restricts the extent to which conclusions can be generalized. This is discussed as part of the threats to validity.
- While generally clear, some aspects of the pattern description would benefit from further clarification. The pattern description states that explanations are stored "at all points that could be unclear (e.g., when executing a complicated method)", but it remains unclear how complexity is defined or measured. Moreover, since the motivation emphasizes the end-user, it is not obvious whether method complexity is the appropriate criterion for deciding where explanations are needed. If this is intentionally out of scope for the pattern, I would suggest to explicitly state this earlier in the paper to better delineate its scope.
- Minor comments:
- The supplementary material should be archived in a long-term repository such as Zenodo rather than GitLab
- For the feasibility evaluation, either cite the bachelor's thesis explicitly or consider omitting mentioning it
-
-
-
pages/EditoringChairing___IEEE_Software_SW-2025-10-0163.md
+124
View File
@@ -0,0 +1,124 @@
type:: [[REVIEWS]]
tags:: [[💺EditoringChairing]]
year:: 2025
venue:: [[IEEE SOFTWARE]]
full-title::
date-start:: [[23-12-2025]] - 15:34
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: ![SW-2025-10-0163_Proof_hi.pdf](../assets/SW-2025-10-0163_Proof_hi_1766500604129_0.pdf)
parent::
todoist:: https://app.todoist.com/app/task/editor-assignment-ieee-software-sw-2025-10-0163-6f5jF5HM5hW6cPF8
- ### [[Comments]]
- **Final decision**
- Reject
- Reviewers agree that the paper is about a relevant and interesting problem. However, the paper cannot be accepted because of several issues that can be summarized as follows:
- The main message of the paper is not effective because it fails to connect with the existing work on model and DSL evolution, and relies heavily on a specific DSL family. It is unclear whether the specificities of the considered languages can be a source of bias or affect the generalizability of the discussion.
- Following the previous point, the lack of novelty makes it challenging to understand the general and broader implications beyond the specific case discussed. The lessons learned section tries to generalize the findings, but it is not convincing.
- The evaluation is informal and lacks details. I understand the page constraint plays a role here; however, reviewers identified overstatements without sufficient evidence.
- Technical and conceptual issues are identified, including inaccuracies in the MDE tool discussion and insufficient justification for using LLMs over traditional methods in specific tasks.
-
- **Preliminary comments from those of the reviewers**
- Across the three reviews, several converging criticalities emerge. First, the paper’s **positioning and core message are unclear and potentially misleading**: the link to *DSL evolution* is weak, the contribution is tightly bound to a single DSL family (USchema/Athena–Orion), and the paper risks suggesting that probabilistic LLMs can replace well-established, deterministic DSL tooling without adequately discussing limitations, risks, or boundaries. Second, the **novelty and contextualization are insufficient**, with limited engagement with the substantial literature on DSL/model co-evolution and related MDE approaches, making it hard to assess what generalizes beyond this specific experience. Third, the **evaluation is informal and under-specified**: claims are often too strong given the lack of methodological detail, limited scale, absence of analysis of non-determinism, and no clear quantification of effort reduction. Finally, there are **technical and conceptual issues**, including inaccuracies in the discussion of MDE tooling, unclear justification for using LLMs over traditional approaches in some tasks, and missing discussion of key aspects such as data migration, reliability, and broader societal or ecological implications.
- > [[gpt3]]
The text highlights several key criticisms from three reviews. Firstly, the paper's main message is unclear and may be misleading, as it fails to effectively connect to DSL evolution and relies heavily on a specific DSL family. Secondly, the lack of novelty and context in the paper makes it challenging to understand its broader implications beyond the specific case discussed. Thirdly, the evaluation is deemed informal and lacks specific details, leading to overstatements without sufficient evidence. Lastly, technical and conceptual issues are identified, such as inaccuracies in MDE tool discussion and insufficient justification for using LLMs over traditional methods in certain tasks.
- **REVIEWER 1** / REJECT
- The paper is generally well-written and sound, and it addresses an interesting and timely topic.
It has however a few important problems that hamper my acceptance.
- The paper claims to evaluates GPT-4o in DSL evolution (in the title and throughout the paper). I had some difficulties understanding that it actually addresses two (very different) classes of tasks: tasks for DSL users (mainly script generation) and DSL developers (mainly script transformation). The link with DSL evolution is not clear, and feels forced.
- While the paper is quite convincing on the tasks for DSL users, I think it is deeply misleading on the tasks for DSL developers. It seems to promote the idea that LLMs should be used to replace traditional DSL tooling like compilers or translators. It completely omits discussing all the drawbacks of such idea. Replacing deterministic translators with probabilistic tools like LLMs would require a much more extensive experimentation. Ecological and societal issues are never mentioned.
- As a less critical issue, the paper should better highlight the peculiarities of the two considered DSLs. While on the surface these DSLs seem very similar to other languages (that the LLM "understands" out-of-the-box) I suppose that they have some specific features that need to be taught the LLM. They should be detailed.
- Finally, reference [1], that contributes to motivating the paper, is just a very short blog post, and does not contain much evidence of the claim.
- In summary, while the topic is interesting, the paper's core message may be misleading to practitioners, and this hampers in my opinion the paper's publication.
- **REVIEWER 2** / MAJOR
- ----------------------------------------
Summary of the submission.
----------------------------------------
The paper presents an experience report on using GPT-4o to support the evolution and use of two domain-specific languages from the USchema family: Athena (for database schema specification) and Orion (for schema evolution). The article proposes a four-step prompting strategy to teach the LLM how to generate DSL scripts and translate them to and from various database technologies. Through two validation experiments, the paper reports that GPT-4o produced syntactically correct and semantically valid outputs in nearly all cases, with only minor issues. As such, the paper argues that this approach can reduce the manual effort traditionally required to implement and maintain complex model-to-text transformations. The paper concludes with lessons learned about the strengths and limitations of combining LLMs with DSL engineering.
----------------------------------------
Detailed comments
----------------------------------------
The paper describes an experience report on the use of large language models to support the evolution of domain-specific languages, focusing on two DSLs within the USchema family. Overall, I found the article quite interesting and divulgative enough to justify a submission to IEEE Software. I appreciated the idea of reporting an experience-driven study to discuss the broader theme of how LLMs can be integrated into DSL engineering workflows. The lessons learned are significant for the community and, more generally, the paper presents insights that are timely and relevant for researchers and practitioners exploring hybrid AI-assisted software development processes. The article effectively reports on the opportunities and challenges of applying LLMs to non-trivial engineering tasks; its form is clear and accessible to a broad audience. So, in this sense, I believe the article is aligned with the objectives of the journal and has the potential to represent a valuable contribution.
At the same time, some aspects should be made more explicit or clarified. More specifically, let me report my major concerns in the following - please note that these issues are listed in no particular order of severity.
- (1) In the 'Evaluation and Results' section, the article describes the main findings coming from the two validation experiments discussed. While reading this section, I found the claims to be a bit too bold with respect to what is actually reported. In particular, the paper frequently uses expressions such as "complete correctness in all schema transformations" or "full correctness" across multiple target languages. However, the section does not provide enough methodological detail to support such strong claims.
- For instance, the paper does not specify (1) how correctness was operationalized (e.g., syntactic vs. semantic correctness criteria, classification of errors, acceptance thresholds); (2) how many test cases were used per transformation direction, nor whether these cases cover the full combinatorial variability of the DSL features; (3) how independence between training examples and evaluation cases was ensured, since few-shot examples may inadvertently encode the exact mapping rules being tested.
- I fully understand that these details may have been omitted because of the strict page limitation constraints imposed by the journal. Nonetheless, I would still suggest to briefly summarize the evaluation procedures to better contextualize the reported results. To save some space, the article may consider combining the last two sections (Lessons Learned and Conclusion) together.
- (2) As far as I can tell, the DSLs evaluated (Athena and Orion) belong to the same USchema family, which may make generalization easier than for unrelated DSLs. This is basically due to the very nature of the experience, which targets cases addressed in previous research. Yet, a more cautious formulation of the claims would make the contribution stronger. In this sense, I would just ask to more explicitly acknowledge that the experience is limited to cases belonging to the same USchema family and that, for this reason, the considerations reported may not fully generalize to other DSLs.
- (3) I appreciated that, in Figure 2, the article reports the prompting and validation strategy. However, some aspects of the prompt strategy are not explicitly discussed. In particular, the article does not address the key concern of LLM non-determinism and how this affects the reliability of the proposed workflow: LLMs can produce different outputs across runs even when using the same prompt, depending on temperature, sampling strategy, and internal stochasticity. As such, the paper should clearly (and briefly) discuss (1) whether the experiments have been conducted in a controlled environment (e.g., by ixing temperature, top-p, or other decoding parameters); (2) whether the reported successful transformations reflect single-run outputs or consistent results across multiple executions; (3) how often incorrect or inconsistent outputs occurred during experimentation, and whether prompt refinements were needed to stabilize behavior. I honestly believe that these details would be essential to assess the overall soundness of the conclusions drawn in the experience report.
- (4) Similar considerations may be reported when considering the effort reduction discussion. While the paper convincingly argues that the LLM-based workflow avoids the need to manually implement and maintain M2T transformations, the evidence provided is largely qualitative and does not fully report the magnitude of effort saved. For example, the article reports the lines of code of traditional transformations and the complexity of certain SCO mappings, but it does not quantify the actual prompting effort, the number of iterations required to achieve stable outputs, or the time spent in validation and correction. These aspects should be somehow accounted in the effort analysis, as they are preliminary activities to reach a level where the LLM may actually be exploited.
- So, in conclusion, I think the paper represents a nice contribution with effective and timely insights for the research community. The points above are relatively minor, assuming they simply reflect clarifications that were not included in the original manuscript due to space limitations. My recommendation is that the paper undergoes a revision to incorporate these clarifications.
- **REVIEWER 3** / Reject
- This article reports on an experience using large language models (LLMs) to support the evolution of two domain-specific languages (DSLs), Athena and Orion, by means of a structured prompting strategy. The paper argues that LLMs and DSLs are complementary: LLMs reduce engineering effort, while DSLs provide the formal backbone needed to ensure correctness and maintainability. The topic is timely and relevant for the IEEE Software readership, and the paper is generally well written and easy to follow.
However, while the paper presents an interesting experience report, several conceptual, methodological, and positioning issues significantly limit the clarity and strength of its contribution. In its current form, the paper lacks adequate contextualization within the literature on model and DSL co-evolution, provides an unclear justification for the use of LLMs over traditional MDE techniques, and presents an evaluation that is informal and insufficiently grounded.
Strengths
The paper addresses a timely topic at the intersection of DSL engineering and LLM-based automation.
The experience-based nature of the article aligns well with the IEEE Software audience.
The paper is generally readable and written in an accessible style.
Major Concerns
A major limitation of the paper is the lack of contextualization with respect to the extensive body of work on model and DSL co-evolution. The paper frames the contribution mainly as an application of LLMs to DSL evolution. However, it does not sufficiently relate this to existing research on co-evolution between models, metamodels, transformations, and instances.
Several recent and closely related works are not discussed, including:
Kebaili et al. (2024) [1], which empirically studies the use of LLMs for metamodel and code co-evolution.
Zhang et al. (2025) [2], which explicitly investigates LLM support for co-evolution between DSL definitions and instances.
Moreover a recent sutdy [3] investigated the usage of LLMs in various MDE tasks.
Without positioning the proposed approach with respect to this literature, it remains unclear what is novel beyond applying LLMs to a specific DSL family.
The paper's contribution is difficult to assess. The study is tightly coupled to a specific DSL family (Athena/Orion) and a specific data modeling context, yet the paper does not clearly articulate:
which insights generalize beyond this particular notation,
which lessons are specific to the USchema-based DSLs,
and how the approach compares to existing DSLs and modeling languages that already support schema evolution and persistence-layer abstractions.
There is a substantial body of work on modeling languages and frameworks for persistence, schema evolution, and query adaptation (e.g., Fink et al., 2020) [4] that is not discussed, nor are the differences between those approaches and Athena/Orion clarified.
The sidebar explaining how DSL generators are built in MDE contains several technical inaccuracies and inconsistencies:
Acceleo is presented as an example of a model-to-model (M2M) transformation language, whereas it is primarily a model-to-text (M2T) template-based language.
The statement that generators “often consist solely of an M2T transformation when the mapping is not complicated” is misleading; M2T transformations can be highly complex and involve sophisticated mappings.
The overall explanation risks confusing non-expert readers and oversimplifying well-known MDE practices.
I recommend either revising this sidebar substantially for technical accuracy or removing it altogether.
Box 1 lists several automated tasks (e.g., generating SQL, CQL, or MongoDB schemas from Athena scripts) that correspond to classic M2T transformations. It is not clearly justified why LLMs are preferable to established template-based approaches in these cases. As presented, the use of LLMs sometimes feels like “using a sledgehammer to crack a nut.”
The paper would benefit from a clearer discussion of:
which tasks genuinely benefit from LLM-based automation,
which tasks are already well supported by traditional MDE techniques,
and where the boundary lies between the two.
While the paper introduces a four-step prompting strategy, it does not explain how these steps were identified, nor how each step contributes to the final outcome. The strategy is presented as a design choice rather than as the result of a systematic process.
In particular:
- There is no analysis of alternative prompting strategies (e.g., few-shot vs. grammar-only, with or without documentation).
- The impact of each step on correctness or coverage is not evaluated.
- An ablation study would be highly beneficial to understand which components of the strategy are essential.
Moreover, it is unclear why the authors used ChatGPT instead of other LLMs (even freely available). This selection should be discussed throughout the paper.
Without this, the prompting strategy remains anecdotal rather than principled.
Although a rigorous evaluation is not mandatory for an IEEE Software article, the evaluation section, as presented, is informal and difficult to interpret:
The goals of the two experiments are not clearly defined.
The contribution of each experiment to validating the approach is unclear.
The reported examples are relatively simple (often fewer than ten entities), making it hard to assess how the approach scales to realistic evolution scenarios.
As a result, the evaluation does not convincingly demonstrate the challenges of real-world model and DSL evolution, nor the advantages of the proposed approach in such settings.
It is unclear whether the approach supports data migration in addition to schema evolution. While Orion generates DDL and DML commands, the paper does not explicitly discuss:
whether data consistency is preserved,
how data migration is validated,
or what guarantees are provided in practice.
Given that data migration is a central concern in schema evolution, this omission is significant.
Minor Comments:
The GitHub repository is referenced late in the paper and should be introduced earlier.
The repository contents mix English and Spanish examples, which reduces the performance of the training part.
Some claims in the text (e.g., the number of entities in examples) appear inconsistent with the repository.
Minor editorial issues (dates, phrasing, and references) should be addressed.
Overall Recommendation:
The paper addresses a relevant topic and reports an interesting practical experience. However, the lack of proper contextualization, unclear contribution, technical inaccuracies, and weak evaluation substantially limit its current impact.
[1] Z. K. Kebaili, D. E. Khelladi, M. Acher, and O. Barais, “An empirical study on leveraging LLMs for metamodels and code co-evolution,” Journal of Object Technology, vol. 23, no. 3, pp. 1–14, 2024.
[2] W. Zhang, R. Hebig, and D. Strüber, “Leveraging LLMs to support co-evolution between definitions and instances of textual DSLs,” 2025.
[3] Di Rocco, J., Di Ruscio, D., Di Sipio, C. et al. On the use of large language models in model-driven engineering. Softw Syst Model 24, 923–948 (2025). https://doi-org.univaq.idm.oclc.org/10.1007/s10270-025-01263-8
[4] J. Fink, M. Gobert, and A. Cleve, “Adapting Queries to Database Schema Changes in Hybrid Polystores,” in Proc. IEEE 20th Int. Working Conf. on Source Code Analysis and Manipulation (SCAM), 2020, pp. 127–131.
-
- ![SW-2025-10-0163_Proof_hi.pdf](../assets/SW-2025-10-0163_Proof_hi_1766500599608_0.pdf)
pages/GOALS-TODOIST.md
+11 -10
View File
@@ -26,7 +26,7 @@ progress:: {{renderer :todomaster}}
todoist-desc:: ✉: http://s.diruscio.org/u9fPP
todoist-id:: [7602643924](https://app.todoist.com/app/task/7602643924)
- TODO [[PAPERS/2024-ONTOLOGY-AI]]
todoist-id:: [7658261760](https://todoist.com/app/task/7658261760)
todoist-id:: [7658261760](https://app.todoist.com/app/task/7658261760)
- TODO NIER paper on how our two-level agent architecture
- TODO [#C] [[PAPERS/2024-BiasInRSSEwithLLM]]
todoist-id:: [7688827022](https://todoist.com/app/task/7688827022)
@@ -95,10 +95,10 @@ progress:: {{renderer :todomaster}}
CLOCK: [2025-05-25 Sun 19:29:04]--[2025-05-25 Sun 19:29:05] => 00:00:01
:END:
- TODO Nuova edizione del PinKamp
todoist-id:: [8644892780](https://app.todoist.com/app/task/8644892780)
todoist-desc:: From: giuseppe.dellapenna@univaq.it
todoist-id:: [8644892780](https://app.todoist.com/app/task/8644892780)
- TODO ICSE 2026 Program Committee
- TODO [[PAPERS/Experience-Report-to-EMSE]]
-
- DONE [[PAPERS/FSE2025-NIER]]
id:: 68362092-aafa-44b6-83b2-8f4a163dd2a0
- TODO [#C] Dottorato industriale riservato a dipendenti
@@ -107,13 +107,14 @@ progress:: {{renderer :todomaster}}
- TODO Richiesta afferenza al Collegio di Mauro Cappelli, ricercatore all’Enea
- TODO [#C] Vedere per compenso per la De Masi
- TODO [#B] [[PAPERS/Journal-Green-Paper]]
- TODO [#A] Rivedere Composizione Collegio
- TODO [#C] Rivedere Composizione Collegio
todoist-id:: [8750396305](https://app.todoist.com/app/task/8750396305)
SCHEDULED: <2026-01-12 Mon>
:LOGBOOK:
CLOCK: [2025-06-04 Wed 21:44:39]--[2025-06-04 Wed 23:46:56] => 02:02:17
:END:
- TODO [#C] [[PAPERS/ABSTRACT-ENGINEERING]]
- TODO [#C] [[PAPERS/TOSEM2025-TESORO]]
-
- TODO [#B] [R: Scheda XLI ciclo e richieste di afferenza al Collegio](https://outlook.office365.com/owa/?ItemID=AAkALgAAAAAAHYQDEapmEc2byACqAC%2FEWg0AjoVpQvBez0Ss5ZY2WGWEJgAHueDXAQAA&exvsurl=1&viewmodel=ReadMessageItem)
- DONE [#B] Informiamo che entro e non oltre il ciascun Coordinatore dovrà caricare sulla piattaforma telematica dedicata: - il verbale del collegio dei docenti con esplicita ammissione all’esame finale; - la copia della tesi finale del dottorando; - il verbale della commissione dell’esame finale.
id:: 68584e9f-280a-4a6a-afab-e3a5172e1586
@@ -128,9 +129,9 @@ progress:: {{renderer :todomaster}}
todoist-desc:: From: noreply-icse2026@hotcrp.com
todoist-id:: [9001461730](https://app.todoist.com/app/task/9001461730)
- TODO Dottorato industriale
todoist-id:: [9006116046](https://app.todoist.com/app/task/9006116046)
id:: 6823acce-6cc8-4da4-9a2c-5ffacf92e168
SCHEDULED: <2025-05-22 Thu>
todoist-id:: [9006116046](https://app.todoist.com/app/task/9006116046)
SCHEDULED: <2025-05-24 Sat>
- DONE [#B] Models Conference 2025
id:: 682ecc99-b356-4086-9ff8-4e4736018009
SCHEDULED✔️ <2025-05-26 Mon>
@@ -151,13 +152,13 @@ progress:: {{renderer :todomaster}}
- DONE [[PAPERS/2025-Survey-MOSAICO]]
id:: 6832257a-63a4-4c89-8353-25f0e94caa51
- TODO [#B] Sinergia con GSSI
- TODO [#B] SLIDES DI PRESENTAZIONE
- DONE [#B] SLIDES DI PRESENTAZIONE
todoist-desc:: Con HOWTO etc.
todoist-id:: [9193848277](https://app.todoist.com/app/task/9193848277)
- TODO [#A] [[MODELS Journal-First-track + 1 more]]
- DONE [[MODELS Journal-First-track + 1 more]]
todoist-desc:: From: noreply@researchr.org
todoist-id:: [8933176944](https://app.todoist.com/app/task/8933176944)
SCHEDULED: <2025-07-15 Tue>
SCHEDULED: <2025-09-19 Fri>
:LOGBOOK:
CLOCK: [2025-06-04 Wed 21:44:10]--[2025-06-04 Wed 23:46:56] => 02:02:46
:END:
pages/Giornata di presentazione del dottorato.md
+51
View File
@@ -0,0 +1,51 @@
tags:: #todoist-task, [[SERVICES/PHDICT]]
page-type:: [[SERVICES/PHDICT]]
date:: [[26-09-2025]] - 11:14
progress:: {{renderer :todomaster}}
- ### Tasks
- DONE Preparare slides di presentazione da mostrare ad un evento per tutti gli studenti che andremo ad organizzare per metà Novembre (online?)
id:: 68df8e5d-fbdf-4070-ba1e-3a748f11766a
- Mail suggerimento VITTORIO
- Slides di presentazione del corso con un po' di numeri / analisi
- Spiegare funzionamento selezione corsi su esse3
- Sezione seminari del sito
- Questione preghiera e docoro
- Richiesta di missione / disponibilità economica
- Gli studenti dovranno caricare il proprio piano entro il 31/01/2025
- quelli del primo anno potranno rivedere il piano del secondo e terzo anno e potranno aggiungere anche l'offerta nuova
- DONE Trovare location
id:: 68df8e5d-3e7c-4377-8a9c-151d1a6f97ae
- Aula Seminari Blocco Zero
- DONE Individuare una data
id:: 68df8e5d-e7d8-4964-9f1a-765fdd2a28e3
- DONE Pensare a connessioni da remoto per studenti che ancora non hanno il visto
id:: 68df8e5d-3f53-4e39-bb5c-c0dbe9368211
:LOGBOOK:
CLOCK: [2025-11-30 Sun 20:50:47]--[2025-11-30 Sun 20:50:48] => 00:00:01
:END:
- DONE Fare una locandina?
- ### Notes
- Direi un paio di ore con i seguenti interventi
- Direttore del Dipartimento / Rettore ???
- Coordinatore
- Durata del dottorato
- Report annuali, cosa e' richiesto
- Missioni
- Missioni lunghe (maggiorazione del 50%)
- Qualche numero anche presi dall'ultimo rapporto
- Responsabili del Reference Group
- Direi che ogni reference group faccia una sorta di overview dei risultati / ricerche?
- Collaborazioni?
- Qualche nostro studente
- Primo/Secondo anno, Post-doc
- Programma di massima:
- Inizio ore 10:30
- Direttore 5min
- Coordinatore / Vice 20min
- Responsabili reference groups 20min
- Studenti 5min
- Q/A 10min
- Fine ore 11:30
- Collegio 11:30 -> 13:00
- Light lunch ore 13:00
pages/Grafana-handOn.md
+12
View File
@@ -0,0 +1,12 @@
tags:: [[TEACHING/SE4IOT]]
date:: [[12-12-2025]]
- Start Grafana
- Create a new datasource selecting InfluxDb (Flux)
- Create a new dashboard and play with the query from InfluxDB
- Show the details of the Forerst Fire Detection
- To see the variables, follow the Settings link
- ![image.png](../assets/image_1765472158589_0.png)
- Add a new variable and see what happens
- Discuss the definition of the forest and area varliables
- ![image.png](../assets/image_1765472378222_0.png)
pages/ICSE2026-paper1356.md
+35
View File
@@ -0,0 +1,35 @@
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 class’s 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, it’s 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?
pages/ICSE2026-paper1656.md
+81
View File
@@ -0,0 +1,81 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: Multi-Agent LLM Collaboration for Enhancing Unit Test Generation Using Repository-Aware Knowledge Graphs
date-start:: [[09-09-2025]] - 15:31
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Multi-Agent LLM Collaboration for Enhancing Unit Test Generation Using Repository-Aware Knowledge Graphs]]
parent::
todoist:: https://app.todoist.com/app/task/1656-multi-agent-llm-collaboration-for-enhancing-unit-test-generation-using-repo-6cVHmvX8F6V23H48
- ### [[Highlights]]
- ### [[Comments]]
- #.tabular
- ### Paper summary
- The paper presents TestAgent, a multi-agent system (MAS) based on LLMs for the automated unit test generation. The proposed MAS consists of three agents (requirement planner, test generator, reviewer) that collaborate while relying on external tool APIs for executing generated tests, and a knowledge graph that includes fine-grained dependencies of the repository storing the code of the method under analysis. The authors have performed experiments on Java and Python projects, showing that TestAgent outperforms existing approaches under different dimensions.
- ### Strengths
- + Interesting and effective use of a multi-agent system for a critical software engineering task
- + Rich experiments including an ablation study showing the contribution of each agent to the unit test generation process
- + Extensive comparison with existing approaches
- ### Weaknesses
- - Some claims are overstated, especially concerning outperforming all baselines across all metrics (e.g., EvoSuite outperforms TestAgent on some dimensions).
- - The multi-agent collaboration protocol is not specified. How agents interact, share state, and resolve conflicts is not well articulated.
- - Several terminologies (e.g., “practicality”, “adaptive states”, “real-world industrial projects”) are ambiguous and need better definition
- - The mutation process is unclear; more details on fault injection are necessary to validate fairness of the evaluation.
- - The scalability of "node-per-line" approach is not discussed
- ### Detailed comments for authors
- Novelty: The usage of the repository-aware knowledge graph sounds promising, even though it is not clear how agents technical exploit it. Many existing tools can extract AST or dependency graphs out of source code. It is not clear if authors essentially rely on existing graph-construction techniques, or if they had to devise a new one because of some specific requirements that are not elaborated in the text. Nevertheless, the usage of MAS for unit test generation is novel.
- Rigor: The evaluation is extensive, covering multiple metrics and configurations (LLMs, baselines, languages). That said, certain evaluation design choices are unclear:
- How exactly mutation faults are injected? ([p.7, “Mutation score”])
- How were datasets split to mitigate LLM memorization or contamination?
- What constitutes a “real-world industrial project”? ([p.6])
- “Adaptability” in RQ3 is misleading. In particular, RQ3 does not demonstrate adaptability. What is shown is essentially that TestAgent can be executed with different models, but without clarifying what “robustness” (as mentioned in RQ3) actually means in this context. Could you specify the concrete efforts required to integrate new models? For instance, what operations or modifications were needed in the system to make different LLMs work within TestAgent? While Table 5 compares models on the same tasks and metrics, it does not provide insights into the potential challenges, limitations, or architectural adjustments necessary when switching models.
- **Relevance**: The planner–generator–reviewer design, together with tool APIs, is potentially relevant to practitioners. The focus on realistic workflows, integration with external tools, and support for multiple LLMs and languages (Java, Python) enhance applicability.
- Verifiability & transparency: A replication package is cited and online. However, key implementation details are missing in the text:
- What MAS framework is used?
- How are the tools (e.g., check_syntax, calculate_coverage) integrated and invoked autonomously?
- What steps are required to plug a new LLM into the system?
- Presentation: Overall, the paper is well written. However, I have some suggestions for improvement. In particular, the motivation for the graph should appear earlier. Statements like "substantially outperforms” (pag. 7) should be moderated especially when EvoSuite wins in different cases.
- Detailed comments:
- page 1 - "captures fine-grained dependency relations through graph edges": How are these dependencies used in practice? Clarify their concrete usage.
page 2 - "voting-based diagnostic mechanism": Mechanism unclear; how is voting implemented? Among agents or heuristics?
page 3 - "graph serves as … representation": The goal of the graph should be presented earlier.
page 3 - "node corresponds to a line of code": Scalability of this design is questionable.
page 3 - "Extensive Evaluation … industrial scenarios": What qualifies as “industrial” here? Real companies? Internal repositories?
page 4 - "dynamic analysis … adequacy checks…": How do agents access runtime info? Through what interface or protocol?
page 5 - "adaptive states": Adaptive in what sense? Not explained.
page 5 - "assesses whether current context is sufficient…": Define what “sufficient” means and how it is determined.
page 7 - "Mutation score": How is mutation done? What tools or techniques are used? Potential bias?
page 7 - "Readability and Usability … aggregated": How is the aggregation done? What weights? Based on what criteria?
page 7 - "TestAgent using GPT-4o … two alternative LLMs": Clarify whether only RQ3 used alternative LLMs.
page 7 - "substantially outperforms baselines": This should be rephrased. On some metrics, EvoSuite is better.
page 8 - "Model Adaptability": The name of the RQ is misleading. This is model portability. What changes are needed to support a new model?
page 8 - "data leakage risk": Why is this a concern? What kind of leakage?
page 8 - "information is completely unseen": Unverifiable claim unless explicit evidence is given.
page 10 - "Taxonomy of Root Causes and Bug Impacts": Could you reflect on how baselines fare in terms of these root causes?
page 10 - "private industrial dataset (UTXXX)": Need more details about this dataset. Company? Domain? Lines of code?
- Typos / Errors
page 3 - "s[": Missing space and typo.
page 5 - "n T": Should be “n. T.” or reformulated.
page 7 - "Appraoch": Should be “Approach”.
page 7 - "97.46%" in bold: Not necessary, especially when it is not the best result.
page 8 - "↑": Inconsistent with performance drop. Arrows should point down.
- ### Questions
- How exactly is the multi-agent collaboration orchestrated? Is there a predefined protocol (e.g., queue-based, blackboard architecture), and which MAS framework (if any) is used to support the coordination, communication, and tool invocation?
- What is the novelty and added value of the repository-aware knowledge graph? How does it compare to existing code representation structures used in similar works (e.g., code property graphs, AST-based models)? Can you provide a motivating example early in the paper?
- What operations are required to integrate a new LLM model into TestAgent? Does the system abstract away model-specific APIs? What challenges arise when using non-OpenAI models (e.g., context window, latency, inference mode)?
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
collapsed:: true
- {{query (and [[ffd400]] [[ICSE2026-paper1656]] )}}
collapsed:: true
- ### ❓️Questions
- {{query (and [[question]] [[ICSE2026-paper1656]] )[[question]]}}
query-table:: true
query-properties:: [:block]
pages/ICSE2026-paper2683.md
+36
View File
@@ -0,0 +1,36 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems
date-start:: [[18-09-2025]] - 00:31
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@A Multi-Agent Approach for Engineering Digital Twins of Smart Human-Centric Ecosystems]]
parent::
todoist:: https://app.todoist.com/app/task/2683-a-multi-agent-approach-for-engineering-digital-twins-of-smart-human-centric-6cVHmvcJVfJcWwhg
- ### [[Comments]]
- #.tabular
- ### Paper summary
- This paper presents MAD, a Multi-Agent Architectural for Digital Twins of Smart Human-centric Ecosystems (SHEs). The main peculiarity of MAD is that it is a decentralized, agent-based architecture that models both cyber and human entities as agents. The architecture has been implemented to simulate a ride-hailing system in San Francisco, and evaluated on responsiveness, fidelity, adaptability, and robustness.
- ### Strengths
- + The use of Multi-Agent Systems (MAS) to represent both cyber and human entities is interesting
- ### Weaknesses
- - The distinction between the architecture and its implementation is not sufficiently clear throughout the paper
- - It remains ambiguous what generalizable insights are derived from the prototype beyond the specific implementation context (MADSF)
- - The novelty with respect to existing work (e.g., MAPE-K, CPS, autonomous systems) is underdeveloped and not convincingly articulated
- - The evaluation metrics (e.g., responsiveness, fidelity) are applied to the implementation rather than the architecture, making it unclear whether the results validate MAD as a general architectural solution
- ### Detailed comments for authors
- Novelty: The contribution claims to be the first concrete architectural solution where agents form the structural foundation of a DT. However, the connection to prior MAS frameworks, CPS architectural patterns (e.g., MAPE-K), and autonomy paradigms is missing. The paper does not clarify whether the innovation lies in the modeling primitives, in the architectural style, or in the instantiation logic of DT components.
- Rigor: The research questions (RQ1–RQ4) are framed in terms of implementation-level properties (fidelity, adaptability, etc.), but the paper lacks a principled separation between the architectural design and its concrete realization. Moreover, claims about properties such as robustness and adaptability are derived from simulation results, but the limitations of such evaluations in the generalization of architectural properties are not discussed.
- Relevance: The work is highly relevant for domains where decentralized and human-in-the-loop systems interact (e.g., smart cities, urban mobility). However, it is not clear what aspects of the proposed architecture would generalize across different domains or be reusable beyond the specific ride-hailing use case (MADSF).
- Verifiability & transparency: A replication package consisting of source code and data is available (https://anonymous.4open.science/r/sfdigitalmirror/README.md). The given repository gives details on how run the code and obtain the results shown in the paper, under different scenarios.
- Presentation: The paper is generally clear and well-structured. However, there is a frequent confusion of architectural and implementation concerns (e.g., responsiveness of an architecture, which is implementation-specific). The discussion of results does not distinguish between general findings and implementation-specific behaviors. This is the main issue of the paper, which presents an interesting simulation tool, without drawing research insights that go beyond the implementation of the considered scenario.
- QUESTIONS:
- Q1: What are the generalizable architectural principles behind MAD that go beyond the specific implementation (MADSF), and how can they be reused or adapted to other SHE scenarios?
- Q2: How does MAD relate to existing architectural paradigms in autonomous and self-adaptive systems (e.g., MAPE-K, feedback control loops)?
- Q3: What is the specific innovation in MAD’s treatment of human agents compared to previous MAS-based DT architectures that either model humans as data sources or external participants?
pages/ICSE2026-paper2859.md
+65
View File
@@ -0,0 +1,65 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code
date-start:: [[17-09-2025]] - 15:05
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code]]
parent::
todoist:: https://app.todoist.com/app/task/2859-trace-coder-a-trace-driven-multi-agent-framework-for-automated-debugging-of-6cVHmvW5WjQw4vmg
- ### [[Highlights]]
- ### [[Comments]]
- #.tabular
- ### Paper summary
- This paper presents TraceCoder, a multi-agent system to support the automated debugging of source code generated by LLMs. The approach is based on three specialized agents on Instrumentation, Analysis, and Repair. To guide the automated debugging process, the approach makes use of two introduced techniques, ie., Historical Lesson Learning (HLLM) and Rollback Mechanism (RM). They permi to avoid redundant failures. The authors claim significant improvements over state-of-the-art methods, achieving up to 34.43% relative gain in Pass@1 on benchmark datasets.
- ### Strengths
- + well-motivated and relevant problem
- + interesting multi-agent architecture
- ### Weaknesses
- - Experimental setup lacks detail. The granularity of the initial code generation (method/class/project), the test suite’s role and coverage, and how baselines were configured/applied are insufficiently explained
- - No agent orchestration framework is employed or discussed
- - Instrumentation phase is critical but underspecified. In particular, semantic-preserving behavior is assumed but not formally verified or tested
- ### Detailed comments for authors
- Novelty: The paper is about an interesting and novel technique based on MAS to deal with a relevant problem. The proposed combination of runtime tracing, historical error learning, and modular multi-agent design is novel and well-motivated. The paper contributes original ideas such as HLLM and RM in the context of LLM-driven code repair.
- Rigor: While the architecture is conceptually solid, key assumptions are not empirically validated, e.g., semantic preservation during instrumentation. Moreover, the experiments related to RQ1 lacks depths. Examples, setup details (class/function/project), and baseline configurations are missing.
- Relevance: The work is highly relevant given the increasing reliance on LLMs for code generation and the frequent presence of logic bugs in such code. Debugging automation remains a practical bottleneck in applying LLMs for software engineering at scale.
- Verifiability & transparency: Authors provide a link with the implementation of the proposed approach. However, details on the form and source of input prompts, testing strategies/coverage, and baseline configurations are missing.
- Presentation: Writing is generally clear, though certain technical claims (e.g., semantic integrity preservation) are not critically assessed. In addition, some terms like “minimal adjustments”, and “strategic print statements” are ambiguous and require proper definitions. Moreover, authors should give details on test cases, e.g., if they play some roles during the initial generation of source code.
- Detailed comments:
- p.3: “Instrumentation Agent inserts diagnostic probes”
Does it mean that it changes the previously generated code? This is a critical point. Clarify whether the instrumentation alters control flow or computational semantics, especially in complex programs.
- p.3: “The Instrumentation Agent employs a dedicated prompt…”
Is it sure that the instrumentation agent does not wrongly add statements that change the semantics of the code? You should explain how you ensure the correctness of the modified code, and whether any formal guarantees or empirical tests were performed.
- p.3: “with strategically placed print statements...” Confirm whether print statements are the only instrumentation method.
- p.3: “must not modify logic, comment out code, or introduce new variables” This is crucial. How do you ensure that? How is this enforced at generation time? Please elaborate.
- p.5: “allowed to make minimal adjustments”
How can you define such "minimal" adjustments? Define what “minimal” means (e.g., token delta, AST edit distance) and how it's enforced across iterations.
- p.5: “Communication follows a structured, sequential pattern…”
Please discuss why you didn’t use an existing MAS framework, especially when others provide orchestration, coordination, and policy enforcement.
- p.5: “instrumentation suggestions in subsequent iterations”
Is this always necessary?
- p.5: “Agents do not communicate directly...” But how can convergence be guaranteed in this loosely coupled setup?
- p.10: Conclusion: Several high-level contributions are claimed. However, the practical usage of the system is hard to infer, especially in terms of granularity of code, role of test cases in initial generation, and setup of generation pipeline.
- QUESTIONS:
- Q1: How is semantic preservation ensured during the instrumentation process?
- Q2: Why was a dedicated MAS framework not used to orchestrate agent interactions and maintain state across iterations?
- Can you provide more details about the experimental setup for RQ1? In particular:
- What is the granularity of the code used (function, class, full project)?
- What is the role of test suites in the initial generation?
- How were baselines configured and executed?
- How was test case coverage measured and controlled?
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
- {{query (and [[ffd400]] [[ICSE2026-paper2859]] )}}
collapsed:: true
- ### ❓️Questions
- {{query (and [[question]] [[ICSE2026-paper2859]] )[[question]]}}
query-table:: true
query-properties:: [:block]
pages/ICSE2026-paper2919.md
+68
View File
@@ -0,0 +1,68 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: Recommending Relevant Classes for Infrequent API Classes
date-start:: [[17-09-2025]] - 11:46
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Recommending Relevant Classes for Infrequent API Classes]]
parent::
todoist:: https://app.todoist.com/app/task/2919-recommending-relevant-classes-for-infrequent-api-classes-6cVHmvX54fQVgpV8
- ### [[Highlights]]
- ### [[Comments]]
- #.tabular
- ### Paper summary
- The paper proposes APIrel, an approach to mitigate bias when recommending API classes, even in the absence of frequent usage patterns in code. APIrel combines mined patterns and document features to train a classifier to predict relationships between infrequently used or new APIs. The paper evaluates APIrel by considering 5 libraries and shows promising results.
- ### Strengths
- + Relevant long-tail problem in API recommendation, where most APIs are rarely used and thus difficult to relate or recommend
- + Interesting attempt to move beyond client-based mining, by relying on API documentations
- ### Weaknesses
- Presentation is confusing and poorly structured, with forward references, missing definitions, and mixing of problem and solution
- The tool is not accessible, making reproducibility and verification impossible.
- Evaluation is limited and lacks user studies (e.g., developers' feedback on relevance predictions).
- ### Detailed comments for authors
- Novelty: The idea of leveraging document-based features rather than usage-based mining for inferring relationships among APIs is interesting and reasonably novel. However, novelty is somewhat undermined by vague distinctions from prior work. The “two lines of research” (document vs. client-based) are repeatedly mentioned but never formally defined with illustrative examples.
- Rigor: The technical rigor is compromised by the lack of concrete examples to clarify design choices, assumptions, and implementation steps. Several parts are abstract and theoretical without operational grounding (e.g., the use of “patterns,” “mined rules,” and model training steps).
- Relevance: The addressed problem is highly relevant for developers who need better tooling to understand or recommend infrequent APIs. However, the current presentation makes it difficult to assess the actual impact or applicability of the method.
- Verifiability & transparency: Broken link to the repository makes it impossible to validate or test the tool. Moreover, it is unclear how the tool is to be used, what the inputs are, or how results are visualized or interpreted. The data collection process (e.g., how patterns are mined or APIs extracted) is not reproducible due to insufficient procedural detail. The fact that SearchCode system is no longer online does not help in this regard.
- Presentation: This is the main problem of this paper. The writing is often unclear and the reader is supposed to go trhough the text many times to get the meaning of the presented concepts. The motivation is not well separated from the solution, especially in Section 2. I suggest adding explanatory examples, without them many parts of the paper hare hard to follow. Moreover, firgure and tables are not always correctly references and there are too many forward references. For instance section 7 is mentioned in the introduction.
- Detailed comments:
- page 1: "As there are many API classes, it is challenging to identify relevant API classes for a given API class." - Sentence is poorly written and redundant. Please rephrase to clearly state what the challenge is: e.g., is the difficulty in discovering dependencies, usage patterns, or semantic relationships?
- page 1: "APIrel uses mined patterns as seeds and compares API documents to build labeled data." - What exactly are the “mined patterns”? How are they extracted, from what sources, and at what stage of the process?
- page 1: "Given the documents of two API classes, our trained model can predict whether they are relevant." - Please clarify what type of documents are used here (e.g., Javadoc, README, class summaries). This needs to be made explicit.
- page 1: "As introduced in Section 7," - This is an overly early forward reference. Consider avoiding such jumps in the introduction. Core ideas should be self-contained in the early sections.
- page 1: "For instance, API documents rarely mention relevant API classes, especially when such classes are infrequent." - Statements like this should be supported by concrete examples to make the issue tangible to the reader.
- page 1: "For instance, researchers use Apriori algorithms to mine the relevant libraries." - This usage of Apriori is unclear. Specify what is mined, how support is defined, and what the items represent in this context.
- page 1: "APIrel. It is the first approach that infers relevant classes from documents without predefined templates." - What kinds of documents are used? This should have been clarified much earlier. The lack of early context makes it difficult to evaluate the novelty.
- page 2: "The document of HSSFWorkbook." - Ambiguous phrase. What is meant by "the document"? Please use consistent terminology throughout (e.g., API class description, Javadoc, etc.).
- page 2: "From the clients" - Please define what is meant by "clients" in this context. Client projects? Users? Code examples?
- page 2: "Table 3" - Typo. Likely meant to reference “Table 1.” Please correct.
- page 2: "SearchCode" - This resource appears to be offline. If it’s critical to the example or dataset, either replace it with an active resource or explain how the necessary data was retained.
- page 3: "Definition 1. The relevant API classes of an API class are classes that can be called together to implement functionalities." - The phrase “called together” is vague. Please formalize this definition and clarify what is meant by "calling a class."
- page 3: "To infer hidden patterns, we reduce the inference of infrequent relevant API classes into a classification problem..." - This paragraph needs a worked-out example to clarify the input/output of the classification function. The formal description is too abstract alone.
- page 4: "Line 1 builds a dictionary from mined patterns..." - This would be more understandable if tied to a running example. Refer to specific APIs from the motivating use case to make the logic concrete.
- page 4: "Line 6 checks whether the c1 and c2 classes appear in our dictionary..." - Please elaborate on this logic with an example. Without referring back to a real code snippet or API class, it remains abstract.
- page 6: "API documents in Table 3" - Table 3 appears to repeat library names listed elsewhere and does not clearly present documents. Please clarify what is meant by "API documents" here.
- page 6: "The repository of SearchCode has millions of projects..." - It's unclear how SearchCode contributes to the methodology. Is it used for mining patterns, extracting features, or labeling data?
- page 6: "4.2 No Baseline Statement" - This section reads more like an appendix to Related Work. Consider moving it and restructuring Section 2 to present motivation and prior work in a more integrated, example-driven fashion.
- page 6: "As introduced in Section 7," - Section 7 is referenced repeatedly and contains important information. Consider moving this section earlier in the paper (e.g., after the introduction).
- page 6: "The first line of approaches analyzes documents with templates..." - The distinction between the two families of approaches (document-based and client-based) is referenced frequently. Please clarify this with illustrative examples.
- page 7: "The accuracy" - Accuracy of what exactly? Prediction of relevant classes? Clarify what the ground truth is and whether human validation was involved.
- page 10: "We evaluated APIrel on five popular libraries..." - Given the subjective nature of what counts as “relevant,” evaluation should involve developers to verify the usefulness of predictions.
- Questions
- Q1: What exactly are the “documents” used as input by APIrel? Are they structured Javadoc descriptions, source code comments, online documentation, or something else?
- Q2: How is “relevance” between two API classes defined and operationalized during model training and evaluation? What constitutes a positive or negative label? Can such labels automatically assessed without any human involvment?
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
- {{query (and [[ffd400]] [[ICSE2026-paper2919]] )}}
collapsed:: true
- ### ❓️Questions
- {{query (and [[question]] [[ICSE2026-paper2919]] )[[question]]}}
query-table:: true
query-properties:: [:block]
pages/ICSE2026-paper3125.md
+48
View File
@@ -0,0 +1,48 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval
date-start:: [[16-09-2025]] - 16:09
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@SRC-Retrieval: Semantic-Based GitHub Repository and Code Retrieval]]
parent::
todoist:: https://app.todoist.com/app/task/3125-src-retrieval-semantic-based-git-hub-repository-and-code-retrieval-6cVHmvhGJfhPWjQg
- ### [[Highlights]]
- ### [[Comments]]
- #.tabular
- ### Paper summary
- The paper presents an approach to retrieving GitHub repositories and specific code files starting from functional requirements given by developers. Functionalities are extracted from README files and GitHub issues, which are about implemented functionalities. The approach has been compared with two different baselines.
- ### Strengths
- + Interesting and relevant topic
- + Linking functionalities with source code is indeed important
- ### Weaknesses
- Problems in the way dataset was constructed, especially regarding the role of classifiers in labeling large amounts of data, potentially introducing noise and cascading errors
- The approach relies heavily on README files for functionality extraction, but the validity and precision of these mappings are questionable.
- The evaluation section does not convincingly show that the retrieved code files actually meet user requirements in a semantically meaningful way.
- The baselines chosen for comparison appear weak, and the omission of modern tools like GitHub Copilot undermines the credibility of the evaluation.
- The presentation is redundant in different parts, especially with repeated technical details on model training.
- ### Detailed comments for authors
- Novelty: The paper presents a retrieval pipeline that integrates multiple transformers to map functional requirements to GitHub repositories and specific code files. While this integration is interesting, the paper is not convincing with respect to the quality of the obtained results especially in comparison with existing supporting technologies like Copilot. The considered baselines are not appropriate because they do not permit to actually stress the novelty of the proposed approach with respect to existing development assistance tools.
- Rigor: The approach heavly rely on multiple trained classifiers, each operating on noisy or weakly supervised data. For instance, the extraction of functionalities from README files lacks solid grounding and examples. The same applies to the issue-to-code linkage process, where the labeling process has been automated without discussing the accuracy of such an automated process. Thus the risk of compounded errors due to the different classifiers that have been used to create the training dataset is not addressed.
- Relevance: The paper is highly relevant to software engineering practice, particularly for developers seeking concrete examples of functionality implementations. However, the lack of comparison with widely adopted tools like Copilot reduces the practical significance of the proposed approach.
- Verifiability & transparency: How functional requirements are defined and extracted remains ambiguous. The use of classifiers to assess whether a GitHub issue represents a valid functionality or not is prone to mislabeling, and the paper does not provide error analysis or a discussion on its impact. The absence of ablation studies, particularly to separate the contribution of README-derived vs. issue-derived functionalities, is an important omission. Moreover, the evaluation lacks a user-centered validation of whether retrieved code files actually satisfy the intended requirement.
- Presentation: The paper is generally readable but suffers from redundancy. Many paragraphs related to the data creation steps are repeated, Some conceptual terms like “semantic alignment” or “repository functionality” are used early on but only vaguely defined.
- QUESTIONS:
- Q1: How have you quantified the effect of classification errors (e.g., incorrectly labeled issues or README sentences) on the overall retrieval performance?
- Q2: What is the actual contribution of README files to the overall retrieval pipeline? Have you considered an ablation study that separates the impact of README-derived vs. issue-derived functionalities?
- Q3: Why have you not compared your method against modern tools like GitHub Copilot?
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
- {{query (and [[ffd400]] [[ICSE2026-paper3125]] )}}
collapsed:: true
- ### ❓️Questions
- {{query (and [[question]] [[ICSE2026-paper3125]] )[[question]]}}
query-table:: true
query-properties:: [:block]
pages/ICSE2026-paper3485.md
+39
View File
@@ -0,0 +1,39 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: A kNN-Based Recommender System for Test Case Reuse in Agile Development
date-start:: [[18-09-2025]] - 01:59
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@A kNN-Based Recommender System for Test Case Reuse in Agile Software Development]]
parent::
todoist:: https://app.todoist.com/app/task/3485-a-k-nn-based-recommender-system-for-test-case-reuse-in-agile-development-6cVHmvgxqh6VgCcg
- ### [[Comments]]
- #.tabular
- ### Paper summary
- This paper proposes a KNN-based Recommender System to support the reuse of test cases by leveraging a domain-specific taxonomy and historical user stories. Authors have performed two different experiments. An off-line experiment to identify the configuration that permits to get the achieve the best recommendation performance. The on-line experiment has been performed by using such a configuration with an industrial case study involving two agile projects. Results show promising potential for enhancing test reuse.
- ### Strengths
- + The paper addresses a relevant and practical problem in agile software testing
- + Simple and lightweight solution compared to deep-learning-based alternatives
- ### Weaknesses
- - The central assumption, that similar user stories lead to reusable test cases, is strong and not critically examined
- - The evaluation lacks a proper baseline or comparative study, which limits the assessment of relative performance
- ### Detailed comments for authors
- Novelty: The idea of test case reuse is not new, but this paper innovates by focusing on early-stage reuse in agile environments and using structured user stories with domain taxonomies. In this respect, I found the paper interesting and I liked the simplificity even though effective simplicity of the proposed solution.
- Rigor: The experimental design is solid and includes statistical tests to select the best configuration during the off-line experiments. However, the paper requires revision to address a number of issues as listed below:
- The paper is based on the assumption "similar user stories have similar tests". I found this assumption very strong. Minor variations in implementation can lead to very different tests. It is necessary to clarify whether the retrieved tests were used as inspiration or directly reused. Were they used as-is, adapted, or just served as reference?
- The relevance of the retrieved test cases is not very high: a large portion of accepted tests were only moderately relevant.
- The practical utility of the recommended tests (whether they were reused as-is, adapted, or merely used as inspiration) is not clarified.
- A few important details on the context of the online study (e.g., nature of the company, business domain) are missing, which affects external validity.
- No mention of effort/time metrics, such as time saved or effort required to adapt reused tests, limits the construct validity.
- Relevance: The paper is very relevant to practitioners working in agile contexts. Reuse of test cases could lead to cost and time savings, but the paper does not quantify this aspect as previously pointed out. Moreover, by referring to Fig. 5, the results of the online experiments are not impressive. Nearly half of the accepted tests had low relevance. This needs a more nuanced discussion, especially in the conclusion. Moreover, what does acceptance mean? Were tests reused unchanged? How much effort was required to make them usable?
- Verifiability & transparency: The design and implementation of the RecSys are clearly described. However, the supplementary material includes only the dataset used during the experiments. The developed tools are not included. Thus it is not possible to replicate the performed experients.
- Presentation: Overall, the paper is well-written, logically organized, and easy to follow despite the issues discussed above.
- Questions:
- Q1: To what extent can the recommended test cases be reused as-is versus requiring significant adaptation?
- Q2: How generalizable is the proposed taxonomy-based RecSys to other domains?
pages/ICSE2026-paper3924.md
+54
View File
@@ -0,0 +1,54 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE]]
full-title:: Determining Application Test Results Using Adaptive JSON
date-start:: [[14-09-2025]] - 18:01
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Determining Application Test Results Using Adaptive JSON]]
parent::
todoist:: https://app.todoist.com/app/task/3924-determining-application-test-results-using-adaptive-json-6cVHmvg3mM8ghg48
- ### [[Highlights]]
- ### [[Comments]]
- #.tabular
- - ### Paper summary
- The paper presents an approach to test JSON-based APIs. The main building blocks of the proposed approach are "Skeleton JSON", "Adaptive JSON", and "Adaptation Sets". By means of these components, engineers can precisely define which parts of an API response have to be validated and how. The application of the approach on two different case studies has been shown.
- - ### Strengths
- + Relevant problem
- + Promising approach based on the declarative "Adaptation Set" mechanism for tuning the testing process
- - ### Weaknesses
- - The paper is not always well written
- - Several parts ar repetitive, vague, or poorly written.
- - The writing includes multiple formatting and typographic errors (e.g., Markdown synatx, missing spaces)
- - Gray literature is used even critical and motivational parts of the paper that would require peer-reviewed references
- - Comparisons with existing techniques (especially other schema-inference-based approaches) are missing or superficial
- - The validation of the claimed advantages (e.g., flexibility, maintainability, reduction of brittleness) is not adequately supported by empirical evidence.
- - ### Detailed comments for authors
- Novelty: The paper does not clearly compare the proposed approach with existing methods that extract or synthesize schemas from JSON payloads. A comparison of the proposed testing mechanism with existing baselines is also missing.
- Rigor: The methodology is described conceptually, but formal definitions, measurable properties, and an empirical evaluation are missing. Moreover, claims such as “resilient to insignificant changes” or “lightweight” need quantification or validation to be taken seriously.
- Relevance: The paper targets a relevant and timely problem in automated software testing, especially in DevOps and CI/CD pipelines that depend on stable, low-maintenance test suites. However, without a comparative evaluation, the practical significance is not clear.
- Verifiability & transparency: There is no mention of tool availability, datasets, or replication packages. The paper should provide a GitHub repository or similar so that readers can downlod tools and related artifacts to play with the proposed approach. Two case studies have been discussed, even though the given details are not enough to replicate them.
- Presentation: This is the main issue of the paper. There are redundant sentences, the writing presents the approach only at conceptual level and several formatting errors are present. Many references from non-peer-reviewed sources (e.g., Medium, Postman blogs) are given.
- Detailed comments:
- p.1: The limitation of JSON-DDT is vaguely mentioned; its impact or relation to the contribution is not evident.
- p.2: “resilient to insignificant changes” - This is too vague. Define what constitutes an “insignificant” change.
p.2: JSON Schema is mentioned, but no comparative discussion is provided - how does the proposed approach differ from or improve upon it?
- p.2: The supposed “distinct advantages” of the technique need to be clarified and situated in the literature (e.g., compare with 10.1016/j.knosys.2016.03.020 and 10.1109/MODELS50736.2021.00033).
- p.2: Claim that Skeleton JSON is “lightweight” and suitable for test automation is not supported by any empirical or architectural argument.
- p.2: What were the requirements that led to the definition of Adaptive JSON? These are not made explicit.
- p.7: The claim about brittleness and spurious failures in Snapshot Testing should be supported by examples or quantitative evidence.
- p.8: The authors state that the technique was “demonstrated in case studies” - but there is no real comparison with other approaches, no quantitative results, and no ablation study.
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
- {{query (and [[ffd400]] [[ICSE2026-paper3924]] )}}
collapsed:: true
- ### ❓️Questions
- {{query (and [[question]] [[ICSE2026-paper3924]] )[[question]]}}
query-table:: true
query-properties:: [:block]
pages/ICSE_2026_WS_28.md
+21
View File
@@ -0,0 +1,21 @@
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE2026-WS]]
full-title:: Graphical Interface Model for Empowering Web Application Users to Make Sustainable Choices: a Technology Acceptance Study
date-start:: [[23-11-2025]] - 19:27
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Graphical Interface Model for Empowering Web Application Users to Make Sustainable Choices: a Technology Acceptance Study]]
parent::
todoist:: https://app.todoist.com/app/task/28-graphical-interface-model-for-empowering-web-application-users-to-make-sustai-6fGCcxFv9QmhxQw6
- ### [[Comments]]
- SUMMARY: The paper proposes a pluggable graphical interface model to enable end-users to customize web applications with the goal of reducing energy consumption and increasing sustainability awareness. A Figma prototype is evaluated through a technology acceptance study based on UTAUT2. The topic is relevant and the idea of involving users in sustainability-oriented customization is interesting, but the paper raises concerns regarding feasibility, generalizability, and the validity of the claimed benefits.
- COMMENTS: The paper is about a relevant and timely topic addressing sustainability and user awareness. The idea of involving end-users in sustainability decisions is interesting. The prototype is clearly articulated, and the authors acknowledge key challenges such as immature metrics and difficulties in mapping environmental indicators to real behavior. However, my main concerns are related to the following issues:
- The main issue of the paper is that it does not explain how user-driven configuration leads to measurable or validated reductions in energy consumption. The link between customization and actual savings remains speculative.
- The generality of the proposed model is unclear. It is doubtful that the approach can be safely applied to arbitrary web applications without breaking layouts, dependencies, or expected behaviours.
- The paper suffers from repetition, especially regarding the model’s universality and vision. Some claims of novelty are overstated.
- To summarize, the proposed idea is interesting enough to stimulate meaningful discussion, and the prototype and preliminary acceptance study provide a reasonable starting point for future work. I therefore recommend weak accept, mainly for the value of the topic and the potential to enrich the workshop discussion.
pages/ICSE_2026_WS_GREENS_27.md
+18
View File
@@ -0,0 +1,18 @@
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE2026-WS]]
full-title:: Bridging the gap between industry and academia: sustainability in LLM-assisted software engineering
date-start:: [[23-11-2025]] - 16:56
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Bridging the gap between industry and academia: sustainability in LLM-assisted software engineering]]
parent::
todoist:: https://app.todoist.com/app/task/27-bridging-the-gap-between-industry-and-academia-sustainability-in-llm-assisted-6fGCcw4wV8fQW9qc
- ### [[Comments]]
- The paper reports on the discussions held during the SILAS (Sustainability in LLM-assisted Software Development) workshop. It highlights sustainability challenges in LLM-based software engineering from both academic and industrial perspectives.
- Although the topic is highly relevant and timely, the work suffers from issues in presentation and structure. The discussion is fragmented across the paper, and the narrative lacks a coherent flow. The choice of the three focus areas is not motivated. I suggest reorganizing the discussion section around clearly defined challenges and their corresponding research directions. A dedicated table mapping focus areas, identified challenges, and the research directions considered relevant during the SILAS event would greatly improve clarity.
- Despite these structural issues, the paper addresses an important subject and can trigger interesting discussions during the workshop. I recommend revising the organization of the paper as suggested above.
pages/Invited talk at LLMA4SE Summer School website.md
+192
View File
@@ -0,0 +1,192 @@
tags:: #todoist-task, [[Talks]], [[WORK]], [[CONFERENCES]]
date:: [[31-08-2025]] - 11:46
progress:: {{renderer :todomaster}}
- ### **Invited talk Tasks**
- DONE Raffinare l'introduzione del concetto di agenti AI
id:: 68ac6e54-e572-42f4-8116-625b4d85d757
collapsed:: true
- Creare / trovare una figura che rappresenti i concetti principali graficamente
- DONE Rivedere le slides di presentazione dei 5 tipi di agenti
- DONE Fare le slide conclusive
id:: 68b4c69b-fa0b-41c1-9633-b87c6cf6ab33
:LOGBOOK:
CLOCK: [2025-09-01 Mon 00:04:03]--[2025-09-01 Mon 00:04:04] => 00:00:01
:END:
- DONE Ridurre un pochino il numero di slides
id:: 68b4c69b-4d77-4192-9cff-d9f87cb200f4
- DONE Sistemare le immagini nel summary
id:: 68b4c69b-7fdf-4663-89af-ac6df65d88af
- Punti da sottolineare:
- Challenges related to the adoption of single-agent systems
- ### **Notes from the venue**
- **Program**: [LLMA4SE 2025 - 1st International Summer School on LLM-based Agents for Software Engineering](https://i3lab.unex.es/summer-school/#agenda)
- **Venue**: [Universidad de Extremadura](https://www.unex.es/) - [Caseres](https://es.wikipedia.org/wiki/C%C3%A1ceres)
- #### **READINGS**
collapsed:: true
- {{query (and [[Invited talk at LLMA4SE Summer School website]] [[Reading]]) (not [[GOALS-TODOIST]]) (not [[TODOIST-LOGSEQED]]))}}
query-table:: true
query-properties:: [:block]
- #### **First day of the event [[01-09-2025]]**
collapsed:: true
- ##### I talked with different people after my talk
- I talked with a student working with Javier from **Universitat Politècnica de Catalunya** on the EU project [HIVEMIND | Human-centred collaboratIVE MultI-ageNt framework for accelerating software Development and maintenance - HIVEMIND](https://hivemind-project.eu/) [[PROJECTS/MOSAICO]]
- **Jesús M. González Barahona** offered to collaborate concerning the "community" aspects of agents.
- I talked with **Jie Zhang** <jie.zhang@kcl.ac.uk>
- Here is the AIware arXiv track I mentioned, the deadline is this Friday: [https://2025.aiwareconf.org/track/aiware-2025-arxiv-track](https://2025.aiwareconf.org/track/aiware-2025-arxiv-track)
- There is also a benchmark and dataset track with the same deadline.
- The efficiency benchmark I mentioned is: [https://arxiv.org/abs/2402.02037](https://arxiv.org/abs/2402.02037)
- The test case generation benchmark (under submission): [https://arxiv.org/abs/2508.00408](https://arxiv.org/abs/2508.00408)
- [[Benchmarks]] seem to be very relevant and is attracting the community. We need to focus on that. There is one slide from the talk of Jesus we can have a look at ((68b57fc1-5214-405c-b4f7-58296590c06d))
- ##### **Generative AI models running in your own structure**
id:: 68bac2bb-1db8-41cb-81ed-7ef7f76e1491
- [tdd-workshop / SelfHostable-AI-Models · GitLab](https://gitlab.com/tdd-workshop/selfhostable-ai-models)
- ![presentation.pdf](../assets/presentation_1756721524484_0.pdf)
- ((68b572ad-6444-494c-8929-43d2665321e6)) for instance if we are fine-tuning we can share the results of the fine-tuning
- ((68b572d4-f669-47ca-b942-f3a52b9e0683)) parts of the open-source aspects are applied to models
- ((68b57311-0b75-4a2a-86a9-b7236e7d2611))
- Important for different reasons, e.g., trust, data leakage,. You really control the information provided by the model.
- ((68b5737f-d5d0-41fd-bdc5-e574964d08ed)) [[STAR]]
id:: 68b57381-292d-4e53-8b79-b0378d3ddcca
- Papers on ((68b57a82-c115-4a56-a85b-4241b54bda29))
- What is fine-tuning ((68b57e64-b29f-42ea-9620-be4bbfa7edc2))
- Have a look at OpenRouter to see the attributes that are given to each of the managed models [[PROJECTS/MOSAICO/WP2]]
id:: 68b598e8-992a-433f-b685-5318c5ba0f4d
:LOGBOOK:
CLOCK: [2025-09-02 Tue 11:28:12]--[2025-09-02 Tue 11:28:13] => 00:00:01
:END:
- ##### **Workshop 1. Test-driven development with the help of generative AI**
- ![image.png](../assets/image_1756730968439_0.png)
- ![image.png](../assets/image_1756731012893_0.png)
- ![image.png](../assets/image_1756731026653_0.png)
- ![image.png](../assets/image_1756731056004_0.png)
- ![image.png](../assets/image_1756731095891_0.png)
- ![image.png](../assets/image_1756731123130_0.png)
- http://www.promptingguide.ai
- ![image.png](../assets/image_1756731154361_0.png){:height 354, :width 519}
- ![image.png](../assets/image_1756731182852_0.png)
- ![image.png](../assets/image_1756731196350_0.png)
- ![image.png](../assets/image_1756731230828_0.png)
- ![image.png](../assets/image_1756731260195_0.png)
- ![image.png](../assets/image_1756731270325_0.png)
- ![image.png](../assets/image_1756731334437_0.png)
- ![image.png](../assets/image_1756731344880_0.png)
- ![image.png](../assets/image_1756731422652_0.png)
- ![image.png](../assets/image_1756732911224_0.png)
- ![image.png](../assets/image_1756732979539_0.png)
- ![image.png](../assets/image_1756732990374_0.png)
- ![image.png](../assets/image_1756733148910_0.png)
- ![image.png](../assets/image_1756733252916_0.png)
- ![image.png](../assets/image_1756733269130_0.png)
- ![image.png](../assets/image_1756733280118_0.png)
- ![image.png](../assets/image_1756733286917_0.png)
- ![image.png](../assets/image_1756733307931_0.png)
- ![image.png](../assets/image_1756733720525_0.png)
- ```
export OPENROUTER_API_KEY="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"
```
- [Giovanni Rosa / Currante · GitLab](https://gitlab.com/grosa1/currante)
- [tdd-workshop / TDD-for-Code-Generation-Lab-Sept-25 · GitLab](https://gitlab.com/tdd-workshop/tdd-for-code-generation-lab-sept-25)
- #### **Second day of the event [[02-09-2025]]**
- ##### **MAS for Code Generation - Jie M.Zhang, King's College London**
- *History of agents*
- 1980s- software agents
- 1990s - MAS
- 2010 - Agents in deep reinforcement learning
- 2020- LLM-based agents, AI agents
- *There are a lot of definition about agents.*
- There is one that has been mentioned, from *Wooldrige, MIchael "Intelligent agents: The key concepts"*
- Hugging face in its "Agent course" gives the following definition: An agent is a system that leverages an AI model to interact with its environment....
- Tutorial fro ICML 2025: Jailbreking LLMs and Agentic Systems
- Mistral AI has also another definition:
- >AI agents are autonomous systems powered by large language models (LLMs) that, given high-level instructions, can plan, use tools, carry out processing steps, and take actions to achieve specific goals. These agents leverage advanced natural language processing capabilities to understand and execute complex tasks efficiently and can even collaborate with each other to achieve more sophisticated outcomes.
- [Agents Introduction | Mistral AI](https://docs.mistral.ai/agents/agents_introduction/#:~:text=%E2%80%8B,to%20achieve%20more%20sophisticated%20outcomes.)
- *When to use multiple agents?*
- A number of questions need to be considered including
- How big and complex is the task?
- Budget?
- Capabilities of a single agent?
- Do the agents have different expertise that I need?
- Advantages of multi-agents
- Objectivity: provide more reliable and objective feedback towards sub-task performance
- Clear instructions: task-switches can lead to significant performance degradation
- Scalability: Easier to scale systems by adding more agents
- Fault tolerance: if one agent fails, others can continue
- How to use agents for code genration?
- look at the "Tutorial fro ICML 2025: Jailbreking LLMs and Agentic Systems"
- [A survey of self-evolving agents](https://arxiv.org/abs/2507.21046) [[PROJECTS/MOSAICO]] [[TEACHING/SE4AS]] [[Reading]]
id:: 68b6a403-1ce2-4fe5-9668-54e32ac0e222
:LOGBOOK:
CLOCK: [2025-09-02 Tue 10:20:45]--[2025-09-02 Tue 10:20:46] => 00:00:01
:END:
- *Challenges and Opportunities*
- TODO [2503.13657 - Why Do Multi-Agent LLM Systems Fail?](https://arxiv.org/abs/2503.13657) [[Reading]]
- Non-determinism
- [En Empirical Study of the non-determinism of chatgpt and code generation](https://arxiv.org/abs/2308.02828) [[Reading]]
- Efficiency
- SWE-Effi: Re-Evaluating SWE Agent Solutions for their Efficiency
- [SWE Effi](https://centre-for-software-excellence.github.io/SWE-Effi/about/introducing-SWE-effi)
- [EffiBench: Benchmarking the Efficiency of Automatically Generated Code](https://arxiv.org/abs/2402.02037)
id:: 68b6a86a-0914-4535-b10a-d81519358f6a
- Hallucination
- [Hallucination Detection in LLM](https://arxiv.org/abs/2502.15844) [[Reading]]
-
-
- *Books*:
- Agent-based software development - Michael Luck, D'Inverno et
- [Agent-based Software Development - Michael M. Luck, Ronald Ashri, Mark D'Inverno - Google Books](https://books.google.es/books/about/Agent_based_Software_Development.html?id=AXMhngEACAAJ&redir_esc=y)
-
- ##### **AI and Software Development**
- Expectation from Industry about AI
- For CTO the main reason is 20% productivity gain
- For Engineer managers/team leads: faster delivery, satisfaction (+10 hours/week saved). They are worried about quality and maintainability
- For senior/staff developers: Skeptical, fear of being behind or deskilled (19% slower for experienced devs)
- For junor developers: embrace it quickly, unclear how it affects learning
- Il ruolo di AI secondo Microsoft
- ![Immagine WhatsApp 2025-09-02 ore 10.57.26_15b51d90.jpg](../assets/Immagine_WhatsApp_2025-09-02_ore_10.57.26_15b51d90_1756803478464_0.jpg)
- Risks from an industry perspective
- Intellectual property
- Security
- Reliability
- Reliance (e.g., what happens when Copilot is down)
- Guardrails
- Trust
- Evaluation
- How to compare different tools/agents?
- [Vibe Busters - Your AI-Generated Codebase is Haunted.](https://vibebusters.com/)
- When it works best
- Scripting
- Small projects
- Prototyping
- Code review
- When it doesn't
- Very large codebases
- Custom undocumented frameworks or tooling
- Debugging internals
- [MIT report: 95% of generative AI pilots at companies are failing | Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/) [[Reading]]
- Why should we study
- Not knowing things in themselvers limits your ability to use them ot to realize that what you are reading is wrong [[TEACHING/SE4AS]]
- TESTING EFFECT
- >In psychology, the testing effect is ==the phenomenon where taking a practice test or retrieving information from memory enhances long-term memory retention and learning more effectively than passively restudying the same material==. This finding shows that the act of "testing" is not just an assessment tool but also a powerful learning tool, improving one's ability to recall information later.
-
- ##### **From workflow-based to fully-agentic applications: smolagents and LangGraph - Antonio Garcia-Dominguez**
collapsed:: true
- [agarciadom/llma4se-2025: Materials for LLMA4SE talk + workshop](https://github.com/agarciadom/llma4se-2025) [[TEACHING/SE4AS]]
- *From LMs to agents*
- Agents = LM + tools + prompt
- tool is a manually written code that an LM can invoke to retrieve information, or permorm an action on our behalf
- Interesting patterns of integrating different agents
-
- ##### **Workshop 2 - Development of agentic applications with human-in-the-loop via LangGraph**
source:: [agarciadom/llma4se-2025: Materials for LLMA4SE talk + workshop](https://github.com/agarciadom/llma4se-2025/tree/main)
collapsed:: true
- default langsmith API KEY
- ```
LANGSMITH_API_KEY="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"
```
- The Service langsmith API KEY
- ```
LANGSMITH_API_KEY="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"
```
- Context schema is to configure the agent
-
pages/Invited talk at MDE Intelligence.md
+18
View File
@@ -0,0 +1,18 @@
tags:: #todoist-task, #invitedtalk
date:: [[28-09-2025]] - 18:40
progress:: {{renderer :todomaster}}
- ### Tasks
-
- ### Notes
- You can find the program of the MDE Intelligence 2025 workshop here:
[MDE Intelligence](https://mde-intelligence.github.io/#program)
- Title: Modeling for Agentic AI - Opportunities for the MDE Community in the AgentWare Era
- Abstract: The transition from PromptWare to AgentWare raises fundamental questions on how to design, orchestrate, and govern communities of AI agents in software engineering. The modeling community has an important opportunity to shape this transformation. This talk will highlight how Model-Driven Engineering can provide the abstractions, languages, and tools to specify agent roles, protocols, governance policies, and quality assessment frameworks for multi-agent systems. I will discuss how the EU MOSAICO project (https://mosaico-project.eu/) is going to leverage model-based techniques to build a repository of AI agents enriched with standardized metadata, KPIs, and governance mechanisms. By presenting MOSAICO's contributions, such as its taxonomy of AI agents, repository design, and [[benchmarking framework]], the talk will highlight specific research challenges for the MDE community, including the modeling of agent roles, interaction protocols, and governance policies.
- Short bio: Davide Di Ruscio is a Full Professor of Computer Science at the University of L’Aquila, Italy, where he also serves as Director of the PhD Program in Information and Communication Technology. His research interests include software engineering, model-driven engineering (MDE), and the application of artificial intelligence to software development. He has contributed to several European and national research projects, most recently MOSAICO, a Horizon Europe project on multi-agent systems for software engineering. He has co-authored numerous publications in top-tier international venues and has been actively involved in conference organization and editorial activities. His current work focuses on how generative AI and multi-agent systems can transform the engineering of software systems.
- SCHEDULE
- The evolution of software development paradigms - 5 mins
- Opportunities and challenges of applying generative AI in software engineering - 5 mins
- Introduce the MOSAICO EU project - 10 mins
- Opportunities for the MDE community - 10 mins
- Slides: ![2025-10-MDEIntelligence-MoDELS-WS.pdf](../assets/2025-10-MDEIntelligence-MoDELS-WS_1760163488768_0.pdf)
pages/Invited talk at workshop ASE.md
+12
View File
@@ -0,0 +1,12 @@
tags:: #todoist-task, #invitedtalk, [[PROJECTS/MOSAICO]]
date:: [[28-09-2025]] - 18:24
email:: ✉: [Web Link](https://outlook.office365.com/owa/?ItemID=AAMkADM1NGNiNjk0LTY0ZGUtNDgzOC04MDM5LWNhODNkYWNjNjU4YwBGAAAAAACT6qp78kRgRKuUMBdWEga%2FBwCOhWlC8F7PRKzlljZYZYQmAAAAAAEMAACOhWlC8F7PRKzlljZYZYQmAAhQr2DBAAA%3D&exvsurl=1&viewmodel=ReadMessageItem)
progress:: {{renderer :todomaster}}
- ### Tasks
-
- ### Notes
- Il talk si farà il [[16-11-2025]]
- **Title**: From PromptWare to AgentWare: Multi-Agent Systems for Reliable AI in Software Engineering
- **Abstract**: Software development is rapidly evolving from traditional coding practices to new paradigms where Large Language Models (LLMs) and agentic AI play a central role. After the emergence of PromptWare, we are now entering the AgentWare era, where multi-agent systems (MAS) collaborate to design, implement, and validate software. This talk explores the opportunities and challenges of LLM-based multi-agent systems in software engineering. I will illustrate how multiple AI agents can cooperate, complement each other's strengths, and be governed under human supervision to increase reliability, transparency, and trust in AI-assisted development. Special emphasis will be given to the MOSAICO Horizon Europe project (https://mosaico-project.eu/), which is building a platform for managing, orchestrating, and supervising AI agents tailored to software engineering tasks. The talk will present examples, insights from existing MAS frameworks, and future research directions on governance and quality assessment in AI-driven software engineering.
- **Short bio**: Davide Di Ruscio is a Full Professor of Computer Science at the University of L’Aquila, Italy, where he also serves as Director of the PhD Program in Information and Communication Technology. His research interests include software engineering, model-driven engineering (MDE), and the application of artificial intelligence to software development. He has contributed to several European and national research projects, most recently MOSAICO, a Horizon Europe project on multi-agent systems for software engineering. He has co-authored numerous publications in top-tier international venues and has been actively involved in conference organization and editorial activities. His current work focuses on how generative AI and multi-agent systems can transform the engineering of software systems.
pages/KaraKeep-Highlights (conflicted copy 2025-12-27 195913).md
+76
View File
@@ -0,0 +1,76 @@
icon:: ✏️
generation_time:: [[2025-12-27]] T17:00:54Z
- # **TODOs and IDEAs**
- {{query (and [[TODO]] [[KaraKeep-Highlights]] (or [[Ideas]] [[KaraKeep-Highlights]]))}}
query-table:: true
query-properties:: [:block]
- ## **Open - Le regole del gioco**
source:: https://www.open.online/le-regole-del-gioco/
url:: https://karakeep.diruscio.org/dashboard/preview/au4h7zjntjdakspb0gcl51bd
tags:: [[behavioral addiction]] [[digital addiction]] [[gaming disorder]] [[mental health]] [[youth risk]]
- Le cosiddette New Addiction sono capaci di diventare l’obiettivo primario della nostra mente finché l’opzione di smettere non rappresenta più una scelta libera.
background-color:: green
- in Italia tra il 10 e il 15% della popolazione presenti comportamenti che rientrano, in forma più o meno manifesta, nei criteri delle nuove dipendenze
background-color:: green
- Durante il primo lockdown uno studio pubblicato su Frontiers in Psychiatry, condotto dall’Istituto di Neuroscienze di Firenze in collaborazione con il Dipartimento di Psichiatria e Scienze del Comportamento della Albert Einstein College of Medicine di New York, ha rilevato che il 23,6% dei soggetti coinvolti mostrava sintomi compatibili con una forma di gioco d’azzardo patologico.
background-color:: green
- Nello studio condotto su studenti delle scuole superiori pubblicato su CNS Spectrums, i ricercatori hanno registrato il 5,4% degli studenti nella categoria di “internet addicted”; percentuali preoccupanti sono emerse anche per altre dipendenze: il 16% degli studenti ha ottenuto per esempio punteggi talmente alti nella scala dedicata al gioco d’azzardo da essere classificato nella fascia clinica definita come “problema estremo”
background-color:: green
- id:: 69500f28-4528-4606-9cdb-acc40518e3a4
> **Note:** #card
- ## **Top AI Agentic Workflow Patterns**
source:: https://blog.bytebytego.com/p/top-ai-agentic-workflow-patterns
url:: https://karakeep.diruscio.org/dashboard/preview/iz529wt1xybxstag5cmcrl1l
tags:: [[AI automation]] [[Agentic Workflows]] [[Artificial Intelligence]] [[Reflective Systems]] [[Tool Integration]]
- An agentic workflow doesn’t just respond to a single instruction. Instead, it operates with a degree of autonomy, making decisions about how to approach a task, what steps to take, and how to adapt based on what it discovers along the way. This represents a fundamental shift in how we think about using AI systems.
background-color:: green
- > **Note:** #IMPORTANT
- An agentic system, however, might first search the web for current information on the topic, then organize the findings into themes, draft sections of the report, review each section for accuracy and coherence, revise weak areas, and finally compile everything into a polished document
background-color:: green
- Instead of generating output in a single pass, agentic workflows involve cycles where the agent takes an action, observes the result, and uses that observation to inform the next action
background-color:: green
- Agentic workflows bring this same adaptive, iterative quality to AI systems.
background-color:: green
- five essential agentic workflow patterns
background-color:: blue
- The reflection pattern works best for tasks where quality matters more than speed and where there are subjective aspects that benefit from review.
background-color:: blue
- > **Note:** Reflection Pattern
- In the tool use pattern, agents are equipped with a set of capabilities they can invoke when needed. These might include web search engines for finding current information, APIs for accessing services like weather data or stock prices, code interpreters for running programs and performing calculations, database query tools for retrieving specific records, file system access for reading and writing documents, and countless other specialized functions. The critical distinction from traditional software is that the agent itself decides when and how to use these tools based on the task at hand.
background-color:: blue
- > **Note:** Tool use pattern
- ## **Contratto “Istruzione e Ricerca” 2022/2024, FLC CGIL: retribuzioni insufficienti, non firmiamo**
source:: https://m.flcgil.it/comunicati-stampa/flc/contratto-istruzione-e-ricerca-2022-2024-flc-cgil-retribuzioni-insufficienti-non-firmiamo.flc
url:: https://karakeep.diruscio.org/dashboard/preview/khv9wkq94ax8wi79swli9hnz
tags:: [[collective bargaining]] [[education]] [[labor union]] [[public sector]] [[research]]
- La nostra non firma di oggi vuole essere un messaggio chiaro nei confronti di un Governo che ha scientemente programmato il taglio delle retribuzioni di oltre 1,3 milioni di lavoratrici e lavoratori, già con gli stipendi più bassi di tutto il settore pubblico. Ora il Governo si deve far carico di colmare il divario retributivo con il resto dei dipendenti della pubblica amministrazione e garantire il completo recupero dell’inflazione
background-color:: green
- ## **GitHub - muratcankoylan/Agent-Skills-for-Context-Engineering: A comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.**
source:: https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
url:: https://karakeep.diruscio.org/dashboard/preview/mujjzfwwjb2xbqiugz3i92nv
tags:: [[AI System Optimization]] [[Agent Architectures]] [[Artificial Intelligence]] [[Context Engineering]] [[Multi-Agent Systems]] [[agent skills]]
- The fundamental challenge is that context windows are constrained not by raw token capacity but by attention mechanics
background-color:: green
- "lost-in-the-middle" phenomenon, U-shaped attention curves, and attention scarcity.
background-color:: yellow
- Effective context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of desired outcomes.
background-color:: blue
- > **Note:** #card
- ## **7 Tiny AI Models for Raspberry Pi - KDnuggets**
source:: https://www.kdnuggets.com/7-tiny-ai-models-for-raspberry-pi
url:: https://karakeep.diruscio.org/dashboard/preview/wrwx75un37buyqnusi33ygm7
tags:: [[Artificial Intelligence]] [[Local AI]] [[Machine Learning]] [[READ]] [[Raspberry Pi]] [[Tiny AI Models]]
- aggressive quantization
background-color:: green
- llama.cpp
background-color:: green
- > **Note:** What's llama.cpp? #TODO To be checked.
- tool calling, vision understanding, and structured outputs
background-color:: green
- vision‑language model
background-color:: green
- > **Note:** Vision Language Models (VLMs) are powerful AI systems that merge computer vision and natural language processing, allowing them to understand, interpret, and generate content from both images/videos and text inputs, enabling tasks like describing photos (captioning), answering questions about visuals (VQA), generating images from text, and understanding complex documents. #card
- Tiny models have reached a point where size is no longer a limitation to capability. The Qwen 3 series stands out in this list, delivering performance that rivals much larger language models and even challenges some proprietary systems. If you are building applications for a Raspberry Pi or other low-power devices, Qwen 3 is an excellent starting point and well worth integrating into your setup.
background-color:: green
- > **Note:** #IMPORTANT
pages/KaraKeep-Highlights-Summary.md
+41
View File
@@ -0,0 +1,41 @@
## Summary
The article discusses the advancements in AI agent frameworks, specifically LangChain and LangGraph. LangChain is a user-friendly tool for building AI agents, while LangGraph is a lower-level framework for highly custom and controllable agents. The article also highlights the importance of agentic workflows, which allow AI systems to make decisions and adapt based on their environment. Five essential agentic workflow patterns are identified: reflection, tool use, planning, learning, and optimization.
- ## Mermaid Mindmap
- {{renderer :mermaid_694c8c42-5621-4d95-bd16-8261a5eb4f1c, 3}}
- ```mermaid
graph TD
A[LangChain] --> B[User-Friendly AI Agent Framework]
A --> C[Standard Tool Calling Architecture]
A --> D[Provider Agnostic Design]
A --> E[Middleware for Customization]
E --> F[Note: MOSAICO]
E --> G[LangGraph: Lower Level Framework]
G --> H[Useful for Highly Custom and Controllable Agents]
G --> I[Support Production-Grade, Long Running Agents]
B --> J[Background Color: Green]
C --> J
D --> J
E --> J
F --> J
H --> J
A --> K[Top AI Agentic Workflow Patterns]
K --> L[AI Automation]
K --> M[Agentic Workflows]
K --> N[Reflective Systems]
K --> O[Tool Integration]
L --> P[An agentic workflow doesn’t just respond to a single instruction. Instead, it operates with a degree of autonomy, making decisions about how to approach a task, what steps to take, and how to adapt based on what it discovers along the way.]
L --> Q[An agentic system might first search the web for current information on the topic, then organize the findings into themes, draft sections of the report, review each section for accuracy and coherence, revise weak areas, and finally compile everything into a polished document.]
L --> R[Instead of generating output in a single pass, agentic workflows involve cycles where the agent takes an action, observes the result, and uses that observation to inform the next action]
L --> S[Agentic workflows bring this same adaptive, iterative quality to AI systems.]
K --> T[Five Essential Agentic Workflow Patterns]
T --> U[Reflection Pattern: Works best for tasks where quality matters more than speed and where there are subjective aspects that benefit from review.]
T --> V[Tool Use Pattern: Agents are equipped with a set of capabilities they can invoke when needed. These might include web search engines, APIs, code interpreters, database query tools, and file system access.]
K --> W[The Fundamental Challenge: Context windows are constrained not by raw token capacity but by attention mechanics]
W --> X[U-Shaped Attention Curves, and Attention Scarcity]
W --> Y[Effective Context Engineering Means Finding the Smallest Possible Set of High-Signal Tokens that Maximize the Likelihood of Desired Outcomes.]
K --> Z[7 Tiny AI Models for Raspberry Pi - KDnuggets]
Z --> AA[Aggressive Quantization]
Z --> AB[llama.cpp: What's llama.cpp? #TODO To be checked.]
Z --> AC[Tool Calling, Vision Understanding, and Structured Outputs]
Z --> AD[Vision-Language Model: Merges Computer Vision and Natural Language Processing, Allowing Them to Understand, Interpret, and Generate Content from Both Images/Videos and Text Inputs, Enabling Tasks Like Describing Photos (Captioning), Answering Questions About Visuals (VQA), Generating Images from Text, and Understanding Complex Documents.]
```
pages/KaraKeep-Highlights.md
+80
View File
@@ -0,0 +1,80 @@
icon:: ✏️
generation_time:: [[2025-12-27]] T19:00:54Z
- # **TODOs and IDEAs**
- {{query (and [[TODO]] [[KaraKeep-Highlights]] (or [[Ideas]] [[KaraKeep-Highlights]]))}}
query-table:: true
query-properties:: [:block]
- ## **Open - Le regole del gioco**
source:: https://www.open.online/le-regole-del-gioco/
url:: https://karakeep.diruscio.org/dashboard/preview/au4h7zjntjdakspb0gcl51bd
tags:: [[behavioral addiction]] [[digital addiction]] [[gaming disorder]] [[mental health]] [[youth risk]]
- Le cosiddette New Addiction sono capaci di diventare l’obiettivo primario della nostra mente finché l’opzione di smettere non rappresenta più una scelta libera.
background-color:: green
- in Italia tra il 10 e il 15% della popolazione presenti comportamenti che rientrano, in forma più o meno manifesta, nei criteri delle nuove dipendenze
background-color:: green
- Durante il primo lockdown uno studio pubblicato su Frontiers in Psychiatry, condotto dall’Istituto di Neuroscienze di Firenze in collaborazione con il Dipartimento di Psichiatria e Scienze del Comportamento della Albert Einstein College of Medicine di New York, ha rilevato che il 23,6% dei soggetti coinvolti mostrava sintomi compatibili con una forma di gioco d’azzardo patologico.
background-color:: green
- Nello studio condotto su studenti delle scuole superiori pubblicato su CNS Spectrums, i ricercatori hanno registrato il 5,4% degli studenti nella categoria di “internet addicted”; percentuali preoccupanti sono emerse anche per altre dipendenze: il 16% degli studenti ha ottenuto per esempio punteggi talmente alti nella scala dedicata al gioco d’azzardo da essere classificato nella fascia clinica definita come “problema estremo”
background-color:: green
- > **Note:** #card
- ## **LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones**
source:: https://blog.langchain.com/langchain-langgraph-1dot0/
url:: https://karakeep.diruscio.org/dashboard/preview/gfuwsnyaj3k8sglws9kncv27
tags:: [[Agent Frameworks]] [[Artificial Intelligence]] [[Machine Learning Framework]] [[Open Source]] [[P1]] [[Software Development]]
- LangGraph is a lower level framework and runtime, useful for highly custom and controllable agents, designed to support production-grade, long running agents
background-color:: green
- > **Note:** [[MOSAICO]]
- ## **Top AI Agentic Workflow Patterns**
source:: https://blog.bytebytego.com/p/top-ai-agentic-workflow-patterns
url:: https://karakeep.diruscio.org/dashboard/preview/iz529wt1xybxstag5cmcrl1l
tags:: [[AI automation]] [[Agentic Workflows]] [[Artificial Intelligence]] [[Reflective Systems]] [[Tool Integration]]
- An agentic workflow doesn’t just respond to a single instruction. Instead, it operates with a degree of autonomy, making decisions about how to approach a task, what steps to take, and how to adapt based on what it discovers along the way. This represents a fundamental shift in how we think about using AI systems.
background-color:: green
- > **Note:** #IMPORTANT
- An agentic system, however, might first search the web for current information on the topic, then organize the findings into themes, draft sections of the report, review each section for accuracy and coherence, revise weak areas, and finally compile everything into a polished document
background-color:: green
- Instead of generating output in a single pass, agentic workflows involve cycles where the agent takes an action, observes the result, and uses that observation to inform the next action
background-color:: green
- Agentic workflows bring this same adaptive, iterative quality to AI systems.
background-color:: green
- five essential agentic workflow patterns
background-color:: blue
- The reflection pattern works best for tasks where quality matters more than speed and where there are subjective aspects that benefit from review.
background-color:: blue
- > **Note:** Reflection Pattern
- In the tool use pattern, agents are equipped with a set of capabilities they can invoke when needed. These might include web search engines for finding current information, APIs for accessing services like weather data or stock prices, code interpreters for running programs and performing calculations, database query tools for retrieving specific records, file system access for reading and writing documents, and countless other specialized functions. The critical distinction from traditional software is that the agent itself decides when and how to use these tools based on the task at hand.
background-color:: blue
- > **Note:** Tool use pattern
- ## **GitHub - muratcankoylan/Agent-Skills-for-Context-Engineering: A comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.**
source:: https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
url:: https://karakeep.diruscio.org/dashboard/preview/mujjzfwwjb2xbqiugz3i92nv
tags:: [[AI System Optimization]] [[Agent Architectures]] [[Artificial Intelligence]] [[Context Engineering]] [[Multi-Agent Systems]] [[agent skills]]
- The fundamental challenge is that context windows are constrained not by raw token capacity but by attention mechanics
background-color:: green
- "lost-in-the-middle" phenomenon, U-shaped attention curves, and attention scarcity.
background-color:: yellow
- Effective context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of desired outcomes.
background-color:: blue
- > **Note:** #card
- ## **7 Tiny AI Models for Raspberry Pi - KDnuggets**
source:: https://www.kdnuggets.com/7-tiny-ai-models-for-raspberry-pi
url:: https://karakeep.diruscio.org/dashboard/preview/wrwx75un37buyqnusi33ygm7
tags:: [[Artificial Intelligence]] [[Local AI]] [[Machine Learning]] [[READ]] [[Raspberry Pi]] [[Tiny AI Models]]
- aggressive quantization
background-color:: green
- llama.cpp
background-color:: green
- > **Note:** What's llama.cpp? #TODO To be checked.
- tool calling, vision understanding, and structured outputs
background-color:: green
- vision‑language model
background-color:: green
- > **Note:** Vision Language Models (VLMs) are powerful AI systems that merge computer vision and natural language processing, allowing them to understand, interpret, and generate content from both images/videos and text inputs, enabling tasks like describing photos (captioning), answering questions about visuals (VQA), generating images from text, and understanding complex documents. #card
- Tiny models have reached a point where size is no longer a limitation to capability. The Qwen 3 series stands out in this list, delivering performance that rivals much larger language models and even challenges some proprietary systems. If you are building applications for a Raspberry Pi or other low-power devices, Qwen 3 is an excellent starting point and well worth integrating into your setup.
background-color:: green
- > **Note:** #IMPORTANT
pages/LARC-2026-70.md
+22
View File
@@ -0,0 +1,22 @@
type:: [[REVIEWS]]
tags::
year:: 2026
venue:: [[ICSE2026-WS]]
full-title:: AI-Assisted Modeling: DSL-Driven AI Interactions
date-start:: [[07-12-2025]] - 16:08
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@AI-Assisted Modeling: DSL-Driven AI Interactions]]
parent::
todoist:: https://app.todoist.com/app/task/l-arc-2026-new-review-assignments-6fGCJrj25FF2VXw8
- ### [[Comments]]
- SUMMARY: The paper proposes an approach to assist programming activities by integrating domain-specific modeling techniques with real-time graphical visualizations of AI-generated code. The conceived technique has been implemented as a Visual Studio Code extension for the Lingua Franca language that enables iterative model development through structured prompt templates and dialog-driven feedback mechanisms.
- COMMENTS: The paper is about an interesting application of AI technologies and domain-specific modeling. However, I have some major concerns that are related to the presentation of the work. Most notably, the paper's primary goal, whether it targets modeling activities (e.g., defining system behavior) or code development (e.g., generating implementation artifacts), remains unclear. The examples (e.g., adding a "compute" reactor that multiplies input by three) and workflow descriptions suggest a modeling-centric focus, yet phrases like "automatically integrated in the overall system" imply code generation is the end goal. This dual perspective risks confusion for readers. The authors should explicitly state whether the extension prioritizes model refinement before code generation or enables parallel modeling/code development with visual feedback.
- The concept of "visual verification tailored to DSL development" also lacks specificity. The paper mentions model checking but does not clarify the scope of verification, whether it involves syntax validation, semantic consistency checks, or runtime behavior testing. Given the example where the multiplier function is defined in code rather than the model (e.g., "multiplies input by three" vs. "multiplies input by five"), it is essential to specify how the system handles manual interventions. For instance, if a model source is altered post-generation, does the system automatically update the code? The current description implies such updates are manual, yet the workflow claims to support "iterative" refinement without detailing this feedback loop.
- Additionally, the paper underestimates the complexity of DSL-specific tooling. Listing 2 shows the Lingua Franca timer definition, but the efforts required to define language-specific APIs are not properly discussed. The authors note that "generating graphical models via AI is technically demanding" yet fail to address how this challenge scales across diverse DSLs. A more thorough discussion of the trade-offs in API design, particularly for languages with complex semantics, would strengthen the paper's relevance. The example in Figure 4 further highlights this gap: the configuration step (e.g., reactor connections) is omitted, and the Lingua Franca language's settings are not visualized. Clarifying that this is a modeling phase rather than a code generation step would prevent misinterpretation.
- Overall, the approach is innovative but requires sharper articulation of its boundaries and mechanisms. The paper would benefit from a dedicated section addressing how manual interventions (e.g., modifying model sources) trigger automated code updates, as this is central to the claimed "iterative" workflow. With these refinements, the contribution could more effectively advance the field of DSL-driven AI interactions.
- Despite these considerations, which can be addressed through minor revisions, the paper presents interesting insights to be discussed during the workshop.
-
pages/LLM-based Planner.md
+18
View File
@@ -0,0 +1,18 @@
tags:: #TEACHING/SE4AS
- [[OLLAMA]]
- ```
docker exec -it my_se4as_pr_PLANNER /bin/bash
curl -s http://host.docker.internal:11434/api/chat -H "Content-Type: application/json" -d '{
"model": "qwen3:4b",
"messages": [
{"role": "user", "content": "Say hello"}
],
"stream": false
}'
ollama list //to list the available models
```
- docker exec -it n8n_ollama_1 sh
-
pages/LLMs-from-scratch%3A Implement a ChatGPT-like LLM in PyTorch from scratch, step by step.md
+3
View File
@@ -0,0 +1,3 @@
source:: [rasbt/LLMs-from-scratch: Implement a ChatGPT-like LLM in PyTorch from scratch, step by step](https://github.com/rasbt/LLMs-from-scratch?utm_campaign=17499772-%5BLIVE%5D-CAMP-PUBLIC_EXTERNAL-TOBO-LI-AI_Agents_Hub_PUSH-2025_07&utm_content=346646057&utm_medium=social&utm_source=linkedin&hss_channel=lcp-91651675)
-
pages/MDE_Intelligence_2024_paper_5.md
+1 -1
View File
@@ -33,7 +33,7 @@ todoist:: https://app.todoist.com/app/task/5-thomas-buchmann-rene-peinl-and-feli
- - “identification of processes based on documents” ([Buchmann et al., 2018, p. 2](zotero://select/library/items/YA3WBXNL)) ([pdf](zotero://open-pdf/library/items/IA6G7ECR?page=2&annotation=D55I4LBU)) #5fb236
- - “Vidgof et al.” ([Buchmann et al., 2018, p. 2](zotero://select/library/items/YA3WBXNL)) ([pdf](zotero://open-pdf/library/items/IA6G7ECR?page=2&annotation=PE22Y6P8)) #ff6666
- *Missing ref.*
- - ““which tasks can be achieved with already existing models” and that data sets, benchmarks and new LLMs specialized on process management are required.” ([Buchmann et al., 2018, p. 2](zotero://select/library/items/YA3WBXNL)) ([pdf](zotero://open-pdf/library/items/IA6G7ECR?page=2&annotation=WSHW9BDT)) #5fb236
- - ““which tasks can be achieved with already existing models” and that data sets, [[benchmarks]] and new LLMs specialized on process management are required.” ([Buchmann et al., 2018, p. 2](zotero://select/library/items/YA3WBXNL)) ([pdf](zotero://open-pdf/library/items/IA6G7ECR?page=2&annotation=WSHW9BDT)) #5fb236
- - “[4] use” ([Buchmann et al., 2018, p. 2](zotero://select/library/items/YA3WBXNL)) ([pdf](zotero://open-pdf/library/items/IA6G7ECR?page=2&annotation=89P468CV)) #ffd400
- *Avoid using references as subject of sentences. Write instead Forell et. al [4] use...*
- - “mining declarative process models from textual descriptions,” ([Buchmann et al., 2018, p. 2](zotero://select/library/items/YA3WBXNL)) ([pdf](zotero://open-pdf/library/items/IA6G7ECR?page=2&annotation=4UAJ6QDV)) #ff6666
pages/MDE_Intelligence_2025_modeling_ai_driven.md
+23
View File
@@ -0,0 +1,23 @@
collapsed:: true
type:: [[REVIEWS]]
tags::
year:: 2025
venue:: [[MODELS-WS]]
full-title:: Modeling AI-Driven Workflows for Ecosystem Resilience Prediction
date-start:: [[29-07-2025]] - 15:17
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Modeling AI-Driven Workflows for Ecosystem Resilience Prediction]]
parent::
todoist:: https://app.todoist.com/app/task/3-tiago-sousa-nicolas-guelfi-and-benoit-ries-modeling-ai-driven-workflows-for-ec-6cVfQ9fHM7mgvQ2c
- ### [[Highlights]]
- ### [[Comments]]
- **SUMMARY: **The paper presents an approach for supporting the development of Ecosystem Resilience Prediction Systems (ERPS). The approach consists of two main metamodels, i.e., EcoSys and PredSys, to precisely define the ecosystems of interest and design the corresponding AI-based prediction systems. The approach's primary goal is to ensure the consistency and traceability of the prediction workflow involving ecosystem properties, data constraints, and AI capabilities. Different scenarios are given to illustrate the adoption of the presented approach.
- *COMMENTS:* The paper is interesting and about a relevant topic. I have only a few concerns related to the work presentation. In particular,
- The concept of *ecosystem resilience* is central to the work, but it is never explicitly defined initially. It remains unclear whether the paper refers exclusively to natural ecosystems and what specific resilience properties are considered. Similarly, the application context emerges only later, which can confuse readers. Early inclusion of concrete examples, such as the types of ecosystems or the resilience indicators targeted, would improve the work's readability.
- The methodology introduces important concepts, yet some remain abstract. For example, while the authors mention *resilience patterns*, they do not provide concrete examples of what these patterns are or how they are used to drive prediction. It is also unclear where features of interest and prediction goals are specified in the proposed models.
- The description of how data is validated against the requirements defined in EcoSys is insufficient and should be expanded. The same applies to the roles of users: the paper should clarify who is expected to use the approach (ecologists, AI engineers, both?) and how they interact during the process.
- A significant weakness is the limited connection with practical execution environments. The workflow is well described at a conceptual level, but how the presented models are operationalized remains unclear. Are there tools or environments capable of interpreting these specifications? Are there code generation steps involved? Without this information, the approach risks remaining purely theoretical. Similarly, while the scenarios are helpful, they do not bridge the gap between abstract modeling and real-world deployment.
pages/MDE_Intelligence_2025_paper_15.md
+34
View File
@@ -0,0 +1,34 @@
type:: [[REVIEWS]]
tags::
year:: 2025
venue:: [[MODELS-WS]]
full-title:: Generation of Unit Tests for Test-Driven Development using Large Language Models
date-start:: [[30-07-2025]] - 12:22
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@Generation of Unit Tests for Test-Driven Development using Large Language Models]]
parent::
todoist:: https://app.todoist.com/app/task/15-nathanael-yao-juergen-dingel-and-ali-tizghadam-generation-of-unit-tests-for-t-6cVfQ9gQhx4Hq826
collapsed:: true
- ### [[Highlights]]
- ### [[Comments]]
- **SUMMARY** The paper presents an approach based on generative AI, to support Test-Driven Development (TDD) by automatically generating unit tests from high-level user-defined goals. The approach is supported by a prototype developed primarily for the network domain and evaluated through manual checks and feedback from an industrial partner.
- **COMMENTS ** The work addresses an important topic, and the idea of generating tests from user-specified goals rather than implementation code is interesting. However, I have some concerns about the presentation of the work as detailed below:
- The presentation of the proposed approach, especially in Section 5, is not effective. The steps involved in refining high-level goals into subgoals and generating unit tests are described in a confusing manner, with unclear distinctions between what is generic and what is application-specific.
- The human involvement in the process, how feedback is integrated, and how the iterative nature of TDD is supported remain ambiguous. Figures, particularly the algorithm in Figure 1, do not enhance understanding; a more concise representation of the three main steps of the process would be more appropriate.
- The explanation of the pool of basic actions raises some questions: Who defines these actions, whether they are domain-specific, and how they scale to arbitrary user goals, as claimed, is not clarified. Similarly, the syntax or format of the goal models is not specified, making it hard to assess the generality of the approach.
- When describing the use of few-shot examples for unit test generation, the paper fails to clearly explain how these examples are composed to create tests tailored to the target application and what the expected granularity of the generated unit tests is. Additionally, it should be explicitly stated that the current prototype is Python-specific.
Overall, the paper presents an interesting idea but requires improving clarity and explanation of the technical details to convey its contribution.
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
- {{query (and [[ffd400]] [[MDE_Intelligence_2025_paper_15]] )}}
collapsed:: true
- ### ❓️Questions
- {{query (and [[question]] [[MDE_Intelligence_2025_paper_15]] )[[question]]}}
query-table:: true
query-properties:: [:block]
pages/MDE_Intelligence_2025_paper_6.md
+29
View File
@@ -0,0 +1,29 @@
type:: [[REVIEWS]]
tags::
year:: 2025
venue:: [[MODELS-WS]]
full-title::
date-start:: [[30-07-2025]] - 14:58
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: [[@LLM-assisted configuration of model-driven business process families]]
parent::
todoist:: https://app.todoist.com/app/task/6-daniel-calegari-and-andrea-delgado-llm-assisted-configuration-of-model-driven-6cVfQ9jXM6pqQv9c
- LLM-assisted configuration of model-driven business process families
- <!--EndFragment-->
- ### [[Highlights]]
- ### [[Comments]]
- The paper proposes an approach to integrate Large Language Models (LLMs) with a model-driven engineering (MDE) framework for managing business process families. The approach builds on the existing Business Process Family Manager (BPFM) tool and leverages LLMs to generate questionnaires that guide users through the configuration of process variants. The process is supported by metamodels, model-to-model transformations, and a questionnaire mechanism, aiming to improve the configuration of business process variants.
DETAILED COMMENTS: The paper is about an interesting problem. However, several aspects need clarification to make the contribution clearer and more convincing, as discussed below:
- First, the novelty of this work compared to reference [3] must be made explicit early in the paper. Much of the metamodel and underlying concepts are reused, and the added value of integrating LLMs should be better highlighted. Similarly, the BPFM tool appears central to the approach, but its last update dates back four years; this raises concerns about its current applicability and maintenance status, which should be discussed.
- The description of business process families is at the conceptual level and remains abstract. To help readers better grasp the approach, illustrative examples of process variants, variation points, and contexts should be introduced earlier in the paper. The same holds for the questionnaire mechanism: while the paper explains that questionnaires guide the configuration, concrete examples of questions should be given, otherwise it's hard to visualize their practical usage. Examples should also be added when discussing how questions relate to facts and dependencies, and when explaining the three parts of the prompt used for LLM generation.
- Regarding the LLM-assisted part, the zero-shot experiment is verbose and lacks concrete examples, making the results difficult to interpret.
- The evaluation mentions metrics based on semantic equivalence, but how this equivalence was assessed is unclear. Clarifying the methodology here is essential.
- The configurations produced by the approach are a crucial output, yet the paper does not sufficiently explain how these configurations are "consumed" in practice.
- Finally, details on the technological updates and how they improve over the original proposal [9] would make the paper convincing.
Overall, while the paper introduces an interesting integration of LLMs in the configuration of business process families, it requires additional illustrative examples and a more explicit discussion of the approach's novelty and the tool's applicability.
pages/MENTORING___TESISTI.md
+7
View File
@@ -1,6 +1,7 @@
-
- # Students
- [[people/azimov]]
collapsed:: true
- titolo-tesi::
tipo-tesi:: [[magistrale]]
email:: sherkhan.azimov@student.univaq.it
@@ -34,6 +35,12 @@
struttura:: [[company/Tirasa]]
deadline-titolo:: [[18-01-2023]]
deadline-tesi:: [[11-03-2023]]
collapsed:: true
- [[people/MarcoGiarrusso]]
- type:: [[masterStudent]]
titolo-tesi::
page-type:: [[people]]
-
- ## General information
- The next dates to discuss your thesis are as follows ([Dipartimento di Ingegneria e Scienze dell'Informazione e Matematica (univaq.it)](https://www.disim.univaq.it/page.php?page_id=197)):
- ![image.png](blob:https://mail.google.com/b351ad1b-03bf-4cf4-a1bb-f846019ce506)
pages/MODELS Journal-First-track + 1 more.md
+14 -2
View File
@@ -7,12 +7,24 @@ goal:: ((6832257a-2676-4bf1-8958-81797e5c7003))
CLOCK: [2025-06-03 Tue 16:05:13]--[2025-06-03 Tue 16:05:13] => 00:00:00
:END:
- DONE Mandare mail a Maurane circa il processo
id:: 683f0108-c7ac-41ae-a6bd-b9c02829e6fc
id:: 683f0108-c7ac-41ae-a6bd-b9c02829e6fc
:LOGBOOK:
CLOCK: [2025-06-03 Tue 16:05:10]--[2025-06-03 Tue 16:05:11] => 00:00:01
:END:
- TODO Inviare email a tutti i paper che dovranno rispondere entro il 20 Giugno (se intendono partecipare o meno)
- DONE Inviare email a tutti i paper che dovranno rispondere entro il 20 Giugno (se intendono partecipare o meno)
id:: 68584ea7-8fde-4a5e-9367-f7054ced2f88
-
- Email template
- Dear Authors,
- Thank you for your interest in the *Journal First* track at MODELS 2025.
- We are pleased to inform you that your SoSyM paper has been **accepted** for inclusion in the *Journal First* track of MODELS 2025.
- Please note that *Journal First* manuscripts are published in the journal and will not appear in the MODELS 2025 proceedings, but they will be listed in the official conference program.
- As you may know, MODELS 2025 will be held in a hybrid format, allowing authors to participate either in person or online.
- To ensure your paper is included in the MODELS 2025 program, at least one author must register for the **main conference** by **September 1st** at the applicable rate:
- [https://2025.models-conf.com/attending/registration](https://2025.models-conf.com/attending/registration)
- We look forward to your presentation at MODELS 2025!
- Best regards,
- Davide
- [[26-05-2025]] ho contattato Martin per chiedere la lista di paper accettati tra Maggio 2024 e oggi
- Dear Davide,
- please excuse my late reply. I was on vacation last week without
pages/Meeting ATOS.md
+1 -1
View File
@@ -1,7 +1,7 @@
type:: [[meeting]]
external-links::
tags:: [[SERVICES/PLACEMENT-ATENEO]]
people:: #people/santucci #company/ATOS
people:: #people/FortunatoSantucci #company/ATOS
tags::
date:: [[07-09-2022]]
pages/Meetings/2020-12-23-Meeting con azienda Eustema - 202012231241.md
+14 -14
View File
@@ -2,25 +2,25 @@
---
# ** Meeting con azienda Eustema **
Date:2020-12-23
Time: 12:41
Attendend: #attendance/online
Project:
People attended: #people/alfonso
---
![[Pasted image 20201223122559.png]]
## Domande fatte
- # ** Meeting con azienda Eustema **
Date:2020-12-23
Time: 12:41
Attendend: #attendance/online
Project:
People attended: #people/AlfonsoPierantonio
---
![[Pasted image 20201223122559.png]]
- ## Domande fatte
- Qual e' l'uso envisioned per voi?
- Chi e' l'utente finale?
- L'utente business
- Progettista di processo
- Figura intermedia che sa modellare un processo
- Sono interessati all'uso di sistemi di raccomandazione
## La proposta fatta è:
- ## La proposta fatta è:
- [ ] Lavorare su un dottorando PON
- [ ] Proposta di progetto MISE in cui l'obiettivo principale e' quello di sviluppare una nuova piattaforma Lowcode interna per supportare lo sviluppo di sistemi mediante gli asset interni (includendo sistemi di raccomandazione)
pages/Meetings/Mentoring/2021-01-15-Call with Philip Langer Damiano Alfonso and Juri.md
+18 -18
View File
@@ -2,24 +2,24 @@
---
# **Call with Philip Langer Damiano Alfonso and Juri**
Date: 2021-01-15
Time: 16:28
Attendend: #attendance/online
Project: #mdegroup
People attended: #people/alfonso #people/juri #people/damiano #externalpeople/phliplanger
---
## Damiano presented some capabilities of the tool he is developing
**Some notes below**
** [Sprotty](https://github.com/eclipse/sprotty) is just to link metaclasses with SVG **
So this means that if you want restrict the behaviour of the editor, you need to develop this. Sprotty does not have first class elements for doing this.
** Co-evolution capabilities of the tool**
Currently basic cases are supported to automatically evolve models according to operated metamodel changes.
** Styling elements and add constraints to graphical elements **
- # **Call with Philip Langer Damiano Alfonso and Juri**
Date: 2021-01-15
Time: 16:28
Attendend: #attendance/online
Project: #mdegroup
People attended: #people/AlfonsoPierantonio #people/juri #people/damiano #externalpeople/phliplanger
---
- ## Damiano presented some capabilities of the tool he is developing
**Some notes below**
** [Sprotty](https://github.com/eclipse/sprotty) is just to link metaclasses with SVG **
So this means that if you want restrict the behaviour of the editor, you need to develop this. Sprotty does not have first class elements for doing this.
** Co-evolution capabilities of the tool**
Currently basic cases are supported to automatically evolve models according to operated metamodel changes.
** Styling elements and add constraints to graphical elements **
- There is a bidirectional relationship between the graphical position of the element and model attributes.
- It is possible to define rules involving different graphical elements.
![[Pasted image 20210115164633.png]]
pages/Meetings/Mentoring/2021-01-22-1046-Meeting-Apurv-Alfonso.md
+1 -1
View File
@@ -1,7 +1,7 @@
type:: #meeting
date:: [[22-01-2021]]
time:: 10:46
people:: #people/alfonso #people/apurv
people:: #people/AlfonsoPierantonio #people/apurv
- Presentation of the SOSYM paper about about BPMN vs Low-code
- Problem with section 5.4 concerning the usability
pages/Meetings/PhDICT/2021-01-18-0936-GiuliaDeMasi.md
+1 -1
View File
@@ -8,7 +8,7 @@ type:: [[meeting]]
**Time**: 09:37
**Attendend**: #attendance/online
**Project**:
**People attended**: #people/Vittorio_Cortellessa #people/henry #externalpeople/giuliademasi
**People attended**: #people/Vittorio_Cortellessa #people/HenryMuccini #externalpeople/giuliademasi
_Celano: 🌫 -3°C_
---
pages/Missione FSE 2025.md
-5
View File
@@ -11,11 +11,9 @@ external-link:: [Program - FSE 2025](https://conf.researchr.org/program/fse-2025
- ### Notes
id:: 68584ea8-f9f8-49c5-a552-12194c301df5
- #### Slides preparation
collapsed:: true
- "Teamwork makes the dream work: LLMs-Based Agents for GitHub README.MD Summarization", has been accepted for presentation in the Ideas, Visions, and Reflections track at FSE 2025
- Instructions to upload / send the slides ✉: [Web Link](https://outlook.office365.com/owa/?ItemID=AAMkADM1NGNiNjk0LTY0ZGUtNDgzOC04MDM5LWNhODNkYWNjNjU4YwBGAAAAAACT6qp78kRgRKuUMBdWEga%2FBwCOhWlC8F7PRKzlljZYZYQmAAAAAAEMAACOhWlC8F7PRKzlljZYZYQmAAgNERPBAAA%3D&exvsurl=1&viewmodel=ReadMessageItem)
- #### Day 1
collapsed:: true
- **FSE Keynote: Mark Harman, Peter O’Hearn, and Shubho Sengupta****[Harden and Catch for Just-in-Time Assured LLM-Based Software Testing: An Industrial Perspective and Open Research Challenge](https://conf.researchr.org/program/fse-2025/program-fse-2025/?date=Mon%2023%20Jun%202025%2BTue%2024%20Jun%202025%2BWed%2025%20Jun%202025%2BThu%2026%20Jun%202025%2BFri%2027%20Jun%202025&past=Show%20upcoming%20events%20only#)**
collapsed:: true
- Abstract:
@@ -41,7 +39,6 @@ external-link:: [Program - FSE 2025](https://conf.researchr.org/program/fse-2025
- Grounds for optimism today! (oracle problem)
-
- #### Day 2
collapsed:: true
- **[Risk Assessment Framework for Code LLMs via Leveraging Internal States](https://conf.researchr.org/program/fse-2025/program-fse-2025/?date=Mon%2023%20Jun%202025%2BTue%2024%20Jun%202025%2BWed%2025%20Jun%202025%2BThu%2026%20Jun%202025%2BFri%2027%20Jun%202025&past=Show%20upcoming%20events%20only#)**
collapsed:: true
- Industry Papers
@@ -58,13 +55,11 @@ external-link:: [Program - FSE 2025](https://conf.researchr.org/program/fse-2025
- ![IMG_20250624_110536063.jpg](../assets/IMG_20250624_110536063_1750756075215_0.jpg)
-
- **[Hallucination Detection in Large Language Models with Metamorphic Relations](https://conf.researchr.org/program/fse-2025/program-fse-2025/?date=Mon%2023%20Jun%202025%2BTue%2024%20Jun%202025%2BWed%2025%20Jun%202025%2BThu%2026%20Jun%202025%2BFri%2027%20Jun%202025&past=Show%20upcoming%20events%20only#)**
collapsed:: true
- Research Papers
- [Borui Yang](https://conf.researchr.org/profile/fse-2025/boruiyang) Beijing University of Posts ad Telecommunications, [Md Afif Al Mamun](https://conf.researchr.org/profile/fse-2025/mdafifalmamun) University of Calgary, [Jie M. Zhang](https://conf.researchr.org/profile/fse-2025/jiemzhang) King's College London, [Gias Uddin](https://conf.researchr.org/profile/fse-2025/giasuddin2) York University, Canada
- [DOI](https://doi.org/10.1145/3715735)
-
- **[Migrating Code At Scale With LLMs At Google](https://conf.researchr.org/program/fse-2025/program-fse-2025/?date=Mon%2023%20Jun%202025%2BTue%2024%20Jun%202025%2BWed%2025%20Jun%202025%2BThu%2026%20Jun%202025%2BFri%2027%20Jun%202025&past=Show%20upcoming%20events%20only#)**
collapsed:: true
- Industry Papers
- [Celal Ziftci](https://conf.researchr.org/profile/fse-2025/celalziftci1) Google, [Stoyan Nikolov](https://conf.researchr.org/profile/fse-2025/stoyannikolov) Google, Inc., [Anna Sjovall](https://conf.researchr.org/profile/fse-2025/annasjovall) Google, Inc., [Bo Kim](https://conf.researchr.org/profile/fse-2025/bokim) Google, [Daniele Codecasa](https://conf.researchr.org/profile/fse-2025/danielecodecasa) Google, Inc., [Max Kim](https://conf.researchr.org/profile/fse-2025/maxkim) Google
- TODO Da vedere questo paper [[@Migrating Code At Scale With LLMs At Google]]
pages/Missione ROMA Mosaico.md
+36 -9
View File
@@ -3,7 +3,6 @@ date:: [[01-07-2025]] - 09:25
progress:: {{renderer :todomaster}}
- ### Tasks
collapsed:: true
- {{query (and [[TODO]] [[Missione ROMA Mosaico]] )}}
query-sort-by:: block
query-table:: true
@@ -12,10 +11,11 @@ progress:: {{renderer :todomaster}}
- ### Notes
- Agenda: ![MOSAICO Consortium meeting Rome_proposed agenda_202506165408279409830273888.pdf](../assets/MOSAICO_Consortium_meeting_Rome_proposed_agenda_202506165408279409830273888_1751381413979_0.pdf)
- Participants: ![MOSAICO 2nd Consortium meeting_Rome_list of participants_202506238683233499270025632.pdf](../assets/MOSAICO_2nd_Consortium_meeting_Rome_list_of_participants_202506238683233499270025632_1751381740630_0.pdf)
-
- ![MOSAICO CM2 GA and EB Meeting Minutes.pdf](../assets/MOSAICO_CM2_GA_and_EB_Meeting_Minutes_1752829106144_0.pdf)
- **First day of meeting [[01-07-2025]]**
query-table:: true
query-properties:: [:block]
collapsed:: true
- ### Overview
collapsed:: true
- ![image.png](../assets/image_1751354765576_0.png)
@@ -43,17 +43,30 @@ progress:: {{renderer :todomaster}}
- Opentelemetry is a communication protocol and LangFuse supports this protocol.
- ![image.png](../assets/image_1751360448322_0.png)
- ![image.png](../assets/image_1751360766405_0.png)
- TODO [[p1]] Da guardare A2A agent card per la tassonomia relativa al repository
- DONE [[p1]] Da guardare A2A agent card per la tassonomia relativa al repository
id:: 6863a4ff-c366-4708-8009-34f6b34fedbb
:LOGBOOK:
CLOCK: [2025-08-19 Tue 18:04:55]--[2025-08-19 Tue 18:04:55] => 00:00:00
:END:
- ![image.png](../assets/image_1751361032317_0.png)
- ![image.png](../assets/image_1751361131943_0.png)
- ![image.png](../assets/image_1751361170015_0.png)
- TODO [[p2]] The agent discovery mechanism is very much related to that of MOSAICO. Have a look at them especially to see what is the taxonomy underpinning them
- DONE [[p2]] The agent discovery mechanism is very much related to that of MOSAICO. Have a look at them especially to see what is the taxonomy underpinning them
id:: 6863a692-e9b0-4b8f-ba41-a9d4a1043651
:LOGBOOK:
CLOCK: [2025-08-19 Tue 18:05:59]--[2025-08-19 Tue 18:06:00] => 00:00:01
:END:
- ![image.png](../assets/image_1751361461752_0.png)
- ![image.png](../assets/image_1751361630543_0.png)
- ![image.png](../assets/image_1751361681318_0.png)
- TODO This is an idea related to the WP2 taxonomy
- DONE This is an idea related to the WP2 taxonomy
id:: 6863a8b5-35d5-492e-a8cf-2549750d9965
:LOGBOOK:
CLOCK: [2025-08-19 Tue 18:08:44]--[2025-08-19 Tue 18:08:47] => 00:00:03
:END:
- ![image.png](../assets/image_1751361765405_0.png)
- ### WP2 Presentation
collapsed:: true
- ![image.png](../assets/image_1751363781466_0.png)
- TODO Developer Interface is not the right naming. THis needs to be changed
- ![image.png](../assets/image_1751364615575_0.png)
@@ -65,11 +78,14 @@ progress:: {{renderer :todomaster}}
- TODO Do they support agents in different technologies?
- TODO What about parallel executions?
- TODO Improve the relation vs existing model repositories
- TODO [[p1]] Have a look at the different repositories shared by Antonio
- DONE [[p1]] Have a look at the different repositories shared by Antonio [[Resources]]
id:: 6863b98d-74e6-435a-8631-c03155c89300
- https://beeai.dev/agents
- https://www.agentlocker.ai/
- https://aiagentslist.com/
- [Taxonomy of AI Agent Skills - Agntcy](https://docs.agntcy.org/oasf/taxonomy/)
-
-
- TODO Look at Traces and Metrics (OpenTelemetry with Spring)
- Our application should be ready to gather telemetry
- It is related to LangFuse
@@ -127,6 +143,7 @@ progress:: {{renderer :todomaster}}
- ![image.png](../assets/image_1751382272258_0.png)
- ![image.png](../assets/image_1751382349242_0.png)
- **Second day of the meeting [[02-07-2025]]**
collapsed:: true
- ### WP10 Presentation
collapsed:: true
- [Florence Bonnet | CEPR](https://cepr.org/about/people/florence-bonnet)
@@ -179,7 +196,8 @@ progress:: {{renderer :todomaster}}
- We removed X from our socialmedia. We should decide what to do. It makes sense to increase the Linkedin KPI
- So far no visits to schools or alike
- ![image.png](../assets/image_1751448051487_0.png){:height 582, :width 980}
- TODO [[p1]] Aggiungere presentazione MOSAICO a FSE
- DONE [[p1]] Aggiungere presentazione MOSAICO a FSE
id:: 6864fa38-39bb-42b6-94f5-ba9bccfc4f04
- ![image.png](../assets/image_1751448218239_0.png)
- ![image.png](../assets/image_1751448299956_0.png)
- Concerning T6.1 and T6.3 (from Eclipse)
@@ -206,9 +224,11 @@ progress:: {{renderer :todomaster}}
- ![image.png](../assets/image_1751449876406_0.png)
- ![image.png](../assets/image_1751450233550_0.png)
- ![image.png](../assets/image_1751450295902_0.png)
- TODO We have now a latex template for deliverables. It's in our Sharepoint. DOwnload it!
- DONE We have now a latex template for deliverables. It's in our Sharepoint. DOwnload it!
id:: 686503c5-75e8-45ab-9237-aa9eb32c63cc
-
- ### WP5 Presentation
collapsed:: true
- ![image.png](../assets/image_1751450650894_0.png)
- ![image.png](../assets/image_1751450694260_0.png)
- ![image.png](../assets/image_1751450748883_0.png)
@@ -220,15 +240,22 @@ progress:: {{renderer :todomaster}}
- ![image.png](../assets/image_1751453516554_0.png)
-
- ### WP8 and WP9
collapsed:: true
- Talked about deliverable 8.2
- ![image.png](../assets/image_1751461226292_0.png)
- ![image.png](../assets/image_1751461269563_0.png)
- ### Discussion
- TODO [[p2]] Look at [MOSAICO Architecture - Google Drawings](https://docs.google.com/drawings/d/1zyO2GLFj8PtQD9j6MZ1AksQwwLM_XmZX8AOPGNs8m_Y/edit)
collapsed:: true
- DONE [[p2]] Look at [MOSAICO Architecture - Google Drawings](https://docs.google.com/drawings/d/1zyO2GLFj8PtQD9j6MZ1AksQwwLM_XmZX8AOPGNs8m_Y/edit) [[Resources]]
id:: 68653364-55e9-4d49-85e1-0c8a9f186e8e
:LOGBOOK:
CLOCK: [2025-08-19 Tue 18:03:00]--[2025-08-19 Tue 18:03:01] => 00:00:01
:END:
- **Third day of the meeting [[03-07-2025]]**
- Agenda: [MOSAICO 2nd Co-Creation meeting Rome_proposed agenda_20250619.docx](https://imtatlantiquefr.sharepoint.com/:w:/r/sites/MOSAICO/_layouts/15/Doc.aspx?sourcedoc=%7BBC69EB4B-582A-4E6B-A86A-13D04EF8FA93%7D&file=MOSAICO%202nd%20Co-Creation%20meeting%20Rome_proposed%20agenda_20250619.docx&action=default&mobileredirect=true)
- Link: https://gov.teams.microsoft.us/l/meetup-join/19%3agcch%3ameeting_cb5648e689bb4db19ab298cdfad07f3f%40thread.v2/0?context=%7b%22Tid%22%3a%227a18110d-ef9b-4274-acef-e62ab0fe28ed%22%2c%22Oid%22%3a%2272d155af-f561-43e3-88f0-0ae9416888e8%22%7d
- ### Critical and important aspects
collapsed:: true
- {{query (and (or [[critical]] [[IMPORTANT]]) [[Missione ROMA Mosaico]])}}
query-table:: true
query-properties:: [:block]
pages/Missione STAF 2025.md
+1 -1
View File
@@ -61,7 +61,7 @@ progress:: {{renderer :todomaster}}
- ![Immagine WhatsApp 2025-06-11 ore 10.16.58_b8d84c22.jpg](../assets/Immagine_WhatsApp_2025-06-11_ore_10.16.58_b8d84c22_1749629984208_0.jpg)
-
- ![Immagine WhatsApp 2025-06-11 ore 10.16.58_28008e59.jpg](../assets/Immagine_WhatsApp_2025-06-11_ore_10.16.58_28008e59_1749629958665_0.jpg)
- This is related to [[Model Context Protocol (MCP)]] #LLMs #PROJECTS/MOSAICO #reading
- This is related to [[Model Context Protocol (MCP)]] #LLMs #PROJECTS/MOSAICO #Reading
- ![Immagine WhatsApp 2025-06-11 ore 10.16.57_98d091d4.jpg](../assets/Immagine_WhatsApp_2025-06-11_ore_10.16.57_98d091d4_1749629948940_0.jpg)
- ![Immagine WhatsApp 2025-06-11 ore 10.16.57_65ad896b.jpg](../assets/Immagine_WhatsApp_2025-06-11_ore_10.16.57_65ad896b_1749629938063_0.jpg)
- ![Immagine WhatsApp 2025-06-11 ore 10.16.57_f5db2351.jpg](../assets/Immagine_WhatsApp_2025-06-11_ore_10.16.57_f5db2351_1749629927969_0.jpg)
pages/Model Context Protocol (MCP).md
+1 -1
View File
@@ -1,4 +1,4 @@
tags:: #LLMs #PROJECTS/MOSAICO #reading
tags:: #LLMs #PROJECTS/MOSAICO #Reading
- MCP has quickly become a cornerstone in enabling AI models—particularly large language models (LLMs) and autonomous agents—to interact with external tools, APIs, and data sources through a standardized interface. Much like USB-C revolutionized device connectivity, MCP aims to standardize how models access and apply contextual information.
- While MCP initially focused on simplifying integrations, its broader impact is now coming into view. We're beginning to see MCP evolve into a foundational layer for distributed AI systems. These systems involve not just a single model with a static toolbox, but networks of interoperating agents, dynamically discovering, invoking, and coordinating with external resources.
pages/Omnivore.md
+1
View File
@@ -5,6 +5,7 @@ icon:: ⤴️
query-sort-by:: block
query-table:: true
query-sort-desc:: false
collapsed:: true
#+BEGIN_QUERY
{:title "STARRED ITEMS"
:query
pages/Omnivore___01-05-2024___Dottorati di ricerca — Italiano.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: pubblicato il 30/04/2024 — ultima modifica 30/04/2024
labels:: [[SERVICES/PHDICT]]
date-saved:: [[01-05-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___02-04-2024___Edge 383- The Key Capabilities of Autonomous Agens.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: davide.diruscio@gmail.com
labels:: [[Newsletter]]
date-saved:: [[02-04-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___02-05-2024___Edge 392- Meet RAFT- UC Berkeley's New Method to Improve RAG Patterns in LLMs.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: davide.diruscio@gmail.com
labels:: [[Newsletter]] [[RAG]]
date-saved:: [[02-05-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___02-05-2024___MAIA.md
+1 -1
View File
@@ -3,4 +3,4 @@ site:: [multimodal-interpretability.csail.mit.edu](https://multimodal-interpreta
author:: Tamar Rott Shaham*,
date-saved:: [[02-05-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___02-05-2024___Phi-3 Technical Report- A Highly Capable Language Model Locally on Your Phone.md
+1 -1
View File
@@ -3,4 +3,4 @@ site:: [arxiv.org](https://arxiv.org/html/2404.14219v1)
author:: Microsoft
date-saved:: [[02-05-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___02-05-2024___[2403.10131] RAFT- Adapting Language Model to Domain Specific RAG.md
+1 -1
View File
@@ -3,4 +3,4 @@ site:: [arXiv.org](https://arxiv.org/abs/2403.10131)
author:: [Submitted on 15 Mar 2024]
date-saved:: [[02-05-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___03-01-2024___ChatGPT in software modeling - Software and Systems Modeling.md
+1 -1
View File
@@ -5,4 +5,4 @@ labels:: [[MDE]] [[ResearchPaper]] [[AI]]
date-saved:: [[03-01-2024]]
date-published:: [[01-06-2023]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___03-01-2024___Leveraging Artificial Intelligence for Model-based Software Analysis and Desi...___.md
+1 -1
View File
@@ -5,4 +5,4 @@ labels:: [[MDE]] [[ResearchPaper]] [[AI]]
date-saved:: [[03-01-2024]]
date-published:: [[01-01-2023]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___04-04-2024___The Todoist Bulletin.md
+1 -1
View File
@@ -2,4 +2,4 @@ full-title:: [The Todoist Bulletin](https://omnivore.app/me/the-todoist-bulletin
site:: [todoist.news](https://todoist.news/2024%5F04)
date-saved:: [[04-04-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___04-06-2024___Edge 401- Reflection and Refinement Planning Methods in Autonomous Agents.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: davide.diruscio@gmail.com
labels:: [[Newsletter]]
date-saved:: [[04-06-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___05-04-2024___RAG, portare l'intelligenza artificiale in azienda e migliorare il business c...___.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: Michele Nasi Pubblicato il 4 apr 2024
labels:: [[RAG]]
date-saved:: [[05-04-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___06-02-2024___Cahiers de doléances - Wikipedia.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: Contributori ai progetti Wikimedia
date-saved:: [[06-02-2024]]
date-published:: [[08-03-2006]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___06-05-2024___Editorial- ICSE and the Incredible Contradictions of Software Engineering - A...___.md
+1 -1
View File
@@ -5,7 +5,7 @@ labels:: [[MauroPezze]] [[P1]]
date-saved:: [[06-05-2024]]
date-published:: [[18-04-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
- ### Highlights
collapsed:: true
pages/Omnivore___08-09-2023___Ddl affitti brevi — idealista-news.md
+3 -2
View File
@@ -5,9 +5,10 @@ labels:: [[affitti]]
date-saved:: [[08-09-2023]]
date-published:: [[07-09-2023]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
- * ### Highlights
- collapsed:: true
* ### Highlights
collapsed:: true
- > **affitti brevi con il nuovo ddl diffuso dal Ministero del Turismo** si abbatterà soprattutto sul piccolo proprietario [⤴️](https://omnivore.app/me/ddl-affitti-brevi-idealista-news-18a74e0b011#7c279898-00b6-4bf2-af16-75a400c87506)
- > si conferma l’obbligo di essere registrati ad un apposito registro nazionale e di essere soggetti a controlli da parte dei Comuni. [⤴️](https://omnivore.app/me/ddl-affitti-brevi-idealista-news-18a74e0b011#6acee3d7-09da-4c2c-9f76-46767c1a4d3f)
pages/Omnivore___10-02-2024___Nutrizionista Roma - Nutrizionista Daniele Sciotti.md
+1 -1
View File
@@ -2,4 +2,4 @@ full-title:: [Nutrizionista Roma | Nutrizionista Daniele Sciotti](https://omnivo
site:: [Daniele Sciotti](https://www.nutrizionistadanielesciotti.it)
date-saved:: [[10-02-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___10-06-2024___ModelXGlue- a benchmarking framework for ML tools in MDE - Software and Syste...___.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: Di Ruscio, Davide
date-saved:: [[10-06-2024]]
date-published:: [[10-06-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___11-01-2024___Meet Ghostbuster- An AI Technique for Detecting LLM-Generated Content.md
+7 -9
View File
@@ -1,12 +1,10 @@
-
full-title:: [Meet Ghostbuster: An AI Technique for Detecting LLM-Generated Content](https://omnivore.app/me/meet-ghostbuster-an-ai-technique-for-detecting-llm-generated-con-18cf870b527)
site:: [thesequence.substack.com](https://thesequence.substack.com/p/meet-ghostbuster-an-ai-technique?isFreemail=true&post_id=140578123&publication_id=54309&r=z2w67&token=eyJ1c2VyX2lkIjo1ODkyMTU2NywicG9zdF9pZCI6MTQwNTc4MTIzLCJpYXQiOjE3MDQ5NzUwOTcsImV4cCI6MTcwNzU2NzA5NywiaXNzIjoicHViLTU0MzA5Iiwic3ViIjoicG9zdC1yZWFjdGlvbiJ9.xmHZDax66HJi0V8onrVLKtwnQAUQuOQUyVyDiFn0Vrs)
author:: davide.diruscio@gmail.com
labels:: [[Newsletter]] [[LLMs]] [[P1]]
date-saved:: [[11-01-2024]]
source:: [[Omnivore]]
state:: [[reading]]
- full-title:: [Meet Ghostbuster: An AI Technique for Detecting LLM-Generated Content](https://omnivore.app/me/meet-ghostbuster-an-ai-technique-for-detecting-llm-generated-con-18cf870b527)
site:: [thesequence.substack.com](https://thesequence.substack.com/p/meet-ghostbuster-an-ai-technique?isFreemail=true&post_id=140578123&publication_id=54309&r=z2w67&token=eyJ1c2VyX2lkIjo1ODkyMTU2NywicG9zdF9pZCI6MTQwNTc4MTIzLCJpYXQiOjE3MDQ5NzUwOTcsImV4cCI6MTcwNzU2NzA5NywiaXNzIjoicHViLTU0MzA5Iiwic3ViIjoicG9zdC1yZWFjdGlvbiJ9.xmHZDax66HJi0V8onrVLKtwnQAUQuOQUyVyDiFn0Vrs)
author:: davide.diruscio@gmail.com
labels:: [[Newsletter]] [[LLMs]] [[P1]]
date-saved:: [[11-01-2024]]
source:: [[Omnivore]]
state:: [[Reading]]
- ### Highlights
- > The rapid evolution of large language models(LLMs) has created new challenges in terms of differentiating between human and AI-generated content. [⤴️](https://omnivore.app/me/meet-ghostbuster-an-ai-technique-for-detecting-llm-generated-con-18cf870b527#1db2b88d-fc61-48dd-bb45-35592804ad8f)
pages/Omnivore___11-01-2024___OpenAI lancia lo store di ChatGPT - Il Sole 24 ORE.md
+10 -12
View File
@@ -1,15 +1,13 @@
-
full-title:: [OpenAI lancia lo store di ChatGPT - Il Sole 24 ORE](https://omnivore.app/me/https-www-ilsole-24-ore-com-art-openai-lancia-store-chatgpt-a-fj-18cf7f7b953)
site:: [Il Sole 24 ORE](https://www.ilsole24ore.com/art/openai-lancia-store-chatgpt-AFjzgwIC)
author:: Il Sole 24 Ore
labels:: [[PROJECTS/SE-H2020-March-Call]] [[LLMs]]
date-saved:: [[11-01-2024]]
date-published:: [[10-01-2024]]
date-archived:: [[11-01-2024]]
is-archived:: 10
source:: [[Omnivore]]
state:: [[archived]]
- full-title:: [OpenAI lancia lo store di ChatGPT - Il Sole 24 ORE](https://omnivore.app/me/https-www-ilsole-24-ore-com-art-openai-lancia-store-chatgpt-a-fj-18cf7f7b953)
site:: [Il Sole 24 ORE](https://www.ilsole24ore.com/art/openai-lancia-store-chatgpt-AFjzgwIC)
author:: Il Sole 24 Ore
labels:: [[PROJECTS/MOSAICO]] [[LLMs]]
date-saved:: [[11-01-2024]]
date-published:: [[10-01-2024]]
date-archived:: [[11-01-2024]]
is-archived:: 10
source:: [[Omnivore]]
state:: [[archived]]
- ### Highlights
- > OpenAI ha finalmente lanciato lo store dove gli utenti possono condividere (e vendere/acquistare) versioni personalizzate del popolare chatbot ChatGPT. [⤴️](https://omnivore.app/me/https-www-ilsole-24-ore-com-art-openai-lancia-store-chatgpt-a-fj-18cf7f7b953#e9bb6bd8-9360-4a1e-b9d5-87b80e7d46ba)
- > GPT Store permetterà agli utenti di vedere i chatbot più popolari e di tendenza in una classifica e di cercarli per categoria. [⤴️](https://omnivore.app/me/https-www-ilsole-24-ore-com-art-openai-lancia-store-chatgpt-a-fj-18cf7f7b953#7d79c5a2-5074-4379-b376-d285e3a648b3)
pages/Omnivore___12-08-2023___The Secret Power of ‘Read It Later’ Apps.md
+3 -2
View File
@@ -9,7 +9,8 @@ is-archived:: 10
source:: [[Omnivore]]
state:: [[archived]]
- * ### Highlights
- collapsed:: true
* ### Highlights
collapsed:: true
- > Pocket over the course of the year. [⤴️](https://omnivore.app/me/the-secret-power-of-read-it-later-apps-189eb9ce888#80cf319f-6a4e-4f98-acbe-91aa5b56f5a9)
omnivore-note:: This is a test note.
@@ -35,4 +36,4 @@ state:: [[archived]]
- > Ideas are high leverage agents. They become more so when arranged in highly cross-referenced networks. [⤴️](https://omnivore.app/me/the-secret-power-of-read-it-later-apps-189eb9ce888#c4cb4fb5-b404-4537-9399-0a0d4822f149)
omnivore-note:: [[ideas]]
- > Reading is the closest thing we have to thinking another’s thoughts. It’s long and sometimes ponderous, but that work is required to wrap yourself in another person’s paradigm. Which is the first step in madly letting go of your own. [⤴️](https://omnivore.app/me/the-secret-power-of-read-it-later-apps-189eb9ce888#5879ed6c-6777-412b-ad61-9eb015fdb108)
omnivore-note:: #reading
omnivore-note:: #Reading
pages/Omnivore___12-09-2023___Obsidian- Stop Wasting Time With Directories and Filenames - by Brian Carey -...___.md
+3 -2
View File
@@ -4,9 +4,10 @@ author:: Brian Carey
date-saved:: [[12-09-2023]]
date-published:: [[29-08-2023]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
- * ### Highlights
- collapsed:: true
* ### Highlights
collapsed:: true
- > we use Obsidian for information management, not file management. [⤴️](https://omnivore.app/me/obsidian-stop-wasting-time-with-directories-and-filenames-by-bri-18a87f2d720#863d2bbb-2a01-42a6-b465-aeab9fc0e4d2)
- > The Bookmarks panel provides an information tree, the Navigator panel provides a file tree. I want the information tree. [⤴️](https://omnivore.app/me/obsidian-stop-wasting-time-with-directories-and-filenames-by-bri-18a87f2d720#f820512c-1994-4ec6-b090-a90c66c25c47)
pages/Omnivore___12-09-2024___Edge 430- Learn About The AI Scientist, The Model that can Conduct Long Term ...___.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: davide.diruscio@gmail.com
labels:: [[Newsletter]]
date-saved:: [[12-09-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___13-01-2024___David Lo - nuovi articoli.md
+1 -1
View File
@@ -3,4 +3,4 @@ site:: [omnivore.app](https://omnivore.app/no_url?q=eef4537b-6dda-4960-a544-943f
labels:: [[Newsletter]]
date-saved:: [[13-01-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___13-08-2023___Rivoluzione dell'Ingegneria del Software- L'Impatto dell'Intelligenza Artific...___.md
+3 -2
View File
@@ -5,9 +5,10 @@ labels:: [[AI]] [[SoftwareEngineering]]
date-saved:: [[13-08-2023]]
date-published:: [[12-08-2023]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
- * ### Highlights
- collapsed:: true
* ### Highlights
collapsed:: true
- > L’integrazione dell’IA nell’ingegneria del software è una svolta epocale, principalmente perché automatizza molti aspetti del processo di sviluppo del software. [⤴️](https://omnivore.app/me/https-ts-2-space-it-rivoluzione-dellingegneria-del-software-limp-189ed6d03b3#8e7397ff-d6de-41ba-a197-9407ff8458ca)
- > strumenti basati sull’IA possono generare automaticamente il codice in base ai requisiti specifici, riducendo la necessità di scrittura manuale del codice. [⤴️](https://omnivore.app/me/https-ts-2-space-it-rivoluzione-dellingegneria-del-software-limp-189ed6d03b3#231abe30-8f41-4d5f-878a-6d773f09491f)
pages/Omnivore___14-01-2024___A New Compute Platform for Generative AI -.md
+2 -1
View File
@@ -4,7 +4,8 @@ author:: davide.diruscio@gmail.com
labels:: [[Newsletter]]
date-saved:: [[14-01-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
tags:: [[Benchmarks]] [[PROJECTS/MOSAICO]]
- ### Highlights
- > Large Action Model (LAM) paradigms. [⤴️](https://omnivore.app/me/a-new-compute-platform-for-generative-ai-18d07ea7958#5dad5316-11a3-45c7-963a-f7bc42c4f85f)
pages/Omnivore___14-05-2024___Edge 395- Task Decomposition in Autonomous Agents.md
+1 -1
View File
@@ -4,4 +4,4 @@ author:: davide.diruscio@gmail.com
labels:: [[Newsletter]]
date-saved:: [[14-05-2024]]
source:: [[Omnivore]]
state:: [[reading]]
state:: [[Reading]]
pages/Omnivore___14-08-2023___Generative AI- A new Gold Rush for software engineering innovation - VentureBeat.md
+4 -3
View File
@@ -9,7 +9,8 @@ is-archived:: 10
source:: [[Omnivore]]
state:: [[archived]]
- * ### Highlights
- collapsed:: true
* ### Highlights
collapsed:: true
- > For all the benefits that generative AI promises, voices are getting louder about the unintended societal effects of this technology. [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#b52716a9-84fb-490b-9b55-b6c22ece3c8c)
- > It is the first time in the history of humanity that white-collar jobs stand to be automated, potentially rendering expensive degrees and years of experience meaningless. [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#5e926a10-acfb-4733-a962-6a82de3dbfbb)
@@ -21,8 +22,8 @@ state:: [[archived]]
omnivore-note:: #TODO
- > Microsoft CEO Satya Nadella famously asked about generative AI, “OpenAI built this with 250 people; why do we have Microsoft Research at all?” [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#e7d5743e-ea5a-4789-88b6-f59ddf9e1d0d)
- > Why would you stop at a ten-billion-parameter model when you can train a massive general-purpose model with 500 billion parameters that can answer questions about any topic from any industry? [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#21cb06ec-c2a4-4b0d-bc56-ce8639b449ba)
- > There has been a realization recently that we might have hit the limit of productivity gains that can be achieved by the size of a model. [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#2c17576d-e8b9-477c-8557-933e82271565)
omnivore-note:: #CARDS
- id:: 68584eb4-9919-41da-ab7f-d39dfb933470
> There has been a realization recently that we might have hit the limit of productivity gains that can be achieved by the size of a model. [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#2c17576d-e8b9-477c-8557-933e82271565)
- > Independent evaluations of models have proved that there is no silver bullet, but the best model for an enterprise will be use-case specific. [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#5c1588e0-b008-43d9-816e-f452bef888d5)
- > In the comprehensive evaluation completed by Stanford using models from openAI, Cohere, Anthropic and others, it was found that smaller models may perform better than their larger counterparts. [⤴️](https://omnivore.app/me/https-venturebeat-com-ai-generative-ai-a-new-gold-rush-for-softw-189f107a215#6c8fc1ef-4578-4396-835f-8144ebd8d569)
omnivore-note:: #STAR
pages/Omnivore___14-12-2023___(20) The Future of Software Engineering with AI Agents - LinkedIn.md
+1 -1
View File
@@ -2,7 +2,7 @@
- full-title:: [(20) The Future of Software Engineering with AI Agents | LinkedIn](https://omnivore.app/me/20-the-future-of-software-engineering-with-ai-agents-linked-in-18c6784cdf7)
site:: [linkedin.com](https://www.linkedin.com/pulse/future-software-engineering-ai-agents-selim-salman/)
author:: Selim Salman
labels:: [[PROJECTS/SE-H2020-March-Call]]
labels:: [[PROJECTS/MOSAICO]]
date-saved:: [[14-12-2023]]
date-published:: [[12-09-2023]]
date-archived:: [[10-01-2024]]

Some files were not shown because too many files have changed in this diff Show More