Ingegneria del Software

Gli artefatti software di alto livello prodotti durante il ciclo di vita di un sistema software (documenti di pianificazione, analisi e progettazione) sono solitamente gestiti in maniera atomica dagli strumenti di Configuration Management.

Tuttavia, un approccio a grana fine, in cui ciascun artefatto viene scomposto in una gerarchia di artefatti pi semplici, é preferibile in quanto consente una migliore gestione della concorrenza, una piú dettagliata definizione delle politiche di accesso e modifica della documentazione prodotta e consente una migliore gestione della tracciabilitá tra gli artefatti.

Uno strumento di Configuration Management solitamente fornisce funzionalitá per la gestione del versioning degli artefatti gestiti. Un approccio a grana fine deve dunque gestire coerentemente le diverse versioni degli artefatti composti cosí come di ciascuno dei suoi componenti.

In tale ambito, l'attività di ricerca del Dipoartiment è rivolta alla gestione del versioning gerarchico per artefatti software gestiti a grana fine, con particolare riferimento a documenti di alto livello (documentazione e diagrammi) supportando team di sviluppo distribuiti.

La complessitá degli odierni sistemi software, richiede un estensivo uso della modellazione e, dunque, la produzione di numerosi diagrammi. Tali diagrammi sono spesso prodotti in diverse versioni e sono il frutto della collaborazione di diversi ingegneri del software.

Una possibile soluzione prevede la modellazione dei diagrammi in modalitá ascincrona, come avviene per i piú comuni sistemi di gestione delle versioni, in cui si affrontato il problema del merge automatico di versioni parallele di uno stesso diagramma e della gestione dei conflitti che si possono verificare qualora piú ingegneri del software modifichino lo stesso elemento del diagramma concorrentemente.

Tale approccio utilizza una gestione a grana molto fine dei modelli (sono gestite le singole proprietá di ciascun possibile elemento di un modello UML), basata sullo standard per lo scambio di modelli XMI. In tal modo, in maniera del tutto trasparente all’utente, è possibile gestire la maggior parte dei conflitti in maniera automatica, richiedendo l’intervento dell’ingegnere del software esclusivamente nel caso in cui la modifica sia apportata concorrentemente ad una stessa proprietá di un medesimo elemento del modello.

L'approccio a grana fine per la gestione di modelli UML è valido anche come supporto alla modellazione sincrona di diagrammi UML. In tal caso, gli sviluppatori possono accedere e modificare, nel medesimo istante, uno stesso diagramma UML, consentendo in tal modo, ai membri di un team distribuito, di discutere e modellare il sistema da realizzare direttamente all’interno dell'ambiente di sviluppo.

L’integrazione con uno strumento per la gestione di progetti e artefatti software, permette di rendere disponibili a tutti e mantenere sempre aggiornate (sotto forma di artefatti collegati tramite link di tracciabilitá) sia le diverse versioni di ciascun elemento del modello, sia l’informazione testuale scambiata e condivisa durante i meeting.

Anche gli artefatti prodotti durante le fasi basse del ciclo di vita del software, quali il codice sorgente e i documenti di testing, possono beneficiare di un approccio a grana fine.

Le ispezioni software sono una pratica dell’Ingegneria del Software il cui scopo consiste nell’identificare difetti all’interno di artefatti software, ridurre la necessitá di manutenzione correttiva e produrre sistemi software si elevata qualitá.

Uno degli aspetti piú controversi, relativamente ai processi di ispezione tradizionali, riguarda a necessitá di eseguire un meeting in cui tutti gli ispettori si incontrano per discutere sui problemi individuati nell’artefatto oggetto dell’ispezione. Tale meeting sincrono é costoso, in quanto richiede la presenza simultanea di tutti i partecipanti al processo di ispezione e, affinché sia efficace, esso richiede un’adeguata preparazione e moderazione, nonché cooperazione tra i membri del gruppo. In un ambiente distribuito, tali problemi sono ancora piú evidenti, in quanto le distanze geografiche rendono ancora piú costosi gli incontri in co-presenza.

In tale ambito è stato proposto un processo di ispezione software distribuito, nel quale il meeting sincrono viene preceduto da una discussione asincrona il cui scopo quello di eliminare i conflitti emersi durante l’individuazione dei difetti, evitando, in molti casi, la necessitá del meeting sincrono.

