FACOLTÀ DI INGEGNERIA TESI DI LAUREA IN INGEGNERIA GESTIONALE

Transcript

1 FACOLTÀ DI INGEGNERIA TESI DI LAUREA IN INGEGNERIA GESTIONALE OOPS: un applicazione per il supporto alla progettazione e alla realizzazione di software object oriented RELATORE Prof. Toni Mancini LAUREANDO Michele Proni Anno Accademico

2 A mamma e papà, con sincera gratitudine

3 RINGRAZIAMENTI Desidero ringraziare il prof. Toni Mancini che ha accettato di portare avanti con me la sua prima tesi gestionale e mi ha seguito sia durante tutta la progettazione sia nella stesura del testo, dimostrandosi sempre disponibile e aiutandomi nella ricerca di soluzioni non banali per i problemi affrontati, lasciandomi contemporaneamente una grande autonomia. Un ringraziamento particolare va poi a tutta la mia famiglia, che mi ha sopportato durante questo periodo di lavoro e mi è stata vicina nei momenti di sconforto, quando mi sembrava di non riuscire a finire il tutto per tempo. Ringrazio specialmente i miei genitori che mi hanno permesso di giungere fino a questo punto degli studi (mamma, poi, è stata una preziosissima consulente nella redazione finale del testo). Michele Proni

4 INDICE Sommario...I Introduzione...II 1.Raccolta e raffinamento dei requisiti Il dominio applicativo I requisiti della fase di analisi I requisiti della fase di progetto I requisiti sulle funzionalità del sistema Fase di analisi Il diagramma delle classi Uno sguardo di insieme La rappresentazione del diagramma delle classi La rappresentazione del diagramma degli use case La rappresentazione del diagramma degli stati e transizioni La rappresentazione delle specifiche Operazioni e attributi Le classi Tipo Concettuale e Tipo Progettuale La rappresentazione del diagramma realizzativo Note del diagramma delle classi Il diagramma degli use case Il passaggio dalla fase di analisi alla fase di progetto La gestione delle proprietà di classe Le specifiche concettuali Le specifiche delle classi Le specifiche degli use case Le specifiche dei tipi di dato Fase di progetto Il diagramma realizzativo La struttura generale La rappresentazione del diagramma delle classi La rappresentazione del diagramma degli stati Le operazioni e gli attributi Il diagramma realizzativo Le altre parti del diagramma realizzativo Note del diagramma realizzativo Le specifiche realizzative Le specifiche realizzative delle classi Le specifiche realizzative degli use case Le specifiche realizzative delle strutture dati Conclusioni...79 Appendice A-la tabella delle responsabilità...82 Appendice B- la tabella delle corrispondenze...87 Bibliografia...88

5 SOMMARIO Questa tesi presenta il progetto relativo a OOPS (Object Oriented Project Support), un applicazione per il supporto allo sviluppo di software object oriented. Si forniranno quindi tutti i documenti creati nel corso della progettazione e si commenteranno le principali scelte progettuali compiute, analizzandone i punti di forza e di debolezza. L idea di creare un applicazione come OOPS nasce dalla considerazione che per poter sviluppare software di elevata qualità è necessario effettuare una fase di progetto particolarmente curata e disporre quindi di strumenti che ne facilitano lo sviluppo, permettendo al progettista di concentrare la propria attenzione su problemi di livello alto. Il progetto è stato elaborato prendendo come modello il processo di progettazione del software presentato nell omonimo corso, tenuto nell ambito del corso di laurea di Ingegneria Gestionale dell Università La Sapienza. In base a tale modello sono stati affrontati la raccolta e raffinamento dei requisiti, la creazione di uno schema concettuale dell applicazione e lo sviluppo di uno schema realizzativo. OOPS permette la rappresentazione e la gestione di tutti gli elementi che si incontrano nelle fasi di analisi e progetto, così come esse sono descritte nel corso sopraccitato, supportando il passaggio dall una all altra fase. L applicazione descritta inoltre presenta alcuni aspetti che possono essere ulteriormente sviluppati accrescendone le potenzialità e si presta ad essere facilmente interfacciata con applicazioni che implementano funzionalità di grande utilità nell ambito dello sviluppo di programmi, prime tra tutte quelle per le verifiche formali di correttezza del software. I

6 INTRODUZIONE La qualità del software è una problematica più che mai attuale. I sistemi software in questi ultimi anni hanno conosciuto un enorme espansione e sono divenuti fondamentali per una serie infinita di applicazioni, declinandosi in una quantità vastissima di utilizzi diversi, che vanno dal puro intrattenimento ad impieghi cruciali come nelle telecomunicazioni, nei trasporti e nella sanità (in questo caso si parla di safetycritical system ). A partire dagli anni Sessanta si è presa sempre più coscienza della necessità di adeguare le tecniche di elaborazione del software a questo continuo aumento della complessità dei sistemi informatici. La nascita del concetto di ingegneria del software (tale termine viene usato per la prima volta nel corso di una conferenza NATO nell ottobre 1968) rappresenta la risposta a questa esigenza. Con esso infatti si comincia a pensare allo sviluppo di un sistema software come ad un processo complesso di pianificazione, progettazione e produzione di un bene che deve prevedere controlli e fornire una documentazione appropriata. Nonostante i grandi sviluppi registrati in questo senso, la quasi totalità di studiosi è concorde nell affermare che il livello della qualità delle applicazioni software sia oggi ancora estremamente basso. Una prima causa di ciò va ricercata nella scarsa attenzione riservata tuttora alle fasi progettuali che precedono la creazione di un software, che comporta una scarsa coerenza di fondo tra le varie componenti del programma generando problemi di compatibilità ed estendibilità. Una seconda causa, quasi una conseguenza della prima, è che le operazioni di verifica vengono concentrate per lo più a valle della realizzazione. Questo tipo di verifiche sono però in grado rilevare solo una piccola parte dei possibili errori commessi, mentre sarebbe necessario compiere un buon numero di test particolarmente approfonditi per rimuoverne una percentuale importante. La tesi di fondo che accompagnerà questo elaborato è che lo sviluppo di un applicazione di qualità (che non abbia dimensioni elementari) non può prescindere da un accurata fase di progettazione. Un progetto ben sviluppato comporta nella produzione di un applicazione due importanti vantaggi. In primo luogo si assisterà allo spostamento delle difficoltà concettuali a monte della realizzazione. In altre parole sarà il progettista a farsi carico di ideare e rappresentare quale sarà la struttura del software che si vuole realizzare, affrontando tutte le problematiche che non sono realizzative ma che richiedono comunque un approfondito studio concettuale e analitico delle situazioni che il sistema dovrà affrontare. Il progettista nel fare questo ha il grande vantaggio di poter ragionare in maniera totalmente svincolata dai dettagli implementativi, utilizzando strumenti adatti allo scopo. Egli potrà dunque immaginare e proporre soluzioni senza doversi curare di come poi queste soluzioni dovranno essere realizzate. Anche il realizzatore trarrà un innegabile giovamento da questo approccio, potendo focalizzare la sua attenzione solo sul come realizzare, essendo il cosa già stato analizzato in sede progettuale, implementando quindi una fase realizzativa più lineare e con minori rischi di errori (che sarebbero comunque errori realizzativi e non concettuali, assumendo che la fase di progetto sia stata condotta correttamente). II

