ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

Transcript

1 ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia orientata agli oggetti. Tali elementi [Larman97] sono: un linguaggio di modellazione che consente di descrivere il sistema da sviluppare organizzando tale descrizione per mezzo di oggetti; un processo di sviluppo che indica il flusso di lavoro nel corso delle fasi del progetto di sviluppo, specificando quando produrre determinati modelli; un insieme di principi di analisi e progettazione o patterns che codificano soluzioni note e testate a problemi caratteristici, consentendo di applicare tali soluzioni al problema in esame e semplificando in tal modo la produzione di porzioni di un modello del sistema. In particolare saranno approfonditi in maggiore dettaglio i primi due elementi, riservando al terzo una breve introduzione Lo sviluppo di sistemi Lo sviluppo di un sistema informatico è un processo comp lesso; gli elementi critici di tale processo sono: la comprensione del dominio di interesse, i problemi di gestione del processo di sviluppo e la capacità di descrivere e controllare il comportamento del sistema sviluppato. Ciascun sistema informatico viene costruito per risolvere un problema nell ambito di un certo dominio di interesse. Tali problemi presentano spesso numerosi elementi che accrescono la loro complessità, come la presenza di numerose esigenze spesso in contrapposizione fra di loro e la presenza di requisiti non funzionali, quali quelli di usabilità, prestazioni, costo e affidabilità. Inoltre accade spesso che gli utilizzatori del sistema e i suoi progettisti parlino un linguaggio completamente differente, così che i primi abbiano difficoltà ad esprimere con precisione le proprie necessità, mentre i secondi non riescano a spiegare correttamente cosa si apprestano a realizzare. Questa difficoltà di comprensione è difficilmente attenuata da specifiche prolisse espresse in forma testuale, mentre di maggiore utilità possono essere modelli del sistema espressi in un linguaggio formale o prototipi del sistema stesso. 1

2 I sistemi informatici inoltre possono avere una struttura interna complessa ed essere composti da migliaia di moduli, ciascuno dei quali contiene migliaia di linee di codice. La produzione di tali sistemi richiede il contributo di numerosi sviluppatori, il cui lavoro deve essere gestito, coordinato e integrato per arrivare al prodotto finale: la comunicazione fra i diversi sviluppatori è un elemento di successo importante nello sviluppo del sistema, e la descrizione del sistema per mezzo di modelli formali può portare un contributo significativo in tale senso. Un sistema software è un sistema che può assumere uno fra un determinato numero di stati: tale numero è però incredibilmente alto a causa dell esplosione combinatoria derivante dal numero di oggetti che compongono il sistema. La complessità strutturale del sistema induce quindi una complessità comportamentale. Di conseguenza un sistema informatico può eseguire transizioni di stato del tutto inattese in conseguenza di un input esterno non previsto, venendosi a trovare in uno stato di errore, uno stato a partire dal quale il successivo comportamento del sistema risulta imprevedibile. La risposta a questo problema è nella decomposizione del sistema in componenti più piccole la cui descrizione possa essere raffinata separatamente dalle altre, e il cui comportamento complessivo possa essere descritto in termini semplici e precisi a partire dal comportamento delle singole parti. Nell approccio tradizionale la decomposizione di un sistema è realizzata da un punto di vista funzionale: l elemento atomico di tale decomposizione è la funzione o procedura e ciascuna funzione può essere decomposta in altre più semplici. L attenzione del progettista del sistema si concentra quindi sul flusso di controllo e sulla decomposizione algoritmica: tale modalità di decomposizione tende a produrre sistemi difficilmente manutenibili, con un grado di resistenza basso verso l evoluzione dei requisiti Modellazione Object-Oriented Una modalità alternativa di decomposizione è quella di un sistema in oggetti e classi; in questo contesto un oggetto nel sistema corrisponde generalmente ad un concetto presente nel dominio del problema o nello spazio della soluzione, mentre una classe corrisponde ad un insieme di oggetti simili. Ogni oggetto è caratterizzato da un identità, da uno stato e da un comportamento. I vantaggi che una decomposizione ad oggetti presenta rispetto ad una funzionale si possono così riassumere: essa conduce allo sviluppo di sistemi più piccoli e semplici per ché consente di applicare meglio la filosofia di riutilizzo di componenti preesistenti; consente di descrivere il sistema in un modo più comprensibile per gli utenti finali e più vicino al dominio applicativo nel quale il sistema si colloca; conduce alla produzione di sistemi più resistenti alle modifiche. La modellazione object-oriented ha un impatto sulle diverse attività che vengono condotte nel corso dello sviluppo di un sistema (analisi, progetto e codifica). In fase di analisi le specifiche del sistema possono essere espresse in termini degli oggetti che popolano la particolare realtà (dominio di interesse) in cui si colloca il problema che il sistema intende risolvere. Nel corso del progetto il sistema da produrre può essere decomposto per mezzo di oggetti: i documenti prodotti descriveranno, utilizzando notazioni diverse, gli aspetti strutturali (classi e oggetti) e comportamentali (interazioni e 2

3 stati). Infine nell attività di codifica i moduli che compongono il sistema saranno organizzati in termini di classi di oggetti che cooperano fra di loro per svolgere un determinato compito. Un modello object-oriented [Booch94] è caratterizzato dai seguenti elementi costitutivi: astrazione di classificazione, la capacità di descrivere un oggetto mettendo a fuoco le caratteristiche più importanti e ignorando le altre, per mezzo del costrutto di classe; incapsulamento, la possibilità di nascondere i dettagli della implementazione di un oggetto; modularità, la possibilità di decomporre un sistema in un insieme di elementi caratterizzati da un basso grado di accoppiamento e da un elevata coesione interna; ereditarietà, la capacità di specificare una gerarchia fra le classi definite; aggregazione, la possibilità di definire un oggetto come composto da altri oggetti. L astrazione di classe consente di descrivere oggetti con caratteristiche simili per mezzo del costrutto di classe: una classe rappresenterà solamente le caratteristiche desiderate per gli oggetti che la compongono. Persona Nome Cognome Bianchi Rossi Figura 1 - Classificazione Verdi Un esempio ereditarietà è quella mostrata in figura fra le classi IMPIEGATO e DIRIGENTE: la seconda classe può ereditare dalla prima caratteristiche strutturali (nome, cognome, ecc.), comportamentali (la capacità di svolgere un compito assegnato) e di relazione con altre classi (entrambi fanno parte di un organizzazione). 3

