💻 computer science

Combining Example-Based and Rule-Based Program Transformations to Resolve Build Conflicts

Il paper presenta BuCoR, un nuovo risolutore di conflitti di build che combina trasformazioni basate su regole e su esempi per generare soluzioni efficaci a conflitti di integrazione software reali.

Autori originali: Sheikh Shadab Towqir, Fei He, Todd Mytkowicz, Na Meng

Pubblicato 2026-02-13

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Sheikh Shadab Towqir, Fei He, Todd Mytkowicz, Na Meng

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere due amici, Luca e Roberto, che stanno lavorando insieme a un progetto molto grande: la costruzione di una casa (il software).

Ognuno di loro prende una stanza diversa della casa e ci fa delle modifiche:

Luca decide di spostare la cucina e cambiare il nome del piano cottura da "Forno" a "FornoMagico".
Roberto, intanto, decide di aggiungere un nuovo elettrodomestico nella cucina, ma lo chiama ancora "Forno".

Quando provano a unire le loro due versioni della casa, succede un disastro: la casa non si può costruire perché c'è confusione. Il nuovo elettrodomestico di Roberto cerca un "Forno" che non esiste più, perché Luca lo ha rinominato. Questo è un conflitto di costruzione (build conflict).

Fino a poco tempo fa, gli strumenti per unire questi lavori erano come dei muratori un po' ottusi: se vedevano un conflitto, dicevano "Ehi, c'è un errore, sistemalo tu". Spesso richiedevano ore di lavoro manuale per capire come aggiustare tutto.

Gli autori di questo paper hanno creato un nuovo "super-muratore" intelligente chiamato BuCoR. Ecco come funziona, spiegato con un'analogia semplice:

1. Il Detective (Rilevamento del conflitto)

Prima di tutto, BuCoR non si limita a guardare il risultato finale. Analizza tre versioni della casa:

La versione originale (la base).
La versione di Luca.
La versione di Roberto.
Come un detective, BuCoR guarda le modifiche e dice: "Ah! Qui c'è un problema: Roberto sta usando un oggetto che Luca ha cambiato nome. La casa non può essere costruita così".

2. I Due Super-Poteri di BuCoR

BuCoR non usa un solo metodo per risolvere il problema. Usa due strategie diverse, come se avesse due assistenti con super-poteri diversi:

A. L'Assistente "Ricercatore di Esempi" (BuCoR-E)

Immagina che BuCoR abbia un archivio segreto. Quando Luca ha rinominato il "Forno" in "FornoMagico", in un'altra parte della casa (in un altro file di codice), qualcuno aveva già dovuto fare lo stesso cambiamento: aveva aggiornato anche il nome scritto sul manuale d'uso e sulla scatola dell'elettrodomestico.

Cosa fa: BuCoR guarda nella versione di Luca e cerca: "Hai già sistemato questo problema da qualche parte?". Se trova un esempio (dove Luca ha aggiornato anche il manuale), impara da quell'esempio.
L'analogia: È come se tu avessi bisogno di riparare una perdita d'acqua. Invece di inventare una soluzione da zero, guardi come l'idraulico ha riparato una perdita simile in un'altra stanza della tua casa, e applichi lo stesso metodo.
Il vantaggio: Risolve problemi complessi e specifici, adattandosi perfettamente al contesto unico di quel progetto.

B. L'Assistente "Manuale delle Regole" (BuCoR-R)

A volte, però, non c'è nessun esempio precedente da guardare. Oppure il problema è molto comune e banale (come quando due persone scrivono la stessa parola su un foglio).

Cosa fa: BuCoR ha un manuale con 16 regole d'oro già scritte. Ad esempio: "Se qualcuno rinomina una classe, aggiorna tutti i riferimenti". Oppure: "Se due persone aggiungono la stessa funzione, cancellane una".
L'analogia: È come avere un libretto di istruzioni per l'assemblaggio di un mobile IKEA. Se vedi un bullone che non entra, apri il manuale alla pagina 4 e segui la regola standard.
Il vantaggio: È veloce e risolve i problemi più comuni e ripetitivi senza dover pensare troppo.