7 Il secondo importante vantaggio che consegue dal realizzare un buon progetto è la possibilità di formalizzare il progetto stesso (o parti di esso). Per formalizzazione di un progetto intendiamo la rappresentazione in logica matematica delle sue entità e dei suoi vincoli. L importanza di questa possibilità risiede nel fatto che una parte del progetto formalizzata può essere oggetto di studio attraverso i metodi formali. Grazie all utilizzo della logica matematica è infatti possibile condurre un analisi rigorosa delle proprietà logiche delle entità in esame. Quello dei metodi formali è uno strumento potente che viene attualmente utilizzato per lo più per supportare lo sviluppo di progetti critici, per i quali un eventuale fallimento comporterebbe costi (a volte non solo economici) molto ingenti, mentre il loro utilizzo sembra essere molto meno diffuso per gli altri progetti. In realtà si ritiene che l uso della logica formale anche in contesti diversi da quello dei sistemi critici porterebbe ad un generale miglioramento della qualità del software, permettendo un analisi rigorosa già in sede progettuale e consentendo quindi di eliminare numerosi errori concettuali che inevitabilmente occorrono quando si lavora su progetti di vaste dimensioni. Figura I.1 - I metodi formali nella progettazione del software III

8 Questo tipo di verifiche infatti si rivelano molto utili in tutte le fasi di progettazione di un sistema software dalla raccolta dei requisiti iniziali alla realizzazione del codice. Possono essere sfruttate per formalizzare i requisiti in input, per validare gli schemi concettuali in ouput e, una volta generato il codice, per effettuare controlli sulla sicurezza nonché generare automaticamente dei casi di test per le verifiche finali. *** Da queste considerazioni nasce l idea di progettare il software che sarà presentato in questo elaborato. Per poter realizzare una progettazione valida occorre utilizzare elementi validi che fungano da ausilio nei vari passaggi necessari per creare un sistema software. Per questo motivo OOPS vuole essere un supporto che accompagni il progettista di software object oriented nelle fasi della progettazione, intesa come sequenza strutturata di operazioni da svolgere per portare a compimento la creazione di un software, fornendo un modello che ne rappresenti tutte le varie realtà di interesse. L aspetto interessante di questa applicazione è che essa prevede funzionalità che le fanno ricoprire un ruolo attivo nella progettazione, come sarà esposto in seguito. Progettare un software non vuol dire eseguire una serie di processi automaticamente determinati, ma è frutto di una serie di scelte derivanti da considerazioni e riflessioni che un algoritmo non è in grado di effettuare e di cui solo il progettista si può fare carico, valutando di volta in volta a seconda del contesto e dei requisiti. Tuttavia nel processo di sviluppo è anche possibile incontrare un gran numero di operazioni che possono essere svolte in maniera automatica o semi-automatica, a partire da decisioni iniziali effettuate dal progettista. Lasciare che sia un software a farsi carico di queste operazioni vuol dire evitare al progettista e al realizzatore dei compiti ripetitivi, permettendo loro di concentrarsi sulle problematiche più complesse che lo sviluppo di un software comporta, in sede di progetto quanto in sede di realizzazione, rendendo possibile un generale miglioramento delle prestazioni. *** Per poter sviluppare il presente progetto è stato innanzitutto necessario utilizzare un processo di progettazione del software ben definito e strutturato che ricoprisse un duplice ruolo. Da una parte esso doveva servire come modello per l applicazione in esame, nel senso che quest ultima avrebbe dovuto fornirne una rappresentazione e supportarne le fasi. Dall altro sarebbe stato utilizzato come guida per la definizione delle varie operazioni da eseguire per la progettazione di OOPS stesso. E stato scelta a questo scopo la modalità di progettazione presentata nel corso di Progettazione del Software [1] poiché di essa si aveva una buona conoscenza e una dettagliata descrizione disponibile. Tale modalità prevede la successione di quattro fasi principali di cui verrà fornita un analisi più dettagliata nel capitolo 1: -fase di raccolta e raffinamento dei requisiti. -fase di analisi. -fase di progetto. -fase di realizzazione. IV