4 Impiegato Dirigente Figura 2 - Ereditarietà La relazione esistente fra un IMPIEGATO e il GRUPPO in cui lavora costituisce un esempio di aggregazione: il gruppo risulta definito come oggetto composto da un certo numero di impiegati. Gruppo Impiegato Figura 3 - Aggregazione 1.3. Linguaggi di modellazione La realizzazione di un modello del sistema che si intende sviluppare prima della sua costruzione o della sua ristrutturazione è essenziale così come lo è il progetto per la costruzione di un edificio. L importanza di un modello e il grado di dettaglio necessario crescono proporzionalmente con la complessità dell oggetto che si intende costruire. Una cuccia per un cane può essere costruita da una sola persona senza la necessità di descrivere in alcun modo l obiettivo che si intende raggiungere. Una casa avrà bisogno almeno di un progetto di massima per verificare le necessità per cui viene costruita ed eventualmente affidare una parte dei lavori a ditte specializzate. La costruzione di un palazzo di molti piani avrà bisogno di un progetto dettagliato, un piano di realizzazione e di spesa, una chiara visione degli obiettivi da raggiungere e del modo in cui raggiungerli [Booch98]. Un modello consente di semplificare la realtà da descrivere mettendo in evidenza alcuni aspetti e scartandone altri: lo stesso sistema può essere modellato a diversi livelli di astrazione in diversi momenti del suo sviluppo. Una vista semplificata del sistema da sviluppare consentirà di visualizzare e comprendere meglio gli aspetti essenziali del sistema. Si desidera qui mettere in evidenza l importanza del modello fra gli elementi che compongono il progetto di un sistema. Un modello infatti assolve a compiti diversi: costituisce un elemento di comunicazione fra le persone coinvolte nella costruzione del sistema permette di verificare le caratteristiche del sistema da costruire permette di confrontare le caratteristiche del sistema con standard di costruzione 4

5 facilita la stima dei tempi e dei costi necessari a completare la costruzione del sistema. Ci sono altri fattori in grado di influenzare il successo di un progetto, ma l adozione di un linguaggio di modellazione è un elemento critico. Un linguaggio di modellazione includerà: gli elementi del modello i concetti di base del modello e il significato loro associato la notazione una rappresentazione visiva degli elementi del modello le linee guida il modo in cui gli elementi del modello possono essere composti 1.4. UML e modellazione OO UML (Unified Modelling Language) è un linguaggio per descrivere, specificare e documentare i prodotti del processo di sviluppo del software. Esso può essere utilizzato per sistemi di tipo e grandezza differenti ed è caratterizzato da un alto potere espressivo. UML non specifica un processo per la modellazione e intende anzi essere indipendente dal processo di sviluppo all interno del quale è utilizzato. I vantaggi di tale divisione fra linguaggio e modellazione e processo di sviluppo sono principalmente: la maggiore probabilità di accettazione di un linguaggio di modellazione rispetto ad un processo di sviluppo; la sostanziale invarianza di un linguaggio di modellazione rispetto agli elementi che caratterizzano un sistema software, differentemente da quanto avviene per il processo di sviluppo che può essere profondamente influenzato da tali fattori. UML fornisce il potere espressivo necessario a modellare un sistema informatico da una prospettiva object-oriented: UML infatti consente di rappresentare le classi e gli oggetti che le compongono, lo stato di tali oggetti e il loro comportamento. UML inoltre permette di mantenere diverse viste di uno stesso sistema, descrivendo gli oggetti che lo compongono da differenti punti di osservazione (strutturale, comportamentale) e a diversi livelli di astrazione. Prima della definizione dell UML chiunque desiderasse utilizzare un modello objectoriented si trovava a scegliere fra linguaggi diversi, ma simili fra loro, con differenze a volte minime di potere espressivo. Molti di tali linguaggi condividevano un insieme di concetti di base eppure li interpretavano e rappresentavano in modo leggermente differente, generando in tal modo confusione e scoraggiando l adozione di modelli object-oriented nello sviluppo di sistemi software. UML è il risultato delle sforzo di unificazione condotto a partire dal 1994 per individuare un linguaggio standard nella modellazione orientata agli oggetti. Il linguaggio è stato sviluppato da Rational Software come il successore ai linguaggi di modellazione specificati da Booch, Jacobson (OOSE) e Rumbaugh (OMT) pur attingendo alcuni concetti anche da altri linguaggi di modellazione. La specifica del linguaggio UML ha raggiunto i seguenti obiettivi: ha stabilito un linguaggio di modellazione visuale, fornendo un mezzo di comunicazione standard per la modellazione object-oriented; ha individuato una base formale per la definizione del significato dei modelli supportati; 5

