Il trattamento dei legacy system

IL TRATTAMENTO DEI LEGACY SYSTEM
Antonio Massari, Massimo Mecella
1.
Introduzione ai Legacy System
1.1.
Cosa è un Legacy System
Secondo il Webster si definisce legacy “something of value received from an ancestor or
predecessor or from the past” (“qualcosa di valore ricevuto da un antenato o
predecessore o dal passato”). Quindi si assumerà la seguente definizione: un sistema
(applicazione) legacy è un sistema informativo (applicazione) di valore ereditato dal
passato. I concetti fondamentali sono appunto di valore (cioè critico per il business
dell’organizzazione) e ereditato dal passato (generalmente 5 anni o più, comunque già
operativo nel momento in cui lo si prende in considerazione).
I Legacy System sono anche definiti come “grandi sistemi software con cui non si
vorrebbe avere a che fare ma che sono vitali per l’organizzazione” [Bennet], “ogni
applicazione in produzione” [Schick] e “ogni sistema informativo che resiste alle
modifiche ed evoluzioni necessarie per tener dietro ai nuovi e mutevoli requisisti di
business dell’organizzazione” [Brodie].
Le caratteristiche fondamentali di un Legacy System sono:
q È un sistema fondamentale per l’operatività dell’organizzazione; inoltre spesso è
pesantemente utilizzato (migliaia di transazioni al giorno) essendo mission-critical e
dovendo quindi rimanere operativo al 100% e 24 ore su 24.
q Su di esso l’organizzazione ha pesantemente investito nel corso degli anni, e quindi
non può essere semplicemente accantonato così com’è.
q E’ enorme (centinaia di migliaia o milioni di linee di codice, distribuite su migliaia
di programmi).
q Spesso il suo primo nucleo risale ad oltre un decennio fa ed è quindi progettato
secondo vecchie concezioni.
q È scritto in linguaggio di vecchia generazione (COBOL, PL1 ed assembler).
q E’ supportato da un DBMS obsoleto (ad es. database IMS - Information
Management System - di IBM), sempre che esista un DBMS e non si faccia ricorso
al file system (file VSAM - Virtual Sequential Access Method).
q Le interfacce utente sono quelle a caratteri (terminali 3270 o 5250) e non GUI.
q Le applicazioni che lo compongono sono prevalentemente stand-alone, ognuna è
stato progettata e realizzata indipendentemente dal resto e quindi il sistema presenta
1
q
q
un’integrazione prevalentemente verticale e monolitica. Strutturalmente tale
software applicativo è tipicamente suddiviso in transazioni (una funzione utente
scritta in COBOL) usabili contemporaneamente da più utenti1 .
Non è ben documentato ed è difficile da comprendere, in quanto, quasi sempre, la
documentazione non è aggiornata con le modifiche che sono state via via apportate
al software.
Il sistema può essere considerato come un repository di anni di esperienza e pratiche
aziendali non esplicitamente documentate, ma presenti “immerse” nel codice stesso
del legacy.
Molte applicazioni sviluppate negli anni ’70 e ’80 possono essere senz’altro considerate
esempi di Legacy System. Si tenga presente, tuttavia, che le caratteristiche sopra
menzionate possono, in larga parte, essere manifestate anche da applicazioni di recente
realizzazione (in alcuni ambienti non sono rare affermazioni “estreme” del tipo “ogni
applicazione non Java è legacy” oppure “qualsiasi cosa che non usa l’OO od il Web è
legacy”).
Per dare una sensazione di quanto la problematica dei Legacy System sia complessa, e
vada spesso ben al di là di semplici considerazioni tecnologiche, si consideri un esempio
ricavato da una esperienza nella Pubblica Amministrazione. Il contesto è quello di un
Ente in cui il sistema informativo prevede un pool di tre mainframe con circa 30
ambienti CICS perfettamente funzionanti e che attualmente sembrano soddisfare le
necessità informative dell’Ente: si tratta di classiche elaborazioni transazionali originate
dai terminali 3270 dislocati presso sedi distribuite sul territorio italiano. Il numero dei
terminali è estremamente elevato e la operatività di questi deve essere preservata da
qualsiasi intervento sul sistema informativo/informatico. Contemporaneamente l’Ente ha
partecipato ad un progetto sperimentale mirato a rendere accessibili alcune informazioni
1
La struttura tipica di una transazione in ambiente gestionale prevede:
Gestione dei dati di I/O a video (mappe): trasferimento in aree di memoria, controlli
di congruenza, ecc.
Elaborazione dei dati: calcoli, preparazione degli output, ecc.
Gestione dei dati su memoria di massa: preparazione delle aree per l’I/O, operazioni
d’accesso, ecc.
La struttura del programma è fortemente influenzata dalle esigenze del TP Monitor
usato:
devono essere presenti precise dichiarazioni riguardanti i dati in memoria, sia per la
gestione dell’I/O da terminale che per quella dei dati negli archivi;
devono essere presenti le istruzioni di attivazione del TP Monitor e delle sue singole
operazioni;
per l’I/O non sono usate le istruzioni native del linguaggio di programmazione.
La struttura tipicamente è monolitica (operazioni concettualmente diverse non sono
collocate in parti diverse del programma) ed è scritta in un linguaggio ibrido (Es.
COBOL/CICS od assembler/IMS).
2
attraverso il paradigma DOC (Distributed Object Computing). Al di là dello specifico
progetto, è emerso che:
q Il Legacy System non è certo costituito dalla sola macchina mainframe con le
applicazioni, ma anche tutta la rete di migliaia di terminali, sparsi su aree
geografiche spesso assai vaste, che devono continuare a funzionare (altrimenti il
servizio al cittadino sarebbe interrotto con conseguenze gravissime) e verso i quali è
necessario garantire la compatibilità applicativa dei nuovi sviluppi. Se di colpo tutte
le applicazioni venissero sviluppate solo sui server e con le tecnologie più nuove, i
terminali non avrebbero modo di utilizzarle. Invece realizzando l’applicazione su
mainframe e contemporaneamente integrandola con le nuove tecnologie si riesce,
durante l’inevitabile periodo di transizione dal vecchio al nuovo, a far funzionare
entrambi.
q Quasi l’80 % del personale ICT continua a progettare e produrre sulla vecchia
architettura mainframe, in quanto il sistema rappresenta un investimento così
cospicuo che la sua dismissione (anche se fosse tecnicamente possibile) non sarebbe
economicamente giustificabile dal management dell’Ente. Questo significa che
qualsiasi nuova applicazione sia necessario sviluppare, essa viene realizzata tramite
un programma COBOL/transazione su mainframe, e solo successivamente essa
viene offerta attraverso un paradigma più moderno come la DOC. Le motivazioni
principali di ciò sono:
Ø i mainframe sono considerati ancora più robusti dei server (d’altronde per
sostituire un mainframe attualmente sarebbero richiesti pool di macchine/server
di fascia alta, ed i rispettivi sistemi operativi ancora non sono così “sicuri”
come quelli su mainframe);
Ø sul totale del personale ICT (all’incirca 400 persone) solo una piccola
percentuale è esperta nelle nuove tecnologie e metodologie (OO,
decomposizione dell’applicazione su tre livelli software, client/server,
piattaforma ed ambienti di sviluppo Windows, CORBA, ecc.), mentre il
restante personale è costituito da sistemisti MVS/CICS e programmatori
COBOL o assembler.
Questo per ribadire che quando si parla di Legacy System non bisogna pensare ad un
“dinosauro” morente, bensì ad un “dinosauro” vivo e vegeto, che per di più spesso trova
nella struttura organizzativa stessa nuova linfa per la propria sopravvivenza.
Ed è appunto per queste ragioni che in questo contesto vengono esposti i principi chiave
per il reengineering di ogni sistema/applicazione esistente.
1.2.
Il problema del Reengineering
Come accennato nei paragrafi precedenti i sistemi e le applicazioni legacy forniscano
servizi vitali per l’organizzazione. Inoltre molti sistemi legacy, contrariamente a quello
che si potrebbe supporre, presentano degli elevati livelli prestazioni e di affidabilità
3
(molti sistemi assembler/IMS-based trattano centinaia di transazioni al secondo,
un’utopia per molte applicazioni client/server).
Ciò nonostante i sistemi e le applicazioni legacy costituiscono un grosso problema per il
management IT di molte organizzazioni. Il problema nasce in quanto la manutenzione di
questi sistemi sta diventando sempre più lenta e costosa, queste applicazioni sempre più
spesso non soddisfano i requisiti di flessibilità dell’organizzazione e le nuove
professionalità tendono a specializzarsi su sistemi basati sulle tecnologie più innovative.
Appare quindi necessario, per una qualsiasi organizzazione che voglia rimanere
competitiva, affrontare il problema d’integrare i propri sistemi (Legacy System) con i
nuovi paradigmi e tecnologie.
Due sono le possibili scelte ad alto livello:
1. Application engineering. Sviluppare un nuovo sistema informatico dal nulla
(sviluppare un nuovo database ed un nuovo software).
2. Application reengineering. Riutilizzare qualcosa del sistema legacy (quello cioè che
è già presente ed attualmente funzionante).
Il termine reengineering viene usato con significati spesso differenti:
q Business Process Reengineering (BPR): conversione dei processi di business
[Hammer].
q Software Reengineering: conversione del software.
q Data Reengineering: conversione dei dati.
q Application Reengineering: conversione della forma di un applicazione, ma non
della funzionalità;
In alcuni casi si fa riferimento al termine Legacy Application Reengineering o, più
genericamente, trattamento dei Legacy System, per intendere una combinazione di
differenti approcci.
1.3.
Tipologie di Legacy System
Le applicazioni ed i sistemi legacy, da una prospettiva di trattamento, possono essere
classificate come:
1. Altamente decomponibili, sono ben strutturati e presentano alcune caratteristiche
fondamentali:
q I componenti applicativi sono separabili in logica di presentazione, logica
applicativa e logica d’accesso ai dati, cioè il software è decomposto in tre
livelli logici.
q I moduli applicativi sono indipendenti tra di loro (non ci sono
interdipendenze gerarchiche).
4
q
2.
I moduli applicativi hanno interfacce ben definite con i servizi di
database, quelli di presentazione e le altre applicazioni.
Data decomponibili, sono sistemi cosiddetti “semistrutturati” con le seguenti
caratteristiche fondamentali:
q I componenti applicativi sono separabili in due livelli: i servizi d’accesso
ai dati e quelli di presentazione e logica applicativa (fusi in un unico
blocco).
q I moduli applicativi hanno interfacce ben definite verso le altre
applicazioni.
In questi sistemi è possibile accedere direttamente ai dati, ma non alla logica
applicativa.
Presentazione
Presentazione
Presentazione
Logica
Applicativa
Accesso
ai Dati
Altamente decomponibile
(“Amichevole”)
Logica
Applicativa
Logica
Applicativa
Accesso
ai Dati
Data decomponibile
(“Trattabile”)
Accesso ai Dati
Program decomponibile
(“Trattabile”)
Presentazione
Logica
Applicativa
Accesso ai
Dati
Monolitico
(“Ostile”)
Figura 1 - Le differenti tipologie di Legacy System.
3. Program decomponibili, sono anch’essi semistrutturati
4.
con le seguenti
caratteristiche:
q I componenti applicativi sono separabili in due livelli: i servizi di
presentazione e quelli d’accesso ai dati e logica applicativa (fusi in un
unico blocco).
q I moduli applicativi hanno interfacce ben definite verso le altre
applicazioni.
In questi sistemi non è possibile accedere direttamente ai dati, ma è necessario
invocare delle funzioni predefinite (tipicamente una transazione). In questa
categoria rientrano la maggior parte delle applicazioni legacy.
Monolitici (non strutturati), sono sistemi in cui tutti i componenti appaiono come
un unico blocco in cui tutti i tre livelli logici sono fusi insieme. Generalmente a
questi sistemi si può accedere solo attraverso l’invocazione da terminale
5
Molte applicazioni in realtà hanno un’architettura che è una combinazione di queste
quattro. Dal punto di vista della facilità di trattamento, i Legacy System possono essere
distinti in:
q Ostili: sono quelli che non permettono la possibilità di interfacciamento con
l’esterno.
q Trattabili: l’interfacciamento con altri sistemi risulta possibile con un certo sforzo di
programmazione e tecnologie ad hoc.
q Amichevoli: l’interfacciamneto con l’esterno è facilmente fattibile.
È evidente che i sistemi del primo tipo sono amichevoli, quelli Data/Program
decomponibili risultano trattabili, mentre quelli dell’ultimo tipo rimangono ostili.
1.4.
Modalità di trattamento
Un sistema, sia esso legacy o meno, sia esso su mainframe o su hardware/software midrange (PC, workstation, server) viene, nel corso del suo ciclo di vita, sottoposto ad una
serie d’attività finalizzate al suo cambiamento ed evoluzione: assessment2 , manutenzione
e quello che si è chiamato trattamento.
Fino a poco tempo fa, la manutenzione era la sola attività operativa associata al
cambiamento ed all'evoluzione del sistema, che veniva costruito e poi aggiornato fino
alla sua sostituzione.
Ultimamente ha acquistato una notevole importanza il trattamento che può richiedere
una comprensione approfondita del sistema (software reengineering con approccio di
tipo white-box) o può limitarsi alle sole interfacce esterne del sistema (software
reengineering di tipo black -box)
2
Si tratta di valutare la strategia e gli obiettivi dell'organizzazione, quanto il sistema
sia ancora valido nel soddisfarli e decidere quindi un possibile intervento.
Quest'attività deve essere per successive approssimazioni con la possibilità di poter
terminare l'analisi quando è possibile raggiungere una conclusione valida: in altre
parole si tratta di una ricerca breadth-first, piuttosto che depth-first, nello spazio delle
informazioni relativo al sistema. L'analisi dei costi è fondamentale in questa fase: se
il costo dell'assessment e del successivo intervento è paragonabile a quello necessario
per risviluppare interamente il sistema da zero, probabilmente non conviene
continuare oltre.
6
L’approccio white-box richiede un reverse engineeering che enfatizzi una comprensione
profonda dei singoli moduli del sistema (program understanding3 ) ed attività di
riconversione.
L’approccio black-box si limita allo studio delle sole interfacce esterne del sistema e ad
attività di incapsulamento (wrapping).
Il reverse engineering è quel processo di analisi del sistema atto a identificarne le
componenti e le loro interrelazioni e a crearne una rappresentazione ad un più alto livello
di astrazione. A partire da questo si può pensare di sostituisce il sistema (attraverso una
sostituzione netta o gradualmente), riconvertendo il codice in nuovi ambienti,
riscrivendone alcune parti ed aggiungendone, in modo coerente, di nuove. Si tratta di un
processo lento, assai specialistico, costoso, con alti rischi e che richiede competenze
disparate.
Il wrapping evita la comprensione della struttura interna del sistema, costruisce dei
"bozzoli" software intorno a quelle unità che funzionano bene ed hanno interfacce ben
definite. Il wrapping, coerente con i principi Object Oriented, in particolare con quello di
incapsulamento ed information hiding, richiede un minore impegno del reverse
engineering e della successiva riscrittura.
Assessment
Necessità del
Cambiamneto
Sistema Esistente
Manutenzione
Trattamento
Black box
White box
Figura 2 - Le attività finalizzate al cambiamento di un sistema esistente.
3
Il program understanding consiste di una serie di attività rivolte a recuperare la
struttura e la documentazione ormai persa del sistema, così da avere una base con cui
iniziare le successive attività. Esso modella il dominio, estrae informazioni dal
sistema usando meccanismi appropriati e creando astrazioni che aiutino nella
comprensione delle strutture risultanti. Gli output dovrebbero essere la
ridocumentazione dell'architettura di sistema e della struttura dei programmi, ed il
recupero del disegno originario.
7
Gli approcci possibili per trattare un Legacy System sono allora:
q Ignorare: escludere il sistema da ogni successivo sviluppo.
q Sostituzione a taglio netto: riscrivere il sistema da zero.
q Migrazione graduale: trasformare il sistema gradualmente.
q Integrazione: consolidare il sistema nelle future applicazioni senza modificarlo ed
effettuare del wrapping con tecnologie ad hoc.
Tra questi si può fare una prima distinzione a seconda che l'obiettivo finale sia la
sostituzione del sistema con uno nuovo, o il mantenimento di gran parte dello stesso,
opportunamente adattato (integrazione).
Fino a qualche tempo fa l'unica possibilità era la sostituzione, che poteva essere
implementata in un unico passo (sostituzione a taglio netto) od in modo incrementale
(migrazione): in ogni caso l'obiettivo per entrambi gli approcci era un nuovo sistema che
riproducesse ed estendesse le funzionalità ed i dati del vecchio.
Ultimamente si sta diffondendo una procedura differente, che può essere in parte
considerata come un'evoluzione dell'approccio di sostituzione incrementale, basata
sull'idea del leverage legacy (far leva sulle cose ereditate dal passato): l'integrazione del
Legacy System, che si basa sulle tecnologie abilitanti della DOC e sul concetto di
wrapping4 .
4
In letteratura non si trova comunque una nomenclatura sistematizzata di tutti questi
approcci, per cui ci si può frequentemente imbattere in Autori che usano il termine
integrare per indirizzare la problematica in tutta la sua generalità, ovvero il termine
migrare con sfumature differenti. Nel contesto di questo capitolo si userà il termine
trattamento quando si vuol indirizzare la problematica generale, il termine
migrazione per indicare una sostituzione incrementale ed il termine integrazione per
indicare il nuovo approccio che non prevede la rottamazione del sistema ma il
riutilizzo di sue larghe parti oppurtunamente wrappate. Spesso a questi vengono
affiancati molti altri approcci, tanto che alla fine risulta difficile distinguere l’uno
dall’altro. Ad esempio uno di questi è il revamping, che consiste in operazioni di
ripulitura della parte esterna del sistema, e quindi
dell’interfaccia utente;
quest’intervento spesso è legato alla necessità di ricondursi a GUI. In generale il
revamping lascia il più possibile inalterato il cuore del sistema, limitandosi a creare
interfacce più gradevoli e friendly. Oppure talvolta può essere utilizzato un
DataWarehouse, che raccogliendo tutti i dati presenti nel sistema crea un database
integrato a cui accedono le nuove applicazioni.
8
Legacy System
utilizza
trattamento
reverse e/o
reengineering
sostituzione
sostituzione a
taglio netto
integrazione
migrazione
(sostituzione
incrementale)
utilizza
wrapping
Figura 3 Un quadro riassuntivo delle possibilità con cui trattare un Legacy System.
2.
Il trattamento dei Legacy System
2.1.
Manutenzione
Per manutenzione si intende il complesso delle operazioni necessarie a conservare la
conveniente funzionalità, efficienza e modificabilità del sistema. La manutenzione è un
elemento strategico per il software, e ancora oggi, nonostante il miglioramento dei
processi produttivi, rappresenta oltre il 70% della spesa per i sistemi informatici; inoltre
una manutenzione non strutturata e caotica porta al rapido degrado di un sistema, e
quindi alla sua totale ingestibilità (accelera il diventare legacy di un sistema).
La manutenzione ha tutta una serie di problematiche, dovute principalmente al fatto che
è estremamente complicato capire il software realizzato da altri (in funzione inversa alla
quantità di documentazione) e che l’autore del software in genere non è disponibile per
collaborare alla risoluzione del problema. Inoltre, soprattutto nel caso di sistemi molto
9
vecchi, la documentazione spesso non esiste o è fortemente inadeguata5 , ed i criteri di
progettazione del software seguiti (spesso semplicemente dei criteri “spontanei”) non
tengono conto della caratteristica di modificabilità: un “programma”, o meglio ciò che
rappresenta oggetto di possibile modifica al più basso livello di astrazione, dovrebbe
essere comprensibile anche a chi non ha partecipato alla sua creazione.
Generalmente in letteratura si distinguono vari tipi di manutenzione:
q Correttiva: serve per la rimozione di difetti (un difetto genera un comportamento del
sistema diverso da quanto stabilito dalle specifiche o errato perchè le specifiche
sono inadeguate). Tale tipo di manutenzione è fondamentale perchè un qualsiasi
software, anche il miglior progettato, presenta degli errori.
q Adeguativa: il suo fine è l’adeguamento del sistema ai mutamenti intervenuti
nell’ambiente tecnico a livello infrastrutturale o tecnologico (cambio di DBMS, o di
versione del sistema operativo, ecc.).
q Migliorativa: serve a migliorare principalmente gli elementi che servono a
soddisfare i requisiti non funzionali (prestazioni, uso di risorse, manutenibilità,
ecc.).
q Evolutiva: il suo fine è di migliorare il sistema dal punto di vista dei requisiti
funzionali di natura non essenziale (ovvero gli obiettivi primari della applicazione e
le sue caratteristiche tecnologiche di base rimangono inalterate)6 .
Talvolta si parla anche di manutenzione Preventiva per riferirsi ad interventi, periodici o
derivanti da determinati eventi, finalizzati ad evitare il degrado del sistema (esecuzione
casi di test, “quadrature”7 , ecc.) o per evitare i malfunzionamenti che possono intervenire
a fronte di nuovi “run” di una procedura; essi possono implicare la produzione di
software ad hoc.
5
6
7
In particolare la documentazione deve essere realmente utilizzabile, quindi deve
essere disponibile un modo per renderla “navigabile”, ovvero per capire dove trovare
le informazioni di volta in volta di interesse, tenendo conto che l’utilizzazione delle
informazioni risponde caso per caso a logiche diverse; inoltre le informazioni devono
essere coerenti.
Alcuni Autori considerano un solo tipo di manutenzione (Perfective) che include la
Migliorativa e l’Evolutiva. Inoltre spesso le prime tre vengono riassunte nella
dicitura "manutenzione MAC".
Una quadratura è la verifica che esistano congruenze, soprattutto a livello di dati, tra
gli output dello stesso sistema ovvero tra output di sistemi diversi ma collegati.
10
Manutenzione
Migliorativa
Adeguativa
Correttiva
Evolutiva
Manutenzione MAC
Figura 4 - Una classificazione delle tipologie di manutenzione.
In generale si può dire che la manutenzione è la base di tutti gli interventi che si possono
operare su un sistema, sia perché la velocità con cui esso tende a diventare legacy
dipende molto dall’adeguatezza e qualità del processo di manutenzione, sia perché
spesso diventa poi difficile dare una chiara separazione tra intervento di manutenzione e
di altro tipo8 . In linea di massima si può assumere che si è in presenza di manutenzione
quando, nonostante le modifiche, il sistema rimane strutturalmente costante e continua a
giocare lo stesso ruolo nell’ambito del contesto d’uso.
Nonostante le metodologie e gli strumenti resi disponibili dall’Ingegneria del Software,
mediamente i costi della manutenzione9 stanno crescendo, in termini percentuali, rispetto
a quelli dello sviluppo, sia perchè i sistemi sono sempre più grandi e complessi, la base
di sistemi obsoleti si ampia sempre di più, ecc., sia per cause meno ovvie, ad esempio
proprio la disponibilità di tool di alta produttività a disposizione di un’ampia base
produttiva (come i 4GL) provoca la frammentazione della produzione e quindi un minor
controllo da parte di unità centralizzate.
8
Alcuni talvolta vedono il reverse engineering come un intervento di manutenzione
perfective, ed addirittura il wrapping può essere visto come un tipo di manutenzione
evolutiva (proprio perchè non agisce profondamente sulla struttura del sistema).
9
Se il costo di sviluppo di una LOC (Line Of Code, è un’unità di misura con cui
valutare la dimensione e consistenza di un prodotto software) è $25, il suo costo di
manutenzione è valutato $1000.
11
Sviluppo
60%
40%
Manutenzione
30%
40%
60%
70%
1970s
1980s
1990s
Figura 5 - L’evoluzione dei costi della manutenzione.
Alcuni fattori influenzano negativamente i costi di manutenzione:
q età del sistema;
q dimensioni;
q complessità dei programmi;
q volatilità dell’applicazione;
q carenza di documentazione;
mentre altri hanno una influenza positiva:
q l’uso di tecniche strutturate o formali;
q la presenza di una metodologia di sviluppo e quindi di una documentazione standard
e controllata;
q la disponibilità di casi di test (per effettuare i test di regressione dopo l’intervento);
q l’utilizzo di tool automatici
q la presenza di un buona concezione di database administration;
q l’esperienza dei manutentori;
q la natura degli strumenti tecnologici utilizzati (a partire dai linguaggi di
programmazione);
q la “pulizia” del codice.
Oltre ai costi diretti, la manutenzione implica un insieme di costi indiretti:
q i nuovi sviluppi devono essere rimandati o ritardati ed in genere perturbati perchè le
risorse sono impegnate nel mantenere qualcos’altro o perchè l’intervento deve
essere realizzato dallo stesso gruppo che ha costruito l’oggetto da modificare;
q il tempo di attesa per un intervento è sempre troppo lungo per l’utente e quindi si
può generare disaffezione verso il sistema;
q le probabilità di introdurre errori latenti con l’intervento sono altissime.
12
Quanto all’incidenza, il tipo di manutenzione che risulta di maggior costo è chiaramente
quella migliorativa, seguita da quella adeguativa, ovvero quei tipi di manutenzioni che
possono rendere necessari gli interventi potenzialmente più “pericolosi”.
4% Altro
21% Adeguativa
50% Perfective
25% Correttiva
Figura 6 - L’incidenza sui costi dei vari tipi di manutenzione.
2.2.
Reverse Engineering
Nonostante l’importanza della manutenzione, per molti anni l'Ingegneria del Software si
è concentrata soprattutto sullo sviluppo di nuove applicazioni: molta ricerca e sforzi
industriali sono stati e sono tuttora investiti nel creare nuovi e più efficienti processi di
sviluppo del software, per aumentare la qualità delle applicazioni, per ridurre il time-tomarket ed ovviamente per sviluppare sistemi che realmente soddisfino la domanda dei
clienti.
La pressione del mercato ha portato a cicli di prodotto estremamente brevi, col risultato
che molto del software rilasciato (soprattutto quello che si potrebbe definire "di massa")
non entra in realtà mai nella fase di manutenzione, ma è sostituito dalla nuova release.
Anche ammettendo che questo sia possibile, le grosse organizzazioni non possono
sostituire i loro sistemi senza un'accurata analisi: queste applicazioni legacy contengono
una grande quantità di informazioni e conoscenza, implicite e non documentate, sul
particolare dominio applicativo; inoltre, come già sottolineato, la manutenzione di questi
sistemi è critica e fondamentale.
13
La maggior parte degli scopi del Reverse Engineering sono legati alle seguenti
problematiche:
q Recuperare l'informazione persa e fornire un'adeguata documentazione del sistema:
significa sia sviluppare documenti mai esistiti (esso fu sviluppato quando non si
applicavano metodologie) che recuperare quelli che si sono persi negli anni. Questo
recupero è fondamentale se sul vecchio sistema devono agire progettisti che non
parteciparono alla sviluppo (cosa ormai frequente dato che i sistemi più vecchi
cominciano ad avere oltre 30 anni). Le tecniche di reverse engineering forniscono i
mezzi per recuperare le informazioni e sviluppare rappresentazioni alternative del
sistema.
q Assistere il processo di manutenzione.
q Migrare ad un'altra piattaforma hardware/software od integrazione in un ambiente
CASE10 : in particolare integrare il sistema in un ambiente CASE richiede la
costruzione di un repository per descrivere gli elementi e la struttura del sistema,
così come le interrelazioni.
q Facilitare il riuso: fornendo una documentazione adeguata del sistema, si
identificano nello stesso i componenti riusabili.
In letteratura il termine Reverse Engineering assume molte sfumature differenti, che lo
rendono quasi una disciplina onnicomprensiva di tutto quello che può riguardare il
vecchio software.
Per inquadrare meglio le specifiche problematiche, di seguito vengono date alcune
indicazioni basate sulle definizioni IEEE:
q Restructuring: consiste in una trasformazione della rappresentazione di elementi di
un sistema (soprattutto il codice) mantenendola allo stesso livello d’astrazione – ad
esempio riscrivere il codice in modo da usare convenzioni per le variabili,
trasformare una sequenza di espressioni in una funzione, aggiungere commenti,
trasformare codice non strutturato in procedurale, ecc. - . E' più simile ad una forma
di manutenzione migliorativa e non sempre aumenta la comprensibilità del sistema.
q Design Recovery: ricostruzione di una visuale astratta (e/o di una documentazione
strutturata della progettazione) di un sistema software a partire da informazioni e
documenti a vari livelli di astrazione.
q Program Comprehension: processo teso ad individuare l’associazione tra
componenti software (a vari livelli di granularità) e le componenti del dominio
applicativo, da esse implementate.
10
Computer Aided Software Engineering: si tratta di strumenti di ausilio allo sviluppo
di sistemi complessi e di supporto in tutte le successive fasi del ciclo di vita (ad
esempio tool per l'analisi Object Oriented, per la rappresentazione con diagrammi ER
dei dati, generatori semiautomatici di codice a partire da una descrizione formale,
ecc. ).
14
Livello di
astrazione
Reengineering
+
Ristrutturazione
Reverse
Engineering
Figura 7 - I concetti di Restructuring, Reverse Engineering e Reengineering.
q
Reverse Engineering: processo di analisi del sistema per identificarne le componenti
e le interrelazioni e crearne una rappresentazione ad un più alto livello
d'astrazione11 . Esso comprende l'estrazione degli elementi di design del sistema, ma
non comprende la modifica o la generazione di un nuovo sistema. Poiché i candidati
al Reverse Engineering sono spesso sistemi privi di documentazione, quasi tutto
deve essere derivato dal codice sorgente, e per alleviare il noioso lavoro degli
esaminatori esistono efficienti tool di supporto che estraggono le informazioni
derivabili. Ultimamente si sta diffondendo un approccio ibrido che combina
l'assistenza dei tool automatici con la conoscenza ed esperienza umana quando il
mezzo automatico raggiunge i propri limiti.
Esistono due tipologie principali d’approccio al problema del Reverse Engineering:
q reverse funzionale, che mira alla ricostruzione globale del sistema trattato;
q data reverse, che considera solo la base dati del sistema, trascurando la parte
funzionale.
Il reverse funzionale utilizza, come fonte principale della conoscenza, il codice sorgente
dell’applicazione oggetto dell’intervento; ha come obiettivo la ricostruzione delle
funzionalità del sistema e della loro interazione con i dati; è più completo ma di più
11
Legato da vicino a questo termine (e talvolta usato come sinonimo nel caso di grossi
sistemi) è quello di Architecture Recovery. Un'architettura sw è una descrizione dei
moduli del sistema e delle loro relazioni; i tratta comunque di una nuova area di
ricerca, e quindi non esistono definizioni largamente accettate, se non che bisogna
considerare tre elementi fondamentali: componenti, connettori e le regole.
L'Architecture Recovery è quel processo d'identificare ed estrarre astrazioni di più
alto livello dai sistemi sw esistenti.
15
difficile realizzazione (le metodologie ed i tool sono poco maturi ed altamente
dipendenti dall’ambiente utilizzato).
Il data reverse utilizza invece, come fonte principale della conoscenza, le strutture
descrittive dei dati dell’applicazione oggetto dell’intervento; ha come obiettivo la
ricostruzione dei prodotti relativi alla base dati del sistema; trascura completamente la
parte funzionale, ma proprio per questo è un processo relativamente più semplice (le
metodologie ed i tool disponibili sono abbastanza maturi e con un buon grado
d’indipendenza dall’ambiente specifico). In generale i dati sono maggiormente da
salvaguardare (e quindi il data reverse è maggiormente studiato, utilizzato e forse,
considerato importante) proprio perchè sono maggiormente stabili e riusabili, mentre le
funzioni sono più dinamiche e volatili (dipendono dai processi dell’organizzazione,
ecc.).
Reverse
Funzionale
Data Reverse
Pic X(8).
SendTo()
Figura 8 - I due approcci al Reverse Engineering.
q
Reengineering: consiste nella trasformazione degli elementi di un sistema per
averne una rappresentazione ad un più alto livello di astrazione da utilizzare per
ricostruire il sistema migliorandolo (tenendo conto di altri requisiti).
Schematicamente, se si indica con forward engineering il normale processo di
progettazione di un nuovo sistema, si ha l'equazione:
reverse engineering + forward engineering = reengineering12
12
Da queste definizioni emerge come il reverse enginnering ed il reengineering siano
abbastanza coincidenti con quelli che nel capitolo precedente (basandosi si altri
Autori) sono stati chiamati software/data reengineering ed application reengineering.
16
2.2.1.
Limiti del Reverse Engineering
Il Reverse Engineering è stato un argomento "caldo" per molti anni; la migrazione dei
database basata sul Reverse Engineering dello schema dati è stata materia di ricerca da
ormai 20 anni.
È evidente che quest'approccio punta solo a comprendere il sistema, per di più a partire
dal solo aspetto tecnico, ma poi non prevede la sua modifica: al Reverse Engineering
deve seguire qualche attività (nel passato era la manutenzione e/o la riscrittura completa
del sistema) che migliori effettivamente il suo stato. In sostanza si tratta di un primo
passo, propedeutico, ma che talvolta richiede già da solo una spesa così elevata (nel caso
di grossi sistemi) da paralizzare le successive attività.
Gli approcci più moderni si occupano anch'essi di comprendere ed analizzare il sistema,
ma solo negli aspetti strettamente necessari, mai con un obiettivo così totalizzante come
la comprensione di tutti i moduli del sistema, e soprattutto con un'ottica più integrata che
tenga conto del contesto (non basta partire dal codice, bisogna considerare anche il
business e soprattutto il BPR, per comprendere se effettivamente alcune funzionalità
siano ancora necessarie: è inutile spendere risorse per analizzare moduli del sistema che
supportano processi che non hanno ragione di essere trasportati nel nuovo sistema).
Comunque questo non implica che il Reverse Engineering sia un approccio ormai
marginale, ma indica che esso da solo non è più sufficiente e soprattutto va integrato, sia
in scopi che in termini quantitativi, con gli altri approcci per aggredire il sistema.
2.3.
Due approcci impraticabili: Ignorare il sistema e la Sostituzione netta
L’approccio di ignorare il sistema non è praticabile nella realtà se non quando il sistema
automatizza dei processi aziendali separati dal core business (cioè copre delle aree di
nicchia) che si pensa di abbandonare in breve tempo. Attualmente (soprattutto negli
USA) stanno crescendo delle software house specializzate nella manutenzione di vecchi
sistemi; in questi casi ignorare il sistema equivale a darlo in outsourcing a tali
organizzazioni.
All’opposto dell’approccio sopra indicato si colloca la sostituzione netta. Per
sostituzione netta13 si intende la riscrittura del sistema legacy, utilizzando metodologie,
tecniche e tecnologie moderne, ed un approccio a taglio netto tra vecchio e nuovo, con
uno switch one - step (metaforicamente si potrebbe riassumere l'approccio dicendo che
13
Molti Autori americani chiamano questo approccio “cold turkey”, che tradotto in
italiano suonerebbe come crisi d’astinenza (quella provata da qualcuno che di colpo
smette d’utilizzare una droga, appunto il vecchio sistema).
17
"… un lunedì mattina l'organizzazione trova il nuovo sistema funzionante, e del vecchio,
usato fino al venerdì sera, non c'è più traccia …").
Questo approccio comporta però dei rischi sostanziali:
q
q
q
q
Le esigenze dell’organizzazione non stanno ad aspettare: lo sviluppo di un sistema
richiede anni, nel frattempo emergono nuovi bisogni informativi per
l'organizzazione ed in base ad essi il legacy viene modificato; è evidente che deve
modificarsi di pari passo anche il nuovo sistema. Il rischio è in questa continua
modifica durante lo sviluppo.
Esistono raramente delle specifiche: talvolta la sola documentazione per il sistema è
il codice stesso ed inoltre spesso tale codice è altamente specifico (per motivi di
performance) per la macchina su cui è o era destinato a girare; ne consegue che è
molto difficile ricostruirne le specifiche. Inoltre c’è il problema delle dipendenze
non documentate: inevitabilmente nel corso degli anni varie applicazioni, missioncritical o meno, si sono appoggiate al sistema per informazioni o servizi. Se questo
va riscritto sarebbe auspicabile reperire queste informazioni da qualche parte, per
non far saltare l’operatività di tante applicazioni al contorno; spesso non c’è una
chiara consapevolezza di ciò e l’individuazione è assai difficile.
Il Legacy System può essere troppo grande per interrompere il suo accesso ai dati:
molti sistemi devono essere operativi per il 100% del tempo, mentre il travaso dei
dati dal vecchio al nuovo sistema richiede settimane per essere attuato: spesso i dati
non solo devono essere travasati, ma anche ripuliti, controllati nella loro qualità e
convertiti per aderire al nuovo sistema; inoltre se il legacy dataserver non fornisce
funzioni di download, e l'accesso ai dati legacy deve avvenire attraverso il sistema
stesso, aumentando ancora di più il tempo di scaricamento degli stessi. Comunque si
tratta di tempi che non sono compatibili con le esigenze mission-critical
dell’organizzazione.
La gestione di grandi progetti è rischiosa: il vecchio sistema ha una dimensione tale
che costruire l’equivalente dal nulla corrisponde ad un progetto di grandissime
dimensioni. Progetti di tali dimensioni hanno probabilità altissime di fallimento
(vengono generalmente sottostimati molti fattori: la complessità di ripartizione del
lavoro, di formazione di nuovo personale di sviluppo e di gestione delle interazioni,
ecc. … - la cultura del Project Management non è ancora così diffusa e ben
applicata) e comportano quasi inevitabilmente grossi ritardi.
18
Durata
media
(in mesi)
Pianificata
< 100
Dimensioni del progetto (in function point)
100 – 1K
1K – 5K
> 5K
6
12
18
24
Effettiva
6
16
24
36
Ritardo
0
4
6
12
Figura 9 - Alcuni dati statistici sull’esito dei progetti software.
Alla fine prevale l’omeostasi: le paure e incertezze legate a questo approccio spesso
irrigidiscono le organizzazioni, facendo loro preferire un inefficace ma tranquillo Legacy
System.
E’ chiaro che al di là della semplice disquisizione teorica questo approccio è in realtà
impraticabile, tanto più in contesti altamente complessi (ad esempio la Pubblica
Amministrazione) in cui l'alto management non vuole, e non può, sacrificare
investimenti di decenni, non vuole reinvestire in nuovi sviluppi e contemporaneamente
vuole tutti i benefici delle nuove tecnologie distribuite e delle nuove architetture di
sistema.
2.4.
La migrazione
Una migrazione ha luogo tra un sistema esistente (source) ed uno nuovo (target), dove il
primo è un Legacy System ed il secondo è un sistema sviluppato secondo i nuovi
paradigmi e tecnologie. Esempi tipici consistono nel migrare da un sistema MVS-IMSCOBOL ad ambienti UNIX-C++-RDBMS o WindowsNT-SQLServer, ovvero
addirittura ad architetture client/server object oriented (DOC).
La migrazione è un processo altamente rischioso; molti progetti di migrazione in grosse
organizzazioni (tipicamente statunitensi) iniziarono nel biennio 1992/93 e nel 1995 quasi
l’80% erano fallite, nel senso che erano state ridimensionate, posposte od addirittura
completamente cancellate. La scelta di migrare deve quindi essere attentamente valutata
considerando che il nuovo sistema target costituirà il perno di tutta la futura strategia
aziendale a medio termine; solo con un commitment così forte lo sforzo di migrazione
può avere possibilità di successo; infatti spesso uno dei motivi del fallimento è il poco
supporto da parte del management, supporto che svanisce alle prime ed inevitabili
difficoltà.
Per condurre una migrazione sono possibili differenti strategie:
19
Migrazione parziale: solo una parte del sistema viene trasformata, tipicamente quella che
dà i maggiori problemi (alti costi di manutenzione, scarsa flessibilità, ecc.); questa è una
soluzione fattibile con rischi contenuti soprattutto per quei sistemi legacy che si sono
definiti amichevoli o trattabili; si agisce principalmente sulle interfacce utente o sui dati.
Migrazione
Completa
Parziale
dei Dati
Mainframe
Unplug
delle Interfacce
Spesso è solo
propedeutico ad
altri interventi
X
Figura 10 - Possibili modalità di migrazione.
Migrazione completa.
Mainframe unplug (ritiro): quest’approccio è valido per molte piccole e medie
organizzazioni, che decidono di passare da un mainframe di medie dimensioni a
piattaforme basate su AS/400 o server Unix. In questi casi sostanzialmente si prende il
sistema (cioè le applicazioni che lo costituiscono) e lo si ricompila con piccole
modifiche nel nuovo ambiente (questo processo è chiamato sliding o rehosting); esistono
buoni tool che supportano questo processo (ad esempio per passare da codice MVSCICS allo stesso codice per Unix-AIX). Chiaramente questo approccio è conveniente se
il sistema è già ben progettato (presenta livelli software con interfacce ben definite) e
l’obiettivo è quello di ottenere maggiori economie passando ad un hardware meno
costoso e sul quale sia poi più facile un intervento d’integrazione con le tecnologie DOC.
20
2.4.1.
Migrazione delle interfacce utente
Spesso il sistema ha bisogno solamente di presentarsi con un’interfaccia utente migliore:
non più quella a caratteri tipica dei terminali 3270, ma una GUI o meglio ancora
un’interfaccia Web accessibile da un browser. In molti casi infatti basta “mettere il
sistema su Internet” per ottenere già un notevole miglioramento per il business
dell’organizzazione (vantaggi economici in quanto si raggiungono nuovi clienti, se
l’organizzazione è un’azienda privata, ovvero maggiore offerta di servizi al cittadino se
si parla di PA). La tecnologia offre allora una serie di strumenti di middleware (spesso
proprietari) con cui diventa quasi immediato offrire con una nuova veste la vecchia
interfaccia sul Web; si tratta degli screen scraper14 e dei linguaggi di scripting15 .
Queste tecnologie non richiedono alcun intervento sul Legacy System (e quindi sono
applicabili a tutti i tipi di sistemi, anche quelli monolitici), ma soffrono di problemi di
prestazioni.
Chiaramente una scelta migliore è quella di sostituire l’interfaccia utente, riscrivendola,
ma questo è possibile solo nel caso di sistemi altamente decomponibili o program
decomponibili. Esistono comunque dei tool che, partendo dal codice sorgente della
vecchia interfaccia, aiutano nel processo di Reverse Engineering e di riscrittura della
nuova GUI.
Nella pratica, si adotta un approccio misto, per cui inizialmente, con lo screen scraping,
si offre subito la nuova interfaccia (verificandone anche l’accettabilità da parte
dell’utente – si fa cioè un prototipo) e nel contempo si comincia la riscrittura.
Alla fine del processo la vecchia interfaccia e lo screen scraper (che quindi si configura
come software “usa e getta” per il periodo della migrazione) verranno ritirate.
14
15
Lo screen scraping è un’estensione dell’emulazione di terminale: esso permette alle
applicazioni client di simulare la pressione dei tasti e la lettura/scrittura di posizioni
specifiche dello schermo, fornendo delle API per tali funzionalità. Allora il browser
Web (attraverso CGI) od il nuovo programma GUI chiamano lo screen scraper che a
sua volta invoca l’interfaccia utente del vecchio sistema.
I linguaggi di scripting, utilizzando l’emulazione di terminale, generalmente riescono
ad ottenere una certa flessibilità: inviano stringhe di comandi o testo, attendono la
risposta e si diramano a seconda dell’output restituito sullo schermo. I comandi del
linguaggio di scripting vengono interpretati in fase di run-time anzichè essere
precompilati, e questo garantisce la flessibilità, in quanto così l’applicazione client (e
non l’utente) riesce a guidare l’interfaccia d’emulazione. Due esempi di linguaggi di
scripting sono HLLAPI (High Level Language Application Programming Interface)
ed IBM REXX.
21
2.4.2.
Migrazione dei dati
La migrazione dei dati consiste nel trasferire i dati da un formato/piattaforma ad un altro.
Essa implica la soluzione di molti problemi:
q conversione (ad esempio da database non relazionale a relazionale);
q trasformazione (ad esempio creazione di viste o dati di sommario);
q spostamento (ad esempio da database su mainframe ad uno su UNIX);
q allocazione (ad esempio da un database centralizzato a più database distribuiti).
Selezione dei dati
(sul sistema source)
Trasformazione dei dati
(sul source e/o sul target
e/o in mezzo)
Trasmissione dei dati
(dal source al target)
Caricamento dei dati
(sul sistema target)
Figura 11 - Uno schema del processo di migrazione dei dati.
La migrazione dei dati in genere è più semplice di quella dell’applicazione, per cui
spesso i dati vengono migrati su un database server di cui la vecchia applicazione su
mainframe diventa “client”. Inoltre spesso tale database server viene utilizzato anche per
il DataWarehousing16 , nel caso che l’organizzazione abbia in progetto un intervento di
questo tipo.
16
Un DataWarehouse è una collezione di dati a supporto delle decisioni e delle analisi,
integrata, variabile nel tempo e non volatile (non è aggiornabile on-line, ma solo
attraverso procedure batch specializzate che fanno il data-sucking). Esso contiene
dati storici (in cui cioè l’elemento temporale è fondamentale) provenienti dai vari
database gestionali dell’organizzazione, sia aggregati sia al massimo livello di
dettaglio, ed è progettato non sulle esigenze di una specifica applicazione gestionale
(come i comuni database) ma sulle necessità informative di analisi e supporto alle
decisioni dell’alta dirigenza. Proprio per questo esso utilizza modelli ad hoc,
differenti da quelli comuni nei database gestionali (il più famoso di questi modelli è
22
Esistono varie tecnologie di supporto alla migrazione dei dati, di complessità, potenza e
disponibilità differenti:
q Database Unload/Reload Utilities: forniscono la possibilità di scaricare i dati in un
formato piatto (come un file sequenziale) che possa poi essere ricaricato dal
database target. Tutti i DBMS, compresi quelli legacy, offrono questa possibilità,
ma i rispettivi formati di fatto sono incompatibili tra fornitori differenti, o non
funzionano bene nel caso in cui il paradigma dei dati sia differente (gerarchico sul
source e relazionale sul target), per cui spesso è necessario scrivere codice di
supporto ad hoc.
q Tools di Conversione Automatica: tentano di automatizzare la conversione dei dati
da un formato ad un altro. Grandi sforzi, sia della ricerca che del mondo
commerciale, si sono orientati nella conversione dal modello IMS a quello
relazionale, per cui esistono tool per la migrazione da database IMS a DB2. Se è
necessario scrivere del codice, esistono dei generatori di programmi che partendo
dalle specifiche sul modello dei dati, sull’ambiente source e target, ecc. (fornite
tipicamente attraverso programmi GUI su workstation) producono i programmi
necessari in C o COBOL per molte tipologie di archivi. Questi tool sono molto
utilizzati anche nel campo del DataWarehousing, da cui nascono come idea.
q Data Propagators, Replication Servers e Gateways: considerato che la migrazione è
graduale nel tempo, forniscono dei servizi necessari durante il periodo di
transizione: trasparenza per le applicazioni su dove sia effettivamente allocato il
dato (sul source o sul target), sincronizzazione tra i due ambienti, trasparenza di
distribuzione nel caso che il database target sia distribuito, ecc. L’effettiva
disponibilità sul mercato è limitata e le funzionalità offerte spesso sono parziali, per
cui può essere necessario un pesante lavoro di sviluppo in proprio.
Comunque la problematica della migrazione dei dati non interessa solo il contesto del
trattamento dei Legacy System, ma abbraccia molti altri settori, primo fra tutti quello del
DataWarehousing e la disciplina delle Basi di Dati in generale.
2.4.3.
Migrazione completa
Una migrazione completa del Legacy System è un processo che può richiedere anni e
presentare rischi notevoli; proprio per questo l’approccio graduale mantiene
costantemente operativo il vecchio sistema e nel contempo sviluppa, con piccoli passi
incrementali, le varie porzioni del nuovo fino a che la sostituzione globale (obiettivo
pianificato a lungo termine) non venga raggiunta. Ogni passo richiede un impiego di
risorse relativamente basso (pochi anni-uomo e poco tempo): si produce così un piccolo
lo star-schema), e nella sua progettazione/costruzione sono fondamentali le
problematiche di analisi dei database sorgenti, della qualità dei dati, dell’unificazione
dei vari modelli logici/fisici, ecc.
23
risultato nella direzione dell'obiettivo (un incremento) ed un controllo del rischio, in
quanto se un passo dell’approccio graduale fallisce, deve essere ripetuto solo quello, con
spese decisamente più contenute e benefici per tutti i passi successivi ad esso correlati,
che non vanno rivisti, ma direttamente progettati in base ad una versione già corretta.
L’aspetto fondamentale per una migrazione graduale di successo è l’individuazione della
dimensione e indipendenza degli incrementi, la loro sequenzializzazione e correlazione.
2.4.4.
I gateways
La migrazione graduale seleziona e sostituisce parti del vecchio sistema per diventare
parti del sistema target incrementalmente costruito. Durante questo processo i due
sistemi formano un sistema composito, che complessivamente implementa le
funzionalità mission-critical. Nel sistema composito il source ed il target sono connessi
da un gateway, cioè da un modulo software introdotto tra i vari componenti operativi per
mediare tra di loro.
I ruoli fondamentali di un gateway sono:
q isolare determinati componenti dagli effetti dei cambiamenti sugli altri: un gateway
mantiene l’interfaccia che il source si aspetta da quel componente, anche se
quest’ultimo in realtà è stato modificato, oppure isola un componente che non è
stato modificato dal resto del sistema;
q traduttore di richieste e dati: il gateway traduce richieste, in un formato standard
offerto ai moduli superiori, nel formato opportuno a seconda che vengano servite da
moduli legacy o target;
q coordinatore tra componenti per mantenere la query ed update consistency: è
possibile che i dati o le funzioni che implementano l’interrogazione o
l’aggiornamento siano stati parzialmente o completamente decomposti in
componenti del source e migrati in componenti target; inoltre ci possono essere
copie replicate di dati e funzioni. Il gateway deve allora decomporre correttamente
la forma di accesso nelle sue sottoforme da presentare alla funzione o ai dati
opportuni e poi raccoglierne ed integrarne gli effetti con coerenza e consistenza; il
compito più difficile dal punto di vista della coordinazione riguarda gli
aggiornamenti e può essere dominato solo con tecnologie database avanzate. Poiché
pochi gateway commercialmente a disposizione sono prodotti sicuri da questo punto
di vista, spesso l'unica soluzione è sviluppare applicazioni special-purpose, una
volta individuato il problema nella specifica situazione.
Il posizionamento di un gateway è un fattore critico per la complessità di una
migrazione:
q database gateway: il gateway può essere messo tra i moduli applicativi ed i servizi
database, incapsulando l’intero database rispetto alle applicazioni;
24
q
q
application gateway: il gateway può essere messo tra lo strato di presentazione e il
resto del sistema;
system gateway: il gateway può incapsulare l’intero sistema.
In genere più in alto è posizionato il gateway più funzionalità deve incapsulare e più
risulta complesso.
Da un punto di vista strutturale un gateway ha due componenti fondamentali utili
durante la migrazione:
q i forward gateway permettono alle applicazioni legacy di accedere ai dati nella parte
già target del sistema;
q i reverse gateway permettono alle applicazioni target di accedere ai dati
nell’ambiente legacy.
2.4.5.
Architetture per la migrazione
I sistemi altamente decomponibili sono i più facili da migrare: ogni componente ha
interfacce ben definite e quindi può gradualmente essere sostituito durante il processo di
migrazione. Questo può procedere secondo due direzioni (od un misto delle due):
q Migrare il database legacy per primo, e successivamente migrare la logica
applicativa e quella di presentazione. Le tecnologie e le tecniche necessarie sono
sostanzialmente quelle utilizzate nel caso della migrazione parziale dei soli dati; il
gateway in questo caso è un forward database gateway.
25
Utente finale ed Applicazioni Esterne
Utente finale ed Applicazioni Esterne
Interfaccia Target
Interfaccia Target
Interfaccia Legacy
Interfaccia Legacy
Moduli Applicativi Target
Migration Gateway
Logica Applicativa Legacy
Moduli Applicativi Target
Migration Gateway
Logica
Applicativa
e
Servizio Dati
Legacy
Servizio Dati
Legacy
Target Database
Target Database
(a)
(b)
Utente finale ed Applicazioni Esterne
Migration Gateway
Interfaccia Target
Moduli Applicativi Target
Le differenti tipologie di gateway per
la migrazione:
(a)
database gateway;
(b)
application gateway;
(c)
system gateway.
Interfaccia
e
Logica
Applicativa
e
Servizio Dati
Legacy
Target Database
(c)
Figura 12 Posizionamento del gateway in una architettura per la migrazione
26
q
Migrare il database legacy per ultimo, dopo aver migrato la logica di presentazione
e quella applicativa. Questo caso è particolarmente valido quando la necessità
fondamentale è quella di offrire un’interfaccia più moderna e nuove funzionalità di
business, ovvero quando il database è troppo grande per essere migrato all’inizio. Il
gateway è allora un reverse database gateway.
Nella pratica vengono contemporaneamente usate entrambe le strategie, per cui in realtà
il gateway presenta funzionalità sia forward che reverse.
Le stesse strategie (anche se il passo di migrazione delle logiche applicativa e di
presentazione diventa più complesso) possono essere utilizzate nel caso di sistema data
decomponibile.
Invece se il sistema è program decomponibile (e questa è la stragrande maggioranza dei
casi concreti), il gateway deve incapsulare tutta la logica sottostante rispetto a quella di
presentazione, e si presenta come un application gateway. Due sono le strategie possibili:
q Migrare le logica di presentazione per prima (uso di reverse gateway);
q Migrare il resto del sistema per primo (uso di forward gateway).
Nel caso di sistemi monolitici, il gateway diventa un system gateway, attraverso cui
devono passare tutte le richieste d’accesso al sistema (sia utente che provenienti da altri
sistemi), ed esso le smista al nuovo od al vecchio sistema. Chiaramente questo tipo di
gateway è abbastanza complesso da costruire, così come questo caso è quello più
difficile e rischioso da affrontare.
2.4.6.
Un framework metodologico
La migrazione completa di un sistema è un’operazione molto vasta che richiede un
notevole impegno di risorse; ne segue che ogni sforzo deve essere opportunamente
calibrato.
Come prima cosa, nel disegno di un progetto di migrazione, va effettuata una riduzione
delle funzioni e dei dati da trasferire nel sistema target: molte funzionalità e dati ormai
vecchi, potrebbero non essere, o essere solo parzialmente, necessari per il nuovo sistema
informativo. Poiché il costo di una migrazione si può considerare esponenziale rispetto
alla dimensione del sistema, è essenziale contenere le spese ed i rischi riducendo il
materiale non critico per le esigenze aziendali. Queste considerazioni e la
semplificazione del sistema vanno ripetute per ogni passo incrementale della migrazione.
La progettazione globale deve essere effettuata senza alcun tipo di vincolo e in un certo
numero di passi: è impensabile che si possa progettare efficacemente in dettaglio una
27
migrazione che si realizzerà in anni di lavoro; qualsiasi cosa va realizzata
incrementalmente, anche il disegno.
Per guidare la migrazione, va comunque delineato un progetto generale, che non deve
scendere nei particolari per non diventare anacronistico rispetto alle esigenze informative
nel momento in cui si passa alla realizzazione; è ogni singolo incremento che deve essere
accuratamente disegnato. Il disegno dell’ambiente del target deve essere il più possibile
aperto e flessibile, per far sì che si possa, in futuro, cambiare qualsiasi cosa senza che si
abbia un impatto negativo sul sistema: è una esigenza che nasce dall’osservazione dei
continui cambiamenti del business. Ad ogni passo non viene completato il disegno
complessivo del sistema, ma piuttosto viene risviluppato un disegno di alto livello sulla
migrazione, che tiene conto dei nuovi aspetti emersi; si crea quindi un disegno di
dettaglio dell'incremento da migrare 17 .
Un aspetto importante del disegno globale è quello che riguarda la progettazione del
framework della migrazione: il source, il target ed il sistema composito, con la
convivenza delle componenti legacy e non. Vengono mappate in questa fase i vecchi
moduli in nuovi, dal punto di vista dell’ambiente, delle interfacce esterne, delle
applicazioni e dei servizi database.
Una proposta metodologica per gestire tutte queste problematiche è dovuta a Brodie e
Stonebraker18 . Il loro framework metodologico consta di undici passi che comportano
piccole migrazioni locali nella direzione prefissata e gestis cono un aspetto specifico: più
indipendenti sono questi passi, maggiore è la flessibilità del metodo rispetto alle
particolari esigenze informative e tecnologiche.
I gateway sono uno degli strumenti fondamentali della migrazione, poiché incapsulano
componenti che devono essere cambiati dietro interfacce standard (non da modificare).
Inoltre i passi non devono procedere necessariamente in sequenza: la loro successione
può cambiare, alcuni possono essere parallelizzati, altri possono essere fusi in un unico,
dipendendo dalle particolarità del sistema da migrare. Il framework è cioè estremamente
flessibile ed adattabile alle necessità dell'organizzazione.
Una possibile sequenza dei vari passi è riportata in Figura 1319 :
17
18
19
Ad esempio verrà progettato uno schema dati globale, fino al livello di repository
(data server, contenitori generici) o se necessario a livello di macroentità e qualche
relazione fondamentale.
Gli Autori la chiamano “chicken little in opposizione a quella del taglio netto detta
cold turkey.
Da notare che lo schema non è per l'intera migrazione, altrimenti sarebbe una
sostituzione netta, ma per ogni incremento: l'intero flusso viene ripetuto ad ogni
iterazione (anche se alcuni passi potrebbero essere tralasciati: ad esempio se viene
utilizzato un gateway general-purpose, esso serve per molti incrementi, e quindi si
può omettere il passo 7).
28
La riduzione dei rischi è uno degli obiettivi fondamentali della metodologia: da una parte
la si cerca fornendo un punto di ritorno sicuro per ogni passo, che non metta in pericolo
tutto il progetto, dall’altra il rischio stesso di ogni singolo passo va dimensionato
opportunamente.
Gli 11 passi della metodologia sono:
1. Analisi incrementale del Legacy System: è importante che si comprenda il sistema in
un giusto livello di dettaglio e si compiano progressi nell’approfondimento dei
requisiti lungo una specifica direzione prestabilita: procedere senza un obiettivo
preciso può paralizzare l’analisi. Spesso i requisiti iniziali sono ormai inesistenti o
non attuali, ed è necessario il più delle volte operare un reverse engineering per
ricostruirli, dopodiché in realtà si finisce per sviluppare le specifiche del vecchio e
del nuovo sistema informativo.
Inizio della migrazione
1.
2.
Analisi incrementale del Legacy System
Decomposizione incrementale
dell'architettura del Legacy System
3. Disegno incrementale delle interfacce
esterne del Target System
4. Disegno incrementale delle applicazioni
del Target System
5. Disegno incrementale del database del
Target System
6. Installazione incrementale dell'ambiente
del Target System
7. Creazione ed installazione incrementale
dei gateway
8. Migrazione incrementale del database del
Legacy System
9. Migrazione incrementale delle applicazioni
del Legacy System
10. Migrazione incrementale delle interfacce
esterne del Legacy System
11. Distacco incrementale verso il Target
System
1
3
5
4
6
2
8
9
10
11
Fine della migrazione
Figura 13 - Un piano di migrazione completa.
29
7
2.
Decomposizione incrementale dell’architettura del Legacy System: si effettuano
modifiche al sistema per assicurarsi che sia decomponibile; vengono quindi rimosse
le dipendenze tra i moduli, come le chiamate di procedura, e si ispeziona l’esistenza
di interfacce ben definite tra moduli e servizi database. Il costo di questo passo
dipende dalla struttura del vecchio sistema, e se non è possibile ristrutturarlo
possono comunque essere adottate e studiate varianti del metodo.
3. Disegno incrementale delle interfacce esterne del Target System: si effettua il
disegno e la specifica delle interfacce esterne (utente ed applicative) del nuovo
sistema con una effettiva pianificazione della migrazione delle stesse. Tipicamente
le interfacce esterne saranno eseguite sulle macchine client del nuovo ambiente
target.
4. Disegno incrementale delle applicazioni del Target System: le applicazioni che
vanno sviluppate per il nuovo sistema vanno progettate in base ai processi
dell’organizzazione ed a volte tagliate sulle vecchie applicazioni dopo una fase di
reengineering.
5. Disegno incrementale del database del Target System: si disegna lo schema entitàrelazioni del nuovo sistema basandosi sui risultati delle fasi precedenti e sulla
comprensione dei sistemi target e legacy. A meno che non si tratti di requisiti
insoliti, è bene poi mapparlo su un RDBMS basato sull’SQL. Questo passo può
essere anche molto comp lesso per via del codice legacy o dei requisiti delle
applicazioni: può essere difficile derivare la struttura dei dati legacy, tipicamente
distribuita su tutta l’applicazione.
6. Installazione incrementale dell’ambiente del Target System: si identificano i
requisiti dell’ambiente target sulla base dei requisiti globali, quindi si seleziona
l’ambiente stesso ed lo si testa in modo approssimativo per ricavarne informazioni
sulle performance ed altro. Dopodiché viene installato, possibilmente in un
ambiente distribuito, il che dovrebbe facilitare la costruzione di programmi GUI e
l’alleggerimento del codice distribuendolo opportunamente tra server e client.
7. Creazione e installazione incrementale dei gateway necessari: vengono sviluppati e
installati i gateway in base alle esigenze delle applicazioni (è probabile che si renda
necessaria la costruzione di più gateway) e tenendo conto delle funzionalità, della
posizione architetturale e dei requisiti non funzionali. A questo punto si presenta
l’alternativa del make or buy, dato che esistono diversi prodotti commerciali che
offrono alcune di queste funzionalità.
8. Migrazione incrementale del database del Legacy System: viene implementato lo
schema disegnato al passo 5 ed effettuata la migrazione del legacy database con
l’ausilio del gateway per supportare le chiamate delle applicazioni legacy. Questa
operazione comporta una notevole quantità di lavoro, che può essere affrontato
anch’esso incrementalmente, complicando le funzionalità del gateway.
9. Migrazione incrementale delle applicazioni del Legacy System: vengono selezionati
e fatti migrare uno o più moduli, secondo criteri tecnici ed organizzativi (semplicità,
costi, priorità), sviluppandoli in modo tale che possano interagire direttamente con il
nuovo DBMS.
10. Migrazione incrementale delle interfacce esterne del Legacy System: vengono
selezionate e fatte migrare una o più interfacce esterne. Se viene utilizzato un 4GL
30
per supportare lo sviluppo di interfacce utente ed applicazioni, la relativa
migrazione può essere coordinata e le interfacce esterne del Target System
gireranno direttamente su un ambiente 4GL/GUI, mentre le altre rimanenti
continuano a convivere con esse.
11. Distacco incrementale verso il Target System: il distacco (cutover) consiste nel
processo di switch dalle componenti del Legacy System alle corrispondenti del
Target System20 ; spesso è accompagnato da problemi di gestione della
configurazione e controllo della versione21 .
20
21
Un grande fattore di rischio per l’approccio del taglio netto è che il momento del
“varo” del nuovo sistema può essere drammatico se il sistema in realtà si presenta
non all’altezza della situazione. Nel caso dell’approccio graduale, invece, il cutover
viene attuato in modo incrementale, seguendo le singole esigenze locali del sistema.
In realtà ognuno dei passi descritti potrebbe avere una sua fase di distacco, ma la
dimensione e la complessità del Legacy System spesso giustificano un passo a parte
completamente dedicato alla coordinazione necessaria per il complesso lavoro di sostituzione delle componenti che coinvolge, per grandi organizzazioni, centinaia di
siti, centinaia di utenti, centinaia di moduli legacy e target riguardanti i database, le
applicazioni e le interfacce esterne. Si può pensare quindi ad una fase di distacco
separata dalle altre, realizzata essa stessa in modo incrementale, come pure può
essere una ottima scelta quella di procedere in parallelo tra la fase di distacco di
alcune componenti e quella di sviluppo di altre.
Il processo di migrazione richiede il controllo delle versioni più avanzate e la
gestione della configurazione del sistema composito, il che è evidentemente più
complesso rispetto al caso della realizzazione di un sistema ex novo: man mano che
la configurazione si evolve dal suo “stato” legacy a quello target, la gestione deve
adeguarsi abbandonando la concezione legata al vecchio sistema per affrontare quella
del nuovo con la continuità necessaria a gestire il transitorio.
E’ fondamentale che durante il processo di migrazione la gestione della
configurazione produca due essenziali risultati:
§ il controllo delle versioni di codice più avanzate sviluppate su piattaforme
multiple, considerando tutto il codice (dalle applicazioni, alle interfacce, al
linguaggio di definizione dei dati, a quello di manipolazione, etc...)
§ la produzione di documentazione di supporto per il sistema composito,
intendendo con questo che mentre i vari componenti evolvono separatamente la
documentazione per l’utente deve evolversi incrementalmente di pari passo.
31
2.5.
Integrazione
L'avvento della DOC promette, oltre di cambiare radicalmente il modo con cui
progettare i nuovi sistemi informativi, anche di cambiare l'approccio con cui fronteggiare
il trattamento dei Legacy System.
Le nuove enterprise architecture22 non considerano più, come nel passato, tanti diversi
sistemi informativi isolati (ognuno afferente ad una diversa unità dell'organizzazione)
che poi dovevano essere messi in comunicazione tra loro, ma tendono ad immaginare un
unico grande Sistema Informativo Distribuito (utilizzato, localizzato ed anche gestito in
modo non centralizzato): un unico grande organismo di cui gli equivalenti, vecchi o
nuovi, dei Legacy System costituiscono i vari organi.
22
Un’Enterprise Architecture costituisce un framework significativo all'interno del
quale i vari livelli dello sviluppo del sistema informativo dell'organizzazione
vengono considerati:
§ Business Architecture: prende in considerazione la strategia di business
dell'organizzazione, i suoi fini a lungo termine e gli obiettivi immediati,
l'ambiente tecnologico e quello esterno.
§ Information Architecture: è una mappa delle necessità informative basate sulla
business strategy (quest'ultima viene tradotta in una information system
strategy); essenzialmente è come un "progetto dell'edificio". Descrive il
contenuto, il comportamento e l'interazione degli oggetti di business; modella le
informazioni e le attività dell'organizzazione e fornisce l'astrazione nel dominio
di business; definisce i blocchi costituenti per lo sviluppo applicativo ed un
framework per i componenti informativi di business.
§ Data Architecture: serve a definire le necessità correnti e future per l'accumulo,
l'uso, il rinnovo, il mantenimento ed il trasferimento dei dati inter ed intra i
confini dell'organizzazione.
§ Application Architecture: definisce i servizi fondamentali richiesti per la
costruzione di soluzioni nel dominio di business: questi servizi forniscono
un'interfaccia astratta, business domain-oriented; i componenti dell'Information
Architecture vengono modellati in termini dei ruoli fondamentali e delle regole
di processamento sviluppati in questo livello.
§ Computer / Technical Architecture: riguarda l'hw/sw che costituiscono la base
tecnologica per i livelli superiori (ad esempio a questo livello si considera un
Legacy System come un modo potenziale per implementare i livelli superiori): la
scelte sono determinate anche dal mercato e dal budget, e le decisioni sul "make
or buy" vengono fatte a questo livello, anche se guidate da aspetti degli altri.
Talvolta gli ultimi livelli vengono accomunati nella complessiva System
Architecture.
32
In questo contesto assume minore importanza l'idea di sostituire il sistema legacy, poiché
anche se progettato con metodologie e tecniche moderne, il nuovo sistema tenderà a
riprodurre quello vecchio e quindi a rimanere un "organo".
La DOC è ora sufficientemente matura per supportare un approccio differente:
sottoporre i Legacy System a trasformazioni black box, cioè non modificarli, ma
attraverso tecnologie ad hoc, dette di contorno (mediatori), farne un object wrapping in
modo che il sistema presenti un'interfaccia ad oggetti verso il "mondo distribuito" in cui
vive. Questo è valido in quanto l'organizzazione moderna deve essere sempre pronta al
cambiamento, i tempi di migrazione/sviluppo dei sistemi non sono compatibili con
queste esigenze "frenetiche" (mentre il wrapping, una volta costruita l'infrastruttura ad
oggetti, è molto più rapido), i costi sono troppo alti, ed infine nella realtà le
organizzazioni non vogliono più spendere per i vecchi sistemi (anche un approccio
incrementale, per non parlare di uno studio completo di reverse engineering e di
rifacimento del sistema, ha un costo proibitivo rispetto a quello del wrapping).
sistema legacy
sistema target
sistema legacy
funzioni
funzioni
sistema composito
sistema target
sistema composito
tempo
tempo
(a)
(b)
Figura 14 - La differenza tra migrare (a) ed integrare attraverso il wrapping (b): con la migrazione
alla fine si giunge alla sostituzione completa del sistema, e si ha un sistema composito solo durante il
periodo di tra nsizione; con il wrapping non si sostituisce il sistema, e c’è un sistema comunque
composito.
Integrare significa usare il sistema ed i dati legacy nel più ampio contesto del business e
della sua architettura informativa. Il focus principale è il business, i processi, le
informazioni e come il vecchio sistema può contribuire ad implementare l'architettura
senza propagare le debolezze del design passato e dei metodi di sviluppo. L'integrazione
nasconde (incapsula) il sistema dietro interfacce consistenti che si riferiscono al
vocabolario/processi di business, nascondono i dettagli implementativi ed abilitano
(side-effect non sottovalutabile) anche successivi cambiamenti o sostituzioni senza
intaccare tutta l'architettura.
Obiettivo dell'integrazione è il far leva sulle informazioni e sul codice del Legacy
System durante lo sviluppo dell'enterprise architecture: il sistema deve essere in grado di
cooperare con gli attuali sistemi (altri legacy) e soprattutto con quelli di successiva
33
generazione. Predire il tipo ed il livello di cooperazione richiede all'organizzazione lo
sviluppo di un'architettura informativa nella quale il Legacy System è una risorsa,
disponibile sia durante il design che l'implementazione dell'architettura. Questa
disaccoppia e decompone il vecchio sistema nei suoi componenti service - based e
partiziona i processi di business in domini distinti ma cooperanti. Per ripartire il legacy è
necessario capire il contenuto semantico e gli usage pattern del sistema e quindi
implementare interfacce astratte che rendono questi due aspetti disponibili in altri
domini.
2.5.1.
Il wrapper
Il concetto di wrapper è abbastanza semplice: si tratta di un livello software che
nasconde l'implementazione effettiva delle funzionalità (che sono realizzate da uno o più
moduli di un'applicazione legacy in ambiente mainframe o server) e le presenta
attraverso un'interfaccia ben definita; quest'ultima è tipicamente ad oggetti, in modo che
all'esterno, cioè verso il nuovo mondo ad oggetti distribuiti, la vecchia applicazione
appaia sotto forma di uno o più oggetti, del tutto simili a tutti gli altri ed in grado, quindi,
di operare nello stesso ambiente, accettare messaggi dagli altri componenti e rispondere
in modo chiaramente definito.
In questo modo, poiché le applicazioni legacy implementano i processi fondamentali di
business, il wrapper ad oggetti alza il livello di astrazione al livello di oggetti di
business, permettendo una facile integrazione con il resto del nuovo sistema.
I requisiti di un buon wrapper sono:
23
q fornire la gestione del protocollo di connessione a differenti livelli ;
q ottenere la traduzione dei dati ed il processamento dell'informazione a differenti
livelli;
24
q implementare una qualche sorta di meccanismo di error detection/recovery ;
25
q gestire l'ambiente nativo del sistema legacy ;
23
24
25
Il wrapper deve connettersi al sistema legacy: questo significa aprire e gestire
differenti connessioni (che normalmente sono risorse platform - specific gestite dal
sistema operativo, come pipe, socket, file I/O stream) se il sistema comunica su
differenti interfacce. Inoltre il wrapper deve implementare un qualche protocollo a
livello applicativo (per esempio un login od un dialog): questo può essere complesso
se il sistema mantiene lo stato.
È fondamentale se il sistema legacy non ha una gestione delle eccezioni esternamente
definita o manca di robustezza; le eccezioni viceversa sono fondamentali per un
sis tema ad oggetti distribuiti.
Se il Legacy System si aspetta file d'inizializzazione con un certo nome e
localizzazione, il wrapper deve prepararli; se usa file temporanei il wrapper deve
34
q
implementare nuove interfacce che rientrino in una specifica molto più generale.
Interfaccia chiaramente
definita
Sistema Esistente
Wrapper : livello software che nasconde l’implementazione effettiva
delle funzionalità e le presenta attraverso un’interfaccia ben definita
Figura 15 - Il concetto di wrapper.
Nello sviluppare un wrapper si possono assumere approcci differenti, che chiaramente
conducono a soluzioni e risultati piuttosto diversi (soprattutto per quel che riguarda il
livello di astrazione ottenuto e l’efficacia dell’integrazione).
Un primo atteggiamento è quello opportunistico di cercare di riusare il vecchio sistema il
più possibile ed in modo facile: è l’uso dell’applicazione che guida il disegno del
wrapper e l’obiettivo del wrapping è solamente quello di esportare l’interfaccia
dell’applicazione nel nuovo ambiente (tipicamente il Web).
Esempi sono dati dalle prime sperimentazioni che alcune Amministrazioni della PA
hanno condotto relativamente alla DOC. In esse è stata identificata una transazione
legacy particolarmente significativa anche dal punto di vista dell’utente finale e la si è
controllare che non ci siano conflitti; se applicazioni collaterali sono necessarie al
Legacy System, il wrapper deve avviarle e gestirle; ecc.
35
offerta sul Web attraverso un semplice wrapper: un componente server con un unico
metodo che accetta in input una stringa formattata secondo il tracciato record della
transazione e riporta l’output sempre come stringa. In pratica il componente non fa altro
che rendere accessibile il tracciato record della transazione (che quindi si mappa 1:1 su
di esso) nel nuovo ambiente, ed il client deve occuparsi dello spacchettamento, non
essendoci trasparenza rispetto alla logica legacy. Quello che si espone non è Object
Oriented, bensì Object Based (nel senso che usa le nuove tecnologie ma non si avvale
delle loro intrinseche potenzialità d’astrazione).
Non si vogliono cioè aggiungere nuove funzionalità, solamente rendere disponibile la
vecchia applicazione nel nuovo ambiente; il punto di partenza quindi rimane la specifica
del vecchio sistema: si risponde alla domanda di come riuscire ad esportare il sistema nel
nuovo ambiente e non alla differente di come riuscire ad integrarlo, che porta a vedere
l'incapsulamento in un'ottica molto differente.
Esportare significa infatti modificare il sistema senza realmente determinare come esso
contribuisce alle necessità complessive dell'organizzazione e che ruoli copre
nell'architettura informativa; ci si focalizza sulla correzione delle deficienze del sistema
e sul suo miglioramento rispondendo alle necessità di business a breve termine.
Integrare significa invece considerare il sistema ed i dati nel contesto del business e
dell'architettura informativa.
Il principale difetto di questa strategia, che si potrebbe definire basata sul legacy (ovvero
di semplice accesso), è l'esposizione dei vincoli della vecchia infrastruttura nel nuovo
sistema, che è particolarmente dannosa nel caso di componenti distribuiti: si desidera che
i componenti interagiscano per costruire nuove applicazioni, ma le applicazioni legacy
non furono disegnate per essere blocchi componenti o per funzionare in concerto con
altre, per cui le interfacce che esportano non rientrano in un framework omogeneo e non
aderiscono ad una strategia.
La necessità che il client conosca il tracciato record della transazione, dovrebbe essere
un pre-requisito da rimuovere nel modo più assoluto, in tutti quei contesti, come la
RUPA, in cui il client è di un’altra organizzazione e non dovrebbe in linea di principio
essere sviluppato dagli stessi che sviluppano il server.
Un atteggiamento più maturo, che si potrebbe definire strategia basata sugli oggetti
(ovvero di vera integrazione), è quello che invece di esportare le interfacce e l’ambiente
nel nuovo dominio, prima costruisce il nuovo dominio e poi determina l'insieme di
funzioni dell'applicazione legacy di cui si ha bisogno per popolarlo: probabilmente è
sufficiente solo una piccola frazione di quanto il sistema legacy può fare, perchè non è
necessario esportare ogni interfaccia - molte saranno nascoste dietro al nuovo modello ad
oggetti .
36
La specifica dei componenti è guidata dalle nuove necessità dell'organizzazione,
piuttosto che dai vincoli del legacy compilati nelle proprie interfacce.
Idealmente questa strategia fa un'analisi come se dovesse costruire il nuovo sistema da
zero (top-down) e solo dopo vede cosa si può “riciclare” dal legacy minimizzando
l'esposizione delle sue limitazioni, invece di partire in modo bottom-up per cercare di
recuperare il più possibile. Inizialmente si esegue un'analisi e si genera un nuovo
modello ad oggetti, identificando in particolare le interfacce dei vari componenti, e poi si
popolano quest'ultime incapsulando le specifiche funzionalità del sistema legacy.
Nella realtà progettuale non si può procedere puramente top-down, ma è necessario
comunque inserire dei momenti bottom-up; comunque quello che caratterizza
quest’approccio non è tanto il processo, bensì il fatto che alla fine il risultato è un
modello ad oggetti che complessivamente incapsula il Legacy System; non si riesce ad
identificare dove sia effettivamente il wrapper di una specifica transazione (non c’è più
un mapping 1:1, perché magari le informazioni riportate da una specifica transazione
sono distribuite su differenti oggetti cooperanti) ma il wrapper è il modello stesso (o
meglio l’insieme degli strati software che complessivamente espongono questo
modello).
Prima di considerare gli aspetti più tecnologici, si vuole riportare un ulteriore esempio
della differenza tra accedere ed integrare: si supponga di dover sviluppare una nuova
applicazione di marketing per una organizzazione e che servano le informazioni sui
clienti; tali informazioni sono distribuite su più applicazioni legacy. Lo sviluppo
dell’applicazione può prendere due approcci:
L’applicazione accede alle differenti transazioni, utilizzando differenti tecnologie ed
occupandosi di tutte le trasformazioni necessarie; nel far ciò utilizza degli oggetti, ma
questi sono l’oggetto Sistema1 con il metodo accesso(), l’oggetto Sistema2 con il
metodo richiediTransazione(), ecc.
screen scraping
legacy 1
Applicazione
screen scraping
di
legacy 2
marketing
legacy 3
application gateway
Figura 16 - Un wrapping basato sul legacy.
L’applicazione utilizza l’oggetto cliente (e forse qualcun’altro ad esso legato) a cui
richiede le proprietà ed eventualmente alcuni metodi. La logica d’accesso ai sistemi è
37
immersa nel codice di wrapping che implementa quest’oggetto. Se ipoteticamente una
differente applicazione avesse bisogno delle stesse informazioni, si avrebbe un notevole
riuso, sia concettuale che di software.
È evidente come il secondo approccio introduca un livello ulteriore; inoltre il secondo
approccio richiede un maggior lavoro di analisi ed astrazione delle necessità informative,
mentre il primo riesce a soddisfare più velocemente esigenze di sviluppo immediato (ed
infatti è quello tipicamente adottato da molte organizzazioni che improvvisamente si
trovano con l’esigenza di dover offrire “qualcosa” sul Web). Questo non significa che il
primo approccio sia da scartare, anche perché esso ha il supporto immediato della
tecnologia, mentre il secondo richiede degli sviluppi ad hoc, che inevitabilmente alla fine
si appoggiano su wrapper costruiti secondo il primo approccio. Ma inevitabilmente alla
fine, per sviluppare sistemi informativi veramente integrati, bisognerà porsi nell’ottica
più ampia offerta dal wrapping basato sugli oggetti.
Applicazione
screen scraping
di
marketing
legacy 1
Cliente
screen scraping
legacy 2
legacy 3
application gateway
Figura 17 - Un wrapping basato sugli oggetti.
2.5.2.
Le tecnologie di contorno
Le tecnologie di contorno, note anche come tecnologie di mediazione, sono un gruppo di
tecnologie che permettono l’effettiva costruzione dei wrapper, in quanto mascherano ai
livelli sovrastanti tutti i dettagli della tecnologia legacy.
Esse possono essere raggruppate in due grandi categorie:
q tecnologie d’accesso, che forniscono la possibilità di connessione remota (un
esempio di tale tecnologia sono i gateway, cioè i convertitori di protocollo, che ad
esempio permettono di passare da socket TCP/IP a SNA LU6.2);
q tecnologie object/web based, che consentono di offrire una visione di più alto livello
appoggiandosi su quelle precedenti e permettono di avere interfacce object oriented,
ovvero d’integrare le risorse legacy direttamente in un ambiente Web.
38
A seconda di dove queste tecnologie vanno ad “agganciarsi” sul vecchio sistema, si
possono avere differenti paradigmi (che comunque devono trovare un corrispettivo nella
tipologia del sistema legacy, in termini di decomponibilità):
q RDA (Remote Data Access) permette di accedere direttamente al servizio dati;
q RFA (Remote Function Access) consente di richiamare direttamente le funzioni
legacy;
q RPA (Remote Presentation Access) permette di richiamare i servizi di presentazione
del vecchio sistema.
Un elenco di tecnologie d’accesso può allora comprendere:
q Database Gateways: un database gateway fa apparire locale un database remoto ed
interrogabile in modo standard 26 . Il paradigma è RDA.
q Application Gateways: utilizzando il paradigma RFA un application gateway
permette di richiamare procedure legacy remote27 .
q Screen Scraping: utilizza il paradigma RPA.
Esempi di tecnologie object/web based sono invece:
q Prodotti proprietari che permettono lo sviluppo di componenti Web (CGI o servlet
Java) che accedono direttamente all’host.
q Prodotti che permettono lo sviluppo di componenti che accedono all’host
presentando un’API OO verso l’esterno28 .
Tutte queste tecnologie presumibilmente, in un prossimo futuro (2000-2004 secondo le
previsioni del Gartner Group), non saranno più necessarie, se le promesse dei grossi
fornitori di mainframe (IBM soprattutto) verranno mantenute; infatti la tendenza è quella
di spostare direttamente il middleware ad oggetti ed il Web sui mainframe 29 , abilitandoli
direttamente a far parte del nuovo mondo DOC senza necessità dei mediatori.
26
Drivers ODBC e JDBC rientrano in questa categoria, così come i convertitori SQLto-IMS.
27
Un esempio è dato dai gateway SNA che permettono ad un server di richiamare
transazioni CICS/IMS su mainframe.
Ad esempio Microsoft COMTI che si appoggia su un sottostante gateway SNA.
28
29
Attualmente IBM offre un’implementazione di ORB CORBA per mainframe
(Component Broker), e nei progetti della Microsoft e del suo partner Software AG
c’è di fornire una versione di DCOM su mainframe. IBM inoltre sta lavorando a tutta
una serie di prodotti per CICS ed IMS che direttamente sul mainframe (che fornirà
quindi nativamente TCP/IP, HTTP, IIOP, ecc.) permetteranno d’accedere alle
applicazioni presenti, non solo attraverso linguaggi tradizionali, ma anche con Java.
IBM infatti vede in Java/CORBA/Web l’arma strategica con cui fronteggiare
Microsoft e riappropiarsi del mercato enterprise, presentando il suo sistema S/390
come la piattaforma adatta anche per il futuro e la DOC [Gartner Group 1998].
39
Paradigma RDA
Paradigma RFA
Paradigma RPA
Databse
Gateways
Application
Gateways
Screen Scraping
Tecnologia
d’accesso
Tecnologia
Obiect/web
based
Tools per lo
sviluppo di CGI e
servlet Java
Microsoft COMTI
Figura 18 - Esempi di tecnologie di mediazione e come esse si pongono rispetto alle due
classificazioni (paradigma d’accesso e livello d’astrazione).
Indipendentemente dal modo usato per accedere al Legacy System, queste tecnologie
risolvono in modo abbastanza immediato solo il problema di costruire wrapper
d’accesso; per costruire un modello di wrapping ad oggetti, deve essere sviluppato uno
strato software (più o meno esteso a seconda delle situazioni) che offra all’esterno il
modello ad oggetti ed utilizzi questi wrapper di più basso livello per farlo. Quindi tutto
lo strato che si estende in pratica dal punto di accesso al vecchio sistema fino al modello
ad oggetti compreso (cioè all’esterno) è quello che viene chiamato wrapper ad oggetti.
3.
Conclusioni
3.1.
Il giusto contesto
Nel presente capitolo sono stati affrontati prevalentemente degli aspetti tecnici relativi al
trattamento dei Legacy System, non toccando problemi di pianificazione delle attività e
gli aspetti organizzativi. Comunque bisogna ribadire che l'ICT esiste per supportare i
requisiti di business: senza questa relazione, l'ICT non risolve le reali necessità
dell'organizzazione.
Il BPR vede il suo target in termini di business process desiderati. I "legacy" business
process spesso non sono ben documentati o compresi poiché si sono evoluti durante un
lungo arco temporale e sono istanziati in molte locazioni e da persone differenti. La
sfida, dalla prospettiva del business, è di sostituirli con dei “target” business process.
L'ICT apparentemente non entra in questo progetto di "trattamento del business".
40
I legacy business process sono supportati a livello di sistema informativo da un insieme
di Legacy System, mentre i target business process saranno supportati da un ambiente
target (idealmente ad oggetti distribuiti). La sfida, a livello di sistema informativo, è
ammodernare i vecchi sistemi; comunque il trattamento avviene in un contesto di
business e per supportare requisiti di business. La pianificazione ed esecuzione del
trattamento (con qualsiasi approccio) deve essere fatta nel più ampio contesto della
pianificazione ed esecuzione del BPR.
C'è un corrispondente requisito dal livello del sistema informativo a quello dei business
process: i Legacy System non vengono trattati "nottetempo", e quindi la velocità del
BPR deve essere consistente con quella fattibile in termini di trattamento dei vecchi
sistemi. In ogni istante, l'ambiente informativo consiste di un sistema composito
(soprattutto nel caso di migrazione graduale o di wrapping), e corrispondentemente i
business process supportati saranno un mix di vecchi e già reengineered. Questa
semplice osservazione indica forse il fattore più significativo nel determinare da quale
porzione conviene partire (l'incremento nel caso della migrazione o le componenti da
integrare per prime nel caso del wrapping).
T2
T1
T3
T4
T5
LEGACY
TRATTAMENTO
T7
TARGET
Application
Objects
CommonFacilities
ObjectRequestBroker
Figura 19 - Trattamento dei Legacy System e BPR.
41
T6
3.2.
Quale approccio?
I diversi approcci presentati non sono in contrapposizione tra di loro e l'applicazione di
uno non esclude automaticamente l'utilizzo anche parziale degli altri.
Inoltre può capitare che si cominci con uno e si passi nel tempo ad uno differente; ad
esempio non è escluso che un’organizzazione, per soddisfare esigenze immediate, inizi
ad esporre alcuni servizi sul Web attraverso semplici wrapper d’accesso od una
migrazione delle interfacce utente, successivamente passi a sviluppare wrapper ad
oggetti ed infine decida di migrare completamente l’implementazione del proprio
sistema informativo, ormai nascosta dietro ad un modello ad oggetti stabile, dal mondo
mainframe ad un’architettura differente. Oppure che un’organizzazione, il cui obiettivo
originario era una migrazione, decida invece, dopo aver implementato un gateway magari ad oggetti -, di accontentarsi, di questo incapsulamento del sistema dietro ad una
nuova interfaccia, realizzando quindi alla fine un wrapping del proprio sistema.
Spesso i concetti di migrazione e di integrazione possono diventare interscambiabili,
dato che è evidente la similitudine (non solo concettuale, ma anche tecnologica e della
relativa offerta di mercato) tra un wrapper ed un gateway.
C'è da tener presente che nessun approccio è completo, nel senso che nessuno può essere
applicato con successo a tutte le categorie di Legacy System. Ad esempio l'approccio
dell’integrazione con il wrapping ha maggior senso nel contesto di un'architettura ad
oggetti distribuiti, mentre altri approcci potrebbero essere più convenienti per sistemi
isolati e non troppo estesi. Inoltre non ci sono ancora molti esempi sull'applicazione con
successo del wrapping (anche la DOC in generale è alle prime esperienze concrete) e
vanno ancora studiate metodologie e le classi di applicazioni per cui il wrapping è
vantaggioso e quelle invece che richiedono approcci più tradizionali.
La scelta di un approccio, ovvero del giusto mix di aspetti di approcci differenti, non è
affatto banale e solleva molti problemi che devono essere attentamente vagliati, non
ultimo l'effettivo supporto del mercato. Il wrapping, anche per il modo integrato con cui
aggredisce il sistema, sembra attualmente essere l’approccio più promettente e quello su
cui la comunità (sia scientifica che commerciale) sembra concentrare i maggiori sforzi.
42
4.
Appendice. Il mondo mainframe
Molte organizzazioni ancor oggi, per tutta una serie di qualità che i mainframe ancora
offrono (robustezza, affidabilità, sicurezza) decidono di sviluppare tutta la parte backend dei loro sistemi informativi su tali macchine.
I mainframe, nelle loro varianti più moderne vengono ancora acquistati ed utilizzati da
una fascia di organizzazioni che gestiscono tipicamente una enorme mole di dati.
Allo scopo di offrire un quadro completo sulla problematica dei Legacy System è quanto
mai opportuno offrire uno spaccato sul mondo mainframe presentando un piccolo
glossario dei termini tecnologici. Di seguito vengono riportate alcune definizioni legate
al mondo dei mainframe IBM (attualmente l’ambiente di riferimento nella stragrande
maggioranza dei casi).
q
q
30
MVS (Multiple Virtual Systems): è il sistema operativo dei mainframe. Pur
essendoci un unico processore, il sistema dà l’impressione, ai livelli software
sovrastanti, che siano in corso più processi ognuno operante sul proprio processore e
con la propria memoria (virtuale); ogni processo, su cui può essere eseguito un
qualsiasi ambiente operativo o pacchetto software (tipicamente il CICS) dispone
quindi di una copia (virtuale) della macchina sottostante.
CICS (Customer Information Control System): è un ambiente operativo con
funzionalità di TP Monitor.
Ø E’ un grosso programma che si appoggia al sottostante MVS e su di esso
appoggiano i programmi applicativi che vivono al suo interno, e per i quali il
CICS costituisce il sistema operativo (offre servizi anche di basso livello, per
cui quando il programma deve interagire con il sistema operativo, in realtà
invoca servizi intermedi del CICS): esso fornisce quindi un supporto a run-time
per i programmi applicativi – da cui la definizione di ambiente operativo.
Ø Grazie al CICS ogni programma può essere progettato e scritto come se fosse
l’unico in esecuzione, poichè esso maschera tutte le problematiche di
multitasking, multithreading ed accesso alle risorse condivise30 .
Ø Per quanto riguarda le funzionalità di TP Monitor, le operazioni vengono
raggruppate in Logical Unit of Work (LUW) ed il CICS si occupa degli aspetti
di commit/rollback interagendo con i sistemi di database sottostanti (non
necessariamente il relazionale DB2 ma anche su file VSAM).
Il CICS viene utilizzato inserendo nei programmi applicativi (tipicamente scritti in
assembler, COBOL o C) dei comandi CICS; questo programma deve poi essere
precompilato in modo che i comandi vengano espansi in opportune macro. Il
sorgente viene compilato e l’eseguibile così ottenuto deve essere reso noto
all’ambiente CICS (in pratica inserito in una tabella di sistema).
43
Ø
q
Tipicamente la transazione CICS viene avviata da un terminale 3270, ma
esistono API per accedere alle funzionalità CICS anche da altre piattaforme
remote (server ed altri ambienti CICS).
Ambiente: un ambiente è un mainframe con il sistema operativo MVS e un TP
Monitor sul quale si appoggiano i programmi applicativi che “vivono” in
quell’ambiente. Quindi su una stessa macchina si possono avere molti ambienti del
tutto indipendenti tra di loro, che all’esterno sembrano essere funzionalmente e
logicamente equivalenti ad una moltitudine di macchine.
Ambiente
Programmi
Programmi
Programmi
Programmi
IMS
CICS
IMS
CICS
sistema operativo MVS
HW: mainframe
Figura 20 - Il concetto di ambiente.
q
q
IMS (Information Management System): è un sistema general-purpose che
migliora le capacità del sistema operativo, permettendo agli utenti di accedere ad un
database attraverso terminali remoti. Funzionalmente è un TP Monitor + DBMS
gerarchico, ed il suo linguaggio per la formulazione delle transazioni è il DL/1.
Attualmente nel mondo ancora vengono elaborate più di 2 miliardi di transazioni
IMS al giorno.
VSAM (Virtual Storage Access Method): è un metodo per il processamento
diretto o sequenziale di record a lunghezza fissa o variabile su memoria di massa. I
record in un dataset o file VSAM possono essere organizzati in sequenze logiche in
base ad un campo chiave, in sequenza fisica secondo come sono scritti o con un
numero relativo. In pratica costituisce ancora il più diffuso sistema di archiviazione
di dati su mainframe.
44
60
50
40
30
20
10
0
VSAM
DB2
IMS
Altro
Figura 21 - I più diffusi sistemi di database su mainframe.
q
q
31
VTAM (Virtual Telecommunication Access Method): può essere visto come il
middleware (insieme di programmi) che controlla le comunicazioni tra i programmi
applicativi e le risorse di rete (tipicamente i terminali). Il VTAM è unico per una
macchina (anche se esso viene usato da molti ambienti) ed in pratica ogni risorsa
remota deve essere ad esso conosciuta31 .
SNA (System Network Architecture): è un’architettura di rete proprietaria IBM
che specifica come far comunicare risorse hardware e software IBM.
Quindi un server mid-range che fosse collegato ad un mainframe attraverso un
gateway-SNA, deve essere preventivamente registrato nel VTAM (cioè in una tabella
di sistema) del mainframe target, così come un altro mainframe a questo connesso.
45
Host
Cluster
Controller
Communication
Controller
Rete di
Telecomunicazioni
Cluster
Controller
Term
Term
Term
Cluster
Controller
Term
PC
Token Ring
Server
Figura 22 - L’architettura di rete IBM SNA.
Ø Gli host sono i nodi di rete che, oltre ad eseguire i programmi applicativi,
realizzano funzioni di controllo sulla rete.
Ø I communication controller sono nodi dedicati al controllo delle linee di
comunicazione ed in grado di fornire servizi di instradamento (routing).
Ø I cluster controller sono concentratori in grado di connettere terminali,
stampanti ed altri dispositivi (come una LAN di workstation/PC).
Ø Le unita di rete indirizzabili che possono comunicare tramite di essa vengono
chiamate NAU (Network Addressable Unit).
Ø Gli utenti finali della rete sono i programmi applicativi, i terminali utente ed i
dispositivi di I/O; ogni utente finale accede alla rete SNA tramite le LU
(Logical Unit) che sono un tipo di NAU e sono realizzate dal software
VTAM, dall’APPC e da altri software/firmware di comunicazione.
q
q
q
Famiglie di host: le principali sono:
Ø IBM S/36 e S/38, due architetture di minicomputer ormai obsolete e sostituite
dall’architettura AS/400;
Ø IBM AS/400, famiglia di medie prestazioni;
Ø IBM S/370, architettura del passato, ma ancora largamente utilizzata, sia ad alte
che basse prestazioni;
Ø IBM S/390, architettura attuale ad alte prestazioni.
Famiglie di terminali: le due principali sono:
Ø IBM 3270, sono terminali video e stampanti comunemente usata nelle reti SNA
con gli host ad alte prestazioni;
Ø IBM 5250, sono invece utilizzati con i minicomputer (AS/400);
Ø In realtà oggi è molto comune utilizzare un PC con software di emulazione
terminale.
LU (Logical Unit): Una LU è il modo con cui un utente (programma o terminale)
accede alla rete SNA. Le LU sono divise in vari tipi:
46
Ø
q
q
LU0, utilizzate in ambiente finanziario per semplici scambi di dati (sportelli
automatici ATM);
Ø LU1, utilizzate per i dispositivi batch;
Ø LU2, utilizzate dai terminali 3270;
Ø LU3, utilizzate da certi tipi di stampanti;
Ø LU4, utilizzate dai terminali 5250;
Ø LU6, utilizzate per la comunicazione tra programmi (particolarmente
importante la LU6.2);
Ø LU7, utilizzate dai terminali 5250;
Ø Le LU di tipo 1, 2, 3, 4, 7 dipendono dall’host per l’attivazione/disattivazione
delle sessioni; invece le LU6.2 possono stabilire sessioni anche senza la
presenza dell’host.
APPC (Application Program to Program Communication): è la modalità con cui
possono colloquiare peer-to-peer programmi applicativi tra due ambienti,
utilizzando LU6.2. Tale modalità prevede qualche decina di verbi (Connect(), Send
(), Disconnect(), ecc.), forniti sotto forma di librerie, che vengono utilizzati per
stabilire la connessione. Ultimamente si sta diffondendo anche la modalità CPI-C,
che è un sottoinsieme (16 verbi) dell’APPC: questa garantisce maggiore portabilità
ai programmi di comunicazione, soprattutto per quelli scritti in ambiente server midrange. Secondo queste modalità nei due ambienti che vogliono comunicare devono
essere presenti due programmi (detti comunemente Sender e Receiver) che si
occupano di stabilire il colloquio. Questi programmi interfacciano, ognuno nel
proprio ambiente, qualsiasi programma che ha bisogno di mettersi in comunicazione
con l'altro ambiente: quindi un programma A che nell'ambiente 1 vuole comunicare
con un programma B nell'ambiente 2 chiama il Sender di 1, che si mette in contatto
con il Receiver di 2, che a sua volta chiama B; a questo punto A e C instaurano il
colloquio, passando però sempre attraverso i due programmi, che forniscono quindi
un servizio di trasporto all'intero ambiente.
Modalità Link: è una seconda modalità di colloquio con la LU6.2. Utilizzandola, il
programma chiamante avvia direttamente quella remoto e rimane in attesa del
risultato; in questo modo si instaura un legame (link ) tra i due (il chiamante rimane
bloccato), ma non sono richiesti ulteriori programmi di comunicazione. Infatti il
CICS offre un servizio per supportare questa modalità, chiamato CSMI, che è una
sorta di transazione mirror che permette la comunicazione diretta tra i due ambienti.
Con la Link non c’è un peer-to peer tra i due programmi, ma una sorta di chiamata a
procedura remota.
47