3. La Magia dell'Unione (Come risolvono insieme)

BuCoR è speciale perché combina questi due mondi.

Se c'è un esempio nel codice, usa l'Assistente Ricercatore per copiare la soluzione intelligente e specifica.
Se non c'è un esempio, usa l'Assistente Manuale per applicare una regola standard.

Nel paper, gli autori hanno testato BuCoR su 88 conflitti reali presi da progetti software veri.

È riuscito a trovare una soluzione per 65 casi su 88 (il 74%!).
Di queste soluzioni, 34 erano perfette e pronte all'uso, esattamente come le avrebbe fatte un programmatore umano esperto.

Perché è importante?

Prima di BuCoR, gli strumenti automatici erano come bambini che imparano solo a cambiare i nomi delle cose (se "Forno" diventa "FornoMagico", cambiano solo quel nome). Ma spesso il problema è più profondo: bisogna cambiare anche il manuale, la scatola e le istruzioni.

BuCoR è come un architetto esperto che non solo cambia il nome, ma capisce il contesto: "Ah, se cambi il nome del forno, devo anche cambiare il nome sulla scatola e nel manuale, altrimenti la casa non funziona".

In sintesi, BuCoR è un assistente che impara dagli errori passati (esempi) e segue le regole consolidate (regole) per aiutare gli sviluppatori a fondere i loro lavori senza distruggere la casa (il software).

1. Il Problema: Conflitti di Build nel Merge

Nello sviluppo software collaborativo, l'integrazione di modifiche da diversi rami (branch) tramite sistemi di controllo versione (come Git) genera spesso conflitti. Mentre i conflitti testuali (sovrapposizione di modifiche allo stesso file) sono ben gestiti, i conflitti di build (o build conflicts) rappresentano una sfida significativa.
Questi conflitti si verificano quando l'integrazione "naif" (automatica) delle modifiche provoca errori di compilazione o test, ad esempio a causa di:

Ridenominazione di metodi o classi in un ramo e aggiunta di chiamate a quelle entità nell'altro.
Modifiche alla gerarchia delle classi, aggiunta/rimozione di parametri o tipi di ritorno.
Incoerenze tra definizioni (def) rimosse/aggiornate e nuovi utilizzi (use) introdotti.

Gli strumenti esistenti (come Gmerge o MrgBldBrkFixer) sono limitati: spesso si concentrano solo sulla ridenominazione dei simboli e falliscono nel gestire conflitti più complessi o nel suggerire modifiche contestuali sistematiche.

2. Metodologia: BuCoR (BUild COnflict Resolver)

Gli autori introducono BuCoR, un nuovo risolutore di conflitti ibrido che combina due strategie complementari: trasformazione basata su esempi (BuCoR-E) e trasformazione basata su regole (BuCoR-R).

Il processo si articola in quattro fasi principali:

A. Rilevamento dei Conflitti e Costruzione del Grafo

BuCoR utilizza uno strumento statico (Bucond) per analizzare tre versioni del programma: la base ( $b$ ), il ramo sinistro ( $l$ ) e il ramo destro ( $r$ ).

Genera un grafo delle entità del programma (PEG) per ciascuna versione.
Crea una versione unita "naif" ( $A_m$ ) tramite git-merge.
Costruisce un grafo interconnesso a quattro vie che collega $G_b, G_l, G_r$ e $G_{A_m}$ , permettendo di identificare le modifiche specifiche responsabili dei conflitti e di allineare il contesto del codice.

B. Strategia 1: Trasformazione Basata su Esempi (BuCoR-E)

Questa componente si basa sull'ipotesi che le correzioni di errori di build già presenti nei singoli rami possano servire come "esemplari" per risolvere i conflitti di merge.