6 ha favorito la proliferazione di strumenti di sviluppo e componenti per la realizzazione di sistemi object-oriented; ha specificato un modello visuale non legato ad un particolare linguaggio o processo di sviluppo; ha integrato alcuni fra gli approcci più interessanti alla modellazione objectoriented. UML è stato proposto per la standardizzazione da parte dell OMG all inizio del 1997 e, dopo un processo di revisione che ha coinvolto le più importanti fra le industrie software, ha ottenuto la approvazione nella sua versione 1.1. UML è ora di dominio pubblico e grazie al processo di standardizzazione in cui è stato coinvolto, ai contributi forniti dalle industrie e dal settore scientifico esso potrà avere una ampia accettazione portando alla nascita di strumenti di modellazione, sviluppo e integrazione basati su di un modello di riferimento comune Schema del processo di sviluppo Nel seguito sarà descritto un processo di sviluppo iterativo, che si concilia con la metodologia object-oriented, con cui verrà condotta la progettazione. Il processo iterativo riduce in modo significativo i rischi di progetto negli stadi iniziali dello sviluppo e permette di ottenere un maggiore controllo sul sistema prodotto. Con un processo di sviluppo iterativo il sistema non viene rilasciato in un unica versione alla fine del progetto, ma viene sviluppato e rilasciato in porzioni, ciascuna delle quali contiene un sottoinsieme progressivamente crescente di funzionalità. Lo sviluppo risulta così suddiviso in iterazioni: durante ogni iterazione si realizza una porzione del sistema rispondente ad un determinato sottoinsieme delle specifiche. Ogni iterazione si articola a sua volta in analisi, progetto, codifica e sperimentazione. Al termine di ogni iterazione è prevista una verifica di quanto sviluppato con i futuri utenti ed i responsabili del progetto. Nel corso del processo di sviluppo vengono prodotti diversi modelli del sistema utilizzando il linguaggio di modellazione prescelto. La prospettiva in cui tali modelli sono prodotti cambierà durante il corso dello sviluppo: essa sarà infatti inizialmente orientata all analisi (definire formalmente cosa sviluppare) quindi al progetto (definire formalmente come svilupparlo, in termini di struttura e comportamento del software) e infine all implementazione (come realizzare, per mezzo degli strumenti di sviluppo individuati le soluzioni progettuali identificate nella fase precedente). Vale la pena di sottolineare in questa sede che, in linea generale, i diagrammi potranno essere disegnati con varie prospettive indipendentemente dal loro tipo. Infatti il tipo di diagramma dipende dal particolare aspetto del sistema (utilizzo, struttura, comportamento) che si desidera descrivere, mentre la prospettiva utilizzata per disegnarlo dipende dal grado di astrazione (concettuale, specifica, implementazione) con cui si è in grado di descriverlo allo stadio corrente del progetto. 6

7 Implementazione Raffinamento progressivo Gli aspetti strutturali del sistema sono descritti con diagrammi dello stesso tipo ma livelli crescenti di dettaglio. Specifica La specifica di differenti aspetti del sistema è descritta con diagrammi di tipo diverso ma medesimo livello di dettaglio. Concettuale Aspetti del sistema Utilizzo Struttura Comportamento Figura 4 - Prospettiva di utilizzo di un modello nei diversi momenti del processo di sviluppo Per utilizzare in modo efficace lo sviluppo iterativo è necessario adottare: un linguaggio di modellazione che garantisca la possibilità di accrescere il progetto del sistema attraverso il riutilizzo di componenti sviluppati precedentemente e sia resistente a successivi raffinamenti delle specifiche; un linguaggio di modellazione in grado di fornire viste del sistema da sviluppare a differenti livelli di astrazione, favorendo la costruzione di una nuova vista a partire da quelle già sviluppate. Il primo requisito è soddisfatto dai linguaggi di modellazione orientati agli oggetti perché, come accennato, questi offrono i migliori strumenti per costruire modelli flessibili e modificabili nel tempo attraverso i meccanismi dell ereditarietà, dell aggregazione e dell incapsulamento. I primi due consentono di costruire nuovi oggetti a partire da quelli preesistenti, sfruttando le relazioni is-a e part-of. Il secondo consente di modificare l implementazione di un determinato oggetto, ad esempio per migliorare le prestazioni di un operazione che esso definisce, senza per questo richiedere la modifica delle classi che utilizzano tale operazione, sfruttando il meccanismo dell incapsulamento. Il secondo requisito è soddisfatto dal linguaggio UML, che integra diversi modelli, permettendo di descrivere diversi aspetti dei componenti del sistema (struttura, comportamento, architettura) a diversi livelli di astrazione (concettuale, logico, implementativo). 7

8 1.6. Patterns UML fornisce un linguaggio per la modellazione mentre i patterns costituiscono il risultato di tale utilizzo: modelli di esempio. Un pattern rappresenta uno problema ricorrente per il quale è stata già individuata una soluzione che è stata applicata nel corso di un esperienza pratica: esso fornisce quindi una soluzione già verificata. D altra parte i patterns devono rappresentare un punto di partenza per individuare la soluzione ad un problema attuale: nel momento in cui si individua un pattern potenzialmente utile esso va provato, calandolo nel contesto del particolare progetto e adattato alle specifiche esigenze del progetto stesso. Gli elementi essenziali di un pattern sono: il nome, che permette di identificarlo all interno di una collezione di patterns; il problema, che descrive in quale contesto il pattern è stato individuato; la soluzione, che illustra le scelte operate per risolvere il problema e mette a disposizione un template per soluzioni a problemi simili; le conseguenze, che mostra i risultati dell applicazione della soluzione allo specifico problema in esame, individuando vantaggi e svantaggi. Vi possono essere pattern utili nelle attività di analisi e di progettazione. Un esempio di pattern di progetto, tratto da [Gamma94], è il seguente: si supponga di voler realizzare un sistema che implementi meccanismi di comunicazione fra oggetti in differenti processi. Un esigenza comune è quella di avere tali processi in esecuzione su procesori differenti e di voler realizzare un architettura in cui gli oggetti in esecuzione su di un processore non debbano specificare esplicitamente su quale processore si trovano gli oggetti cui devono accedere. Una soluzione a tale problema prevede l utilizzo di un proxy sullo stesso processore in cui si trovano gli oggetti chiamanti. Tale proxy presenterà la stessa interfaccia dell oggetto da invocare, così da svincolare gli oggetti locali dalle modalità di chiamata degli oggetti remoti. Subject request() <<method>> RealSubject.request() Real Subject request() Proxy request() Figura 5 - Pattern di progetto di un Proxy Un esempio di pattern di analisi, da [Fowler97B], è invece il seguente: si supponga di voler modellare un meccanismo per la gestione del rischio in un mercato finanziario. È necessario comprendere il modo in cui il valore di un portafoglio di azioni cambia nel 8