9 Nelle fasi di analisi e progetto vengono utilizzati come output alcuni diagrammi che vengono disegnati in linguaggio UML. anche se essi ne sfruttano solo un sottoinsieme di elementi e in maniera molto rigida. In effetti UML è forse il più diffuso linguaggio per il supporto alla progettazione di applicazioni software, ma a causa della sua vastità, risulta necessario fissare delle regole stabili e coerenti per il suo utilizzo, così come è stato fatto nel corso di Progettazione del Software, a costo di ridurne leggermente le potenzialità. Oggi sono diffusi numerosi editor che permettono di produrre diagrammi in UML. Tali applicazioni però sono per lo più strumenti prettamente grafici: consentono di disegnare i vari elementi dei diagrammi, ma in maniera del tutto destrutturata, eventualmente prevedendo varie funzionalità, come la generazione di parti di codice. In altre parole questi software, da una parte permettono di sfruttare tutto lo spettro di elementi previsto da UML, dall altra però non fanno riferimento ad una specifica modalità di progettazione. Si cercherà di far comprendere meglio questo punto con l aiuto di un esempio. Visual Paradigm 1 è uno dei più diffusi e completi editor di testo UML. Tale software non prevede la divisione tra diagramma della fase di analisi e diagramma della fase di progetto, ma consente di creare un generico diagramma (che viene chiamato Class Diagram ) con elementi grafici che possono indistintamente riferirsi ad ognuna delle due fasi progettuali. Così, se per esempio ci trovassimo nella fase di analisi del nostro processo di sviluppo, sarebbe possibile creare due classi concettuali relazionate fra loro da un un aggregazione (cioè una particolare associazione che si definisce nella fase di progetto, poiché farlo prima non avrebbe senso). Non viene dunque agevolmente supportato un processo di sviluppo coerente con i vari momenti della progettazione perché, come già spiegato, non esiste un effettiva differenziazione tra le varie fasi. Ma il limite che appare più evidente è che gli elementi così creati sono oggetti puramente grafici; ad esempio un interfaccia verrà considerata alla stregua di una classe, in quanto dal punto di vista grafico esse sono identiche (a meno dello stereotipo interface ). Ma nella realtà l oggetto classe ha delle caratteristiche differenti da quelle di un oggetto interfaccia (per esempio può contenere operazioni definite). Questo limite comporta l impossibilità di poter effettivamente creare e gestire tutti gli elementi progettuali che si incontrano nel corso della progettazione del software. Inoltre una così accentuata destrutturazione spinge necessariamente a focalizzare l attenzione sui problemi implementativi, di basso livello, scoraggiando un effettiva analisi critica a livello concettuale. Le considerazioni fin qui descritte, riguardanti Visual Paradigm, possono essere estese alla gran parte degli editor UML; è quindi evidente che l applicazione presa qui in esame non può in alcun modo rientrare in questa categoria. Un software che è invece stato oggetto di particolare studio in questa fase preliminare è UMLgc [2]. Esso consente di rappresentare e gestire l output della fase di progetto di software object oriented e di supportare la fase realizzativa ad esso relativa. In altre parole, permette di creare un diagramma realizzativo e le specifiche di operazione,in maniera coerente, rispetto a quanto visto durante il corso di progettazione del software e di generare il codice in maniera autonoma. 1 V

10 Tale applicazione però manca completamente della rappresentazione della fase di analisi e della gestione del passaggio tra questa e la fase di progetto e prevede dunque che il progettista abbia già svolto autonomamente le operazioni che precedono la realizzazione. Ha dunque costituito un buon punto di riferimento per il presente elaborato. *** Le fasi che abbiamo visto costituire dei momenti fondamentali per la progettazione di un applicazione si inseriscono nel contesto più ampio della definizione del ciclo di vita del software. Esso è rappresentato da una serie di fasi in cui viene scomposta l attività di produzione di un applicazione e della documentazione che tale attività deve fornire, giungendo così alla creazione di vari modelli. Tale modelli prevedono tutti la scomposizione del processo di sviluppo in un gruppo di attività simili. E possibile dunque distinguere, nel corso della vita di un software le seguenti fasi: -studio di fattibilità. -analisi dei requisiti. -progettazione e realizzazione. -verifica. -manutenzione. Lo studio di fattibilità di un software rappresenta, come implicito nella nozione stessa di studio di fattibilità, la fase di valutazione preliminare del progetto, atta all analisi critica dei costi e benefici che essa comporta, con l intento di comprendere l opportunità o meno di realizzare il prodotto. Viene solitamente analizzata tale opportunità da due punti di vista. Da una parte si approfondiscono i fattori relativi agli aspetti economici e di mercato, dall altra si avanzano considerazioni di tipo tecnico. Nell ambito dello studio di fattibilità gioca un ruolo di particolare importanza la raccolta dei requisiti, i quali rappresentano la descrizione delle caratteristiche che dovrà necessariamente avere l applicazione che si vuole progettare e costituiscono dunque i principali punti di riferimento per le scelte successive. Ovviamente questa operazione vede coinvolti il progettista (o il team di sviluppo) da una parte e il cliente del progetto dall altra. Se lo studio di fattibilità ha dato esito positivo, si può passare a raffinamento dei requisiti che sono stati raccolti. A partire dalle esigenze espresse dal cliente, è infatti necessario ricostruire un quadro completo dei requisiti che sono richiesti al nostro sistema.. Nella fase di progettazione e realizzazione il progettista ha il compito di creare un modello dell applicazione coerente con i requisiti e ben strutturato e quindi di realizzarlo in codice. E in questo passaggio che si inseriscono le attività di analisi, progetto e realizzazione previste nel corso di Progettazione del Software. Con la scrittura del codice termina dunque il progetto dell applicazione, ma il ciclo di vita del software non si esaurisce. Ad essa infatti fa sempre seguito una fase di verifica del prodotto. In questa sede l applicazione software viene sottoposta ad una serie di test che hanno lo scopo di analizzarne la correttezza, intesa sia come assenza di bug che come capacità del sistema di svolgere in maniera efficace i compiti e le funzionalità previste dai requisiti. Tradizionalmente la verifica si articola in due tipi di test. VI

