Progettazione delle Applicazioni

6 Progettazione delle Applicazioni Questo capitolo è dedicato alla progettazione delle applicazioni. In particolare, faremo riferimento al linguaggio UML (Unified Modeling Language) prendendo in considerazione alcuni dei diagrammi previsti da tale linguaggio e, più specificatamente, il diagramma dei casi d uso, il diagramma di sequenza e il diagramma di connessione che, a nostro avviso, sono quelli maggiormente utilizzati nella Progettazione delle Applicazioni di un Sistema Informativo. 6.1 Introduzione alla Progettazione delle Applicazioni Per progettazione delle applicazioni si intende quella fase della progettazione di un Sistema Informativo che si occupa di progettare tutti i programmi che dovranno operare sui dati relativi al Sistema Informativo stesso. Tale fase della progettazione è, senza dubbio, meno standardizzata rispetto a quella precedente; esistono, infatti, svariati modi di procedere, alcuni artigianali e altri più o meno scientifici. Anche tra gli approcci scientifici vi è una grande varietà di metodologie basate, spesso, su modelli differenti. Due tra i modelli maggiormente utilizzati sono i Diagrammi di Flusso dei Dati (DFD) e lo Unified Modeling Language (UML). Noi prenderemo in considerazione proprio quest ultimo modello per svariate ragioni. Innanzitutto UML è più recente rispetto ai DFD e, quindi, è dotato di una serie di costrutti volti a risolvere problemi che, invece, non erano stati presi in considerazione al tempo della definizione dei DFD. In secondo luogo UML si sta diffondendo sempre più capillarmente tra i programmatori per cui, in alcuni cotesti, quali la programmazione orientata agli oggetti, sta diventando il modello standard de facto. In terzo luogo UML è già il meta-modello di riferimento nel contesto dell Ingegneria del Software; adottare tale modello anche nel contesto della progettazione delle applicazioni di un Sistema Informativo consente una maggiore correlazione tra queste due forme di progettazione. Nella progettazione delle applicazioni tramite UML prenderemo in considerazione tre tipologie di diagrammi previste da tale linguaggio, ovvero i diagrammi dei casi d uso, i diagrammi di sequenza e i diagrammi di comunicazione. Essi verranno esaminati in dettaglio nelle prossime sezioni. 6.2 Diagrammi dei casi d uso 6.2.1 Concetto di caso d uso I casi d uso sono una tecnica utilizzata per identificare i requisiti funzionali di un sistema e si basano sulla descrizione, in una forma quasi narrativa, delle interazioni tipiche tra gli utenti e il sistema. Per capire il loro funzionamento cominciamo a introdurre il concetto di scenario. Uno scenario è una sequenza di passi che caratterizzano una particolare interazione tra un utente e il sistema. Ad esempio, nel caso di un negozio on-line su Web, potremmo avere uno scenario Acquisto di un Prodotto così descritto:

74 6 Progettazione delle Applicazioni Il cliente naviga nel catalogo e aggiunge gli articoli desiderati in un carrello della spesa. Quando il cliente desidera pagare, prima di concludere l acquisto, deve scegliere la modalità di spedizione e fornire i dati della propria carta di credito. Il sistema controlla se la carta di credito è valida e conferma l acquisto sia immediatamente che con un successivo messaggio di posta elettronica. Questo scenario descrive come potrebbero andare le cose; tuttavia, vi potrebbero essere alcune variazioni. Innanzitutto la carta di credito potrebbe non essere valida; in tal caso si avrebbe uno scenario separato. In un altra ipotesi, un cliente abituale potrebbe aver già salvato un profilo con le preferenze relative alla spedizione e il numero di carta di credito: questo sarebbe un terzo scenario. Le modalità di interazione descritte presentano piccole differenze ma sono tuttavia molto simili. L essenza della loro somiglianza sta nel fatto che in tutti e tre gli scenari l utente ha lo stesso scopo: acquistare un prodotto. Può darsi che l acquisto non vada a buon fine, ma l intento rimane. Questa è la chiave dei casi d uso: un caso d uso è un insieme di scenari che hanno in comune lo scopo finale dell utente. In termini tecnici, gli utenti sono denominati attori. Un attore è un ruolo interpretato da un utente in relazione al sistema. Ad esempio, in un contesto commerciale, gli attori possono includere clienti, impiegati del servizio clienti, manager delle vendite e analisti di prodotto. Gli attori svolgono i casi d uso. Un singolo attore può prendere parte a più casi d uso; dualmente un singolo caso d uso può coinvolgere diversi attori. Normalmente ci sono molti clienti, per cui è possibile che persone diverse interpretino il ruolo dell attore-cliente. Può anche capitare che una singola persona ricopra la parte di più di un attore, come nel caso di un manager delle vendite impegnato nell attività di servizio clienti. Un attore non deve essere necessariamente umano: se il sistema svolge un servizio richiesto da un altro sistema, quest ultimo è anch esso un attore. In effetti attore non è il termine esatto; ruolo sarebbe molto più appropriato. I casi d uso sono ben conosciuti come una parte importante di UML. Tuttavia, la loro definizione è alquanto informale; in particolare, non c è alcuna descrizione specifica del formato in cui si deve esprimere il contenuto di un caso d uso. UML descrive meglio il diagramma dei casi d uso, che mostra le relazioni che intercorrono tra casi diversi. Tuttavia, l utilità dei casi d uso sta quasi esclusivamente nel loro contenuto, mentre il relativo diagramma ha un valore molto limitato. 6.2.2 Contenuto di un caso d uso Non esiste un modo standard per esprimere il contenuto di un caso d uso e, a seconda della situazione, possono funzionare bene formati diversi. La Figura 6.1 illustra uno stile diffuso. Acquisto di un Prodotto 1. Il cliente naviga nel catalogo e seleziona gli articoli da acquistare 2. Il cliente si avvia alla cassa check out 3. Il cliente fornisce le informazioni relative alla spedizione (indirizzo; scelta tra consegna giornaliera o entro 3 giorni) 4. Il sistema presenta un prospetto con il conto totale, comprese le spese di spedizione 5. Il cliente riempie un modulo con le informazioni sulla carta di credito 6. Il sistema autorizza l acquisto 7. Il sistema conferma immediatamente la vendita 8. Il sistema invia al cliente una e-mail di conferma Estensioni: 3a. Il cliente è abituale.1 Il sistema visualizza le preferenze memorizzate riguardanti la spedizione, il pagamento e la fattura.2 Il cliente può accettare il default o ridefinire le preferenze, in questo caso ritorna al passo 6 dello scenario principale 6a. Il sistema non autorizza l acquisto con carta di credito.1 Il cliente può inserire nuovamente le informazioni e riprovare oppure cancellare l acquisto Figura 6.1. Un esempio di caso d uso espresso in forma testuale Per prima cosa si sceglie lo scenario principale di successo (main success scenario), talvolta chiamato anche flusso d eventi principale o corso d azione base. Il corpo del caso d uso è costituito dallo scenario principale, espresso come sequenza di passi numerati.

