IL TRATTAMENTO DEI LEGACY SYSTEM. Antonio Massari, Massimo Mecella

Transcript

1 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: È 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. Su di esso l organizzazione ha pesantemente investito nel corso degli anni, e quindi non può essere semplicemente accantonato così com è. E enorme (centinaia di migliaia o milioni di linee di codice, distribuite su migliaia di programmi). Spesso il suo primo nucleo risale ad oltre un decennio fa ed è quindi progettato secondo vecchie concezioni. È scritto in linguaggio di vecchia generazione (COBOL, PL1 ed assembler). 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). Le interfacce utente sono quelle a caratteri (terminali 3270 o 5250) e non GUI. Le applicazioni che lo compongono sono prevalentemente stand-alone, ognuna è stato progettata e realizzata indipendentemente dal resto e quindi il sistema presenta 1

2 un integrazione prevalentemente verticale e monolitica. Strutturalmente tale software applicativo è tipicamente suddiviso in transazioni (una funzione utente scritta in COBOL) usabili contemporaneamente da più utenti 1. 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

3 attraverso il paradigma DOC (Distributed Object Computing). Al di là dello specifico progetto, è emerso che: 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. 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 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

4 (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: Business Process Reengineering (BPR): conversione dei processi di business [Hammer]. Software Reengineering: conversione del software. Data Reengineering: conversione dei dati. 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 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: 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. I moduli applicativi sono indipendenti tra di loro (non ci sono interdipendenze gerarchiche). 4

5 I moduli applicativi hanno interfacce ben definite con i servizi di database, quelli di presentazione e le altre applicazioni. 2. Data decomponibili, sono sistemi cosiddetti semistrutturati con le seguenti caratteristiche fondamentali: 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). 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 Presentazione Logica Applicativa Logica Applicativa Logica Applicativa Logica Applicativa Accesso ai Dati Accesso ai Dati Accesso ai Dati Accesso ai Dati Altamente decomponibile ( Amichevole ) Data decomponibile ( Trattabile ) Program decomponibile ( Trattabile ) Monolitico ( Ostile ) Figura 1 - Le differenti tipologie di Legacy System. 3. Program decomponibili, sono anch essi semistrutturati con le seguenti caratteristiche: 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). 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. 4. 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

6 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: Ostili: sono quelli che non permettono la possibilità di interfacciamento con l esterno. Trattabili: l interfacciamento con altri sistemi risulta possibile con un certo sforzo di programmazione e tecnologie ad hoc. 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 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: assessment 2, 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

7 L approccio white-box richiede un reverse engineeering che enfatizzi una comprensione profonda dei singoli moduli del sistema (program understanding 3 ) 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

8 Gli approcci possibili per trattare un Legacy System sono allora: Ignorare: escludere il sistema da ogni successivo sviluppo. Sostituzione a taglio netto: riscrivere il sistema da zero. Migrazione graduale: trasformare il sistema gradualmente. 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 wrapping 4. 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

9 Legacy System reverse e/o reengineering utilizza trattamento sostituzione integrazione sostituzione a taglio netto 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

10 vecchi, la documentazione spesso non esiste o è fortemente inadeguata 5, 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: 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. 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.). Migliorativa: serve a migliorare principalmente gli elementi che servono a soddisfare i requisiti non funzionali (prestazioni, uso di risorse, manutenibilità, ecc.). 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 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

11 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 tipo 8. 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 manutenzione 9 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 9 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). 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 $

12 Sviluppo Manutenzione 60% 40% 40% 60% 30% 70% 1970s 1980s Figura 5 - L evoluzione dei costi della manutenzione. 1990s Alcuni fattori influenzano negativamente i costi di manutenzione: età del sistema; dimensioni; complessità dei programmi; volatilità dell applicazione; carenza di documentazione; mentre altri hanno una influenza positiva: l uso di tecniche strutturate o formali; la presenza di una metodologia di sviluppo e quindi di una documentazione standard e controllata; la disponibilità di casi di test (per effettuare i test di regressione dopo l intervento); l utilizzo di tool automatici la presenza di un buona concezione di database administration; l esperienza dei manutentori; la natura degli strumenti tecnologici utilizzati (a partire dai linguaggi di programmazione); la pulizia del codice. Oltre ai costi diretti, la manutenzione implica un insieme di costi indiretti: 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; il tempo di attesa per un intervento è sempre troppo lungo per l utente e quindi si può generare disaffezione verso il sistema; le probabilità di introdurre errori latenti con l intervento sono altissime. 12

13 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 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

14 La maggior parte degli scopi del Reverse Engineering sono legati alle seguenti problematiche: 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. Assistere il processo di manutenzione. Migrare ad un'altra piattaforma hardware/software od integrazione in un ambiente CASE 10 : 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. 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: 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. 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. 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

15 Reengineering Livello di astrazione + Ristrutturazione - Reverse Engineering Figura 7 - I concetti di Restructuring, Reverse Engineering e Reengineering. Reverse Engineering: processo di analisi del sistema per identificarne le componenti e le interrelazioni e crearne una rappresentazione ad un più alto livello d'astrazione 11. 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: reverse funzionale, che mira alla ricostruzione globale del sistema trattato; 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

16 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. 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 = reengineering 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

17 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 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 netta 13 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

18 " 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: 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

19 Durata media (in mesi) Dimensioni del progetto (in function point) < K 1K 5K > 5K Pianificata Effettiva Ritardo 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 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-IMS- COBOL 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

20 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 Parziale Completa Mainframe Unplug dei Dati 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 MVS- CICS 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

21 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 scraper 14 e dei linguaggi di scripting 15. 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 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

22 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: conversione (ad esempio da database non relazionale a relazionale); trasformazione (ad esempio creazione di viste o dati di sommario); spostamento (ad esempio da database su mainframe ad uno su UNIX); 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 DataWarehousing 16, 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

23 Esistono varie tecnologie di supporto alla migrazione dei dati, di complessità, potenza e disponibilità differenti: 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. 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. 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 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

24 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 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: 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; 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; 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: database gateway: il gateway può essere messo tra i moduli applicativi ed i servizi database, incapsulando l intero database rispetto alle applicazioni; 24