11 Un primo tipo, che prende il nome di alfa test, rappresenta la fase iniziale della valutazione del prodotto, consente di verificarne il corretto funzionamento e l usabilità. Il secondo tipo, il beta test, rappresenta la fase conclusiva di tale verifica; esso è più ampio e approfondito del primo, in quanto tiene conto dei giudizi forniti dagli utenti finali che lo utilizzano in situazioni reali. L ultima attività prevista nel ciclo di vita del software è la manutenzione. Con questo termine si indica usualmente l insieme di interventi che vengono effettuati sul software durante il suo esercizio sia per il controllo sia per l aggiornamento e la correzione. Si rende necessario intervenire sul software dopo il suo rilascio perché durante il corso del suo ciclo di vita verosimilmente le condizioni in cui esso era stato sviluppato possono mutare e necessita quindi di particolari adeguamenti. Si è detto che i vari modelli di ciclo di vita del software esistenti prevedono tutti le attività fin qui descritte. Essi in effetti si differenziano per lo più per il diverso ordine con cui le presentano e le importanze relative assegnate. Il primo modello di ciclo di vita ad essere sviluppato fu quello a cascata. Esso prevede una netta distinzione tra le varie fasi, eseguite rigidamente in sequenza, in maniera tale che l input di una fase sia rappresentato esattamente dall output di quella precedente, senza possibilità di retroazione. A causa della sua eccessiva rigidità, con il passare del tempo tale modello è stato affiancato e sostituito da altri, come il modello iterativo e il modello a spirale. I modelli iterativi si basano sull idea di costruire il software in maniera incrementale, producendo una serie di versioni via via più complesse, dettagliate e corrette. Ogni volta che viene fornita una versione nuova se ne cercano i difetti e i possibili miglioramenti, anche con la collaborazione dell utente, in maniera da ottenere un perfezionamento costante. Figura I.2 - Schema del modello a spirale Uno dei principali modelli iterativi è il Rational Unified Process[3]. Il modello a spirale poi rappresenta in realtà un meta-modello, in quanto consente di rappresentare vari modelli di ciclo di vita. Esso introduce concetti di tipo gestionale, permettendo un analisi dei rischi. Questo modello prevede quattro fasi che possono eventualmente essere ripetute più volte. VII

12 Nella prima fase si definiscono obiettivi e alternative, nella seconda i potenziali rischi, nella terza si progetta e sviluppa il prodotto e nell ultima si effettua uno studio critico di quanto finora compiuto. *** Lo sviluppo di questi nuovi modelli si è reso necessario perché la struttura eccessivamente rigida del modello a cascata non permetteva un efficace adattamento al continuo aumento di complessità che hanno conosciuto e conoscono tuttora i sistemi informatici e alle nuove metodologie legate al paradigma object oriented. Con paradigma, intendiamo uno schema concettuale che descrive la filosofia di fondo di uno stile di programmazione determinandone il modo in cui deve formulare le soluzioni in un linguaggio di programmazione. Il paradigma object oriented guarda al software come ad un insieme di oggetti interagenti fra di loro e non come ad una sequenza di istruzioni. Ogni tipo di oggetto ha delle proprietà e delle operazioni che permettono di operare sull oggetto stesso ed è definito da una classe che ne descrive appunto gli attributi e i metodi. Questo modo di strutturare il codice permette di soddisfare alcune importanti proprietà che determinano la buona qualità del software e consente di organizzare progetti anche di grandi dimensioni in maniera efficiente. Innanzitutto l idea stessa di organizzare il codice per classi favorisce la modularizzazione: ogni classe costituisce un modulo indipendente dagli altri, in grado di compiere una serie di operazioni. Ciò determina un elevata coesione interna: ogni classe gestisce un insieme di dati omogenei e le relative operazioni. Accanto a questo abbiamo la possibilità di realizzare un buon information hiding, inteso come la necessità di minimizzare e controllare il flusso di informazioni (al di là di quelle strettamente necessarie) che un oggetto deve fornire ad un altro. In base al paradigma object oriented, infatti, viene mantenuta una rigorosa separazione di interfaccia ed implementazione, rendendo le proprietà di un oggetto che devono essere utilizzate all esterno accessibili solamente tramite l utilizzo di metodi propri. L interfaccia è dunque costituita dall insieme di messaggi che un qualsiasi elemento esterno alla classe può indirizzarle. In questa maniera si garantisce una buona manutenibilità, in quanto, mantenendo invariata l interfaccia, è possibile modificare l implementazione di una classe senza dover conseguentemente modificare l implementazione delle classi che con essa interagiscono. Un altro caposaldo del paradigma object oriented è la possibilità che una classe derivi da un'altra. Una classe derivata avrà tutte le proprietà e i metodi (i quali potranno eventualmente essere ridefiniti) della classe originale ma potrà anche definirne di nuovi. Anche questo meccanismo, che prende il nome di ereditarietà, comporta degli innegabili vantaggi. Innanzitutto garantisce un elevata manutenibilità, rendendo possibile modificare metodi e attributi comuni a più derivate semplicemente agendo sulla classe base. In secondo luogo, evidenziando gli aspetti comuni a più classi e quelli specifici di una determinata classe, permette una migliore organizzazione e comprensione del codice. Un altro tipico vantaggio derivante da questa organizzazione del software è il polimorfismo. La possibilità che ogni classe implementi il corpo di un metodo differentemente dalle altre classi, comporta che ognuna possa rispondere in maniera differente al medesimo VIII

13 messaggio; in tal modo non è necessario conoscere a quale classe appartiene l oggetto su cui si invoca l operazione. Il polimorfismo determina una generale diminuzione della complessità della realizzazione, perché viene eliminata gran parte della logica condizionale legata al trattamento di oggetti di tipologia diversa. Queste caratteristiche dell'approccio object oriented hanno favorito la progressiva diffusione dei linguaggi OO in tutti i domini applicativi e nelle realtà che richiedono volumi di dati e processi elevati. IX

