Round-trip engineering

In ingegneria del software, la Round-Trip Engineering (RTE) (che si potrebbe tradurre in Italiano con “Ingegneria dell'Andata e Ritorno”) è una metodologia che, appoggiandosi ad opportuni strumenti di sviluppo software, prevede la sincronizzazione di tutti gli artefatti software, come ad esempio, i requisiti del sistema, il modello software di specifica, i file di configurazione o la documentazione a corredo.

L'esigenza di operare secondo la metodologia RTE nasce quando una stessa informazione è contenuta in più artefatti e lo sviluppo perderebbe consistenza se, al variare di una caratteristica di un qualche artefatto, tale variazione non venisse opportunamente propagata a tutti gli altri. È tipico il caso in cui l'aggiunta di una funzionalità, ad esempio nel codice, non viene riportata nel modello relativo a livello architetturale. In questo caso quindi il modello non rifletterà più la sua implementazione e viceversa.

La RTE è intimamente legata al tradizionale software engineering essendo composta, appunto, di un'“andata” e un “ritorno” cioè il forward engineering, che prevede la creazione del software a partire dalle specifiche, e il reverse engineering, che prevede invece la definizione di specifiche a partire dal software esistente. Come guida e supporto in questi due percorsi viene usata la tecnica del reengineering, ovvero l'intima comprensione di un software esistente e la capacità di modificarlo a fronte di esigenze che nascono sia nella parte dei requisiti della specifica sia nell'implementazione software.

Ma RTE non è una tecnica che, semplicemente, propone la possibilità di andare avanti e indietro sulla linea dello sviluppo software: piuttosto è la capacità di sincronizzare fra loro artefatti esistenti che evolvono incrementalmente in una condizione di concorrenza. In altre parole, ogni artefatto viene modificato a fronte della modifica di un altro. Il forward engineering può essere visto come una specifica istanza della RTE nella quale è presente solo la specifica, mentre il reverse engineering è l'istanza nella quale è presente solo il software. Molte attività di reengineering possono a loro volta essere interpretate come RTE ogni volta che il software viene modificato per adattarsi a cambiamenti fatti nelle specifiche dedotte da un'attività di reverse engineering.

La RTE è inoltre caratterizzata da strumenti che permettono una modifica automatica degli artefatti a fronte di un'inconsistenza intercettata in modo altrettanto automatico. Anche questa caratteristica la distingue dall'approccio classico dove sia il forward sia il reverse possono entrambi essere gestiti sia in modo manuale che automatico. Nella RTE invece l'automatismo è essenziale anche se può essere “istantaneo” o “su richiesta” nel senso che sia sincrono o asincrono alle variazioni effettuate sui diversi artefatti. Nel caso dell'asincronicità i diversi attori possono lavorare in modo concorrente sui singoli artefatti e richiedere una verifica di consistenza in momenti definiti e scegliere poi come gestire gli eventuali conflitti che si sono venuti a creare.

Esempi di Round-Trip Engineering

L'esempio più comune di RTE è la sincronizzazione tra i modelli UML (Unified Modeling Language) e relativo codice sorgente.

Molti strumenti commerciali e prototipi di ricerca (ed esempio FUJABA: “From UML to Java and back again”) implementano questo tipo di RTE. Normalmente i diagrammi delle classi UML sono supportati ad un qualche livello. Ma in generale alcuni concetti dell'UML quali “associazione” e “contenimento” non hanno una rappresentazione diretta in molti linguaggi di programmazione, cosa che limita l'usabilità e la creazione di codice oltre ad una significativa accuratezza nell'analisi del codice (ad esempio il “contenimento” non è semplice da individuare nel codice). Ulteriori problemi per la RTE sono dati dalle parti di descrizione comportamentale in UML

Una forma più approcciabile di RTE è implementata nel contesto delle application programming interface (API), dove un modello che descrive l'uso di un framework API da parte di un'applicazione è sincronizzato con il codice di quella applicazione. In questo caso, l'API “prescrive” tutti i modi corretti in cui quel determinato framework può essere usato. Questo permette di individuare in modo preciso e completo dove l'API viene usata nel codice e, allo stesso tempo, la creazione di codice che implementi un corretto uso dell'API stessa. Di questa categoria fanno parte due importanti implementazioni: framework-specific modeling languages and Spring Roo