Differenza tra approccio white-box, black-box e per sistemi Legacy
Un sistema, sia esso un sistema 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, manutenzione e quello che si è chiamato trattamento, all’interno dell’articolo Il problema del Reengineering per i Sistemi Legacy.
Detto ciò, è utile precisisare inizialmente che l’attività di assessment consiste nel valutare la strategia e gli obiettivi dell’organizzazione, ovvero 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.
D’altro canto, 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).
L’approccio white-box
L’approccio white-box richiede un reverse engineering che enfatizzi una comprensione profonda dei singoli moduli del sistema (program understanding) ed attività di riconversione.
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.
L’approccio black-box
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.
Approcci per sistemi Legacy
Gli approcci possibili per trattare un Legacy System sono allora:
- Ignorare: escludere il sistema da ogni successivo
- Sostituzione a taglio netto: riscrivere il sistema da
- Migrazione graduale: trasformare il sistema
- 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.
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.