6.2 Diagrammi dei casi d uso 75 A questo punto si possono prendere gli altri scenari e scriverli come estensioni di quello principale: questi possono risolversi con un successo, come in 3a, o con un fallimento, come in 6a. Ogni caso d uso ha un attore principale, quello che richiede un servizio al sistema. L attore principale persegue lo scopo che il caso d uso cerca di soddisfare ed è solitamente, ma non sempre, quello che dà inizio al caso con la prima chiamata. Ci possono essere altri attori con i quali il sistema comunica nel tentativo di svolgere con successo il caso d uso: questi prendono il nome di attori secondari. Un passo del caso d uso corrisponde ad un interazione tra un attore e il sistema. Dovrebbe essere sempre possibile esprimere ogni passo con una frase semplice. Non si dovrebbero mai indicare le particolarità tecniche delle azioni dell attore, quanto piuttosto il suo intento: di conseguenza, nelle descrizioni dei casi d uso, non si fa mai menzione dell interfaccia utente. Per indicare un estensione all interno di un caso d uso si deve scrivere la condizione che determina il verificarsi di una sequenza di interazioni diverse rispetto a quelle descritte nello scenario principale di successo, specificando poi i dettagli delle differenze. Prima di tutto si scrive il nome del passo in cui si può verificare la condizione, con una breve descrizione della stessa; quindi si aggiungono dei passi numerati espressi nello stesso stile dello scenario principale. Alla fine si può indicare, se necessario, in quale punto si rientra nel flusso di eventi base. I casi d uso rappresentano un ottimo mezzo per considerare le alternative a uno scenario principale di successo. Ad ogni passo è necessario chiedersi in quale altro modo potrebbero andare le cose e, in particolare, cosa potrebbe andare storto. La cosa migliore è identificare per prima cosa tutte le condizioni di estensione, senza perdere tempo ad esaminare le conseguenze di ognuna di esse. In questo modo si identificherà sin dall inizio il maggior numero possibile di estensioni e si risparmierà la fatica di tornare indietro per aggiungerle durante lo sviluppo. Se ci si accorge che un passo di un caso d uso è particolarmente complicato, è possibile esprimere tale passo come un altro caso d uso completo. In UML si dice che il primo caso include il secondo. Non c è una notazione standard per mostrare l inclusione di un caso d uso: spesso per questo si usa la sottolineatura che, di per sè, suggerisce un collegamento ipertestuale. Così, nella Figura 6.1 il primo passo include il caso d uso naviga nel catalogo e seleziona gli articoli da acquistare. L inclusione può essere utile per esprimere in modo conciso un passo complesso, che renderebbe pesante la descrizione dello scenario principale, oppure per raccogliere una sequenza di passi che si ripetono più volte nello stesso o in diversi casi d uso. È opportuno non esagerare usando la scomposizione funzionale per suddividere i casi in sotto-casi e questi in sotto-sotto-casi, ecc. Oltre ai passi che compongono gli scenari, un caso d uso può comprendere le seguenti informazioni: Una pre-condizione; essa descrive ciò di cui il sistema dovrebbe assicurarsi prima che il caso d uso possa avere inizio. Questo è utile, tra l altro, per indicare ai programmatori quali controlli si possono omettere nel codice. Una garanzia descrive ciò che il sistema assicura alla fine dello svolgimento di un caso d uso. Uno scenario di successo garantisce il conseguimento dello scopo del caso d uso; può anche darsi che risultati minori siano garantiti da qualsiasi altro scenario. Un trigger specifica precisamente l evento che dà origine al caso d uso. È opportuno evidenziare che con i casi d uso è meglio avere poche informazioni che troppe. Ogni caso deve essere conciso e di facile lettura: gli scenari troppo lunghi e dettagliati spesso finiscono per non essere neppure letti, il che li rende ben poco utili. Spesso è necessario definire con precisione dall inizio soltanto pochi casi davvero critici; gli altri possono essere sviluppati al momento dell implementazione. Non c è bisogno di mettere su carta tutto quanto; la comunicazione verbale può bastare, soprattutto se si adotta un processo iterativo in cui è più facile scrivere codice in tempi brevi che produrre documenti cartacei. 6.2.3 Diagrammi dei casi d uso UML definisce un diagramma per la rappresentazione dei casi d uso. Un esempio di diagramma dei casi d uso è illustrato in Figura 6.2. Il modo migliore di trattare un diagramma dei casi d uso è quello di considerarlo alla stregua di un sommario grafico: a qualcuno può anche ricordare il diagramma di contesto dei DFD, dato che mostra il confine del sistema e le sue interazioni con il mondo esterno.

