Riuso del software: chimera o realtà?

I CEO delle maggiori aziende produttrici di software in un momento di riduzione degli investimenti in IT hanno focalizzato la loro attenzione sulla riduzione dei costi di produzione e quindi come è facile intuire diventa centrale la capacità di re-use del software, ovvero la capacità di sperimentare, strumenti di controllo e qualita’, relativi alle fasi di progettazione, sviluppo e integrazione di applicazioni e soluzioni aziendali.I nuovi linguaggi di programmazione basati su logiche object oriented consentono di applicare i principi della riusabilità ad ogni fase del processo di sviluppo software, dalla progettazione al test; nelle prime fasi di sviluppo del software, grazie ai meccanismi di estensione e astrazione presenti nei casi d’uso, la riusabilità può riguardare aspetti funzionali macroscopici del sistema software.. Un uso appropriato dei design pattern può, invece, fornire il riuso di soluzioni di progettazione a livello di architettura del sistema, questo tipo di riuso estensivo sul processo consente il riuso anche di casi di test di unità, riducendo anche lo sforzo per la definizione ed esecuzione degli stessi casi di test. Infatti, se la corrispondenza tra casi d’uso, architettura, codice e casi di test è realizzata in modo efficace e mantenuta in modo disciplinato, è possibile far seguire al riuso di un componente architetturale, il riuso dei corrispondenti casi di test.

I benefici principali del riutilizzo di componenti sono:
• propagazione in più contesti di soluzioni efficaci;
• riduzione dello sforzo di progettazione ed implementazione;
• incremento della qualità del software;
• un risparmio nei costi.

La progettazione di un sistema software e la scrittura del codice relativo, per quanto possa essere disciplinato da metodologie ingegneristiche, rimane un’attività con un’importante componente di creatività e competenza individuale, è quindi divenuta pratica comune e diffusa tra gli sviluppatori la ricerca di soluzioni che altri hanno già sperimentato essere efficaci, quando ci si imbatte in un nuovo problema.

Il riuso di una soluzione in un contesto operativo differente da quello per il quale è stata creata, comporta non pochi problemi:
- il linguaggio di programmazione può essere differente, quindi bisogna realizzare la migrazione tra due linguaggi, operazione non banale e non esente da rischi. In questo caso il riuso potrebbe essere più costoso dello sviluppo ex-novo;
- riutilizzare codice scritto da altre persone, con approcci e stili di progettazione completamente differenti da quelli abituali ha impatti devastanti sulla manutenibilità del sistema finale. La parte riusata rischia di avere livelli molto bassi di comprensibilità e probabilmente utilizza standard di codifica non coerenti con quelli utilizzati all’interno dell’organizzazione;
- un riuso non disciplinato potrebbe aumentare quella che in letteratura è nota come “pollution” del codice, cioè la presenza di elementi amorfi o con comportamenti anomali che sono dovuti per l’appunto ad una manutenzione e ad un riuso indisciplinato: strutture dati solo aggiornate o solo consultate, funzioni che non vengono mai chiamate, variabili mai utilizzate, metodi utilizzati per il debugging o per il test lasciati nel codice e così via. Nella migliore delle ipotesi questo abbassa la qualità del prodotto ed aumenta i tempi di manutenzione, nella peggiore crea malfunzionamenti o vulnerabilità al sistema software.

Un processo di riuso dei componenti software disciplinato ed istituzionalizzato nell’organizzazione ridurrebbe il costo dello sviluppo ed eviterebbe ai programmatori di ricreare continuamente routine standard, come quelle per la gestione dei processi di business, il flusso di processo tra componenti in un framework e il test del codice.

Circa il 40% del tempo speso in un tipico ciclo di sviluppo è occupato dal debug del codice, e l'utilizzo di componenti già testati consentirebbe agli sviluppatori di risparmiare il tempo di debug e dunque di incrementare la propria produttività.

Le soluzioni efficaci per problemi ricorrenti potrebbero essere riutilizzate ottenendo il doppio vantaggio di risolvere ottimamente un problema e di ridurre i tempi di risoluzione dello stesso.

Il riuso intensivo ed estensivo diffonderebbe più rapidamente esperienza, accrescendo le capacità e le abilità dei programmatori. Infatti questi sarebbero continuamente stimolati dallo studio delle soluzioni (riusate) che questi applicano ai loro problemi, confrontandosi con nuovi approcci e nuove strategie.