9 tempo, ad esempio mantenendo i prezzi per ogni azione con associato un time-stamp. Potrebbe inoltre essere utile essere in grado di prevedere rischi ipotetici oltre a quelli reali, effettuando analisi di tipo what-if. A tale scopo si può considerare il concetto di Scenario che contiene un insieme di azioni diverse. Scenario Istante temporale 1 * 1 Azione * Elemento Quotazione 1 * * 1 Figura 6 - Pattern di analisi di uno Scenario I pattern di analisi sono particolarmente utili per acquistare confidenza con un dominio non noto; d altra parte un pattern individuato nel contesto di un certo dominio può rivelarsi utile anche all interno di un dominio differente 1.7. Un primo esempio In questa sezione viene proposto un primo esempio di specifica di un sistema automatizzato per la prenotazione degli esami universitari. Tale esempio è utile per dare una prima vista generale alle caratteristiche del linguaggio di modellazione UML e identificare una sequenza di modelli prodotti nel corso del processo di sviluppo. In questo esempio sono descritti alcuni strumenti per la cattura dei requisiti e l analisi del sistema, come i diagrammi use case o il modello concettuale del dominio rappresentato per mezzo di un class diagram, e altri utili nella fase di progetto, come l interaction diagram e il modello di progetto delle classi del sistema descritto per mezzo di un class diagram. 9

10 Use cases Un primo use case per il sistema indicato è il seguente: Use case Prenotazione di un esame universitario Attori Descrizione Studente Lo use case inizia quando lo studente fornisce al sistema la propria matricola e il proprio codice fiscale per identificarsi. Il sistema verifica che lo studente sia regolarmente iscritto e quindi fornisce un elenco degli esami che lo studente può sostenere. Lo studente seleziona un esame, quindi il sistema suggerisce le prossime date per sostenere l esame. Lo studente seleziona la data prescelta e conferma la prenotazione. Lo use case termina quando il sistema fornisce un numero di registrazione allo studente. Il sistema può non riconoscere lo studente fra quelli iscritti regolarmente. Lo studente può interrompere la registrazione senza selezionare un esame o una data. Tabella 1- Descrizione testuale di uno use case Lo use case sopra introdotto può essere in parte descritto per messo di uno use case diagram Attore Relazione di associazione Use Case Prenota esame <<uses>> Studente Relazione uses Valida accesso Figura 7 - Diagramma use case Lo use case illustrato descrive una tipica interazione fra l utente del sistema ed il sistema stesso per lo svolgimento di un compito specifico. Esso costituisce un importante strumento di comunicazione fra committente e sviluppatore nel corso della elaborazione del progetto e consente una migliore comprensione dei processi da automatizzare. 10

11 Modello concettuale Il modello concettuale è un altro importante prodotto risultante dall analisi del dominio: mentre gli use cases descrivono i requisiti funzionali del sistema, il modello concettuale illustra il modo in cui gli oggetti vengono classificati e consente di mettere a fuoco il significato dei termini usati nella realtà di interesse. Esso permette di identificare i concetti, gli attributi e le associazioni considerate importanti nel dominio e può essere descritto per mezzo di diagrammi di classi quale quello che segue. Classe Attributi Studente nome matricola CF frequenta Corso materia anno accademico insegna Professore nome sostiene riguarda Relazione di associazione sottoscrive Esame data include Lista prenotazione Figura 8 - Modello concettuale del dominio descritto per mezo di un class diagram Si noti come il mo dello concettuale sopra descritto non descrive componenti software, oggetti del sistema da sviluppare, ma piuttosto rappresenta concetti del mondo reale all interno del dominio di interesse Diagrammi di interazione Un diagramma di interazione (interaction diagram) descrive il modo in cui gruppi di oggetti collaborano fra loro per svolgere un determinato compito. Tipicamente un diagramma di interazione descrive il flusso di eventi rappresentato in uno use case. Esso permette di assegnare delle responsabilità agli oggetti, mostrando come essi interagiscono fra di loro. 11

12 Oggetto : Studente : Modulo di registrazione : Gestore delle prenotazioni : Esame : Lista prenotazione Inserisci Dati Verifica Dati Prenota AggiungiStudente Messaggio Figura 9 Flusso di messaggi fra oggetti del sistema illustrato per mezzo di un sequence diagram Progetto e diagrammi delle classi Dopo aver descritto gli oggetti del sistema ed il modo in cui essi collaborano per la realizzazione di uno use case, per mezzo di un diagramma di interazione, è ora possibile specificare in dettaglio quali classi comporranno il sistema software. Queste informazioni possono essere catturate per mezzo di una diagramma delle classi di progetto. 12

13 Relazione di dipendenza Modulo di registrazione Gestore delle prenotazioni VerificaDati() Classe Esame data Prenota() Corso materia anno accademico * 1 Attributi Studente nome matricola CF 1 Lista prenotazione AggiungiStudente() Relazione di aggregazione Figura 10 Progetto dei componenti software del sistema illustrato per mezzo di un class diagram Questo diagramma illustra in che modo i componenti del sistema software sono connessi e quali metodi realizzano. 2. Il processo di sviluppo Identificare e seguire un processo di sviluppo è un attività necessaria per diminuire i rischi legati allo sviluppo di un sistema software. Inoltre una volta codificato un processo esso può essere ripetuto, rendendo l attività di sviluppo meno dipendente dal contributo che le singole risorse umane sono in grado di offrire [Larman97]. Il processo di sviluppo di un sistema software è costituito da un insieme di passi che consentono di muoversi dalle attività di analisi dei requisiti fino all implementazione e alla consegna del sistema. Obiettivo di tale processo è quello di sviluppare il sistema in oggetto secondo le esigenze del committente. Nel classico approccio allo sviluppo dei sistemi il modello seguito è quello a cascata in cui si distinguono diverse fasi ordinate linearmente: analisi, in cui si definiscono i requisiti del sistema e si descrive cosa si vuole realizzare; progetto, in cui si decide come realizzare il sistema; codifica, con l implementazione del sistema per mezzo di un linguaggio di programmazione; test, in cui si verifica la rispondenza del sistema implementato ai requisiti espressi; manutenzione, in cui si apportano cambiamenti al sistema. 13

