Search arXiv⌕ Search
Home/Archive/arXiv

arXiv · 1206.0122

ACME vs PDDL: support for dynamic reconfiguration of software architectures

Jean-Eudes Méhus·Thais Batista·Jérémy Buisson
View original source ↗Read source document ↗Export metadata ↓

Abstract

On the one hand, ACME is a language designed in the late 90s as an interchange format for software architectures. The need for recon guration at runtime has led to extend the language with speci c support in Plastik. On the other hand, PDDL is a predicative language for the description of planning problems. It has been designed in the AI community for the International Planning Competition of the ICAPS conferences. Several related works have already proposed to encode software architectures into PDDL. Existing planning algorithms can then be used in order to generate automatically a plan that updates an architecture to another one, i.e., the program of a recon guration. In this paper, we improve the encoding in PDDL. Noticeably we propose how to encode ADL types and constraints in the PDDL representation. That way, we can statically check our design and express PDDL constraints in order to ensure that the generated plan never goes through any bad or inconsistent architecture, not even temporarily.

Explore related subjects

cs.SE

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Jean-Eudes Méhus, Thais Batista, Jérémy Buisson. 2012-06-01. ACME vs PDDL: support for dynamic reconfiguration of software architectures. https://arxiv.org/abs/1206.0122

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

arXiv2026

Energy-Efficient Code Generation Using Large Language Models: A Systematic Literature Review

Large Language Models (LLMs) are increasingly used in software engineering for code generation, completion, translation, and repair. While substantial research has examined the energy consumption and environmental impact of LLM training and inference, considerably less attention has been given to the energy efficiency of the code produced by these models. Existing studies are fragmented across different models, programming tasks, benchmarks, hardware platforms, and measurement methods, making it difficult to draw consistent conclusions about the energy efficiency of LLM-generated code. No systematic synthesis currently consolidates these findings or identifies common trends, gaps, and methodological inconsistencies. To address this gap, we conduct a systematic literature review of existing empirical studies on the energy efficiency of LLM-generated code. We examine the extent to which LLMs generate energy-efficient code, the metrics used for evaluation, the benchmarks, datasets, and measurement tools employed, and the influence of prompting and fine-tuning strategies. Our findings show that the current evidence remains limited and highly heterogeneous. Most studies rely on conventional software-efficiency metrics and existing programming or code-generation benchmarks rather than evaluation methods specifically designed for LLM-generated code. The reported energy-efficiency outcomes are strongly dependent on the evaluated model, task, benchmark, and experimental configuration, and no single prompting strategy consistently improves energy efficiency across settings. We further find limited investigation of small language models, energy-aware fine-tuning, diverse programming languages, real-world software domains, and direct hardware-based energy measurement. Overall, the review highlights the lack of standardized evaluation practices and dedicated energy-efficiency benchmarks.

cs.SE↗
arXiv2026

Where Accountability Lives: Mapping Human Responsibility to Workflow Artifacts in Agentic Software Development

Coding agents author commits, open pull requests and push code in production repositories. Responsibility is settled in two layers that do not refer to each other: platform controls gating what an agent may do, and provider terms allocating responsibility for its output. Objective: Where the two layers disagree at a workflow event, and what each states there about authority, execution, verification, consequence and record. Method: A qualitative document study of 121 items archived byte-exact: documentation for four agentic coding tools, the platform controls on their output, and eighteen policy documents from seven providers, read by deductive content analysis against an a-priori system of five dimensions and nine workflow events. An independent second coder blind-recoded the verification-mechanism classification, a complete enumeration and not a sample (Cohen's kappa 0.81, n = 13, on whether a mechanism compels; 0.75, n = 12, on who performs it). Results: Cursor's terms make the user responsible for evaluating the use of any suggestion; its documentation describes a product that performs that evaluation and records it as an approval. No collected artifact records that the verification the terms make the user's duty took place. At merge two tools compel a person, one documents an agent approving below a configured risk threshold, and one only advises. Six of the fifteen mechanisms that compel a check have a default the vendor states; nine have one this study inferred. Readers who had not made them refuted five of the eight absence claims; three survived, one materially qualified. Conclusions: The terms attach duty and consequence to output as a class, the platform records events, nothing records the duty discharged. One vendor documents a product that forms the approval judgement, and the terms allocate consequence against the artifact regardless.

cs.SE↗
arXiv2026

Rebuild Dossier: Mechanically-Enforced Specs for Agentic App Rebuilds, and What Model-Tier Failures Reveal

An AI agent's rebuild is only as good as the process that produced it. Prior work found that once a model is strong enough, a multi-agent rebuild pipeline loses to the simplest approach: giving the model the original code and one instruction (AgentModernize). We present rebuild-dossier, an open-source tool that locks an application's real interface - its exact inputs and outputs - before any code is written, then enforces one-test-at-a-time building through automated checks, not written instructions alone. Three results shape this evaluation, with differing amounts of evidence. First, in a small comparison, the compliant agent failed a held-back test while the rule-breaking agent passed everything - proof that a passing suite doesn't certify correctness when tests can be gamed. Second, we tested whether this beats simply giving the weaker model the source and one instruction: tied on a small app, but lost outright on a larger one where the automated check wasn't even running - pointing to the check mechanism, not interface-locking, which held up separately. Third, every claim here is checked at three levels - the agent's own report, an automated log, and the actual files produced - catching real errors, including a bug in our own logging code, that a single level would have missed. These risks reproduce on a different model and toolchain: a stronger model followed our process three times running, something the weaker model never managed. The tool is public, MIT licensed, and reproduces end to end against our own applications.

cs.SE↗