14 Capitolo 1 LA RACCOLTA E IL RAFFINAMENTO DEI REQUISITI L applicazione che si vuole qui presentare si propone di supportare il processo di progettazione del software così come esso è stato descritto nel corso di Progettazione del Software. Le fasi di cui esso si compone sono, come già accennato nel capitolo introduttivo la fase di raccolta e raffinamento dei requisiti, la fase di analisi, la fase di progetto e la realizzazione. In particolar modo OOPS intende rappresentare un ausilio efficace per le fasi di analisi e di progetto. Interfacciando questo programma con l applicazione UMLgc (che si occupa della fase realizzativa) si può infatti ottenere un sistema software in grado di coprire praticamente tutte le fasi descritte nel corso sopraccitato. Per adempiere al suo scopo la presente applicazione deve essere in grado di modellare tutti gli elementi che si incontrano in entrambe le fasi di analisi e progetto, nonché di rappresentare le relazioni che intercorrono tra ognuno di essi, gestendo il passaggio dall uno all altro momento progettuale e incaricandosi di svolgere alcuni dei compiti di basso livello di cui altrimenti si dovrebbe far carico il progettista. Prima di poter cominciare la progettazione occorre definire nel dettaglio tutti gli aspetti del nostro dominio applicativo. Il lavoro in questa fase preliminare è dunque consistito nello stilare un elenco dei requisiti; esso dovrà essere rispettato dalla applicazione da progettare, partendo dalla descrizione che di essi è data nel materiale didattico disponibile del corso. Si è così giunti ad un documento di specifica raffinata, che ne rappresenta una descrizione il più possibile puntuale e non ambigua, strutturata in maniera gerarchica e affiancata da una numerazione che ne garantisce la tracciabilità. In questo capitolo sono state forniti sia una breve descrizione del dominio applicativo sia il documento di specifica raffinata dei requisiti. 1.1 IL DOMINIO APPLICATIVO I requisiti rappresentano una descrizione sia di tutto ciò che il cliente si aspetta dall applicazione da progettare, sia, eventualmente, del dominio applicativo nel quale quest ultima dovrà operare. Il progettista procede dunque con la raccolta e il raffinamento di tali requisiti. E questa una fase delicata del processo di progettazione di un software perché, come si accennava precedentemente, tutte le successive scelte progettuali verranno prese sulla base dei requisiti elaborati; questo vuol dire che se si omette o mal interpreta un requisito ciò comporterà decisioni progettuali errate, molto difficilmente correggibili. Le esigenze dell utente sono tipicamente descritte in linguaggio naturale e, come conseguenza di ciò, esse sono soggette ad ambiguità, incompletezza e talvolta anche contraddittorietà. Il compito del progettista è quello di giungere ad una descrizione dei requisiti che il sistema dovrà possedere il più possibile completa, non ambigua e strutturata. 1

15 Ovviamente questo può essere compiuto solo con la collaborazione degli stakeholder del progetto. Si procede perciò ad una classificazione dei requisiti, con una loro organizzazione in sottoinsiemi coerenti. Quindi si passa alla soluzione di eventuali conflitti e ambiguità e all assegnazione di priorità tra i vari requisiti. A questo punto viene prodotto un documento di specifica raffinata dei requisiti. Essa contiene l elenco di tutti i requisiti disambiguati e descritti mediante una struttura gerarchica per aumentarne la leggibilità. Essi vengono usualmente anche numerati con lo scopo di garantirne la tracciabilità. Quest ultima è essenziale perché da una parte permette di conoscere lo stato di avanzamento di ogni requisito e dall altra rende possibile verificare l impatto sul sistema nel momento in cui si decida di modificare un requisito. Una volta che si è giunti ad un elenco raffinato dei requisiti che soddisfa tutti gli stakeholder, si può passare all effettiva fase di progettazione e realizzazione del software in esame. L analisi è quella fase del ciclo di vita di un software in cui, partendo dai documenti di specifica dei requisiti, si costruisce un modello dell applicazione completo, leggibile e traducibile in un programma. Questo modello deve rivelarsi stabile e garantire che i rischi di errori siano sufficientemente limitati. Tale obiettivo comporta necessariamente il compiere numerose scelte strutturali, sviluppate a partire dall analisi critica delle varie possibilità. E dunque importante aver compreso a fondo le funzionalità del sistema richieste dai requisiti ed essere in grado di prevedere le possibili implicazioni derivanti dal preferire una soluzione piuttosto che un altra. Per queste ragioni, è facile comprendere come questa fase sia la parte più critica del processo di progettazione di un software. L output della fase di analisi è lo schema concettuale. Tale schema, così come è stato presentato nel corso di Progettazione del Software, si articola in tre differenti diagrammi (delle classi, degli use case, degli stati e transizioni) e nei documenti dei specifica. I diagrammi vengono elaborati utilizzando UML (Unified Modelling Language), un linguaggio sfruttato dalle metodologie per lo sviluppo della fase di analisi orientate agli oggetti. Il diagramma delle classi fa parte dei diagrammi strutturali che tale linguaggio prevede. Esso infatti permette di modellare quella che sarà la struttura di massima del presente progetto, avendo la funzione di rappresentare, mediante l utilizzo di classi UML, le varie entità di interesse per l applicazione in esame, modellando anche le loro associazioni e le operazioni che saranno in grado di svolgere. Ogni classe UML rappresenta un insieme di oggetti omogenei a cui vengono associate delle proprietà. Accanto a questo diagramma strutturale abbiamo poi gli altri due diagrammi che sono invece classificati come comportamentali. Il diagramma degli use case ha il compito di rappresentare graficamente le funzionalità che, coerentemente con i requisiti, l applicazione dovrà offrire all utente. Esso si presenta come un grafo, i cui nodi sono composti principalmente da elementi di due tipi: gli attori, che rappresentano chi (o cosa) sfrutterà tali funzionalità e gli use case che rappresentano le funzionalità stesse. Più precisamente, uno use case (letteralmente: caso d uso ) rappresenta la maniera in cui un generico attore può utilizzare l applicazione, sfruttando i servizi che essa mette a disposizione, mentre un attore rappresenta il ruolo che svolge l utente dell applicazione nell effettuare quella particolare interazione con il programma. 2