14 Analisi Progetto Codifica Test Manutenzione Figura 11 - Schema del modello a cascata Il modello a cascata presenta però notevoli svantaggi. Nel mondo reale infatti i progetti raramente seguono il flusso sequenziale proposto dal modello ed è spesso difficile per il cliente dichiarare tutti i requisiti in modo esplicito nelle prime fasi del progetto. Inoltre il cliente dovrà attendere le ultime fasi del ciclo di vita per poter lavorare con il sistema e verificare quindi che le sue aspettative sono state soddisfatte. Questa situazione può rivelarsi assai penalizzante nello sviluppo di sistemi di grandi dimensioni: infatti tutti i problemi che si riscontreranno nel corso della verifica (test), dovuti ad errori commessi in una delle precedenti fasi, comporteranno correzioni che dovranno essere propagate attraverso tutti i precedenti passi che compongono il ciclo di vita. In tal modo potranno aumentare in modo significativo il tempo e i costi per la consegna del sistema, così come il rischio di insuccesso del progetto ( 1, [Standish95]) Il processo iterativo Il processo proposto nel seguito è stato desunto in larga parte da quello definito dai medesimi autori dell UML e denominato RATIONAL UNIFIED PROCESS e dalla metodologia OBJECTORY definita in [Jacobson94]; spunti significativi sono tratti anche da [Fowler97] e [Larman97]. RATIONAL UNIFIED PROCESS è un processo di sviluppo iterativo e incrementale: il sistema non viene rilasciato un'unica volta alla fine del processo, ma in passi successivi. Questo approccio presenta vantaggi significativi quanto più aumenta la complessità del sistema da sviluppare. Innanzitutto la comprensione del problema da risolvere non avviene in un unica fase iniziale, ma in passi successivi con il raffinamento e la crescita 1 Si consideri che negli USA secondo dati del 1995 circa un terzo dei progetti di sviluppo software non viene completato e più della metà ha un costo doppio rispetto alle previsioni iniziali. 14

15 incrementale di un medesimo modello nel corso di cicli successivi. Inoltre grazie ad un approccio iterativo è possibile accogliere nuove esigenze o modifiche negli obiettivi per i quali viene sviluppato il sistema. Infine l approccio iterativo permette di affrontare e risolvere nelle fasi iniziali i rischi collegati allo sviluppo del sistema, quali i rischi tecnologici, professionali e organizzativi. Il RATIONAL UNIFIED PROCESS è un processo incentrato sugli use cases: tale approccio consente di comprendere a fondo le esigenze degli utenti e gli use case individuati fin dalle prime fasi dello sviluppo del sistema costituiscono delle linee guida per i passi successivi, dalla pianificazione, all analisi dei requisiti, fino al test del sistema stesso. Il processo di sviluppo dovrà mettere in luce fin dall inizio l architettura software di riferimento. Ciò significa identificare i sottosistemi da sviluppare, assegnare loro delle responsabilità precise, individuando le interfacce fra tali componenti e il modo in cui essi possono interagire, allo scopo di realizzare le funzionalità previste dal sistema. L architettura verrà raffinata quindi nel corso dei successivi cicli di sviluppo e la sua qualità potrà essere misurata [Larman97] in termini di: chiarezza nella descrizione; robustezza e solidità rispetto a necessità di modifica dei requisiti; adozione di componenti riutilizzabili; articolazione in una struttura stratificata a sottosistemi; basso grado di accoppiamento fra i sottosistemi, con interfacce ben definite. Si noti infine come lo sviluppo dell architettura dovrà essere focalizzato fin dall inizio su quei componenti e sottosistemi che realizzano le funzionalità più critiche e complesse, allo scopo di minimizzare i rischi legati allo sviluppo del sistema. Altri elementi essenziali nel RATIONAL UNIFIED PROCESS sono: l adozione delle tecnologie object oriented, incluso il linguaggio di mo dellazione UML, la possibilità di configurare il processo di sviluppo per rispondere alle esigenze di sviluppo di sistemi differenti da parte di diverse organizzazioni, l adozione di criteri oggettivi per la misura della qualità dei prodotti nel corso di tutto il processo di sviluppo. Il RATIONAL UNIFIED PROCESS naturalmente non può essere applicato in modo identico nello sviluppo di qualsiasi sistema: esso però può essere adattato in funzione delle esigenze del progetto; fra i fattori che influenzano l esatta sequenza di passi da compiere e i prodotti del processo vi sono da esempio: il tipo di sistema da realizzare (applicazione per l automazione di un ufficio, sistema per il controllo di un satellite geostazionario, sistema informativo distribuito); le dimensioni del sistema (il grado di formalismo necessario nella produzione della documentazione può cambiare se il team è composto da due persone o da 20) Le fasi del processo Il processo di sviluppo delineato può essere suddiviso nelle seguenti fasi: avvio, la fase in cui si individua la necessità di realizzare un sistema, si misurano i benefici attesi e si stimano i costi; elaborazione, in cui si caratterizza in modo più preciso il sistema da realizzare e si mettono a fuoco l architettura di base, il modello concettuale di riferimento e la piattaforma tecnologica; 15

