linguaggi. Un esempio: la trasformazione sintattica di un codice
scritto in un linguaggio procedurale verso un altro linguaggio pro-
cedurale è relativamente facile; la trasformazione risulta più com-
plessa quando si parte da un linguaggio con uno stile di
programmazione procedurale per arrivare a un linguaggio in stile
object-oriented. Non solo la sintassi dei due linguaggi è diffe-
rente, ma anche la struttura dei programmi e degli ambienti run-
time è molto diversa. La conversione di un programma PL/I in
un programma COBOL, ad esempio, non è difficile. Viceversa, la
conversione di programmi COBOL o PL/I associati a un am-
biente transazionale CICS (Customer Information Control Sy-
stem) o IMS (Information Management System) di un mainframe
IBM verso i linguaggi Java o C# presenta un livello di comples-
sità superiore.
Allo stesso modo, la trasformazione di un’applicazione scritta in
ALGOL o COBOL in un ambiente Unisys TIPS o COMS intro-
duce alcune difficoltà nel processo di trasformazione. I pro-
grammi procedurali rappresentano la logica di business come
un insieme di routine o subroutine che fanno riferimento a strut-
ture di dati o a variabili condivise. I programmi object-oriented, vi-
ceversa, rappresentano la logica di business in termini di
“oggetti” che incorporano completamente le proprie variabili e
strutture di dati specifiche, indipendentemente dagli altri oggetti.
La trasformazione di programmi procedurali molto estesi con nu-
merose routine, subroutine e unità di storage condivise in una
serie di oggetti incapsulati in un nuovo linguaggio di program-
mazione e in un ambiente runtime differente è possibile, ma que-
ste soluzioni devono essere valutate con grande attenzione.
Fornitori di nicchia
Alcuni fornitori di nicchia offrono soluzioni di trasformazione del
codice per un’ampia serie di linguaggi, database e ambienti run-
time di vecchia generazione.
Le implementazioni di sistemi eseguite negli ultimi 50 anni hanno
utilizzato un’infinita varietà di linguaggi e sistemi di gestione dei
database (DBMS). Per questa ragione, molte soluzioni di tra-
sformazione del codice si concentrano su determinati linguaggi
e/o DBMS. Per decenni, lo sviluppo dei portafogli di applicazioni
è stato effettuato usando linguaggi e/o ambienti di programma-
zione molto differenti, come IBM PL/I o COBOL, IBM RPG (II, III
e IV), Natural di Software AG, ADSO per ADS Online o CA Ideal
di CA Technologies, Model 204 di Rocket Software e molti altri.
Diversi sistemi di generazione delle applicazioni, come CA Gen,
2E, Plex e Telon di CA Technologies, EGL di IBM e molti altri, ge-
neravano il codice come risultato di un linguaggio o di un sistema
di specifiche di livello superiore.
Questi tipi di sistemi possono essere trasformati utilizzando il co-
dice generato, ma questo non è l’approccio ottimale. Le solu-
zioni di trasformazione più pulite sono quelle che analizzano la
descrizione nativa dei programmi in questi generatori di codice.
Databorough, una società inglese che serve i mercati di IBM
AS/400 o System i, offre una serie di prodotti in grado di analiz-
zare, documentare o trasformare le strutture CA 2E e CA Gen di
CA Technologies. X-2E estrae automaticamente una definizione
completa del modello CA 2E, precedentemente noto come
Synon, e la utilizza per studiare i sistemi esistenti in questo am-
biente. X-2E Enterprise utilizza il modello CA 2E (ex Synon) come
specifica per rifattorizzare e generare automaticamente un’ap-
plicazione MVC (model-view-controller) usando metodi object-
oriented in Java, C# o perfino in RPG a formato libero. Questa
soluzione permette di sostituire un’applicazione CA Gen preesi-
stente con applicazioni Java, C# o COBOL che non richiedano
ambienti runtime proprietari.
Tiburon Technologies è specializzata nella trasformazione di ap-
plicazioni CA-Datacom/CA Ideal, di applicazioni CA IDMS, CA
ADS, Natural/Adabas di Software AG e di una miriade di altri lin-
guaggi 4GL. La soluzione Tiburon permette di trasformare le ap-
plicazioni scritte in questi linguaggi in COBOL, pur non offrendo
la migrazione ad ambienti .NET o Java. Essa introduce inoltre
una routine di I/O per DBMS (DBNTRY) che mappa le chiamate
ai database dei vecchi DBMS in chiamate con accesso SQL a
database relazionali come DB2/UDB, Oracle o SQL Server.
Tecnologie di trasformazione
Mentre molti fornitori di nicchia offrono soluzioni studiate appo-
sitamente per determinati linguaggi o tecnologie di DBMS, altri
propongono un approccio più formale, basato sui principi del-
l’informatica.
Questi fornitori analizzano il codice sorgente e ne producono
una rappresentazione intermedia. Le rappresentazioni interme-
die possono essere denominate in vari modi a seconda del for-
nitore, ma tutte sono fondate sul concetto informatico dell’albero
sintattico astratto (AST). Gli AST rappresentano la struttura sin-
tattica del codice sorgente in forma di albero, in cui ogni nodo
dell’albero rappresenta un costrutto del codice sorgente. Gli
AST sono completamente indipendenti dalla sintassi originale
del sorgente e possono essere usati, insieme a principi di com-
luglio-agosto 2012
37
