Modernizzazione di Sistemi Legacy

R I A S S U N T O
La maggior parte dei sistemi informatici attualmente considerati mission
critical sono sistemi legacy realizzati e mantenuti tramite l’utilizzo di tec-
nologie ormai obsolete. Oggi esistono più di200 miliardi di linee di Cobol
equivalente all’80% del codice utilizzato a livello mondiale e sono in eser-
cizio applicazioni mainframe per un valore di 2 miliardi di dollari, con le
quali vengono gestite circa il 70% di tutte le transazioni eseguite a livello
mondiale. Le applicazioni legacy gestiscono ogni aspetto della nostra vita:
dai semafori stradali ai telefoni cellulari. Queste applicazioni portano con
se molti problemi. Sono difficili da mantenere e migliorare a causa della
carente conoscenza interna del sistema; rendono difficile l’innovazione poiché
la maggior parte delle risorse è impegnata nell’attività di manutenzione;
hanno costi di gestione molto alti, dovuti sia a questioni prettamente tec-
nologiche che di risorse umane: è sempre più difficile trovare personale
con le competenze adatte; infine sono generalmente caratterizzati da un
alto livello di complessità. Oggi le aziende hanno l’esigenza di restare com-
petitive nella recessione del mercato il che significa incrementare i servizi
senza aumentare i costi e perseguire l’agilità per permettere di stare al
passo con i processi di business: ciò risulta estremamente difficile quando
si deve fare affidamento su un’infrastruttura IT datata. In questo contesto
assume particolare importanza la modernizzazione, cioè l’applicazione di
quelle tecniche che permettono di intervenire su un sistema per adeguarlo
ai requisiti attuali.
Scopo di questo lavoro è stato mostrare caratteristiche, vantaggi e limiti
di un particolare strumento di modernizzazione di tipo black box, che non
indaga cioè il funzionamento interno del sistema. L’applicazione su cui la
modernizzazione è stata realizzata è scritta in Cobol, è in esecuzione su
ambiente CICS mainframe ed è accessibile tramite terminale 3270. Nonos-
tante l’applicazione sia ancora soddisfacente da un punto di vista fun-
zionale, essa presenta diverse problematiche in termini di usabilità, ac-
cessibilità ed efficienza operativa. Infatti anche se i programmi di emu-
lazione consentono agli operatori di eseguire l’applicazione su un normale
computer, rimangono comunque i problemi di usabilità legati all’utilizzo
della vecchia interfaccia testuale, che rende le operazioni di inserimento, ac-
cesso e ricerca dei dati difficoltose e caotiche. Per questi motivi il revamp-
ing dell’applicazione, cioè la creazione di una nuova interfaccia grafica,
è risultata essere la scelta di modernizzazione più appropriata. A tale
scopo è stato utilizzato uno strumento di sviluppo agile per il disegno
e l’implementazione di applicazioni web, WebRatio, il quale fornisce un
ambiente integrato basato sul linguaggio WebML; il suo approccio model
iii
driven permette di velocizzare e semplificare in modo considerevole la
fase di implementazione. Al fine di rendere WebRatio uno strumento spe-
cializzato nel revamping è stato integrato con una particolare libreria, la
w4bms, che implementa il concetto di screen scraping, cioè un mapping
tra le mappe BMS (le “schermate” dell’applicazione legacy) e le pagine
web dell’applicazione modernizzata.
Questo tipo di modernizzazione ha portato a risultati estremamente pos-
itivi. Per quanto riguarda la fase di sviluppo ha reso possibile il riutilizzo
di gran parte dell’applicazione legacy e ha quindi permesso di mantenere
bassi i costi e limitato il rischio. Il fatto poi che WebRatio sia uno stru-
mento di modellazione di facile utilizzo ha consentito al personale abitu-
ato a lavorare con tecnologie legacy di conoscere e imparare nuovi stru-
menti tipici del web. I miglioramenti in termini di usabilità sono stati di-
mostrati tramite l’utilizzo di opportuni test con utenti. Tali miglioramenti
si sono tradotti in una maggiore efficienza ed efficacia nell’utilizzo da parte
dell’utente finale, oltre che ad un più alto livello di soddisfazione e quindi
di produttività. Infine la realizzazione dell’interfaccia web ha permesso
all’applicazione di essere utilizzabile attraverso differenti strumenti e da
persone affette da disabilità percettive o cognitive. Durante la fase di mod-
ernizzazione non sono mancati i problemi, legati sia al tipo di moderniz-
zazione che allo strumento. I primi dipendono dal fatto che il revamping
non permette di modificare la logica interna dell’applicazione e quindi i
problemi che facevano parte della logica interna dell’applicazione legacy
sono ancora presenti in quella modernizzata. I secondi riguardano invece
i limiti in termini di personalizzazione che è possibile effettuare. La forza
di WebRatio e della w4bms sta nel fatto che essi sono strumenti basati su
una modellazione concettuale che permette di gestire un certo numero di
situazioni: grazie a ciò si hanno tempi di sviluppo brevi, costi bassi e ris-
chio limitato. Questo però significa che i requisiti dell’applicazione che non
ricadono dentro allo standard previsto dallo strumento sono difficili da ge-
stire ed estremamente costosi poiché richiedono una personalizzazione su
misura.
In conclusione l’accoppiata WebRatio w4bms è risultata essere un ottimo
strumento per la modernizzazione di applicazioni legacy 3270 nel caso in
cui i problemi siano legati esclusivamente all’usabilità e all’accessibilità e
non si rendano necessarie particolari personalizzazioni.
iv
1
I N T R O D U Z I O N E
Chiunque sia vissuto intorno alla fine degli anni ’90 ricorderà la grande
paura che aleggiava attorno alla presunta catastrofe del millennium bug. Il
problema nasceva dal fatto che in molti sistemi informatici l’anno veniva
rappresentato con due sole cifre e quindi con il passaggio al nuovo mil-
lennio i calcolatori avrebbero pensato di essere nel 1900 a causa della con-
trazione in 00, portando a conseguenze impredicibili.
Le radici di questo problema affondano negli anni 60 quando uno dei
maggiori problemi nell’ambito IT era quello della scarsa capacità di memo-
rizzazione dei dati. Uno dei metodi più utilizzati per risparmiare memoria
era quello di accorciare la lunghezza dei campi delle date nei programmi:
ciò veniva fatto appunto mediante la contrazione dell’anno e permetteva
di risparmiare 2 byte per occorrenza. Di per se un tale risparmio potrebbe
sembrare insignificante ma bisogna pensare che i campi con le date erano
molto frequenti e all’interno della stessa applicazione potevano ricorrere
centinaia se non addirittura migliaia di volte. Si pensi ad esempio ad un
file che contiene la lista di impiegati di una grande azienda e supponiamo
che per ogni impiegato si voglia memorizzare l’informazione circa la data
di nascita, di assunzione, quella del previsto pensionamento e di eventu-
ali promozioni. O ancora si pensi all’industria delle automobili e a quella
aerospaziale dove è necessario tenere traccia delle milioni di parti associate
ad un particolare modello di macchina o di aeroplano: ogni modello ha dei
campi che riguardano la data di costruzione, di installazione, di durata, di
sostituzione e molti altri ancora. Si capisce quindi perché una riduzione
di soli 2 byte per data significhi nella realtà pratica un risparmio ben più
grande.
Durante quegli anni i programmatori non si preoccupavano delle con-
seguenze dovute all’utilizzo di tale sintassi poiché di certo non si aspetta-
vano che i loro programmi sarebbero stati ancora in esecuzione 20, 30 o
addirittura 40 anni dopo. Negli anni ’60, quando questi programmi veni-
vamo sviluppati, l’industria dell’IT era ancora agli albori e da allora il
mondo dell’informatica è rapidamente mutato: sono nati nuovi metodi di
sviluppo del software come la programmazione strutturata, i database re-
lazionali, i linguaggi di quarta generazione e la programmazione a oggetti.
Si pensava che attraverso questi nuovi strumenti si sarebbero potuti imple-
mentare nuovi programmi, più efficienti e funzionali, che sarebbero andati
a sostituire quelli vecchi. Quello che non si era ancora realizzato era che
le applicazioni sarebbero cresciute così tanto in complessità, grandezza e
importanza da renderne complicata se non impossibile la sostituzione. Il
3
4 introduzione
risultato di ciò fu che un gran numero dei programmi sviluppati negli anni
60 era ancora in esecuzione alla fine degli anni 90.
Tutto ciò rappresentava il fulcro del problema quando, con l’arrivo del
nuovo millennio, l’anno2000 sarebbe stato interpretato dalla maggior parte
dei sistemi legacy in maniera erronea, causando black out o altri risultati
impredicibili. Fu attuato quindi una massivo sforzo di correzione. Alcune
industrie come banche e compagnie aeree spesero diversi anni per correg-
gere il loro software e per garantire il corretto funzionamento dei sistemi
entro il 1 gennaio del nuovo anno. Si stima che i costi per la gestione del
millennium bug, tra prevenzione e correzione postuma, furono molto alti
e si aggirarono intorno ai 300 bilioni di dollari.
Ci furono comunque anche dei lati positivi. In questo periodo, ad es-
empio, molte aziende furono costrette a stilare un inventario delle appli-
cazioni su cui dovevano essere attuate le correzioni: durante questa fase si
accorsero che molte di queste non supportavano più le attività di business
e addirittura non venivano più utilizzate e fu quindi possibile eliminarle
dagli asset aziendali permettendo una notevole riduzione dei costi.
1.1 il problema
Il caso illustrato non rappresenta un’eccezione ma è altamente esemplifica-
tivo della situazione in cui si trovano oggi la maggior parte delle aziende:
sono costantemente spinte da diversi fattori ad intervenire sui propri sis-
temi che però sono diventati negli anni complessi, difficili da mantenere
e impossibili da modificare. Nella maggior parte dei casi anche la sosti-
tuzione è diventata critica poiché tali sistemi racchiudono il core business
dell’impresa, cioè la conoscenza e l’esperienza accumulata nel corso degli
anni, e una sostituzione rischierebbe di comprometterne la conservazione.
E’ proprio a causa di questi motivi che negli anni sono stati introdotti
diversi approcci di modernizzazione, che servono a supportare il cambia-
mento di questi grandi sistemi laddove per diverse ragioni non è possibile
una sostituzione e la semplice manutenzione non è più sufficiente.
1.2 le domande di ricerca
Scopo di questa tesi è illustrare in quale modo oggi sia possibile risolvere
i problemi legati ai sistemi legacy. Le domande a cui si cercherà di trovare
una risposta saranno quindi:
• quand’è che un sistema non può più essere mantenuto e deve essere
modernizzato o sostituito?
• quali sono i tipi di modernizzazione disponibili e come si può scegliere
quello corretto per un dato sistema?
1.3 organizzazione dei contenuti 5
• quali sono gli strumenti a disposizione per la modernizzazione?
• come è possibile valutare se la modernizzazione ha raggiunto il suo
scopo, e il sistema è stato effettivamente rinnovato in termini di effi-
cienza?
1.3 organizzazione dei contenuti
La prima parte della tesi si occuperà di illustrare il ciclo di vita dei prodotti
software e dei sistemi, con particolare attenzione alle fasi che seguono il ri-
lascio degli stessi sul mercato. Si analizzeranno nel dettaglio le situazioni in
cui si rende necessario apportare delle modifiche, catalogandole a seconda
dell’invasività come parti dei processi di manutenzione, modernizzazione
e sostituzione. Si spiegherà quindi cosa caratterizza un sistema legacy, per-
ché diventa tale e in che modo la modernizzazione ne risolve i problemi.
Nella parte pratica si illustrerà il funzionamento di uno strumento ca-
pace di implementare il revamping, un particolare tipo di modernizzazione
black-box in cui si agisce solo sull’interfaccia del sistema. Infine si mostr-
eranno i risultati del lavoro attraverso l’analisi dell’usabilità e dell’accessibilità,
che metteranno in risalto i miglioramenti dell’applicazione web moderniz-
zata.
Di seguito si riporta la suddivisione degli argomenti per capitolo.
primo capitolo si spiegheranno le dinamiche evolutive del software
dal momento in cui viene rilasciato per la prima volta. Si spiegher-
anno quindi quali sono i motivi per cui si interviene sulle appli-
cazioni e quali sono i tipi di modifiche possibili nel contesto dell’ingegneria
del software. In particolare si vedranno i processi di manutenzione,
di modernizzazione e di sostituzione nel contesto dell’attuale letter-
atura.
secondo capitolo si descriveranno i sistemi legacy: si spiegherà per-
ché sono così importanti, perché è così difficile mantenerli e se ne
delineerà in breve la struttura.
terzo capitolo si spiegherà in modo approfondito cos’è la moderniz-
zazione, quali sono le diverse tecniche con cui è possibile attuarla,
come e quando può essere applicata ai sistemi legacy e in che modo
ne risolve i problemi. Si metteranno quindi in evidenza pregi e difetti
delle diverse soluzioni.
quarto capitolo descriverà un particolare strumento di modernizzazione
di tipo black-box, WebRatio, con particolare enfasi sul linguaggio di
modellazione su cui esso è basato: WebML.
6 introduzione
quinto capitolo presenterà una famiglia di applicazioni di tipo legacy,
quelle Customer Information Control System (CICS) a interfaccia tes-
tuale accessibili mediante terminali3270. Su un esempio di tale appli-
cazione, Soluzione Assegni RA (SARA) sarà effettuata l’analisi euris-
tica allo scopo di analizzare le problematiche in termini di usabilità
che rendono necessaria la modernizzazione.
sesto capitolo si introduce la libreria w4bms, necessaria alla customiz-
zazione di WebRatio per la realizzazione effettiva della moderniz-
zazione. Si mostrerà nel dettaglio cosa significa, in pratica, modern-
izzare con WebRatio.
settimo capitolo mostrerà i risultati ottenuti in termini di interfaccia
grafica con la modernizzazione. Si metteranno in evidenza i miglio-
ranti sia in termini di logica di navigazione che di layout.
ottavo capitolo attraverso il confronto in termini di usabilità tra la
nuova e la vecchia applicazione si mostreranno i risultati ottenuti me-
diante la modernizzazione. Inoltre si mostrerà come la nuova appli-
cazione web risponda anche ai requisiti di accessibilità previsti dalle
Web Content Accessibility Guidelines (WCAG).
nono capitolo sarà dedicato alle considerazioni conclusive.