16 L ultimo tipo di diagramma che viene redatto in sede di analisi è quello degli stati e transizioni. Tale diagramma ha il compito di rappresentare le leggi che governano l evoluzione degli oggetti di una particolare classe. Gli stati modellano le situazioni in cui le proprietà dell oggetto possono essere considerate stabili, mentre le transizioni rappresentano i possibili passaggi dall uno all altro stato. Accanto a questi diagrammi vengono compilate le specifiche. E prevista una specifica per ogni classe, per ogni use case e per ogni struttura dati che si è creata. Lo scopo di queste specifiche concettuali è, in ultima analisi, quello di contenere le specifiche relative alle operazioni che sono presenti nei vari elementi (classe,use case o struttura dati). Tramite l utilizzo di un linguaggio che è un ibrido tra il linguaggio naturale e quello logico, una specifica di operazione descrive quale sarà il comportamento dell operazione e, più in dettaglio: l insieme delle condizioni che devono valere al termine dell esecuzione(le postcondizioni), a quali condizioni viene eseguita (le precondizioni), gli input di cui ha bisogno per farlo (i parametri concettuali) e il tipo di output che fornisce (il tipo di ritorno). Tutti questi documenti, come si è detto, compongono lo schema concettuale, che costituisce l output della fase di analisi. Al termine di questa fase si è ottenuto un quadro chiaro, non ambiguo e coerente del cosa l applicazione deve compiere. Il come viene analizzato nell attività successiva. Nella fase di progetto il progettista ha il compito di trasformare le varie parti dello schema concettuale in un output facilmente realizzabile, coerentemente con la tecnologia disponibile. E questo il momento in cui vengono presi in esame alcuni aspetti sul come la nostra applicazione utilizzerà le funzionalità che deve implementare e le informazioni che deve gestire. Il progettista è qui chiamato a prendere una serie di decisioni realizzative essenziali a valle di considerazioni di tipo tecnologico, come definire le architetture del programma, scegliere le strutture di rappresentazione e stabilire gli algoritmi per le operazioni previste. L insieme di queste scelte e considerazioni (che non saranno affrontate nel dettaglio per brevità) confluisce sostanzialmente in alcuni documenti: la tabella delle corrispondenze, lo schema realizzativo e le specifiche realizzative. Con la tabella delle corrispondenze si stabiliscono come dovranno essere realizzati i vari tipi di dato che sono stati previsti in analisi, tenendo conto dei tipi di dato offerti dal linguaggio di programmazione. Il diagramma realizzativo si costruisce a partire dal diagramma delle classi e rappresenta quella che sarà l architettura finale del software che si sta progettando. Per tale ragione esso contiene numerosi dettagli implementativi che in sede di analisi non vengono analizzati affatto (visibilità delle operazioni, responsabilità sulle associazioni, etc.). Creare il diagramma realizzativo comporta inoltre l effettuazione di modifiche alla struttura delle classi prevista in sede di analisi, a causa della necessità di tener conto delle caratteristiche tecniche del linguaggio di programmazione scelto. Tale diagramma sarà il punto di riferimento per la creazione del codice nella successiva fase di realizzazione. Le specifiche realizzative sono documenti simili, per la forma con cui si presentano, alle specifiche previste in sede di analisi, ma posseggono una funzione diversa. Esse hanno infatti lo scopo di descrivere puntualmente gli algoritmi con cui svolgere le operazioni previste per ciascun elemento (use case, struttura dati, classe), in maniera tale da sollevare 3

17 il realizzatore dal problema di elaborare lui stesso una possibile procedura per lo svolgimento di tali operazioni. Svolte le fasi di analisi e progetto nel modo descritto precedentemente, la scrittura del codice del programma avviene quasi in maniera automatica, nel senso che per la gran parte comporterà solo la trascrizione in codice di quanto previsto in sede di analisi, utilizzando, per la realizzazione delle varie parti del diagramma realizzativo, delle sequenze procedurali già stabilite. Anche in questa fase di realizzazione, tuttavia, è necessario utilizzare alcuni accorgimenti che tengano conto dei vincoli tecnologici posti dal linguaggio di programmazione e anche in questo caso, per brevità, essi non saranno affrontati in dettaglio. Il loro compito è comunque quello di ovviare ad alcune problematiche che si incontrano nel realizzare talune parti di codice (relative, ad esempio, alla gestione dei link tra oggetti). 1.2 REQUISITI DELLA FASE DI ANALISI 1.Dello schema concettuale sono di interesse: 1.1 Diagramma delle classi. 1.2 Diagramma degli usecase. 1.3 Diagrammi degli stati e transizioni. 1.4 Documenti di specifica. 2. Del diagramma delle classi sono di interesse: 2.1 classi. 2.2 associazioni. 2.3 generalizzazioni. 3. Delle classi sono di interesse: 3.1 nome. 3.2 attributi. 3.3 operazioni. 3.4 specifiche (eventuali). 3.5 associazioni a cui partecipa. 4. Delle associazioni sono di interesse: 4.1 nome. 4.2 classi associate con relativo ruolo una classe può partecipare a d un associazione con più ruoli. 4.3 molteplicità (una per ogni ruolo). 4.4 attributi (eventuali). 4.5 specializzazione: è possibile che un'associazione sia la specializzazione di un'altra Un'associazione può specializzare solamente una (unica) altra associazione Creare una specializzazione di un'associazione Assoc che associa n classi (A1, 4

18 A2,..., An) vuol dire creare una nuova associazione Assoc' che associa n classi (A1',A2',..., An'), con Ai' sottoclasse di Ai per ogni i=1,...,n La specializzazione Assoc' avrà gli stessi attributi di Assoc, eventualmente con molteplicità più specifiche. 5. Degli attributi sono di interesse: 5.1 nome. 5.2 molteplicità. 5.3 tipo UML. 6. I tipi UML sono di due differenti tipologie: tipi UML definiti dall utente o tipi UML base. 6.1 Dei tipi UML definiti interessano: nome specifica di tipo di dato struttura dati che li realizzerà (definita in fase progetto). 6.2 Dei tipi UML base sono di interesse: nome vincolo di specializzazione (eventuale). 7. Delle operazioni sono di interesse: 7.1 nome. 7.2 parametri concettuali i parametri concettuali sono ordinati. 7.3 tipo di ritorno, che può essere: tipo UML classe prevista in analisi. 7.4 specifica di operazione. 8. Dei parametri concettuali sono di interesse: 8.1 nome 8.2 tipo, che può essere: tipo UML classe prevista in analisi. 9. Di ogni generalizzazione vogliamo conoscere: 9.1 classe base (o super classe), solo una per ogni generalizzazione. 9.2 classi derivate (o sottoclassi), almeno una. 9.3 se è disjoint. 9.4 se è complete. 9.5 se è un is-a. 5