Mining degli Esempi: Identifica la modifica responsabile del conflitto (es. una definizione rimossa o rinominata) e cerca nel ramo che ha apportato tale modifica altri esempi di come gli sviluppatori hanno adattato l'uso di quell'entità.
Inferenza del Pattern: Estrae uno script di modifica (AST) dagli esempi trovati. Utilizza l'analisi delle dipendenze (controllo e dati) per filtrare le modifiche irrilevanti e isolare il pattern di trasformazione minimo necessario per adattare il codice.
Applicazione del Pattern: Cerca di adattare il pattern inferito al contesto della versione unita ( $A_m$ ) tramite un algoritmo di matching "centrato sull'uso" (use-centric). Se il contesto corrisponde, applica le modifiche per risolvere il conflitto in modo specifico per quel progetto.

C. Strategia 2: Trasformazione Basata su Regole (BuCoR-R)

Questa componente affronta i conflitti ricorrenti che non hanno esempi specifici nei rami.

Gli autori hanno definito e implementato 16 regole di risoluzione basate su studi empirici precedenti.
Le regole coprono scenari comuni come: ridenominazione di classi/interfacce, modifiche ai parametri dei metodi nelle super-classi, rimozione di import, ecc.
Il modulo applica queste regole predefinite quando BuCoR-E non trova esempi pertinenti o quando il conflitto rientra in una categoria standard.

3. Contributi Chiave

BuCoR: Il primo risolutore di conflitti di build che combina dinamicamente l'apprendimento basato su esempi (context-aware) con regole strutturate.
Approccio Ibrido: La capacità di gestire sia conflitti convenzionali (tramite regole) sia conflitti non convenzionali o specifici del progetto (tramite mining di esempi e inferenza di pattern).
Algoritmi Avanzati: Sviluppo di tecniche sofisticate per l'estrazione di pattern basata su dipendenze, il matching contestuale e la generazione di soluzioni multiple.
Dataset e Valutazione: Creazione di un dataset di 88 conflitti reali di build da 30 progetti open-source Java, coprendo 21 tipi diversi di conflitti.

4. Risultati Sperimentali

Il tool è stato valutato su 88 conflitti reali:

Copertura: BuCoR ha generato almeno una soluzione per 65 casi su 88 (74%).
- BuCoR-E ha coperto il 32% dei casi.
- BuCoR-R ha coperto il 58% dei casi.
- La combinazione ha permesso di risolvere conflitti che una singola strategia non avrebbe potuto gestire.
Accuratezza: Su un totale di 79 soluzioni generate, 41 sono state corrette (52%).
- BuCoR-E ha raggiunto un'accuratezza del 75% (21/28), dimostrando alta precisione quando riesce a trovare esempi pertinenti.
- BuCoR-R ha raggiunto un'accuratezza del 39% (20/51), coprendo più casi ma con un tasso di errore più alto a causa della rigidità delle regole.
Confronto: BuCoR ha superato significativamente i modelli LLM (come o4-mini) testati sullo stesso dataset, risolvendo correttamente più conflitti e fornendo soluzioni semanticamente più coerenti.

5. Significato e Impatto

Questo lavoro rappresenta un passo avanti significativo verso l'automazione intelligente del merge software:

Superamento dei limiti attuali: Risolve conflitti che vanno oltre la semplice ridenominazione di simboli, affrontando problemi strutturali complessi come le modifiche alle gerarchie di classe.
Adattabilità: Dimostra che l'uso di esempi reali dal repository (es. come gli sviluppatori hanno già risolto errori simili) è una strategia potente per generare soluzioni contestuali che gli strumenti basati su regole rigide non possono produrre.
Futuro della manutenzione: Fornisce una base per strumenti di merge più intelligenti che riducono il tempo di risoluzione dei conflitti e migliorano la qualità del software, specialmente in progetti complessi dove gli errori di build sono frequenti e difficili da diagnosticare manualmente.

In sintesi, BuCoR dimostra che un approccio ibrido, che unisce la flessibilità dell'apprendimento dagli esempi alla robustezza delle regole predefinite, è la via più promettente per automatizzare la risoluzione dei conflitti di build.