76 6 Progettazione delle Applicazioni Imponi limiti finanziari Aggiorna i conti Manager commerciale Analizza il rischio <<include>> inclusione Sistema di contabilità Attore Calcola i costi <<include>> Valuta l affare Chiudi l affare Trader Caso d uso Venditore Confini del sistema Figura 6.2. Esempio di diagramma dei casi d uso Il diagramma dei casi d uso raffigura gli attori, i casi d uso e le loro relazioni, in particolare quali attori partecipano ai vari casi d uso e le inclusioni tra i casi d uso. È opportuno evidenziare che UML prevede anche altre relazioni tra i casi d uso oltre la semplice inclusione come, ad esempio, l estensione, indicata dalla parola chiave << extend >>. Tuttavia, è bene non esagerare con l utilizzo di queste relazioni per cui non discuteremo in dettaglio il significato di << extend >>. 6.3 Diagrammi di sequenza 6.3.1 I fondamenti Un diagramma di sequenza documenta, tipicamente, il comportamento di un singolo scenario. Il diagramma include un certo numero di oggetti e i messaggi scambiati tra essi durante l esecuzione del caso d uso. Per introdurre l argomento, consideriamo un semplice scenario in cui abbiamo un ordine e vogliamo invocare un metodo per calcolare il suo prezzo. Per farlo, l ordine deve determinare il prezzo di tutti gli elementi della linea; questo, a sua volta, dipende da regole associate ai prodotti della linea d ordine. Dopo aver raccolto il prezzo di tutti gli elementi della linea, l ordine deve calcolare uno sconto globale, che dipende, invece, da regole specifiche del cliente. La Figura 6.3 è un diagramma di sequenza che mostra un implementazione di tale scenario. Ogni partecipante è raffigurato da una riga che attraversa la pagina verticalmente dall alto in basso chiamata, convenzionalmente, linea di vita ; l ordinamento dei messaggi è determinato scorrendo la pagina verso il basso. La cosa bella dei diagrammi di sequenza è che non c è quasi bisogno di spiegarne la notazione. Ad esempio, in Figura 6.3, si vede chiaramente che un ordine invia a una linea d ordine i messaggi getquantità e getprodotto. Si può anche vedere che, a un certo punto, l ordine fa una chiamata a se stesso e che il metodo invocato manda, a sua volta, un messaggio getinfosconto a un cliente. Il diagramma, comunque, non si presta a esporre tutta l informazione utile. La sequenza di messaggi getquantità, getprodotto, getdettagliprezzo e calcolaprezzobase va inviata a ciascuna delle linee che fanno parte dell ordine, mentre il metodo calcolasconti viene invocato soltanto una volta. Ciò non può essere determinato guardando il diagramma, anche se tra poco introdurremo appositamente della notazione aggiuntiva. La maggior parte delle volte i partecipanti di un diagramma di sequenza sono oggetti; tuttavia, UML ammette che i partecipanti possano anche non essere oggetti (e proprio questa proprietà sarà

6.3 Diagrammi di sequenza 77 un Ordine una Linea d Ordine un Prodotto un Cliente calcolaprezzo getquantità messaggio trovato getprodotto partecipante linea di vita un Prodotto getdettagliprezzo ritorno calcolaprezzobase chiamata interna attivazione calcolasconti getinfosconto messaggio Figura 6.3. Diagramma di sequenza a controllo centralizzato utilizzata nella Progettazione delle Applicazioni). Per questo motivo si continuerà ad utilizzare il termine generico partecipanti che, formalmente, non fa parte della specifica. Ogni linea di vita ha una barra di attivazione che indica quando il partecipante è attivo nell interazione. Le barre di attivazione sono opzionali, ma utilissime per chiarire il comportamento dei partecipanti. È opportuno sottolineare, anche se ciò dovrebbe essere scontato, che i nomi utilizzati nel contesto dei diagrammi di sequenza devono essere significativi. Nella figura la freccia di ritorno è stata disegnata solo per la chiamata getprodotto; alcuni preferiscono non indicare i ritorni delle varie chiamate, dandole per scontate. Nel caso della Progettazione delle Applicazioni di un Sistema Informativo è opportuno mettere sempre i ritorni, tranne per quei casi in cui essi indicano semplicemente l avvenuta esecuzione con successo di una determinata azione. Il primo messaggio non scaturisce da un partecipante al diagramma, ma proviene da una fonte esterna indeterminata; per questo è chiamato messaggio trovato (found message); il termine, che può sembrare strano, deriva dall ambito telematico: si definiscono messaggi trovati quelli di cui non si conosce l origine e messaggi perduti quelli che non ottengono risposta. Un altro approccio alla modellazione dello stesso scenario è mostrato nella Figura 6.4. Il problema base è sempre quello, ma è cambiata completamente la modalità di collaborazione tra i partecipanti. L ordine chiede ad ogni linea d ordine di calcolare il suo prezzo. A sua volta la linea d ordine delega questo calcolo al prodotto; si noti che in questo caso abbiamo indicato esplicitamente il passaggio di un parametro. In modo analogo, per calcolare lo sconto, l ordine invoca un metodo del cliente. Dato che per far questo ha bisogno di informazioni provenienti dall ordine, il cliente fa una chiamata all indietro (getvalorebase) per ottenere i dati necessari. La prima cosa da notare su questi due diagrammi è la chiarezza con cui la sequenza delle chiamate evidenzia le differenze di interazione tra i partecipanti. Questa è la forza dei diagrammi di interazione: non spiegano i dettagli degli algoritmi, come i cicli e i comportamenti condizionali, ma rendono assolutamente chiare le chiamate tra i partecipanti e illustrano bene cosa fa ognuno di essi. La seconda cosa da notare è la netta differenza stilistica tra le due interazioni. Il diagramma della Figura 6.3 è a controllo centralizzato, in cui un partecipante svolge tutta l elaborazione mentre gli altri si limitano a fornire i dati. Il diagramma della Figura 6.4 usa, invece, il controllo distribuito, che prevede