16 sviluppo, suddiviso a sua volta in iterazioni nel corso delle quali si realizzano versioni successive del sistema che soddisfano insiemi sempre più completi di requisiti; rilascio, in cui il sistema viene raffinato in termini di prestazioni e robustezza, e consegnato agli utenti finali. Ciascuna fase può essere suddivisa a sua volta in diverse iterazioni: ciascuna iterazione racchiude in se tutte le fasi di un processo di sviluppo classico, ovverosia analisi, progetto, codifica e test, e si conclude con la consegna di una versione del sistema. Avvio Elaborazione Sviluppo Rilascio Iter. 1 Iter Iter. N Figura 12 - Struttura del RATIONAL UNIFIED PROCESS Si noti come la suddivisione in iterazioni, sebbene enfatizzata in particolare per la fase di sviluppo, possa in realtà essere applicata a tutte le fasi del processo di sviluppo Distribuzione delle attività nelle diverse fasi Il RATIONAL UNIFIED PROCESS definisce inoltre una distribuzione indicativa delle attività che compongono il processo di sviluppo nelle diverse fasi. T EMPO Avvio Elaborazione Sviluppo Rilascio Modellazione del dominio Individuazione dei requisiti ATTIVITÀ Analisi e progettazione Codifica Test Dispiegamento Iterazioni preliminari iter 1 iter 2 iter 3... iter n iter n+1 iter n+2 Figura 13 - Distribuzione delle attività nelle diverse fasi del RATIONAL UNIFIED PROCESS Le medesime attività possono essere svolte nelle diverse fasi del progetto, pur in proporzioni differenti: così la fase di avvio sarà incentrata sulla descrizione della struttura dell organizzazione e dei suoi processi interni, la fase di elaborazione sulle attività di analisi e progettazione, la fase di sviluppo sulla codifica e test del sistema e la fase di rilascio sulle attività di dispiegamento del sistema stesso Avvio Obiettivo della fase di avvio è quello di individuare le esigenze generali alle quali il progetto di sviluppo deve rispondere e i confini del problema che si intende risolvere. Tale fase può essere altamente informale o arrivare a prevedere la stesura di uno studio 16

17 di fattibilità e lo sviluppo di un prototipo per verificare la validità delle esigenze individuate. Alla fine di questa fase si decide l avvio del progetto effettivo, dando inizio ad uno studio più approfondito del problema che contribuisca a identificare i tempi e i costi di realizzazione, e prevedere i rischi Elaborazione La elaborazione è necessaria per analizzare in modo approfondito l ambito del problema che si intende risolvere, identificare un architettura di riferimento, descrivere un possibile piano di sviluppo e ridurre i rischi legati allo sviluppo stesso. In questa fase dovranno essere catturati la maggior parte dei requisiti del sistema allo scopo di verificare che l architettura di riferimento individuata risponda in modo completo alle esigenze prospettate. Come indicato precedentemente anche la fase di elaborazione può seguire delle iterazioni per portare a raffinamenti successivi dei suoi prodotti Requisiti del sistema e dominio di interesse Un primo obiettivo della fase di elaborazione è quello di individuare i requisiti del sistema: essi costituiscono una descrizione delle necessità o dei desideri che gli utenti sono in grado di esprimere in relazione al sistema da realizzare. I requisiti hanno per oggetto gli obiettivi di alto livello che impongono la realizzazione del sistema, le funzioni che il sistema dovrà fornire (cosa fa il sistema) e le caratteristiche che esso offrirà (in che modo il sistema si comporta). Fra le caratteristiche non funzionali del sistema sono comprese la facilità di utilizzo, le prestazioni, la tolleranza all errore. I requisiti funzionali del sistema vengono catturati per mezzo degli use case: ciascuno use case descrive una possibile interazione che un utente ha con il sistema allo scopo di ottenere un risultato. Si pensi ad un impiegato che utilizza un sistema per la gestione di uno sportello bancario: un possibile use case è il seguente: Use Case Attori Descrizione CAMBIO DI UN ASSEGNO IN DENARO CONTANTE Cliente, Cassiere Un cliente arriva allo sportello bancario e consegna un assegno compilato e firmato. Il cassiere prende l assegno, verifica che il conto corrente cui fa riferimento l assegno abbia una disponibilità sufficiente, registra l operazione e consegna al cliente il denaro contante corrispondente. Ciascuno use case descrive una funzione del sistema che l utente può comprendere e rappresenta un oggetto del quale lo sviluppatore può valutare la complessità: esso assume la funzione di unità di misura del sistema da sviluppare. Un insieme di use cases può essere descritto utilizzando l UML per mezzo di uno use case diagram. Nel corso della fase di elaborazione sarà necessario identificare la maggior parte degli use cases relativi al sistema che si vuole realizzare, ad esempio per mezzo di interviste con gli utenti del sistema stesso. Gli use case potranno essere descritti a diversi livelli di dettaglio; a ciascuno di essi potrà essere associato un livello di rischio, una priorità in relazione alle esigenze degli utenti e un livello di astrazione al quale si colloca la descrizione della funzione del sistema. 17

18 Un altro prodotto della fase di elaborazione è il modello concettuale del dominio di interesse. Un modello concettuale descrive gli oggetti del mondo reale che sono di primaria importanza per lo svolgimento delle attività che il sistema deve automatizzare, il modo in cui essi sono associati gli uni agli altri e i loro attributi. Un modello concettuale è rappresentato per mezzo di un class diagram; i passi da compiere per disegnare tale diagramma sono: 1. identificare i concetti principali in base ai requisiti individuati e rappresentarli nel class diagram; 2. rappresentare le associazioni fra tali concetti per mezzo di relazioni fra le classi; 3. rappresentare gli attributi più significativi in ciascuna classe. È importante notare che le classi presenti nel modello concettuale non rappresentano oggetti del sistema da sviluppare ma unicamente oggetti del mondo reale che si intende descrivere. Il flusso del lavoro all interno del dominio, ovvero l insieme delle attività comunemente svolte nella realtà di interesse, può invece essere rappresentato per mezzo di un activity diagram; tale modello costituisce un complemento alla rappresentazione strutturale del dominio fornita dai class diagrams. Si noti che le attività fin qui descritte si influenzano a vicenda e i prodotti di ciascuna attività (insieme dei requisiti, modello dei concetti e modello dei processi) dipendono dagli altri: ad esempio i termini e le operazioni utilizzati nella descrizione dei requisiti possono costituire una base per l individuazione dei concetti e dei processi da modellare; tali modelli a loro volta consentono di verificare la completezza e la coerenza dei requisiti raccolti, e offrono importanti spunti per ampliare la base iniziale. Individuazione dei requisiti Modellazione dei concetti Modellazione dei processi Figura 14 - Flusso di lavoro per la individuazione di requisiti e la costruzione del modello del dominio Nel corso della fase di elaborazione viene inoltre disegnata una prima versione del modello di progetto del sistema; tale modello introduce le classi principali che rappresentano componenti software da sviluppare per un corretto funzionamento del 18

