MELIS un ambiente per la reingegnerizzazione di interfacce legacy verso il web

  11 
sistema a mutate esigenze, migliorarlo per prevenire problemi e 
trasformarlo radicalmente per adattarlo a tecnologie moderne.  
Come sostiene Lehman [ML80], un sistema software che mantiene la 
sua utilità, anche a distanza di anni, è necessariamente in continua 
evoluzione per adattarsi ai cambiamenti del mondo reale. In 
particolare, egli afferma che il software deve cambiare continuamente o 
diventare sempre meno utile nel mondo reale(prima legge 
dell’evoluzione del software). In aggiunta, Lehman nella seconda legge 
dell'evoluzione del software, evidenzia come la struttura di un sistema 
software che evolve è necessariamente soggetta al degrado, a meno che 
non vengano regolarmente intraprese azioni di rimedio. Di fatto anche 
il minimo intervento di manutenzione, può diventare un problema 
critico di difficile soluzione a causa dell’aumento della resistenza alle 
modifiche, che è conseguenza dei ripetuti interventi di manutenzione e 
delle considerevoli dimensioni assunte dai sistemi software (causate 
dalle nuove funzionalità introdotte per soddisfare le richieste del 
mercato). Tale problema è noto alla comunità scientifica come 
problema dei sistemi software “ereditati” (legacy system), ossia sistemi 
software che sono stati progettati e sviluppati con teorie, modelli, 
tecniche, strumenti e metodologie profondamente diverse da quelle 
emerse negli ultimi anni. Bennett ha definito informalmente i legacy 
system come grossi sistemi software che non sappiamo trattare, ma che 
sono vitali per la nostra organizzazione. 
Un tipico sistema legacy è scritto, ad esempio in Assembler Cobol, o 
Fortran ed è stato sviluppato usando metodologie e tecnologie 
dell'ingegneria del software dell’epoca. La rilevanza economica di tali 
sistemi, per le aziende che li producono e li usano, ed il fatto che è 
assolutamente improponibile una loro sostituzione con sistemi 
  12 
sviluppati utilizzando nuove tecnologie, ha ulteriormente favorito il 
crescente interesse nei confronti delle tecniche e metodologie di 
manutenzione del software. Gli interventi in tale ambito, non 
riguardano solo semplici attività di manutenzione, ma anche azioni 
radicali che mirano ad operare una profonda trasformazione di tali 
sistemi o di loro componenti al fine di garantirne un’evoluzione 
coerentemente con le nuove esigenze e le innovazioni tecnologiche e/o 
metodologiche. Di conseguenza, nel corso degli anni si è assistito a 
differenti ondate migratorie, come ad esempio, la migrazione dai 
sistemi batch ai sistemi interattivi, dalle architetture monolitiche alle 
architetture client-server, dai modelli procedurali a quelli ad oggetti, 
dalle interfacce a caratteri alle interfacce grafiche. 
In questa tesi si propone un ambiente integrato che supporta una 
strategia incrementale per la migrazione di Legacy Information System 
(LIS) scritti in ACUCOBOL-GT verso applicazioni web multi-tier. Tale 
approccio prevede di separare il Graphical User Interface (GUI) Layer 
dall’Application Layer e dal Data Layer. Questo disaccoppiamento 
permette di incapsulare il sottosistema costituito dall’application e data 
layer in un wrapper. 
La strategia di migrazione prevede le seguenti fasi: Pre-processing, 
Restructiring and Wrapping, GUI Reengineering ed Integration. La prima 
fase fornisce dettagli sul tipo e sugli attributi di ogni oggetto grafico 
che compone una  GUI del sistema legacy. Le GUI sono implementate 
in ACUCOBOL-GT sottoforma di SCREEN SECTION. Queste 
interfacce grafiche sono molto simili a quelle dei più moderni software 
e dunque costituite da elementi grafici quali etichette  dette LABEL, 
campi di testo detti ENTRY-FIELD e bottoni. 
  13 
Nella fase di Restructuring and Wrapping ogni call di 
INPUT/OUTPUT di una SCREEN SECTION viene sostituita da 
istruzioni che abilitano la comunicazione con il Wrapper. Sempre in 
questa fase è possibile identificare due diversi tipi di clausole associate 
ad ogni campo di testo della SCREEN SECTION: clausola AFTER e 
clausola BEFORE. Tali clausole possono essere necessarie a validare il 
contenuto del campo e dunque migrabili lato client con un linguaggio 
di scripting oppure possono accedere al data base e compiere 
operazioni di logica applicativa.  
Nella fase di GUI Reengineering ad ogni SCREEN SECTION migrata 
sarà associato un nuovo sottosistema grafico nell’applicazione web. 
Il passo finale della strategia, fase di Integration, prevede 
l’integrazione tra il sistema legacy ristrutturato ed il sistema web. 
Per fornire un supporto allo sviluppatore durante il processo di 
migrazione, è stato implementato un ambiente integrato che 
automatizza ogni sua fase. Questo ambiente dal nome MELIS (a 
Migration Environment for Legacy Information System), è stato 
sviluppato come plug-in per la piattaforma Eclipse [Eclipse].  
Nella fase di Pre-processing il tool genera un file XML che 
rappresenta la struttura di ogni SCREEN SECTION del programma 
cobol da migrare. Il file include inoltre tutte le azioni associate a 
ciascun campo della GUI e tutti i dettagli corrispondenti agli oggetti 
grafici. 
Il file XML prodotto è dato in input alle fasi di Restructuring and 
Wrapping e  GUI-Reengineering. In questa fase la struttura associata a 
ciascuna SCREEN SECTION è visualizzata in maniera gerarchica in 
modo da identificare velocemente gli oggetti grafici che la 
compongono e le clausole AFTER/BEFORE associate. Per ogni clausola 
  14 