78 6 Progettazione delle Applicazioni un Ordine una Linea d Ordine un Prodotto un Cliente calcolaprezzo calcolaprezzo getprezzo(quantità:numero) parametro getvalorescontato(un ordine) getvalorebase ValoreScontato ritorno Figura 6.4. Diagramma di sequenza a controllo distribuito la suddivisione dei compiti tra i partecipanti, ognuno dei quali contribuisce in parte all elaborazione dell algoritmo. Ciascuno dei due stili ha punti di forza e limiti. Noi non entreremo in dettaglio in tale argomento e lasceremo al lettore la facoltà di scegliere la tipologia di diagramma di sequenza che preferisce. 6.3.2 Creazione e distruzione dei partecipanti I diagrammi di sequenza prevedono una notazione particolare per indicare la creazione e la distruzione dei partecipanti. Un esempio di tale notazione è illustrato in Figura 6.5. un Handler interroga il database new una Query creazione new esegui un Comando sul database risultati estrae i risultati chiudi risultati distruzione causata da un altro oggetto auto-distruzione Figura 6.5. Creazione e distruzione dei partecipanti

6.3 Diagrammi di sequenza 79 Per la creazione si disegna la freccia del messaggio in modo che punti direttamente al box dell oggetto creato. Il nome del messaggio è opzionale se si utilizza il suo costruttore; spesso si indica con new in tutti i casi. Se il nuovo partecipante fa qualcosa immediatamente dopo la creazione, ad esempio eseguendo una query, la sua barra di attivazione viene disegnata direttamente attaccata al box. La distruzione del partecipante è indicata da una grossa X. Se la freccia di un messaggio termina nella X, vuol dire che un partecipante ne sta cancellando un altro; una X posta da sola alla fine della linea di vita indica che il partecipante sta distruggendo se stesso. In un ambiente dotato di garbage collection gli oggetti non sono distrutti esplicitamente; tuttavia è buona idea usare la X per indicare quando un oggetto non serve più ed è pronto per essere cancellato automaticamente. La stessa cosa si può fare in corrispondenza delle operazioni di chiusura, in seguito alle quali l oggetto non è disponibile per l elaborazione. 6.3.3 Cicli, condizioni e altro Un problema noto dei diagrammi di sequenza è la loro inadeguatezza nel rappresentare comportamento ciclico e condizionale. Se si vuole porre l accento sulle strutture di controllo è, forse, più opportuno usare un diagramma delle attività oppure ricorrere al codice stesso. I diagrammi di sequenza sono, infatti, un ottimo mezzo per visualizzare l interazione tra gli oggetti, non la logica di controllo. Premesso ciò, esaminiamo comunque la notazione. Sia i cicli che le condizioni usano frame di interazione, una sorta di cornici che servono a inquadrare ed evidenziare una parte del diagramma. La Figura 6.6 mostra un semplice algoritmo basato sul seguente pseudocodice: procedure spedizione for each (elementolinea) if (prodotto.valore > $10000) raccomandata.spedizione else normale.spedizione end if end for if (necessitaconferma) messenger.conferma end procedure In generale, i frame selezionano uno o più frammenti di un diagramma di sequenza. Ciascun frame ha un operatore e ciascun frammento può avere una guardia. La Tabella 6.1 elenca gli operatori più comuni. Operatore Significato alt opt par loop region neg ref sd Frammenti multipli in alternativa; verrà eseguito solo quello per cui è verificata la condizione. Opzionale; il frammento viene eseguito solo se la condizione specificata è verificata. Equivale ad un alt con una sola traccia Parallelo; ogni frammento è eseguito in parallelo. Ciclo; il frammento può essere eseguito più volte; la base dell iterazione è indicata dalla guardia Regione critica; il frammento può essere eseguito da un solo thread alla volta. Negativo; il frammento mostra un interazione non valida. Riferimento; si riferisce a un interazione definita in un altro diagramma. Il frame deve essere disegnato in modo da racchiudere le linee di vita coinvolte nell interazione. È possibile indicare anche dei parametri e un tipo di ritorno Sequence diagram; usato per racchiudere un intero diagramma di sequenza, qualora lo si desideri Tabella 6.1. Alcuni operatori utilizzati con i frame di interazione Per indicare un ciclo si utilizza l operatore loop con un singolo frammento, indicando la base dell iterazione nella guardia. Per rappresentare logica condizionale, è possibile utilizzare un operatore alt associando una condizione ad ogni frammento: verrà eseguito solo il frammento la cui guardia è verificata. Se si vuole esprimere l esecuzione condizionale di una singola regione, si utilizza l operatore opt. I frame di interazione sono una novità introdotta in UML 2. Di conseguenza, probabilmente, potrà capitare di vedere diagrammi disegnati precedentemente che utilizzano un approccio diverso; tra l altro