19 sistema e rappresenta l ossatura dell architettura del sistema. Tale modello verrà arricchito nel corso della fase di sviluppo con la verifica e il dettaglio delle decisioni progettuali introdotte. Un ulteriore prodotto della fase di elaborazione può essere un prototipo: questo può essere utilizzato per verificare l esatta comprensione degli aspetti dinamici della realtà in esame Piattaforma tecnologica Nel corso della fase di elaborazione è importante definire la piattaforma tecnologica per lo sviluppo del sistema. Questa include: l insieme delle componenti di sistema utilizzate (sistema operativo, middleware, ); l insieme delle componenti da acquisire da terze parti (DBMS, software per la gestione di un workflow, software per l archiviazione ottica, ); l insieme degli strumenti di sviluppo (inclusi strumenti di supporto alle attività di analisi e progettazione, compilatori, strumenti per l automazione delle attività di test, ); Individuata la piattaforma è importante verificare le possibilità di integrazione fra le componenti individuate, allo scopo di minimizzare i rischi tecnologici: ad esempio un motore di workflow di terze parti potrebbe non integrarsi correttamente con una particolare classe di DBMS e portare a mutare le scelte già effettuate. La verifica di integrazione fra le componenti può essere condotta tramite lo sviluppo di prototipi che utilizzino un sottoinsieme delle componenti tecnologiche selezionate Architettura del sistema La fase di elaborazione ha come prodotto la specifica dell architettura del sistema da realizzare. L architettura è composta da differenti viste del sistema, quali l insieme dei requisiti, il modello concettuale, il modello di progetto e la descrizione della piattaforma tecnologica; essa individua la ripartizione di componenti del sistema secondo due coordinate principali: livelli di astrazione (componenti che poggiano l uno sull altro si collocano a differenti livelli di astrazione); partizioni ad un medesimo livello di astrazione (componenti che si collocano ad un medesimo livello di astrazione e collaborano alla realizzazione di una funzionalità comune ). L architettura individuata in questa fase è inevitabilmente soggetta a modifiche nei dettagli, ma dovrebbe guidare gli sviluppatori nel corso di tutto il processo senza richiedere modifiche sostanziali Piano di realizzazione Un ultimo prodotto della fase di elaborazione è un piano di realizzazione che fornisca: una stima dei tempi e dei costi per lo sviluppo complessivo del sistema; la scelta della durata delle iterazioni e del numero di iterazioni che comporranno la fase di sviluppo; 19

20 l allocazione degli use cases all interno delle iterazioni; l assegnazione ad ogni iterazione di una data di inizio e di fine. Il primo passo in questa attività consiste nella classificazione degli use cases in base a caratteristiche quali: la priorità per gli utenti, la presenza di rischi architetturali o di progetto o tecnologici, la difficoltà nella stima del tempo necessario al loro sviluppo. Quindi per ogni use case viene prodotta una stima del tempo e delle risorse necessarie per lo sviluppo: questa stima deve comprendere tutte le attività classiche per lo sviluppo di una porzione del sistema, analisi, progetto codifica e test. È molto importante che la stima dei tempi di realizzazione e dei costi collegati venga effettuata dalle medesime persone che assumeranno la responsabilità della realizzazione degli use cases. A questo punto viene individuata la durata massima prevista per ciascuna iterazione. Tale scelta è basata su considerazioni pratiche: non è opportuno avere iterazioni troppo brevi, perché ciascuna iterazione comporta un sovraccarico di lavoro per la gestione del suo avvio e della verifica dei risultati raggiunti; non è opportuno avere iterazioni troppo lunghe perché si perderebbero i vantaggi derivanti dall adozione di un processo iterativo, come la diminuzione della complessità e dei rischi di sviluppo per ciascuna iterazione. In letteratura i tempi indicati oscillano fra le due settimane e i due mesi di lavoro [Fowler97] [Larman97]. L allocazione degli use case all interno delle singole iterazioni deve portare a pianificare prima quegli use case che presentano un rischio di sviluppo più elevato: in tal modo è possibile far diminuire più velocemente il fattore di rischio collegato al progetto nel corso della fase di sviluppo. Alcuni use case particolarmente complessi possono essere suddivisi e realizzati in differenti versioni all interno di più iterazioni. La stima del tempo necessario alla fase di rilascio è particolarmente critica: tutte le attività di ottimizzazione, raffinamento e dispiegamento del sistema possono essere più o meno costose in funzione del tipo di sistema da realizzare (una stima riportata in [Fowler97] indica tempi fra il 10% e il 35% del tempo di sviluppo) Sviluppo In questa fase il sistema viene realizzato nel corso di una o più iterazioni. Ciascuna iterazione è simile a un progetto a se stante, completo di tutte le attività dall analisi al test. Al termine di ciascuna iterazione gli utenti collaudano il sistema verificando che esso risponda in modo completo alle caratteristiche indicate per l iterazione in corso. 20

