pilazione, per generare nuovi programmi sorgenti nel linguaggio
di programmazione di arrivo. Questo approccio, per quanto ri-
goroso, produce risultati migliori quando la trasformazione ri-
guarda linguaggi con strutture di programmazione simili. Ad
esempio, la trasformazione di programmi scritti in un dato lin-
guaggio procedurale in un altro linguaggio procedurale è relati-
vamente semplice, perché gli stili e le strutture di codifica sono
concettualmente omogenei.
Tuttavia, quanto si tratta di trasformare questi linguaggi proce-
durali in linguaggi più moderni e object-oriented, è spesso ne-
cessario un approccio più sofisticato. La trasformazione della
sintassi di un linguaggio procedurale nella sintassi di un linguag-
gio object-oriented, come Java o C#, non è sufficiente. È ne-
cessario cambiare l’intera struttura o architettura del programma
e/o dell’applicazione. La separazione dell’accesso al database
dal livello di presentazione e dalla logica di business costituisce
solitamente un requisito indispensabile per la corretta moderniz-
zazione di un programma di vecchia generazione. Per molte ap-
plicazioni tecnologicamente superate il passaggio non è così
semplice, anche perché alcune parti di codice obsolete o ridon-
danti offuscano spesso la logica alla base del programma.
Senza un certo livello di ristrutturazione e/o ri-ingegnerizzazione,
un programma modernizzato, per quanto correttamente de-
scritto nel nuovo linguaggio, risulta spesso difficile se non im-
possibile da mantenere. Sotto un profilo strettamente tecnico, il
programma opera correttamente nel nuovo ambiente runtime;
tuttavia, la maggior parte delle aziende si aspetta qualcosa in più
dalla modernizzazione di un codice. È importante perciò com-
prendere esattamente sin dall’inizio il modello a oggetti che si ot-
terrà con la trasformazione. A volte, il modello a oggetti risultante
riflette la tecnologia di automazione più da vicino di quanto non
farebbe un modello definito dal cliente.
38
luglio-agosto 2012
Alcune soluzioni di trasformazione applicano al massimo grado
la tecnologia di automazione per la creazione del modello a og-
getti, riducendo il costo della soluzione. In questo processo, pos-
sono introdurre la dipendenza da un ambiente runtime che
supporti in modalità di emulazione alcune funzionalità caratteri-
stiche del linguaggio originale. A volte le soluzioni prendono de-
cisioni artificiali riguardo alla natura delle classi e alle modalità di
implementazione dei metodi. In altri casi, il codice risultante pre-
serva direttamente una parte dell’architettura o del flusso logico
dell’applicazione originale.
In questi casi la trasformazione può essere definita tecnicamente
riuscita, e il prezzo risulta spesso inferiore grazie alla tecnologia
di automazione applicata, ma il risultato sarà probabilmente in-
feriore alle aspettative dei clienti. Si raccomanda perciò di stu-
diare a fondo, prima di scegliere la soluzione di modernizzazione,
la forma che assumerà il modello a oggetti risultante.
Alcuni fornitori, come The Software Revolution (TSRI) e Trinity Mil-
lennium Group, utilizzano questi sofisticati approcci di conversione
e offrono servizi di trasformazione per numerosi linguaggi.
La tecnologia JANUS di TSRI analizza le applicazioni software
scritte in un linguaggio di vecchia generazione e le trasforma in
un linguaggio object-oriented, ad esempio C++, C# o Java. La
soluzione di TSRI può inoltre rifattorizzare il codice trasformato
per migliorarne la struttura, le prestazioni e la facilità di manu-
tenzione; allo stesso modo, può generare una documentazione
UML (Unified Modeling Language) sia per il sistema di partenza
che per quello di arrivo.
Il processo AEM (Automation-Enabled Modernization) di Trinity è
studiato per offrire alle aziende un approccio graduale alla mo-
dernizzazione. Dalla caratterizzazione all’estrazione delle cono-
scenze fino alla trasformazione, i clienti possono ottenere
un’analisi ben documentata dei sistemi esistenti, oltre a una com-
pleta trasformazione delle applicazioni.
Trinity utilizza un approccio particolare che manipola gli AST in-
termedi prima che questi generino la nuova applicazione. I clienti
ricevono così un’applicazione correttamente strutturata, solita-
mente in Microsoft C# o Java, in cui tutti i programmi e i codici
in disuso sono stati eliminati. La soluzione unifica inoltre le parti
di codice ridondanti in componenti riutilizzabili. Anche la belga
Anubex offre soluzioni di trasformazione del codice basate sul-
l’uso degli AST. Il suo metodo SLAM (Source Language Abstract
Method) permette di analizzare, manipolare e generare nuovi co-
dici sorgenti. La soluzione Anubex è in grado di trasformare un
codice scritto in COBOL, nel linguaggio Natural di Software AG
o persino in FORTRAN convertendolo in Java.
Make Technologies, una società tecnologica canadese, utilizza
uno schema di generazione del codice denominato TLM (Tran-
sformational Legacy Modernization) come base per la trasfor-
mazione delle applicazioni in Java. Questo approccio permette
MODERNIZZAZIONE DELL’IT: STRATEGIA E SOLUZIONI
