Reverse Engineering per sistemi Legacy

Reverse Engineering per sistemi Legacy

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-to-market 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.

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: 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. Bisogna specificare che quando si parla di CASE (Computer Aided Software Engineering) si definiscono tutti gli 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. ).
  • 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
  • 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.
  • 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. Esso comprende l’estrazione degli elementi di design del sistema, ma non comprende la modifica o la generazione di un nuovo sistema. Poiché i candidatial 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.

Principali approcci al Reverse Engineering per sistemi Legacy

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ù 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.).

Infine, è utile valutare anche i limiti derivanti dall’applicazione del Reverse Engineering per sistemi Legacy. Questo tema è trattato all’interno del seguente articolo: Limiti Reverse Engineering dei sistemi Legacy.

Quindi riassumendo…

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.

Precedente Manutenzione dei sistemi Legacy Successivo Limiti Reverse Engineering dei sistemi Legacy

Lascia un commento

*