80 6 Progettazione delle Applicazioni Ordine Distributore Raccomandata Distributore Normale Messenger spedizione loop [per ogni elemento della linea] alt [valore>$10000] spedizione operatore frame [else] spedizione guardia opt [necessitaconferma] conferma Figura 6.6. Frame di interazione molte persone non apprezzano particolarmente i nuovi frame e con ogni probabilità continueranno ad usare le vecchie notazioni. La Figura 6.7 mostra alcuni elementi ora non ufficiali ma ancora diffusi. Ordine Distributore Raccomandata Distributore Normale Messenger spedizione indicatore di iterazione pseudomessaggio! non normativo alternativa * [per ogni elemento della linea] [valore>$10000] [else] spedizione messaggio asincrono (UML 1.4 e success.) spedizione no. linea id. ordine girino dei dati id. spedizione messaggio asincrono (UML 1.3 e preced.) [necessitaconferma] conferma guardia Figura 6.7. Vecchie convenzioni per la rappresentazione della logica di controllo UML 1 usava gli indicatori di iterazione e le guardie. Un indicatore di iterazione è un asterisco * aggiunto al nome di un messaggio; si può anche aggiungere del testo racchiuso tra parentesi quadre per indicare la base dell iterazione. Le guardie sono espressioni condizionali tra parentesi quadre: un messaggio associato ad una guardia viene inviato soltanto se essa è verificata.

6.4 Diagrammi di Comunicazione 81 Con il rilascio di UML 2, tutte queste notazioni sono state abolite ufficialmente dai diagrammi di sequenza ma sono ancora legali nei diagrammi di comunicazione. Gli indicatori di iterazione e le guardie possono aiutare, ma hanno anche le loro debolezze. Come si vede nella Figura 6.7, non si può indicare che due o più guardie sono in mutua esclusione. Inoltre, gli indicatori e le guardie si applicano a un solo messaggio e non funzionano bene quando diversi messaggi sono coinvolti all interno di un ciclo o di un blocco condizionale. Per risolvere quest ultimo problema si è diffusa una soluzione non ufficiale che consiste nell utilizzo di uno pseudomessaggio contenente la condizione del ciclo o la guardia. Qualcuno preferisce colorare di grigio anche la relativa barra di attivazione. Le barre di attivazione sono molto utili ma non aggiungono molto nel caso di metodi come spedizione alla cui chiamata non fa seguito nulla sul diagramma. Una convenzione comune, adottata nella Figura 6.7 è quella di omettere le barre di attivazione per queste chiamate semplici. UML non prevede una grafica standard per mostrare il passaggio dei dati; per questo scopo di devono usare i parametri dei messaggi e le frecce di ritorno. Molti vecchi metodi usavano a questo fine i girini dei dati, così chiamati per la loro forma peculiare; alcune persone amano usarli anche all interno dei diagrammi UML. Tutto sommato, nonostante ci siano molte tecniche per aggiungere informazioni condizionali e cicliche ai diagrammi di sequenza, questi non funzionano meglio del codice stesso, o, quanto meno, di un valido pseudo-codice. 6.3.4 Chiamate sincrone e asincrone I messaggi scambiati in un diagramma di sequenza possono essere sincroni oppure asincroni. Se un oggetto chiamante invia un messaggio sincrono deve aspettare che la relativa esecuzione sia terminata prima di procedere. Nel caso di un messaggio asincrono, invece, non c è bisogno di aspettare la risposta e si può procedere nella computazione. Le chiamate asincrone sono comuni nelle applicazioni multithread e nel middleware perchè aumentano l efficienza del sistema e riducono le dipendenze temporali; tuttavia, esse rendono più difficoltosa l attività di debugging. In UML 2 questo fatto si rappresenta utilizzando differenti punte per le frecce: le punte piene, infatti, indicano un messaggio sincrono, quelle composte da due segmenti sottili un messaggio asincrono. La differenza tra i diversi tipi di freccia è molto difficile da notare. Tra l altro è una modifica non compatibile all indietro introdotta nella Versione 1.4 di UML: prima i messaggi asincroni si indicavano usando una mezza punta di freccia, come si vede nella Figura 6.7. 6.3.5 Conclusioni Al termine di questa presentazione sui diagrammi di sequenza cerchiamo di trarre qualche conclusione. I diagrammi di sequenza sono particolarmente adatti ogni volta che si vuole rappresentare il comportamento di un insieme di oggetti all interno di un singolo caso d uso. I diagrammi di sequenza eccellono nel mostrare le collaborazioni tra gli oggetti, ma non sono altrettanto precisi quando si tratta di definire il loro comportamento. Se si vuole documentare il comportamento di un singolo oggetto in diversi casi d uso lo strumento da utilizzare è il diagramma di stato. Se si vuole analizzare il comportamento attraverso più casi d uso o più thread, lo strumento da utilizzare è il diagramma delle attività. Altri utili diagrammi di interazione sono quelli di comunicazione e temporizzazione: i primi sono ottimi per mostrare le connessioni, i secondi vanno usati per rappresentare vincoli temporali. 6.4 Diagrammi di Comunicazione I diagrammi di comunicazione sono un tipo speciale di diagramma di interazione che enfatizza lo scambio di dati tra i partecipanti. Invece di indicare ogni partecipante con la sua linea di vita e rappresentare l ordine dei messaggi in base alla posizione lungo l asse verticale, come fa il diagramma di sequenza, quello di comunicazione permette di disegnare i partecipanti in qualsiasi posizione aggiungendo collegamenti per mostrare le connessioni.