19 9.5.6 le is-a sono particolari generalizzazioni con una sola sottoclasse. 10. Del diagramma degli use case sono di interesse: 10.1 attori 10.2 associazioni 10.3 use case 10.4 generalizzazioni 11. Di ogni attore è di interesse: 11.1 nome use case a cui è associato (anche più di uno). 12. Di ogni use case è di interesse: 12.1 nome specifica di usecase lo usecase a cui è (eventualmente) associato tramite una relazione di tipo extend una relazione extend parte da uno (unico) use case e arriva ad uno (unico) altro use case Per ogni use case possono essere definite più relazioni extend che partono o arrivano lo use case a cui è (eventualmente) associato tramite una relazione di tipo include una relazione include parte da uno (unico) use case e arriva ad uno (unico) altro use case Per ogni use case possono essere definite più relazioni include che partono o arrivano attori a cui è associato 13. Le generalizzazioni del diagramma degli use case possono essere generalizzazioni di use case o generalizzazioni di attori tutte le generalizzazioni del diagramma use case sono di tipo "is-a" delle generalizzazioni di use case sono di interesse: lo use case base lo usecase derivato delle generalizzazioni di attori sono di interesse: l'attore base l'attore derivato. 14. Delle associazioni del diagramma use case sono di interesse: 14.1 nome (eventuale) use case associato (unico) attore associato (unico). 6

20 15. Del diagramma stati e transizioni sono di interesse: 15.1 classe (o gerarchia di classi) a cui è riferito 15.2 stati 15.3 transizioni 16. Per quanto riguarda le transizioni: 16.1 ognuna ha un evento (unico) ogni evento può essere relativo a più transizioni ognuna ha una condizione (eventuale) ogni condizione può essere relativa a più transizioni ognuna ha un azione (eventuale) ogni azione può essere relativa a più transizioni ognuna ha uno stato di origine delle transizione (unico) ognuna ha uno stato di destinazione della transizione (unico) per una data transizione stato di origine e stato di destinazione possono coincidere Poiché il diagramma degli stati deve essere deterministico, se da uno stesso stato abbiamo due transizioni in uscita T e T' aventi lo stesso evento,esse debbono avere condizioni associate mutuamente esclusive, ovvero si deve avere che (chiamando tali condizioni C e C') C è verificata se e solo se C' non è verificata Sia T una transizione che va dallo stato H allo stato K. Siano E,C,A rispettivamente l'evento, la condizione e l'azione associate alla transizione T. Il significato della transizione è il seguente: in corrispondenza dell'evento E, se l'istanza si trova nello stato H e se C è verificata, allora esegui A e passa allo stato K. 17. Per quanto riguarda gli stati: 17.1 uno stato può essere rappresentato nel diagramma delle classi mediante una sottoclasse. Di ogni stato è di interesse: 17.2 le transizioni di cui è origine le transizioni di cui è destinazione l'attività ad esso associata (eventuale) uno stato può essere rappresentato nel diagramma delle classi mediante una sottoclasse se è uno stato iniziale uno stato iniziale ha solo transizioni in uscita può esistere un solo stato iniziale per ogni diagramma stati transizioni se è uno stato finale uno stato finale non ha transizioni in uscita può esistere un solo stato finale per ogni diagramma stati transizioni. 18. Un particolare tipo di stato è il macrostato (o stato composto). Di un macrostato sono di interesse: 7

21 18.1 nome diagramma stati e transizioni che lo rappresenta lo stato iniziale ogni stato contenuto nel macrostato avrà le transizioni in uscita dal macrostato più eventuali transizioni in uscita specifiche per lo stato. 19. Esistono tre tipi di documenti di specifica: specifiche di classe, specifiche di tipo di dato, specifiche di usecase. 20. Delle specifiche di classe sono di interesse: 20.1 classe a cui sono riferite (unica) specifiche di operazione. 21. Delle specifiche di tipo di dato interessa: 21.1 attributi specifiche di operazione tipo UML definito dall utente a cui si riferisce. 22. Delle specifiche di usecase sono di interesse: 22.1 lo usecase a cui si riferisce specifiche di operazione. 23. Delle specifiche di operazione sono di interesse parametri concettuali tipo UML di ritorno precondizioni postcondizioni se l'operazione è utilizzata in una classe tali valori dovranno coincidere con i valori che sono già stati stabiliti in sede di definizione dell'operazione di classe. 1.3 REQUISITI DELLA FASE DI PROGETTO 24 In fase di progetto viene creata una tabella delle corrispondenze. 25 Della tabella delle corrispondenze sono di interesse le corrispondenze tra i tipi previsti in sede di analisi e i tipi previsti in sede progettuale (tipi linguaggio o strutture dati). 26 Delle corrispondenze sono di interesse: 26.1 tipo UML o classe prevista in analisi a cui la corrispondenza si riferisce. 8