21 Sistema 1 Sistema 2 Sistema finale Figura 15 Ad ogni iterazione gli utenti verificano la versione del sistema che viene prodotto fino ad ottenere un sistema finale che risponde a tutti i requisiti individuati Il sistema nel corso delle successive iterazioni si accresce in modo incrementale: ad ogni iterazione nuove funzionalità vengono sviluppate e aggiunte a quelle previste dagli use cases delle precedenti iterazioni. Nel corso di ogni iterazione potrà essere modificata una parte del sistema già sviluppata allo scopo di migliorare la qualità delle soluzioni già individuate 2 : tali modifiche sono tipicamente piccole, non aggiungono funzionalità, ma comportano in ogni caso l esecuzione di nuovi test sulle porzioni di sistema interessate. Poiché ad ogni iterazione si sviluppa una versione del sistema in produzione a partire da una precedente, è fondamentale che il modello del sistema consenta di costruire nuovi oggetti componendoli per mezzo di oggetti preesistenti, di raffinare un oggetto a partire da oggetti preesistenti, di modificare l implementazione di un oggetto senza modificare la sua interfaccia. Un modello object-oriented è in grado di offrire le caratteristiche desiderate: esso supporta infatti i meccanismi di aggregazione, ereditarietà e incapsulamento. Si supponga di dover realizzare un sistema per la gestione di uno sportello bancario; nel corso di delle precedenti iterazioni si è realizzata una porzione del sistema che include la classe CASSA, che rappresenta l insieme dei valori che un operatore di sportello ha a disposizione, e la classe VALORE, che rappresenta un oggetto generico cui è associato un valore in una determinata divisa. Sfruttando il meccanismo dell aggregazione è possibile specificare un nuovo tipo di oggetto, lo SPORTELLO che aggrega la CASSA, ove in tal modo si intende esprimere il fatto che la cassa è un elemento costituente di uno sportello bancario. Inoltre nel corso della medesima iterazione si potrà definire la classe ASSEGNO come specializzazione della classe VALORE, indicando per la nuova classe le caratteristiche aggiuntive che essa possiede rispetto alla classe di partenza, utilizzando il meccanismo dell ereditarietà. Infine se la classe CASSA mette a disposizione l operazione BILANCIOFINEGIORNATA sarà possibile modificare l implementazione di tale operazione, senza per questo dover modificare il modo in cui tale operazione è utilizzata da altre classi, sfruttando il meccanismo dell incapsulamento. 2 Tale tecnica è detta refactoring. 21

22 All inizio di ciascuna iterazione può essere raffinata o rivista la pianificazione già stabilita, verificando che la situazione corrente sia in accordo con quanto previsto inizialmente. Le date di chiusura di ciascuna iterazione infatti non possono essere modificate, ma se necessario il gruppo di sviluppo e gli utenti possono accordarsi per spostare alcuni use cases da un iterazione all altra. L analisi già effettuata nel corso della fase di elaborazione viene approfondita nelle iterazioni successive: il modello concettuale, il modello del flusso di lavoro e l insieme degli use cases pianificati per l iterazione sono un buon punto di partenza per discutere con gli esperti del dominio. Ogni iterazione prevede le seguenti attività: identificazione delle classi e degli oggetti necessari alla progettazione delle porzione di sistema interessata dall iterazione; specifica del comportamento delle diverse classi; analisi delle relazioni fra le classi; definizione dell interfaccia di ciascuna classe e sua implementazione. Il progetto della porzione di sistema da sviluppare può quindi essere raffinato utilizzando costrutti dell UML quali: gli interaction diagrams, che permettono di illustrare come gli oggetti del sistema dialogano fra di loro per soddisfare i requisiti del sistema; i class diagram di progetto, che consentono di definire i componenti del sistema 3. Un class diagram di progetto descrive la specifica del sistema in termini di classi e interfacce fra le classi; esso comprende: le classi, con le loro associazioni e attributi; le interfacce fra le classi; i metodi che ciascuna classe deve supportare; le relazioni di dipendenza fra le classi. La specifica di un interaction diagram consente di identificare le interazione fra gli oggetti del sistema assegnando loro delle precise responsabilità: questa attività è di fondamentale importanza perché influenza la robustezza del sistema, la possibilità di produrre componenti riutilizzabili, la flessibilità dell architettura. L assegnazione delle responsabilità agli oggetti risulta indispensabile per la produzione del sistema e richiede una profonda esperienza nello sviluppo di sistemi object oriented. Le attività di individuazione di classi e assegnazione di compiti alle classi, allo scopo di realizzare un sistema che assolva determinati compiti secondo i requisiti espressi, possono ricevere un aiuto significativo dall utilizzo di modelli di riferimento che racchiudano in se la soluzione a problemi di progettazione comuni. Tali modelli vengono comunemente chiamati design patterns [Gamma94] Rilascio Sebbene la maggior parte delle attività di sviluppo sono eseguite ciclicamente nel corso delle diverse iterazioni, alcune possono essere pianificate solamente alla fine del 3 Si ricordi invece che i class diagram a livello concettuale consentono di descrivere i concetti presenti nel dominio di interesse. 22

23 processo, quando tutte le funzionalità previste sono state realizzate e il sistema risponde in pieno ai requisiti funzionali. A questo punto dello sviluppo il sistema viene fornito agli utenti: spesso in questa fase sorgono problemi riguardanti le sue prestazioni o la sua stabilità in condizioni operative. È opportuno che l ottimizzazione del sistema sia pianificata alla fine del ciclo di sviluppo, perché può diminuire la chiarezza delle soluzioni adottate, rendendo più difficili ulteriori modifiche al sistema stesso. 3. Modellazione per mezzo dell UML Allo scopo di comprendere come utilizzare l UML si introduce in questa sezione una descrizione informale del linguaggio; tale descrizione include gli elementi atomici del linguaggio e le regole che permettono di comporre tali elementi. Quindi sono descritti i diversi diagrammi prodotti utilizzando il modello Atomi dell UML Gli atomi del linguaggio UML sono gli elementi, le relazioni fra gli elementi e i diagrammi che raggruppano elementi e relazioni di interesse. Gli elementi si articolano a loro volta in: elementi strutturali, che descrivono la parte statica del modello; elementi comportamentali, che descrivono i suoi aspetti dinamici; elementi di raggruppamento, che suddividono un modello in gruppi di oggetti; elementi di annotazione, che consentono di inserire commenti all interno del modello Elementi strutturali Gli elementi strutturali sono elementi grafici che descrivono la parte più statica di un modello, a diversi livelli di specifica. Un primo esempio di elemento strutturale è la CLASSE, che descrive un insieme di oggetti, con i medesimi attributi, operazioni e relazioni. Una classe è rappresentata per mezzo di un rettangolo all interno del quale sono elencati il nome, gli attributi e le operazioni. Paziente Nome Indirizzo Ammetti() Figura 16 - Classe Un secondo elemento strutturale è l INTERFACCIA: esso definisce un insieme di operazioni che costituiscono un servizio offerto da una classe o da un componente. L interfaccia descrive quindi il comportamento di un elemento, così come visibile all esterno, in modo completo o parziale. Un interfaccia definisce un insieme di 23