lo sviluppatore può deciderne la migrazione sia sul server, sia sul client 
permettendo, in questo ultimo caso, di utilizzare un linguaggio di 
scripting quale javascript. Sempre in modo automatico il tool permette 
di sostituire le call alla visualizzazione della vecchia SCREEN 
SECTION con una call al wrapper che abiliterà dunque la 
comunicazione e la sincronizzazione con il sistema web. 
Nella fase di GUI-Reengineering, lo sviluppatore potrà generare un 
nuovo sottosistema grafica per ogni SCREEN SECTION del sistema 
cobol. Sarà creata una pagina JSP che rappresenta la user interface 
reingengerizzata, un java bean contenente le informazioni provenenti 
dal  wrapper e due servlet necessarie alla corretta sincronizzazione tra 
il LIS ristrutturato ed il nuovo sistema Web.  
In fine, nella fase di integration, MELIS permette la compilazione dei 
sorgenti ACUCOBOL-GT, il debug del sistema LIS ristrutturato, la 
possibilità di visualizzare le interfacce grafiche reingengerizzate 
all’interno di un browser integrato ed infine l’esecuzione del sistema 
migrato. 
Per validare la strategia ed il tool è stata poi effettuata la migrazione 
di due moduli del sistema BS&C sviluppato in ACUCOBOL-GT presso 
l’azienda MTSYS di Avellino. Questo sistema si occupa 
dell’informatizzazione degli adempimenti fiscali e previdenziali delle 
aziende. Il primo caso di studio, modulo GST000, permette la gestione 
degli archivi aziendali, il secondo, GST001 gestisce l’anagrafica degli 
utenti. La scelta è ricaduta su questi moduli, perché, vista la loro 
complessità, è stato possibile identificare e risolvere differenti 
problematiche che potrebbero ripresentarsi nella migrazione dell'intero 
sistema BS&C. Dopo aver illustrato i vari passi per effettuare la 
migrazione di ogni singolo modulo utilizzando MELIS, verranno 
  15 
mostrati ed analizzati i vantaggi avuti nell’utilizzare l’ambiente 
durante l’intero processo. 
Infine per validare formalmente l’approccio ed il tool è stato 
progettato un esperimento controllato che punta ad analizzare e 
valutare l’utilità di MELIS nella migrazione di sistemi LIS 
implementati in ACUCOBOL-GT verso un’architettura web multi-tier. 
La prospettiva di questo esperimento è quella di valutare la possibilità 
di adottare MELIS in un’azienda software. 
I soggetti che hanno preso parte all’esperimento sono quattro 
volontari appartenenti al corso di laurea di Informatica dell’Università 
degli Studi di Salerno (laureandi Unisa/laureati e/o dottorandi Unisa) e 
quattro impiegati con esperienza di programmazione ACUCOBOL-GT 
appartenenti all’azienda MTSYS. Gli otto soggetti sono stati poi 
raggruppati in quattro gruppi, ognuno dei quali costituisce un team di 
sviluppo. Ogni team è costituito da un impiegato aziendale e da un 
soggetto Unisa. L’esperimento si è svolto in un laboratorio dell’azienda 
MTSYS dotato di videocamere, video proiettore e impianto di 
climatizzazione. E’ stata effettuata dapprima una sessione di training in 
modo da fornire a tutti la medesima conoscenza delle applicazioni 
software da migrare, poi due sessioni di laboratorio in cui  i soggetti 
hanno portato a termine due task assegnati. Infine,  prima di eseguire 
l’esperimento è stato fornito ai soggetti tutto il materiale necessario per 
effettuare in modo corretto l’esperimento.  
Infine saranno discussi i risultati ottenuti dall’analisi dei dati raccolti 
durante la sperimentazione. Saranno analizzati i tempi raccolti e le 
risposte fornite dai soggetti ai questionari compilati al termine di ogni 
sessione di laboratorio. Lo scopo di questa analisi, è quello di verificare 
se il tool ha migliorato o meno i tempi e lo sforzo nelle fasi del processo 
  16 
di migrazione e se, in tutte quelle fasi in cui esso fornisce un supporto 
allo sviluppatore, c’è un effettivo appiattimento delle competenze tra i 
soggetti. 
Gli argomenti trattati in questa tesi, sono stati suddivisi in cinque 
capitoli ed una appendice: 
 
• Stato dell’arte: panoramica sulle tecniche e sulle strategie 
di migrazione presenti in letteratura con riferimento alle 
tecnologie a supporto delle stesse 
 
• Strategia ed architettura: presentazione dell’approccio, dei 
vincoli implementativi e dell’architettura di riferimento adottata 
 
• MELIS - un ambiente di migrazione: presentazione 
dell’ambiente intergrato sviluppato e descrizione delle 
funzionalità offerte a supporto della strategia di migrazione 
 
• Casi di studio: reale utilizzo di MELIS al fine di migrare le 
graphical user interface di due moduli di un sistema scritto in 
ACUCOBOL-GT 
 
• Un esperimento controllato: progettazione ed esecuzione 
di un esperimento controllato al fine di validare formalmente 
l’approccio ed il tool 
 
• Appendice: descrizione delle tecnologie utilizzate 
nell’implementazione dell’ambiente integrato e materiale di 
supporto fornito a corredo del plugin MELIS