22 26.2 tipo linguaggio, struttura dati o classe progettuale a cui la corrispondenza si riferisce un tipo UML (o una classe analisi) puo' corrispondere ad un solo tipo linguaggio (o classe progettuale o struttura dati), ma ad uno stesso tipo linguaggio possono corrispondere più tipi UML occorre prevedere che il sistema si occupi autonomamente di gestire le corrispondenze dei tipi base UML associandogli dei tipi linguaggio di default in prima istanza definiremo le corrispondenze di default solo fra alcuni tipi UML base e tipi linguaggio (più precisamente tipi Java) occorre lasciare la possibilità di aggiungere nuove corrispondenze di default con i tipi Java e definire tali corrispondenze anche per altri linguaggi nota (eventuale) per ogni tipo linguaggio o struttura dati. Ogni nota contiene: definizione degli eventuali vincoli necessari alla riduzione del dominio del tipo linguaggio l'esistenza o meno di una specifica realizzativa di questo tipo di dato. 27. Esistono tre tipi di specifiche realizzative:specifiche strutture dati,le specifiche realizzative di classe e le specifiche realizzative di usecase. 28. Requisiti delle strutture dati: 28.1 ad ogni specifica tipo di dato creata in sede di analisi corrisponde una (unica) struttura dati possono anche essere previste ulteriori strutture di dato. Di una struttura dati sono di interesse: 27.3 nome (eventuale) nuovo tipo UML previsto in sede di analisi che la struttura realizza (eventuale) operazione di classe o di use case che la struttura supporta specifica struttura dati associata. 29. Di una specifica struttura dati sono di interesse: 29.1 nome attributi, dei quali è di interesse: nome tipo linguaggio se la struttura prevede side effect se la struttura prevede condivisione di memoria come verrà effettuato il controllo di uguaglianza (uguaglianza superficiale vs profonda) specifiche realizzative di operazione. 30. I tipi del linguaggio realizzativo possono essere: 30.1 tipi base 9

23 30.2 tipi di libreria. 31.I requisiti delle specifiche realizzative di classe sono: 31.1 avremo una specifica realizzativa di classe per ogni classe prevista in sede di analisi 31.2 ogni specifica realizzativa di classe conterrà: nome della classe operazioni con relative specifiche 32.I requisiti delle specifiche realizzative di operazione sono: 32.1 in sede di progetto l'utente può creare nuove operazioni, oltre quelle già definite in sede di analisi, ma dovrà fornire sempre una specifica realizzativa di operazione ad ogni operazione corrisponde una specifica realizzativa di operazione. Delle specifiche realizzative di operazione sono di interesse: 33.3 l'operazione alla quale si riferiscono i parametri realizzativi necessari, ordinati, di cui interessa: nome tipo linguaggio, struttura dati o classe progettuali tipo linguaggio, struttura dati o classe progettuale di ritorno precondizioni algoritmo. 34 Occorre poter definire la responsabilità delle classi sulle associazioni. 35. I requisiti per la responsabilità sulle associazioni sono: 35.1 si definisce per ogni associazione prevista in fase di analisi quale classe che vi partecipa ha responsabilità su tale associazione occorre mantenere l informazione relativa a tale responsabilità se una classe partecipa ad un'associazione con molteplicità diversa da 0...* essa ha sicuramente responsabilità in questo caso il sistema deve essere in grado di assegnare autonomamente la responsabilità in caso contrario sarà l'utente a stabilire la responsabilità dell associazione per un associazione, almeno una classe deve avere responsabilità su di essa. 36. Il diagramma delle classi realizzativo si costruisce attraverso la ristrutturazione generalizzazioni, la progettazione delle classi, la progettazione degli stati/transizioni, la dichiarazione di interfacce. 37. I requisiti per la ristrutturazione delle generalizzazioni sono: 10

24 37.1 ad ogni classe base di gerarchie complete viene associata una classe abstract del diagramma realizzativo se una gerarchia è disjoint possiamo creare direttamente una gerarchia di tipo "is-a" tra ogni classe derivata e la classe base se una generalizzazione non è disjoint dovrà essere ristrutturata dall'utente è possibile prevedere che questo venga fatto in maniera completamente "manuale" dall'utente (che provvederà a creare una serie di classi per la ristrutturazione e inserirne tutti gli attributi) una seconda possibilità è che il sistema fornisca autonomamente le classi per la ristrutturazione calcolando le possibili combinazioni delle varie gerarchie non disjoint che interessano la stessa classe base. In questo caso il sistema "importerebbe" automaticamente gli attributi se una sottoclasse rappresenta un particolare stato del diagramma stati/transizioni viene fusa nella classe base, creando una nuova classe che sarà associata a tutti gli attributi, le operazioni e le associazioni cui è associata la classe base più tutti gli attributi, le operazioni e le associazioni cui è associata la classe derivata. Gli attributi della classe derivata saranno opzionali (cioè avranno molteplicità 0..1) tutte le generalizzazioni del diagramma realizzativo sono di tipo is-a. 38. i requisiti per la progettazione delle classi sono: 38.1 per ogni proprietà (attributi e operazioni) delle classi del diagramma delle classi realizzativo occorre definire il suo livello di visibilità (con tre valori ammissibili: pubblico, privato, protetto) per ogni attributo occorre stabilire se esso è noto alla nascita per ogni attributo occorre stabilire se esso è mutabile per ogni associazione in cui è coinvolta la classe sarà necessario poter rappresentare se la classe ha o meno responsabilità sull'associazione 38.4 il sistema dovrà fare le seguenti assunzioni di default: tutti gli attributi sono mutabili tutti gli attributi con molteplicità sono noti alla nascita. Gli altri attributi non sono noti alla nascita al fine di aumentare l information hiding, vanno decise quali proprietà (attributi e operazioni) delle classi possono essere accessibili dall esterno della classe nella quale sono definite e quali no i livelli di visibilità possibili sono tre: pubblico:a proprietà è accessibile nella classe dove è definita e da ogni altra classe o use case protetto: la proprietà è accessibile solo nella classe dove è definita e nelle sue sottoclassi privato: la proprietà è accessibile solo nella classe dove è definita il sistema fisserà un livello di visibilità "pubblico" per tutte le proprietà previste in sede di analisi occorre quindi permettere il tracciamento delle singole operazioni e dei singoli attributi,questo vuol dire che deve essere mantenuto in riferimento esplicito tra gli elementi creati in sede di analisi e quelli creati in sede di progetto ad essi relativi il progettista fisserà un livello di visibilità "privato" o "protetto" alle altre 11