82 6 Progettazione delle Applicazioni La sequenza temporale di queste ultime è espressa mediante la numerazione dei messaggi. In UML 1 questi erano chiamati diagrammi di collaborazione; il nome ha avuto successo e, probabilmente, passerà parecchio tempo prima che la gente si abitui al cambiamento (che è stato introdotto per evitare confusioni con le Collaborazioni). La Figura 6.8 è un diagramma di comunicazione a controllo centralizzato che rappresenta la stessa interazione della Figura 6.3. Come si può vedere, questo tipo di diagramma permette di mostrare i collegamenti tra i partecipanti. auto-collegamento! non normativo 1: calcolaprezzo 7: getinfosconti 5: calcolaprezzobase() 6: calcolasconti() un Ordine un Cliente 4: getdettagliprezzo 2: getquantita() 3: getprodotto() tipo del collegamento temporaneo <<Local>> una Linea d Ordine un Prodotto Figura 6.8. Diagramma di comunicazione a controllo centralizzato Oltre a quelli che rappresentano associazioni, è possibile includere nel diagramma anche collegamenti temporanei, che esistono solo per la durata dell interazione. In questo caso, il collegamento << local >> da Ordine a Prodotto è una variabile locale. Altri tipi di collegamenti temporanei sono << parameter >> e << global >>. Queste parole chiave erano previste in UML 1 ma nella nuova versione non lo sono più; è, però, probabile che continueranno ad essere usati. Lo stile di numerazione dei messaggi della Figura 6.8 è semplice ed è quello comunemente usato; tuttavia, in effetti, non è strettamente legale. Per essere del tutto aderenti alla specifica UML, sarebbe necessario adottare un sistema di numerazione decimale nidificato, come si vede nella Figura 6.9. Lo scopo di questa tecnica sta nel risolvere l ambiguità nella sequenza delle chiamate in presenza di auto-collegamenti di un oggetto a se stesso: nella Figura 6.4 si vede chiaramente che il metodo getinfosconti viene invocato all interno di calcolasconti. Usando la semplice numerazione progressiva della Figura 6.8, invece, non si può capire se getinfosconti è invocato da calcolasconti o, più in generale, dall interno del metodo calcolaprezzo. La numerazione nidificata risolve questo problema. Nonostante non sia formalmente legale, molti preferiscono la semplice numerazione progressiva. Nei casi in cui ci sono molte chiamate nidificate, i numeri corrispondenti possono diventare davvero difficili da leggere: non è certo immediato cogliere la posizione della chiamata 1.1.1.2.1.1 all interno di una sequenza. In questi casi, la cura contro l ambiguità può essere peggiore del male. Oltre ai numeri, i messaggi possono essere etichettati anche con delle lettere: questo significa che appartengono a diversi thread di controllo. I messaggi A5 e B2, quindi, apparterranno a thread diversi; i messaggi 1a1 e 1b1 corrisponderanno a thread differenti in esecuzione parallela all interno del messaggio. Le lettere dei thread si possono usare anche sui diagrammi di sequenza, benchè questi non rappresentino visivamente la concorrenza.