Diffondere una cultura del riuso nell’organizzazione significa: istituire un processo che disciplina il ciclo di vita del riuso; fornire uno strumento per catalogare i componenti e le relazioni tra essi tenendo conto di metriche e/o di indicatori di complessità. Infine, manutenere l’esperienza valutando quali componenti vengono effettivamente riusate e con quali esiti.

Definizione di un processo per il riuso.
Il riuso di componenti software deve essere opportunamente disciplinato perché possa essere efficace. Definire il processo corretto, significa definire la metodologia per: la creazione di un componente riusabile, la ricerca del componente adeguato, l’integrazione del componente all’interno del nuovo sistema. Perché un componente possa essere riusato deve essere progettato e realizzato in accordo a standard e documentato opportunamente, così che colui che lo riusa possa farlo nella maniera più efficace. La ricerca del candidato al riuso deve seguire delle regole stabilite a livello di organizzazione e che devono tenere conto sia delle metodologie di progettazione del componente sia dell’ambiente in cui questo possa essere riusato. Una ricerca realizzata male potrebbe proporre una gamma di componenti candidati al riuso ‘sbagliati’, nel senso che richiederebbero uno sforzo di integrazione notevole. Oppure potrebbero ‘nascondere’ il componente migliore, candidato al riuso. L’integrazione del componente, infine, è un momento estremamente delicato del processo di riuso. Infatti, riusare un componente comporta, spesso, il riuso di casi di test, di casi d’uso e di disegni architetturali.

Catalogazione dei componenti candidati al riuso.
Si intende realizzare un riuso a diversi livelli ( requisiti, progettazione, implementazione e test). Di conseguenza costruire il database di componenti candidati al riuso non è un’operazione affatto banale. Il data base, in questo caso, deve tenere traccia dei differenti livelli di riuso e delle loro relazioni. E’ necessario stabilire un metodo e uno strumento semantico per catturare e descrivere queste relazioni. La perdita della tracciabilità tra i componenti a diverso livello di dettaglio non consentirebbe di sfruttare il riuso nella logica object oriented.

Strumento per la ricerca e valutazione dei componenti di riuso.
Un riuso di tipo intensivo ed estensivo richiede una quantità di informazione che sarebbe difficilmente gestibile con un semplice database. E necessario definire il ‘contesto operativo’ del riuso; così è possibile effettuare il riuso a differenti granuli di dettaglio ( requisiti, progettazione, implementazione e test). Esistono strumenti, quali le tavole di decisione, che consentono di catturare questo tipo di informazione e consentono una navigazione della base di dati che sia a differenti viste e per interrogazioni successive. Seguendo l’albero delle interrogazioni, l’utente dettaglia sempre di più il contesto raffinando il reale focus di interesse. Inoltre le tavole di decisione, proprio perché lasciano integra la gerarchia degli elementi soggetti al riuso, consentono di preservare anche le relazioni tra i componenti del riuso. Perché il riuso sia efficace, gli elementi candidati al riuso devono essere valutati in base ad indicatori metrici che indichino il grado di efficacia del riuso. In questo modo il fruitore del database di elementi riusabili ha anche informazioni relative alla qualità dell’elemento riusabile. Inoltre in questo modo il database sarà mantenuto aggiornato con gli elementi che sono stati riusati con successo e quelli che hanno riportato insuccessi possono essere rimossi.

Raggiungere l’obiettivo ambizioso di fare re-use è possibile ma solo se viene seguita una strategia che prevede la definizione di una metodologia per la creazione, fruizione e integrazione di componenti riusabili in logica object-oriented; uno strumento metodologico, semantico e semiautomatico per la catalogazione, archiviazione e reperimento intelligente del componente da riusare; la realizzazione di un programma aziendale per il riutilizzo del software, concepito per fare del riuso una pratica sistematica del processo iterativo di sviluppo.

La strategia dovrebbe articolarsi secondo tre direttrici:
• il processo di sviluppo per il riutilizzo del software (design for reuse)
• il processo di sviluppo con il riutilizzo del software (design with reuse)
• la realizzazione di una “libreria” per la gestione dei prodotti riutilizzabili
• definizione di indicatori e metriche per valutare il successo del riuso ed effettuare analisi predittive e di impatto.