Preview only show first 10 pages with watermark. For full document please download

Il Trattamento Dei Legacy System

   EMBED


Share

Transcript

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