6.5 Progettazione delle Applicazioni mediante UML 83 auto-collegamento 1: calcolaprezzo() 1.4: calcolaprezzobase() 1.5: calcolasconti() un Ordine 1.5.1: getinfosconti() un Cliente 1.3: getdettagliprezzo() 1.1: getquantita() 1.2: getprodotto() una Linea d Ordine un Prodotto Figura 6.9. Diagramma di comunicazione con numerazione decimale nidificata I diagrammi di comunicazione non definiscono una notazione precisa per esprimere la logica di controllo. È possibile usare indicatori di iterazione e guardie, così come sono stati introdotti nella Sezione 6.3.3; tuttavia, questi elementi da soli non sono sufficienti a specificare completamente la logica. Manca anche una notazione speciale per la creazione/distruzione di oggetti, ma per questo si usano comunemente le parole chiave << create >> e << delete >>. Il problema principale dei diagrammi di comunicazione è decidere quando usarli, preferendoli ai più diffusi diagrammi di sequenza. Gran parte della scelta dipende dalle preferenze personali: in genere sembra che i progettisti preferiscano i diagrammi di sequenza. Volendo spiegare la differenza in modo più razionale, potremmo dire che i diagrammi di sequenza esprimono meglio la successione delle chiamate, mentre quelli di comunicazione enfatizzano il collegamento tra gli oggetti. 6.5 Progettazione delle Applicazioni mediante UML La Progettazione delle Applicazioni condotta tramite UML può essere suddivisa nei seguenti passi: individuazione dei gestori di base, ovvero dei gestori che interrogano e manipolano direttamente la base di dati sottostante; costruzione del Diagramma dei Casi d Uso; costruzione dei Diagrammi di Sequenza e/o dei Diagrammi di Comunicazione per ciascun caso d uso individuato. Nel seguito illustreremo in dettaglio ciascuno di questi passi facendo riferimento ad uno specifico scenario, ovvero la progettazione del Sistema Informativo a supporto di un hotel descritto nella Sezione 3.5.1. 6.5.1 Individuazione dei gestori di base Come detto in precedenza, un gestore di base è un gestore che ha il compito di interrogare e manipolare direttamente le relazioni che costituiscono la base di dati. In generale, vi è un gestore di base per ciascun concetto importante definito nella realtà di interesse; pertanto, in via del tutto generale, possiamo dire che: se la realtà di interesse è espressa mediante il modello Entità/Relazione, vi sarà un gestore di base per ciascuna entità; gestori di base possono essere definiti anche per le associazioni più importanti;

84 6 Progettazione delle Applicazioni se la realtà di interesse è espressa mediante il Diagramma delle Classi, vi sarà un gestore di base per ciascuna classe; gestori di base possono essere definiti anche per le classi di associazione più importanti; se la realtà di interesse è espressa mediante il modello relazionale 1 vi sarà un gestore di base per ciascuna relazione che rappresenta un concetto nonchè per ciascuna relazione che rappresenta associazioni tra concetti e che gioca un ruolo importante nel contesto di riferimento. Ciascun gestore di base deve prevedere almeno le seguenti operazioni: inserimento; rimozione; modifica; interrogazione; ulteriori operazioni potranno essere definite laddove necessario. Se si sta operando con un linguaggio di programmazione ad oggetti, un gestore di base non è altro che una classe avente per attributi gli attributi della corrispondente entità (risp., associazione, classe, tabella) e per metodi almeno i metodi di inserimento, rimozione, modifica e interrogazione dei dati. Se, invece, si sta operando con un linguaggio di programmazione non orientato agli oggetti ciascun gestore può essere visto come un processo a sè stante che, tra i suoi dati di supporto, possiede almeno tante variabili per quanti sono gli attributi della corrispondente entità (risp., associazione, classe, tabella); tale processo prevede, inoltre, opportune funzioni per la gestione dell inserimento, della rimozione, della modifica e dell interrogazione dei dati. Per quanto riguarda la nostra realtà di interesse, è possibile pensare ai seguenti gestori di base: Cliente; Camera; Prenotazione; Assegnamento; ; Servizi Extra. 6.5.2 Costruzione del Diagramma dei Casi d Uso Questa fase ha lo scopo di individuare quali sono i casi d uso relativi alla realtà di interesse e di costruire il corrispettivo diagramma. Per quanto riguarda la nostra realtà di riferimento, il Diagramma dei Casi d Uso è illustrato in Figura 6.10. 6.5.3 Costruzione dei Diagrammi di Sequenza o dei Diagrammi di Comunicazione per ciascun caso d uso La terza fase della Progettazione della Applicazioni di un Sistema Informativo tramite UML ha lo scopo, una volta individuati i casi d uso relativi al Sistema Informativo che si vuole costruire, di indicare, per ciascun caso d uso, e quindi per ciascun scenario di interesse, quali sono i flussi informativi scambiati tra i vari gestori di base e tra questi e l esterno. Lo scambio dei flussi informativi può essere rappresentato, indifferentemente, mediante i Diagrammi di Sequenza oppure mediante i Diagrammi di Comunicazione. A titolo di esempio, nelle Figure 6.11, 6.12, 6.13, 6.14, 6.15, 6.16, 6.17, 6.18, 6.19, 6.20, 6.21 e 6.22 illustriamo i Diagrammi di Sequenza e i Diagrammi di Comunicazione relativi alla nostra realtà di riferimento. Si noti che, per questioni di praticità e di layout, mentre nei Diagrammi di Sequenza vengono esplicitamente evidenziati i flussi di ritorno, nei Diagrammi di Comunicazione tali flussi vengono mantenuti impliciti. L unica eccezione sono i flussi di ritorno verso l esterno che saranno esplicitamente rappresentati anche nei Diagrammi di Comunicazione. A margine di questa discussione consideriamo il Diagramma di Sequenza di Figura 6.15 e il Diagramma di Comunicazione di Figura 6.16. In essi il Processo Polizia è visualizzato con bordo spesso; 1 Ciò sarebbe già in sè una cosa poco auspicabile dal momento che una realtà di interesse dovrebbe essere espressa innanzitutto mediante un modello concettuale.