Un processo di sviluppo software prevede la realizzazione di numerosi artefatti, ciascuno dei quali puó essere collegato ad altri artefatti. Ció ancora piú evidente nel caso in cui si adotti un approccio a grana fine, in cui un artefatto complesso (quale, ad esempio, un documento di specifica dei requisiti software) puó essere considerato come una composizione a piú livelli di artefatti piú semplici (ad esempio i singoli requisiti software) e dunque il link di tracciabilitá puó interessare artefatti a diversi livelli della gerarchia.

La gestione della tracciabilitá è ampiamente riconosciuta come un fattore determinante per la buona riuscita di un progetto software. Durante la fase di realizzazione del sistema, infatti, le informazioni relative alla tracciabilitá supportano l’ingegere del software durante la stima della copertura dei requisiti del sistema e l’individuazione di componenti riusabili. In fase di manutenzione, invece, le stesse informazioni sono essenziali per una accurata valutazione dell’impatto di una eventuale modifica, nonché per la comprensione del codice esistente.

In tale ambito l'attività di ricerca del Dipoartimento S.T.A.T. è rivolta a fornire supporto all’ingegnere del software durante l’intero ciclo di cita del software tramite una opportuna gestione delle informazioni sulla tracciabilitá.

Questo sono, ad esempio, utilizzate per propagare gli eventi riguardanti cambiamenti apportati su di un artefatto, agli artefatti che da esso dipendono. In tal modo, il livello di context awareness tra i membri del team aumenta.

Paricolare attenzione è rivolta ad alcune tematiche inerenti la gestione della tracciabilità tra artefatti software quali:

• la visualizzazione dei link di tracciabilità
• il recupero dei link di tracciabilità

Per quanto riguarda la prima tematica, l'approccio adotta prevede l'uso di um grafo di tracciabilitá, ossia un grafo avente per nodi gli artefatti software e per archi i link di tracciabilitá. Tale grafo puó essere visualizzato e navigato per accedere ad artefatti collegati tra di loro, scaricarne le diverse versioni o sottoscrivere eventi di cui essere notificati.

Il problema dell’identificazione dei link è invece di particolare rilevanza e complessità. Ciò dipende in parte dal numero elevato di artefatti prodotti per un sistema di medie dimensioni, ed in parte dal fatto che, anche dopo aver definito il layer di tracciabilitá, questo puó variare dopo ogni modifica, inserimento o cancellazione di uno degli artefatti del sistema.

Una risposta al problema é rappresentata da un supporto automatico o semi-automatico alla fase di recupero dei link di tracciabilitá. Basandosi sulla considerazione che gran parte degli artefatti contengono informazioni in formato testuale, si è deciso di adottare un metodo per il recupero dei link di tracciabilitá tra artefatti basato sul Latent Semantic Indexing (LSI), una tecnica di Information Retrieval (IR), per l’individuazione di link candidati sulla base della somiglianza testuale tra gli artefatti legati dalla dipendenza.

Durante il suo ciclo di vita, un sistema software può trovarsi nella situazione di dover essere adattato, reingegnerizzato e migrato ai fini della coesistenza con sistemi software diversi e sviluppati in nuovi ambienti tecnologici, in particolare in ambienti client-server e/o basati su tecnologia ad oggetti.

La sostituzione del vecchio sistema con un sistema sviluppato conformemente ai nuovi requisiti tecnici è quasi sempre inammissibile a causa degli elevati costi che una tale soluzione comporta.

Una soluzione più plausibile da un punto di vista economico è la decomposizione di un tale sistema in componenti funzionalmente omogenei sui quali è possibile compiere delle scelte indipendenti.

Le scelte che un ingegnere del software potrà effettuare su tali sottosistemi variano dalla reingegnerizzazione, all’incapsulamento di tali componenti in "‘object wrapper"’, alla loro sostituzione incrementale.

In tale ambito l'attività di ricerca è rivolta alla creazione di un plug-in per Eclipse per supportare il processo di migrazione di sistemi software eraditati verso piattaforme moderne.

In particolare, si vuole affrontare il problema di migrare la gestione dei dati gestiti da una applicazione scritta nel linguaggio di programmazione COBOL verso un sistema che utilizzi basi di dati relazionali.

Un'altra area di ricerca riguarda la definizione e l’esecuzione di processi di reverse engineering e di comprensione di sistemi informativi tradizionali e basati sul web. I processi possono essere definiti in termini di activity diagram UML in cui a ciascuna attività è possibile associare componenti software predefinite o darealizzare. Tali componenti, implementate realizzando linguaggi di programmazione tradizionali e ambienti software per l’analisi dei dati, possono essere ovviamente riusati.