6.5 Progettazione delle Applicazioni mediante UML 85 Verifica Disponibilità <<include>> Procedura Prenotazione <<include>> Utente Procedura Assegnamento Amministratore Addebito Servizio Extra Emissione Gestione Statistiche Figura 6.10. Diagramma dei Casi d Uso relativi ad un Sistema Informativo per la gestione di un hotel Camera Prenotazione Richiesta Disponibilità Individua Camere Candidate loop Richiesta Disponibilità [Per ciascuna camera candidata] Risposta Disponibilità Assembla Risultato Risposta Disponibilità Figura 6.11. Diagramma di Sequenza relativo al caso d uso Verifica Disponibilità 2: Individua Camere Candidate 4: Assembla Risultato 1: Richiesta Disponibilità 5: Risposta Disponibilità Camera 3: * [Per ciascuna camera candidata] Richiesta Disponibilità Prenotazione Figura 6.12. Diagramma di Comunicazione relativo al caso d uso Verifica Disponibilità

86 6 Progettazione delle Applicazioni Prenotazione Camera Cliente Richiesta Prenotazione Rich. Info. Camera Risp. Info. Camera alt [il cliente è registrato e i dati sono aggiornati] Richiesta Dati Cliente Risposta Dati Cliente [else] Dati Cliente Registrazione Dati Cliente Registrazione Prenotazione Registrazione Risposta Prenotazione Figura 6.13. Diagramma di Sequenza relativo al caso d uso Procedura Prenotazione 4: Registrazione Prenotazione 1: Richiesta Prenotazione 3b1: [il cliente non è registrato o i suoi dati non sono aggiornati] Dati Cliente Prenotazione 2: Richiesta Info. Camera Camera 5: Registrazione Docum. 3a: [il cliente è registrato e i dati sono aggiornati] Richiesta Dati Cliente 3b2: [il cliente non è registrato o i suoi dati non sono aggiornati] Registrazione Dati Cliente Cliente Figura 6.14. Diagramma di Comunicazione relativo al caso d uso Procedura Prenotazione

6.5 Progettazione delle Applicazioni mediante UML 87 Assegnamento Camera Cliente Polizia Richiesta Assegnamento Rich. Info. Camera Risp. Info. Camera alt [il cliente è registrato e i dati sono aggiornati] Richiesta Dati Cliente Risposta Dati Cliente [else] Dati Cliente Registrazione Dati Cliente Registrazione Assegnamento Registrazione Scheda Notifica Risposta Assegnamento Figura 6.15. Diagramma di Sequenza relativo al caso d uso Procedura Assegnamento 4: Registrazione Assegnamento 1: Richiesta Assegnamento 3b1: [il cliente non è registrato o i suoi dati non sono aggiornati] Dati Cliente Assegnamento 2: Richiesta Info. Camera Camera 7: Risposta Assegnamento 6: Scheda Notifica 3a: [il cliente è registrato e i dati sono aggiornati] Richiesta Dati Cliente 3b2: [il cliente non è registrato o i suoi dati non sono aggiornati] Registrazione Dati Cliente 5: Registrazione Docum. Cliente Polizia Figura 6.16. Diagramma di Comunicazione relativo al caso d uso Procedura Assegnamento

88 6 Progettazione delle Applicazioni Richiesta Servizio Extra Servizio Extra Cliente Registraz. Prenot. Richiesta Dati Cliente Risposta Dati Cliente Registrazione Addebito Figura 6.17. Diagramma di Sequenza relativo al caso d uso Addebito Servizio Extra 2: Info. Servizio Extra 1: Richiesta Servizio Extra Servizio Extra 3: Richiesta Info. Cliente Cliente 4: Registrazione Addebito Figura 6.18. Diagramma di Comunicazione relativo al caso d uso Addebito Servizio Extra ciò sta ad indicare che si tratta di un processo separato esterno al flusso di controllo e che non dipende dal flusso di controllo corrente.

6.5 Progettazione delle Applicazioni mediante UML 89 Richiesta alt [Il documento desiderato è una fattura] Emissione Fattura [Il documento desiderato è una ricevuta] Emissione Ricevuta Figura 6.19. Diagramma di Sequenza relativo al caso d uso Emissione 1: Richiesta 2a: [Il documento desiderato è una fattura]: Emissione Fattura 2b: [Il documento desiderato è una ricevuta]: Emissione Ricevuta Figura 6.20. Diagramma di Comunicazione relativo al caso d uso Emissione Statistiche Prenotazione Assegnamento Cliente Richiesta Statistiche alt [L Ammin. desidera statistiche su Pren.] [L Ammin. desidera statistiche su Ass.] Rich. Stat. Prenot. Risp. Stat. Prenot. Richiesta Statistiche Assegnamenti Risposta Statistiche Assegnamenti [L Ammin. desidera statistiche sui Clienti] Richiesta Statistiche Cliente Risposta Statistiche Cliente [L Ammin. desidera statistiche sui Ricavi] Richiesta Statistiche Ricavi Risposta Statistiche Ricavi Risposta Statistiche Figura 6.21. Diagramma di Sequenza relativo al caso d uso Gestione Statistiche

90 6 Progettazione delle Applicazioni 1: Richiesta Statistiche 3: Risposta Statistiche Statistiche 2a: [L Ammin. desidera statist. su Pren.] Richiesta Statistiche Prenotazioni Prenotazione 2b: [L Ammin. desidera statist. su Assegn.] Richiesta Statistiche Assegnamenti 2c: [L Ammin. desidera statist. sui Clienti] Richiesta Statistiche Clienti 2d: [L Ammin. desidera statist. sui Ricavi] Richiesta Statistiche Ricavi Assegnamento Cliente Figura 6.22. Diagramma di Comunicazione relativo al caso d uso Gestione Statistiche