Sei sulla pagina 1di 768

A Francesco e Anna, miei dolci genitori: a voi cui tutto devo.

Silenzio assordante Eco smarrita Frastuono di preghiera inconsolata sussurrata nella notte.

Introduzione
Nemo propheta in patria

Prefazione
Probabilmente gran parte dei lettori di questo libro conosceranno svariati trattati relativi alla programmazione Object Oriented, magari in Java, e avranno partecipato alla costruzione di sistemi informatici pi o meno complessi. Altrettanto probabilmente, una buona percentuale avr constatato che non sempre il modo di produrre sistemi software segue un approccio, per cos dire, ingegneristico basato su un processo formale e che spesso il linguaggio di modellazione unificato (UML, Unified Modeling Language) recita un ruolo troppo marginale. Il problema che, sebbene lo UML sia un linguaggio magari di modellazione ma pur sempre un linguaggio non sempre chiaro come, quando e perch utilizzarlo. Ebbene, il presente libro si prefigge lobiettivo di fornire al lettore tutte le informazioni necessarie per utilizzare lo UML nel contesto dei processi di sviluppo del software, utilizzando un approccio operativo che per non trascuri limprescindibile teoria. Il libro stato scritto riducendo al minimo i prerequisiti, e conferendo particolare importanza agli esempi, specialmente quelli tratti da progetti reali, nella convinzione che un particolare legame con la realt quotidiana dellambiente lavorativo sia il mezzo pi idoneo per focalizzare rapidamente i concetti esposti nonch per procurare allautore vitto e alloggio a spese dello Stato. Ci nondimeno si cercato di non trascurare il pubblico pi esigente, inserendo nel libro diversi paragrafi di livello tecnico superiore. Si tratta tuttavia di sezioni dedicate a lettori che desiderano lapprofondimento, ben circoscritte e assolutamente opzionali, quindi non indispensabili alla comprensione di quanto

Introduzione

esposto. Il libro pertanto si presta ad essere fruito secondo diversi livelli di difficolt in base a necessit e obiettivi del lettore. Questo libro conferisce particolare enfasi a due grandi tematiche portanti: analisi dei requisiti utente e analisi e disegno del sistema. Quindi gli strumenti dello UML analizzati pi approfonditamente sono sia quelli utilizzati durante le relative fasi del processo di sviluppo del software sia quelli utilizzati pi frequentemente nel ciclo di vita del software: anche in questo contesto come rimarcato dallo stesso James Rumbaugh vale la famosa equazione dell80/20: l80% della modellazione di un sistema, tipicamente, necessita del 20% dei concetti dello UML. Ma quali sono i motivi che hanno spinto a scrivere un altro libro dedicato allo UML? Le risposte potrebbero essere due e molto semplici: perch in lingua italiana (o almeno in un suo surrogato); perch i libri dei Tres Amigos (James Rumbaugh, Ivar Jacobson, Grady Booch) pur essendo uno straordinario ausilio guai a non averne una copia, anche se mai aperta, poich si rischierebbe di suscitare giudizi di scarsa professionalit forse risentono del limite di essere poco accessibili a un pubblico non espertissimo di progettazione Object Oriented. Lidea di fondo del libro fornire un diverso livello di astrazione: i libri dei Tres Amigos offrono un livello molto elevato quasi filosofico mentre il presente vuole essere decisamente vicino alla pratica nel tentativo di fornire un supporto concreto a tutti coloro che utilizzano, o vorrebbero utilizzare, lo UML quotidianamente per costruire sistemi che funzionano. A tal fine sono stati utilizzati moltissimi esempi che, sebbene finiscano per rendere i capitoli decisamente corposi, sono comunque sezioni opzionali bench costellate di utili riflessioni. La scrittura del libro iniziata quasi congiuntamente alla pubblicazione della versione 1.2 dello UML e abbraccia un periodo di due anni di lavoro matto e disperatissimo. I contenuti sono costantemente revisionati e aggiornati sia al fine di renderlo via via conforme alle nuove specifiche, sia per integrare esempi sempre pi interessanti attinti dallesperienza lavorativa. Nella sua versione attuale, la variante dello UML di riferimento la 1.4, sebbene lautore stia controllando da vicino i lavori relativi alla versione 2. Tra le righe del libro fa capolino l(auto)ironia dellautore, coadiuvata alloccorrenza da quella dei collaboratori: ci sia al fine di rendere largomento meno gravoso, sia per evidenziare con spirito grottesco le distorsioni riscontrate nel modo di produrre il software in molte realt organizzative. Troppo spesso i vari manager sono sfrenatamente concentrati a consegnare i sistemi senza curare minimamente la crescita professionale del proprio personale e quindi, in ultima analisi, la qualit dei sistemi prodotti. Non il software che rifiuta lingegnerizzazione, ma i tecnici che rimangono intimoriti dalla progettazione:

UML e ingegneria del software: dalla teoria alla pratica

troppo spesso si ha la sensazione che la produzione del software sia ancora concepita come unarte piuttosto che come una scienza.

A chi rivolto
Questo libro prevede un pubblico di potenziali lettori piuttosto vasto: tutti coloro che hanno a che fare con progetti basati sul paradigma Object Oriented (o Component Based). In particolare, potrebbe risultare vantaggioso per figure professionali che vanno dai tester ai programmatori, dagli architetti ai capi progetto, dai business analyst a, perch no, persone con ruoli a carattere pi commerciale. Gli architetti costituiscono sicuramente il pubblico ideale: loro, in effetti, dovrebbero essere in grado di utilizzare proficuamente il linguaggio durante tutta la fase di sviluppo del software, dallanalisi dei requisiti, al disegno del sistema, ai test di accettazione. I vantaggi che potrebbero ricavarne i programmatori scaturiscono essenzialmente dalla capacit di leggere i diagrammi forniti dagli architetti, per tradurli in codice e infine aggiornarli per far s che il disegno finale corrisponda alla reale implementezione del sistema. Non peccato mortale se limplementazione varia, entro certi limiti, dal modello di disegno sia perch non opportuno scendere eccessivamente in dettaglio nel disegno del sistema, sia perch non sempre possibile prevedere tutto fin dallinizio, inclusi malfunzionamenti di software fornito da terze parti. Nel mondo ideale la codifica dovrebbe essere immediata e senza troppe variazioni: nella realt non sempre cos. Variazioni in corso dopera sono normali fintantoch non stravolgano il disegno stesso. Sempre i programmatori, durante la codifica del disegno, dovrebbero avere bene in mente i casi duso oggetto dellimplementazione: essi descrivono la sequenza di azioni da svolgere nel caso in cui tutto funzioni correttamente e per gestire eventuali anomalie che potrebbero verificarsi. Per ci che concerne i capi progetto, in molti casi essi potrebbero aumentare la qualit del proprio lavoro utilizzando i diagrammi dei casi duso (use cases diagram) e pi in generale la relativa vista (use cases view, vista dei casi duso), sia al fine di coadiuvare il team nella cattura dei requisiti utente nel miglior modo possibile, sia per poter monitorare adeguatamente lo stato di avanzamento del progetto, sia per riuscire ad avere una pi intima conoscenza di cosa si sta costruendo. Il cliente alla fine verifica che il sistema realizzi correttamente quanto sancito nella use case view presente nel documento di analisi dei requisiti. I team leader, tra le altre attivit, potrebbero trarre enorme beneficio dallutilizzo dello UML per assolvere alle tipiche funzioni di coordinamento, supporto e addestramento del team e per coadiuvare i capi progetti nellanalisi della tempificazione al fine di renderla quanto pi reale possibile La tempificazione non esclusivo esercizio di fantasia: tempificare con successo non significa giocare al lotto con Microsoft Project. I tester dovrebbero essere in grado di validare, o, se si preferisce, di individuare malfunzionamenti eseguendo i famosi test a scatola nera (black box tests) per verificare che il sistema effettivamente aderisca alle specifiche catturate sempre dalla use case view.

Introduzione

Per terminare, i business analyst, nel loro lavoro di analisi dellorganizzazione del cliente e del relativo business, potrebbero utilizzare i diagrammi dello UML, per realizzare il famoso documento dei requisiti utente, modellando una prima versione del modello dei casi duso. Ci apporterebbe due validi risultati: semplificazione del lavoro dei tecnici responsabili delle fasi seguenti e accrescimento del livello di professionalit e della qualit della documentazione prodotta.

Consigli per la lettura


Visto il grande impegno profuso nel redigere il presente libro, verrebbe voglia di consigliarne una lettura basata sul seguente algoritmo:
Iterator pagineLibro = libroUML.iterator(); while ( pagineLibro.hasNext() ) { utente.read( pagineLibro.next() ) }

Chiss che ci possa essere realmente utile e possa fornire validi spunti soprattutto a coloro che non hanno molta esperienza dello UML e dei processi di sviluppo. Si comunque consapevoli di quanto poco e prezioso sia il tempo: si cercato di soddisfare le esigenze anche di coloro che sono desiderosi di arrivare direttamente al nocciolo degli argomenti senza perdere troppo tempo in tematiche ritenute meno interessanti. A tal fine il libro stato strutturato in modo da favorirne una fruizione diversificata dipendente dalle necessit dei singoli lettori. In particolare vi sono sezioni di elevata complessit dedicate ai lettori pi esigenti, che per possono essere assolutamente ignorate senza per questo precludersi la possibilit di comprendere quanto riportato negli altri paragrafi. Altre parti invece sono dedicate a considerazioni relative al processo di sviluppo: di nuovo, i lettori che volessero concentrare lattenzione unicamente sullo UML possono semplicemente sorvolare tali paragrafi. Infine, vi sono interi paragrafi dedicati allo stile da utilizzarsi per disegnare i vari diagrammi. Lobiettivo pertanto migliorare la forma senza entrare nel merito della semantica, quantunque le due caratteristiche non possano essere trattate in maniera completamente separata. Sebbene non siano di importanza fondamentale, questi paragrafi non sono neanche originati da un vezzo estetico. Si tratta di una serie regole che permettono di rendere i diagrammi pi eleganti, armoniosi, semplici, in poche parole pi accattivanti. Ci molto utile perch rende i diagrammi pi facilmente comprensibili, memorizzabili, concorre a ridurre le barriere psicologiche che spesso si innalzano nella mente dei fruitori dei diagrammi, ecc. I primi due capitoli (UML: che cosa , che cosa non e UML: struttura, organizzazione, utilizzo), considerata la genericit degli argomenti affrontati, possono risultare dispersivi

UML e ingegneria del software: dalla teoria alla pratica

e a tratti tediosi. Sebbene non siano di importanza fondamentale, risultano utili per chiarire fin da subito cosa sia lo UML e il suo rapporto con le tecnologie attigue. A partire dal capitolo relativo ai casi duso, tutto diviene pi operativo e quindi scorrevole: si entra nel vivo dello UML! Infine presente un numero decisamente elevato di esempi attinti dal mondo del lavoro; tutti coloro certi di aver capito possono placidamente concentrarsi solo su alcuni di essi ignorando i restanti.

Struttura
Questo libro stato strutturato in capitoli autonomi, in ognuno dei quali viene esaminato approfonditamente uno specifico argomento, cercando di limitare al massimo i rimandi ai capitoli successivi: non quindi necessario rincorrere gli argomenti per tutto il testo. Si tentato di ricostruire una sorta dunit dazione: Milan Kundera non approverebbe. Ci se da un lato offre evidenti vantaggi, dallaltro genera la necessit di introdurre inevitabili ridondanze

Capitolo 1 UML: che cosa , che cosa non


Obiettivo del primo capitolo di presentare lo UML inquadrandolo nel suo contesto, chiarendo fin dal principio il rapporto esistente con le altre tecniche/metodologie che lo circondano. Il capitolo si apre con una breve panoramica storica dello Unified Modeling Language e delle motivazioni che hanno spinto i Tres Amigos ad affrontare lo straordinario progetto di un linguaggio di modellazione unificato. Si prosegue con una descrizione di cosa sia e cosa non sia lo Unified Modeling Language, della sua architettura e di quali siano gli obiettivi. Successivamente viene affrontato il tema dei pi diffusi processi di sviluppo del software e, in particolare, The Unified Software Development Process, Use Case Driven Object Modeling with UML, il Rational Unified Process (RUP), leXtreme Programming (XP) e lAgile Modeling (AM).

Capitolo 2 UML: struttura, organizzazione, utilizzo


Il secondo capitolo interamente dedicato a una panoramica dello UML: vengono presentate le viste, i diagrammi e i meccanismi di estensione forniti dallo UML per aumentarne semantica e sintassi. Sono inoltre introdotti i profili, ossia collezioni di meccanismi di estensione predefiniti da utilizzarsi durante la modellazione di sistemi che utilizzano architetture standard quali ad esempio CORBA ed EJB (Appendice C) o per compiti specifici come la modellazione dellarea business.

Introduzione

Lobiettivo fornire unidea, quanto pi esauriente possibile, di cosa sia il linguaggio senza aver la pretesa che il lettore comprenda fin da subito tutti i concetti introdotti, per i quali sono presenti appositi capitoli di dettaglio. Importante iniziare a comprendere che lo UML fornisce tutta una serie di utensili, ciascuno dei quali risulta appropriato a scopi ben precisi e del tutto inadeguato ad altri: una vera e propria cassetta degli attrezzi. La descrizione dei vari manufatti che si prestano a essere realizzati per mezzo dello UML avviene nel contesto di un generico processo di riferimento.

Capitolo 3 Introduzione agli Use Case


Nel terzo capitolo si focalizza lattenzione sulla teoria degli use case e sul relativo impiego rispettando rigorosamente le direttive dello UML. Nel capitolo seguente invece, ci si discoster sensibilmente dalle direttive standard, al fine di illustrare un utilizzo avanzato e maggiormente operativo dei casi duso. Dopo una breve disquisizione su cosa si intenda con i termini requisiti utente, si procede con lintroduzione della use cases view (vista dei casi duso), entrando finalmente nel vivo dello UML. Della vista dei casi duso sono descritte le due componenti: statica e dinamica. Per ci che riguarda la proiezione statica, sono descritti in dettaglio i diagrammi dei casi duso correlati da elementi e relazioni. Per ci che concerne la proiezione dinamica (ossia gli scenari), viene illustrata la versione standard basata sui flussi degli eventi e sui diagrammi dello UML atti a modellare comportamenti dinamici (diagrammi di sequenza, collaborazione, attivit, ecc.).

Capitolo 4 Modellazione avanzata degli Use Case


Nel quarto capitolo viene illustrata una tecnica di utilizzo operativo per la cattura e la documentazione degli scenario dei casi duso che a volte si discosta sensibilmente dalle direttive standard. Modellare sistemi reali mette in luce una serie di problemi e lacune di cui si tratta raramente nei libri e nelle specifiche ufficiali dello UML. Si tratta di un capitolo di stampo decisamente pratico corredato da un notevole numero di esempi di casi duso pseudoreali. Sebbene non sia indispensabile esaminarli attentamente tutti, ognuno di essi stato selezionato in quanto fornisce una serie di spunti molto interessanti.

Capitolo 5 Completamento dellanalisi dei requisiti


Il quinto capitolo verte sue due tematiche portanti: la presentazione di una tecnica dimostratasi particolarmente valida nellarduo compito dellanalisi dei requisiti utente e lillustrazione dei manufatti (artifact) che completano il modello dellanalisi dei requisiti.

UML e ingegneria del software: dalla teoria alla pratica

Il problema che tenta di risolvere la tecnica di analisi dei requisiti esposta trovare una piattaforma di dialogo comune e costruttiva tra personale tecnico e clienti, in altre parole trovare un efficace raccordo tra i due diversi linguaggi tecnici: quello dellarea business e quello informatico. A tal fine viene sfruttato il formalismo degli activity diagram (diagramma delle attivit). Il modello dei casi duso, sebbene costituisca un artifact di importanza centrale nel contesto dei processi di sviluppo del software, da solo non assolutamente in grado di fornire sufficienti informazioni per il pieno svolgimento delle restanti fasi del ciclo di vita del sistema. La completa realizzazione della vista dei requisiti del sistema prevede la produzione di ulteriori manufatti complementari. In particolare, nel capitolo sono presentati artifact di notevole importanza, come il dettaglio delle interfacce, i test case, il documento dei requisiti non funzionali e le famosissime business rules.

Capitolo 6 Object Oriented in un chicco di grano


Il sesto capitolo dedicato alla presentazione dei princpi fondamentali dellObject Oriented. Lobiettivo introdurre le nozioni utilizzate nei capitoli successivi, senza aver la presunzione di trattare in maniera approfondita un argomento cos importante e vasto. Il capitolo non poteva che iniziare con la definizione formale di oggetto e classe e delle relative relazioni, prosegue con lillustrazione degli elementi essenziali di cui composto un oggetto (identit, stato e interfaccia) e quindi presenta le tre leggi fondamentali dellObject Oriented (ereditariet, incapsulamento e polimorfismo). In questa sede si coglie loccasione per riportare alcuni errori tipicamente commessi da tecnici alle prime armi. Questa prima sezione termina con lintroduzione di due princpi fondamentale del disegno dei sistemi, note con i nomi di massima coesione e minimo accoppiamento. La parte conclusiva del capitolo dedicata al formalismo dellAbstract Data Type (tipo di dato astratto) e al Design By Contract (disegno per contratto).

Capitolo 7 Gli oggetti: una questione di classe


Il settimo capitolo focalizzato sullillustrazione del formalismo dei diagrammi delle classi, probabilmente uno dei pi noti e affascinanti tra quelli definiti dallo UML. Nei processi di sviluppo del software, questo formalismo si presta a rappresentare formalmente molteplici artifact presenti in diversi stadi del processo. Nelle primissime fasi lo si adotta per rappresentare i modelli del dominio e di business, nello stadio di analisi utilizzato per dar luogo allomonimo modello, nella fase di disegno impiegato per progettare e documentare lorganizzazione in codice del sistema e cos via. Dopo aver illustrato come rappresentare in UML i concetti basilari di classi, interfacce, ecc., si passa allillustrazione delle diverse tipologie di relazioni. La modellazione di un sistema non richiede esclusivamente lidentificazione delle classi di cui composto, ma anche dei

Introduzione

legami che le interconnettono. Si prosegue pertanto passando in rassegna le relazioni con cui possibile collegare le classi tra loro. La sezione successiva del capitolo illustra il formalismo dei diagrammi degli oggetti (object diagram). Questi rappresentano una variante dei diagrammi delle classi, o meglio ne sono istanze e ne condividono gran parte della notazione. Rappresentano la famosa istantanea del sistema eseguita in un preciso istante di tempo di unipotetica esecuzione.

Capitolo 8 Le classi nei processi


Il capitolo ottavo dedicato allillustrazione dellutilizzo del formalismo dei diagrammi delle classi nel contesto di un processo di sviluppo del software. In particolare si presentano le diverse versioni di modelli a oggetti, le loro propriet, un nutrito insieme di esempi e consigli, eventuali tranelli in cui possibile cadere, il rapporto di ciascuno di essi con i restanti, ecc. Si tratta di uno di quei capitoli che dovrebbe fornire risposte esaurienti agli interrogativi pi frequentemente posti allautore del libro. Il primo modello ad oggetti presentato quello relativo al dominio del problema (Domain Object Model). In particolare si presenta un processo pratico atto a semplificare lindividuazione delle classi appartenenti al modello e a inserirle in un contesto strutturato. Del processo viene fornito un esempio di applicazione, nel quale sono evidenziati errori ricorrenti e vengono dati utili consigli. Poich sempre meno frequente realizzare sistemi partendo dal nulla, mentre ormai prassi reingegnerizzare sistemi esistenti, si presenta una tecnica atta a realizzare prime versioni del modello a oggetti del dominio partendo dallanalisi di una base di dati del sistema. Il modello ad oggetti presentato successivamente quello relativo allarea business (Business Object Model). Si tratta di una versione molto simile a quello del dominio, in cui compaiono elementi aggiuntivi (work unit, unit di lavoro e worker, lavoratori). Pertanto si evidenziano le similitudini e le differenze con quello del dominio e si d quindi una serie di consigli relativi a quale usare, quando, e cos via. Teoricamente, in un processo di sviluppo andrebbero realizzati entrambi; nella pratica, per via di una serie di problemi relativi a tempo, budget, personale, ecc. normale trascurarne uno per concentrasi sullaltro. Il passo successivo consiste nel presentare il modello a oggetti di analisi (Analysis Model). Anche per questo modello viene presentata una tecnica utile per la sua realizzazione, una serie di consigli, nonch i vari tranelli in cui si pu correre il rischio di imbattersi. Nei progetti reali non sempre possibile realizzare il modello di analisi, per via dei soliti problemi (mancanza di tempo, personale, ecc.), pertanto si fornisce una serie di consigli su come ridurre il rischio generato dalla mancata realizzazione, su quando sia possibile trascurarlo, su quando invece opportuno realizzarlo, ecc. Prima di proseguire nella presentazione del modello successivo, viene presentato un formalismo di importanza storica per il processo di realizzazione dei vari modelli a oggetti che tuttora conserva delle aree di applicazioni, ossia il metodo delle CRC cards.

UML e ingegneria del software: dalla teoria alla pratica

Lultimo modello a oggetti presentato, probabilmente il pi noto, quello di disegno (Design Object Model). Di questo dovrebbero esistere almeno due versioni: quello di specifica e quello di implementazione. Il primo dovrebbe essere realizzato prima dellinizio della codifica, mentre il secondo il risultato dellevoluzione che il disegno subisce durante limplementazione (variazioni in corso dopera). Come al solito si riportano immancabili esempi, consigli su come realizzarlo ecc. Il capitolo si conclude cercando di rispondere alla fatidica domanda: Quando un modello a oggetti di disegno si pu considerare ben costruito?.

Capitolo 9 I diagrammi di interazione


Le parti che costituiscono un qualsivoglia sistema non sono assemblate per persistere semplicemente in una posizione stabile, bens interagiscono tra loro scambiandosi messaggi al fine di raggiungere uno scopo ben preciso. Pertanto la descrizione di ogni comportamento necessita di essere modellata sia attraverso una prospettiva che mostri la struttura statica degli elementi cooperanti, sia mediante unaltra che illustri il relativo comportamento dinamico. Obiettivo del presente capitolo e di quello successivo illustrare i formalismi forniti dallo UML per modellare comportamenti dinamici. In particolare nel capitolo nono lattenzione focalizzata sui diagrammi di interazione (interaction diagram). Con questo nome si indicano i diagrammi di sequenza (sequence diagram) e quelli di collaborazione (collaboration diagram). Quantunque permettano di mostrare lo stesso contenuto informativo, si diversificano per laspetto dellinterazione cui attribuita maggiore importanza: i diagrammi di sequenza enfatizzano lo scambio dei messaggi nel tempo, mentre i diagrammi di collaborazione attribuiscono maggiore importanza allorganizzazione degli oggetti coinvolti nellinterazione modellata. Lutilizzo di questi diagrammi comprende quasi tutte le fasi dei processi di sviluppo del software: si va dallanalisi dei requisiti in cui possono essere utilizzati per illustrare gli scenari dei casi duso (soprattutto i diagrammi di sequenza), alla fase di analisi e disegno in cui mostrano le dinamiche interne del sistema. Si tratta di diagrammi ampiamente utilizzati nei capitoli precedenti e che, nel capitolo nono, trovano unillustrazione completa. Di questi due diagrammi presentato in modo approfondito il formalismo, consigli su come e quando utilizzarli, ecc. Il tutto sempre coadiuvato da un consistente insieme di esempi nonch dalle sezioni dedicate ai consigli relativi allo stile.

Capitolo 10 Le attivit di stato


In questo capitolo viene conclusa lillustrazione dei diagrammi dello UML destinati a modellare comportamenti dinamici. In particolare sono illustrati i diagrammi degli stati (state chart diagram) e quelli di attivit (activity diagram). Anche in questo caso si tratta di

10

Introduzione

diagrammi ampiamente utilizzati nel corso dei capitoli precedenti che per nel capitolo decimo sono affrontati in maniera organica. I diagrammi degli stati descrivono il ciclo di vita di automi a stati finiti. Pi precisamente, possibili sequenze di stati e azioni attraverso le quali istanze di opportuni elementi possono procedere durante il relativo ciclo di vita. Tale evoluzione leffetto delle reazioni innescate in tali istanze al verificarsi di opportuni eventi discreti. I diagrammi di attivit (discendenti dei celebri diagrammi di flusso, flowchart diagram) sono una variante di quelli degli stati, ove gli stati rappresentano lesecuzione di azioni o sottoattivit e le transizioni sono innescate dal completamento di tali azioni o sottoattivit. Questi diagrammi possono prevedere un considerevole utilizzo nelle fasi di analisi dei requisiti, che, tipicamente, si affievolisce nelle restanti fasi del processo di sviluppo del software. I diagrammi delle attivit trovano grande applicazione nella fase di analisi dei requisiti dove sono impiegati per mostrare gli scenari dei casi duso. Nelle restanti fasi tendono a essere utilizzati qualora vi sia la necessit di mostrare comportamenti concorrenti e la precisa allocazione delle responsabilit. Sempre i diagrammi delle attivit recitano un ruolo di primissima importanza ogniqualvolta sia necessario illustrare graficamente processi e sottoprocessi. I diagrammi degli stati sono utilizzati indistintamente in tutte le fasi del processo di sviluppo del software qualora vi sia la necessit di illustrare il ciclo di vita di oggetti (anche composti) che possono evolvere attraverso un insieme finito di stati. Di questi due diagrammi illustrato approfonditamente il formalismo, consigli su come e quando utilizzarli, ecc. Il tutto sempre coadiuvato da un consistente insieme di esempi nonch dalle sezioni dedicate ai consigli relativi allo stile grafico.

Capitolo 11 Anche gli aspetti fisici sono importanti


Il libro si conclude con la presentazione dei diagrammi forniti dallo UML per modellare aspetti fisici del sistema: ossia i diagrammi di implementazione (implementation diagram). Con questo termine ci si riferisce ai diagrammi dei componenti (component diagram) e a quelli di dispiegamento (deployment diagram). I diagrammi dei componenti mostrano appunto la struttura dei componenti di cui composto il sistema, inclusi gli elementi che li specificano (classificatori) e i manufatti che li implementano. I diagrammi di dispiegamento mostrano la struttura dei nodi che costituiscono larchitettura fisica del sistema e nei quali vengono installati i componenti. Questi diagrammi si prestano anche a utilizzi pi estesi. Nella modellazione dellarea business, per esempio, i componenti mostrano procedure di business e manufatti, mentre i nodi rappresentano organizzazioni e risorse del business. Sebbene costituiscano il modello fisico, la loro produzione inizia gi dalle primissime fasi dellanalisi dei requisiti, poich considerazioni di carattere architetturale forniscono importantissimi feedback allo studio di fattibilit dei requisiti.

UML e ingegneria del software: dalla teoria alla pratica

11

Di questi diagrammi, in particolare di quello dei componenti, sono mostrate importanti lacune evidenziate (quasi completamente riassorbite dalla versione 2 di UML), illustrato ampiamente il formalismo, sono forniti consigli su come e quando utilizzarli, un consistente insieme di esempi, vengono proposte indicazioni relative allo stile grafico, ecc.

Appendice A UML e i linguaggi di programmazione non OO


Sebbene UML sia un linguaggio di modellazione ideato per la progettazione di sistemi OO e component-based, si presta a essere utilizzato per la produzione di sistemi che prevedano linguaggi di programmazione non basati su tali paradigmi. Ci vero per utilizzando opportune cautele. NellAppendice A sono illustrati utili criteri, idee e problematiche relative allutilizzo dello UML con linguaggi di programmazione non OO.

Appendice B UML e la modellazione di basi di dati non OO


Obiettivo dellappendice B illustrare una sorta di profilo utilizzabile per modellare basi di dati fondati su paradigmi non OO. In particolare lattenzione focalizzata sulle basi di dati relazionali, sebbene i concetti esposti si prestino a essere estesi anche a basi di dati fondati su diversi paradigmi.

Appendice C Il profilo EJB


Lappendice C dedicata ad una breve illustrazione di un profilo (non standard) utilizzabile per la modellazione di sistemi component based fondati sullarchitettura Sun EJB. Brevemente, un profilo una particolare estensione dello UML, o meglio una collezione di estensioni predefinite, le quali nascono dallesigenza di standardizzare lutilizzo dello UML per domini o scopi o tecnologie ampiamente diffuse.

Appendice D Glossario
Un utile glossario di riferimento costituisce lAppendice D.

Appendice E Bibliografia ragionata


Un elenco di libri, riviste e siti web di riferimento.

Ringraziamenti
Come ogni libro che si rispetti anche qui presente limmancabile e doverosa sezione dedicata ai ringraziamenti. In primo luogo la personale riconoscenza dellautore va al fantastico team che lo ha assistito e coadiuvato durante tutto il ciclo di sviluppo del libro. In particolare si ringraziano gli amici Roberto Virgili, (www.RobertoVirgili.com, team leader architetto nonch sviluppatore di sistemi distribuiti, vero e proprio formatore di menti il quale, tra laltro, ha sostenuto per primo lidea del libro: i lettori sanno quindi a chi rivolgersi per le eventuali ritorsioni), e ad Antonio Rotondi (Antonio.Rotondi @Artech.freeserve.co.uk, team leader, architetto di sistemi distribuiti e infrastrutture di sicurezza che negli ultimi anni ha lavorato intensamente allo sviluppo di sistemi per la gestione di smart card). Si tratta di due tecnici informatici di profonda levatura ed esperienza, veri e propri profeti dellarte di realizzare sistemi informatici che funzionano. Ringraziamenti aggiuntivi spettano a Gianluca Pignalberi, (Gianluca.Pignalberi @caspur.it, attualmente applicativo presso il CASPUR, Consorzio Interuniversitario per le Applicazioni di Supercalcolo Per Universit e Ricerca, esperto di metodi di Intelligenza Artificiale applicati allelaborazione delle immagini e di Linguistica Computazionale) sempre prodigo di consigli e preziosi suggerimenti, specie relativi alla sfera delle strutture dati e dei linguaggi formali. Un particolare ringraziamento va poi a Francesco Saliola che ha curato la redazione e limpaginazione del libro. Ulteriori ringraziamenti spettano a Giovanni Puliti (Java enthusiast, esperto di Java e tecnologie annesse, scrittore, articolista e direttore della rivista web www.MokaByte.it) e a Claudio Bergamini (amministratore di profonda conoscenza tecnica e rara lungimiranza., www.imolainfo.it) che hanno creduto nel libro e si sono adoperati proficuamente affinch il progetto potesse vedere la luce di Internet. Altri ringraziamenti doverosi spettano ai familiari dellautore e a tutti i veri amici, presenti nei tanti momenti di bisogno. La profonda riconoscenza e il ringraziamento dellautore spettano poi a tutti coloro che accoglieranno linvito di leggere il libro e a fornire le proprie riflessioni, al fine di arricchire il presente lavoro rendendolo sempre pi vicino alle tipiche esigenze dei progetti reali. Dulcis in fundo forse un ringraziamento particolare, molto particolare, va ai sedicenti tecnici, i vari gatto e volpe onnipresenti in tutte le organizzazioni. A tutti coloro che, chiusi nella loro arroganza, si sentono perpetuamente pi furbi, patrigni dispensatori di consigli sempre troppo gratuiti. Agli adepti delle ditte a conduzione familiare, che obbligano giovani professionisti a combattere contro muri di gomma, a lavorare sempre di pi e a dare costantemente il meglio di s fino alla nausea per dimostrare che la qualit non alberga esclusivamente nei libri di teoria Ammesso che queste persone siano in grado di capirla!

UML e ingegneria del software: dalla teoria alla pratica

13

Scuse
Le personali scuse dellautore vanno ai teorizzatori dellinformatica, agli autori dei vari testi sacri, e in primo luogo ai Tres Amigos. Il loro contributo alla semplificazione del processo di sviluppo dei sistemi informatici cos evidente da non richiedere assolutamente commenti. Si tratta di vere oasi di formazione intellettuale nel deserto degli Azzeccagarbugli, di fari che illuminano la rotta di tutti coloro per i quali linformatica una scienza Ci nonostante si ritenuto opportuno non prendersi troppo sul serio, permettendosi ironie anche nei confronti dei mostri sacri non solo nel senso etimologico del termine dellinformatica Daltronde i cimiteri sono gremiti di lapidi che declamano: Qui giace una persona insostituibile. Le scuse personali dellautore sono rivolte ai lettori pi attenti, se, talune volte, limpeto di voler illustrare concetti complessi nel modo pi semplice possibile possa aver travolto la trattazione erudita e portato a frasi fuorvianti. Ci nonostante si deciso si perseverare diabolicamente in tale direzione confidenti che quando il saggio indica la luna solo lo stolto fissa il dito. Le scuse finali sono relative alla voluminosit del libro Attualizzando una frase che Voltaire usava scrivere nelle lettere alla sua amica: vi porgo le mie scuse per la voluminosit della lettera, ma proprio non ho avuto tempo per scriverne una concisa.

Breve biografia dellautore


Luca Vetti Tagliati nato a Roma il 03/12/1972 (ottima annata per il vino). Ha da sempre studiato IT: quando allasilo bucava i fogli di carta con la matita, manifestava i primi sintomi da programmatore di schede perforate. Ha iniziato a lavorare professionalmente nel 1991 occupandosi di sistemi firmware ed assembler per microprocessori della famiglia iAPXx286. Nel 1994/95 ha intrapreso il lungo cammino nel mondo Object Oriented grazie al meraviglioso linguaggio C++. Nel 1996 si trovato catapultato nel mondo Java. Negli ultimi anni ha applicato la progettazione/programmazione Component Based in settori che variano dal mondo delle smart cards (collaborazione con la Datacard, www.datacard.com) a quello del trading bancario (www.hsbc.com). Attualmente lavora come consulente presso la sede londinese della banca HSBC con funzioni di chief designer, team leader e membro del gruppo PEG (Processing Engineering Group) istituito per stabilire un processo di sviluppo standard da applicarsi per lo sviluppo di sistemi software. Il PEG si avvale della collaborazione di persone del calibro di John Daniels ([BIB15]) e Frank Armour ([BIB14]). rintracciabile per ingiurie ed eventuali apprezzamenti presso lindirizzo LVettiTagliati@Mokabyte.it.

14

Introduzione

Convenzioni grafiche
Il carattere senza grazie, accoppiato a unopportuna icona, utilizzato per evidenziare parti di testo meritevoli di particolare attenzione oppure dedicati esclusivamente a un pubblico esperto.

Il carattere piccolo indica parti di testo che riportano considerazioni non fondamentali: nonostante le informazioni contenute in tali parti di testo possano risultare interessanti per alcuni lettori, si tratta di nozioni che non sono indispensabili e che possono essere tranquillamente tralasciate senza pregiudicare la comprensione del testo restante.

Licona della lampadina, congiuntamente al carattere senza grazie viene utilizzata per mettere in luce un determinato concetto chiave, un consiglio pratico o un altro argomento che meriti particolare attenzione.

Licona del pericolo generico viene utilizzata per evidenziare sezioni, parti o paragrafi aventi una difficolt intrinseca elevata e dedicati a un pubblico esperto. Si tratta comunque di paragrafi completamente opzionali la cui lettura e comprensione non assolutamente indispensabile per lapprendimento di quanto riportato nei paragrafi e capitoli successivi. Ad ogni modo, non scarseggiano mai ampie descrizioni testuali atte a rendere accessibili a tutti anche le trattazioni pi complesse.

Licona degli ingranaggi stata utilizzata per evidenziare sezioni, parti o paragrafi dedicati ai processi di sviluppo del software. Tutti coloro allettati unicamente dal linguaggio dello UML e quindi interessati fino ad un certo punto ai processi di sviluppo, possono tranquillamente disinteressarsi di questi paragrafi.

Licona della tavolozza dei colori evidenzia paragrafi contenenti linee guida per il miglioramento delleleganza e della comprensibilit dei diagrammi. Lobiettivo pertanto migliorare lo stile senza entrare nel merito della semantica in altre parole si focalizza lattenzione sullo strato di presentazione sebbene poi le due caratteristiche non possano essere trattate in maniera completamente disgiunta.

Capitolo

1
Beati monoculi in regno caecorum

UML: che cosa , che cosa non


Introduzione
Obiettivo del presente capitolo fornire una panoramica generale sullo UML: il capitolo pertanto risulta essere decisamente corposo, quasi onnicomprensivo e non sempre di facile comprensione. Il fattore positivo che si pu procedere tranquillamente nella lettura del testo pur non comprendendo appieno quanto riportato. Il consiglio per tutti coloro che si accostano allo UML per la prima volta di leggerlo comunque, magari molto rapidamente, una prima volta, con lintento di tornare a rileggerlo in un secondo momento, quando si sar in possesso di una maggiore familiarit con il linguaggio stesso. Allora si potranno apprezzare maggiormente gli argomenti illustrati e si potr comprendere pienamente il rapporto che intercorre tra lo UML e le tecnologie correlate. Lobiettivo del capitolo chiarire sin da subito, e in modo inequivocabile, che cosa sia e che cosa non sia lo UML e, quindi, quali siano le relative aree di competenza e gli obiettivi. A tal fine vengono presentate anche altre tecnologie strettamente correlate con lo UML, nella convinzione che ci, aiutando a definire pi distintamente i confini dello UML, concorra a fornire una visione pi completa e precisa dello stesso. Si ritenuto altres utile fornire un conciso quadro storico della situazione presente prima e durante levoluzione dello UML, al fine di evidenziare le motivazioni teoriche che hanno spinto i cosiddetti Tres Amigos (Grady Booch, James Rumbaugh, Ivar Jacobson) ad affrontare il superbo progetto del linguaggio unificato. Sebbene sia opinione comune di molti tecnici che lo UML rappresenti semplicemente una notazione standard per la creazione di modelli Object Oriented di sistemi, in realt molto di pi. Esso possiede una definizione rigorosa di metamodello, istanza del meta-metamodello noto con la sigla MOF (Model-Object Facility). Si tratta di concetti

Capitolo 1. UML: che cosa

, che cosa non

molto eleganti e affascinanti, a elevato livello di astrazione (la relativa descrizione riportata nellapposita appendice). Tali concetti meriterebbero, in effetti, una trattazione pi rigorosa (le specifiche ufficiali constano di oltre 500 pagine) rispetto a quella riportata, ma ovviamente e fortunatamente ci esula dagli obiettivi del presente libro. Il problema che si pone a questo punto che il metamodello dello UML descritto per mezzo dello UML stesso: unistanza che definisce la classe (ci rievoca il ricordo del compilatore del linguaggio C scritto in linguaggio C). Si tratta indubbiamente di una scelta molto elegante, ma che, come incoveniente, pu creare seri problemi a tutti coloro che affrontano lo UML per la prima volta: come andare a lezione di Inglese senza conoscerne una parola e assistere a spiegazioni esclusivamente in lingua impartite da un insegnante di madrelingua che non faccia altro che parlare e parlare. La trattazione pi approfondita riportata nellappendice A: stata inserita in questo contesto solo al fine di rendere i lettori consapevoli delle specifiche formali, nonostante la relativa illustrazione venga ripresa e argomentata nel corso di tutto il libro. Se i vari concetti dovessero risultare troppo enigmatici non c da preoccuparsi pi di tanto: si pu utilizzare tranquillamente lo UML senza averne capito il metamodello (si pu tranquillamente progammare in C senza sapere come sia stato realizzato il relativo compilatore). I paragrafi successivi a quelli relativi al metamodello sono dedicati alla trattazione dei metodi di sviluppo (i famosi processi) sia da un punto di vista generale illustrazione delle principali dottrine (Use case Driven, Architecture Centric e Iterative and Incremental) , sia da un punto di vista particolare presentazione dei processi pi diffusi (The Unified Software Development Process, frutto del lavoro dei Tres Amigos, Use case Driven Object Modeling with UML, OPEN Process patrocinato dallOPEN Consultorium e Object-Orient Software Process). Per questioni di completezza viene fornita una brevissima introduzione delleXtreme Programming (XP) con tutte le relative perplessit generate e la relativa evoluzione fornita dalleXtreme Modelling o Agile Modeling, in cui, fortunatamente, lattenzione viene nuovamente spostata sulla fase di modellazione. Il capitolo termina con limmancabile parte dedicata ai tool disponibili in commercio, con una brevissima illustrazione, quanto pi oggettiva possibile, dei relativi pregi e difetti.

La modellazione
Ogni qualvolta, in una disciplina dellingegneria, vi sia la necessit di realizzare un manufatto, indipendentemente dalla dimensione e dal settore di interesse (una casa, un grattacielo, un particolare meccanismo, un ponte, un dipartimento di unazienda, e cos via) si procede cercando di realizzarne un modello. Lobiettivo produrre, in tempi relativamente brevi e soprattutto a costi contenuti, una versione razionalizzata e semplificata del sistema reale che, tuttavia, consenta di evidenziarne laspetto finale e di studiarne prestazioni, affidabilit, comportamento, ecc

UML dalla teoria alla pratica

I modelli, importantissimi in tutti i processi di sviluppo, trovano la loro pi completa legittimazione nellambito di sistemi di dimensioni medie e grandi. In tali circostanze la complessit di questi sistemi nella loro interezza ne rende molto difficoltosa la comprensione. quindi maggiormente avvertita la necessit di avvalersi di modelli in grado di descrivere, in maniera semplificata, sistemi comunque complessi. Si vedr come lo UML, grazie alla sua organizzazione in viste (Views), risponda alla logica necessit della mente umana di concentrarsi, in ogni istante, su un numero limitato di aspetti del sistema ritenuti importanti per la particolare fase del processo di sviluppo, rimandando a momenti successivi lanalisi degli aspetti rilevanti per le altre viste. Oltre ai motivi gi citati, i modelli sono basilari poich, avvalendosi anche del feedback fornito dai committenti, permettono di definire i requisiti del sistema in maniera chiara e, con la cooperazione del proprio gruppo, di razionalizzarne il processo di sviluppo. I vantaggi che se ne ricavano sono diversi: adeguate analisi dei tempi, migliori stime dei costi, piani pi precisi di allocazione delle risorse, distribuzioni pi affidabili del carico di lavoro, e cos via. Si riesce quindi a risparmiare tempo e denaro, a ridurre i fattori di rischio presenti in ogni progetto, a studiare la risposta del sistema a particolari sollecitazioni, e via di seguito. Nonostante il grande valore apportato allingengeria del software dallutilizzo della modellazione, troppo spesso in molte organizzazioni, questa meravigliosa tecnica rimane ancora una chimera. A nessuno appartenente al settore dellingegneria edile verrebbe in mente di costruire interamente un grattacielo, per poi studiarne la risposta a sollecitazioni di carattere sismico. Il buon senso risorsa purtroppo sempre rara suggerisce di procedere con la realizzazione di una versione miniaturizzata sulla quale condurre tutti gli studi del caso. Non necessariamente un processo di modellazione genera un oggetto tangibile: talvolta si tenta di rappresentare un complesso reale per mezzo di eleganti sistemi di disequazioni e quindi lintero modello si risolve in una raffinata astrazione. Tutto ci che fin troppo scontato in molte discipline dellingegneria non lo nel settore dellinformatica. In molte organizzazioni e qui non si pensi a un limite riscontrabile solo nelle piccole realt la produzione del software ancora unattivit, per cos dire, artigianale in cui il relativo processo di sviluppo del software prevede tre fasi: analisi dei requisiti, implementazione e test Forse. Si provi a immaginare che cosa potrebbe accadere se si avviasse la progettazione di un ponte a partire da specifiche sommarie, magari comunicate verbalmente o, peggio ancora, se si partisse subito a costruirlo materialmente, magari affidandosi allesperienza di qualche costruttore. Inconcepibile eh? Tutto ci, bench possa sembrare fuori dal mondo, molto spesso prassi comune nel mondo dellingengeria informatica. Malgrado siano stati versati fiumi dinchiostro sullargomento, e svariati gruppi di ricerca lavorino a tempo pieno per la definizione di nuovi standard di analisi, in molte organizzazioni, soprattutto italiane, anche di comprovato prestigio, tale attivit ancora considerata prettamente accademica, vezzo di giovani neolaureati perch, in ultima analisi, di

Capitolo 1. UML: che cosa

, che cosa non

scarsa utilit nel mondo reale, dove lobiettivo produrre codice e lesperienza in grado di sopperire a tutto. Linevitabile risultato che spesso si procede cominciando paradossalmente da una delle ultime fasi del processo di ingegnerizzazione del software, ossia dalla stesura del codice (paragonabile alla costruzione del ponte di cui si parlava nellesempio). Si inizia concentrandosi prematuramente sul modo in cui redigere il codice ed, eventualmente, alla fine si scrivono due righe di analisi, magari demandando il tedioso incarico allultimo arrivato nel team, al baldo giovane di turno. I rischi che si corrono sono noti a tutti e possono generare delle veniali anomalie note in letteratura informatica come crisi del software. In molte occasioni lautore potrebbe citarne diverse, ma preferirebbe evitare vitto e alloggio a carico dello Stato pu accadere che, a progetto ultimato e pronto per la consegna, ci si accorga dellerrata architettura. Non da escludere, nel peggiore dei casi, che, per via di uno sviluppo interamente incentrato sulla fase di codifica, e quindi privo della visione globale che solo un buon processo di modellazione pu apportare, sia praticamente impossibile integrare i moduli prodotti in parallelo o che sia necessario costruire estemporanei moduli di interfacciamento o, ancora, che il sistema preveda percorsi cos tortuosi da renderlo praticamente inutilizzabile. Lunico vantaggio, in questo modo di procedere che si placano, almeno sul momento, gli stati dansia di taluni manager, i quali diventano improvvisamente irrequieti quando il team non genera codice, anche se nel frattempo si stanno affrontando delicate e impegnative fasi di analisi e/o disegno. Lalibi che viene rispolverato lo scarso tempo a disposizione, dimenticando quanto incida il processo di manutenzione sullintero ciclo di vita del software: il famoso risparmio della massaia. A onor del vero, gli eventuali fallimenti non sono sempre imputabili a tecnici/commerciali che vendono limpossibile, di manager informaticamente poco lungimiranti o di capi-progetto invisibili (detti in gergo ghost) che un giorno sono a favore di una soluzione e il giorno dopo di quella opposta Maschere e pugnali! Molto spesso qui doveroso procedere con un po di sana autocritica gli stessi progettisti si sentono pi a loro agio quando si deve affrontare un problema di programmazione, piuttosto che quando si deve affrontare la modellazione di un sistema. Probabilmente non suoner nuova la frase Che noia! Non ne posso pi! Ma quando si comincia a scrivere del codice?. Probabilmente si tratta anche delleredit di una dannosa abitudine: allinizio i sistemi non erano cos complessi, le metodologie di progettazione erano quasi inesistenti, i problemi e gli imprevisti dellimplementazione erano di quantit e entit tutto sommato limitate, tali da rendere quasi giustificabile la contrazione del processo di modellazione. Eppure da allora alcune cose dovrebbero essere cambiate E pensare che, da oltre un decennio, in ambito accademico si afferma che la programmazione un incidente anche molto piacevole se si vuole dellinformatica.

UML dalla teoria alla pratica

Figura 1.1 La vignetta dellaltalena


Quello che voleva l'utente... Quello che ha capito il business analyst... Quello che ha progettato l'architetto...

Quello che hanno realizzato i programmatori...

Come hanno installato gli installatori...

Quello di cui aveva realmente bisogno l'utente...

Nella realt, troppo spesso si liquidano prematuramente le fasi di analisi e disegno del software per tuffarsi a testa bassa nella programmazione. Come nella celebre vignetta dellaltalena, tutti sono felici e contenti, almeno fino al momento di appenderla al ramo dellalbero. La temporanea soddisfazione viene vinta dalla triste constatazione che, a causa del modo superficiale in cui si operato, necessario operare un taglio ortogonale alla base del tronco dellalbero per poter ospitare il seggiolino. In altre realt, pu succedere di realizzare unanalisi adeguata, di produrre modelli sofisticati ad elevato livello di astrazione da fornire al team di sviluppatori object disoriented. Una situazione del genere potrebbe ingenerare qualche problema, magari per spiegare che con la frase loverloading dei metodi non si intende sovraccaricare il processo di sviluppo di metodologie.

Capitolo 1. UML: che cosa

, che cosa non

Questo per evidenziare che gli strumenti da utilizzare in fase di analisi, purtroppo, possono anche dipendere, in gran misura, dal team con cui si lavora. Provate a fornire, sempre allo stesso team di cui sopra, un class diagram (diagramma delle classi) Non si otterranno grossi risultati, neanche con lesempio dellentomologo (qualcuno ricorda la catalogazione degli insetti un tempo tanto cara a taluni manuali?). Premesso ci, va comunque ribadito che il processo di analisi e modellazione unattivit estremamente creativa, strettamente dipendente dalle capacit, dalla cultura e dallesperienza dei singoli: insomma un vero e proprio bene soggettivo. Il bello si fa per dire che non esiste un manuale delle soluzioni corrette con il quale confrontarsi alla fine del proprio studio: solo il tempo fornir i verdetti. A tutti coloro per i quali tale introduzione, e in generale la domanda why do we model?, pi che scontata, felicitazioni di cuore! Significa che si trovano a lavorare presso la APBDM (leggasi Azienda Pi Bella Del Mondo). Purtroppo le realt lavorative non sono sempre cos, e la dice lunga il fatto che anche i fondatori dellUML abbiano deciso di dedicare allargomento un intero paragrafo sia del libro [BIB01], sia delle specifiche ufficiali dello UML. Per terminare, sintetizzando al massimo il concetto si pu dire che si modella essenzialmente per due motivi: aumentare la propria comprensione sia di un problema sia di eventuali soluzioni ipotizzate; comunicare.

Qualit di un modello
Illustrato il concetto di modello cui si ricorrer ampiamente in tutto il libro si ritiene opportuno evidenziarne brevemente le qualit peculiari utili nel contesto dello sviluppo di sistemi software. Le propriet che deve possedere un modello dovrebbero essere tenute a mente e guidare la fase di progettazione del sistema, al fine di produrne versioni di migliore qualit. Un modello dovrebbe essere: accurato: deve descrivere il sistema correttamente, completamente e senza ambiguit; consistente: le diverse viste devono completarsi vicendevolmente per formare un insieme coerente (la completezza di unerma bifronte); semplice: deve poter essere compreso, senza troppi problemi, da persone estranee al processo di modellazione;

UML dalla teoria alla pratica

manutenibile: la variazione dello stesso deve essere la pi semplice possibile.

Nascita e sviluppo di UML


La babele dei metodi
Uno degli obiettivi che hanno caratterizzato il lavoro dei Tres Amigos stato realizzare un linguaggio di modellazione che unificasse e incorporasse le caratteristiche migliori dei linguaggi esistenti intorno agli anni Novanta. In particolare, come citato esplicitamente nel documento delle specifiche [BIB07], lo UML scaturito principalmente dalla fusione dei concetti presenti nei metodi di Grady Booch, OMT (Object Modeling Technique di cui Rumbaugh era uno dei principali fautori) e OOSE (Object Oriented Software Engineering /Objectory di cui Ivar Jacobson era uno dei pi importanti promotori). Agli inizi degli anni Novanta, ossia poco prima dellavvio dei lavori per lo UML, i suddetti metodi erano probabilmente quelli pi apprezzati, a livello mondiale, dalla comunit Object Oriented. Brevemente, il metodo di Booch, diventato famoso nel settore con il nome di metodo delle nuvolette, definisce una notazione in cui il sistema viene analizzato e suddiviso in un insieme di viste, ciascuna costituita dai diagrammi di modello. Il metodo non si limita a un linguaggio di modellazione, ma contiene anche un processo, in base al quale, il sistema viene studiato attraverso micro- e macroviste di sviluppo, secondo un classico schema incrementale e iterativo. Il metodo di Booch, a detta degli esperti, sembrerebbe molto efficace soprattutto in fase di disegno e di codifica, mentre presenterebbe qualche lacuna nelle varie fasi di analisi. LOMT un linguaggio di modellazione, sviluppato presso la General Electric, rilevatosi particolarmente efficace nella fase di esplorazione dei requisiti. In maniera speculare al metodo precedente, questultimo sembrerebbe essere carente nella fase della formulazione delle soluzioni, mentre risulterebbe particolarmente accurato nellesplorazione delle specifiche nel dominio del problema. LOMT prevede che il sistema venga descritto attraverso un preciso numero di modelli che si completano vicendevolmente. Grazie alla sua accuratezza nella fase di analisi dei requisiti, il modello fornisce un valido ausilio anche alla fase di test di sistema. Infine i metodi OOSE e Objectory (in gran parte dovuti al lavoro di Jacobson) si basano, quasi interamente, sugli Use Case (casi duso). Poich gli Use Case permettono di definire i requisiti iniziali del sistema cos come vengono percepiti da un attore esterno allo stesso, i metodi OOSE e Objectory si sono dimostrati particolarmente efficaci nello spazio dellanalisi nel dominio del problema. Anche questi metodi forniscono una serie di informazioni e linee guida su come passare dallanalisi dei requisiti al disegno del sistema. Altri metodi degni di essere menzionati sono Fusion (elaborato presso i laboratori della Hewlett-Packard) e il metodo Coad/Yourdon (noto anche come OOA/OOD Object

Capitolo 1. UML: che cosa

, che cosa non

Oriented Analisys / Object Oriented Design) che vanta il primato di essere stato uno dei primi metodi di analisi e disegno di sistemi Object Oriented. Negli anni intercorsi tra il 1989 ed il 1994, oltre ai metodi appena citati, considerati tra i pi importanti, se ne contarono addirittura una cinquantina. Questi andarono ad alimentare quella che fu definita guerra dei metodi: la famosa Babele tra i modelli software con la conseguente incomunicabilit. Ovviamente ciascuno di questi presentava punti di forza, lacune, un proprio formalismo, una nomenclatura proprietaria e un peculiare processo di sviluppo. Tutto ci finiva per minare alla base lo sviluppo di processi di progettazione pi accurati e rendeva difficoltosa la realizzazione di opportuni tool di supporto. Altri inconvenienti, sempre frutto dellincomunicabilit dei metodi, erano legati allimpossibilit di far circolare informazioni tra team di aziende diverse, alla difficolt di rendere rapidamente produttive nuove risorse allocate al progetto e cos via. In ultima analisi si finiva per fornire un pretesto ai vari team analisi-disegno repellenti.

Le motivazioni
Il presente libro viene pubblicato dopo pi di sette anni da quando Grady Booch e James Rumbaugh iniziarono i lavori alla Rational Software Corporation (1994). Probabilmente si trattato della tecnologia giusta al momento giusto (ci potrebbe far impallidire anche il buon Murphy), visto il grande successo riscosso e le prestigiose collaborazioni che hanno contributo alla sua realizzazione. Tra i partner si contano alcune delle aziende pi importanti nel settore della Computer Science, tra le quali IBM, Oracle, Microsoft, Sun Microsystem, Texas Instruments, MCI Systemhouse, Hewlett-Packard, e cos via. Il clamoroso successo riscosso molto probabilmente dovuto alla necessit, avvertita da tutta la comunit Object Oriented, di disporre di un unico linguaggio di modellazione che mettesse finalmente termine alla proliferazione degli anni precedenti. La guerra dei metodi ha finito per costituire un serio limite allevoluzione di una rigorosa metodologia di sviluppo del software. Le aziende che producevano tool di supporto al processo di sviluppo del software, i famosi CASE (Computer Aided Software Engineering), avevano notevoli problemi nello scommettere, sul linguaggio da adottare. Si trattava di affidare la politica di sviluppo dellazienda al successo di un metodo: vera e propria roulette russa. Lidea di produrre plug-in per il supporto degli altri linguaggi risultava uno sforzo troppo impegnativo e costoso, vista la significativa disomogeneit degli stessi. Dal canto loro le aziende di Information Tecnhnology non riuscivano a orientarsi bene nello scegliere un metodo da utilizzare come standard interno. Linvestimento per la produzione di processi proprietari e per laddestramento del personale risultava cos elevato, che lo spettro di una scelta sbagliata rendeva di fatto molto difficile qualsiasi decisione e quindi finiva per produrre una certa immobilit. Le grandi aziende finivano per crearsi un proprio processo proprietario, basato sul bagaglio delle esperienze accumulate, e quindi

UML dalla teoria alla pratica

assolutamente non supportato. Nelle imprese medio-piccole, molto spesso, tutto era demandato alla capacit e alla saggezza dei singoli architetti. Il risultato era una totale incomunicabilit tra i vari team di sviluppo e una discrepanza di metodi presenti in progetti sviluppati in tempi diversi e sotto la direzione di persone diverse. La confusione imperante generava diversi problemi anche ai singoli tecnici, desiderosi di utilizzare un linguaggio di modellazione che agevolasse il lavoro di tutti i giorni e che fosse supportato da tool commerciali. Tali situazioni prepararono il terreno ideale alla sollecita accettazione del progetto di unificazione dei metodi. Non a caso, il progetto avviato alla Rational Software Comporation suscit limmediato consenso di tutta la comunit OO. Altro fattore non trascurabile che i fautori (i Tres Amigos) del progetto dello UML erano padri dei metodi pi conosciuti ed utilizzati. Chiaramente laccettazione e il supporto del progetto da parte di altri metodologi non coinvolti nel lavoro fu tuttaltro che scontato: ma questo un altro discorso. Se a tutto ci si aggiunge il fatto che il linguaggio nonproprietario si pu ben capire che la sua affermazione era garantita sin dallinizio della sua invenzione. Si tratta infatti di un linguaggio completamente aperto, tanto che le aziende sono incoraggiate a integrarlo nei propri metodi di sviluppo del software e che le imprese produttrici di CASE possono liberamente produrre software di supporto allo UML.

La genesi
Originariamente il lavoro fu iniziato dai Dos Amigos Grady Booch e James Rumbaugh, con lintento di produrre un nuovo metodo, detto metodo unificato che raccogliesse il meglio dei metodi Booch e OMT-2, del quale Rumbaugh era stato uno dei principali promotori. Nel 1995 si un a loro Ivar Jacobson, fautore del metodo denominato OOSE (Object Oriented Software Engineering): il terzetto si era cos costituito. Lazienda che promuove il progetto la Rational Software Corporation che, dal canto suo, provvede anche ad assorbire la Objective Systems, azienda svedese che aveva sviluppato e distribuito il software Objectory. A questo punto il quadro era completo e lo standard in lavorazione fu ribattezzato Unified Modeling Language. La prima versione, la celebre 1.0, fu disponibile nel gennaio 1997. Lo UML uno strumento di analisi molto versatile, nato per risolvere le problematiche connesse con la progettazione Object Oriented del software, ma che ben si adatta a essere utilizzato negli ambienti pi disparati. Esso stato, per esempio, utilizzato alla Cadence per la produzione di un dispositivo di compressione vocale operante a livello di porta fisica. Ancora, una delle aziende fornitrici della US Navy ha utilizzato lo UML come linguaggio di progettazione di un sistema darma di nuova generazione. Unazienda sanitaria si avvalsa dello UML nella realizzazione di un modello per il trattamento dei pazienti, e cos via. Visto lenorme successo riscosso nellapplicazione industriale e nel mondo accademico e considerato il relativo riconoscimento a livello di standard (UML 1.0 stato proposto

10

Capitolo 1. UML: che cosa

, che cosa non

Figura 1.2 Diagramma dei componenti dellevoluzione dello UML. Nel diagramma sono riportati due stereotipi, etichettati rispettivamente con i termini inglesi refine e document. Per ora basti sapere che uno stereotipo una specializzazione di un elemento standard UML. In particolare refine una versione della relazione di dipendenza il cui significato piuttosto intuitivo. In generale lasserzione che un oggetto B dipende da un oggetto A (visualizzata per mezzo di una freccia tratteggiata in direzione delloggetto A), indica che una variazione alloggetto indipendente (A) produce la necessit di revisionare ed eventualmente aggiornare loggetto dipendente (B). Lo stereotipo document rappresenta una particolare versione dellelemento package, che, in questa fase, pu essere considerato come un contenitore di oggetti. La similitudine con le cartelle del file system piuttosto immediata. Una directory (o cartella che dir si voglia) in grado di contenere eventuali altre cartelle e file delle pi svariate tipologie (audio, filmati, grafici, testo, e cos via).

2002 - 2004 (Pianificate revisioni significative)

document

UML 2.0
refine

Q3 2001 (Pianificate minori revisioni)

document

UML 1.4
refine

Q3 1999

document

UML 1.3
refine

Q2 1998
document

UML 1.2
refine document

Nessuna modifica significativa

Q3 1997 OMG acquisice lo UML

UML 1.1

Unificazione dei precedenti modelli quali Booch, OMG, Objectory

allObject Managment Group nel gennaio 1997), gli stessi ideatori, i Tres Amigos, dichiararono ormai conclusa la loro esperienza in questo ambito tanto da dedicarsi a nuove sfide Allo stato attuale lo sviluppo dellUML affidato a una task force appartenente

UML dalla teoria alla pratica

11

allOMG, la famosa RTF (Revision Task Force per che fantasia), diretta da Chris Kobyrn. Obiettivo di tale gruppo accogliere e analizzare suggerimenti provenienti dalle industrie, correggere inevitabili imperfezioni (bugs), colmare eventuali lacune e cos via. Attualmente disponibile la versione 1.4 (risultato dellattivit della seconda RTF) e si sta lavorando, alla versioni 2.0 come mostrato nel paragrafo seguente. Levoluzione dello UML mostrata in fig. 1.2, attraverso il diagramma dei componenti, uno degli strumenti messi a disposizione dal linguaggio.

UML 2.0
A questo punto viene da interrogarsi legittimamente su come stiano procedendo i lavori per la versione 2.0 (etichettata spaventosamente come major revision), che cosa sia lecito attendersi per i legami con la serie 1.x dello UML, e cos via. Figura 1.3 Decomposizione delle attivit dello UML 2.0 in sottogruppi. Le linee culminanti con un diamante rappresentano relazioni di composizione dette anche whole-part (tutto-parte). In particolare, nel contesto oggetto di studio, indicano che la versione UML 2.0 costituita dalla documentazione prodotta dalla RTF Infrastructure, Superstructure e OCL.

document

UML 2.0

document

UML 2.0 Superstructure

Pianificata per Q4 2002

document

document

UML 2.0 Infrastructure

UML 2.0 OCL

Pianificata per 2004

document

UML 1.4

12

Capitolo 1. UML: che cosa

, che cosa non

Molto probabilmente uno degli impegni pi importanti consiste nel proseguire nella direzione, gi intrapresa con la versione 1.4, dello studio delle necessit dei sistemi component-based. Ci al fine di adeguare sempre pi lo UML allo stato dellarte della tecnologia e quindi di fornire soluzioni concrete alle esigenze dei tecnici coinvolti nella realizzazione di sistemi basati sui componenti. Si consideri il diagramma riportato nella figura precedente. Come annunciato in precedenza dallo OMG, la RTF per la versione 2.0 stata suddivisa (questa volta ufficialmente) in tre parti.

Infrastruttura (Infrastructure RFP, OMG document ad/00-09-01)


Come suggerisce il nome, obiettivo di questa RTF consiste nel curare miglioramenti relativi alla struttura base del metamodello UML, riguardanti il core, i meccanismi di estensione, le facility del linguaggio ecc. In particolare i relativi obiettivi sono di allineare larchitettura dello UML agli altri standard gestiti dallOMG (quali per esempio il MOF, Meta Object Facility, Meta-data Interchange XMI), ristrutturare il linguaggio al fine di renderlo pi comprensibile ed estenderlo mantenendo per la semantica e la notazione attuale. (Per ulteriori informazioni consultare lappendice A).

Superstruttura (Superstructure RFP, OMG document ad/00-09-02)


Obiettivo di questa RTF elaborare proposte atte a incorporare le best practices in aree particolarmente sensibili, come lo sviluppo di sistemi basati sui componenti, i modelli architetturali, quelli eseguibili e dellarea business. In particolare necessario studiare ulteriormente le soluzioni per: la gestione degli eventi nei diagrammi delle attivit; migliorare lillustrazione dellincapsulamento con particolare riferimento ai diagrammi di stato e di sequenza; ridefinire la semantica di relazioni come la generalizzazione, associazione, ecc. il supporto dello sviluppo component-based di sistemi software; il supporto per architetture a tempo di esecuzione, favorendone la descrizione del comportamento dinamico e leventuale rappresentazione gerarchica.

Object Constraint Language (OMG document ad/00-09-03)


Il nome di questa RTF evidenzia chiaramente quale sia la relativa area di competenza: lOCL. Gli obiettivi sono di presentare proposte atte ad aumentare il livello di specializzazione dellOCL per lutilizzo UML. Ci dovrebbe semplificare il lavoro degli utenti, favorendo laumento di formalit dei vari modelli prodotti.

UML dalla teoria alla pratica

13

Da diverso tempo in corso un dibattito allinterno dellOMG stesso, teso a investigare la necessit di introdurre unulteriore Task Force con lobiettivo di studiare larea relativa allo scambio di modelli UML prodotti da tool diversi. Il nome di tale gruppo dovrebbe essere Diagram Interchange RFP. Sebbene in tale direzione ci sia gi stato un impegno iniziale della seconda RTF, il relativo interesse stato focalizzato principalmente sulla semantica e non sulla problematica specifica dello scambio concreto di diagrammi. Come ben noto a tutti i tecnici informatici, laumento del parallelismo nello svolgimento di attivit presenta evidenti vantaggi riduzione dei tempi grazie al lavoro in parallelo, maggiore specificit delle tematiche affrontate, ecc. a fronte dei quali per, sono presenti tutta una serie di problematiche. In questo caso sono relative essenzialmente allincremento del lavoro necessario sia per lintegrazione delle proposte avanzate dai singoli gruppi, sia per il mantenimento della coerenza tra le varie parti costituenti le specifiche finali. Pertanto, ulteriore preoccupazione della RTF per la revisione 2.0 dello UML controllare lo sviluppo parallelo delle varie task force al fine di far s che le varie componenti lavorino nella stessa direzione e producano la major revision preservando la coerenza e le strutture delle precedenti versioni mostratesi particolarmente efficaci.

Obiettivi dello UML


Vengono di seguito descritti gli obiettivi che i Tres Amigos si sono prefissi di raggiungere attraverso lo sviluppo dello UML. La relativa descrizione stata tratta direttamente dal documento ufficiale delle specifiche [BIB07]. Scopi principali dello UML sono: Fornire agli utenti un linguaggio di modellazione visuale pronto ad essere utilizzato per sviluppare e scambiare modelli espressivi. Chiaramente, risulta molto importante che un linguaggio di analisi e disegno Object Oriented standard (OA&D Object Analysis & Design) fornisca tutti i concetti necessari alla sua diretta utilizzazione nelle fondamentali attivit del processo di produzione di un modello software. Lo UML ha consolidato un insieme nucleare di concetti di modellazione, necessari in molte applicazioni reali, presenti in molti metodi di progrettazione e tool di modellazione disponibili sul mercato. Fornire meccanismi di estensione e specializzazione al fine di accrescere i concetti presenti nel nucleo. Uno dei punti fermi che ha guidato il lavoro dei Tres Amigos stato realizzare un linguaggio di modellazione quanto pi generale possibile, in modo da non relegarne lutilizzo a un dominio specifico. In prima analisi, si sarebbe potuto raggiungere tale obiettivo corredando lo UML di un numero di elementi molto elevato, in modo tale da fornire gli strumenti specificamente necessari a tutte le esigenze dei vari ambienti e delle varie architetture. Si sarebbe potuto, ad esem-

14

Capitolo 1. UML: che cosa

, che cosa non

pio, includere nello UML tutta una serie di elementi specifici per la modellazione di sistemi CORBA, EJB, ecc. Tutto ci per avrebbe sicuramente portato a un conflitto con unaltra esigenza, altrettanto importante di quella dellapplicazione dellUML in campi specifici: mantenere il linguaggio il pi semplice possibile, al fine di massimizzarne laccettazione da parte della comunit Object Oriented. La soluzione a queste esigenze contrastanti stato realizzare un nucleo del linguaggio basilare, valido per ogni ambiente, corredato da una serie di strumenti che consentano di aggiungere nuova semantica e sintassi al linguaggio stesso per utilizzi specifici dello UML. Il risultato che i concetti fondamentali del linguaggio vengono utilizzati cos come sono, senza ulteriori estensioni, per la maggior parte del sistema: vige, anche in questo contesto, la famosa legge empirica dell80/20: l80% del progetto utilizza il 20% dei concetti dello UML. Per quanto riguarda la restante parte e per progetti molto specifici possibile sia aggiungere nuovi concetti e notazioni, al fine di modellare opportunamente le aree non coperte dal nucleo dello UML, sia specializzare quelle gi esistenti per particolari domini dellapplicazione. Supportare specifiche che risultino indipendenti da un particolare linguaggio di programmazione o processo di sviluppo. Lo UML stato concepito con lobiettivo di supportare plausibilmente tutti i linguaggi di programmazione. Quindi stato reso idoneo allutilizzo nei pi svariati ambienti produttivi, che ricorrono a una vasta gamma di tecnologie, e inoltre si fatto in modo di preservare la sua adattabilit a sviluppi futuri. Chiaramente lo UML risulta particolarmente indirizzato a linguaggi di programmazione Object Oriented. Pertanto parte della sua efficacia viene attenuata da linguaggi che non realizzano tale paradigma. Come solitamente succede, molto dipende dallutilizzatore. Per esempio si pu programmare in C seguendo il paradigma Object Oriented, al limite aiutandosi con un sistema evoluto di macro (le prime versioni di compilatori C++ altro non erano che preprocessori del linguaggio C, C-front). Si altres cercato di rendere lo UML idoneo a essere utilizzato con molteplici metodi di sviluppo: pu essere proficuamente adoperato per esprimere i prodotti generati dalle varie fasi di cui ogni processo composto. Fornire le basi formali per comprendere il linguaggio di modellazione. Un linguaggio di modellazione deve necessariamente essere preciso e al contempo offrire una complessit contenuta. I formalismi non dovrebbero ricorrere allutilizzo di nozioni matematiche di basso livello e distanti dal dominio del modello. Tali insiemi di nozioni teoriche e di definizioni operative risulterebbero essere una forma diversa di programmazione e implementazione, non idonea a tutte le fasi del processo di sviluppo del software. Lo UML fornisce una definizione formale del del modello, utilizzando un metamodello espresso attraverso il diagramma delle classi dello stes-

UML dalla teoria alla pratica

15

so UML. Esso presenta pertanto un adeguato formalismo e una complessit molto contenuta. Incoraggiare la crescita del mercato dei tool Object Oriented. Lesistenza di un linguaggio di modellazione standard doveva e cos stato eliminare tutti quei problemi analizzati nel paragrafo dedicato alle motivazioni dello UML: difficolt per le aziende di selezionare standard da adottare, frustrazione da parte dei tecnici di fronte alla proliferazione dei metodi, difficolt di circolazione dei vari modelli prodotti, impedimenti per le aziende creatrici di CASE di individuare metodi da automatizzare, ecc. Pertanto, una volta rimossi i problemi alla base dello sviluppo formale dellOO, venne incrementata la crescita del mercato dei prodotti commerciali per il supporto dello UML. Si tratt di un vero e proprio toccasana per tutta la comunit Object Oriented. Supportare concetti di sviluppo di alto livello come componenti, collaborazioni, framework e pattern. Ulteriore obiettivo dello UML fu la chiara definizione dei concetti succitati poich ci essenziale per trarre i massimi benefici dal paradigma Object Oriented e in particolare da quello della riusabilit. Integrare le best practices. Unaltra motivazione alla base dello UML stata integrare le pratiche mostratesi vincenti nella realizzazione di progetti reali. Ci risultato particolarmente utile al fine di offrire sin da subito un linguaggio maturo che inglobasse il meglio delle tecniche di comprovata validit.

Che cosa lo UML


Secondo le specifiche [BIB07] lo Unified Modeling Language un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, sia di processi produttivi e altri sistemi non strettamente software. UML rappresenta una collezione di best practices di ingegneria, dimostratesi vincenti nella modellazione di vasti e complessi sistemi. Lo UML permette di visualizzare, per mezzo di un formalismo rigoroso, manufatti dellingegneria, consentendo di illustrare idee, decisioni prese, e soluzioni adottate. Tale linguaggio favorisce, inoltre, la divulgazione delle informazioni, in quanto standard internazionale non legato alle singole imprese. In teoria, un qualunque tecnico, di qualsivoglia nazionalit, dipendente della pi ignota delle software house, con un minimo di conoscenza dellUML dovrebbe essere in grado di leggere il modello del progetto e di comprenderne ogni dettaglio senza troppa fatica e, soprattutto, senza le ambiguit tipiche del linguaggio naturale. Come al solito qualche problema pu sempre emergere, ma si tratterebbe comunque di problemi di poca entit. Un conto non comprendere qualche

16

Capitolo 1. UML: che cosa

, che cosa non

dettaglio, un altro non comprendere assolutamente cosa voleva realizzare lautore; situazione tipica di alcuni progetti ribattezzati temini di scuola superiore: si tratta di documenti tipicamente corposi quando non si sicuri meglio scrivere tanto in cui il 99% del contenuto relativo alla descrizione, assolutamente non organica, di nozioni teoriche copiate da appositi libri e il restante 1% a embrioni di soluzioni. I vantaggi che derivano dal poter disporre di un modello del sistema sono notevoli e fin troppo evidenti. Basti pensare alla non indifferente semplificazione del processo di manutenzione che, da solo, tipicamente incide pi del 50% nel ciclo di vita dei sistemi software ben progettati; alla possibilit di allocare risorse aggiuntive in corso dopera, riducendo il rischio che ci diventi controproducente (anche si tratta spesso di un finto rimedio a cui si ricorre in prima istanza: sarebbe un po come pensare che, poich una donna impiega nove mesi per dare alla luce un bambino, se si allocassero tre donne, ecco che lo stesso figlio potrebbe essere disponibile in tre), e cos via. Disporre di un linguaggio per descrivere un sistema costringe il progettista stesso ad analizzare, con maggior minuzia, aspetti del sistema, anche di un certo rilievo, i quali, viceversa, potrebbero incautamente venir trascurati da unanalisi non molto rigorosa. Per ci che concerne lutilizzo dello UML per specificare, bisogna tener presente che in questo contesto lespressione si riferisce alla possibilit di realizzare modelli completi, precisi e non ambigui. Lo UML dispone di tutti i meccanismi necessari per la specifica di qualsiasi dettaglio ritenuto rilevante in ogni fase del ciclo di vita del software e quindi, in ultima analisi, per produrre modelli accurati. Lo UML, permette di realizzare modelli che si prestano ad essere implementati con diversi linguaggi di programmazione, sebbene risulti particolarmente efficace per la progettazione di sistemi Object Oriented. In effetti possibile realizzare un mapping esplicito tra un modello UML e un linguaggio di programmazione. Chiaramente, tale legame risulta pi immediato per i linguaggi fortemente basati sul paradigma Object Oriented, quali C++, Java, Small-Talk, Ada, ecc. Sul mercato sono presenti diversi tool, in grado di generare codice a partire dal relativo modello, sia interattivamente durante la fase di disegno, sia su richiesta. Lesistenza di queste funzionalit, sebbene ancora non del tutto mature, dovrebbe far capire che limplementazione veramente un dettaglio del disegno, specie con linguaggi come Java. La generazione automatica di una prima implementazione del sistema risulta particolarmente utile quando il modello deve essere realizzato parallelamente (cio sempre!), poich fornisce, ai diversi sviluppatori, lo scheletro eventualmente con qualche metodo implementato delle classi fondamentali del sistema che dovrebbero presentare uninterfaccia stabile e ben definita. Sebbene alcuni tools tentino, in alcuni casi particolari, di dettagliare determinati metodi con il codice appropriato, probabilmente ancora un po prematuro azzardarsi a utilizzare appieno tale funzionalit, a meno che non si tratti di meri metodi get / set di propriet.

UML dalla teoria alla pratica

17

Il mapping tra modello e linguaggio di programmazione permette anche la realizzazione di funzioni di reverse engineering: fornendo a un opportuno tool i codici sorgenti o, talune volte anche quelli compilati, questo in grado di ricostruire a ritroso il modello fino, ovviamente, alla fase di disegno. Purtroppo non si ancora riusciti a realizzare un tool in grado di ricostruire i requisiti del cliente: un vero peccato! Il processo diretto (engineering) e quello inverso (reverse engineering) determinano quello che in gergo viene definito round-trip engineering. Nel mondo ideale, la funzione di reverse non dovrebbe mai venir utilizzata In quello reale invece molto apprezzata, e tutto dipende dalluso che se ne fa. In fase di disegno, probabilmente non opportuno disegnare tutto dettagliatamente; verosimilmente opportuno lasciare qualche margine ai programmatori (tutto in funzione delle loro capacit). Sono ritenute assolutamente naturali e accettabili modifiche del modello in fase di codifica, fintantoch queste non stravolgano il modello stesso. Durante la fase di codifica pu anche accadere di accorgersi che una data libreria non funziona come dovrebbe, o che c qualche lacuna nel modello, o che risulta opportuno cambiare qualche strategia al fine di ottenere un codice pi efficiente Tutto ci normalissimo. Tuttavia, nelleventualit che le modifiche generino uno stravolgimento del modello, piuttosto che procedere nellimplementazione sarebbe forse opportuno introdurre unopportuna iterazione della fase di disegno e successiva codifica. Per ci che concerne lutilizzo dello UML per la fase di documentazione, la tentazione di considerare il tutto fin troppo ovvio forte; ma la famosa vocina dellesperienza si fa sentire. Un progetto, per quanto ben congegnato, potrebbe perdere gran parte del suo fascino se poco documentato, o addirittura potrebbe finire per non essere compreso e in futuro non venire correttamente aggiornato. Per terminare, lo UML fornisce sia dei meccanismi molto formali, sia del testo libero da aggiungere, ogni qual volta lo si ritenga necessario, a parti ritenute poco chiare o particolarmente complesse, al fine di aumentarne il livello di dettaglio.

Che cosa non lo UML


Riportata la definizione formale del linguaggio, si ritiene opportuno ribadirne il concetto da un altro punto di vista: che cosa lo UML non . Potrebbe sembrare ridondante e invece probabilmente il caso del melius abundare quam deficere: c sempre il distratto di turno. In primo luogo, sebbene ci dispiaccia a molte persone, lo UML non un linguaggio di programmazione visuale, anche se questa sar probabilmente la sua naturale evoluzione). In ogni modo, chi ritiene che la modellazione sia inutile in quanto coincidente con la codifica sappia che lo UML non gli sar di particolare aiuto. Il linguaggio di modellazione definisce un metamodello semantico ma non un tool di interfacciamento o di memorizzazione, e nemmeno un modello in grado di essere eseguito.

18

Capitolo 1. UML: che cosa

, che cosa non

La documentazione dello UML include molti suggerimenti utili alle aziende che si occupano di realizzare dei tool di supporto, ma non stabilisce ogni necessario particolare. Per esempio, non vengono presi in considerazione dettagli quali la selezione dei colori da utilizzare nella costruzione di diagrammi, la navigazione allinterno del modello, le modalit con cui memorizzare le informazioni, e cos via. Infine lo UML non un processo di sviluppo, sebbene alcuni tecnici tendano a confondere i ruoli: lo UML solo un linguaggio di modellazione e, in quanto tale, si presta a rappresentare i prodotti generati nelle varie fasi di cui un processo composto. Pertanto lo UML, contrariamente ai processi, non fornisce alcuna direttiva su come fare evolvere il progetto, n attraverso quali fasi farlo transitare, n tantomeno su quali siano i manufatti da produrre, o su chi ne sia responsabile ecc.

Metamodello e meta-metamodello
Definizioni di metamodello e meta-metamodello
Contrariamente a convinzioni comuni in molti tecnici, lo Unified Modeling Language, non unicamente una notazione standard per la descrizione di modelli Object Oriented di sistemi software; si tratta bens di un metamodello definito rigorosamente che, a sua volta, istanza di un meta-metamodello definito altrettanto formalmente. Si provveder ora a illustrare brevemente i succitati concetti e le inerenti relazioni, senza avere la pretesa di fornirne una descrizione dettagliata, per la quale si rimanda sia allapposita Appendice A, sia a testi specializzati e in particolare al documento di specifica dellOMG. Ancora una volta si tratta di una materia cos vasta che, probabilmente, meriterebbe un libro a s stante. Ma largomento ha unimportanza e un fascino cos elevato che sarebbe stato un vero peccato escluderlo dalla trattazione del presente libro. Un metamodello un modello a sua volta istanza di un meta-metamodello, fruibile per esprimere una sua istanza di modello: lUML (metamodello) permette di realizzare diversi modelli Object Oriented (modelli definiti dallutente). Il metamodello dello UML definisce la struttura dei modelli UML. Un metamodello non fornisce alcuna regola su come esprimere concetti del mondo OO, quali ad esempio classi, interfacce, relazioni e cos via, ma esso rende possibile avere diverse notazioni che si conformano al metamodello stesso. Per esempio, in UML una classe viene rappresentata da un rettangolo suddiviso in tre sezioni. Unaltra notazione (in modo molto originale ma poco appropriato) potrebbe stabilire di rappresentare il concetto di classe per mezzo di un apposito pseudo-codice e di visualizzare le relazioni graficamente. Entrambe le notazioni, se definite rigorosamente, rappresentano istanze del metamodello, e sono quindi valide a tutti gli effetti. Un metamodello pu specificare che una relazione di associazione deve avere due o pi terminazioni di associazione, ma non prescrive assolutamente che essa vada rappresentata per mezzo di una linea che connette due classi.

UML dalla teoria alla pratica

19

Cos come avviene nella relazione che lega le classi agli oggetti una volta definita una classe si possono avere svariate istanze della stessa (oggetti) analogamente possibile progettare un numero infinito di varianti dello UML (istanze del metamodello). Al fine di evitare unennesima proliferazione di dialetti sembrerebbe che non appena si lasci un minimo spazio di azione, i generatori naturali di entropia tendano a prendere il sopravvento lo OMG ha anche definito la notazione standard conforme al metamodello, comunemente denominata UML. A dire il vero le cose non sono proprio andate cos; si piuttosto utilizzata una metodologia Bottom-up: partendo da un oggetto concreto (lo UML) e procedendo per astrazioni successive, stata definita la classe (il metamodello). Nelle sue prime apparizioni ufficiali lo UML era composto semplicemente da una notazione grafica, fruibile per rappresentare modelli di sistemi Object Oriented. Quando poi giunto il momento della sottomissione allo OMG, per il riconoscimento ufficiale di standard (gennaio 1997), si reso necessario conferirgli una veste pi formale. Cos a partire dalla versione 1.1 lo UML definisce rigorosamente un metamodello e la notazione atta alla formulazione di modelli Object Oriented conformi a esso. Fin qui quasi tutto chiaro Forse. Volendo per procedere oltre, i concetti diventano un po pi articolati. In effetti, cos come in molti linguaggi di programmazione Object Oriented esiste il concetto di metaclasse (classe le cui istanze sono costituite da altre classi), anche il metamodello unistanza di unentit di livello di astrazione superiore: il meta-metamodello. Un meta-metamodello un modello che definisce un linguaggio per esprimere un metamodello. Chiaro no? La relazione tra il meta-metamodello e il metamodello paragonabile a quella esistente tra il metamodello e il modello. Lo UML definito in termini di un meta-metamodello denominato MOF: Meta Object Facility. Nella fig. 1.4 viene illustrato graficamente quanto emerso fino a questo punto: relazioni esistenti tra il meta-metamodello, il metamodello e il modello dellutente. Scorrendo il diagramma dallalto verso il basso si assiste a una graduale diminuzione del livello di astrazione: se si fosse deciso di visualizzare un ulteriore livello, si sarebbero trovate entit istanze della classe del modello dellutente: oggetti. Se per esempio si realizzasse un prototipo di un sistema di commercio elettronico (i famosi siti .com), a livello del modello realizzato dallarchitetto, si troverebbero classi, opportunamente relazionate tra loro, del tipo: Categoria, SottoCategoria (probabilmente lorganizzazione in Categorie si presta ad essere rappresentata per mezzo del pattern Composite), Prodotto, Utente, Profilo, e cos via. Se poi si volesse visualizzare lulteriore livello, listanza delluser model, bisognerebbe inserire oggetti, istanze di tali classi, come per esempio il Prodotto di codice X, avente prezzo Y, della categoria Z, e cos via. Per avere unidea pi chiara, si consultino la tab. 1.1 e il diagramma riportato nella fig. 1.5. Come si pu notare, nel modello di analisi compare una classe denominata Ordine appartenente al dominio del problema. La classe unistanza della metaclasse, presente nel package UML metamodello e contiene attributi ed operazioni che, a loro volta, sono

20

Capitolo 1. UML: che cosa

, che cosa non

Figura 1.4 Meta-metamodello, metamodello e modello UML.

document

MOF - meta-metamodel

Specifica meta-meta classi per il metamodello.

instanceOf

document

MOF - meta-metamodel

Specifica meta classi per il metamodello. Esempio: Classe

instanceOf

document

MOF - meta-metamodel

Specifica classi per il Modello UML dell'architetto.

istanze rispettivamente delle metaclassi Attributi e Operazioni. Se anche in questo caso si fosse deciso di visualizzare un ulteriore livello si sarebbero trovate le istanze delle classe Ordine, ossia oggetti del tipo: 00000312 : Ordine.

Linguaggi e processi
A questo punto opportuno chiarire la relazione che lega i linguaggi di modellazione, con particolare riferimento allo UML, ai metodi di sviluppo del software: spesso si tende a confonderne le relative funzioni. Lo UML un linguaggio di progettazione e, come tale, solo parte di metodi pi generali per lo sviluppo del software: lo UML un formalismo utilizzato dai processi per realizzare, organizzare, documentare i prodotti generati dalle fasi di cui il processo si compone. Un metodo, tra i vari princpi, formato dalle direttive che indicano al progettista cosa fare, quando farlo, dove e perch. Un linguaggio invece carente di questo aspetto.

UML dalla teoria alla pratica

21

Tabella 1.1 La scala di astrazioni: dal meta-metamodello agli oggetti utente.

livello

descrizione

elementi
MetaClassi MetaAttributi MetaAssociazioni Mof::Classi Mof::Attributi Mof::Associazioni

M3

MOF Core

Definizione degli oggetti utilizzati per specificare metamodelli.

M2

Metamodello

Metamodello definito in termini degli elementi appartenenti al core del MOF.

UML: Classi, Attributi, AssociazioniData Warehousing: Base di Dati, Tabelle, ennuple,

M1

Modello

Il modello la descrizione delle informazioni del dominio del problema, effettuata attraverso lo UML. A dir il vero molto di pi

UML classi: Cliente, Item, Ordine, UML associazioni: Prodotti ordinati(Business Entities and processes)

M0

Oggetti utente

Istanze degli elementi del modello.

Cliente #00DNLMDRCliente #01BRZRIOItem #00HSFRNTItem #01HITECHOrdine #0000003Associazione tra Ordine #0000233 e Item #00HSFRNT

Va da s che i processi svolgono un ruolo assolutamente fondamentale nella realizzazione di progetti di successo, e non solo in campo informatico. Talvolta, nonostante tutti i migliori prerequisiti, si assiste al fallimento di un progetto perch lo sviluppo non stato guidato da un processo ben definito o perch non stato ben gestito: spesso i processi costituiscono la differenza tra progetti iperproduttivi e progetti fallimentari.

22

Capitolo 1. UML: che cosa

, che cosa non

Le varie ipotesi di processi di produzione del software, in ultima analisi, rappresentano tentativi di conciliare la produzione della testa (analisi e progetto) con quella delle mani (codifica e test). Il tempo, la quarta dimensione in cui siamo imprigionati, chiaramente, svolge un ruolo importante nella produzione di qualsiasi oggetto o servizio, ma scorre in modo diverso a seconda dellattivit nella quale viene impegnato. Non esiste il processo universalmente valido o che risulti ottimale per ogni progetto. Alcune volte necessario conferire particolare attenzione ai requisiti del cliente, altre allarchitettura da utilizzare, altre volte ancora necessario tenere sotto controllo i rischi pi rilevanti del progetto e cos via. Il processo, per sua natura, deve essere rapportato allorganizzazione, alla relativa cultura tecnologica, al particolare dominio del problema, alle capacit del team, e cos via. Figura 1.5 Esempio delle relazioni ai vari gradi di astrazione tra i modelli UML.

metamodel

UML metamodel
Class Association

metamodel

UML metamodel
Instance of MetaClass Instance of MetaAssociation Instance of MetaClass

IDL for UML


IDL for Class IDL for Class-Association IDL for Association

UML dalla teoria alla pratica

23

Un linguaggio, uno strumento nel caso dello UML un insieme di strumenti da utilizzarsi per realizzare, descrivere e documentare i modelli prodotti nelle varie attivit di cui si compone un modello. Un linguaggio costituito da una sintassi, una semantica e dei paradigmi. Nel linguaggio naturale la sintassi costituita sia dalle norme che regolano il coordinamento delle parole (in UML, i simboli dei diagrammi) nelle proposizioni sia da quelle che specificano come organizzare tali proposizioni allinterno di un periodo (in UML, come combinare i simboli, quali possono essere associati e quali no, come, ecc.). La semantica si occupa del significato delle parole (simboli), considerate sia singolarmente, sia nel contesto nel quale vengono utilizzate (significato dei simboli in un particolare diagramma). Infine, un particolare paradigma potrebbe contenere le direttive atte a conferire determinate forme, variabili a seconda dei casi, aggiungendo quindi chiarezza e precisione ad alcuni elementi della lingua (in UML, come realizzare modelli chiari, leggibili, eleganti, ecc.). In quanto linguaggio di modellazione, lo UML quindi indipendente dal processo che si utilizza per lo sviluppo del software. I processi pi popolari nelle aziende di produzione del software tipicamente si fondano su uno dei seguenti aspetti: Use Case Driven (il processo guidato dalla vista dei casi duso, ossia dai requisiti utente), lo Architecture Centric (incentrato sullarchitettura), lo Iterative and Incremental (iterativo e incrementale). Come spesso accade nel mondo dellinformatica, difficile trovare un metodo da applicare alla pratica cos come previsto dalla teoria. Molto pi frequentemente il processo un ibrido generato dalla fusione di caratteristiche presenti anche in altri metodi. Per esempio, non infrequente il ricorso a un processo basato sui casi duso, che preveda il raggiungimento del modello finale attraverso un processo iterativo e incrementale e che, a ogni iterazione, sviluppi il relativo contenuto semantico. La Rational, visto il grande successo riscosso con lo UML, ha sostenuto il progetto volto a diffondere la relativa standardizzazione anche al mondo dei processi (consultare il paragrafo dedicato allo Unified Software Development Process). Si tentato di applicare la strategia dimostratasi vincente con lo UML al settore dei processi, affidando lincarico alle stesse persone: i Tres Amigos. Il risultato stato denominato USDP (Unified Software Development Process) [BIB08] poi confluito nel RUP (Rational Unified Process). In questo caso, nonostante lenorme successo riscontrato, laccettazione dellUSDP come standard decisamente pi difficoltosa, per via di tutta una serie di problemi, non ultimi i retaggi culturali radicati nelle aziende, lutilizzo storico di standard interni e internazionali e cos via. Come gi asserito, lapplicazione di processi dipende molto dalle caratteristiche peculiari delle organizzazioni: quelli che possono risultare vincenti in alcune potrebbero rivelarsi assolutamente fallimentari in altre. Probabilmente la necessit di disporre di un processo unificato non era e non cos avvertita contrariamente a quanto si verificato con il linguaggio. I tre processi elencati precedentemente si differenziano essenzialmente per via del particolare aspetto, ritenuto fondamentale per lintero ciclo di vita. Il primo (Use Case Driven)

24

Capitolo 1. UML: che cosa

, che cosa non

probabilmente il pi popolare, come suggerito dal suo stesso nome basa tutta la progettazione sugli use case, utilizzati per stabilire il comportamento del sistema, per verificarne e validarne larchitettura, per eseguire la fase di test, ecc. Il secondo invece (Architecture Centric), pone in primo piano la progettazione dellarchitettura del sistema, considerata come il manufatto primario per la concettualizzazione, la costruzione, e la gestione dellevoluzione del sistema in costruzione. Infine lultimo (Iterative and Incremental) basato sulliterazione incrementale del modello. Un processo di sviluppo iterativo comporta la realizzazione di versioni successive del sistema, e un processo incrementale richiede lapporto di continui arricchimenti dello stesso per ottenere le relative nuove versioni. La fusione delle due modalit operative genera unaltra metodologia definita risk-driven in quanto ogni nuova versione del sistema incentrata sulla risoluzione del fattore di rischio ritenuto pi pericoloso nella precedente versione.

Il famoso gap: mind the gap


Nel libro Use Case Driven Object Modeling with UML [BIB05] viene proposta unimmagine, simile a quella in fig. 1.6, che di per s chiarisce, pi di molte parole, articoli e libri, uno dei principali problemi della progettazione: il salto del gap, il passaggio dalle specifiche del cliente alla realizzazione del modello di disengo del sistema (questi argomenti vengono trattati in maniera approfondita nel relativo capitolo). Alcune persone, confortate anche dallimpostazione di taluni tool CASE, confidano sul fatto che il problema sia passare dal disegno alla codifica: niente di meno vero! Tale passaggio abbastanza diretto a patto di non avere i famosi programmatori object disoriented. Il problema reale esprimere in termini di componenti software sia il dominio del problema sia linfrastruttura necessaria per sostenere il tutto. Per quanto concerne Figura 1.6 Il gap della progettazione del software.

UML dalla teoria alla pratica

25

linfrastruttura, le nuove architetture (come per esempio J2EE), cercano di semplifcare sempre di pi il problema della realizzazione dellinfrastruttura). Chi scrive ha avuto modo di constatare quanto sia gravoso superare il famoso gap: sperimentandolo in prima persona attraverso la realizzazione di progetti Object Oriented di grandi dimensioni, attraverso il preziosissimo feedback maturato nellambito della collaborazione con la rivista web MokaByte e, infine, nellambito dellinsegnamento di UML. Il problema tipo riscontrato che i neofiti, pur avendo compreso come funzioni lo UML, eventualmente con qualche lacuna, non lo sanno poi applicare alla pratica. Come si pu ben intuire, ancora una volta il problema strettamente connesso allesperienza e al processo utilizzato, piuttosto che al linguaggio di per s. Un buon supporto rappresentato dai vari libri dedicati ai Design Pattern e ai processi. il caso di sottolineare che, cos come conoscere un linguaggio non significa necessariamente essere bravi programmatori, conoscere lo UML non significa assolutamente essere in grado di produrre buoni disegni n tantomeno essere bravi architetti. Un valido aiuto viene fornito dal processo il quale deve: 1. provvedere le linee guida e il relativo ordine delle attivit che il team deve svolgere; 2. specificare quali manufatti debbano essere prodotti in ogni fase; 3. fornire direttive allo sviluppo sia dei singoli programmatori sia del team; 4. offrire dei criteri per controllare e misurare i prodotti e le attivit del progetto. La trattazione di tale argomento necessiterebbe da solo di un libro a s stante: come si suol dire, esula dai fini del presente libro. Ci nonostante nei seguenti paragrafi si tenter di affrontarlo, seppur molto parzialmente, consigliando lo studio dei libri [BIB05] e [BIB06] a tutti coloro che desiderassero approfondire largomento.

Processi Use Case Driven


I sistemi software, in primo luogo, dovrebbero essere realizzati per soddisfare specifiche esigenze dellutente anche se, a volte, specie nel Belpaese, il fine decisamente meno nobile Logica conseguenza che, per produrre un sistema il quale effettivamente realizzi gli obiettivi per il quale stato finanziato, indispensabile chiarire la prospettiva del cliente, le relative necessit, le aspirazioni pi o meno recondite, ecc.: tutto ci che comunemente viene indicato con specifiche utente. Occorre inoltre tenere bene a mente queste ultime durante tutto il ciclo di vita del software: lutente non sempre lidiota che inserisce i dati nelle caselle di testo e successivamente preme il tasto OK. I team tecnici, tipicamente,

26

Capitolo 1. UML: che cosa

, che cosa non

tendono a non provare sufficiente rispetto per le esigenze degli utenti finali. Discorso a parte andrebbe fatto per taluni committenti che rivendono i sistemi limitandosi ad aggiungere un paio di zeri prima della virgola nella fattura: ci sono 99 possibilit su 100 che raccontino inesattezze. Come si vedr nel capitolo dedicato ai casi duso, non sempre cos semplice tenere conto di tutte le specifiche utente, per una serie di motivi: difficolt di stabilire una piattaforma di intesa comune, background e prospettive diverse, esigenze contrastanti, ecc. Focalizzare, fin dalle primissime fasi del ciclo di vita del software laderenza dei vari modelli alle richieste del cliente, continuando a monitorarle, pu risultare una mossa vincente. da tener presente che lutente del sistema (attore) non sempre un operatore umano: pu essere un altro sistema o un qualsiasi dispositivo fisico. In generale si tratta di unentit esterna al sistema che interagisce con esso. Se, per esempio, si volesse realizzare un sistema di elaborazione automatica e smistamento di documentazione in formato digitale, il quale, a partire da modelli di documenti riesca a completarne il contenuto, richiedendo ai vari enti le informazioni mancanti (dati anagrafici, penali, pensionistici, ecc.), i vari attori del sistema sarebbero, oltre che diversi operatori, altri enti in grado di produrre, completare, ricevere e inoltrare file di documentazione. Se si volesse poi rendere possibile memorizzare tali documenti, corredati da opportune firme digitali in apposite smart card di propriet degli utenti, anche queste risulterebbero attori. Tipicamente un sistema, a fronte di uniterazione avviata da un utente, risponde eseguendo una sequenza di azioni in grado di fornire allattore stesso i risultati desiderati: produzione del documento, completamento dello stesso con laggiunta dei dati richiesti, inoltro verso opportuno destinatario, e cos via. Tali interazioni costituiscono quello che viene denominato caso duso (Use Case), si tratta cio di una parte delle funzionalit del sistema che fornisce allutente determinati valori. La sommatoria di tutti i casi duso costituisce la proiezione statica dello Use Case Model, il quale, oltre a specificare quali siano le funzionalit che il sistema deve realizzare e fin qui non ci sono grosse novit rispetto ai metodi tradizionali, eccezion fatta per il formalismo grafico , mette in rilievo gli attori coinvolti e le relative interazioni con il sistema. Quindi, ancora una volta, gli Use Case risultano particolarmente focalizzati sul ruolo degli attori. La centralit degli attori dovrebbe spingere il progettista a pensare il sistema non solo in termini delle funzionalit da realizzare, ma anche in termini del valore da fornire agli utenti. Dunque, i casi duso non vengono utilizzati unicamente come formalismo per la specifica formale dei requisiti utente, ma come valido supporto alle altri fasi, ossia disegno, implementazione e test. In altre parole essi guidano lintero processo di sviluppo. Logica conseguenza che i prodotti generati nelle varie fasi sono modelli che realizzano, in qualche misura, i casi duso. I programmatori dovrebbero continuamente rivedere il codice, al fine di verificarne laderenza con quanto sancito nei casi duso codificati, mentre i tester dovrebbero prova-

UML dalla teoria alla pratica

27

re le funzionalit del codice, per accertarsi che il sistema realizzi effettivamente quanto sancito nelle specifiche. Sintetizzando, lintero ciclo di vita ruota attorno alla Use Case View, vale a dire che i casi duso vengono progettati, soprassiedono la fase di disegno, vengono implementati e infine, nei test di sistema, si verifica che il sistema realizzi quanto stabilito. Nel paragrafo dedicato al processo ICONIX, viene fornita unistanza di processo Use Case Driven.

Processi Architecture Centric


Il ruolo dellarchitettura di un sistema software pu essere, per molti versi, ricondotto a quello svolto dallarchitettura nelle costruzioni civili. Ledificio viene studiato da parte del team di progettisti da diversi punti di vista: struttura, sicurezza, servizi, tubature, riscaldamenti, e cos via, in modo che se ne abbia una visione completa prima di avviare la costruzione effettiva: perla di saggezza! Allo stesso modo larchitettura di un sistema software descritta per mezzo di diverse viste prima che venga iniziata la codifica del sistema. I relativi concetti comprendono gli aspetti pi significativi della proiezione statica e dinamica del sistema. Larchitettura, in ultima analisi, dovrebbe venire progettata con lintento di fornire linfrastruttura necessaria per il soddisfacimento dei requisiti utente e, come tale, dovrebbe essere funzionale alla Use Case View. Larchitettura, chiaramente, influenzata da molti altri fattori tra i quali: la piattaforma sulla quale il sistema dovr funzionare (architettura di rete, sistemi operativi presenti, gestori di base di dati, modalit di comunicazioni tra sistemi esistenti, ); riusabilit di determinati componenti (framework, interfacce utente, ), considerazioni di dispiegamento (adattamento dei componenti sullarchitettura fisica), presenza di legacy system, requisiti non funzionali (prestazioni, robustezza, efficiente utilizzo delle risorse), e cos via. Larchitettura la vista del disegno nella sua globalit, grazie alla quale si evidenziano gli aspetti di maggiore importanza, mentre gli altri dettagli vengono lasciati appositamente fuori. La valutazione di quali aspetti siano pi interessanti e quali, invece, lo siano meno un metro soggettivo e come tale dipende dallesperienza dei singoli. Comunque ciascun metodo di sviluppo offre linee guida come comprensibilit, flessibilit, capacit di adattamento a futuri cambiamenti, riusabilit, e cos via.

Processi iterativi e incrementali


Lo sviluppo di un sistema software un processo che pu richiedere mesi o anni, mentre la relativa manutenzione, se il software si rivela di successo, pu richiedere un ordine di grandezza superiore. Queste considerazioni di carattere empirico hanno finito inevitabilmente per fornire un prezioso feedback ai processi di sviluppo: lintero processo viene infatti suddiviso in

28

Capitolo 1. UML: che cosa

, che cosa non

Figura 1.7 Schematizzazione di un processo software.

Processo

diversi miniprogetti, ognuno dei quali uninterazione che produce un incremento significativo del progetto globale. Le varie iterazioni non dovrebbero essere frutto del caso o dellumore degli architetti, dovrebbero bens essere debitamente pianificate e controllate, vale a dire che dovrebbero essere veri e propri miniprogetti completi. La scelta di cosa realizzare a ogni iterazione dovrebbe dipendere da due fattori: selezione del gruppo di use case in grado di estendere ulteriormente le funzionalit del sistema, considerando il punto di evoluzione raggiunto o da raggiungere nelliterazione precedente; rischi pi pressanti. Giacch ogni iterazione un miniprogetto, questa dovrebbe includere tutte le fasi relative: analisi, disegno, implementazione e test. Non sempre uniterazione produce un aumento quantitativo del modello; ma spesso tale aumento si pu risolvere nella sostituzione di parti di disegno/implementazione con altre pi dettagliate e/o pi sofisticate. Infatti pu accadere di realizzare velocemente parti del disegno, e relativa implementazione, senza curarne troppo la struttura interna, rimandando quindi la relativa reingegnerizzazione a ulteriori iterazioni. Ci si rivela particolarmente utile quando tali sottosistemi forniscono linfrastruttura o le funzionalit utilizzate da altri. Pu infatti risultare conveniente realizzare prime versioni, seppur grezze, di un particolare sottosistema, al fine di dare modo alle altre parti dipendenti di poter evolvere liberamente. Lintento quello di reingengerizzare tali versioni prototipali in un secondo momento, disponendo di maggior calma e migliori informazioni (magari applicando opportuni criteri, come quelli specificati nel libro Refactoring di Fowler). Ancora una volta possibile ricorrere a tale approccio attraverso lutilizzo intelligente delle interfacce. Si potrebbe, per esempio, progettare e realizzare una prima versione del sistema di sicurezza magari in grado di fornire risposte costanti senza che esso realizzi alcun meccanismo specifico, solo per fornire agli altri sottosistemi la possibilit di poter eseguire dei test.

UML dalla teoria alla pratica

29

Nella realizzazione dei casi duso ritenuti fondamentali per literazione in atto (Use Case Driven), necessario utilizzare come guida anche larchitettura stabilita (Architecture Centric), realizzando pertanto il disegno nei termini di componenti compatibili con essa. Al termine di ciascuna iterazione indispensabile verificare che essa abbia effettivamente raggiunto gli scopi prefissati, ossia che la nuova versione del sistema realizzi correttamente i casi duso selezionati. In caso affermativo si pu procedere con literazione successiva, altrimenti necessario introdurre una fase di revisione, nella quale, pu rendersi necessaria anche una completa revisione dellapproccio utilizzato in precedenza. Per avere migliori possibilit di riuscita, un progetto dovrebbe seguire liter pianificato, pur con minime deviazioni dovute a imprevisti, i quali dovrebbero comunque sempre essere tenuti in considerazione allatto della pianificazione del processo stesso. I vantaggi nellutilizzo di metodi di sviluppo iterativo e incrementale sono: riduzione dei costi dovuti a errori o imprevisti generatisi durante una singola iterazione. Se per qualche motivo si rende necessaria lintroduzione di una nuova iterazione, lorganizzazione impegnata nello sviluppo viene penalizzata solo per il relativo contesto senza per intaccare lintero prodotto. riduzione del rischio di non produrre il sistema nei tempi previsti. Identificare fin dallinizio i rischi maggiori e assegnare un congruo periodo di tempo per la realizzazione della relativa soluzione, dovrebbe consentire alle varie persone coinvolte di trattare il rischio con la dovuta calma, evitando paradossalmente di aggravare la situazione per via di eventuali stati dansia dovuti a potenziali ritardi. Seguendo i metodi tradizionali comune osservare come nel momento in cui un un problema viene evidenziato si generi laffanno di risolverlo, temendo di produrre un ritardo nei tempi di consegna. Come direbbe Murphy: se esiste la possibilit che una cosa vada male, sicuramente andr male!. riduzione del tempo necessario per rilasciare il sistema globale. Ci dovrebbe essere il risultato di un lavoro pi razionale e dominato da obiettivi pi immediati e ben riconoscibili. maggiore flessibilit in caso di modifiche dei requisiti utente. Nella pratica si verifica che molto raramente si riescano a identificare sin da subito e correttamente le specifiche del cliente, anche per via di sue inequivocabili responsabilit. Paradossalmente la comprensione di esse, nella loro globalit, si raggiunge a progetto ultimato. La suddivisione in iterazioni e la realizzazione di insiemi ben identificati di casi duso, rende pi facile la possibilit di verificare il sistema in maniera incrementale e di evidenziarne eventuali anomalie.

30

Capitolo 1. UML: che cosa

, che cosa non

The Unified Software Development Process


Nei prossimi paragrafi viene presentato, sin troppo brevemente, il processo di sviluppo del software, ideato dai Tres Amigos presso la Rational e denominato processo unificato di sviluppo software (Unified Software Development Process). Quanto riportato tratto dal libro [BIB08] al quale si rimanda per una trattazione pi approfondita dellargomento cos indispensabile per la produzione di sistemi software di elevata qualit. Lutilizzo consapevole di un buon processo pu, da solo, produrre la differenza tra un progetto fallimentare e uno altamente produttivo, sebbene in molte organizzazioni la produzione del software sia ancora basata su processi ideati ai tempi delle schede perforate oppure standardizzati da personale commerciale o addirittura inesistenti o demandata alla responsabilit e allesperienza dei singoli (leggasi inesistente). Chiaramente si tratta di una condizione necessaria, ma non sufficiente! Un processo di sviluppo software costituito dal complesso di attivit necessarie per trasformare i requisiti utente in un sistema software. Lo Unified Software Development Process, in realt, non semplicemente un processo bens un framework di un processo generico. Esso si presta a essere proficuamente utilizzato per classi piuttosto estese di sistemi software, differenti aree di applicazioni, diverse tipologie di organizzazioni, svariati livelli di competenza e progetti di varie dimensioni. Una delle linee-guida del processo unificato di essere component-based: il sistema da realizzare viene basato su componenti e interconnesioni fra i componenti stessi, fondate su opportune e ben definite interfacce. In questo contesto, per componente si intende una parte fisica e sostituibile di un sistema che si conforma e fornisce la realizzazione di un insieme ben definito di interfacce. Queste ultime sono collezioni di operazioni, utilizzate per specificare un servizio offerto da una classe o da un componente. Vista limportanza e leleganza di questi concetti e la loro centralit nella produzione di sistemi Object Oriented, si deciso di trattare tali argomenti in dettaglio nel capitolo

Figura 1.8 Esempio di suddivisione del sistema in sottosistemi.


subsystem Services UserInterface SystemCore framework SecurityServices subsystem SecuritySystem

ResultListener

NotificationListener RemoteServices subsystem ClientBusinessLogic subsystem RemoteSystem

UML dalla teoria alla pratica

31

appropriato, ossia quello dedicato ai diagrammi delle classi (Capitolo 7). Per ora basti sapere che tale approccio si basa sulla suddivisione del sistema globale in diversi sottositemi, comunicanti per mezzo di interfacce che, in questo contesto, assumono la valenza di un contratto. Un sottosistema si impegna a fornire i servizi esposti nelle relative interfacce, mentre un altro le utilizza impegnandosi a rispettarne le condizioni. Il processo unificato, ovviamente, utilizza lo UML per produrre e documentare i manufatti prodotti in ciascuna delle fasi di cui si compone. Altra caratteristica peculiare, offerta dal processo, la fusione razionale dei tre principali metodi esistenti: Use Case Driven, Architecture Centric e Iterative and Incremental. Forse ci non solo lo rende unico ma, verosimilmente anche raro da utilizzare nella sua versione originale. Se da una parte, infatti, linsufficienza cronica di tempo non pu e non deve giustificare la produzione di sistemi software non guidati da un processo e tantomeno pu giustificarne la produzione incentrata sulla sola fase di codifica, dallaltra bisogna ammettere che il problema tempo esiste ed molto sentito. Forse, se possibile avanzare una critica al processo unificato, si pu dire che esso necessita di una notevole quantit di tempo, non sempre disponibile, per poter essere attuato cos come proposto.

Integrazione tra Use Case Driven e Architecture Centric


Ogni prodotto possiede delle funzionalit e una forma fisica. Il problema sta nel trovare il giusto equilibrio per riuscire a generare un valido prodotto. Nel caso di sistemi software le funzionalit vengono modellate per mezzo della vista dei casi duso mentre la forma rappresentata dallarchitettura. Tra le due viste esiste una forte interdipendenza: il sistema che realizza la Use Case View deve conformarsi allarchitettura fisica, la quale, a sua volta, deve fornire lo spazio necessario al soddisfacimento dei requisiti utente, sia quelli attuali, sia quelli futuri Le due viste dovrebbero evolvere parallelamente attraverso una successione di sincronizazzioni. Larchitetto, nel conferire la forma al sistema (progettazione dellarchitettura), deve prestare attenzione sia a fornire un appropriato ambiente per la versione iniziale, sia a consentire a eventuali versioni future di adattarsi senza grandi problemi. Per individuare la forma migliore, necessario essere in grado di comprendere le funzionalit che il sistema dovr fornire; chiaramente non necessario conoscerle perfettamente tutte. In particolare larchitetto dovrebbe: generare un disegno iniziale di architettura che non sia specificamente connessa ai requisiti utente (use case independent), sebbene ne debba possedere una certa conoscenza. Ci conseguibile iniziando a tener presenti i vincoli dettati dalla piattaforma, dal network che si utilizzer, e cos via. Tipicamente si ragiona in termini di pattern architetturali o pi semplicemente si cerca di ricondursi ad architetture o opportuni segmenti di esse dimostratesi efficaci in precedenti progetti.

32

Capitolo 1. UML: che cosa

, che cosa non

a questo punto necessario lavorare con forte aderenza ai casi duso. Vengono selezionati quelli ritenuti pi importanti o significativi e, di ciascuno di essi, vengono forniti i dettagli in termini di sottosistemi, classi e componenti. non appena i casi duso sono stati ben specificati e presentano una certa stabilit, si procede con una verifica dellarchitettura che a sua volta potrebbe fornire nuovi elementi per migliorare i casi duso. Tale processo viene iterato fin quando anche larchitettura viene considerata stabile.

Ciclo di vita del processo


Lo Unified Software Development Process integra i tre principali processi di sviluppo tra cui lIterative and Incremental; pertanto la realizzazione del sistema avviene attraverso cicli di iterazioni controllate, ognuna delle quali termina con la produzione di una nuova versione del sistema. Ogni ciclo costituito da quattro fasi: iniziale, elaborazione, costruzione e transizione, ognuna delle quali , a sua volta, suddivisa in iterazioni. Risultato di ogni ciclo la produzione di una nuova versione del sistema virtualmente pronta per la consegna. Grosso vantaggio di questo criterio che anche il processo di verifica iterativo e incrementale: ogni volta che una nuova versione disponibile viene sottoposta a relativa fase di test. Ci dovrebbe favorire la produzione di sistemi di migliore qualit. Nel mondo dellideale, ogni versione dovrebbe consistere in codice incapsulato in opportuni componenti eseguibili, corredati da manuali, documentazione e cos via. Sebbene dal punto di vista del cliente i componenti eseguibili siano i manufatti pi importanti, essi da soli non sono sufficienti. Ci dovuto al fatto che lambiente tipicamente destinato a variare: espansione dei sistemi hardware, aggiornamenti di sistemi operativi e database manager, ecc. Gli stessi requisiti cliente diventano pi chiari e precisi con il procedere nel ciclo di vita del software e pertanto sono soggetti anchessi ad aggiornamenti. Non a caso unidea che spesso si ingenera nei team di sviluppo a consegna avvenuta, di essere in grado di poter rifare lintero sistema pi adeguatamente e in minor tempo. I prodotti che devono accompagnare la versione finale sono: il modello dei casi duso, con evidenziate tutte le relazioni tra i diversi use case e i relativi attori e gli scenari; il modello di analisi che dovrebbe conseguire, principalmente, due obiettivi: a. definire i casi duso in maggior dettaglio; b. orientare un iniziale disegno del comportamento del sistema per mezzo dellindividuazione degli oggetti basilari che lo caratterizzano;

UML dalla teoria alla pratica

33

il modello di disegno che definisce: a. la struttura statica del sistema in termini di sottosistemi, classi, interfacce; b. la realizzazione dei casi duso per mezzo di collaborazioni attraverso i sottosistemi, le classi , ecc. evidenziati nella proiezione statica al punto precedente; il modello di implementazione che include i componenti (raggruppamento di codice) e il mapping degli stessi con le relative classi; il modello di dispiegamento (deployment) che definisce come i componenti software vadano allocati sui nodi fisici (computer, server, reti, ecc.) previsti dallarchitettura hardware; il modello di test il quale definisce i casi di test (Test Case) che verificano gli Use Case; la rappresentazione dellarchitettura. La totalit di questi manufatti rappresenta il sistema nel suo insieme. Ogni ciclo necessit di unappropriata porzione di tempo che viene suddivisa in quattro fasi che sono: iniziale, elaborazione, costruzione e transizione. Ciascuna fase pu a sua

Figura 1.9 I modelli previsti dallo Unified Process.

specificato da

Modello casi d'uso


realizzato da dispiegato come da

Modello di analisi

Modello di disegno

implementato da

verificato da

Modello di dispiegamento

Modello di implementazione

OK

OK Modello di test

OK

34

Capitolo 1. UML: che cosa

, che cosa non

volta essere ulteriormente suddivisa e termina con il raggiungimento del milestone pianificato: realizzazione dei manufatti programmati. I milestones sono importanti per diverse ragioni. In primo luogo permettono ai manager di prendere cruciali decisioni prima di considerare conclusa una fase e passare alla successiva. Successivamente risultano utili anche per gli sviluppatori in quanto permettono di monitorare la progressione delle attivit assegnate. Infine, tenendo traccia del tempo speso e delle problematiche emerse in ciascuna fase, possibile raccogliere tutta una serie di informazioni da utilizzarsi nella pianificazione dei progetti futuri. Nella fase iniziale di ogni ciclo (detta inception) si ipotizzano diverse soluzioni e lidea migliore viene sviluppata in una visione del prodotto della quale vengono forniti gli scenari di utilizzo. Obiettivo della fase di inception essenzialmente fornire risposte adeguate agli interrogativi riportati di seguito: quali sono le funzioni basilari che il sistema deve fornire per ciascuno dei principali attori? qual il modello di massima dellarchitettura necessaria al sistema? qual il piano e quanto dovrebbe costare lo sviluppo del prodotto? Il primo quesito trova risposta in un modello semplificato degli Use Case che ne contempli i pi critici. Per ci che concerne il secondo punto va tenuto presente che nella prima fase larchitettura poco pi di unipotesi da sviluppare in dettaglio nelle fasi successive, pertanto sufficiente che contenga i principali sottosistemi. Molto importante invece riuscire ad identificare prima possibile i rischi principali, assegnare loro la giusta priorit ed elaborare la pianificazione della fase in dettaglio. La seconda fase, nota come elaborativa (elaboration), prevede la specifica di dettaglio di tutti i casi duso e il disegno dellarchitettura la quale riveste un ruolo di primaria importanza e viene espressa per mezzo delle viste di tutti i modelli del sistema, i quali, globalmente, costituiscono il sistema stesso. Ci equivale a dire che esistono viste architetturali del modello: dei casi duso, di analisi, di disegno, di implementazione e di deployment. La vista del modello di implementazione include componenti per dimostrare che larchitettura eseguibile. In questa fase i casi duso pi critici, identificati nella fase precedente, vengono realizzati. Risultato di questa fase lArchitectural Baseline, ovvero un insieme rivisto e approvato di manufatti che: rappresentano una base stabilita per futuri sviluppi ed evoluzioni; possono essere modificati solo attraverso una procedura formale di configurazione o di cambio di gestione.

UML dalla teoria alla pratica

35

Al termine della fase elaborativa il capo progetto si trova nelle condizioni di poter pianificare le attivit e di stimare le risorse necessarie per completare lintero progetto. I pericoli di questa fase possono essere adeguatamente sintetizzati dalle seguenti inquietudini: i casi duso, larchitettura e i vari piani sono sufficientemente stabili? I rischi sono abbastanza sotto controllo perch lo sviluppo dellintero progetto in contratto sia in condizione di procedere? Terminata la seconda fase si passa a quella di costruzione (construction), in cui, come lecito aspettarsi, il prodotto viene costruito. Nel corso dellevoluzione del prodotto larchitettura di base cresce allaumentare dei dettagli del sistema e il prodotto evolve fino ad essere pronto per la trasformazione per gli utenti finali. Durante questa fase le risorse precedentemente ipotizzate vengono impiegate. Larchitettura del sistema assume una sua stabilit anche grazie al lavoro degli sviluppatori che in corso dopera ne verificano la validit ed eventualmente ne suggeriscono opportune varianti. Terminata la fase di costruzione il prodotto contiene tutti i casi duso concordati per la versione generata dalla fase in corso. Come pratica insegna, raramente si tratter di una versione senza difetti: questi sono oggetto di indagine nella fase successiva. Il milestone della fase di costruzione si raggiunge quando si certi che il prodotto risolva sufficientemente le necessit di qualche utente tanto da poterne consegnare la versione per il test. Lultima fase, di transizione (transition) comprende il periodo necessario al prodotto per divenire una versione beta. Un ristretto numero di utenti prova la versione e compila un documento con lelenco di difetti e deficienze. Questo documento viene quindi fornito a un gruppo di sviluppatori che ricontrolla il prodotto e provvede a risolvere i problemi esposti. A questo punto il prodotto pronto a essere somministrato a un gruppo di prova pi ampio. La fase di transizione dovrebbe prevedere attivit quali la manutenzione del prodotto per accogliere eventuali suggerimenti, l addestramento del personale, la fornitura di assistenza, e cos via. I suggerimenti ricevuti, tipicamente, vengono suddivisi in due categorie: quelli urgenti che quindi necessitano di essere risolti il prima possibile e quelli da demandare alle fasi successive (i famosi must, should, could).

RUP: Rational Unified Process


La Rational ha presentato un processo di sviluppo, denominato RUP (Rational Unified Process) che, lentamente, ambisce a divenire lo standard di mercato per la produzione del software. Il principale fautore Philippe Kruchten, Lead Architect della Rational. La prima versione fu rilasciata a dicembre 1998 frutto, verosimilmente, della rielaborazione di quello presentato dai Tres Amigos (illustrato nel paragrafo precedente) e del processo Objectory (frutto della medesima organizzazione di Jacobson). Al momento in cui viene scritto il presente libro disponibile la versione 5.5.

36

Capitolo 1. UML: che cosa

, che cosa non

Brevemente i vantaggi offerti dal RUP sono: basato su princpi di ingegneria del software dimostratisi efficaci: approccio Iterative and Incremental, Use Case Driven, Architecture Centric; si tratta di un processo proprietario e verosimilmente leader del mercato, pertanto frutto di continue evoluzioni grazie agli investimenti della Rational; prevede una serie di meccanismi, come per esempio i prototipi funzionanti da realizzare alla fine di ogni interazione del ciclo, i punti di decisione (go/no go) che permettono di stabilire, alla fine di ogni fase, se abortire il processo: chiaramente se il processo destinato a fallire meglio rendersene conto e quindi abortirlo il prima possibile; include un sistema semplificato di agevolazione dellutilizzo grazie alla descrizione basata su tecnologie web. Gran parte della descrizione del RUP stata riportata nella sezione dedicata ai tool di sviluppo, in quanto si tratta dellunico processo dotato di apposito software. Gli svantaggi sono: molto focalizzato nel processo di sviluppo e trascura altri flussi importanti nello sviluppo di sistemi software (come spiegato di seguito); essere iterativo e incrementale un vantaggio ma uno svantaggio al tempo stesso: richiede tutta una serie di attivit supplementari dovute alle varie iterazioni; non si integra perfettamente in organizzazioni, quali le software house, che, tipicamente, realizzano pi progetti contemporaneamente; essendo un prodotto proprietario e guidato dalle esigenze di mercato, fa s che aspetti meno pressanti vengano trascurati (tools per il disegno dellinterfaccia utente, per la modellazione dei dati, ecc.). Del RUP disponibile una versione migliorata elaborata presso la Ronin International Inc. il cui fautore principale Scott Ambler autore, tra laltro, di testi come Building Object Applications that Work (1998) e Process Patterns (1999) che ne il presidente. Tale versione, denominata EUP (Enhanced Unified Process, processo unificato miglioraro) animata dallobiettivo di perfezionare il RUP aggiungendo flussi mancanti ed espandendo opportunamente, qualora necessario, quelli esistenti. Per esempio presente una quinta fase (oltre Inception, Elaboration, Construction e Transiction) denominata Production

UML dalla teoria alla pratica

37

(produzione). Si tratta di ununica iterazione atta a gestire le attivit necessarie per mantenere il sistema operativo fino a quando sia disponibile una nuova versione o, addirittura, il sistema venga rimpiazzato da uno completamente nuovo. Unaltra innovazione data dalla presenza di un workflow denominato Operations and Supports che, come indicato dal nome, designato a gestire operazioni di sviluppo e piani di supporto. Per esempio classiche attivit di supporto necessarie a sistema rilasciato sono le attivit di backup, lesecuzione di specifici lavori batch, ecc.

ICONIX: un processo Use Case Driven


In questo paragrafo viene introdotto brevemente il processo di sviluppo Use Case Driven denominato ICONIX Unified Object Modeling. Per uno studio pi completo, si rimanda il lettore a [BIB05] e [BIB06]. I processi di sviluppo del software basati sulla vista dei casi duso sono probabilmente i pi popolari nelle aziende di informatica. In ultima analisi, sono quelli utilizzati pi o meno formalmente da sempre: si tratta di conferire la massima importanza ai requisiti funzionali di un sistema e ci da sempre ha costituito un criterio guida nello sviluppo del software. Poich il ciclo di vita viene completamente basato sulla vista dei casi duso, logica conseguenza che la use case view assume unimportanza e una criticit eccessive: un errore nella formulazione dei requisiti potrebbe determinare il fallimento dellintero processo. Si ricordi che la difficolt di comunicazione tra clienti e personale tecnico e la laboriosit nel tentare di definire una piattaforma comune hanno generato linsuccesso di molti progetti. Spesso accade che certi team siano riusciti a realizzare progetti fantastici con tecnologie ultramoderne ma con lunico neo, affatto trascurabile, di non risolvere minimamente i problemi del cliente. Per ridimensionare il pi possibile tale rischio, il processo viene frequentemente associato ad altri e spesso si utilizza un approccio incrementale e iterativo: lo sviluppo richiede diverse iterazioni del modello del dominio al fine di identificare ed analizzare completamente i vari casi duso. Altre iterazioni avvengono durante lintero ciclo di vita del software tra le viste di cui si compone. Lo stesso modello statico viene definito incrementalmente a seguito delle successive iterazioni attraverso il modello dinamico. Rappresentando le fondamenta del processo di sviluppo, la Use Case View necessita di uneccezionale attenzione; in particolare necessario stabilire con assoluta precisione ed esattezza: chi sono gli attori del sistema e quali interazioni esercitano con il sistema (Use Case View); quali sono gli oggetti del dominio del problema (lambiente che si sta automatizzando) e quali relazioni esistono tra di essi (diagramma concettuale delle classi);

38

Capitolo 1. UML: che cosa

, che cosa non

quali oggetti sono coinvolti in ogni caso duso; come gli oggetti collaborano allinterno di uno Use Case (diagrammi di interazione e collaborazione); come gestire le problematiche di controllo del mondo reale (diagrammi di stato); come costruire fisicamente il sistema (diagramma di dettaglio delle classi); Come si vedr in seguito, lo UML fornisce tutti i formalismi necessari per modellare quanto sancito nei punti precedenti nel contesto di ununica notazione. Il processo Use Case Driven come ulteriore vantaggio offre un elevato livello di tracciabilit. Con ci si intende dire che durante tutto il ciclo di vita sempre possibile risalire, pi o meno direttamente, ai requisiti del cliente. Ci permette di realizzare il disegno del sistema senza venire meno alle necessit dellutente e in pi sempre possibile seguire come gli oggetti evolvono dai casi duso allanalisi fino al disegno. Il processo di sviluppo guidato dai casi duso proposto nel libro Use Case Driven Object Modeling with UML (cfr. [BIB05]) prevede quattro pietre miliari (milestones): 1. riesame dei requisiti utente; 2. revisione del disegno preliminare; 3. verifica del disegno di dettaglio; 4. consegna. Durante la prima fase necessario identificare gli oggetti del dominio del problema e le relazioni che intercorrono tra di essi. Tale primissimo processo dovrebbe concludersi con la realizzazione di diagrammi delle classi di alto livello. Laddove i tempi e la complessit del sistema lo permettano, un forte valore aggiunto potrebbe venire dalla realizzazione di un rapidissimo prototipo. La riesamina dello stesso alla presenza del cliente fornisce di solito unottima piattaforma di argomentazione. Ulteriore vantaggio che si riesce a placare temporaneamente il cliente facendolo trastullare con il nuovo giocattolo A dire il vero i prototipi possono risultare anche rischiosissimi: pu capitare che, da qualche capo progetto avventuriero, esso venga fatto passare come prodotto ultimato, per la gioia di tutto il team di sviluppo; credete che sia solo un rischio e che non sia gi capitato? Oppure il che sostanzialmente si riconduce al caso precedente pu succedere che il cliente sviluppi lidea che il passaggio dalla fase prototipale a quella definitiva avvenga con accelerazione infinita, ossia tempo zero.

UML dalla teoria alla pratica

39

Pu accadere che alcune menti semplici pensino che per edificare la propria casetta ci vogliano pochi giorni o settimane, dal momento che, per immaginarsela impiegano pochi minuti. Poi discutono con architetti e muratori e tornano rapidamente sulla terra: si rassegnano ad aspettare il tempo necessario. Nel software, tanto per cambiare, le cose funzionano in modo leggermente diverso: le menti semplici immaginano, per esempio, complicati sistemi di e-commerce e credono di averli gi tra le mani, poi discutono con chi il software lo deve realizzare e, strano ma vero, restano comunque della propria opinione. A questo proposito si ritiene opportuno tributare una meritatissima lode a uno dei padri dellObject Oriented: leccelso Bjarne Stroustrup. Nel suo libro C++, capitolo Progetto e sviluppo, nel contesto Sperimentazione e analisi egli esprime un concetto molto interessante: afferma che allinizio di un progetto importante semplicemente impossibile ipotizzare con successo i dettagli della sua realizzazione; pertanto occorre sperimentare per acquisire quellesperienza che, riguardo alla problematica, ancora non si possiede. Il prototipo uno dei principali strumenti di sperimentazione sicuramente uno dei pi utili ma ha il terribile difetto di somigliare troppo alla soluzione finale. Le menti semplici, gi messe a dura prova dalla discrepanza tempi mentali / tempi fisici, non riescono a distinguere il dito dalla luna: ma se un cliente pu essere opportunamente edotto riguardo la reale natura di ci che vede, nulla si pu fare quando lassurdit si annida nella testa dei cosiddetti coordinatori, manager o capi progetto. In tal caso, lunico consiglio da dare ai malcapitati sviluppatori coinvolti quello di abbandonare la nave al pi presto, prima che linfausta marea li travolga. Al riguardo, possibile citare Fowler: Se non puoi cambiare la tua azienda, cambia azienda. Sempre durante la prima fase essenziale identificare i casi duso utilizzando i relativi diagrammi o appositi schemi e organizzarli in gruppi. Risultato di ci la produzione di primi diagrammi dei componenti. Per terminare la prima fase e quindi raggiungere il milestone della riesamina dei requisiti del cliente, necessario allocare i requisiti funzionali agli oggetti del dominio del problema e ai relativi casi duso. La prima attivit del secondo milestone prevede la redazione della descrizione di dettaglio dei casi duso emersi nella fase precedente. In particolare, per ogni caso duso, necessario descrivere lo scenario relativo al caso ideale, quello in cui tutto funziona bene (mainstream) e non si verifica alcuna anomalia, e quelli relativi ai casi meno frequenti e alla gestione delle situazioni di errore che possono verificarsi. Durante questa fase si procede verso linterno del sistema. A questo punto necessario eseguire la famosa analisi di robustezza. Per ogni caso duso necessario individuare tutti gli oggetti che permettono di realizzare i vari scenari e aggiornare il diagramma delle classi del dominio del problema con quelle nuove, gli attributi e i metodi, a mano a mano che vengono individuati. Durante questa fase si procede dallinterno del sistema verso il suo esterno utilizzando un approccio Top Down: si aumenta il livello di dettaglio per mezzo di iterazioni successive. La seconda pietra miliare

40

Capitolo 1. UML: che cosa

, che cosa non

viene raggiunta con laggiornamento del diagramma delle classi al fine di adeguarlo ai concetti emersi nelle attivit della seconda fase. La terza fase prevede lallocazione del comportamento. Per ogni caso duso si identificano i messaggi scambiati dai vari oggetti e i metodi da invocare. A tal fine risulta conveniente utilizzare i diagrammi di interazione Sequence o Collaboration. Si tratta di diagrammi equivalenti; quello che cambia laspetto al quale si conferisce maggior risalto: literazione temporale nel primo, la collaborazione tra oggetti nel secondo. Nel tracciare i diagrammi, necessario continuare ad aggiornare il class diagram a mano a mano che vengono introdotti nuovi concetti. Terminata anche questa fase occorre completare il modello statico aggiungendo le informazioni dettagliate di disegno, eventualmente ricorrendo ai design patterns. Per raggiungere anche questa milestone bisogna procedere con la verifica del disegno: indispensabile accertarsi che soddisfi i requisiti precedentemente identificati. Giunti qui, non resta che concentrarsi sullultima fase: il delivery. In primo luogo necessario produrre i diagrammi di implementazione: componenti e dispiegamento. Quindi si passa alla codifica che dovrebbe risultare abbastanza automatica. Si eseguono i test di unit e di integrazione. Si esegue il famoso test di accettazione: utilizzando i casi duso e agendo sul sistema con una strategia a scatola nera, si verifica che il sistema faccia effettivamente quello per cui stato finanziato. Terminata tale fase il progetto concluso e quindi si passa alla relativa manutenzione che, nel caso in cui il sistema si riveli di successo, occuper circa il 50% dellintero ciclo di vita.

XP (eXtreme Programming): tutto e il contrario di tutto


Viene qui presentato un particolare processo di sviluppo del software, di recente formulazione e in continua evoluzione, incentrato sulla fase di codifica: il teatro dellassurdo. Si tratta di camminare sulla lama del rasoio. La comunit informatica e lo stesso team che ha collaborato alla realizzazione del presente libro percorsa da vivaci dibattiti tra sostenitori dellXP e coloro che invece lo considerano come un vero e proprio anti-processo. Onde evitare di essere tacciato di ignavia, lautore dichiara onestamente di aver sempre osservato lXP con non poche riserve mentali, riserve poi attenuate dallaumento di formalit apportato grazie alle collaborazioni di personaggi del calibro di Martin Fowler e Erich Gamma (uno della combriccola dei quattro). Prima di fornire qualche dettaglio sulleXtreme Programming (XP), si consiglia a tutti i lettori che stessero casomai leggendo in piedi questo libro di sedersi comodamente e di rilassarsi: in questo paragrafo vengono azzerati diversi sforzi prodotti finora nel tentativo di conferire il giusto rilievo alla fasi di analisi e disegno. Il problema principale che di questo metodo si tende a fare abuso con estrema facilit. Esso finisce involontariamente per fornire giustificazioni a tutta una serie di gruppi modello-repellenti. Spesso, collaborando con varie aziende e implorando i diversi team di

UML dalla teoria alla pratica

41

poter prendere visione dei modelli prodotti, ci si sente rispondere che non sono stati realizzati in quanto il sistema stato sviluppato con un approccio di tipo XP e che, eventualmente, alcuni diagrammi delle classi verranno prodotti per mezzo di reverse engineering Come se questi fossero gli unici manufatti necessari. Team furbetti di questo tipo trascurano qualche particolare: a differenza dei processi model free (presenti in molte aziende), lXP attribuisce elevata importanza agli unit test (test di unit): prima di scrivere il codice effettivo assolutamente necessaria la scrittura dei relativi casi di test (quindi, se si utilizzasse veramente un approccio di tipo XP, come minimo dovrebbe essere disponibile una serie di package di test). La realizzazione di test di unit equivale a dire che il comportamento viene analizzato e modellato a priori per sempre attraverso codice: il che non assolutamente vietato, ma forse non privo di tutta una serie di svantaggi. Per esempio si ritiene complicato sottoporre il modello ad altre persone, magari non esperte del particolare linguaggio, al fine di ricevere qualche considerazione; risulta pi complicato considerare i modelli stessi come risorse preziose per il futuro: si pensi a Use Case o modelli di analisi e disegno presenti in organizzazioni bancarie che rappresentano veri e propri investimenti indipendenti dal linguaggio utilizzato per limplementazione, di un valore elevatissimo per futuri sviluppi e reingegnerizzazioni. Chiaramente non si pu accusare uno strumento di cattivo funzionamento se lo si utilizza per fini non contemplati; come dire che non si pu attribuire allAspirina alcuna colpa se la si utilizza per curare gastriti: del resto, non si tratta della cura per tutte le malattie; sicuramente efficace per tutta una serie di patologie ma in altri casi non solo non produce alcun effetto, ma rischia anzi di aggravare la situazione. Con ci si intende dire che ogni prodotto, e quindi anche i processi, deve essere utilizzato per i fini per il quale stato ideato: lXP pu dare buoni risultati in contesti ben definiti: progetti di dimensioni medio-piccole, team di buona qualit, persone in grado di capire i limiti e le virt del processo stesso, e cos via. Si provi invece a pensare di utilizzare lXP per sviluppare un complesso sistema bancario Lidea di fondo che legittima lintero processo linsufficienza cronica di tempo tipica dei progetti: invece di non seguire assolutamente un processo, il che rischierebbe di produrre risultati assolutamente non desiderabili, probabilmente pi opportuno seguirne uno intuitivo, leggero, pragmatico e quindi molto operativo. Ci pu risultare particolarmente utile lavorando a progetti con cicli di consegna molto compressi e con fattori di rischio tecnologico molto elevati: indagini e sperimentazioni condotte codificando possono rivelarsi ottimi espedienti. Lautore ritiene preferibile, anche in casi estremi, applicare versioni light di processi come lo RUP; ma va riconosciuto che lXP pu risultare un ottimo strumento a supporto di persone intelligenti, preparate e frustrate dai soliti manager sempre convinti di saper far girare correttamente gli ingranaggi del sistema di produzione del software, magari perch riescono a consegnare qualcosa .exe ai vari clienti.

42

Capitolo 1. UML: che cosa

, che cosa non

Uno dei punti deboli dellXP che il team deve prevedere persone di talento, cooperative, dotate di buon affiatamento, coordinate da un Team Leader dotato di esperienza e capacit personali non del tutto comuni. Per le persone meno brave del team si prospettano due alternative: elevare rapidamente la propria esperienza o uscirne fuori a gambe levate. Un altro punto da menzionare che lXP non porta a produrre tutta una serie di modelli estremamente importanti per lorganizzazione in cui il sistema funzioner. Infatti, sebbene lobiettivo del ciclo di vita del software sia produrre un sistema eseguibile, i processi del tipo RUP permettono di realizzare, oltre al sistema stesso, tutta una serie di manufatti di estremo interesse, come per esempio il modello del business. Esso pu essere utilizzato per aggiornare il sistema, per future reingegnerizzazioni, per insegnare a nuovi dipendenti larea di business, ecc. Per capirne limportanza, basti pensare che mentre la tecnologia tende a rinnovarsi molto rapidamente, non altrettanto vale per il business, e quindi un buon modello pu risultare valido per decine di anni. Nel processo XP, per cos dire code centric, tutte le fasi del ciclo di vita del software vengono compresse a favore dellattivit di codifica: levoluzione delle API del sistema si acquisisce leggendo direttamente il codice, il comportamento di oggetti complessi viene definito per mezzo della codifica di appositi casi di test, gli inconvenienti vengono mostrati attraverso i problemi emersi dallesecuzione dei casi di test, e cos via. In tale ottica tutto il processo di sviluppo si risolve in una continua reingegnerizzazione del software e quindi ecco che le tecniche di refactoring illustrate da Fowler (Refactoring pubblicato dalla solita Addison Wesley) risultano un validissimo strumento di lavoro. Questo approccio pu risultare particolarmente utile nel realizzare opportuni FrameWork: la collezione di classi via via prodotte viene immediatamente verificata ed eventuali lacune vengono alla luce rapidamente. Il processo non rifiuta completamente la fase di disegno, ma ne prevede lutilizzo in casi estremi, quando non sia possibile codificare: in tutti gli altri casi lattivit di implementazione ha la precedenza. Da quanto emerso risulta chiaro che un processo code centric applicabile quando si dispone di team di dimensioni medio-piccole formati da personale particolarmente esperto e il progetto da affrontare anchesso di dimensioni piuttosto contenute. Si tratta comunque di processi in grado di rendere felici taluni manager i quali ogni settimana, o poco pi, si vedono consegnare nuove masse di codice. XP viene presentato come un processo leggero, efficiente, a basso rischio, flessibile, scientifico con un approccio divertente allo sviluppo del software. Questultima qualit sicuramente la pi allettante: a tutti i tecnici piace divertirsi con nuovi giocattoli. Certamente un metodo coraggioso e per questo merita di essere considerato con il dovuto rispetto che fa e far discutere. Lautore nutre diversi dubbi sulla relativa efficacia nello sviluppo parallelo. Anche trovandosi nel caso pi ideale possibile (requisiti utente ben chiari, team di elevata qualit tecnica, ecc.) il dubbio che lo sviluppo parallelo del software possa risultare piuttosto

UML dalla teoria alla pratica

43

macchinoso in quanto, evidentemente, nessun elemento del team pu sapere in anticipo cosa produrranno gli altri: non c il modello di disegno. Ci, in ultima analisi, dovrebbe rendere difficile lintegrazione dei vari sottositemi prodotti da elementi diversi del team. Chiaramente il processo richiede personale intelligente in grado di capire che le aree di collegamento tra i vari sottosistemi andrebbero realizzate per prime e non prevede che il personale debba chiudersi in una stanza fino a sviluppo terminato; per la macchinosit del processo potrebbe risultare notevole. Ulteriore considerazione che si tratta di un processo di produzione un po cieco: non si tenta in alcun modo di prevedere e affrontare i problemi che si potrebbero incontrare. Come dire, si comincia a costruire la strada, prima di edificarne un tratto si producono i vari test, ogni elemento del personale ne costruisce un pezzo, magari qualche kilometro pi a est o pi ad ovest, magari comunicando frequentemente per informarsi vicendevolmente circa il punto geografico in cui ognuno sta lavorando, e cos via Per come si dovrebbe procedere se poi alla fine ci si dovesse accorgere di trovarsi di fronte a una montagna o a un altro elemento geografico che complicano il raccordo delle strade?

XM (eXtreme Modeling): un buon compromesso


Il processo Agile Modeling si deve allo studio di Scott W. Ambler e la seguente illustrazione deriva dal sito ufficiale del processo (www.extreme-modeling.com). LeXtreme Modeling un processo che tenta di riutilizzare quanto di positivo emerso grazie alleXtreme Programming, riportando finalmente lattenzione dalla fase di programmazione a quella di modellazione: un metodo decisamente pi vicino alla forma mentis che sta alla base del presente libro Sar per la presenza della magica parolina modeling nel nome? Sia chiaro che non qui non si ripudia assolutamente il mio amore per la programmazione che tante gioie ha dato e continua a darmi: chi scrive anzi convinto che spesso qualche sperimentazione programmativa (specie quando si gioca con nuovi giocattoli) prima di procedere con lattivit di modellazione possa far risparmiare molto tempo. Ci di cui invece si dubita dellapproccio diametralmente opposto: ricorrere alla modellazione solo nei casi in cui non sia possibile codificare come lXP suggerisce. Recentemente il nome di eXtreme Modeling stato variato in Agile Modeling in quanto ritenuto pi rispondente ai propositi del processo: definire come mettere in pratica una collezione di valori, princpi e pratiche per la modellazione del software applicabile in progetti per lo sviluppo di sistemi software in modo efficace e leggero. Il segreto non sono le tecniche di modellazione in s stesse quanto piuttosto il modo in cui metterle in pratica; determinare come il processo possa essere utilizzato agevolmente ed efficacemente in progetti di sviluppo di sistemi software utilizzando anche criteri provenienti dallXP;

44

Capitolo 1. UML: che cosa

, che cosa non

determinare come il processo possa essere applicato seguendo le direttive e i modelli previsti dello Unified Process. I valori alla base delAM sono: comunicazione, semplicit, riscontri, coraggio e umilt. Chiaramente una delle precondizioni irrinunciabili per un progetto di successo la comunicazione efficace tra i vari personaggi coinvolti nello stesso: dai clienti ai Business Analyst ai programmatori ai tester e cos via; e qui ci sarebbe molto da attingere dallesperienza personale di chi scrive, specie dopo lespatrio. Una delle propriet che aiutano a conseguire questo risultato sicuramente la capacit di riuscire a individuare la soluzione pi semplice in grado di soddisfare completamente le proprie necessit. Molto importante ricevere continui riscontri durante il proprio lavoro i quali, a seconda delle fasi possono venire dai clienti, dai Business Analyst, dagli Architect ecc. necessario poi avere il coraggio di prendere delle decisioni e cercare di mantenerle fino in fondo: questa frase dovrebbe essere stampata a lettere cubitali e affissa nella stanza di taluni manager che allinizio si dicono disposti ad adattarsi ai tempi necessari per produrre modelli di qualit salvo poi cambiare improvvisamente idea non vedendo scrivere codice. Ovviamente, nel caso in cui una decisione risulti errata, bisognerebbe avere altrettanto coraggio di cambiare rotta prima che sia troppo tardi. Infine necessario avere lumilt di riconoscere che non si pu sapere tutto e che anche altri elementi del proprio team possono apportare del valore aggiuntivo allintero progetto: e ci si rende conto che questo il pi difficile dei valori a cui credere. Tra i princpi da applicare, quello in cui pi credo afferma che un modello pu avere pi valore di 1024 linee di codice; e personalmente lautore avrebbe inserito un ordine di grandezza superiore Realizzare un paio di modelli magari anche su un foglio di carta o alla lavagna pu aiutare a pensare e a investigare in merito a determinate soluzioni prima di realizzarle e magari a rendersi conto che non erano le migliori o addirittura che non erano praticabili. Lo sviluppo guidato da uno scopo ben preciso e gi verificato il modo migliore per evitare di sprecare tempo ed energie. Ovviamente non si tratta solo di applicare il modello pi adatto ma anche di realizzarne diverse viste al fine di catturare i vari aspetti di sistemi complessi. Ogni qualvolta sia necessario sviluppare un sistema in team o interagire con sistemi esterni al proprio pu risultare molto conveniente realizzare un modello che funga da contratto specie se il sistema esterno gestisce delle risorse necessarie al progetto. Sembrerebbe scontato, ma opportuno asserire che per modellare necessario conoscere sia i modelli che gli strumenti. In genere non esiste quello ideale, tutto dipende dagli obiettivi. Talune volte sono sufficienti un pennarello e una lavagna o una matita e un foglio di carta, altre volte preferibile avere un dispositivo che proietti quanto oggetto dello studio su uno schermo o in realtime in un sito remoto del mondo. Alcune volte sono sufficienti pochi minuti per realizzare un modello sufficiente; altre volte ci vogliono settimane. Importante cercare di riutilizzare manufatti esistenti, patterns ecc.

UML dalla teoria alla pratica

45

In primo luogo bene chiarire gli obiettivi fondamentali dellattivit di modellazione: aumentare la propria conoscenza del sistema esplorando soluzioni; comunicare. Disegnare diagrammi aiuta a formalizzare e a discutere eventuali problemi, magari con persone dislocate allaltro capo del mondo. Si capisce come risulti assolutamente necessario cercare di realizzare modelli pi semplici possibile, magari concentrandosi su singole parti del sistema. Molto spesso importante realizzare modelli collettivamente con il proprio team al fine di rendere tutti consapevoli delle problematiche e delle collaborazioni necessarie tra le varie componenti del sistema. Fortemente consigliato utilizzare pattern ogni qualvolta risulti possibile: si tratta di soluzioni eleganti, ben collaudate, facili da comunicare, e cos via. Altra pratica fortemente consigliata rendere disponibili a tutto il personale coinvolto nel progetto i modelli prodotti. Ci aiuta ad aumentare la comunicazione e a ricevere preziosi feedback. Ci ottenibile sia preparando un opportuno sito Intranet/Internet sia, eventualmente, utilizzando unapposita bacheca in cui affiggere le riproduzioni cartacee dei vari modelli prodotti. Sebbene la collezione di valori, princpi e pratiche proposte quelle riportate sono solo una parte derivi dal buon senso e dallesperienza di ogni sviluppatore di sistemi, la relativa catalogazione ed esposizione in un quadro organico sicuramente un lavoro di grande interesse che finisce per fornire la mancante formalit al processo delleXtreme Programming.

I restanti processi
Un altro processo degno di considerazione lOPEN Process. Il nome del processo gi di per s dovrebbe fornire diverse indicazioni circa i relativi obiettivi e gli artefici dello stesso. In effetti, si tratta di un processo ideato presso lOPEN Consortium (consorzio aperto), che raggruppa un insieme di persone e di organizzazioni animate dallobiettivo comune di accrescere e migliorare lutilizzo della tecnologia Object Oriented. Dati i presupposti, evidente che i destinatari principali dellOpen Process sono le organizzazioni interessate nello sviluppo di sistemi Object Oriented o Component Based. LOpen Process indipendente dai particolari linguaggi di modellazione, e pertanto qualsiasi linguaggio in grado di rappresentare modelli Object Oriented idoneo, quantunque alla fine gli unici utilizzabili siano lo UML e lOML (Object Modelling Language). LOML un linguaggio di modellazione ideato anchesso dallOPEN Consortium, che a lungo si opposto allo UML nella corsa alla conquista della standardizzazione. Chiaramente si trattava di una competizione dallesito scontato in quanto opponeva un linguag-

46

Capitolo 1. UML: che cosa

, che cosa non

gio (lo UML) fortemente sostenuto dagli investimenti di unazienda che su di esso ha basato il proprio successo, allaltro (lo OML) affidato alla buona volont delle persone che hanno collaborato al progetto. Il ciclo di vita del sistema software denominato contract driven, in quanto ciascuna attivit vincolata a contratti dichiarati che quindi, finiscono per rendere il processo guidato dalle responsabilit (responsability-driven). Uno dei pregi del progetto la relativa capacit di adattarsi ad organizzazioni che, generalmente, sviluppano pi progetti contemporaneamente: esempio tipico sono le software house. Il processo, in prima analisi, pu essere scisso in due grosse categorie di attivit: quelle da svolgersi per il singolo progetto e quelle trasversali, ossia comuni a tutti i progetti. Le attivit appartenenti alla seconda categoria supportano la gestione del programma (Programme Management), dove per programma si intende un insieme di progetti e/o versioni. Come gli altri processi anche lOpen si presta a essere adattato alle esigenze delle varie organizzazioni e progetti. I punti di forza di questo processo sono: copre quasi tutti gli aspetti della produzione ingegneristica del software; uno standard aperto a cui partecipano liberamente le persone di esperienza e capacit elogiate; A dir il vero il secondo punto un vantaggio/svantaggio. un pro in quanto permette al processo di evolvere indipendentemente dalle strategie di mercato, e quindi per esempio gli permette di prevedere strumenti per problemi considerati di minore importanza (disegno della GUI per esempio); per al tempo stesso un punto a sfavore in quanto, non essendo sostenuto da unazienda investitrice, verosimilmente destinato a condividere la sorte dellOML. Un ultimo processo da menzionare Object-Oriented Software Process (OOSP, Processo di sviluppo software object oriented). Verosimilmente liniziale elaborazione attribuibile a James Coplien (A Generative Development-Process Pattern Language e Pattern Languages of Program Design) sebbene i recenti miglioramenti e successi siano stati congegnati da Scott Ambler (Process Patterns e More Process Patterns). Il processo OOSP basato sul concetto di pattern di processi: ossia soluzioni dimostratesi valide nella soluzione di problemi tipici presenti nello sviluppo di sistemi software. Ciascuno di essi costituito da una collezione di tecniche, azioni e attivit che permettono di risolvere problemi specifici del processo software prendendo in giusta considerazione fattori ed eventuali vincoli presenti. Tali processi operano su tre diversi livelli di astrazione: fase (phase), stadio (stage) e attivit (task). LOOPS basato, essenzialmente, su quattro fasi:

UML dalla teoria alla pratica

47

1. iniziale (initiate) composta dagli stadi: giustificazione (justify), definizione e validazione dei requisiti iniziali (define and validate initial requirements), definizione iniziale dei documenti di gestione (define initial management documents) e definizione infrastruttura (define infrastructure); 2. costruzione (construct) formata dagli stadi: modellazione (model), verifiche in piccolo (test in the small), generalizzazione (generalize) e programmazione (program); 3. consegna (deliver) costituita dagli stadi: verifiche in larga scala (test in large), rielaborazione (rework), rilascio (release) e assestamento (assest); 4. mantenimento e supporto (maintain and support) che come sancito dal nome modellata dagli stadi di supporto e identificazione dei difetti e migliorie (indetify defects and enhancements). Anche lOOSP un processo iterativo, in cui le iterazioni avvengono nel contesto delle fasi, che vengono eseguite in serie. Come lopen process, lOOSP prevede una serie di attivit da svolgersi attraverso i progetti, ossia a livello di programma. Queste attivit prevedono controllo qualit, gestione del progetto, formazione del personale, gestione dei rischi, gestione del personale, ecc. Chiaramente molte attivit richiedono di essere svolte sia nellambito del singolo progetto sia in quello, pi generale, di tutti i progetti attivi presso lorganizzazione. Per esempio importante effettuare la valutazione (e gestione) dei fattori di rischio dei progetti sia nel dominio dei singoli, sia nella loro totalit: un insieme di progetti relativamente rischiosi potrebbe generare un rischio molto elevato a livello di organizzazione. I vantaggi del processo sono: 1. operare a livello di singolo progetto e a quello di portafoglio di progetti; 2. considerare tutti i processi necessari per lo sviluppo, la consegna e il mantenimento in esercizio dei sistemi prodotti; 3. includere tecniche dimostratesi valide nella realizzazione dei processi e nella segnalazione di condizioni che potrebbero generare effetti indesiderati.

I tool
Tool UML
Lintento predominante che ha guidato tutto il lungo processo di stesura del presente libro stato quello di tentare di suscitare, nel maggior numero possibile di lettori non

48

Capitolo 1. UML: che cosa

, che cosa non

ancora espertissimi dello UML, un qualche interesse nel disegnare modelli di sistemi Object Oriented. Sia chiaro che limportante progettare un sistema, usando poi un qualsivoglia formalismo, ma visto e considerato che esiste uno standard universalmente accettato, elegante, ben provato, perch non utilizzarlo? A questo punto il passo successivo consiste nel reperire un tool commerciale da utilizzarsi come ausilio nella modellazione di sistemi software Fino a qualche tempo fa non cerano molte alternative: nelle varie aziende di informatica era possibile trovare quasi esclusivamente Rational Rose o TogetherJ.

TogetherJ
TogetherJ, sebbene sia un ottimo prodotto pu correre il rischio di generare delle perplessit. Il motivo risiede proprio e paradossalmente in quella che dovrebbe esserne una peculiarit: la fusione del processo di disegno con quello di implementazione. Ci, considerando il programmatore che si nasconde dentro ogni buon disegnatore, finisce per essere una tentazione troppo forte, quasi irresistibile, ad abbandonare prematuramente la fase di disegno per tuffarsi in quella di codifica. Chiaramente si tratta di uno strumento e quindi, se lutilizzatore lo utilizza in modo errato la classica zappa sul piede non si pu attribuire la colpa allapplicativo; ma anche vero che se lo stesso non fa altro che esibire la magnifica mela tentatrice chiaro che prima o poi venga la voglia di morderla In ogni modo si tratta di un tool di comprovato successo, particolarmente apprezzato per la relativa cura conferita allaspetto grafico e ai dettagli. Anche la funzione di reverse engineering (o meglio di sincronizzazione in tempo reale tra disegno e codifica) risulta ben congegnata. Probabilmente si tratta di un ottimo strumento per lo sviluppo di sistemi component-based. Qualora si disponga di un buon team di sviluppatori e si sia realizzato almeno il disegno delle interfacce relative ai vari componenti si potrebbe assegnarne limplementazione di ciascuno di essi a uno sviluppatore, provvedendo un minimo di disegno e affidandosi alla relativa buona volont ed esperienza. In un contesto di questo tipo, TogetherJ rappresenterebbe effettivamente uno strumento imbattibile. Il passaggio dal modello di disegno alla relativa traduzione in codice non stato mai o quasi mai, dipende dai programmatori a disposizione un problema del processo di sviluppo del software; anzi il tutto quasi immediato specie con linguaggi di programmazione come Java. La vera fase critica invece passare dalla vista dei casi duso a quella di disegno. Un altro piccolo problema che il tool molto Java oriented e ci lo porta, talune volte, lontano dalle specifiche formali dello UML. Attualmente la TogetherSoft distribuisce unottima evoluzione del prodotto denominata Together Controlo Center.

Rational Rose
Un discorso a parte va fatto per il software della Rational: , o comunque stato, il punto di riferimento degli altri, realizzati a sua immagine e somiglianza. Si tratta indub-

UML dalla teoria alla pratica

49

biamente di un altro livello, anche dal punto di vista economico (tipicamente, costa unordine di grandezza in pi rispetto agli altri): la relativa esosit, non sempre giustificata, forse ne costituisce la seccatura principale. Probabilmente per sistemi di una certa dimensione esistono poche alternative. La cosa meno comprensibile che, nonostante Rational Rose sia fornito dallazienda che ha prodotto le prime versioni dello UML, non sembra aderire sempre alle relative specifiche. Attualmente disponibile levoluzione denominata XDE (eXtended Development Environment, ambiente di sviluppo esteso), nella quale si cercato di muoversi vero le fasi pi di dettaglio del processo di sviluppo del software.

MagicDraw
Un altro tool che recentemente ha iniziato a prendere piede nelle varie organizzazioni MagicDrawUML. Si tratta probabilmente del software che al momento in cui viene redatto il presente libro (2002) aderisce maggiormente alle specifiche standard dello UML. La quasi totalit degli esempi forniti i questo libro sono stati realizzati con la versione 3.6, proprio per fornire esempi pi standard possibile. molto accurato, ben congegnato e non trascura alcun diagramma o meccanismo dello UML. Lunico problema che, verosimilmente, tanta e tale la frenesia di aderire alle nuove specifiche dello UML e di rilasciare nuove versioni sempre pi vicine alle direttive, che esse non sempre sono esenti da un certo numero di bugs. Ciononostante la versione 4 sembrerebbe finalmente aver raggiunto un buon livello di maturit.

Argo UML
Un altro tool che merita particolare menzione Argo UML (www.ArgoUML.org), frutto di un progetto realizzato presso lUniversit della California (Computer Science University of California, Irvine). Si tratta veramente di un tool accattivante e ben studiato, soprattutto dal punto di vista dellinterfaccia utente. Propone soluzioni decisamente innovative, accattivanti, completamente diverse rispetto allapproccio classico su cui sono basati gli altri software. Altro grosso vantaggio che si tratta di un sistema open source e quindi i sorgenti sono di pubblico dominio. Eventualmente possibile customizzarlo alle proprie esigenze modificandone direttamente il codice. Qualche pecca imputabile alla non sempre perfetta aderenza alla direttive standard dello UML e alla latenza nellincorporamento dei cambiamenti di specifiche dovuti alle varie versioni dello UML: si tratta pur sempre di un prodotto gratuito! Questo ne costituisce il punto di forza e la debolezza al tempo stesso: trattandosi di un prodotto open source, non esiste unazienda che ne faccia un prodotto di punta e quindi: non viene effettuata alcuna operazione di marketing, non vi sono dipendenti (stipendiati) per curare il supporto della clientela, lo sviluppo di nuove funzionalit, il miglioramento ecc. Ci, daltro canto, offre altri vantaggi relativi soprattutto al fatto che il prodotto non vincolato alle leggi di mercato. Per esempio vengono realizzate funzionalit relative ad aree che dal punto di vista del mercato risultano di minore importanza per via del numero di clienti che potrebbero esservi inte-

50

Capitolo 1. UML: che cosa

, che cosa non

ressati, il ciclo di vita del prodotto basato su criteri canonici della progettazione, possibile avvalersi della collaborazione di personale veramente esperto dislocato nelle pi svariate parti del mondo, ecc. A integrazione e modifica di quanto appena riportato, va considerato per che recentemente la software house Gentleware distribuisce una versione di ArgoUML, battezzata Poseidon. Ovviamente esistono altri tool di supporto allo UML e probabilmente qualcuno di questi veramente formidabile: purtroppo chi scrive ha lavorato a progetti reali solo con quelli appena citati; ma del resto la professione dellautore non lo UML tool tester

Tool per i processi


Mentre possibile reperire svariati tool di supporto dello Unified Modeling Language, lo stesso non si pu dire per i processi di sviluppo del software. Nel momento in cui viene redatto il presente libro, lautore ha avuto la possibilit di utilizzare sarebbe pi opportuno dire consultare un solo prodotto: il software di supporto al processo RUP (Rational Unified Process, Processo Unificato della Rational) fornito, tanto per cambiare, dalla Rational. Per fare chiarezza il RUP un processo formale scaturito dalla revisione del processo elaborato dai Tres Amigos e da quello denominato Objectory. In questo paragrafo, quando si parla di RUP si fa riferimento al pacchetto software che lo accompagna. Non si tratta di un applicativo vero e proprio bens di una base di informazioni messe a disposizione dellutente: una sorta di sito web dello Unified Software Development Process, corredato da tutta una serie di consigli, linee guida, best practices, e cos via. Non a caso il pacchetto corredato da una copia del celebre libro dei Tres Amigos (The Unified Software Development Process). Per il software di supporto al processo di sviluppo che tutti sognano, probabilmente bisogna attendere ancora un po Aspirazione di RUP fornire una valida guida allo sviluppo di sistemi Object Oriented in tutte le relative fasi del ciclo di vita del software. A detta della casa produttrice, il Rational Unified Process un software di supporto al processo di sviluppo, fornito di un sistema di conoscenza fruibile con tecnologia web based (si tratta di un vero e proprio sito web), in grado di incrementare il livello di produttivit dei team e quindi ridurre i tempi necessari per la consegna del software grazie alle linee guida fornite: dalle best practices, ai templates, a un tool in grado di fornire suggerimenti in tutte le attivit del ciclo di vita del software e cos via. Il RUP basato essenzialmente sui tre concetti: workers (lavoratori), artifacts (manufatti) e activities (attivit) illustrate da appositi workflow. Un worker definisce il comportamento e le responsabilit di un individuo o di un team in termini del ruolo ricoperto e quindi le relative attivit possono essere svolte da un

UML dalla teoria alla pratica

51

singolo individuo o da un team. I lavoratori vengono suddivisi in categorie quali: analisti, sviluppatori, tester, manager, ecc. che a loro volta vengono suddivisi in ruoli. Tipicamente la categoria degli sviluppatori include architetti, disegnatori, programmatori e integratori di sistemi. Ai vari lavoratori vengono affidate diverse attivit: unit di lavoro che i lavoratori devono espletare nel contesto del progetto. La granularit delle attivit pu spaziare dallordine delle ore a quello dei giorni: uneccessiva minuziosit richiede una lunga e laboriosa programmazione che spesso pu risolversi in un inutile spreco di energie, mentre una programmazione superficiale pu condurre a una errata stima dei tempi. Come al solito si tratta di individuare il giusto mezzo. Ciascuna attivit decomposta in tre fasi: thinking (elaborazione mentale), performing (esecuzione) e reviewing (revisione) i cui obiettivi sono ben comprensibili dai nomi stessi. Il sistema fornisce tutta una serie di linee guida, consigli e tecniche pratiche al fine di aiutare i lavoratori a conseguire le relative attivit. Le azioni da svolgere per implementare le varie attivit vengono descritte in termini dei prodotti di input e di quelli da produrre in output. Per esempio, le linee guida fornite dal sistema (RUP) a un programmatore che deve assolvere lattivit di implementazione di un componente, consistono nelleseguire le seguenti attivit: codificare le operazioni; implementare gli stati; utilizzare la delegazione al fine di riutilizzare il codice; realizzare le associazioni; codificare gli attributi; fornire un opportuno feedback al disegno del modello; valutare il codice. Al fine di espletare le attivit assegnategli, ciascun lavoratore necessita di informazioni. Per esempio, per produrre un componente, uno sviluppatore necessita di un disegno con le specifiche. La realizzazione di unattivit produce un qualche tipo di risultato, come le classi prodotte dallo sviluppatore. Le informazioni di input e i risultati prodotti vengono comunemente definiti manufatti. Alcuni esempi di manufatti sono: il modello dei casi duso, il modello di analisi, il modello di disegno, il modello di implementazione, il piano dei test, il glossario, il documento di analisi dei rischi, il documento architetturale e cos via.

52

Capitolo 1. UML: che cosa

, che cosa non

Storicamente il ciclo di vita del software organizzato a cascata: il progetto passa attraverso una successione di fasi (workflow) a partire dallanalisi del dominio del problema procedendo via via per le fasi di analisi, disegno, implementazione, test e consegna. Nella pratica, i workflow si sono dimostrati non ottimali in quanto eventuali lacune o problemi presenti in una fase emergono tipicamente solo alla fine, durante i test. La sistemazione di tali anomalie pu richiedere costosissime e non sempre risolutive iterazioni del workflow stesso, magari perch per colmare una lacuna bisognerebbe scardinare le fondamenta del modello di disegno. I processi pi recenti, come illustrato precedentemente, prevedono un approccio iterativo e incrementale: ogni iterazione perfeziona ed espande il sistema che via via assume una forma sempre pi completa. In sostanza ogni iterazione prevede lo svolgimento dellintero workflow. Le prime iterazioni sono decisamente incentrate sullanalisi del dominio del problema e sulla cattura dei requisiti utente, mentre le ultime risultano molto implementative. Man mano che il progetto matura si assiste a una graduale diminuzione delle attivit di analisi e progetto a favore dellespansione delle attivit di sviluppo e test. Dal punto di vista della gestione, il progetto pu essere suddiviso nelle quattro fasi esaminate nel paragrafo dello Unified Software Developmente Process: inception, elaboration, construction e trasition. Ogni workflow costituito dalle seguenti parti: introduzione: illustra gli obiettivi del workflow stesso e le relative relazioni con gli altri; spiegazione dei concetti necessari per comprendere il workflow; descrizione di dettaglio del workflow; overview delle attivit: viene fornita la lista delle attivit da svolgere corredata dai lavoratori coinvolti; overview dei manufatti: elenco dei manufatti da produrre corredato dallattribuzione delle responsabilit; overview delle linee guida: spiegazioni e consigli su come produrre ed utilizzare i manufatti coinvolti nel processo in corso. Pertanto ogni iterazione del workflow descrive lavoratori, manufatti e attivit coinvolte nelliterazione del ciclo di vita del software. Il sistema prevede diverse sezioni, tra le quali le classiche best practices, white papers chiss come mai il nome di questa sezione

UML dalla teoria alla pratica

53

finisce per rievocare inesorabilmente memorie delle straordinarie interpretazioni di Tot , forms, tool mentor, La sezione dedicata ai modelli (forms) particolarmente utile in quanto, fornendo templates in molteplici formati per tutta una serie di attivit, permette di risparmiare molto tempo. La sezione denominata tool mentor fornisce una serie di consigli e istruzioni su come utilizzare al meglio il software Rational Rose durante tutta la fase di sviluppo del sistema. Ovviamente non sono presenti consigli su come realizzare i vari modelli o come organizzare viste, classi, ecc. ma unicamente quali funzioni utilizzare, dove muovere il mouse e quale pulsante premere. In conclusione si pu dire che questo sistema rappresenta una valida risorsa per tutti coloro che desiderano sviluppare seriamente sistemi software Object Oriented. In ultima analisi, si tratta di una fruizione ipertestuale della rivisitazione del libro dei Tres Amigos corredata di qualche riferimento al software Rose.

Ricapitolando
Il presente capitolo stato dedicato allillustrazione di che cosa sia e che cosa non sia lo UML e di quali siano le relative aree di applicabilit. Lintento stato quello di chiarire il prima possibile quali siano gli obiettivi, le aree di interesse e i confini dello UML: nella comunit Object Oriented non sono infrequenti opinioni poco chiare che conferiscono allo UML funzionalit tipiche dei processi di sviluppo del software o che, in maniera diametralmente opposta, lo riducono a semplice linguaggio per la rappresentazione dellorganizzazione statica del software. Secondo le specifiche formali, lo UML un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, sia di processi produttivi e altri sistemi non strettamente software. LUML rappresenta una collezione di best practices di ingegneria dimostratesi vincenti nella modellazione di vasti e complessi sistemi. Il capitolo, considerati anche gli obiettivi, decisamente voluminoso e non sempre di facile fruizione. Il lato positivo che si pu tranquillamente proseguire nella lettura del testo anche se non lo si compreso completamente; in altre parole: non necessariamente propedeutico per la comprensione dei restanti capitoli. Frasi del genere proferite dai docenti allUniversit facevano guizzare nella mente degli studenti limplicazione quindi possibile saltare il capitolo!. In questo caso si consiglia comunque di leggerlo, magari molto rapidamente, e di ritornare a leggerlo in un secondo momento quando si avr maggiore padronanza dello UML: ci permetter di apprezzare maggiormente gli argomenti riportati. Il capitolo si apre con una digressione sul concetto di modello e sulle propriet a cui si interessati nel contesto della progettazione di sistemi software, ossia: accuratezza, consistenza, semplicit e manutenibilit. Si illustra il grande vantaggio di ricorrere ai modelli: essendo rappresentazioni puntuali ma semplificate di sistemi reali, permettono comun-

54

Capitolo 1. UML: che cosa

, che cosa non

que di studiarne le propriet di interesse ma, in quanto rappresentazioni, possono essere realizzati molto rapidamente e soprattutto a costi contenuti. Inoltre forniscono una base formale di argomentazione con i clienti. Sebbene i modelli offrano vantaggi indiscutibili, a tuttoggi, in molte organizzazioni informatiche semplicemente se ne dimentica limportanza per concentrarsi prematuramente sullimplementazione del sistema. Negli anni che hanno preceduto la presentazione dello UML, la comunit Object Oriented, limitatamente alla sfera dei linguaggi di progettazione, viveva un momento di smarrimento: agli inizi degli anni Novanta si contavano una cinquantina di diversi linguaggi che finivano per alimentare la cosiddetta guerra dei metodi. Ci creava problemi a tutti gli attori operanti nel mondo dellObject Oriented dai singoli tecnici, ai clienti, dalle aziende produttrici di prodotti CASE, alle varie consulting, e cos via e finiva per costituire un serio limite al fiorente sviluppo delle tecnologia stessa. Lo UML nato dallo straordinario lavoro di Grady Booch, James Rumbaugh e Ivar Jacobson, presto divenuti famosi nella comunit informatica internazionale con il nomignolo di Tres Amigos. Inizialmente, limpegno profuso stato indirizzato essenzialmente nel tentativo di realizzare un linguaggio di progettazione che unificasse, come suggerito dal nome stesso, quanto di buono era presente nei metodi esistenti o almeno in quelli di maggior successo. In particolare, lo UML scaturito, principalmente, dalla fusione dei concetti presenti nei metodi di Grady Booch, OMT (Object Modeling Techique di cui Rumbaugh era uno dei principali fautori) e OOSE (Object Oriented Software Engineering /Objectory di cui Ivar Jacobson era uno dei promotori). Lo UML uno dei pochi esempi di standard nati nel mondo dellindustria ( stato interamente finanziato dalla Rational Software Comporation) per poi approdare ai riconoscimenti accademici: nel 1997 stato ratificato come standard e posto sotto il controllo dellOMG (Object Management Group). Contrariamente a convinzioni comuni in molti tecnici, lo Unified Modeling Language, non unicamente una notazione standard per la descrizione di modelli Object Oriented di sistemi software; si tratta bens di un metamodello definito rigorosamente che a sua volta istanza di un meta-metamodello definito altrettanto formalmente. Nelle specifiche formali, la proiezione statica dello UML specificata dai diagrammi delle classi: una delle tipologie di diagrammi previste dal linguaggio stesso. In altre parole, lo UML definito per mezzo di s stesso, o meglio la relativa definizione formale utilizza il linguaggio stesso. In alcuni gruppi di lavoro vi una certa confusione sul rapporto che lega i linguaggi di progettazione ai processi di sviluppo del software: lo UML un linguaggio di progettazione e, come tale, solo parte di metodi pi generali per lo sviluppo del software. Lo UML un formalismo utilizzato dai processi per realizzare, organizzare, documentare, i prodotti generati dalle fasi di cui il processo si compone. Un metodo, tra i vari princpi, formato dalle direttive che indicano al progettista cosa fare, quando farlo, dove e perch: un linguaggio invece carente di ci. I processi di sviluppo pi celebri, tipicamente, sono fondati su un insieme ben definito di filosofie quali: Use Case Driven, Architecture Centric e Iterative and Incremental.

UML dalla teoria alla pratica

55

La prima, come suggerito dal nome, completamente imperniata sui casi duso, ossia sulle funzionalit del sistema cos come vengono percepite da entit esterne al sistema stesso. Focalizzare fin dalle primissime fasi del ciclo di vita del software e continuare a monitorare laderenza dei vari modelli alle richieste del cliente pu evitare tutti quei problemi derivanti da uninefficace dialogo tra il gruppo di tecnici e i clienti. Si tratta della strategia decisamente pi ricorrente e, pi o meno consciamente, utilizzata da sempre: i sistemi software in primo luogo dovrebbero essere realizzati per soddisfare specifiche esigenze dellutente. I processi Architecture Centric tentano di creare il sistema partendo dalla progettazione dellarchitettura del sistema, la quale viene posta al centro dellintero processo di sviluppo. Molto importante quindi stabilire il prima possibile unarchitettura ben definita e quindi un embrione di prototipo per poterla valutare. Chiaramente la versione finale del sistema e dellarchitettura stessa viene raggiunta attraverso una serie di iterazioni, ma le variazioni dovrebbero essere confinate a rifiniture e non rappresentare stravolgimenti della versione base. Da tenere presente che nella pratica non esistono processi unicamente basati sullarchitettura di un sistema: in genere sono ibridi che ospitano anche le direttive derivanti da dottrine Architecture Centric. Gli approcci Iterative and Incremental prevedono di produrre il sistema finale attraverso una serie di successive versioni generate alla fine di opportune iterazioni. Ci equivale a dire che il progetto si risolve in una successione di miniprogetti completi ognuno con opportune e prestabilite versioni del sistema. I vantaggi derivanti dallutilizzo di metodi di sviluppo iterativo e incrementali sono riduzione dei costi dovuti a errori o imprevisti generatisi durante una singola iterazione, riduzione del rischio di non produrre il sistema nei tempi previsti, riduzione del tempo necessario per rilasciare il sistema globale, maggiore flessibilit in caso di modifiche dei requisiti utente. I processi di sviluppo del software pi interessanti sono molto probabilmente: The Unified Software Development Process (processo unificato di sviluppo software) e ICONIX Use Case Driven. Tipicamente i processi non possono essere utilizzati nella loro forma originale: necessario eseguirne determinate personalizzazioni al fine di adattarli alla realt organizzativa, al team che si ha a disposizione, alla natura del progetto, e cos via. Il paragone pi immediato con gli abiti: una volta acquistati necessario effettuarvi dei ritocchi per adeguarli alla propria struttura, stile, ecc. Lo Unified Software Development Process progettato dai Tres Amigos presso la Rational in realt non semplicemente un processo bens un framework di un processo generico; si presta a essere utilizzato proficuamente per classi piuttosto estese di sistemi software, differenti aree di applicazioni, diverse tipologie di organizzazioni, svariati livelli di competenza e per progetti di varie dimensioni. Caratteristica peculiare offerta dal processo la razionale fusione dei tre principali metodi esistenti: Use Case Driven, Architecture Centric e Iterative and Incremental. Forse ci non solo lo rende unico ma, verosimilmente, anche raro da utilizzare nella sua versione originale: richiede un notevole investimento in termini di tempo.

56

Capitolo 1. UML: che cosa

, che cosa non

Il processo presentato dalla ICONIX anchesso basato sulla vista dei casi duso e utilizza un approccio iterativo e incrementale, per risulta essere decisamente pi flessibile, leggero e facile da applicare Magari un po meno formale di quello presentato dai Tres Amigos. Per terminare, vengono presentati i prodotti software utilizzabili come supporto al ciclo di vita del software, sia quelli di ausilio alla progettazione del sistema (supporto dello UML) sia prodotti di ausilio al processo di sviluppo. Nel primo gruppo si trovano software quali Rational Rose, MagicDrawUML, TogetherJ, Argo UML mentre come unico esemplare di software di supporto al processo di sviluppo va menzionato RUP (Rational Unified Process).

Capitolo

2
Lesperienza insegna che la capacit di comunicare il comportamento e il disegno di un sistema, prima della relativa implementazione, cruciale per la buona riuscita dello sviluppo. WALKER ROYCE

UML: struttura, organizzazione, utilizzo

Introduzione
Scopo del presente capitolo fornire una panoramica generale dello UML corredata da opportuni esempi. In particolare viene esposta lorganizzazione in viste e vengono presentati molto brevemente i diagrammi di cui ciascuna di essa composta. Particolare attenzione stata attribuita ai metodi forniti dal linguaggio UML per estenderne sintassi e semantica. Sebbene esuli decisamente dagli obiettivi del presente libro illustrare dettagliatamente i processi di sviluppo, durante la stesura del presente capitolo ci si resi conto che unillustrazione decontestualizzata da un processo di sviluppo avrebbe probabilmente finito per apportare un beneficio relativo al lettore. Pertanto, senza avere la pretesa di scrivere un libro sui processi di sviluppo, si ritenuto indispensabile prenderne in considerazione uno di riferimento al fine di illustrare pi concretamente lutilizzo dello UML per la modellazione dei relativi manufatti. Tutti coloro che gi conoscono lo UML verosimilmente potrebbero venir tentati di procedere direttamente alla lettura del capitolo successivo e potrebbe forse trattarsi di una buona idea. Nonostante ci, nel presente capitolo sono inserite alcune riflessioni relative ai processi di sviluppo, ai meccanismi di estensione e ai profili che potrebbe valer la pena leggere, magari sullautobus o in metropolitana Per tutti i meno esperti il consiglio di non ostinarsi e perder tempo nel tentar di capire da subito tutti i meccanismi presenti in ciascun diagramma: in questo capitolo hanno

Capitolo 2. UML: struttura, organizzazione, utilizzo

valenza unicamente introduttiva. Limportante cominciare a crearsi unidea delle potenzialit dello UML e prendere familiarit con i vari strumenti messi a disposizione e le relative aree di utilizzo: per ciascuno dei concetti introdotti presente una trattazione precisa ed esaustiva nel capitolo dedicato allargomento. Si colta loccasione per proporre un primo esempio di progetto completo: un sistema Internet/Intranet per lacquisto di biglietti del teatro.

La struttura
Lo UML presenta una tipica struttura a strati; procedendo dallesterno verso linterno, essa costituita da: 1. viste 2. diagrammi 3. elementi del modello Le viste mostrano i diversi aspetti di un sistema per mezzo di un insieme di diagrammi. Si tratta di astrazioni, ognuna delle quali analizza il sistema da modellare secondo unottica diversa e ben precisa (funzionale, non funzionale, organizzativa, ecc.), la cui totalit fornisce il quadro dinsieme. I diagrammi permettono di descrivere graficamente le viste logiche. Lo UML prevede ben nove tipi di diagrammi differenti, ognuno dei quali particolarmente appropriato a essere utilizzato in particolari viste. Per ci che concerne gli elementi del modello, essi sono i concetti che permettono di realizzare i vari diagrammi. Alcuni esempi di elementi sono: attori, classi, packages, oggetti, e cos via. Durante la fase di definizione dei vari elementi, per i Tres Amigos fu necessario affrontare il problema di stabilire quanti e quali elementi dovessero essere inglobati nel linguaggio e se era il caso di iniziare a catalogare tutti quelli immaginabili. Sebbene da un lato ci sarebbe stato utile perch ogni applicazione o tecnologia avrebbe avuto il proprio set di simboli, dallaltro il prezzo da pagare sarebbe stato troppo elevato: linguaggio rigido, eccessivamente complesso e comunque carente: si trova sempre un progettista Tizio che abbia la necessit di esprimere qualche concetto e non trova gli strumenti opportuni per farlo. Addirittura si possono incontrare presunti tecnici, guerrafondai non paghi della pace raggiunta dopo decenni di guerra dei metodi di analisi, che tentano ancora di riaccendere qualche focolaio inventando propri formalismi. Il buon senso, ovviamente port a preferire un altro approccio: si decise di definire e standardizzare un certo numero di elementi base invarianti (core, nucleo), ritenuti fonda-

UML e ingegneria del software: dalla teoria alla pratica

mentali, e di fornire un insieme di altri meccanismi atti a estendere la semantica del linguaggio (stereotypes) per aggiungere documentazione, note, vincoli, ecc. I vantaggi offerti da tale soluzione furono essenzialmente: mantenimento della semplicit e, contestualmente, conferimento del dinamismo e della flessibilit necessari per rendere lo UML in grado di adattarsi ai pi svariati settori. Come per spesso accade, attraverso riscontri ottenuti dallapplicazione dello UML in progetti reali, fu possibile realizzare che, probabilmente, la soluzione migliore era una via di mezzo: era necessario standardizzare collezioni predefinite di estensioni denominate profili. Quindi a partire dal nucleo base, utilizzando opportunamente i meccanismi di estensione dello UML, nel momento in cui viene scritto il libro si stanno definendo una serie di plug-in di elementi standardizzati (appunto i profili) dimostratisi particolarmente utili nellapplicazione dello UML in progetti che sfruttano le architetture ricorrenti (EJB, CORBA, ecc.). possibile pensare ai profili come alle librerie utilizzabili nella stesura del codice. Sebbene ognuno possa definirsi e riscrivere librerie proprie per risolvere particolari problemi, ne esistono tutta una serie predefinite (gratuite), ben testate e universalmente accettate Eventualmente nessuno vieta di estenderle, ma davvero conviene reinventare la ruota? Il rischio a cui si andava incontro per via della mancanza di tale standardizzazione era una ennesima proliferazione di linguaggi o meglio dialetti che avrebbero finito per ridurre molti dei vantaggi offerti dallo UML.

Le viste
In prima analisi, lo UML organizzato in viste, e in particolare costituito dalle viste Use Case, Design, Implementation, Component e Deployment come illustrato in fig. 2.1. In breve, la prima vista, Use Case View (vista dei casi duso), utilizzata per analizzare i requisiti utente: specifica le funzionalit del sistema come vengono percepite dalle entit esterne al sistema stesso dette Attori. Dunque, si tratta di una vista ad alto livello di astrazione, e di importanza fondamentale sia perch, nella maggioranza dei processi, guida lo sviluppo delle rimanenti, sia perch il manufatto principale utilizzato per ottenere riscontri dal cliente, sia perch stabilisce le funzionalit che il sistema dovr realizzare: quelle per le quali il cliente paga. Obiettivo di questo livello di analisi studiare il sistema considerandolo come una scatola nera: necessario concentrarsi sul cosa il sistema deve fare astraendosi il pi possibile dal come: necessario individuare tutti gli attori, i casi duso e le relative associazioni. La vista dei casi duso costituita da due proiezioni: quella statica catturata dai diagrammi dei casi duso e quella dinamica rappresentante le interazioni tra gli attori e il sistema.

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.1 Diagramma delle viste dello UML.


vocabolario funzionalit assemblaggio del sisterma gestione della configurazione

DESIGN VIEW
comportamento

IMPLEMENTATION VIEW USE CASE VIEW DEPLOYMENT VIEW


topologia del sistema distribuzione consegna installazione

COMPONENT VIEW
prestazioni scalabilit throughput

Importante dettagliare i requisiti del cliente, carpirne i desideri pi o meno inconsci, cercare di prevederne i possibili sviluppi futuri, ecc. La Design View (vista di disegno, talune volte indicata come Logical View, vista logica), specularmente alla precedente, descrive come le funzionalit del sistema debbano essere realizzate, in altre parole si analizza il sistema dallinterno (scatola trasparente). Anche questa vista composta sia dalla struttura statica (diagramma delle classi e diagramma degli oggetti), sia dalla collaborazione dinamica dovuta alle interazioni tra gli oggetti che lo costituiscono (diagrammi di comportamento del sistema). La Implementation View (vista implementativa, detta anche Component View, vista dei componenti) la descrizione di come il codice (classi per i linguaggi object oriented) debba essere accomunato in opportuni moduli (package) evidenziandone le reciproche dipendenze. La Process View (vista dei processi, detta anche Concurrency View, vista della concorrenza), rientra nellanalisi degli aspetti non funzionali del sistema e consiste nellindividuare i processi e i processori. Ci sia al fine di dar luogo a un utilizzo efficiente delle risorse, sia per poter stabilire lesecuzione parallela degli oggetti (almeno quelli pi importanti), sia per gestire correttamente eventuali eventi asincroni, e cos via. La Deployment View (vista di dispiegamento), mostra larchitettura fisica del sistema e fornisce lallocazione delle componenti software nella struttura stessa.

I diagrammi
Lo UML definisce diversi diagrammi (consultare fig. 2.2).

UML e ingegneria del software: dalla teoria alla pratica

Figura 2.2 Diagrammi dello UML.

Use Case (Casi D'uso)

Class Diagram (Diagrammi delle Classi)

Object Diagram (Diagrammi degli Oggetti)

Collaboration Diagram (Diagramma di Collaborazione)

Sequence Diagram (Diagramma di Sequenza)

Activity Diagram (Diagramma di Attivita')

Statechart Diagram (Diagramma degli Stati)

Component Diagram (Diagramma dei Componenti)

Deployment Diagram (Diagramma di Dispiegamento)

Diagrammi strutturali (logico): Use Case Diagram (diagramma dei casi duso, da non confondersi con la relativa vista) Class Diagram (diagramma delle classi) Object Diagram (diagramma degli oggetti) Diagrammi di comportamento: Statechart Diagram (diagramma degli stati)

Capitolo 2. UML: struttura, organizzazione, utilizzo

Activity Diagram (diagramma delle attivit) Diagrammi di interazione: Sequence Diagram (diagramma di sequenza) Collaboration Diagram (diagramma di collaborazione) Diagrammi di implementazione: Component Diagram (diagramma dei componenti) Deployment Diagram (diagramma di dispiegamento)

Qualche lacuna...
Una prima lacuna individuata dallautore utilizzando lo UML riguarda il disegno della base dati. Nel mondo dellideale non dovrebbero esserci troppi problemi: sia larchitettura software, sia il database dovrebbero essere Object Oriented, quindi mapping unoa uno o quasi. In queste circostanze il disegno della base dati deriva direttamente dal modello ad oggetti del dominio e quindi si presta a essere descritto attraverso i diagrammi delle classi. Nella realt per, i database relazionali sono ancora la stragrande maggioranza per tutta una serie di motivi: molto spesso si ha a che fare con sistemi legacy che nei casi migliori utilizzano database relazionali; non sempre i database OO sembrerebbero offrire performance paragonabili ai rispettivi database relazionali; esiste ancora una certa ignoranza e quindi timore nei confronti dei database Object Oriented, e cos via. Comunque sia, il risultato che i database relazionali sono molto ricorrenti nei progetti reali, e da qui nasce la lacuna dello UML di non prevedere apposito formalismo per la descrizione del disegno logico e fisico della base di dati. Si spera che questa lacuna venga colmata con la versione 2 dello UML; ma nel frattempo cosa fare? Un consiglio potrebbe essere di cercare di adattare la metodologia EntityRelationship. Questo consiglio rientra nella categoria di quelli che suggeriscono al progettista di adoperare i modelli nella maniera pi confacente alle proprie necessit. Lidea scaturisce dalla constatazione che, in ultima analisi, i diagrammi delle classi possono essere considerati unevoluzione dei diagrammi E-R. Nella metodologia EntityRelationship, partendo dai relativi diagrammi si arriva fino al disegno della base di dati, disegno che poi si ottimizza in funzione delle operazioni da compiervi e del relativo carico. Pertanto, attraverso una serie di passaggi successivi, si pu giungere fino alla rappresentazione dello schema finale partendo dalla rappresentazione Object Oriented del do-

UML e ingegneria del software: dalla teoria alla pratica

minio del problema.1 Per far ci necessario applicare tutta una serie di regole ben fissate che per esulano dalla presente trattazione. Sintetizzando, trasportare un diagramma delle classi nella relativa versione E-R dovrebbe essere un lavoro abbastanza immediato e, fatto ci, si tratterebbe di proseguire applicando placidamente le direttive della metodologia Entity-Relationship. Unaltra tecnica consiste nellelaborare particolari versioni del formalismo dei Class Diagram stesso. Sebbene ci possa offrire diversi vantaggi, quali per esempio utilizzare uno stesso tool UML e quindi uno stesso repository anche per questa tipologia di manufatti, daltro canto porta a generare diagrammi delle classi a dir poco artificiosi. Nel mondo dei database relazionali le relazioni si ottengono per mezzo di relazioni implicite realizzate per mezzo di codici. Si consideri la fig. 2.3. Volendo per esempio rappresentare che un record di una tabella A associato con n record di una tabella B, si potrebbe ricorrere a una relazione di dipendenza tra le classi rappresentanti le due tabelle, esportando esplicitamente lattributo chiave della tabella A nella tabella B come chiave

Figura 2.3 Esempio di utilizzo dei diagrammi delle classi per mostrare la struttura logica di un database relazionale. Lesempio di figura vuole avere unicamente valenza dimostratrice. Nella realt, probabilmente sarebbe stato pi opportuno mostrare una relazione tra le entit Squadra e Persona e quindi evidenziare opportune generalizzazioni di questultima (per esempio Uomo, Donna) e unulteriore associazione con unaltra entit denominata Funzione. Una persona pu recitare pi ruoli: Calciatore, Allenatore, ecc.
costituita

idSquadra nome ...

SQUADRA

(1,1)

(1,n)

CALCIATORE

idCalciatore cognome nome ...

Squadra
primaryKeyidSquadra : String name : String ...

Calciatore
primaryKeyidCalciatore : String foreignKeyidSquadra : String cognome : String nome : String ...

La versione finale della rappresentazione Object Oriented del dominio del problema tipicamente viene realizzata

nel modello di analisi attraverso opportune varianti dei diagrammi delle classi. La caratteristica di questi ultimi visualizzare unicamente le entit effettivamente presenti nella realt oggetto di studio, corredate dai relativi attributi,

Capitolo 2. UML: struttura, organizzazione, utilizzo

straniera. Eventualmente si potrebbero utilizzare stereotipi del tipo <<PrimaryKey>> e <<ForeignKey>>. Probabilmente lautore verr accusato di essere affetto da un virus di stranezza, o di realizzare software dellet della pietra, eppure, nel 99% dei sistemi realizzati erano presenti uno o pi moduli dedicati allinterfaccia utente. I sistemi, incredibilmente, erogano servizi fruibili dagli utenti e, stranamente, linterazione avviene attraverso opportuni layer di interfacciamento. Si tratta dello strato pi esterno: quello che per lutente vede ed in grado di valutare, tanto che spesso il giudizio che un utente si costruisce di un sistema basato principalmente sulla relativa interfaccia utente, sulla sua accuratezza, sulla semplicit di utilizzo, ecc. Ora viene ancora da farsi la solita domanda: perch lo UML non prevede formalismo dedicato alla descrizione dellinterfaccia lutente? Eppure il relativo studio, qualora necessario, rappresenta uno dei manufatti di una certa importanza (si pensi a sistemi Internet di commercio elettronico) da produrre e sottoporre al vaglio dellutente. Probabilmente esisteranno altri strani fattori traversali che rendono difficile lindividuazione di uno standard. A questo punto si ritiene divertente riportare una serie di aneddoti relativi al rapporto tra lautore e la produzione di interfacce utente: Errare humanum est, perseverare diabolicum. Nel primo progetto londinese lautore temeva che gli inevitabili problemi di abilit linguistiche avrebbero potuto creare notevoli problemi; la situazione era pi drammatica del solito: oltre al problema di parlare un linguaggio differente dal committente per via delle diverse competenze (cliente esperto di business con scarso bagaglio tecnico), era proprio la lingua a essere effettivamente diversa! Che fare? Ecco la brillante si fa per dire idea: realizzare rapidamente e nottetempo un prototipo con uno strumento quale ad esempio Borland Delphi o MS Visual Basic, da utilizzarsi come piattaforma di dialogo. Allinizio sembrava che lidea fosse veramente buona. Il prototipo, vera primadonna, era al centro di tutti i meeting e forniva un valido ausilio anche al cliente per capire di cosa avesse effettivamente bisogno: si richiedeva di aggiungere informazioni supplementari, di modificarne altre, di variare le dimensioni di alcuni campi, di modificare le business rules ecc. Tutto bene fino al momento in cui il prototipo fu giudicato sufficientemente rispondente. A questo punto ci si accorse che nella mente del cliente si era drammaticamente instaurata la malsana idea secondo la quale il sistema reale era quasi pronto: bastava riciclare e sistemare quanto presente nel prototipo per poi consegnare. In altre parole il cliente si aspettava di avere la versione finale del sistema nellarco di poco pi di un mese! A quel punto la catastrofe si era consumata: ci vollero non pochi meeting per far comprendere ci che in altri ambienti dellingegneria abbastanza ovvio: un prototipo non un sistema reale Chi potrebbe pretendere di camminare sul plastico di un ponte o di un centro commerciale? Chiss come mai la solita vocina dice che ci sono manager i quali farebbero anche questo. Secondo progetto londinese: memori di quanto accaduto con il progetto precedente, questa volta si tent con MS PowerPoint: caspita, tutti sanno che si tratta di un prodotto

UML e ingegneria del software: dalla teoria alla pratica

per le presentazioni e non per lo sviluppo del software lautore comincia a odiare la vocina che gli urla dentro. Se da un lato non si corse quindi il rischio di ingenerare nellutente la spaventevole idea che il prototipo fosse quasi il sistema finale, dallaltro non si riusc a differenza del caso precedente a evidenziare le varie procedure del business, la navigazione della GUI, i vari dettagli e cos via. In altre parole lutilit della presentazione realizzata con MS PowerPoint fu molto relativa, a dir poco. Terzo tentativo Il problema era il seguente: il prototipo realizzato in Delphi o MS Visual Basic risultava molto allettante, ma nessuno, proprio nessuno, voleva pi correre il rischio di ingenerare nel cliente strane idee Cosa fare? La soluzione venne allautore vedendo un negozio di giocattoli: acquistare un bel modellino in scala del famoso London Bridge. A questo punto si realizz lennesimo prototipo in Delphi, ma questa volta lautore port con s nei vari meeting il ponte giocattolo non perdendo nessuna occasione per indicarlo al fine di evidenziare loggetto delle varie analisi: un prototipo, solo un prototipo, nientaltro che un prototipo.

Utilizzo dello UML nei processi di sviluppo


Sebbene esuli decisamente dagli obiettivi del presente libro trattare una materia cos complessa e fondamentale come quella dei processi di sviluppo ci vorrebbe almeno un libro solo per questo argomento si ritenuto altres indispensabile prendere in considerazione un processo di riferimento al fine di illustrare in maniera pi concreta lutilizzo dello UML. Spesso alcuni tecnici tendono a confondere lo UML con il processo di sviluppo: come ripetuto pi volte lo UML solo un linguaggio di modellazione e come tale si presta a rappresentare i prodotti generati nelle varie fasi di cui un processo composto. Pertanto lo UML, al contrario dei processi, non fornisce alcuna direttiva (cosa fare, quali attivit svolgere, quando, chi ne detiene la responsabilit e cos via) su come fare evolvere il progetto attraverso le varie fasi (si veda il Capitolo 1) cos come non specifica quali sono i manufatti da produrre, chi ne responsabile ecc. Nel momento in cui viene scritto il presente libro, non esiste un processo standard universalmente accettato2 n tantomeno esiste un accordo sulle varie fasi e sui relativi nomi. Addirittura non esiste una visione completamente concordante tra il libro dei Tres Amigos The Unified Software Development Process ([BIB08]) e il processo proposto dalla Rational, il RUP (Rational Unified Process), che ne rappresenta una rielaborazione.

Sembrerebbe che il processo proposto dalla Rational (RUP) stia di fatto prendendo sempre pi piede nelle varie

aziende con non poche difficolt non sempre ingiustificate.

10

Capitolo 2. UML: struttura, organizzazione, utilizzo

Lavorando come liberi professionisti pu anche accadere di dover inventare nuovi nomi per indicare alcune fasi e/o modelli (come per esempio Detailed Design Model, modello di disegno di dettaglio), al fine di evitare con il rifacimento del lavoro di urtare la suscettibilit dei colleghi Come dire che se un manufatto presenta seri problemi, per stato realizzato da una persona importante, magari dal Chief Architect, allora meglio escogitare un nuovo nome per il rifacimento piuttosto che pestare i piedi di qualche collega. I processi devono essere sia adattati alle singole organizzazioni in funzione di molti parametri, come per esempio le dimensioni, lo skill tecnico, le diverse figure professionali disponibili e cos via, sia dimensionati rispetto alle caratteristiche dei progetti: probabilmente il processo dimostratosi efficace per la costruzione di un grattacielo potrebbe risultare non altrettanto efficace per realizzare una copertura per le macchine. Sebbene per decenni i vari lavoratori siano stati considerati attori, componenti sostituibili del sistema di sviluppo, solo recentemente si cominciato a comprendere come in realt le cose non siano cos. Come dire: un processo di sviluppo del software per essere prevedibile necessita di componenti a comportamento altrettanto prevedibile. A. Cockburn addirittura si esprime in termini di processi incentrati sulle persone (people-centric). In queste situazioni di mancanza di standard, gli autori professionali suggeriscono al lettore di accendere il proprio cervello switch on the brain ancora la vocina che si fa sentire! e di cercare di prendere tutto ci che viene percepito positivamente e confacente al proprio contesto, eventualmente arrangiandolo in funzione delle proprie esigenze, conferendo eventualmente unimportanza relativa a ci che viene ritenuto meno importante. Lo stesso processo proposto dai Tres Amigos, applicato fedelmente, probabilmente richiederebbe il triplo del tempo e delle risorse effettivamente necessarie. In tal caso gli stati dansia dei vari manager potrebbero risultare giustificabili. Visti gli obiettivi del libro, il processo illustrato di seguito viene presentato focalizzando lattenzione sui prodotti generati piuttosto che sul processo stesso. In ogni modo, cercando di interpolare i vari processi, con particolare riferimento al processo proposto dai soliti Tres Amigos, una schematizzazione abbastanza plausibile potrebbe essere quella in fig. 2.4. Come emerge chiaramente dal diagramma in fig. 2.4, diversi modelli prevedono due proiezioni: una statica ed una dinamica. Per ci che concerne la prima, a seconda della fase in cui si trova, possibile impiegare le seguenti tipologie di diagrammi: casi duso, classi, oggetti, componenti, dispiegamento e cos via. Per ci che concerne la proiezione dinamica, possibile descriverla (sempre in funzione della fase del processo oggetto di studio) attraverso il linguaggio naturale (pi opportuno nelle primissime fasi), con appositi modelli e/o schede, mediante gli appositi diagrammi dello UML (sequenza, di collaborazione, delle attivit e degli stati). Levoluzione logica del progetto avviene secondo un approccio classico denominato a cascata: si passa da una fase a quella successiva e i manufatti prodotti in una fase fornisco-

UML e ingegneria del software: dalla teoria alla pratica

11

no linput delle seguenti. Qualora si evidenzino delle lacune (una fase stata conclusa prematuramente), necessario ripercorrere il processo a ritroso fino a raggiungere la fase Figura 2.4 Utilizzo dei diagrammi UML per produrre i modelli di cui un processo composto. I modelli evidenziati in figura non corrispondono necessariamente a una successione temporale del processo di sviluppo: molte fasi, che in prima analisi potrebbero considerarsi terminali o in stretta successione, vengono avviate il prima possibile al fine di massimizzare il parallelismo (si veda fig. 2.5). Ci utile non solo per logiche legate allottimizzazione dellutilizzo delle risorse, ma anche per aumentare la qualit: ricevere, prima possibile, il feedback da diverse prospettive del modello. Per esempio, le primissime versioni del modello dellarchitettura, tipicamente, sono progettate parallelamente alla fase di analisi dei requisiti, al fine di bilanciare i diagrammi dei casi duso nel contesto dellarchitettura. Si tenga presente che obiettivo del processo presentato semplicemente avere un riferimento atto a illustrare limpiego dello UML nellambito di un processo organico di sviluppo. Il primo diagramma mostrato nel modello di analisi rappresenta una versione del diagramma delle classi che utilizza particolari stereotipi.
Modello Business Modello dei Requisiti
Proiezione statica

Modello di Analisi
Proiezione statica

Modello dei Disegno


Proiezione statica

Modello Fisico
Modello di dispiegamento

Modello di Test

Modello Implementativo

Proiezione dinamica Proiezione dinamica Proiezione dinamica

Modello di dispiegamento

OK

OK

OK

12

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.5 Ciclo di vita di un processo di sviluppo del software. Il diagramma in figura una rielaborazione del processo denominato Enhanced Unified Process (EUP) proposto dalla Ronin Internation Inc.
Organizzazione temporale Fasi

Main Process Workflow


Business modelling Requirements Analysis

Inception Elaboration

Construction

Transition

Production

Organizzazione flussi attivit

Analysis and Design Implemetation Test Deployment Operations and Supports

Support Process Workflow


Configuration and Changes Management Project Management Environment Infrastructures management
iterazioni/e 1a 2a preliminari Iter. Iter. i-ma i-ma+1 i-ma+2 n-ma Iter. Iter. Iter. Iter. n-ma+1 Iter.

Iterazioni

che permette di colmarla. Chiaramente gli effetti generati dalle correzioni sono proporzionali al numero di fasi a ritroso in cui necessario risalire: pi si risale e maggiore lonere necessario per aggiornare i manufatti prodotti. Qualora si utilizzi un approccio iterativo e incrementale, lintero processo viene suddiviso in sottoprogetti e quindi levoluzione avviene sulla base di opportune iterazioni. In ciascun sottoprogetto vengono presi in considerazione un certo numero di casi duso o relative frazioni. Man mano che si procede verso fasi pi tecniche del processo, risulta fortemente consigliabile cercare di utilizzare modelli sempre pi formali, come per esempio i diagrammi dello UML. Per esempio mentre nel modello dei requisiti del tutto legittimo ricorrere a template per descrivere gli scenari dei casi duso, lo sarebbe di meno nel modello di disegno ove consigliabile utilizzare i diagrammi dello UML dedicati alla descrizione del comportamento dinamico (per esempio Sequence, Collaboration, Activity, ecc.). Gli stessi diagrammi dovrebbero possedere un livello di astrazione decrescente (aumento del livello di dettaglio) procedendo nelle fasi pi interne dello sviluppo del siste-

UML e ingegneria del software: dalla teoria alla pratica

13

ma: un diagramma di sequenza utilizzato nel modello dei requisiti dovrebbe possedere un livello di astrazione molto elevato, mentre utilizzato nel modello di disegno dovrebbe essere molto dettagliato. Lo UML pu essere efficacemente paragonato allinsieme di attrezzi presente, per esempio, in una falegnameria. Ci sono tutta una serie di utensili (i diagrammi) ognuno dei quali risulta particolarmente indicato per compiti specifici, mentre del tutto inadeguato per altri. Volendo avvitare una vite verosimilmente il cacciavite risulta lo strumento pi consono, mentre per conficcare un chiodo in una superficie, probabilmente, lo sarebbe di meno (pu capitare per che determinati capi progetto non abbiano alcun problema a richiedere di infilare chiodi utilizzando i cacciaviti). Sebbene sia possibile individuare processi pi formali o pi affini alle necessit delle singole organizzazioni e ai progetti, la schematizzazione proposta in figura dovrebbe risultare piuttosto credibile; eventualmente si potrebbero escogitare nomi diversi, ulteriori manufatti da produrre e cos via. Brevemente (ogni fase verr ripresa nei capitoli successivi) i vari modelli da produrre come risultato delle varie fasi di un processo sono quelli riportati di seguito.

Modello Business
Viene generato come risultato della fase di modellazione della realt oggetto di studio (Business Modeling). Lobiettivo capire cosa bisogner realizzare (requisiti funzionali e non), quale contesto bisogner automatizzare (studiarne struttura e dinamiche e, a tal fine, spesso si utilizzano i famosi Domain e/o Business Object Model), comprendere lorganigramma dellorganizzazione del cliente, valutare lordine di grandezza del progetto, individuare possibili ritorni dellinvestimento per il cliente, eventuali debolezze, potenziali miglioramenti, iniziare a redigere un glossario della nomenclatura tecnica al fine di assicurarsi che, nelle fasi successive, il team di sviluppo parli lo stesso linguaggio del cliente, e cos via. necessario effettuare il famoso studio di fattibilit, redigere una prima versione dei famosi requisiti del cliente sia attraverso la versione iniziale del modello dei casi duso (denominato appunto business) sia per mezzo di documenti elettronici (lista dei potenziali requisiti), ecc. Molto spesso viene avviata anche la produzione del documento dellarchitettura software del sistema (SAD, Software Architect Document) aggiornato durante tutto il ciclo di vita del sistema. In questo contesto di fondamentale importanza riuscire a instaurare una corretta piattaforma di intesa con il cliente: si tratta di una fase non eccessivamente formale in cui tutte le convenzioni utilizzate risultano ben accette purch concorrano effettivamente ad instaurare un dialogo costruttivo con il cliente. Nel mondo ideale gran parte di questo modello potrebbe essere realizzato attraverso i vari diagrammi messi a disposizione dallo UML Per quanti manager (anche di societ informatiche) sono in grado di capire modelli formulati attraverso lo UML? Linterrogazione retorica potrebbe essere posta anche in altri termini: quanti dei vostri manager sono in grado di comprendere modelli espressi per mezzo dello UML? Si provi allora a immaginare la

14

Capitolo 2. UML: struttura, organizzazione, utilizzo

risposta pensando ai clienti i quali, per definizione, possiedono limitate conoscenze informatiche. In molti processi non prevista la presente fase: si parte direttamente con il modello dei requisiti. In questo contesto si deciso invece di riportarla sia perch si fa sempre in tempo a eliminarla dal proprio processo, sia perch, tipicamente, prima di avviare il processo di sviluppo vero e proprio necessario superare una prima attivit relativa allo studio di fattibilit, al fine di accertarsi che esista una piattaforma dintesa economica con il cliente: chiss come mai gli studi di fattibilit non producono mai un esito negativo. Nella peggiore delle ipotesi sempre possibile aggiustare lesito con qualche donazione (gli orologi vanno per la maggiore). Nella realt gli studi di fattibilit dovrebbero venir eseguiti da particolari dipartimenti interni allazienda committente o da terze parti

Modello dei requisiti


Questo modello viene prodotto a seguito della fase comunemente detta analisi dei requisiti (Requirements Analysis). Scopo di questa fase produrre una versione pi tecnica dei requisiti del cliente evidenziati nella fase precedente. Tipicamente, il modello dei casi duso elaborato in questa fase (prodotto da System Analyst e Use Case Specifier) ancora utilizzato come strumento di dialogo con il cliente: gli Use Case prodotti risultano ancora parlare un linguaggio assolutamente compatibile con il cliente, sebbene il modello venga inserito nel contesto definito dallarchitettura (ci si riferisce ad esso con i termini di System Use Case Model). In questa fase importante far confluire eventuali vincoli presenti e i cosiddetti requisiti non funzionali del sistema (performance, affidabilit, disponibilit, scalabilit, e cos via), sebbene alcuni di essi si prestino ad essere inclusi direttamente nei vari Use Case: vengono raggruppati in appositi documenti (SRS, Supplementary Requirements Specifications, specifica dei requisiti supplementari). Altri prodotti particolarmente importanti da produrre sono: stima dei costi e dei tempi di sviluppo dellintero sistema, assegnazione delle priorit (e quindi suddivisione del processo in iterazioni), primissime versioni/idee relative alla GUI (Graphical User Inetrface), rielaborazioni dei vari Object Model, del SAD, e cos via.

Modello di analisi
Come lecito attendersi, questo modello viene prodotto come risultato della fase di analisi i cui obiettivi sono: 1. produrre una versione dettagliata e molto tecnica della Use Case View attraverso opportuni diagrammi delle classi, accogliendo direttive provenienti dalle versioni disponibili del disegno dellarchitettura del sistema, che a loro volta dipendono da questo modello. Si assiste alla graduale perdita di generalit dei modelli e si passa a un linguaggio pi vicino agli sviluppatori e quindi dotato di una notazione pi formale. Lobiettivo del modello varia: a questo punto il fruitore principale il

UML e ingegneria del software: dalla teoria alla pratica

15

proprio team tecnico e non pi il cliente. Si realizza, pertanto, una primissima versione del modello di disegno, generalmente, costituita dalle entit effettivamente presenti nel dominio, interfacce e processi di controllo. In questa fase, tipicamente, non si ha interesse a introdurre ottimizzazioni o razionalizzazioni: lobiettivo quello di rappresentare formalmente i requisiti del sistema. 2. analizzare dettagliatamente le business rules da implementare. 3. qualora necessario, si revisiona il prototipo (o comunque una descrizione) dellinterfaccia utente, il SAD, ecc. In molti processi (come il RUP per esempio) la fase di analisi viene aggregata con la fase di disegno.

Modello di disegno
Anche in questo caso il modello di disegno il prodotto della omonima fase, in cui ci si occupa di plasmare il sistema, trasformare i vari requisiti (funzionali e non funzionali) forniti nel modello di analisi in un modello direttamente traducibile in codice. A tal fine necessario costruire linfrastruttura intorno ai diagrammi delle classi prodotti nella precedente fase. Sempre in questo stadio, importante realizzare un modello completo dellinterfaccia utente e della relativa navigabilit. In sintesi, gli obiettivi della fase di disegno sono: 1. acquisire una profonda comprensione di problematiche relative ai requisiti nonfunzionali e ai vincoli dovuti ai linguaggi di programmazione, al riutilizzo di eventuali componenti, ai sistemi operativi coinvolti, a problematiche di distribuzione del carico di lavoro e alla conseguente possibilit di svolgere operazioni in parallelo, al sistema di gestione della base dati, alle tecnologie da utilizzare per linterfaccia con lutente, a quelle da utilizzarsi per la gestione delle transazioni, e cos via. 2. realizzare un opportuno modello completo in grado da fornire tutte le direttive necessarie per limplementazione del sistema. 3. stabilire il piano per la decomposizione intelligente dellimplementazione del sistema, al fine di massimizzarne levoluzione parallela dei vari sottosistemi. 4. disegnare quanto prima possibile le interfacce esistenti tra le varie componenti del sistema.

16

Capitolo 2. UML: struttura, organizzazione, utilizzo

5. disegnare opportuni modelli al fine di investigare sulle possibili soluzioni attuabili. In genere non necessario eccedere nel disegno del sistema dettagliando tutte le classi di un package e/o tutti i metodi. Qualora il disegno sia sufficiente per la relativa implementazione e non sia fonte di ambiguit, del tutto accettabile procedere alla codifica senza sprecare tempo. Chiaramente il livello di dettaglio a cui giungere inversamente proporzionale al livello tecnico del proprio team di codificatori: al diminuire del secondo deve aumentare il livello di dettaglio; quando poi lo skill tende a zero, allora conviene implementare in proprio e inventarsi esercizi di stile da assegnare al proprio team. Poich il modello di disegno molto vicino allimplementazione del sistema, tipicamente risulta soggetto a correzioni, rifiniture e aumento del livello di dettaglio provenienti sia dallimplementazione del modello stesso sia da eventuale refactoring. Il reverse engineering, posto in questi termini, del tutto accettabile. Pu capitare per di chiedere ad alcuni tecnici di visionare il modello di disegno del loro sistema e sentirsi rispondere che verr prodotto alla fine dellimplementazione attraverso, appunto, reverse engineering. Il roundtrip (si modella, si implementa e quindi si ritocca il modello) del tutto accettabile (daltronde solo il codice allineato con limplementazione del sistema), mentre il reverse engineering da solo, nella mente dellautore, percepito come cosa da evitarsi e spesso del tutto inutile. Si pensi al caso in cui si utilizzino tecniche di reflection nel codice Java. Tra le varie caratteristiche, le classi di questo package permettono di creare oggetti specificando la classe di appartenenza per mezzo del nome impostato in una stringa. In altre parole si chiede di creare un oggetto non attraverso il classico costruttore new, ma specificando il nome (stringa) della classe di appartenenza come parametro di un opportuno metodo. In tal caso i vari tool non sono ancora in grado di ricostruire le dipendenze tra oggetti di questo tipo, e quindi il reverse engineering non mostrerebbe alcun legame tra le classi che incorporano tecniche di reflection e quelle specificate nelle relative stringhe.

Modello fisico
Il modello fisico, a sua volta, composto essenzialmente da due modelli: Deployment e Component. Non si tratta quindi del prodotto di una fase ben specifica, bens dei risultati di rielaborazioni effettuate in diverse fasi. Il modello dei componenti mostra le dipendenze tra i vari componenti software che costituiscono il sistema. Come tale la versione finale di questo modello dovrebbe essere il risultato della fase di disegno. Non infrequente il caso in cui per se ne realizzino versioni preliminari in fasi precedenti con lobiettivo di chiarire i servizi esposti dai vari sottosistemi e quindi di consentire levoluzione parallela dei sottosistemi. Il modello di dispiegamento (Deployment) descrive la distribuzione fisica del sistema in termini di come le funzionalit sono ripartite sui nodi dellarchitettura fisica del sistema. Si tratta quindi di un modello assolutamente indispensabile per le attivit di disegno ed implementazione del sistema. In genere le primissime versioni del modello di dispiegamento vengono create nella fase di elaborazione dei requisiti per consen-

UML e ingegneria del software: dalla teoria alla pratica

17

tire di contestualizzare e bilanciare tra loro i vari modelli: gli Use Case perdono di genericit e incorporano riferimenti architetturali. Il disegno dellarchitettura fisica dovrebbe essere realizzato in funzione del modello dei casi duso, ossia dei servizi che il sistema dovr fornire calati nel contesto dei requisiti non funzionali. In realt, si cerca di partire da soluzioni architetturali mostratesi efficaci in precedenti progetti (pattern architetturali) eventualmente revisionati in funzione di alcune particolari necessit.

Modello di test
Nella produzione di sistemi, con particolare riferimento a quelli di dimensioni medie e grandi, opportuno effettuare test in tutte le fasi. Eventuali errori o lacune vanno eliminate prima possibile sarebbe ancor pi opportuno prevenire al fine di neutralizzare leffetto delle relative ripercussioni sul sistema. Se si sta costruendo un ponte evidente che opportuno verificare le varie colonne sia dopo la relativa progettazione sia subito dopo la costruzione. Non si vuole di certo correre il rischio di riscontrare manchevolezze dopo avervi posato la sezione relativa alla strada. Quindi opportuno effettuare test prima di dichiarare conclusa ciascuna fase. In questo contesto si fa riferimento a uno specifico modello atto a verificare la rispondenza di ogni versione del sistema frutto di unappropriata iterazione. Il modello di test dovrebbe essere generato non appena disponibile una nuova versione stabile dei casi duso. Pertanto dovrebbe essere elaborato o dopo il modello dei requisiti o dopo quello di analisi. Chiaramente opportuno verificare tutti i manufatti; per meritano particolare attenzione quelli che in ultima analisi verranno eseguiti: classi, package, componenti, sottosistemi, script e cos via. Nel realizzare il modello di test necessario: 1. pianificare i test richiesti a seguito di ciascuna iterazione. In questo contesto si parla di test di integrazione (Integration Test) e test di sistema (System Test). I primi vengono eseguiti ogni qualvolta si integrano diverse parti del sistema al fine di verificarne la corretta collaborazione. I secondi si effettuano alla fine delliterazione e servono per accettarsi che le funzionalit oggetto della iterazione siano rispondenti agli Use Case/scenari presi in considerazione dalla stessa. 2. disegnare e realizzare i test attraverso i Test Cases che specificano cosa verificare e le Test Procedure che illustrano come eseguire i test. Quando possibile, sarebbe opportuno creare componenti eseguibili (test component) in grado di effettuare i test automaticamente. 3. Integrare i test necessari al termine dellattuale iterazione con quelli eventualmente prodotti per le iterazioni precedenti. Il modello di test quindi specifica come eseguire i vari test (che ovviamente vanno eseguiti nella relativa fase) e come tenere traccia dei risultati e del comportamento. Lobietti-

18

Capitolo 2. UML: struttura, organizzazione, utilizzo

vo essere in grado, in caso di malfunzionamenti, di fornire opportuno feedback per la rigenerazione dellerrore.

Modello implementativo
Questo modello frutto della fase di implementazione il cui obiettivo tradurre in codice i manufatti prodotti nella fase di disegno e quindi realizzare il sistema in termini di componenti: codice sorgente, file XML, file di configurazione, scripts, ecc. In particolare necessario: pianificare lintegrazione necessaria tra i sottosistemi prodotti durante le varie iterazioni (nel caso classico in cui il processo utilizzi un approccio iterativo e incrementale); distribuire il sistema come prescritto dal Deployment Diagram (mapping dei componenti eseguibili sui nodi del sistema); codificare il modello di disegno in classi. A seconda del livello di completezza del disegno, tipicamente accade che limplementazione richieda un aumento del dettaglio del disegno catturato attraverso il reverse engineering; realizzare dei package, atti a eseguire gli Unit Test, ossia a verificare il corretto funzionamento di sottosistemi prima di renderli disponibili per lintegrazione. Dalla descrizione del processo sono stati trascurati volutamente tutti i manufatti tra laltro importantissimi relativi alla pianificazione del progetto, in altre parole quelli pi a carattere manageriale. Si tratta di una sorta di processo parallelo presente in tutte le fasi del ciclo di vita del software: pianificazione della gestione dei requisiti, assegnazione delle priorit agli Use Case con conseguente pianificazione delle iterazioni, analisi dei rischi anche questa concorre alla pianificazione delle iterazioni , continua elaborazione e monitoraggio del SDP (Software Development Plan, piano di sviluppo del software) cos via. Chiaramente la buona riuscita di un progetto dipende molto dalla sua corretta pianificazione, anche se taluni manager credono che ci sia il risultato della padronanza del tool Microsoft Project: che cosa importano i vari numeri (giorni/uomo) o la pianificazione delle attivit? Limportante disporre di un bel diagramma da appendere al muro Altri manufatti da produrre nelle varie fasi sono i documenti con le linee guida (Guidelines) con indicazioni sul modo di realizzare i vari manufatti stessi. In altre parole si tratta di prodotti funzionali al processo, da riutilizzarsi anche per eventuali progetti futuri. Per esempio necessario realizzare le guidelines relative agli Use Case (quali stereotipi utilizzare, come descrivere i vari scenari, ecc.). Ogni progetto ha delle proprie problematiche specifiche e quindi si vuole che i vari manufatti alla fine di ogni fase risultino consistenti.

UML e ingegneria del software: dalla teoria alla pratica

19

La critica che pi di frequente viene avanzata ai processi formali di essere eccessivamente burocratici e Document-Oriented, tanto da essere addirittura definiti monumentali (Jim Highsmith). Come suggerisce lo stesso M. Fowler, spesso necessario mettere a dieta i processi, al fine di evitare la produzione di un enorme quantitativo di documentazione che, oltre a richiedere molto tempo per la realizzazione e laggiornamento, finisce, paradossalmente, per scoraggiare i tecnici pi volenterosi. Come alternativa si assiste a tutto un fiorire di processi per cos dire leggeri (Lightweight), pi pragmatici, comunque migliori di metodologie completamente imperniate sulla codifica e correzione. Processi basati su tutta una serie di decisioni a breve o brevissimo termine, validissimi per progetti di piccole dimensioni, che per, applicati in sistemi di dimensioni maggiori, sono in grado di generale sistemi caotici e chiusi. In tali sistemi linserimento di nuove funzionalit implica acrobazie e pene indescrivibili nonch il terrore dellintero team di sviluppo. In fig. 2.6 viene riportato un altro diagramma che visualizza le dipendenze tra i vari manufatti prodotti durante un processo. Ancora una volta non sono stati presentati tutti i manufatti, ma solo quelli ritenuti pi interessanti e confacenti ai fini della trattazione (il diagramma gi abbastanza complicato cos). Alcuni sono stati condensati in uno stesso package e altri sono stati estrapolati in quanto ritenuti interessanti da visualizzare: si ricor-

Figura 2.6 Diagramma delle classi dei manufatti prodotti dal processo. (Si tratta di una rielaborazione Object Oriented di quello fornito da Scott Ambler nel libro Process Pattern ([BIB12]).

GUI Diagramma di navigazione

GUI Prototipo GUI (alpha ver) refine

GUI Prototipo GUI (beta ver)

deployment diag. Deployment

class diagram Def. interfacce esterne

activity diagram Comportamento concorrente

sequence diagram Comportamento dinamico refine class diagram Modello di disegno componet diag. Modello dei componenti

use case Modello u.c. business

refine

use case Modello u.c. requisiti


r efi ne

class diagram Modello di analisi

collaboration diag. Collaborazione tra oggetti class diagram Modello ad ogg. business class diagram Modello ad ogg. dominio statechart diagram Descrizione stati

doc Glossario

doc Requisiti non funzionali Vincoli Business rules refine Test model Modello del database

sorgenti Modello implementativo

20

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.7 Diagramma delle attivit del processo.

Acquisizione ed analisi documentazione

Analisi dominio del problema

Studio requisiti funzionali e non

Analisi vincoli

Stesura glossario

Studio: ROI, fattibilita', organigramma, ecc.

Studio business

Revisione modello business [modello non soddisfacente] [modello soddisfacente] Analisi business rules Revisione vincoli Modellazione use case requisiti Assegnazione priorita' Prima definizione test case Produz. modello ad oggetti del dominio Prototipazione GUI versione alpha Indagine soluzioni architetturali Def. prima versione interfacce

Analisi dei requisiti

Revisione modello dei requisiti [modello non soddisfacente] [modello soddisfacente] Realizzazione modello di analisi Affinamento soluzioni architetturali Aggiornamento modello concettuale Revisione / aggiornamento GUI

Revisione test case

Revisione business rules

Analisi

Revisione manufatti di analisi [manufatti non soddisfacenti] [manufatti soddisfacenti] Disegno sistema Revisione architettura Definizione interfacce Definizione diag. componenti Pianificazione integrazione sottosistemi

Disegno

Revisione manufatti di disegno [manufatti non soddisfacenti] [manufatti soddisfacenti] Implementazione sottosistemi

Codifica test Test sottosistemi

Integrazione sottosistemi Test di integrazione

Aggiornamento modello di disegno

Test

Verifica versione del sistema [versione del sistema non soddisfacente] [versione del sistema soddisfacente]

UML e ingegneria del software: dalla teoria alla pratica

21

di che lobiettivo evidenziare i manufatti realizzabili per mezzo dei meccanismi forniti dallo UML In questo contesto la relazione di dipendenza (freccia tratteggiata) che unisce i vari package ha un significato piuttosto intuitivo: un aggiornamento dellentit indipendente genera necessariamente modifiche su quella dipendente. Per esempio se si apportano delle modifiche al modello di analisi, verosimilmente necessario rivedere il modello di disegno. Non sempre la relazione di dipendenza ha un legame cos forte. Per esempio la variazione del modello di analisi non sempre genera modifiche in quello della base di dati, per, tipicamente, ne richiede almeno la revisione. I vari package (in questo contesto sono collezioni di manufatti) assumono un colore che ne indica, per cos dire, la connotazione UML: quelli evidenziati con un giallo intenso possono essere specificati interamente attraverso i meccanismi dello UML, quelli in giallo tenue possono esserlo solo parzialmente, mentre per quelli bianchi necessario ricorrere a formalismi diversi, quali per esempio i classici documenti. Per esempio il modello del database, nel caso in cui si consideri un database Object Oriented potrebbe essere specificato attraverso diagrammi delle classi e degli oggetti e quindi per mezzo dello UML, mentre negli altri casi necessario realizzare un mapping tra tali diagrammi e altri pi vicini alla natura del database manager con tecniche non presenti nello UML. I vari package del diagramma tengono conto della propriet transitiva della dipendenza. Per esempio poich il modello del database dipende dal modello di disegno che a sua volta dipende dal modello concettuale, evidente che anche il modello del database dipenda da quello concettuale. Ciononostante, alcune volte, si deciso di evidenziare tale dipendenza perch, teoricamente, diversi modelli (in questo caso disegno e database) dovrebbero venir sviluppati separatamente e in parallelo per poi essere riallineati. In fig. 2.7 viene riportata unaltra proiezione del processo di sviluppo focalizzata questa volta sulle attivit da svolgere. Il formalismo utilizzato quello degli Activity Diagram (diagrammi di attivit). Linterpretazione abbastanza intuitiva: i rettangoli arrotondati indicano attivit da svolgere, i rombi evidenziano la divisione del flusso mentre le linee orizzontali doppie indicano che le attivit incluse tra due successive possono essere eseguite parallelamente. Il diagramma si configura ancora come una overview: ogni attivit dovrebbe essere illustrata per mezzo di un altro Activity Diagram di dettaglio. Ovviamente lobiettivo quello di fornire al lettore unidea delle varie attivit da svolgere nelle varie fasi, senza avere assolutamente la pretesa di essere esaustivi. Nella rappresentazione del processo non si data alcuna enfasi allapproccio iterativo e incrementale solo al fine di evitare di complicare maggiormente il diagramma. Tipicamente le prime due o tre iterazioni (in funzione delle dimensioni del progetto) sono imperniate sulle prime due fasi: analisi del business e dei requisiti.

22

Capitolo 2. UML: struttura, organizzazione, utilizzo

Le restanti iterazioni invece sono focalizzate sulla realizzazioni di versioni successive del sistema e quindi hanno come dominio le fasi di analisi, disegno, implementazione e test.

Sistemi di sistemi: il progetto che non ti aspetti


Per definizione tutti i progetti sono unici. Anche qualora si lavori nel settore dellecommerce, dove i pattern utilizzati sono sempre gli stessi, prassi che ogni progetto abbia Business Rules del tutto esclusive, integrazioni specifiche, architetture di riferimento particolari e cos via. Capita sempre insomma di dover affrontare problematiche particolari non presenti in nessun testo: a questa legge empirica non si sottraggono certo i processi di sviluppo. Si prendano in considerazione grandi sistemi quali per esempio quelli delle banche. In questi contesti probabilmente pi opportuno affrontare il processo di sviluppo pensando il progetto in termini di sistemi di sistemi: c una serie di sistemi (front office, gestione conti correnti, sistema di banking on-line, treasury, gestione delle eccezioni, e cos via) e il sistema globale con funzioni di collante (fig. 2.8). La realizzazione del sistema finale di solito non prevede la realizzazione ex-novo di tutti i sistemi: sarebbe una follia. Verosimilmente, per la maggior parte di essi risulta sufficiente realizzare appositi strati di wrapping: business logic antica in una facciata moderna. In contesti di questo tipo probabilmente utilizzare un processo tradizionale potrebbe causare diversi problemi. Il fatto che ormai i progetti non sono pi come quelli di un ventennio fa in cui cera tutto da fare e quindi era possibile dividere nettamente le varie aree: nelle organizzazioni Figura 2.8 Schematizzazione di un sistema di sistemi.

Sistema "globale"

UML e ingegneria del software: dalla teoria alla pratica

23

moderne i vari impiegati crescono con linfrastruttura informatica fusa nel loro business; essa diventa parte integrante anche della loro forma mentis. Pertanto, affrontare il processo realizzando dapprima il modello dei casi duso a livello business, poi requirements, il modello di analisi, ecc. potrebbe risultare alquanto complicato. Per esempio i clienti in questo contesto gli esperti dellarea business della banca sono generalmente abituati a pensare alle varie funzionalit in termini di collaborazione tra i sistemi informatici presenti; sanno esattamente, per esempio, quando termina il workflow a carico del front office e quando inizia quello relativo al back office; conoscono di quali altri sistemi si avvale la collaborazione (revaluation, messaggistica, market rates, ecc.) e cos via. In queste situazioni, per quale motivo forzare il cliente di astrarsi dalla suddivisione del sistema in sottosistemi? Anzi, magari fossero tutti cos i clienti. Cercare di applicare il processo in modo accademico potrebbe addirittura portare a realizzare modelli artificiosi e innaturali per gli stessi clienti. Altri problemi potrebbero venire dal tempo e dallaumento del fattore di rischio dovuto allaffrontare globalmente anche solo la modellazione dei casi duso di un sistema di dimensioni cos elevate. Una buona idea potrebbe essere quella di sfruttare la percezione della scomposizione architetturale del sistema intrinseca nella concezione del cliente e quindi affrontare n+1 progetti con n uguale al numero dei sottosistemi esistenti e il fattore aggiuntivo dovuto al sistema globale di raccordo (lintegrazione). Il rischio pi preoccupante in cui si potrebbe incorrere con approcci di questo tipo, realizzare un sistema in cui le varie parti non risultino facilmente integrabili tra loro. Ricorrendo per a particolari accorgimenti possibile gestire questo rischio corrispondente alla mancata integrazione. Alcuni suggerimenti potrebbero essere: realizzare la versione business considerando globalmente i vari processi dallinizio alla fine senza preoccuparsi dellorganizzazione in sottosistemi, ossia focalizzando lattenzione sulla sequenza delle attivit da svolgere per erogare il servizio, senza per entrare nel dettaglio dellallocazione delle varie attivit ai sottosistemi; pianificare per tempo un processo parallelo per lo studio delle aree in comune tra sottosistemi (integrazione); definire, prima possibile, le interfacce tra i sottosistemi, e cos via. Lapproccio descritto risulterebbe particolarmente valido in tutti quei contesti in cui il cliente possiede una chiara comprensione della suddivisione del flusso tra i vari sistemi ed in grado di specificare le responsabilit e le funzionalit di ciascuno di essi.

24

Capitolo 2. UML: struttura, organizzazione, utilizzo

In ultima analisi, dopo la definizione del modello del business, sarebbe necessario applicare, per ogni sottosistema, lo stesso processo di sviluppo. Ognuno di essi sarebbe caratterizzato dal focalizzare lattenzione su uno specifico sottosistema e dal considerare i restanti come entit esterne (ossia attori) con cui scambiare informazioni. Decomponendo il modello generale dei casi duso, si verifica che determinati servizi, per essere realizzati, necessitano di attraversare pi sottosistemi. Nei punti di attraversamento risiedono le varie interfacce. Lindividuazione delle stesse semplificata dalla successiva versione dei casi duso: focalizzando lattenzione su di un sottosistema, quelli restanti diventano attori per lo stesso. Lassociazione tra un attore sottosistema e quello oggetto di studio avviene rispettando una specifica interfaccia.

In queste tipologie di progetto, potrebbe risultare vantaggioso adeguare parte dellorganigramma alla struttura del sistema. Per esempio, potrebbe essere una buona idea suddividere il personale in tanti team di sviluppo quanti sono i diversi sottosistemi. Prevedere un architetto leader e un analista leader per ciascuno di essi. Ci al fine di decentrare le varie responsabilit, aumentare la consistenza, creare aree di competenza, disporre eventualmente di team ridotti (costituiti per esempio da tutti i vari architetti leader) atti a studiare problemi relativi a pi sistemi (come per esempio lo scambio di messaggi), a evidenziare e utilizzare componenti comuni e cos via.

Questo approccio, che dovrebbe risultare naturale in progetti in cui sia preesistente unorganizzazione in sottosistemi, potrebbe altres essere utilizzato comunque proficuamente anche in casi in cui il sistema da sviluppare risulti oggettivamente grande. Situazioni di questo tipo sono facilmente riscontrabili dalle continue lamentele del team di sviluppo considerato in senso generale: architetti, programmatori, ecc. Le frasi tipiche sono: il modello troppo astratto, servono maggiori dettagli, e cos via. Il che non significa, necessariamente, che il modello non sia stato realizzato correttamente, anzi Evidentemente per necessario produrre unaltra versione del modello, che potrebbe ricollegarsi al caso del sistema di sistemi. Volendo procedere con questa tecnica, unattivit importante quella di individuare correttamente i vari sottosistemi. Nel caso canonico, ci non era necessario semplicemente perch ci si trovava di fronte a una situazione predefinita, da tenere in conto. Ci risulterebbe del tutto coerente con le direttive dei processi di sviluppo: tipicamente la versione requirements del modello dei casi duso detta system proprio perch si pone il modello del business nel contesto del sistema da realizzare e si accettano eventuali feed back provenienti dal disegno di architettura. Di solito gli architetti esperti non hanno enormi difficolt nel decomporre il sistema generale in sottosistemi. In ogni modo la tec-

UML e ingegneria del software: dalla teoria alla pratica

25

nica generalmente utilizzata , a tutti gli effetti, basata sulle direttive Object Oriented: si cerca di costruire sottosistemi intorno a gruppi di dati relazionati tenendo conto anche delle relative funzioni. Per questo fine il Domain Object Model assume un ruolo molto importante: attraverso lispezione visiva permette di raggruppare oggetti strettamente relazionati tra loro e relativamente disaccoppiati dai restanti. Per esempio, se si disponesse di un modello di dominio di un sistema di investimenti bancari, si potrebbe evincere lesistenza di un gruppo di oggetti strettamente legati ai dati provenienti dalla quotazioni di mercato, di un altro relativo a gruppi di dati (relativamente) statici, di un gruppo relativo alla gestione dei trade, di un altro afferente alla gestione della messaggistica e cos via. Chiaramente ci non significa assolutamente che i vari mondi non siano relazionati tra loro. Una buona verifica consiste nel bilanciare le ripartizioni in sottosistemi in funzione dei servizi da erogare. Da tener presente che, una volta decomposto il sistema, la fornitura di diversi servizi richiede in genere linterazione dei sottosistemi attraverso opportune interfacce. Il bilanciamento dalla prospettiva delle funzioni, permette di verificare che un sottosistema soddisfi i criteri base dellingegneria dei sistemi: forte coesione interna; minimo accoppiamento tra sottosistemi; comunicazione ridotta al minimo tra sottositemi; servizi logicamente accomunabili; e cos via.

Use Case Diagram


I diagrammi dei casi duso mostrano un insieme di entit esterne al sistema, dette attori, associati con le funzionalit, dette a loro volta Use Case (casi duso), che il sistema dovr realizzare. Linterazione tra gli attori e i casi duso viene espressa per mezzo di una sequenza di messaggi scambiati tra gli attori e il sistema. Lobiettivo dei diagrammi dei casi duso definire un comportamento coerente senza rivelare la struttura interna del sistema. Nel contesto dello UML, un attore una qualsiasi entit esterna al sistema che interagisce con esso: pu essere un operatore umano, un dispositivo fisico qualsiasi, un sensore, un legacy system, e cos via. Allinterno dei diagrammi degli use case diagram sono illustrate un insieme di funzionalit, gli use case appunto, che il sistema dovr fornire. Si faccia attenzione a non fare

26

Capitolo 2. UML: struttura, organizzazione, utilizzo

confusione: sia i diagrammi, sia le relative funzionalit vengono chiamati Use Case. Questi elementi possono essere connessi tra loro per mezzo di una serie di relazioni quali generalizzazione, inclusione ed estensione. I diagrammi dei casi duso costituiscono il fondamento della Use Case View (ancora una volta use case) e in particolare ne rappresentano la proiezione statica. Tipicamente la vista dei casi duso composta da un insieme di diagrammi use case, i quali sono indipendenti gli uni dagli altri sebbene condividano alcuni elementi. Per illustrare i vari diagrammi forniti dallo UML si deciso di prendere in considerazione un unico esempio: il sito Internet/Intranet con funzioni di commercio elettronico di un teatro; sito che lautore avrebbe tanto voluto utilizzare. In questo caso si tratta di un sistema frutto della fantasia e quindi potrebbero evidenziarsi lacune e incongruenze tipiche di sistemi non realizzati: solo il passaggio attraverso le varie fasi del processo permette di effettuare revisioni formali e quindi di evidenziare le immancabili lacune e incoerenze. Il primo diagramma che viene visualizzato una sorta di indice, o meglio di ricapitolazione delle varie funzioni fornite dal sistema: per ogni caso duso visualizzato lecito attendersi il relativo diagramma di dettaglio.

Sebbene di solito non sia buona pratica procedere per raffinamenti successivi e mostrare diagrammi via via di maggiore dettaglio si rischia di disegnare il sistema in fasi troppo premature e con strumenti sbagliati: non si devono applicare metodologie quali il Data Flow Diagram buona pratica visualizzare il diagramma iniziale di overview.

In esso compaiono Use Case con funzioni di riepilogo e quindi non completamente coerenti con quelli di dettaglio: ci legittimo considerando il relativo fine di overview. Per esempio viene mostrato che lattore Credit Card Authority, associato allo Use Case vendita biglietti , mentre nella realt ne previsto uno appropriato: ottenimento autorizzazione. Analizzando il diagramma dei casi duso mostrati in fig. 2.9, si pu notare che, in primo luogo, gli attori possono essere suddivisi in due macrocategorie: quelli umani (Addetto allo sportello e Cliente) e quelli non umani (Credit Card Authority e Sistema di back office). La suddivisione degli attori umani del sistema in clienti e addetti allo sportello dovuta, come si vedr meglio nel diagramma di deployment, alle modalit con cui sar possibile fruire del sistema: attraverso qualsiasi stazione remota Internet e per mezzo di apposite postazioni ubicate nelle varie biglietterie.

UML e ingegneria del software: dalla teoria alla pratica

27

Figura 2.9 Diagramma dei casi duso: overview delle funzioni del sistema.

Consultazione calendario spettacoli

Vendita biglietti

Utente
Validazione utente

Credit Card Authority

Registrazione cliente

Addetto Sportello

Cliente

Aggiorna profilo cliente

Invio dati biglietto

Invio nuovo calendario

Aggiornamento dati calendario

Sistema di back-office

Produzione dati statistici

Le direttive Object Oriented consigliano, qualora possibile, di inserire attori, eventualmente astratti, atti a raggruppare il comportamento comune di altri attori

In questo contesto ci si traduce con laggiunta di un attore astratto, denominato genericamente Utente, specializzato dai due attori concreti: Addetto allo sportello e Cliente. Dallanalisi degli attori non umani, si pu notare che: lacquisto on-line di biglietti fruibile solo ai possessori di carta di credito e le relative transazioni sono subordinate allautorizzazione fornita da apposito sistema: Credit Card Authority;

28

Capitolo 2. UML: struttura, organizzazione, utilizzo

il sistema rappresenta una sorta di front office, mentre tutte le attivit di contabilit, amministrative, ecc. vengono effettuate da apposito sistema: Sistema di back office (BCS). I due sistemi dialogano tra loro attraverso invio di opportuni messaggi. Per esempio il BCS invia messaggi contenenti aggiornamenti relativi ai calendari degli spettacoli e riceve quelli relativi ai biglietti venduti. In fig. 2.10 viene riportato lo Use Case Diagram relativo alla vendita dei biglietti teatrali.

Una delle leggi non scritte, ma applicate nella pratica da tutti gli utilizzatori dello UML nota come legge del 7. Si tratta del consiglio, proveniente direttamente da studi di psicologia realtivi alla capacit di concentrazione e comprensione, che propone di limitare il numero massimo degli elementi presenti in ogni diagramma a 7 unit.

In questo caso non stata rispettata per semplici motivi legati alla necessit di presentare un unico diagramma e di presentarlo in un contesto organico. Sebbene gli Use Case Diagram verranno presentati in dettaglio nei prossimi due capitoli, ne viene comunque fornita la chiave di lettura. Le frecce tratteggiate che uniscono i vari casi duso rappresentano relazioni di include ed extend. Si tratta di relazioni molto dibattute che verranno argomentate dettagliatamente nellapposita sede. Per ora basti considerare che uninclusione ha un significato del tutto equivalente a una invocazione di procedura effettuata in un programma scritto in un qualsiasi linguaggio di programmazione. Ad un certo punto dellesecuzione di un caso duso compare la richiesta di inclusione di un altro incluso, quindi il flusso passa a questo ultimo che viene eseguito completamente e quindi il controllo ritorna allo Use Case chiamante. Per esempio la relazione di inclusione che lega il caso duso seleziona posto, a quello di aggiorna mappa disponibilit, sancisce che la funzione di selezione del posto, durante la propria esecuzione, eseguir un aggiornamento della mappa delle disponibilit dei posti per il determinato spettacolo prescelto. La relazione di extend molto simile ma pi potente: possibile associarvi unespressione booleana che deve essere vera per abilitare lesecuzione dello Use Case: in altre parole lesecuzione di un Use Case estendente subordinata al soddisfacimento di una condizione di guardia. Nel caso in cui tale espressione non sia presente (indipendentemente dal fatto che sia visualizzata o meno), ci equivale a una condizione sempre verificata. Tipicamente, le relazioni di extend vengono utilizzate per distinguere il comportamento opzionale da quello obbligatorio visualizzato per mezzo della relazione di include. Per esempio lo use case ottenimento autorizzazione, nel caso in cui lautorizzazione venga rifiutata, prevede lesecuzione della funzione di annullamento della vendita.

UML e ingegneria del software: dalla teoria alla pratica

29

Figura 2.10 Diagramma dei casi duso: dettaglio Use Case vendita biglietti.

consegna diretta

spedizione Sistema di back office notifica gravi anomalie cash pagamento

login erogazione biglietto Addetto sportello


extend [validazione non ancora avvenuta] extend

extend

vendita biglietti Utente


extend extend

extend

extend

carta di credito annulla vendita


extend [transazione annullata] include

selezione spettacolo Cliente selezione posto

include include

ottenimento autorizzazione

aggiorna mappa disponibilita'

Credict card authority

Anche se la direzione della freccia della relazione di dipendenza potrebbe risultare innaturale invece corretta: la relazione di extend prevede che la funzione utilizzata (come per esempio annulla vendita) venga incorporata nellesecuzione del caso duso invocante (ottenimento autorizzazione). Di seguito viene riportata la descrizione dellintero diagramma dei casi duso. Per esercizio, si consiglia al lettore, di provare a descriverlo per poi verificare la propria descrizione con quanto riportato di seguito. In primo luogo il caso duso di vendita biglietti prevede lautenticazione dellutente (login). Si tratta di un extend e quindi di un comportamento opzionale in quanto necessario eseguire il caso duso solo se lutente non sia gi stato precedentemente riconosciuto nellarco della stessa sessione. Poich presente lo Use Case di validazione utente, tutti gli altri diventano opzionali: se il riconoscimento fallisce, lesecuzione termina, e quindi tutte le altre funzioni non devono essere eseguite. Per questioni di leggibilit molte delle condizioni presenti nelle relazioni di estensione non sono state riportate.

30

Capitolo 2. UML: struttura, organizzazione, utilizzo

Nel caso in cui tutto proceda bene, lutente seleziona lo spettacolo desiderato e quindi i posti desiderati tra quelli disponibili. Come si pu notare fin da questi primi scampoli, i diagrammi dei casi duso, da soli, non sono in grado di fornire alcuna indicazione circa la dinamica dellesecuzione, lordine di esecuzione degli stessi casi duso, n tantomeno permettono di descrivere il comportamento che ciascuno di essi possiede. La selezione del posto include lesecuzione della funzione di aggiornamento della mappa di disponibilit: i posti prenotati non devono ovviamente poter essere selezionati da altri utenti. Selezionati anche i posti, necessario effettuare il fatidico pagamento. Nel caso la fruizione del sistema avvenga da uno sportello vendita biglietti, il pagamento pu avvenire o tramite contante o per mezzo di carta di credito, in tutti gli altri casi (da casa o attraverso apposito chiosco) solo per mezzo di carta di credito. Nel caso in cui il cliente opti per un pagamento tramite carta di credito necessario richiedere autorizzazione a un apposito sistema esterno, indicato genericamente con il nome di Credit Card Authority. Nel caso in cui lautorizzazione venga negata, necessario effettuare una sorta di roll-back: la vendita viene annullata e quindi i posti precedentemente prenotati vengono nuovamente resi disponibili.3 Effettuato con successo anche il pagamento, possibile effettuare lerogazione del biglietto. Nel caso dello sportello possibile fornirlo direttamente al cliente, eventualmente con opportune stampe su biglietti di formato predefinito (come avviene nelle agenzie di viaggi quando si acquista un biglietto aereo). Nel caso in cui il cliente stia fruendo del sistema attraverso le altre modalit, potr decidere se richiedere il recapito presso lindirizzo impostato o ritirarlo in uno degli uffici oppure direttamente al teatro. Nel caso in cui si verifichino dei problemi gravi prevista immediata notifica al sistema di back office. Si suppone che questo preveda opportuni meccanismi (workflow) in grado di tenere traccia dellaccaduto e di avvisare il personale umano ritenuto pi adatto a risolvere il problema occorso. I diagrammi dei casi duso illustrano la proiezione statica del sistema; quella dinamica invece affidata ad altri strumenti (come si vedr nei capitoli successivi dedicati agli Use Case), come per esempio i diagrammi di interazione, di attivit, i flussi di attivit od opportuni moduli.

Nel diagramma di figura lo Use Case ottenimento autorizzazione collegato allattore Credit Card

Authority per mezzo di unassociazione senza verso (entrambi gli oggetti sono navigabili). Sebbene ci non costituisca una grave mancanza e in questo contesto si fatto ricorso a tale espediente al fine di contenere il livello di complessit del grafico non costituisce nemmeno un buon disegno: in genere si preferisce dettagliare tale associazione per mezzo di pi connessioni dotate di verso. In effetti gli Use Case prevedono unicamente scambi di messaggi per cos dire asincroni. consigliabile dettagliare le associazioni con gli attori per una serie di motivi: evidenziare la direzione dellinterazione (chi fornisce informazioni) e quindi rendere i diagrammi pi chiari; evidenziare gli attori primari da quelli secondari, evidenziare ulteriori Use Case e in particolare i messaggi che li avviano, e cos via.

UML e ingegneria del software: dalla teoria alla pratica

31

Class Diagram
Il diagramma delle classi probabilmente una delle tipologie di diagramma pi note e affascinanti dello UML; se non altro anche quella che lautore adora maggiormente. Lutilizzo pi importante legato alla realizzazione del modello di disegno, il quale, una volta completato, rappresenta graficamente limplementazione del sistema eseguibile. Coloro che provengono dal mondo dellanalisi strutturata potranno notare la stretta somiglianza con i diagrammi Entit-Relazioni, di cui i Class Diagram rappresentano levoluzione Object Oriented (vi il fattore comportamentale). Ovviamente il passo non diretto: nella catena evolutiva dei diagrammi delle classi sono presenti diversi significativi anelli, quali per esempio il formalismo OMT e quello di Booch apprezzabile nel libro capostipite dei Design Pattern ([BIB04]). Obiettivo principale dei diagrammi delle classi visualizzare la proiezione statica del sistema: sono utilizzati per realizzare il modello ad oggetti del dominio e quello del business. Qualora si utilizzino Database Management System Object Oriented, i diagrammi delle classi ne rappresentano la struttura (schema logico) utilizzata per la persistenza del sistema (negli altri cassi necessario realizzare un mapping); inoltre supportano i diagrammi degli oggetti, del deployment (dispiegamento), gli Interaction ecc. Come suggerito dal nome, tali diagrammi sono costituiti da un insieme di classi, interfacce, collaborazioni e relazioni tra tali elementi. Esistono diverse tipologie di relazioni con le quali possibile associare classi, come, la dipendenza, lassociazione, la specializzazione, il raggruppamento in package e cos via (fig. 2.11). Il diagramma riportato nella figura rappresenta una possibile organizzazione in package di unopportuna sezione del modello ad oggetti del dominio. Probabilmente il livello di Figura 2.11 Organizzazione in package del modello del dominio.

StrutturaTeatro

ListiniPrezzi

InfoSpettacoli

Rappresentazioni

Biglietti

32

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.12 Frammento del Domain Model del sistema teatrale.


composite

Piantina
getZona() 1 possiede 1 e' relativo

ListinoPrezzi
codice : String descrizione : String getZoneTariffarie() getTariffeZonaDescr()

Settore
nome : String descrizione : String getPoltrone() getSettori()

e' suddiviso 0..*

Teatro
denominazione : String ragioneSociale :String getCalendario() getCalendari() 1 prevede 0..*

ApplTipologie

TemplateFasce

Zona

SottoSettore

1..* e' inerente 1

utilizza
a ott ad

1..* e' relativa 1..* applica

1..*

1 raggruppa 1..* 1..*

CalendarioSpettacoli
codice : String descrizione :String getSpettacolo() getSpettacoli() 1 formato 1..*

TemplateTariffe
codice : String descrizione : String ... 0..* utilizza colleziona

FasciaTariffaria
codice : String descrizione : String getTipologieTariffe() 1..*

Posto
numero : int

1..*

Spettacolo
codice : String titolo :String getRappresentazione() 1 1 1

Tariffa
importo : float prevista : boolean

TipologiaTariffa
descrizione : String

Biglietto
codice : String stato getStato()

e' provvisto

presenta

Rappresentazione
1..* data : Date orario : Time getBiglietto() getListinoPrezzi() dispone 1..*

InfoSpettacolo

granularit eccessivo, ossia alcuni package raggruppano non pi di un paio di classi e potrebbero essere tranquillamente inglobati in altri. In questo contesto si comunque deciso di mostrarli per poter meglio illustrare i formalismi dello UML. Questo approccio stato utilizzato in tutto il libro: elevata granularit a fini espositivi. Se, per ragioni di riusabilit del codice, opportuno seguire il principio di disaccoppiamento al livello delle classi, lo ancora di pi a livello dei package. Probabilmente pi importante poter riutilizzare interi package piuttosto che singole classi. Da notare che spesso non si parla pi di riusabilit del codice, bens di sostituibilit di opportuni componenti al fine di rendere pi semplice far rincorrere al sistema levoluzione del business del cliente. La mutua dipendenza esistente tra i package Biglietti e Rappresentazione non di certo un buon disegno e pertanto, nella fase di disegno, andrebbe disaccoppiata per mezzo dellintroduzione di opportune interfacce. Le razionalizzazioni dovrebbero essere introdotte con attenzione nei modelli relativi al dominio del problema il cui scopo principale rappresentare appunto il dominio del problema e cercare di ottenere riscontri dal

UML e ingegneria del software: dalla teoria alla pratica

33

cliente su quanto modellato. Le relazioni tra package mostrate in figura (frecce tratteggiate) illustrano le relative dipendenze: se un package A dipende da uno B, ci implica che modifiche a questultimo package (indipendente) si ripercuotono sul primo (dipendente). Per esempio una revisione dellorganizzazione interna del package dei ListiniPrezzi verosimilmente richiede una verifica di quello dei Biglietti. Nel diagramma di fig. 2.12 viene proposto un frammento di quello che potrebbe essere il Domain Object Model (modello ad oggetti del dominio). Questa particolare tipologia di modello ha alcune caratteristiche peculiari: sono presenti unicamente entit effettivamente esistenti nel mondo reale; nelle varie classi vengono riportati principalmente gli attributi ritenuti pi significativi, mentre linteresse per i metodi decisamente pi marginale. Il diagramma rappresentato risulta piuttosto interessante in quanto permette di illustrare buona parte del formalismo previsto dallo UML per i disegnare i diagrammi delle classi. Si proceda con lanalisi del diagramma a partire dalla classe Teatro, e in particolare si inizi con il considerare la relativa rappresentazione strutturale. Un Teatro dispone di una Piantina la cui unica istanza utilizzata come raggruppamento, ossia come punto

Figura 2.13 Frammento del diagramma delle classi relativo allutilizzo del Design Pattern Composite.
composite

Settore
nome : String descrizione : String getPoltrone() getSettori()

e' suddiviso 0..*

Zona

SottoSettore

34

Capitolo 2. UML: struttura, organizzazione, utilizzo

di partenza della struttura. Questultima rappresentata attraverso un celebre Design Pattern denominato Composite (fig. 2.13). Brevemente, si tratta di una soluzione che permette di modellare complessi grafi ad albero (intrinsecamente ricorsivi) in cui compaiono relazioni gerarchiche tuttoparte. Nel contesto oggetto di studio la foglia dellalbero (nodo senza figli, elemento parte della relazione gerarchica) rappresentato dalla Zona, mentre i nodi con figli sono rappresentati dai SottoSettori. Quindi, in accordo al diagramma, la Zona lelemento pi semplice della struttura, quello che raggruppa direttamente i posti. Il Composite in questione permette di asserire, per esempio, che la struttura del teatro costituita da livelli (istanze della classe SottoSettore) che a loro volta sono suddivisi in altri SottoSettori (centrale, centrale-est, est, centrale-ovest e ovest) suddivisi per Zone (palchetto centrale, palchetto centrale di destra, palchetto centrale di sinistra, ecc.). Si tratta ovviamente di un caso e nulla vieta di disporre di diverse configurazioni, come per esempio che il teatro possa essere diviso in Livelli e Platea (primo livello dellalbero) e quindi in Zone. In un successivo paragrafo viene fornita una visualizzazione di quanto esposto attraverso lutilizzo dei diagrammi degli oggetti (fig. 2.17). Come si pu notare, lutilizzo del pattern Composite ha permesso di risolvere elegantemente ed efficacemente una struttura altres complessa, con poco sforzo intellettivo: sufficiente ricercare nel relativo catalogo una soluzione generale al proprio problema e quindi adattarla alle proprie necessit. Lorganizzazione gerarchica, e in particolare il raggruppamento dei Posti per Zone, particolarmente importante in quanto permette di assegnare opportunamente le Tariffe: lecito attendersi che un palco centrale abbia una tariffa leggermente diversa da un posto nel loggione. Dallanalisi del diagramma in figura, si pu notare che spesso le classi vengono interconnesse da una particolare associazione, detta aggregazione, visualizzata per mezzo di un rombo vuoto posto ad una estremit. La relazione di aggregazione specifica una relazione binaria, detta whole-part (tuttoparte) tra un elemento detto aggregato (il tutto) e uno detto costituente (la parte). Nella rappresentazione grafica il rombo viene collocato nellestremit relativa allentit tutto. La peculiarit rispetto a una relazione di associazione semplice la semantica: laggregazione sancisce una relazione decisamente pi forte tra le parti associate. Tornando alla classe Teatro , essa pu essere collegata a n istanze della classe CalendariSpettacoli: si supponga che lo stesso teatro possa essere utilizzato per diverse tipologie di spettacoli: rappresentazioni teatrali, concerti, show ecc., oppure che gli stessi possano essere divisi per stagioni: il calendario invernale, quello estivo e cos via. Ogni calendario ovviamente costituito da un insieme di Spettacoli (La Tosca, La Traviata, La Locandiera, il concerto dei Vaia Con Dios, lo show Barracuda di D. Luttazzi) le cui informazioni salienti sono riportate in unapposita classe denominata

UML e ingegneria del software: dalla teoria alla pratica

35

Figura 2.14 Frammento del diagramma della classi relativo a Spettacoli e Rappresentazioni.

Piantina
getZona() 1 possiede 1

Teatro
denominazione : String ragioneSociale :String getCalendario() getCalendari() 1 prevede 0..*

CalendarioSpettacoli
codice : String descrizione :String getSpettacolo() getSpettacoli() 1 formato 1..*

Spettacolo
codice : String titolo :String getRappresentazione() 1 1 presenta 1

Rappresentazione
data : Date 1..* orario : Time getBiglietto() getListinoPrezzi()

InfoSpettacolo

36

Capitolo 2. UML: struttura, organizzazione, utilizzo

InfoSpettacolo. Da notare che volendo descrivere propriamente queste informazioni

sarebbe stato necessario realizzare un apposito modello: per questo nel diagramma dei package mostrato un apposito package denominato InfoSpettacoli. In questo caso si deciso di trascurarlo per non complicare ulteriormente la spiegazione.

Figura 2.15 Frammento del diagramma della classi relativo ai listini prezzi.

Zona

1 raggruppa 1..*

Posto
numero : int

1..*

TipologiaTariffa
descrizione : String

Biglietto
codice : String stato getStato()

Rappresentazione
data : Date orario : Time getBiglietto() getListinoPrezzi() dispone 0..*

UML e ingegneria del software: dalla teoria alla pratica

37

Figura 2.16 Frammento del diagramma delle classi relativo ai biglietti e alle relative tariffe.

Zona

1 raggruppa 1..*

Posto
numero : int

1..*

TipologiaTariffa
descrizione : String

Biglietto
codice : String stato getStato()

Rappresentazione
data : Date orario : Time getBiglietto() getListinoPrezzi() dispone 0..*

In prima analisi si potrebbe distinguere la tipologia di spettacolo (rappresentazione teatrale, concerto, show, ecc.) verosimilmente attraverso una relazione di generalizzazione con tante specializzazioni quante sono le tipologie. Poi si sarebbero dovute formalizzare informazioni come: autori o compositori, direttori o registi o coreografi, gruppo teatrale o orchestra sinfonica o corpo di ballo, ecc. Tipicamente, per ogni Spettacolo possono essere previste diverse Rappresentazioni.

38

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.17 Esempio di diagrammi degli oggetti: frammento di unipotetica struttura di un teatro.

:Piantina

Platea :SottoSettore

PrimeFile :SottoSettore PrimaFila :Zona SecondaFila :Zona RestantiPrimeFile :Zona FileCentrali :SottoSettore ZonaCA :Zona ZonaCB :Zona FileFondo :SottoSettore ZonaFondo :Zona Piano1 :SottoSettore

. . .
Loggione :SottoSettore Centrale :Zona CntOvst :Zona CntEst :Zona Ovst :Zona Est :Zona

A questo punto si giunge alle informazioni relative ai listini prezzi: un Teatro ne pu prevedere diversi che possono differenziarsi sia per questioni lucrative, sia per struttura. Lintento principale seguito per la modellazione di questa sezione stato realizzare un modello abbastanza generale da potersi applicare al maggior numero di casi possibili si ricordi che si sta realizzando un prodotto senza per complicare eccessivamente la struttura.

UML e ingegneria del software: dalla teoria alla pratica

39

Un altro elemento preso in esame leffettiva analisi della realt quella dei teatri londinesi dove in particolare si pu notare che la struttura dei tariffari tende a rimanere fissa (tariffa extra lusso da applicarsi a palchetti centrali e primissime file della platea, tariffa normale per la restante parte della platea, tariffa scontata per il loggione, ecc.) cos come gli stessi prezzi tendono a prevedere poche alternative (tariffa di lusso equivalente a 150 sterline per spettacoli pi importanti, 100 per quelli medi, 75 per quelli meno blasonati o in periodi dellanno meno richiesti, ecc.). Se la seguente trattazione dovesse risultare oscura, possibile far riferimento ai paragrafi successivi e alla fig. 2.18), in cui viene riportato un esempio di listino. In prima analisi un listino prezzi pu essere suddiviso in diverse fasce tariffarie (per esempio: Imperiale, Lusso, Normale, Economica, ecc.). Onde evitare di produrre un insieme di oggetti slegati e di dover ogni volta ridefinire tale struttura si introdotta la classe TemplateFasce. La considerazione che i diversi listini non dovrebbero differire gli uni dagli altri di molto; pertanto, in una situazione a regime, ci si dovrebbe ridurre a riutilizzare due o tre modelli. La classe TemplateFasce pu essere associata a diverse fasce tariffarie. Lutente, per ogni listino da inserire, potrebbe selezionare un template tra quelli esistenti oppure realizzarne uno nuovo, selezionando le fasce tariffarie di interesse. Figura 2.18 Esempio di diagrammi degli oggetti: illustrazione dei listini prezzi.

AS :ListinoPrezzi Standard :TemplateFasce

BS :ListinoPrezzi

Lusso :FasciaTariffaria

Ordinaria :FasciaTariffaria

Super :FasciaTariffaria

Economica :FasciaTariffaria

ASL :ApplTipologie

BSL :ApplTipologie

ASS :ApplTipologie

TLusso :TemplateTariffe

TSuper :TemplateTariffe

Scontata :TipologiaTariffa

Anziani :TipologiaTariffa

Piena :TipologiaTariffa

L95 :Tariffa

L60 :Tariffa

L80 :Tariffa

L50 :Tariffa

L40 :Tariffa

L90 :Tariffa

L22 :Tariffa

40

Capitolo 2. UML: struttura, organizzazione, utilizzo

Limportanza delle fasce risiede nella loro associazione (n a n) con le zone: in particolare ogni zona, nel contesto di uno stesso listino, viene associata a una FasciaTariffaria, mentre, in generale, pu essere associata a diverse: una per ogni listino appunto. Questo il meccanismo alla base del tariffario: una zona applica una specifica fascia tariffaria, la quale, a sua volta, pu essere associata a diverse zone. Pertanto, dopo aver dato luogo alle varie associazioni (ZonaFasciaTariffaria) e aver quotato le varie fasce, anche il listino risulta quotato, ossia si sono quotate tutte le zone e quindi i posti in esse presenti. Da notare come il vincolo molto importante per cui una zona pu prevedere una sola FasciaTariffaria allinterno di uno stesso listino non si desume dalla lettura del diagramma; sarebbe pertanto necessario riportarlo esplicitamente, per mezzo dellOCL (Object Constraint Language). La suddivisione del listino in fasce tariffarie non risulta ancora sufficiente: necessario tenere in considerazione le varie tariffe applicabili: tariffa piena, scontata, anziani, studenti ecc. Nuovamente queste tipologie vengono raggruppate in opportuni template, definiti dallassociazione della classe TemplateTariffe con la classe TipologiaTariffa. Analogamente al caso precedente, si suppone che, se lutente prevede un certo numero di tipologie, tender a riapplicare le stesse con qualche variazione eventualmente evidenziabile per mezzo di ulteriori template. Quindi, una volta definite tre o quattro versioni del template tariffe, non si dovrebbe aver pi bisogno di definirne altre. I vari oggetti TemplateTariffe dipendono sia dal listino di riferimento, sia dalla fascia tariffaria, o meglio ogni listino deve prevedere, per ogni FasciaTariffaria, unapposita istanza della classe TemplateTariffa da associarvi. A tal fine stata introdotta la classe ApplTipologie.4 Sebbene non esista nella struttura del listino unassociazione diretta tra le classi TemplateFasce e TemplateTariffa necessario definire tale legame in funzione

Nel disegno la classe ApplTipologie non associata direttamente a unaltra, bens a una relazione tra due classi

e pertanto un esempio di Association Class (classe associazione). Da un punto di vista implementativo, chiaramente, non possibile associare una classe a una relazione. Si tenga presente che, in ultima analisi, unassociazione lesportazione e/o limportanzione di un indirizzo di memoria di un oggetto (pardon di un reference) in un particolare attributo di un altro oggetto. La sua realizzazione, tipicamente, prevede che la classe associazione contenga i riferimenti a entrambe le classi che darebbero vita allassociazione da cui dipende. Nel caso oggetto di studio ApplTipologie, dovrebbe memorizzare i reference degli oggetti istanza delle classi ListinoPrezzi e FasciaTariffaria. La domanda potrebbe essere la seguente: perch allora non modellare la classe associazione direttamente con due associazioni alle classi da cui dipende?. La risposta semplice e risiede nella semantica: la classe associazione sancisce che, se loggetto istanza di una delle due classi a cui associata listanza della classe associazione viene distrutto o deferenziata in caso si consideri Java anche la classe associazione deve essere distrutta di conseguenza. Con due associazioni a due classi non si evincerebbe questa regola a meno di non inserire esplicitamente appositi vincoli. Questi argomenti verranno debitamente trattati nel capitolo relativo ai Class Diagram.

UML e ingegneria del software: dalla teoria alla pratica

41

del listino che si sta considerando stata definita unassociazione di default tra le due. Ci semplifica linserimento di nuovi listini: dovendone introdurre uno nuovo, per ci che concerne la struttura, linterazione con lutente potrebbe essere limitata alla conferma della struttura di default proposta. Lattribuzione delle tariffe vere e proprie dipende da tre fattori: il listino prezzi di riferimento (per esempio listino rappresentazioni pi importanti), la fascia tariffaria (per esempio economica), la tipologia di tariffa (per esempio tariffa studenti). Poich la classe ApplTipologie gi dipende dal listino e dalla relativa suddivisione in fasce tariffarie, sufficiente asserire che gli oggetti Tariffa dipendono dallassociazione delle istanze della classe ApplTipologie con quelle della classe TipologiaTariffa. Cos si eliminata al necessit di dover ricorrere a una relazione tra quattro classi. Nella classe Tariffa stato introdotto lattributo prevista il quale con il suo valore permette di discriminare i casi in cui una particolare tipologia deve essere applicata o meno. Lidea alla base di evitare di dover ridefinire tutta una struttura solo perch una particolare Tipologia in un particolare contesto non debba essere applicata. Per ci che riguarda la classe Biglietti, si pu notare che questi appartengono a unopportuna MappaDisponibilit, associata a una specifica Rappresentazione e, una volta acquistati, fanno riferimento a una particolare TipologiaTariffa. Per esempio il biglietto stato acquistato da uno studente e quindi la tariffa applicata la relativa. In questo contesto i Biglietti esistono indipendentemente dal fatto che siano stati acquistati o meno (non a caso esiste lattributo Stato), il che dovrebbe essere abbastanza rispondente alla realt. La relazione con la TipologiaTariffa viene instaurata allatto della vendita. Naturalmente quando si acquista un biglietto lo si fa in riferimento a una particolare Rappresentazione, e per un posto appartenente a una ben specifica Zona. Ecco ancora una volta che la classe Biglietto rappresenta una classe associazione e dipende appunto dal legame tra la classe Rappresentazione e quella Posto. Quindi, ricapitolando, per ogni Posto e per ogni Rappresentazione prevista unapposita istanza della classe Biglietto che, una volta acquistato, ha una specifica Tariffa applicata.

Object Diagram
I diagrammi degli oggetti rappresentano una variante dei diagrammi delle classi, tanto che anche la notazione utilizzata pressoch equivalente con le sole differenze che i nomi degli oggetti vengono sottolineati e le relazioni vengono dettagliate. Gli Objects Diagrams mostrano un numero di oggetti istanze delle classi con i relativi legami riportati in modo esplicito. Per esempio, se nel diagramma delle classi una classe A associata con n istanze della classe B, nel diagramma degli oggetti vengono visualizzati un opportuno oggetto istanza della classe A ed esplicitamente tutti i legami che lo connettono con gli altrettanti oggetti istanza della classe B.

42

Capitolo 2. UML: struttura, organizzazione, utilizzo

Anche questa tipologia di diagramma si occupa della proiezione statica del sistema e mostra un ipotetico esempio di un diagramma delle classi. Si tratta della famosa diapositiva scattata a un istante di tempo preciso, riportante un ipotetico stato di esecuzione evidenziato dagli oggetti presenti in memoria e dal relativo stato.

Pertanto mentre un diagramma delle classi sempre valido, un diagramma degli oggetti rappresenta una possibile istantanea del sistema valida in un istante di tempo ben preciso. I diagrammi degli oggetti vengono utilizzati essenzialmente per dettagliare le relazioni presenti in diagrammi delle classi ritenute poco chiare o particolarmente complicate: ci permette di verificare la correttezza logica dei diagrammi delle classi realizzati. Qualora non si riescano a concretizzare formalmente determinate relazioni o non si abbia la certezza che quanto modellato sia effettivamente ci che si desiderava, consigliabile realizzare un paio di diagrammi degli oggetti al fine di visualizzare come, in una situazione a regime, i vari oggetti siano relazionati gli uni agli altri.

Lutilizzo dei diagrammi degli oggetti nel corso di una modellazione tipicamente limitato ma non per questo non importante: talune volte da solo pi esplicativo e preciso di molte linee di commento di un Class Diagram. Il problema? La maggior parte dei tool commerciali (al momento in cui viene scritto il presente libro) sembrerebbe sottovalutarne limportanza. Per realizzare i diagrammi degli oggetti bisogna ricorrere sempre a qualche artificio, come simularlo attraverso un Class Diagram o un Collaboration. Tipicamente la soluzione migliore realizzare i diagrammi degli oggetti per mezzo dei diagrammi di collaborazione. Il diagramma riportato nella fig. 2.17 mostra una possibile organizzazione della struttura di un teatro. In una situazione reale, questa dovrebbe essere definita, attraverso un opportuno tool, allatto della configurazione del sistema e memorizzata in un database. Il sistema allatto dellavvio dovrebbe provvedere a caricarla in memoria. Il diagramma visualizza una ipotetica struttura di un teatro attraverso un opportuno grafo ad albero e quindi dimostra lefficacia del pattern Composite. Loggetto radice dellintero albero unistanza della classe Piantina, alla quale si ritenuto non necessario attribuire un nome in quanto ne esiste una sola istanza e quindi non si corre il rischio di confusione. I nodi di primo livello sono Platea, Piano1, Piano2, e cos via fino a Loggione. Si tratta chiaramente di istanze della classe SottoSettore, specializzazione di Settore. Per questione di rappresentazione grafica, non viene data la descrizione di tutti gli elementi. La Platea, a sua volta, viene suddivisa in altri settori: PrimeFile, FileCentrali e FilediFondo ancora istanze della classe SottoSettore.

UML e ingegneria del software: dalla teoria alla pratica

43

Il settore PrimeFile , infine, suddiviso in PrimaFila , SecondaFila e RestantiPrimeFile istanze della classe Zona che a sua volta una specializzazione del Settore. Per il Loggione invece stata decisa unorganizzazione diversa: si passa dal Settore direttamente alle Zone senza SottoSettori intermedi. Il diagramma degli oggetti proposto in fig. 2.18, mostra una porzione di due ipotetitici listini prezzi applicabili al Teatro, denominati rispettivamente Alta Stagione (AS) e Bassa Stagione (BS). La notazione grafica utilizzata, o meglio quella relativa ai colori, prevede: testo e bordi rossi per gli elementi dipendenti dal listino AS; testo e bordi blu per gli elementi dipendenti dal listino BS; testo e bordi neri per gli elementi indipendenti dai listini. Come si pu notare, entrambi applicano lo stesso template previsto per la suddivisione in fasce tariffarie, denominato Standard e composto dagli oggetti istanza della classe FasciaTariffaria: Super, Lusso, Ordinaria e Scontata. A ciascuno di questi oggetti si pu associare un particolare oggetto TemplateTariffe in funzione anche del listino che si prende in considerazione. A tal fine prevista la classe (associazione) ApplTipologie che appunto associa un listino a un opportuno TemplateTariffe. Nel caso in esame, entrambi i listini applicano, per le fasce tariffarie Super e Lusso, gli stessi template, rispettivamente TLusso e TSuper. La prima prevede lapplicazione delle tipologie di tariffe Piena, Scontata e Anziani, mentre la seconda solamente Piena.

Interaction Diagrams
I diagrammi di sequenza e collaborazione detti anche di interazione in quanto mostrano le interazioni tra oggetti che costituiscono il sistema e/o con attori esterni allo stesso vengono utilizzati per modellare il comportamento dinamico del sistema. I due diagrammi risultano molto simili e si pu passare agevolmente dalluna allaltra rappresentazione (isomorfi). Alcuni tool, tra cui Rational Rose, permettono, dato un Sequence Diagram, di generare lequivalente Collaboration. Sequence e Collaboration si differenziano per via dellaspetto dellinterazione a cui conferiscono maggior rilievo: i diagrammi di sequenza focalizzano lattenzione sullordine temporale dello scambio di messaggi, i diagrammi di collaborazione mettono in risalto lorganizzazione degli oggetti che si scambiano i messaggi. Possono essere utilizzati con diversi livelli di astrazione in funzione dellutilizzo che se ne vuole fare. Li si utilizza nella Use Cases View per modellarne la proiezione dinamica, ossia per fornire lillustrazione grafica degli scenari (esempi di utilizzo dei casi duso). In tale conte-

44

Capitolo 2. UML: struttura, organizzazione, utilizzo

sto il livello di astrazione deve essere necessariamente elevato: ci non significa che si ignorano i dettagli del funzionamento del processo. Semplicemente lastrazione relativa alla mancanza di particolari a carattere pi implementativo, come per esempio i metodi di una classe da invocare. In questo contesto i diagrammi di sequenza risultano particolarmente utili, mentre quelli di collaborazione lo sono molto meno: verrebbero visualizzati due/tre oggetti con molte connessioni. I diagrammi di interazione vengono utilizzati anche in fase di modellazione (livello di astrazione molto basso) per documentare lutilizzo di classi, per illustrare come funzionalit complesse siano realizzate per mezzo dellinterazione (scambio di messaggi) tra pi oggetti, e cos via. In fig. 2.19 viene riportato il Sequence Diagram che illustra linterazione dinamica tra un cliente e il distributore automatico. Il grande vantaggio offerto, come si riscontra facilmente, legato alla semplicit di lettura e comprensione; pertanto il diagramma di sequenza si presta a essere utilizzato per illustrare dei comportamenti da sottoporre allattenzione del cliente. In tal caso i diagrammi devono possedere un elevato livello di astrazione. Come si vedr meglio nel prossimo capitolo, lo scenario illustrato viene comunemente denominato main success scenario (scenario principale di successo) in quanto illustra uninterazione in cui tutto magicamente funziona bene e non si verificano errori o eccezioni di sorta. Per esempio le varie verifiche di disponibilit non danno mai esito negativo, cos come la richiesta di autorizzazione della transazione viene sempre accordata ecc. Per la visualizzazione delle anomalie e la relativa gestione, a meno di casi semplici, si preferisce realizzare altri diagrammi. Lobiettivo evitare di realizzare diagrammi confusi e quindi meno leggibili: ci ne invaliderebbe la peculiarit. Per, se da un lato disporre di una serie di diagrammi permette di mantenere gli stessi semplici e lineari, dallaltro crea problemi nella manutenzione: spesso una modifica al flusso descritto nel main scenario implica laggiornamento di tutti i diagrammi. Questo uno dei motivi per cui spesso gli scenari vengono descritti attraverso opportuni moduli di testo. Nel caso dei diagrammi di sequenza, nella prima riga vengono riportati i gli oggetti che partecipano allinterazione. Da ciascuno di essi parte una linea tratteggiata verticale che rappresenta il trascorrere del tempo, mentre le varie frecce rappresentano lo scambio esplicito dei messaggi. Come si vedr nellapposito capitolo esistono diverse tipologie di messaggio. Una prima obiezione che si potrebbe fare la seguente : Come possibile realizzare diagrammi di interazione, i cui elementi principali sono gli oggetti (istanze di classi) nella vista dei casi duso? In altre parole, se concetti come classi e oggetti sono oggetto di studio

UML e ingegneria del software: dalla teoria alla pratica

45

Figura 2.19 Sequence diagram.

:Sistema :Utente
1: Esegue funzione acquisto biglietti 3: Visualizza lista calendari spettacoli 4: Seleziona calendario spettacolo desiderato 5: Reperisce elenco spettacoli 2: Reperisce lista calendari spettacoli

:Credit Card Authority

6: Visualizza elenco spettacoli 7: Seleziona spettacolo desiderato 8: Reperisce inform azioni spettacolo 9: Visualizza inform azioni spettacolo 10: Conferma seleziona spettacolo 12: Visualizza elenco rappresentazioni 13: Seleziona rappresentazione desiderata 14:Genera m appa disponibilita' con prezzario 11: Reperisce elenco rappresentazioni

15: Visualizza m appa 16: Seleziona settori desiderati 18: Visualizza m odulo dettaglio settori, disponibilita', tariffe 19: Seleziona posti desiderati 21: Visualizza somm ario posti/tariffe 22: Seleziona tariffa e conferm a 23: Visualizza m odulo richiesta dati transazione 24: Imposta dati carta di credito 25: Verifica correttezza dati impostati 26: Riserva biglietti 28: Verifica transazione L'utente seleziona la tariffa in quanto potrebbe appartenere ad una delle categorie per le quali sono previste tariffe speciali (studenti, anziani, vip, ecc.) 20: Verifica disponibilita' 17:Determ ina disponibilita' settori

BUSINESS RULE: la prenotazione fisica avviene solo dopo aver validato i dati relativi alla transazione (prima di richiedere l'autorizzazione della transazione)

27: Richiede autorizzazione transazione

29: Autorizza transazione 30: Visualizza m odulo richiesta istruzioni di recapito 31: Imposta dati istruzioni di recapito 32: Mem orizza dati

33: Com unica conferm a transazione

46

Capitolo 2. UML: struttura, organizzazione, utilizzo

di fasi successive del processo di sviluppo del software (analisi, disegno), come possibile prevederli gi in durante lanalisi dei requisiti utente?. Le risposte possono essere diverse. Una prima soluzione consiste nellindicare globalmente il sistema attraverso un unico oggetto (come fatto nel diagramma in figura). Unaltra alternativa utilizzare la propria esperienza cominciando a dare una sbirciatina allinterno del sistema individuando i primi macrosottosistemi. Unultima alternativa consiste nel cominciare a realizzare un diagramma delle classi concettuale, ad elevato livello di astrazione, fin dalle primissime fasi del processo di sviluppo. Nella fase di disegno poi si provveder a rendere tale diagramma sempre pi concreto fino a farlo diventare la rappresentazione del codice del sistema. Il diagramma di fig. 2.20 rappresenta un esempio di utilizzo del sequence diagram nel modello del disegno: mostra come gli oggetti istanze delle classi collaborino tra loro per realizzare un determinato servizio, in questo caso la verifica della disponibilit di un posto per una specifica rappresentazione. Nel diagramma si considerato che, nel modello di disegno, esiste una classe, denominata TicketingServer, in grado di nascondere i dettagli della navigazione delle varie classi del modello. Si tratta, nuovamente, di un Design Pattern denominato Faade. In sostanza, ogniqualvolta diverse classi necessitino di navigare attraverso altre classi di uno o pi package, al fine di evitare uneccessiva complicazione delle varie relazioni, si preferisce inserire unapposita classe schermante in grado Figura 2.20 Sequence Diagram a livello del modello di disegno.
GenericClient :TicketingServer :Teatro :CalendarioSpettacoli :Spettacolo :Rappresentazione :Biglietto

1: getDisponibilita()

2: getTeatro()

3: getCalendario()

4: getSpettacolo()

5: getRappresentazione()

6: getBiglietto()

7: getStato()

UML e ingegneria del software: dalla teoria alla pratica

47

Figura 2.21 Collaboration Diagram della funzione getDisponibilit.

GenericClient
1. getDisponibilita() 2. getTeatro()

:Teatro
3. getCalendario()

:TicketingServer
7. getStato() 4. getSpettacolo()

:Biglietto
6. getBiglietto()

:CalendarioSpettacoli
5. getRappresentazione()

:Rappresentazione

:Spettacolo

di fornire i vari servizi, nascondendo i vari dettagli alle diverse classi client. Tra laltro ci particolarmente utile in quanto, qualora i dettagli della navigazione dovessero variare, sufficiente modificare ununica classe. Da notare che loggetto che usufruisce del servizio, GenericClient, essendo esterno al sottosistema considerato poteva essere indicato come un attore. Ancora una volta il diagramma piuttosto semplice da leggere: le uniche differenze sono costituite dalle frecce piene che rappresentano delle invocazioni sincrone, tipiche invocazioni di metodi di classi. Si consideri il diagramma delle classi di fig. 2.12. In primo luogo si suppone che la classe TicketingServer sia associata alla classe Teatro, il cui reperimento del riferimento avviene invocando un proprio metodo. Nel caso ci si trovi in una gestione multiteatro sarebbe necessario specificare il codice del teatro desiderato. A questo punto, tramite codice del calendario degli spettacoli desiderato, si reperisce la relativa istanza dalla quale, sempre tramite codice, possibile selezionare listanza dello Spettacolo richiesto. A questo punto, tramite la data, possibile selezionare la Rappresentazione, da cui, per mezzo del numero del posto, possibile reperire il relativo biglietto e quindi verificarne la disponibilit.

48

Capitolo 2. UML: struttura, organizzazione, utilizzo

Riassumendo, il metodo getDisponibilit() dovrebbe prevedere i seguenti parametri: eventualmente codice teatro, codice calendario spettacoli, codice spettacolo, data rappresentazione e numero del posto. La presenza dei vari codici non dovrebbe preoccupare pi di tanto: verrebbero nascosti dallapposita interfaccia utente. Il Collaboration Diagram riportato in fig. 2.21 illustra la stessa funzionalit del precedente Sequence Diagram (getDisponibilit; possibile passare dalluno allaltro molto agevolmente), solo che in questo caso laspetto a cui viene conferita maggiore enfasi la sequenzialit dei messaggi nel contesto dellorganizzazione strutturale degli oggetti. Per questa caratteristica, e per la capacit di mostrare senza grandi problemi molti oggetti nellambito di uno stesso diagramma senza disordinare il diagramma, i Collaboration Diagram vengono preferiti in fase di disegno. Il diagramma di collaborazione presentato in fig. 2.22 non presenta grosse novit. Lunico elemento da evidenziare che il metodo dovrebbe ritornare, nel caso di successo, un array di oggetti istanze di una classe che si potrebbe indicare con il nome TariffeDescritte. Essa dovrebbe possedere come attributi sia il codice e la descrizione della tipologia della tariffa (presente nella classe FasciaTariffaria), sia la tariffa stessa (attributo della classe Tariffa).

Figura 2.22 Collaboration Diagram della funzione getTariffe().

GenericClient
1. getTariffeZona() 2. getTeatro()

:Teatro
3. getCalendario()

4. getSpettacolo() 8. getListino()

:TicketingServer

:CalendarioSpettacoli

9. getTariffeZonaDescr() 7. getZona()

6. getPiantina()

3. getRappresentazione()

:ListinoPrezzi

:Piantina

:Spettacolo

UML e ingegneria del software: dalla teoria alla pratica

49

Figura 2.23 Statechart Diagram: ciclo di vita di un biglietto.

Annullato

tempo limite scaduto

Disponibile
do / verifica data e ora

[timer = timeout]

autorizazzione pagamento negata

prenotazione

annulla acquisto

Prenotato
entry / reset(Timer) do / inc(Timer) transazione acquisto confermata

Acquistato

Statechart Diagrams
I diagrammi di stato essenzialmente descrivono automi a stati finiti e pertanto sono costituiti da un insieme di stati, transazioni tra di essi, eventi e attivit. Ogni stato rappresenta un periodo di tempo ben delimitato della vita di un oggetto durante il quale loggetto stesso soddisfa precise condizioni. I diagrammi degli stati pertanto, modellando la possibile storia della vita di un oggetto, vengono utilizzati principalmente come completamento della descrizione delle classi: concorrono a modellarne il comportamento dinamico. Nulla vieta di utilizzarli anche nelle primissime fasi del processo di sviluppo del software al fine di documentare levoluzione attraverso i relativi stati di macrooggetti, con laccorgimento di mantenere elevato il livello di astrazione. Chiaramente ha senso utilizzare i diagrammi degli stati per illustrare in dettaglio il comportamento delle sole classi i cui oggetti possono transitare per ben definito insieme di stati. Per esempio se un particolare oggetto un biglietto per un preciso spettacolo, esso pu trovarsi nello stato Disponibile (non stato ancora acquistato o prenotato e lo spettacolo non andato in scena), Prenotato (il biglietto stato riservato ed il tempo a dispo-

50

Capitolo 2. UML: struttura, organizzazione, utilizzo

sizione per acquistarlo non scaduto), Acquistato (limporto del biglietto stato versato) e Annullato (il tempo limite per lacquisto trascorso). Come si pu notare esistono due tipi di transazioni: provocate dallesterno (per esempio il Credit Card Authority autorizza la transazione di acquisto e quindi provoca la transizione del biglietto nello stato Acquistato); che scaturiscono internamente (scade il tempo a disposizione per poter acquistare il biglietto, e lo stesso transita nello stato di Annullato). Il diagramma di fig. 2.23 risulta piuttosto comprensibile: unica nota che nei vari stati possono essere descritte esplicitamente attivit da compiersi allatto dellentrata nello stato (entry), durante la permanenza (do) ed in uscita (exit). Per esempio si potrebbe avere la necessit di notificare luscita di un oggetto da un ben preciso stato. In quel caso si potrebbe associare la comunicazione di notifica alluscita dallo stato (exit). Chiaramente i diagrammi degli stati prevedono altri elementi che verranno descritti in dettaglio nel relativo capitolo.

Activity Diagram
Gli Activity Diagram (diagrammi delle attivit) mostrano levoluzione di un flusso di attivit, ognuna delle quali definita come unesecuzione continua non atomica allinterno di uno stato: un diagramma di attivit mostra una procedura o un workflow. Si tratta di una variante dei diagrammi di stato (mostrati nel paragrafo precedente) in cui ogni stato rappresenta lesecuzione di unopportuna attivit e la transizione da uno stato a quello successivo generata dal completamento dellattivit stessa (trigger interno). Gli stati evidenziati negli Activity Diagram sono essenzialmente di due tipologie: Activity State (stati di attivit) e Action State (stati di azione). I primi consistono in stati che eseguono una computazione la quale, una volta ultimata, genera la transizione allo stato successivo; uno stato di azione, invece, uno stato atomico (ossia non pu essere interrotto).

I diagrammi delle attivit possono essere considerati una versione rivista e aggiornata dei paleolitici Flow Chart: per questo risultano particolarmente familiari a un vastissimo numero di persone anche con limitato skill tecnico. Logica conseguenza che risultano un valido ausilio per documentare funzionalit da sottoporre al vaglio di personale non tecnico: clienti e utenti.

UML e ingegneria del software: dalla teoria alla pratica

51

Figura 2.24 Activity Diagram acquisto biglietti.


Utente
Selezione servizio acquisto biglietti Genera modulo "elenco calendari spettacoli" Selezione calendario spettacoli Genera modulo "elenco spettacoli calendario" Seleziona spettacolo Genera modulo "elenco rappresentazioni" Seleziona rappresentazione Genera mappa "disponibilit posti" Seleziona settori Genera dettaglio settori selezionati Seleziona posti nel dettaglio settori Riverifica disponibilit posti
[posti non piu' disponibili] P oic he' uno dei crite ri utilizzati per la selezione d el s e t t o re i l re l a t iv o importo, la mappa dovrebbe riflettere le fasce tariffarie.

Sistema

Credit Card Authority

Aggiunge notifica non disponibilit


[posti ancora disponibili]

Determina importo transazione Genera modulo richiesta accredito Imposta dati accredito Verifica formale dati
[dati non validi]

Aggiunge notifica dati errati

[dati validi]

Prenota biglietti
[posti non pi disponibili]

Aggiunge notifica non disponibilit


Richiesta autorizzazione Ricezione richiesta [time-out]

Attesa esito valutazione

Verifica formale richiesta


Notifica esito valutazione

Ricezione richiesta

Valutazione responso
[responso negativo]

Aggiunge notifica autorizzazione fallita Annulla prenotazione

[responso positivo]

Valuta tempo a disposizione


[tempo insufficiente per consegna] [responso positivo]

Genera modulo richiesta indirizzo consegna Imposta indirizzo consegna Genera pagina riassuntiva

52

Capitolo 2. UML: struttura, organizzazione, utilizzo

Tipicamente li si utilizza nella fase di disegno, in particolare quando alcune decisioni implementative tipo quali attivit assegnare agli oggetti istanza di una classe risultano difficili da prendere. Infatti i diagrammi di attivit permettono di enfatizzare la sequenzialit e la concorrenza degli step di cui si compone una particolare procedura.

Component diagrams
I Component Diagram mostrano la struttura fisica del codice in termini di componenti e di reciproche dipendenze. Insieme ai Deployment Diagram costituiscono la vista fisica del sistema e vengono comunemente indicati collettivamente con il nome generico di diagrammi di implementazione. In particolare, i diagrammi dei componenti illustrano la proiezione statica dellimplementazione del sistema e pertanto, sono strettamente connessi ai diagrammi delle classi. Ciascun componente rappresenta una parte del sistema, modulare, sostituibile5, deployable, che incapsula implementazione ed espone un insieme di interfacce. Un componente tipicamente costituito da un insieme di elementi (interfacce, classi, ecc.) che risiedono nel componente stesso. Un certo numero di questi ne definisce esplicitamente le interfacce esterne, ossia la definizione dei servizi esposti e quindi forniti dal componente. Unarea dello UML giudicata particolarmente carente dai vari esperti di sistemi Component-Based, che ha suscitato e continua a suscitare non poche critiche, proprio quella relativa ai componenti. La definizione attuale fornita dallo UML effettivamente un po restrittiva; ci per abbastanza comprensibile se si pensa che la tecnologia dei sistemi Component-Based relativamente recente e, verosimilmente, nel momento in cui viene scritto il libro, ci si trova ancora allinizio della relativa curva di apprendimento. Lapproccio basato sui componenti la logica evoluzione della filosofia Object Oriented ed destinata ad avere un impatto profondo su disegno e implementazione dei sistemi. Probabilmente lo stesso UML finir magari non a brevissimo termine per essere considerato un linguaggio di modellazione Component-Based piuttosto che semplicemente Object Oriented. Con la versione 1.4 molto stato fatto nella direzione dello studio di soluzioni atte a colmare le lacune evidenziate dallo UML nella modellazione di sistemi basati sui componenti. Ciononostante, ancora diverse carenze risultano irrisolte. Per esempio sarebbe opportuno definire profili da utilizzarsi per la modellazione di sistemi basati sulle architetture Component-Based pi famose (EJB, COM+ e CCM), proporre tecniche per modellare il

Recenti studi hanno evidenziato come la volatilit dei requisiti, tipica nel 90% dei sistemi, ha finito per minimizzare

il concetto di riusabilit, una volta baluardo dellObject Oriented. Allo stato attuale si preferisce parlare di sostituibilit dei componenti (in senso generale). La variazione dei requisiti pu essere neutralizzata aggiornando o sostituendo uno o pi componenti senza dover modificare altre parti del sistema non affette dalla variazione stessa.

UML e ingegneria del software: dalla teoria alla pratica

53

Figura 2.25 Component Diagram del distributore automatico.


servlet EJB

ControllerWEB

ServizioDIPrenotazione

BusinessLogic

DatabaseServices jsp DatabaseLayer View

contesto dellesecuzione dei componenti (Containers EJB) e relative comunicazioni, individuare tecniche per modellare lassemblaggio dei sistemi Component-Based e cos via. Nella fig. 2.25 illustrato il diagramma dei componenti (concettuale) del sistema di ticketing del teatro. Si tratta di una primissima versione da raffinare durante la fase di disegno e da revisionare durante il processo di implementazione. Probabilmente lesempio artificioso e i componenti vengono assemblati per tecnologia, il che non sempre rappresenta lidea migliore. In ogni modo viene presentata una schematizzazione di una versione del Design Pattern MVC (Model-View-Control, modello vista e controllo): lo stesso utilizzato dalle Swing Java, adattato al Web. (Per maggori informazioni possibile consultare il documento Suns Blueprints dor J2EE). In particolare la o le Servlet dovrebbero incaricarsi essenzialmente di fornire dei servizi comuni come autenticazione, login, gestione degli errori, ecc. e di effettuare opportune re-direzioni delle richieste dellutente (il vero e proprio Controller). Le richieste del client (browser Internet) dovrebbero giungere allopportuna Servlet, la quale dovrebbe girare la richiesta alla classe appropriata (magari servizio EJB) atta alla relativa gestione: agisce in qualche modo da notificatore eventi (Events Dispatcher). Le Servlet si dovrebbero anche incaricare di istanziare opportuni JavaBean da trasmettere (in qualche modo) al client insieme alla pagina HTML generata dallappropriata JSP (pagine HTML con integrato del codice Java). Chiaramente la Business Logic del sistema dovrebbe essere fornita dagli Enterprise Java Bean: le Servlet dovrebbero utilizzare anche questi elementi per inserire dati in appo-

54

Capitolo 2. UML: struttura, organizzazione, utilizzo

siti JavaBeans. Nel diagramma presentata una generica macrointerfaccia esposta dagli EJB; ovviamente si tratta di una rappresentazione simbolica: in realt bisognerebbe evidenziare tutta una miriade di interfacce implementate dai relativi EJB. Per terminare mostrato un component definito Database Layer, in quanto si assume che la persistenza non venga gestita da Entity Beans bens da Session. Nella fig. 2.26 riportato un ulteriore esempio di Component Diagram. Brevemente, il diagramma mostra tre componenti: Prenotazione, ListinoPrezzi e DisponibilitaPosti. Verosimilmente, compito del primo componente fornire una serie di servizi quali prenotazione di poltrone situate in specifici settori del teatro per determinate rappresentazioni di spettacoli, reperimento di informazioni relative al listino prezzi, verifica disponibilit, ecc. Lesempio, sebbene non completo probabilmente sarebbe stato opportuno mostrare un maggior numero di componenti opportunamente organizzati stato proposto al fine di presentare alcuni elementi dello UML introdotti con la versione 1.4. Questi elementi risultano particolarmente utili per la progettazione e descrizione della struttura dei componenti. In particolare gli stereotipi (in questo contesto si tratta di classi con particolare significato) <<focus>> e <<auxiliary>>, da utilizzarsi in coppia, permettono di distinguere classi core (fondamentali o centrali per il flusso di controllo) da altre di secondaria importanza (sempre dal punto di vista logico). Figura 2.26 Esempio di specifica di un componente.
EJBEntity ListinoPrezziHome

ListinoPrezzi
auxiliary focus
ListinoPrezziHome

ListinoPrezziPK auxiliary ListinoPrezziInfo

ListinoPrezzi
ListinoPrezzi

ListinoPrezzi

jarFile ListinoPrezziJar

DisponibilitaPostiHome

EJBSessionBean

EJBEntity
DisponibilitaPosti

Prenotazione

DisponibilitaPosti

UML e ingegneria del software: dalla teoria alla pratica

55

Nel diagramma in fig. 2.26 viene conferito particolare risalto alla struttura del componente ListinoPrezzi, costituito dalle classi ListinoPrezzi, ListinoPrezziInfo, ListinoPrezziPK. Lacronimo PK riportato come suffisso allultima classe indica un oggetto che ingloba la chiave primaria (PK, Primary Key). Sarebbe stato opportuno considerare un nome diverso, soprattutto al fine di non creare confusione con altre tecnologie, come per esempio quella dei database relazionali, ma questa tecnica permette di specificare lidentificatore univoco dei componenti entity EJB. Da quanto descritto, si comprende come il componente generale sia realizzato attraverso lutilizzo di due classi ausiliarie. Gli stereotipi <<focus>> e <<auxiliary>> risultano particolarmente utili per cominciare a progettare e descrivere componenti gi nelle fasi di analisi e disegno direttamente nei diagrammi delle classi. Infine lo stereotipo <<jarFile>> permette di distinguere componenti eseguibili (EJB entity bean, EJB session bean, COM object) dai manufatti che li implementano (JAR file, DLLs ).

Deployment Diagram
I diagrammi di dispiegamento mostrano larchitettura hardware e software del sistema: ne vengono illustrati gli elementi fisici (computer, reti, dispositivi fisici, ) opportunamente interconnessi e i moduli software allocati su ciascuno di essi. In sintesi viene mostrato il dispiegamento del sistema a tempo di esecuzione sulla relativa architettura fisica, in termini di componenti e relative allocazioni nelle istanze dei nodi. Dallanalisi di fig. 2.27 possibile individuare una serie di nodi, rappresentati attraverso parallelepipedi, collegati tra loro per mezzo di opportune connessioni (associazioni). I nodi sono elementi fisici esistenti a tempo di esecuzione che rappresentano risorse computazionali, mentre i collegamenti mostrano le relative connessioni fisiche. I nodi vengono suddivisi in processori (Processor) e dispositivi (Device): la differenza risiede nel fatto che i primi dispongono di capacit elaborative (possono eseguire dei componenti), mentre i secondi no e, tipicamente, vengono utilizzati per rappresentare elementi di interfacciamento con il mondo esterno. I nodi sono entit simili alle classi (ereditano dallo stesso genitore: classificatore), per cui possibile utilizzarne le stesse potenzialit: ruoli, molteplicit, vincoli, ecc. Poich diagrammi con soli nodi possono risultare decisamente anonimi e poco esplicativi, possibile utilizzare delle rappresentazioni alternative utilizzandone istanze (TelefonoCellulareWAP, TouchScreen, ecc.) : un concetto del tutto simile a quello dei diagrammi degli oggetti. In tali varianti, possibile corredare i nodi con un nome, indicarne i processi allocati, e cos via. Nel diagramma in fig. 2.27 viene mostrata una prima versione del Deployment Diagram. Nelle versioni pi dettagliate sarebbe corretto riportare anche i propri moduli: per esem-

56

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.27 Esempio di diagramma di dispiegamento.

:TelefonoCellulareW AP

WAP Internet browser

er nt I ne t

W eb Server

InternetClient : PC

In

te r

net

A L

W eb Server

Web Server

Internet browser

LAN
L

e er n Int
TouchScreen : PC

t
Web Server

Internet browser

e nt I

et rn

AN

W eb Server

Web Server Sportello : PC

Internet browser

pio tutte le pagine HTML, JSP (Java Server Pages), le Servlet e i JavaBeans andrebbero installate nel Web Server, il core del sistema; i servizi EJB e il layer di interfacciamento al database invece andrebbero ubicati nellApplication Server e cos via.

Meccanismi generali
I successivi paragrafi illustrano i meccanismi generali, in quanto utilizzabili in qualsiasi vista e diagramma, forniti dallo UML per estenderne sintassi e semantica. Sebbene gli elementi del nucleo dello UML permettano di formalizzare molti aspetti di un sistema, impossibile pensare che da soli siano sufficienti per illustrarne tutti i dettagli. Si sarebbe potuto tentare di colmare tale lacuna per esempio inserendo numerosi elementi specializzati, ma il costo da pagare sarebbe stato quello di rendere il linguaggio inutilmente complesso e rigido e poi ci sarebbe sempre stato il famoso caso non contemplato (Murphy insegna).

UML e ingegneria del software: dalla teoria alla pratica

57

Per evitare ci, lo UML fornisce sia meccanismi generali utilizzabili per aggiungere informazioni supplementari difficilmente standardizzabili, sia veri e propri meccanismi di estensione. Lesempio pi classico, gi incontrato nel corso di alcuni dei diagrammi presentati nei paragrafi precedenti, quello delle note (notes): informazioni supplementari redatte con un formalismo che pu variare, a completa discrezione dellarchitetto, dal linguaggio di programmazione, allo pseudocodice al testo in linguaggio naturale.

Naturalmente la selezione del livello di astrazione da utilizzare deve essere subordinata al miglioramento della leggibilit del diagramma. Poich la leggibilit dipende anche dal fruitore, ne segue che il formalismo da utilizzarsi dipende dal destinatario principale del diagramma. Per esempio unannotazione in codice avrebbe poco significato nella Use Case View, dove il pubblico dei fruitori prevede anche i clienti che, per definizione, non hanno conoscenze tecniche, mentre dovrebbe risultare del tutto naturale in un Class Diagram, i cui fruitori sono tecnici qualificati.

Figura 2.28 Utilizzo delle note in uno Use Case Diagram.

login
include

reperimento dati cliente


extend
Il caricamento avviene con le stesse modalita' con cui si associa un attachment ad una e-Mail in un server di posta elettronica con interfaccia webbased.

upload ordine Cliente

extend

extend

verifica ordine

invia ordine espresso Legacy System


Gli ordini es pres si vanno spediti a l Legacy System appena disponibili, gli a ltri in m od alita' b a tc h s ec o nd o scadenze prestabilite.

58

Capitolo 2. UML: struttura, organizzazione, utilizzo

Graficamente le note vengono rappresentate per mezzo di un foglio di carta stilizzato associato, per mezzo di una linea tratteggiata, allelemento che si vuole dettagliare. Nella fig. 2.28 le note sono state attaccate a due casi duso: Upload ordini e Invia ordine espresso, rispettivamente per specificare la modalit utilizzata per trasmettere un file da un browser client a un Web server e per evidenziare la differenza esistente tra gli ordini comuni e quelli espressi da trasmettere al legacy system appena disponibili. In questo caso le note contengono semplice testo in linguaggio naturale coerentemente con la vista di appartenenza e quindi con i relativi fruitori. Si noti il ricorso al colore grigio chiaro sia per il testo, sia per il disegno della sagoma delle note. Esso utilizzato al fine di non appesantire il diagramma e di non distogliere lattenzione dagli elementi pi importanti. Un altro meccanismo generale costituito dai cosiddetti ornamenti (adornments), che permettono di aggiungere semantica al linguaggio. Si tratta di elementi grafici atti a fornire al lettore una cognizione diretta di aspetti particolarmente importanti di specifici elementi. Con riferimento a fig 2.29, si pu notare che il nome delle classi stato scritto in corsivo per indicare che si tratta di classi astratte. Nella relazione (associazione) che lega lOggettoOsservato allOggettoOsservatore presente un altro esempio di ornamento: la molteplicit. In una relazione tra classi, le molteplicit sono i numeri (o simboli) che specificano, per entrambe le classi dellassociazione, quante istanze possono essere coinvolte nella relazione con laltra classe. Per esempio nel diagramma di fig. 2.29, un O g g e t t o O s s e r v a t o pu disporre di diversi osservatori, cos come OggettoOsservatore pu osservare diversi oggetti. Un altro esempio di ornamento sono i simboli utilizzati per mostrare la visibilit di metodi ed attributi delle classi (+ per elementi pubblici, - per privati, # per protetti, ecc). Da notare che nella versione 1.4 dello UML stata aggiunta unulteriore visibilit: quella a livello di package (il friendly del C++) indicata con il simbolo tilde (~ package). Ulteriore esempio di meccanismo generale rappresentato dalle specificazioni (specifications): elementi di testo che aggiungono sintassi e semantica agli elementi dello UML. Un esempio di specificazione fornito dallindicazione dellelenco degli attributi e Figura 2.29 Utilizzo delle note per illustrare le operazioni eseguite da un metodo.
OggettoOsservatore ... +richiestaAggiornamento() ... * osservatori OggettoOsservato

while(osservatori.hasElement()) { osservatore = osservatori.next(); osservatore.richiestaAggiornamento(); }

... +aggiungiAscoltatore() +leggiStato() +notificaEvento +rimuoviAscoltatore() +rimuoviAscoltatori() ...

UML e ingegneria del software: dalla teoria alla pratica

59

Figura 2.30 Distinzione tra classe e relative istanze (oggetti).

Spettacolo - codice : String - titolo : String ... + getRappresentazione() ...

: Spettacolo

Barracuda : Spettacolo

Barracuda

dei metodi (inclusa la firma completa) presenti nellicona delle classi. Tipicamente per conferire ai vari diagrammi un livello migliore di chiarezza, vengono visualizzati solo determinati sottoinsiemi degli attributi e metodi dei vari elementi, chiaramente quelli ritenuti pi utili nel contesto oggetto di studio. Ci implica che per una stessa classe, in diversi diagrammi, possano essere visualizzati sottoinsiemi diversi di metodi e attributi. Ultimo esempio di meccanismo generale costituito dalle divisioni comuni (common divisions): nella modellazione di sistemi OO, ogni elemento reale pu essere diviso, almeno, in due diverse tipologie. Il primo esempio costituito dalle classi e dagli oggetti: una classe unastrazione; un oggetto ne il corpo, ossia una concreta manifestazione della classe. Su questi argomenti si torner in dettaglio nel capitolo dedicato ai diagrammi delle classi e degli oggetti, per ora sufficiente sapere che lo UML fornisce i meccanismi per mostrare la dicotomia presente in molti degli elementi (Use Case e istanze di Use Case, componenti e istanze di componenti, e cos via). In fig. 2.30 sono rappresentate la classe Spettacolo e tre sue istanze: nella prima viene indicata unicamente la classe di appartenenza (Spettacolo appunto), la seconda evidenzia anche il nome (Barracuda :Spettacolo), mentre la terza solo il nome. Un altro esempio di divisione comune fornito dalle interfacce e dalle relative implementazioni: uninterfaccia dichiara un contratto e una sua implementazione rappresenta una concreta realizzazione del contratto stesso, e quindi responsabile della fornitura dei servizi in esso promessi.

Meccanismi di estensione
I meccanismi di estensione (Extensibility Mechanisms) consentono di aumentare sintassi e semantica dello UML al fine di permetterne il proficuo utilizzo in aree molto specifiche migliorando la leggibilit dei diagrammi prodotti e, al contempo, contenendo il livello di complessit del linguaggio stesso.

60

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.31 Esempio di Interfaccia e relativa implementazione.

PrenotazioneBigliettiImp PrenotazioneBiglietti

In particolare i meccanismi di estensione forniti dallo UML sono: Stereotypes (stereotipi); Tagged Values (valori etichettati); Constraints (vincoli). Gli stereotipi permettono di estendere il vocabolario dello UML attraverso lintroduzione di nuovi elementi, definiti dallutente, specifici per il problema oggetto di studio. Chiaramente la definizione degli stereotipi deve seguire regole ben precise: ciascuno di essi deve essere la specializzazione di un elemento presente nello UML (metamodello). In ultima analisi uno stereotipo un nuova classe che viene (virtualmente) aggiunta al metamodello in fase di progettazione. Chiaramente non assolutamente necessario andare a modificare il metamodello: sufficiente che il nuovo stereotipo rispetti le regole previste. Spesso uno stereotipo viene introdotto unicamente per disporre di icone pi accattivanti (per esempio se un attore un legacy system, invece di mostrare luomo stilizzato potrebbe risultare pi chiaro mostrare unicona con riportato un vecchio mainframe) o per evidenziare unetichetta autoesplicativa (come per esempio nel caso di focus e auxiliary). Altre volte li si utilizza per aggiungere insiemi predefiniti di Tagged Value (associazione tra un attributo e il relativo valore) e vincoli validi per tutte le istanze dello stereotipo stesso. Ovviamente i vincoli, il nome e le altre caratteristiche aggiunte per mezzo di uno stereotipo, non devono entrare in conflitto con la definizione dellelemento base (metaclasse o stereotipo) che si intende specializzare. Un esempio di quanto detto rappresentato dallo stereotipo <<persistent>> (fig. 2.32) dellelemento classe (volendo essere formali si tratta di una specializzazione della metaclasse del metamodello denominata Classe). Esso si presta a essere utilizzato per

UML e ingegneria del software: dalla teoria alla pratica

61

inserire informazioni aggiuntive alle classi le cui istanze necessitino di essere memorizzate in forma permanente dal sistema. La presenza della etichetta riportante con lo stereotipo (<<persistent>>), gi da sola aiuta ad aumentare la chiarezza del modello. Infatti permette di distinguere immediatamente le classi (istanze dello stereotipo) i cui oggetti necessitano di essere memorizzati in modo permanente da quelle che invece non ne hanno bisogno. Questo stereotipo presenta tutta una serie di elementi aggiuntivi, quali: Tag: storageMode i cui elementi sono di tipo enumerato e possono assumere uno dei seguenti valori: table, file, object;

Figura 2.32 Definizione ed utilizzo di uno stereotipo (Persistent). Formalmente in UML uno stereotipo rappresentato attraverso unapposita (meta)Classe il cui stereotipo <<stereotype>> appunto. Tale classe la client di una relazione di dipendenza (a sua volta stereotipizzata con il termine <<stereotype>>) che la vincola allelemento del metamodello che intende estendere. Nellesempio di figura lelemento che si intende estendere la metaclasse Class (Classe). I Tagged Value del nuovo elemento sono rappresentati per mezzo di appositi attributi, talune volte stereotipizzati come <<taggedvalue>>.

metaclass Class stereotype stereotype Persistent tags table : String database : Database isContainer : boolean constraints {table.size <= 16} Persistent Articolo
{table = Articolo} {database=eCommerce} {isContainer=true}

- id : String - name : String - description : String ... getPrize() ...

Metamodello

Modello

62

Capitolo 2. UML: struttura, organizzazione, utilizzo

Per gli oggetti persistenti su tabella, risulta inoltre possibile specificare informazioni aggiuntive come: Nome della tabella con il vincolo che sia minore di 16, database, ecc. Chiaramente tutte le classi istanze dello stereotipo <<persistent>> devono fornire valori per i Tagged Value riportati poco sopra, nonch rispettarne il vincolo. La descrizione formale degli stereotipi viene anche data in forma tabulare, per mezzo di apposita tabella (tab. 2.1). In essa sono presenti sei colonne, rispettivamente lo stereotipo (Stereotype), lelemento del metamodello che si specializza (Base Class), lelemento genitore (Parent), eventuali valori etichettati associati (Tags), eventuali vincoli (Constraints) e la descrizione (Description). La colonna Parent ha senso qualora lo stereotipo che si intende definire sia la specializzazione di un altro predefinito.

Tabella 2.1 Descrizione formale degli stereotipi.


Sterotype Base class Parent Tags Constraints Description Indica classi le cui istanze devono essere memorizzate in forma permanente.

Persistent

Class

N/A

table database isContainer

table.size() < 17

Questa tabella deve poi essere seguita da quella che definisce i Tagged Value associati allo stereotipo. Da tener presente che con la versione 1.4 dello UML si esorta a definire Tagged Value in associazione con gli stereotipi. In sostanza sarebbe obbligatorio, per tale obbligatoriet viene meno per questioni di compatibilit con le versioni precedenti. Si vuole sottolineare ancora una volta che nella pratica non assolutamente necessario dar luogo alla definizione formale dei vari stereotipi che si intende utilizzare nei propri modelli: essi possono essere utilizzati alluopo. Chiaramente le definizioni rigorose diventano necessarie qualora gli stessi stereotipi debbano essere utilizzati da diversi team, in svariati progetti e cos via. Un altro classico esempio di stereotipo quello delle classi di eccezione: sebbene siano classi a tutti gli effetti, i relativi oggetti vengono trattati in modo del tutto particolare. Gli stereotipi vengono indicati o per mezzo del nome racchiuso tra doppie parentesi angolari (da definizione dello UML le doppie parentesi devono essere un solo carattere) oppure fornendo una nuova icona. In fig. 2.33 viene mostrato come le istanze della classe SourceParser possano scatenare eccezioni del tipo TokenNotValidException. In questo caso si evidenzia che questultima classe uneccezione sia dal nome sia dallindicazione dello stereotipo

UML e ingegneria del software: dalla teoria alla pratica

63

Figura 2.33 Esempio di stereotipo: classe eccezione.


Exception

TokenNotValidException
... ...

throws
... ...

SourceParser

(exception appunto) racchiuso tra doppie parentesi angolari. Unalternativa decisamente accattivante consiste nel definire una nuova icona ad hoc, (fig. 2.34). Invece di una piatta stringa exception racchiusa tra parentesi angolari si utilizzata una colorata icona. Ricapitolando, uno stereotipo pu essere visualizzato in UML attraverso una serie di meccanismi, quali: 1. visualizzazione della sola stringa identificante lo stereotipo chiusa tra parentesi angolari doppie (fig. 2.33); 2. visualizzazione di unapposita icona (fig. 2.34, in alto a sinistra); 3. visualizzazione della rappresentazione grafica prevista per lelemento che si esteso, in questo caso una classe, con aggiunta di unicona specifica (fig. 2.34, in basso a sinistra); Figura 2.34 Esempio di stereotipo: classe eccezione visualizzata attraverso le varie modalit dello UML.
SourceParser
...

throws TokenNotValidException
...

Exception

TokenNotValidException
... ...

TokenNotValidException
... ...

64

Capitolo 2. UML: struttura, organizzazione, utilizzo

4. visualizzazione sia del nome dello stereotipo, sia dellicona nella rappresentazione grafica standard, un mix tra tecnica riportata nel punto1 e quella del punto 3 (fig. 2.34, in basso a destra). Chiaramente possibile utilizzare stereotipi per tutti gli elementi dello UML, come per esempio particolari Use Case, attributi di classi, messaggi, ecc. Gli stereotipi possono essere utilizzati anche a livello di elementi pi semplici come attributi e metodi (sempre metaclassi al livello di metamodello). Per esempio possibile specificare che un determinato attributo di sola lettura premettendo ad esso lopportuno stereotipo. Come si vedr nel paragrafo dedicato al profilo CORBA, ci particolarmente utile per modellare server e client realizzati per mezzo della tecnologia CORBA. Poich uno stereotipo specializza un elemento base, ne segue che pu essere utilizzato in ogni posto in cui viene utilizzato questultimo ( a tutti gli effetti una generalizzazione). Un ultimo esempio di utilizzo degli stereotipi relativo al Deployment Diagram mostrato in fig. 2.35: in questo caso il ricorso agli stereotipi genera un effetto decisamente pi incisivo degli spigolosi cubi definiti dallo UML, sebbene in un progetto professionale probabilmente il diagramma potrebbe risultare leggermente appariscente. Il diagramma dovrebbe far riferimento a unarchitettura gerarchica costituita da uninstallazione centrale alla quale afferiscono sia gli utenti Internet, sia tutta una serie di biglietterie remote. Larchitettura di queste lesatta copia di quella presente nel sistema centrale: ci al fine di non congestionare il sistema centrale per richieste che non coinvolgano dati relativi a prenotazione e acquisti di biglietti. Pertanto le varie biglietterie sono in grado di svolgere tutte le funzioni ordinarie in locale, limitandosi ad interagire con il sistema centrale solo per informazioni che variano in tempo reale. Nel diagramma in fig. 2.35 sono presenti anche due device, rispettivamente il lettore della Smart Card e lettore di Magnetic Card, che si distinguono dai processor, in quanto non dispongono di capacit elaborative, almeno non nel senso tradizionale. Tra i vari stereotipi introdotti, si pu notare quello per lassociazione tra nodi remoti (la nuvola Internet), i database server mostrati per mezzo di unicona a forma di cilindro, il telefono cellulare, il chiosco rappresentato da un Touch Screen, e cos via. I Tagged Value estendono le propriet degli elementi dello UML consentendo di aggiungere informazioni supplementari a qualsiasi elemento. Sono a tutti gli effetti esempi di specificazioni. Si tratta di elementi costituiti dalla coppia nomevalore. Linterpretazione della semantica dei valori etichettati esula volutamente dagli obiettivi dello UML. Si tratta di convenzioni interamente demandate al tool e/o allutente. Non a caso vengono definiti metaattributi virtuali. Per esempio un tool di disegno potrebbe utilizzare opportuni Tag Value per definire in quale linguaggio effettuare la generazione del codice. Si possono impostare informazioni specifiche relative a metodi, allo stato di avanzamento del modello, dati necessari ad altri strumenti di sviluppo e cos via. Per esempio, possibile specificare la versione della

UML e ingegneria del software: dalla teoria alla pratica

65

revisione di un diagramma o di un suo elemento. A tal fine, sufficiente impostare sotto il relativo nome la stringa : {versione = 1.02}. Con la versione 1.4 dello UML i Tagged Value diventano tipizzati: le relative istanze possono assumere solo valori vincolati, come mostrato nel caso dello stereotipo Persistent. Sempre con la versione 1.4 stata definita una nuova metaclasse nel package

Figura 2.35 Esempio di deployment con lutilizzo di opportuni stereotipi.

Server applicativo centrale

WAP

Server centrale

N LA

WAP Internet browser

Internet WEB Server FTP server


L AN

Application server
LAN
Database server centrale

Internet browser

Internet
Lettore smart card Chiosco
s al eri e

DB management system
Server applicativo biglietteria

Server biglietteria
LAN

N LA

Sportello

Application server
LAN

LAN
L AN

Lettore smart card


eri al e

WEB Server FTP server

Database server biglietteria

DB management system

66

Capitolo 2. UML: struttura, organizzazione, utilizzo

Extension Mechanisms del metamodello dello UML denominata tagDefinition. Questa specifica linsieme di Tagged Value che possono essere associati a un elemento. Si tratta di un espediente tecnico per invogliare i progettisti a associare insiemi di valori etichettati a opportuni stereotipi. In altre parole, qualora sia necessario definire dei Tagged Value, dovrebbe essere obbligatorio definire anche un opportuno strereotipo che li raggruppi. Il condizionale dovuto al fatto che, per questioni di compatibilit con le versioni precedenti dello UML, ancora possibile definire Tagged Value non associati ad alcuno stereotipo. Inoltre la convenzione sancisce che ogniqualvolta un Tagged Value sia di tipo booleano, la relativa presenza implica un valore true (per esempio riportare isAbstract = true o semplicemente isAbstract completamente equivalente), mentre lomissione indica un valore false. Tornando allesempio del profilo CORBA, potrebbe risultare utile indicare lesatto ordine con cui gli attributi di una classe rappresentante uninterfaccia CORBA compaiono. A tal fine si potrebbe utilizzare un Tag Value di nome IDLOrder come riportato negli esempi dedicati al profilo CORBA. La definizione formale dei Tagged Value dovrebbe essere effettuata per mezzo di una tabella come la tab. 2.2. In essa sono presenti cinque colonne, rispettivamente: valore etichettato (Tag), lo stereotipo a cui associato (Stereotype), il tipo (Type), la molteplicit (Multiplicity) e la descrizione (Description).

Tabella 2.2 Definizione formale dei Tagged Value.


Tag Stereotype Type Multiplicity Description

Table

Persistent

UML::Datatypes::String

Nome della tabella in cui memorizzare in forma permanente loggetto.

Database

Persistent

Database::DataBaseEnum (enumeration :{eCommerce, Security})

Nome del database a cui appartiene la tabella.

isContainer

Persistent

UML::Datatypes::Boolean

Valore true indica che la persistenza gestita dal container.

UML e ingegneria del software: dalla teoria alla pratica

67

Ulteriore esempio di meccanismo di estensione si fa per dire fornito dallo UML costituito dai Constraints (vincoli) che rappresentano restrizioni della semantica dei modelli. Una delle migliori definizioni formali sancisce che un vincolo una restrizione di uno o pi valori (o parti) di un modello Object Oriented o di un sistema. Tipicamente un vincolo pu essere rappresentato attraverso qualsiasi formalismo: la selezione di quello ritenuto pi idoneo completamente demandata al progettista. Da notare per che, nella versione 1.3 dello UML stato incorporato ufficialmente lo OCL6 (Object Constraint Language) dellIBM, linguaggio Object Oriented per la formulazione di vincoli esenti da effetti collaterali. Quindi, sebbene non sia strettamente obbligatorio definire tutti i vincoli per mezzo dellOCL, lutilizzo fortemente consigliato. LOCL si presta a essere utilizzato per esprimere rigorosamente anche altri concetti presenti nei vari diagrammi dello UML, come precondizioni e postcondizioni (particolarmente utili per il Design By Contract), condizioni di guardia, transizioni di stato, invarianti, e cos via. Con il termine invarianti si indicano particolari classi, tipi ecc. le cui istanze sono caratterizzate dal fatto che la valutazione di una specifica espressione fornisce per tutte lo stesso risultato (true), durante lintero ciclo di vita. In altre parole, invariante indica che lespressione associata a una classe o tipo deve fornire lo stesso risultato per tutte le rispettive istanze in ogni istante del relativo ciclo di vita. Tipicamente le classi invarianti vengono evidenziate attraverso apposito stereotipo <<invariant>>.

Un primo consiglio proveniente dallesperienza quotidiana: probabilmente non necessario possedere una conoscenza approfondita dello OCL; ovviamente occorre averne le basi concettuali e conoscerne i costrutti principali. Verosimilmente il sistema migliore per utilizzarlo acquistare una copia del libro [BIB11] e consultarla ogniqualvolta si abbia la necessit di comprendere e/o esprimere formalmente un vincolo. Da tener presente per che la versione incorporata nelle specifiche ufficiale dello UML sensibilmente diversa da quella illustrata nel libro [BIB11], per cui sempre opportuno avere qualche riscontro.

I constraint formulati tramite lOCL sono decisamente molto eleganti, espressi per mezzo di un linguaggio basato sul paradigma orientato agli oggetti, definito attraverso una grammatica rigorosa e chi pi ne ha pi ne metta. Ma, ahim, a fronte di tutti questi bellissimi vantaggi, esiste uno svantaggio che rischia di invalidarli tutti: quanti tecnici del proprio team conoscono e riescono a comprendere la semantica di vincoli espressi per mezzo delOCL?. Si tratta ovviamente di una domanda retorica. Proprio questo lo svantaggio:

Volendo essere precisi occorre dire che il primo embrione dellOCL va fatto risalire a Syntropy.

68

Capitolo 2. UML: struttura, organizzazione, utilizzo

ad eccezione di limitati casi semplici, pochissimi tecnici riescono a comprendere vincoli espressi per mezzo della grammatica OCL. Quanti, nel vostro team, padroneggiano lOCL?

Allora cosa fare? Secondo consiglio sempre gratuito di esprimere comunque i vincoli in modo formale, anche perch ci conferisce un aspetto di maggiore professionalit (a Roma si direbbe perch fa pi gajardi), ricordando per contestualmente che i vincoli vengono inseriti per essere compresi e quindi comunque necessario spiegarli attraverso il linguaggio naturale.

Si prenda in considerazione il diagramma riportato nella fig. 2.36. Si tratta di un semplice esempio atto ad illustrare la relazione esistente tra i conti corrente delle banche e i relativi clienti. Il diagramma sancisce che un conto corrente pu essere intestato a pi clienti cos come ciascuno di essi pu possedere diversi conti correnti (relazione n a n). Il primo vincolo espresso attraverso lOCL sancisce che, qualora un conto corrente sia intestato a una societ, non possibile disporre di altri cointestatari.
BankAccount.holders->exists(Customer.oclIsKindOf(Company)) implies BankAccount.holders->size = 1

In particolare la prima riga afferma che se nella collezione degli intestatari (holders) del conto corrente presente una societ, allora tale collezione prevede un solo elemento: la societ stessa. Il secondo vincolo risulta decisamente pi interessante. Afferma che se uno degli intestatari di un conto corrente un minorenne, allora lo stesso conto corrente deve necessariamente essere intestato anche a unaltra persona, questa volta maggiorenne.
BankAccount.holders->exists( elem|elem.oclIsKindOf(Person) & elem.oclAsType(Person).age() < 18) implies BankAccount.holders->exists( elem|elem.oclIsKindOf(Person) & elem.oclAsType(Person).age()>= 18)

Si consideri ora il diagramma delle classi riportato in fig. 2.37. Si tratta di una porzione di un diagramma proveniente direttamente dal mondo degli investimenti bancari (Treasury System). Diagrammi del tipo di quello in figura servono a rappresentare le entit dellarea

UML e ingegneria del software: dalla teoria alla pratica

69

Figura 2.36 Esempio di diagramma delle classi atto a rappresentare la relazione tra clienti di una banca e conti correnti.

- BankAccount.holders-> exists(Customer.oclIsKindOf(Company)) implies BankAccount.holders -> size = 1 - BankAccount.holders-> exists( elem | elem.oclIsKindOf(Person) & elem.oclAsType(Person).age() < 18) implies BankAccount.holders-> exists( elem | elem.oclIsKindOf(Person) & elem.oclAsType(Person).age() >= 18)

BankAccount
- balance - accountNumber ... +getHolders() +getMovements() ...

Customer - holders 1..* 1..*


- customerId - address ... +getId() ...

Customer
- customerId - address ... +getId() ...

Person
- title - dateOfBirth - name ... +getAge() ...

oggetto di studio (business) e tipicamente vengono indicati come modelli a oggetti del dominio (DOM, Domain Object Model). Il relativo obiettivo, come illustrato nel capitolo dei diagrammi delle classi, mostrare le varie entit e le relative associazioni presenti nel mondo concettuale che il sistema software deve automatizzare (area business o dominio del problema). Si tratta a tutti gli effetti di versioni Object Oriented dei famosi diagrammi entit-relazioni (Entity-Relationship Diagram). I DOM sono caratterizzati dal fatto che specificano nelle varie classi i soli attributi ritenuti significativi per lutente, corredandoli solo sporadicamente con qualche metodo ritenuto particolarmente significativo per larea

70

Capitolo 2. UML: struttura, organizzazione, utilizzo

di business oggetto di studio. Visto e considerato il dominio del problema si lasciato il diagramma in lingua inglese A Cesare quel che di Cesare. Senza entrare troppo nei dettagli in fondo lobiettivo quello di fornire un esempio di utilizzo dellOCL il diagramma pu essere spiegato come segue. In primo luogo nel mondo degli investimenti esistono diverse entit (agenti, broker, dipartimenti di banche, clienti, ecc.) aventi ruoli diversi ma comunque accomunabili sia perch condividono un certo sottoinsieme di comportamento sia per evitare di avere miriadi di oggetti simili sparsi per il sistema. Queste entit vengono rappresentate dalla classe denominata genericamente Party. Da tener presente che il raggruppamento delle relative istanze necessario anche perch ciascuna di esse pu recitare diversi ruoli: lassociazione plays che connette la classe Party a quella PartyRole prevede cardinalit (1, n). Per ogni ruolo che una classe Party recita necessario disporre delle informazioni inerenti i relativi recapiti (Contact): indirizzo, telefono, fax, e-mail, indirizzo per la messaggistica interbancaria, ecc. Unentit Party poi localizzata in una specifica citt (City) e pu essere strutturata secondo unapposita organizzazione gerarchica: ogni oggetto Party pu essere associato a un altro per mezzo dellassociazione parent. Una stessa banca per esempio pu essere suddivisa in dipartimenti, ognuno dei quali organizzato altri dipartimenti e cos via.

Figura 2.37 Diagramma concettuale relativo allentit party e relative associazioni.


self.books->notEmpty() implies self.roles->exists(PartyRole.oclIsKindOf(ProcessingOrg))

self.counterparty.roles->exists(PartyRole.oclIsKindOf(Counterparty))

-parent 0..1

City
1

located

0..n 0..n

Party
1

-counterparty 1 1

Trade
0..n

-roles

1..n

-books 0..n

Contact

PartyRole

Book

Agent

Broker

CalculationAgent

Counterparty

IPA

Investor

Issuer

Trustee

ProcessingOrg

UML e ingegneria del software: dalla teoria alla pratica

71

A questo punto si considerino le informazioni pi direttamente legate agli investimenti. Ciascuno di essi (Trade ) deve possedere almeno due entit: sorgente (chi vende) e destinatario (chi acquista). Nel caso pi generale possono essere coinvolte molte pi entit: agenti, intermediari ecc. Questi per vengono specificati attraverso altre entit (non riportate nel diagramma) denominate istruzioni per lerogazione delle liquidazioni (Standing Settlement Instructions), che si applicano agli investimenti in funzione dellennupla (sorgente, destinatario, prodotto finanziario, moneta, ecc.). Ogni trade appartiene a un solo book che tra laltro permette di individuare il dipartimento che ha stipulato linvestimento. A questo punto entrano in gioco i vincoli. Il primo (quello pi a sinistra) sancisce che solamente Party che svolgono anche funzioni di Processing Organization possono amministrare dei book.
self.books->notEmpty() implies self.roles->exists(PartyRole.oclIsKindOf(ProcessingOrg))

Precisamente, il vincolo sancisce che se un Party gestisce almeno un book ne segue che nella lista dei ruoli recitati dal Party stesso deve necessariamente comparire quello di Processing Organization. Il secondo vincolo invece associato alla classe Trade. Sancisce che un trade pu prevedere come controparte unicamente unistanza della classe Party che recita appunto il ruolo di controparte:
self.counterparty.roles->exists(PartyRole.oclIsKindOf(Counterparty))

Formalmente, nella lista dei ruoli recitati dalla classe Party collegata al trade per mezzo dellassociazione counterparty deve essere necessariamente presente il ruolo di Counterparty. Quindi unistanza di Trade rappresenta un deal (contratto, affare) stipulato tra uno specifico dipartimento della banca (ProcessingOrg), quello che amministra il Book a cui il Trade associato, e una controparte. Ultimo esempio di meccanismo di estensione costituito dai Profili (illustrati anche nei paragrafi seguenti) che con la versione 1.4 sono entrati a far parte integrante del linguaggio. Attualmente ne sono stati formalmente incorporati due: il profilo per i Software Development Processes (processi di sviluppo del software) e quello per il Business Modeling (modellazione dellarea business). Un profilo uno stereotipo di un package contenente un insieme di elementi del modello opportunamente adattati a uno specifico dominio o scopo. Tipicamente lo si ottiene estendendo il metamodello tramite luso adeguato di meccanismi di estensione forniti dallo UML (stereotipi, definizioni di Tagged Value, vincoli e icone). In tali casi si parla di profili leggeri (lightweight), in quanto ottenuti per mezzo dei meccanismi di estensione propri del linguaggio, in contrasto con quelli pesanti (heavyweight) ottenibili per mezzo dei meccanismi di estensione definiti dalle specifiche del MOF.

72

Capitolo 2. UML: struttura, organizzazione, utilizzo

Tabella 2.3 Stereotipi presenti nel profilo dei Software Development Processes.
NOME STEREOTIPO ELEMENTO BASE

UseCaseModel AnalysisModel DesignModel ImplementationModel UseCaseSystem AnalysisSystem DesignSystem ImplementationSystem AnalysisPackage DesignSubsystem ImplementationSubsystem UseCasePackage AnalysisServicePackage DesignServiceSubsystem Boundary Entit Control Communicate Subscribe

Model* Model Model Model Package Package Subsystem** Subsystem Package Subsystem Subsystem Package Package Subsystem Class Class Class Association Association

* Il modello cattura una particolare vista di un sistema fisico, in altre parole, ne una astrazione realizzata per scopi ben precisi. In particolare lo scopo permette di determinare quali elementi sia interessante riportare e quali invece possano essere trascurati. possibile definire diversi modelli per uno stesso sistema, dove ciascuno ne rappresenta una vista definita da propri obiettivi e dal relativo livello di astrazione (per esempio modello di analisi, modello di disegno, modello di implementazione, e cos via). Tipicamente diversi modelli risultano tra loro complementari e vengono definiti dalle prospettive (Viewpoints, punti di vista) dei diversi fruitori del sistema. Poich nel metamodello la metaclasse modello che scioglilingua! eredita da Package , ne consegue che rappresenta un raggruppamento di elementi opportunamente organizzati secondo strutture gerarchiche ( P a c k a g e eredita dal N a m e s p a c e e dal

GeneralizableElement).
* * Un sottosistema (Subsytem) un raggruppamento di elementi che rappresentano ununit, aggregabile dal punto di vista del comportamento, del sistema fisico. I sottosistemi sono in grado di esporre opportune interfacce e dispongono di operazioni. Gli elementi che costituiscono i sottosistemi vengono divisi in due categorie: elementi di specifica e quelli di realizzazione. Nel metamodello lelemento Subsystem presenta una ereditariet multipla: eredita sia dal Package sia dal Classifier. Quindi oltre alle caratteristiche proprie del Package, esso possiede tutta una serie di features quali operazioni, associazioni, ecc.

UML e ingegneria del software: dalla teoria alla pratica

73

La definizione formale di un profilo, per essere consistente allapproccio utilizzato nel documento delle specifiche ufficiali, deve prevedere le seguenti sezioni: 1. insieme delle estensioni standard che definiscono il profilo stesso, ottenuto attraverso lopportuna applicazione dei meccanismi di estensione dello UML al sottoinsieme di interesse del metamodello; 2. definizione della relativa semantica descritta attraverso il linguaggio naturale (americano, ovviamente); 3. insieme delle regole ben formate (well-formed rules), ossia insieme di vincoli, espressi in linguaggio naturale, e qualora possibile per mezzo dellOCL, appartenenti agli elementi introdotti con il profilo; 4. elementi comuni del modello (common model elements), ossia istanze predefinite di elementi del metamodello UML. La definizione di tali elementi pu far uso delle estensioni standard definite nel profilo stesso secondo gli eventuali vincoli in esso presenti; 5. eventuali estensioni al MOF (Meta Object Facility). Questa sezione, qualora presente, determina la transazione del profilo dalla caratterizzazione leggero a quella pesante. Si ottiene definendo nuove meta-classi da incorporare nella definizione formale del MOF. Chiaramente, si tratta di estensioni delicate a cui ricorrere solo dopo aver appurato linadeguatezza ai fini richiesti dei meccanismi standard. possibile pensare ai profili come a librerie di elementi o a plug-in da installare, contenenti insiemi predefiniti di elementi ottenuti dallestensione di quelli base, da utilizzarsi per modellare specifiche aree business o per determinati scopi. Nella fig. 2.38 vengono riportati alcuni esempi di elementi presenti nel profilo dei Software Development Processes. Questi sono solo alcuni esempi di stereotipi presenti nel profilo: la lista completa presente nella tab. 2.3. Per quanto riguarda gli stereotipi delle classi riportati in figura, non si tratta di elementi nuovi; li si pu trovare, tra laltro nel libro dei Tres Amigos dedicato al processo di sviluppo del software ([BIB08]). Essi si prestano a essere utilizzati nel modello di analisi con i seguenti significati:
<<entity>>

Il significato di questo stereotipo abbastanza intuitivo: gli oggetti entit contengono informazioni che necessitano di essere memorizzate in forma permanente. Quindi, tipicamente, rappresentano entit che esistono (o traspirano) nel mondo concettuale oggetto di

74

Capitolo 2. UML: struttura, organizzazione, utilizzo

Figura 2.38 Stereotipi di classi definiti nel profilo dei Software Development Proecesses.
control

SessionTracker SessionTracker
boundary

TicketReservation TicketReservation

entity

ShowRepresentation ShowRepresentation

studio: si tratta prevalentemente, di raffinamenti delle classi presenti nel modello del dominio. Le istanze dello stereotipo <<entity>> sono oggetti passivi (per esempio non iniziano una interazione per loro iniziativa) e tipicamente partecipano nella realizzazione di molti Use Case e sopravvivono alle singole interazioni.
<<control>>

Le istanze di questo stereotipo gestiscono interazioni tra collezioni di oggetti. Tipicamente hanno comportamento specifico per un singolo Use Case e i relativi oggetti non sopravvivono a una specifica interazione a cui prendono parte. Queste classi sono anche utilizzate per rappresentare complessi algoritmi di calcolo, regole appartenenti allarea business, ecc.
<<boundary>>

Le istanze di questa classe vivono nel confine interno del sistema, e il relativo compito, tipicamente, consiste nel gestire linterazione tra attori esterni e altri oggetti boundary, entity e control interni al sistema stesso. Quindi si tratta di parti del sistema che dipendono dai relativi attori e in particolare catturano i requisiti per determinate interazioni.

I profili attesi
Come visto in precedenza, i profili sono delle particolari estensioni dello UML, o meglio collezioni di estensioni predefinite, le quali nascono dallesigenza di standardizzare

UML e ingegneria del software: dalla teoria alla pratica

75

lutilizzo dello UML per domini o scopi o tecnologie ampiamente diffuse come per esempio le architetture CORBA, EJB e COM+. Lo UML di per s un metamodello e quindi una notazione a scopo generale (general purpose) particolarmente indicata per esprimere modelli ad oggetti. Uno degli intenti che fin dallinizio hanno ispirato il lavoro dei Tres Amigos stato di renderlo cos generico da poter essere utilizzato proficuamente in unestesa variet di ambienti. Poich per era impossibile riuscire a immaginare i requisiti di tutti i possibili ambienti fin dallinizio, stato deciso di dotare lo UML di meccanismi che ne consentissero lestensione (consultare i paragrafi precedenti) garantendo cos un efficace utilizzo in ogni ambiente specifico. Il problema emerso era che le estensioni da apportare allo UML al fine di adattarlo a tecnologie particolarmente ricorrenti in progetti Object Oriented erano completamente demandate ai progettisti. Il rischio, ancora una volta, era quello di una nuova proliferazione di plug-in non standardizzati e completamente disomogenei che chiaramente finivano per minare i grandi vantaggi offerti dallo UML, derivanti dallelevato grado di standardizzazione. Per esempio, se si fosse chiesto ad n architetti (esperti) di progettare un sistema basato sulla tecnologia EJB attraverso lo UML, verosimilmente tutti avrebbero realizzato altrettanti modelli perfettamente validi e formali ma, probabilmente, ciascuno avrebbe formulato un proprio insieme di estensioni, diverso da quello ideato degli altri. Si correva pertanto il rischio di generare ancora una volta una miriade di dialetti. Un altro problema legato, paradossalmente, a una delle caratteristiche pi apprezzate del linguaggio: lessere general purpose. Se da un lato un vantaggio per i motivi pi volte elencati, dallaltro la relativa flessibilit pu creare non pochi problemi e qui ce ne sarebbero di esempi da citare soprattutto a un pubblico di utilizzatori UML non esperti. Molto spesso i progettisti vengono sopraffatti dalla flessibilit del linguaggio e preferirebbero disporre di elementi pronti la cui validit sia stata gi collaudata da altri. Onde evitare tutto ci, lo OMG (Object Management Group) ha deciso di lavorare alla standardizzazione di una serie di profili, tra i quali molto importanti sono quello CORBA e quello EJB per il quale, ovviamente, stata richiesta lapprovazione della stessa Sun Microsytem. Si tratta di un passo indietro? Tanto valeva, allora, definire tutti gli elementi direttamente dallinizio. In realt le cose non stanno cos. La struttura dello UML risulta paragonabile a quella di un qualsiasi linguaggio di programmazione. Esiste un core ben definito, basato su un numero di elementi relativamente limitato, e quindi pi facilmente accessibile, utilizzabile per costruire tutte le funzionalit di cui si ha bisogno, e in pi possibile utilizzare tutta una serie di librerie predefinite, di provato successo, addirittura gratuite. Larchitettura dello UML un esempio di ingegneria del software, che possiede le caratteristiche pi ambite: flessibilit, formalit, potenza, semplicit, ecc. I meccanismi di estensione, pertanto, rimangono strumenti comunque molto validi, la cui efficacia, tra laltro, stata provata durante il lavoro stesso di definizione di profili. Si tratta di un framework utilizzabile per estendere efficacemente il linguaggio per gli usi pi svariati

76

Capitolo 2. UML: struttura, organizzazione, utilizzo

secondo direttive ben definite E poi nessuno vieta di definire ulteriori elementi non previsti dai profili. Di seguito si cercher di illustrare il modo in cui utilizzare proficuamente i meccanismi di estensione forniti dallo UML e di rendere il lettore consapevole dellesistenza di direttive standardizzate per la modellazione di sistemi basati su tali architetture. lecito attendersi variazioni in fututo, visto che, al momento in cui si scrive, le specifiche per tali profili non sono ancora disponibili.

Profilo CORBA molto in generale


In primo luogo, il profilo CORBA, sancisce come era logico attendersi che le relative interfacce siano modellate attraverso classi. Ovviamente gli attributi e i metodi di tali classi corrispondono, rispettivamente, ai metodi e alle operazioni delle interfacce (IDL). Figura 2.39 Frammento di un layer di wrapper di un sistema per le prenotazioni dei biglietti per voli aerei.

Aeroporto
- codiceIATA : string - nomeBreve : string - nome : string - zonaFusoOrario : string - tasseNaz : string - tasseIntrn : string - tasseIntrc : string ... ...

Citta
- codice : string - nome : string - sigla : string ... ...
1..* appartiene 1
za iliz ut

Moneta
- codice : string - nome : string - simbolo : string ... ...
1..*

e' ubicato 1..* 1

Nazione
IDL

1..*

Continente
- codice : string - nome : string - simbolo : string ... ...

IAeroporto
... ...

- codice : string - nome : string - sigla : string ... ...

contiene 1..* 1

IDL

IAeroportoFinder
+getAeroporti(citta) +getAeroporto(codiceIATA) +getAeroporto(nomeAeroporto)

AeroportoFinder

...

UML e ingegneria del software: dalla teoria alla pratica

77

A questo punto lettori non esperti dellarchitettura CORBA potrebbero avere qualche perplessit legata alla presenza di attributi nelle interfacce CORBA. tutto corretto; si tratta di interfacce definite per mezzo di un apposito linguaggio denominato IDL (Interface Definition Language) e possono ospitare anche attributi. Prima di proseguire oltre si prenda in considerazione il diagramma delle classi illustrato in fig. 2.39: costituisce lesempio di riferimento della spiegazione che segue. Il frammento riportato in figura mostra una porzione di un layer atto a incapsulare, per mezzo di opportuna architettura CORBA, un sistema legacy di una generica compagnia aerea. In particolare, la sezione mostrata focalizza lattenzione sullentit aeroporto e sulle classi CORBA che ne permettono lesposizione. Il primo problema che si poneva era che in CORBA possibile specificare che un attributo sia di sola lettura (read only), mentre in UML ci non possibile. Al pi possibile specificare che un attributo sia congelato (frozen), ma il significato non esattamente lo stesso. Brevemente frozen indica che il valore di un attributo o di unassociazione non pu essere modificato dopo che il relativo oggetto stato creato e lattributo/associazione frozen stato/a inizializzato/a. Per risolvere questo primo inconveniente possibile definire uno stereotipo che estende il costrutto UML di attributo in grado di indicarne appunto linibizione della scrittura (fig. 2.40). Nella classe visualizzata tutti gli attributi sono dichiarati di sola lettura in quanto utilizzata per comunicare alla classe client le informazioni relative agli aeroporti. Laspetto inte-

IDL IAeroporto ReadOnly codiceIATA : string ReadOnly nomeBreve : string ReadOnly nome : string ReadOnly zonaFusoOrario : string ReadOnly codiceCitta : string ReadOnly nomeCitta : string ReadOnly nomeNazione : string ReadOnly continente : string ReadOnly tasseNaz : string ReadOnly tasseIntrn : string ReadOnly tasseIntrc : string ... ...
IDL IAeroporto ReadOnly codiceIATA : string ReadOnly nomeBreve : string ReadOnly nome : string ReadOnly zonaFusoOrario : string ReadOnly codiceCitta : string ReadOnly nomeCitta : string ReadOnly nomeNazione : string ReadOnly continente : string ReadOnly tasseNaz : string ReadOnly tasseIntrn : string ReadOnly tasseIntrc : string ... ... {IDLOrder = 1} {IDLOrder = 2} {IDLOrder = 3} {IDLOrder = 4} {IDLOrder = 5} {IDLOrder = 6} {IDLOrder = 7} {IDLOrder = 8} {IDLOrder = 9} {IDLOrder = 10} {IDLOrder = 11}

Figura 2.40 Esempio dellutilizzo dello stereotipo <<readOnly>>.

Figura 2.41 Esempio di utilizzo del Tagged Value IDLOrder.

78

Capitolo 2. UML: struttura, organizzazione, utilizzo

ressante che lo UML si limita a fornire il supporto alla specificazione degli stereotipi mentre non necessita assolutamente di conoscerne il significato, il quale, evidentemente, deve per essere noto ai fruitori. Ci permette ai tool commerciali di abilitare lutente a estendere sintassi e semantica dello UML senza dover necessariamente fornire il significato dei nuovi costrutti eventualmente introdotti. Un altro problema che si potrebbe incontrare nella definizione di uninterfaccia IDL la necessit di specificare lesatto ordine in cui gli attributi e le operazioni compaiono nelle interfacce, che non necessariamente deve coincidere con quello degli stessi elementi che compaiono nelle classi che rappresentano le interfacce. In questo caso uno stereotipo non sarebbe di grande aiuto e pertanto stato necessario ricorrere a qualcosa di diverso come i valori etichettati (Tagged Value). In effetti il profilo CORBA prevede di utilizzare un Tagged Value il cui nome IDLOrder in cui il valore associato, un numero naturale, specifica lordine dellelemento al quale viene associato (fig. 2.41). Nuovamente, un tool commerciale per permettere allutente di utilizzare il profilo CORBA deve unicamente supportare i concetti come stereotipi e Tagged Value senza dover assolutamente conoscere la semantica di quanto introdotto dallutente. Un profilo costituito sostanzialmente da un insieme di stereotipi e Tagged Value predefiniti. Nel caso del profilo CORBA, la definizione dello stereotipo readonly e del Tagged Value IDLOrder ha permesso di estendere virtualmente il metamodello UML senza introdurre esplicitamente nessun nuovo costrutto o concetto notazionale.

Profilo EJB molto in generale


La formulazione del profilo EJB il risultato della collaborazione tra Rational, Sun Microsystem e Object Management Group (Java Specification Request JSR-26). Attualmente disponibile la versione draft (UML Profile for EJB, pubblicata nel maggio 2001), il cui principale fautore Jack Greenfield coadiuvato da un team formato da James Abbott, Loc Julien, David Frankel, Scott Rich e molti altri ancora. Sebbene di recente formulazione, si tratta di un profilo gi obsoleto sia perch basato sulla versione 1.3 delle specifiche ufficiali dello UML, sia perch la versione dellarchitettura EJB presa in considerazione la 1.1. Ci nonostante si tratta di un documento molto importante e ben congegnato, il cui adeguamento alle ultime versioni delle specifiche UML ed EJB non dovrebbe richiedere eccessivo lavoro. Obiettivo del profilo definire un mapping standard tra lo UML e larchitettura Enterprise JavaBeans (EJB). Il raggiungimento di tale obiettivo comporta: la definizione di un approccio standard per la modellazione di sistemi basati sullarchitettura EJB e quindi fondati sul linguaggio di programmazione Java; il supporto delle esigenze pratiche comunemente incontrate nel disegno di sistemi EJB-based;

UML e ingegneria del software: dalla teoria alla pratica

79

la definizione di una rappresentazione completa, accurata e non ambigua dei manufatti previsti dallarchitettura EJB corredati dalla relativa semantica limitatamente ai fini della modellazione; il supporto della costruzione di modelli di assemblati EJB frutto della combinazione di package creati utilizzando tool forniti da diversi produttori; la semplificazione del disegno di sistemi basati sullarchitettura EJB, in modo tale che gli sviluppatori da un lato non siano costretti a definire per conto proprio tecniche per la modellazione di sistemi EJB e dallaltro possano confidare in tecniche di reverse engineering compatibili con quanto disegnato; il supporto alle diverse fasi del ciclo di vita del software che implicano manufatti attinenti ai componenti EJB (modello di disegno, di sviluppo, deployment e runtime); lattuazione dellinterscambio di modelli di manufatti EJB prodotti per mezzo di tool forniti da diverse ditte produttrici; la compatibilit con tutte le API e gli standard del linguaggio di programmazione Java; la compatibilit con i profili UML per le analoghe tecnologie, come CORBA e il modello a componenti CORBA Per approfondimenti ulteriori sul profilo EJB si rimanda il lettore allAppendice C dove possibile trovare una trattazione pi dettagliata di tale profilo con una breve introduzione sulla tecnologia a oggetti distribuiti Enterprise JavaBeans.

Ricapitolando
Il presente capitolo stato dedicato alla disamina del linguaggio UML: una vera e propria overview. Lintento di iniziare a mostrare le potenzialit e i meccanismi dello UML senza avere assolutamente la pretesa di essere esaustivi: per ogni argomento presentato esiste un apposito capitolo in cui i vari concetti vengono illustrati dettagliatamente. Procedendo dallesterno verso linterno, lo UML composto da una serie di viste (Use Case, Design, Implementation, Component e Deployment) realizzate attraverso opportuni di diagrammi ognuno dei quali utilizza specifici elementi del modello. La prima vista, Use Case View (vista dei casi duso), utilizzata per analizzare i requisiti utente; specifica le funzionalit del sistema come vengono percepite da entit esterne allo stesso, dette attori.

80

Capitolo 2. UML: struttura, organizzazione, utilizzo

La Design View (vista di disegno), descrive come le funzionalit del sistema devono essere realizzate; in altre parole il sistema viene analizzato dallinterno. La Implementation View (vista implementativa, detta anche Component View, vista dei componenti), la descrizione del modo in cui il codice (classi per i linguaggi Object Oriented) viene aggregato in moduli (package) e di come questi dipendano gli uni dagli altri. La Process View (vista dei processi, detta anche Concurrency View, vista della concorrenza) rientra nellanalisi degli aspetti non funzionali del sistema, e consiste nellindividuare i processi e i processori. La Deployment View (vista di dispiegamento), mostra larchitettura fisica del sistema e fornisce lallocazione delle componenti software nella struttura stessa. Per ci che concerne i diagrammi, sono previste ben nove tipologie: Use Case, Class, Object, Sequence, Collaboration, StateChart, Activity, Component e Deployment. Utilizzando lo UML per rappresentare modelli di sistemi reali possibile riscontrare due lacune: linterfaccia utente e il disegno di database relazionali. Il problema che non esistono formalismi per rappresentare due modelli decisamente importanti nella realizzazione di sistemi informatici come linterfaccia utente e il disegno di database razionali. Per database Object Oriented possibile utilizzare i diagrammi delle classi e quelli degli oggetti. Sebbene il presente testo non si occupi di trattare in dettaglio i processi di sviluppo, si comunque preso in considerazione un processo di riferimento al fine di illustrare in maniera pi concreta lutilizzo dello UML. Spesso alcuni tecnici tendono a confondere lo UML con il processo di sviluppo: come ripetuto pi volte lo UML solo un linguaggio di modellazione e come tale si presta a rappresentare i prodotti generati nelle varie fasi di cui un processo composto. Pertanto lo UML, al contrario dei processi, non fornisce alcuna direttiva su come fare evolvere il progetto attraverso le varie fasi cos come non specifica quali sono i manufatti da produrre, chi ne responsabile ecc. Il problema che non esiste un processo standard universalmente accettato e tantomeno esiste un accordo sulle varie fasi e sui relativi nomi: ogni processo va adattato alle caratteristiche delle specifiche organizzazioni, ai progetti, e cos via. Brevemente ogni fase verr ripresa nei capitoli successivi i vari modelli da produrre sono: Modello business. Viene generato come risultato della fase di modellazione della realt oggetto di studio (business modeling). Lobiettivo capire cosa bisogner realizzare (requisiti funzionali e non), quale contesto bisogner automatizzare (studiarne struttura e dinamiche; a tal fine, spesso, si utilizzano i famosi Domain e/o Business Model), comprendere lorganigramma dellorganizzazione del cliente, valutare lordine di grandezza del progetto, individuare possibili ritorni dellinvestimento per il cliente, eventuali debolezze, potenziali miglioramenti, iniziare a redi-

UML e ingegneria del software: dalla teoria alla pratica

81

gere un glossario della nomenclatura tecnica al fine di assicurarsi che, nelle fasi successive, il team di sviluppo parli lo stesso linguaggio del cliente, e cos via. Modello dei requisiti. Questo modello viene prodotto a seguito della fase comunemente detta analisi dei requisiti (Requirements Analysis). Scopo di questa fase produrre una versione pi tecnica dei requisiti del cliente evidenziati nella fase precedente. Modello di analisi. Questo modello viene prodotto come risultato della fase di analisi i cui obiettivi sono di produrre una versione dettagliata e molto tecnica della Use Case View accogliendo anche le direttive provenienti dalle prime versioni del disegno dellarchitettura del sistema (che a loro volta dipendono da questo modello), realizzare un modello concettuale, analizzare dettagliatamente le business rules da implementare, revisionare il prototipo o comunque una descrizione dellinterfaccia utente. Modello di disegno. Anche in questo caso il modello di disegno il prodotto della omonima fase, in cui ci si occupa di plasmare il sistema, trasformare in un modello direttamente traducibile in codice i vari requisiti (funzionali e non funzionali) forniti nel modello dei casi duso di analisi. Modello fisico. Il modello fisico, a sua volta, composto essenzialmente da due modelli: Deployment e Component. Non si tratta quindi del prodotto di una fase ben specifica, bens sono risultati di rielaborazioni effettuate in diverse fasi. Il modello dei componenti mostra le dipendenze tra i vari componenti software che costituiscono il sistema. Come tale, la versione finale di tale modello dovrebbe essere il risultato della fase di disegno. Il modello di dispiegamento (Deployment) descrive la distribuzione fisica del sistema in termini del modo in cui le funzionalit sono ripartite sui nodi dellarchitettura fisica del sistema. Si tratta quindi di un modello assolutamente indispensabile per le attivit di disegno e implementazione del sistema. Modello di test. Nella produzione di sistemi, con particolare riferimento a quelli di medio/grandi dimensioni, opportuno effettuare test in tutte le fasi. Eventuali errori o lacune vanno eliminate prima possibile al fine di neutralizzare leffetto delle relative ripercussioni sul sistema. opportuno effettuare test prima di dichiarare conclusa ciascuna fase. In questo contesto si fa riferimento a uno specifico modello atto a verificare la rispondenza di ogni versione del sistema frutto di unappropriata iterazione. Il modello di test dovrebbe essere generato non appena disponibile una nuova versione stabile dei casi duso. Nel realizzare il modello di test necessa-

82

Capitolo 2. UML: struttura, organizzazione, utilizzo

rio: pianificare i test richiesti a seguito di ciascuna iterazione, disegnare e realizzare i test attraverso i Test Cases che specificano cosa verificare, e le Test Procedure che illustrano come eseguire i test. Quando possibile, sarebbe opportuno creare componenti eseguibili (Test Component) in grado di effettuare i test automaticamente, integrare i test necessari al termine delliterazione in corso con quelli eventualmente prodotti per le iterazioni precedenti. Modello implementativo. Questo modello frutto della fase di implementazione il cui obiettivo tradurre in codice i manufatti prodotti nella fase di disegno e quindi realizzare il sistema in termini di componenti: codice sorgente, file XML, file di configurazione, scripts, ecc. I diagrammi dei casi duso mostrano un insieme di entit esterne al sistema, detti attori, associati con le funzionalit che il sistema stesso dovr realizzare. Le funzionalit vengono espresse per mezzo di una sequenza di messaggi scambiati tra gli attori e il sistema. Lobiettivo dei casi duso definire un comportamento coerente senza rivelare la struttura interna del sistema. I diagrammi delle classi, a disegno completato, forniscono una rappresentazione grafica dellimplementazione del sistema eseguibile e sono costituiti da un insieme di classi, interfacce, collaborazioni e relazioni tra tali elementi. I diagrammi degli oggetti rappresentano una variante dei diagrammi delle classi, tanto che anche la notazione utilizzata pressoch equivalente, con le sole differenze che i nomi degli oggetti vengono sottolineati e le relazioni vengono dettagliate. Gli Objects Diagrams mostrano esplicitamente un numero di oggetti istanze delle classi e i relativi legami. I diagrammi di sequenza e collaborazione detti anche di interazione in quanto mostrano le interazioni tra gli oggetti che costituiscono il sistema vengono utilizzati per modellare il comportamento dinamico del sistema. I due diagrammi risultano molto simili: si pu passare agevolmente dalluna allatra rappresentazione (isomorfismo). Si differenziano per via dellaspetto dellinterazione a cui conferiscono maggior rilievo: i diagrammi di sequenza focalizzano lattenzione sullordine temporale dello scambio di messaggi, i diagrammi di collaborazione mettono in risalto lorganizzazione degli oggetti che si scambiano i messaggi. I diagrammi di stato essenzialmente descrivono automi a stati finiti, e pertanto sono costituiti da un insieme di stati, transazioni tra di essi, eventi e attivit. Ogni stato rappresenta un periodo di tempo ben delimitato della vita di un oggetto durante il quale esso soddisfa precise condizioni. I diagrammi delle attivit vengono utilizzati per illustrare il flusso di attivit coinvolte in un particolare processo. Sono particolarmente utili per mostrare esecuzioni del comportamento del sistema di alto livello che non coinvolgano dettagli interni come lo scambio di messaggi catturati da altri diagrammi.

UML e ingegneria del software: dalla teoria alla pratica

83

I Components Diagram mostrano la struttura fisica del codice in termini di componenti e di reciproche dipendenze. Insieme ai Deployment Diagrams costituiscono la vista fisica del sistema. I diagrammi di dispiegamento (Deployment) mostrano larchitettura hardware e software del sistema: vengono illustrati gli elementi fisici (computer, reti, dispositivi fisici) opportunamente interconnessi e i moduli software presenti su ciascuno di essi. In sintesi viene mostrato il dispiegamento del sistema a tempo di esecuzione sulla relativa architettura fisica, in termini di componenti e relative allocazioni nelle istanze dei nodi. Sebbene gli elementi del nucleo dello UML permettano di formalizzare molti aspetti di un sistema, impossibile pensare che da soli siano sufficienti per illustrarne tutti i dettagli. Pertanto, al fine di mantenere il linguaggio semplice, flessibile e potente allo stesso tempo, lo UML stato corredato sia di meccanismi generali utilizzabili per aggiungere informazioni supplementari difficilmente standardizzabili (per esempio le note), sia di veri e propri meccanismi di estensione (come per esempio gli stereotipi). I meccanismi generali forniti dallo UML sono: Notes (note): informazioni supplementari, scritte con un formalismo che pu variare dal linguaggio di programmazione, allo pseudocodice al testo in linguaggio naturale e pertanto difficilmente standardizzabili; Adornments (ornamenti): elementi grafici che permettono di aggiungere semantica al linguaggio al fine di fornire al lettore una cognizione diretta di aspetti particolarmente importanti di specifici elementi (come per esempio le cardinalit); Specifications (specificazioni): elementi di testo che aggiungono sintassi e semantica agli elementi dello UML, per esempio lelenco degli attributi e metodi presenti appartenenti alle classi. Common Divisions (divisioni comuni): nella modellazione di sistemi Object Oriented, ogni elemento reale pu essere diviso almeno in due modi diversi: lastrazione e il relativo corpo; si pensi al rapporto che esiste tra classi e oggetti; I meccanismi di estensioni forniti dallo UML sono: Stereotypes (stereotipi): permettono di estendere il vocabolario dello UML aggiungendo nuovi elementi, specifici per il problema oggetto di studio, ottenuti estendendo opportunamente quelli esistenti; Tagged Value (valori etichettati): estendono le propriet degli elementi dello UML, aggiungendo nuove informazioni costituite dalla coppia nomevalore.

84
Constraints (vincoli).

Capitolo 2. UML: struttura, organizzazione, utilizzo

Durante il processo di disegno di sistemi che utilizzano particolari tecnologie piuttosto ricorrenti nei progetti, necessario avvalersi di una serie di estensioni dello UML. Ci al fine di renderlo in grado di rappresentare adeguatamente le caratteristiche peculiari di suddette tecnologie. Lo OMG ha deciso pertanto di standardizzare questi insiemi di regole, detti profili, come veri e propri plug-in dello UML. Particolarmente utili sono i profili CORBA ed EJB.

Capitolo

3
Il problema di questo particolare progetto che le specifiche continuano a variare! LVT Un software veramente forte in grado di cambiare i propri utenti DONALT KNUTH

Introduzione agli Use Case

Introduzione
Il presente capitolo dedicato allillustrazione dei concetti forniti dallo UML per supportare il delicato processo di analisi dei requisiti utente; lattenzione sar puntata sulla sua prima vista: la Use Cases View (Vista dei Casi dUso). In questa fase della modellazione del sistema importante cercare di astrarsi il pi possibile dallimplementazione dello stesso: bisogna concentrarsi su cosa il sistema dovr fare e non sul come. Sebbene i casi duso siano utilizzati quasi esclusivamente per catturare i requisiti del cliente, essi si prestano a documentare funzionalit offerte da qualsiasi entit: sistema, sottosistema o classe. I casi duso sono modelli importantissimi nel contesto del ciclo di vita del software, sia perch sono quelli su cui il cliente appone la sua firma, sia perch stabiliscono in maniera inequivocabile o dovrebbero farlo quali funzioni il sistema dovr fornire, le relative modalit di fruizione nonch il modo in cui trattare eventuali anomalie che potrebbero verificarsi. Costituiscono inoltre, gi di per s un prodotto di eccezionale importanza da consegnare al committente, in quanto, corredate da altri manufatti il modello ad oggetti del dominio per esempio , le viste dei casi duso condensano lanalisi del business dellorganizzazione. La tecnologia evolve molto rapidamente, mentre in genere levoluzione del business si consideri per esempio un sistema bancario decisamente meno rapida. Pertanto i modelli dei casi duso si prestano a essere usate per molteplici funzioni:

Capitolo 3. Introduzione agli Use Case

implementazioni di nuove versioni del sistema, ottimizzazione dei processi interni, addestramento del personale, ecc. Come illustrato nel capitolo precedente, i processi di sviluppo prevedono diverse versioni di modelli dei casi duso: business e requirements (detta anche di sistema). Procedendo nelle varie fasi del processo si assiste a una graduale transizione sia del linguaggio, sia del livello di astrazione. Per ci che concerne il primo, si assiste a un progressivo passaggio dal linguaggio del cliente a quello tecnico. Per quanto riguarda il livello di astrazione, si passa da un livello elevato a uno sempre pi dettagliato fino a incorporare suggerimenti derivanti dallarchitettura del sistema. I processi di sviluppo del software pi popolari prevedono, tra laltro, lintegrazione di approcci Use Case Driven. Ci implica che la vista dei casi duso divenga il punto di riferimento per tutto il ciclo di sviluppo del sistema: dalla progettazione in termini sia di disegno, sia di architettura hardware allo sviluppo, ai test. La criticit della vista viene parzialmente attenuata dallintegrazione di altri approcci, quali, per esempio, Architecture Centric e Risk Driven. I modelli dei casi duso risultano costituiti da due proiezioni: statica e dinamica. La prima viene completamente catturata attraverso i diagrammi dei casi duso, mentre per la seconda sono disponibili diverse alternative che variano dal linguaggio naturale a opportuni diagrammi UML (sequence, activity, ecc.). La proiezione dinamica dovrebbe, illustrare sia le sequenze di attivit da svolgere quanto tutto funziona correttamente (best scenario, scenario migliore), sia lelenco completo degli inconvenienti che potrebbero insorgere, correlato dai provvedimenti che il sistema deve attuare per la relativa gestione. Quindi i programmatori, durante la fase di codifica, dovrebbero implementare il modello di disegno tenendo sotto controllo i casi duso relativi alla parte di sistema oggetto dello sviluppo. Da quanto detto, va da s che errori o lacune nelle viste dei casi duso determinano problemi in tutte le restanti viste, fino a giungere, in situazioni estreme, allinvalidazione della qualit del sistema finale: magari il sistema tecnicamente ben congegnato, realizzato rispettando tutti i canoni della produzione del software ma, semplicemente, non risolve i problemi del cliente. Non bisogna sempre pensare allutente come lasino di turno che inserisce i dati quando il cursore lampeggia in una casella. Al fine di minimizzare i rischi dovuti a possibili analisi dei requisiti approssimative o errate, si preferisce incorporare nel processo di sviluppo approcci di tipo incrementale e iterativo, tipicamente guidati dallattenuazione dei fattori di rischio. Ci permette di sottoporre al vaglio del cliente successive versioni del sistema per verificarne la rispondenza alle reali necessit ed eventualmente correggere tempestivamente la rotta. Lo stesso utente, potendo interagire con il sistema, o con una sua versione, riesce a chiarirsi le idee e a capire quanto i requisiti analizzati siano effettivamente rispondenti alle reali necessit: non a caso spesso si ricorre alla realizzazione di opportuni prototipi.

UML e ingegneria del software: dalla teoria alla pratica

La vista dei casi duso viene illustrata partendo dalla visione globale; ne viene illustrata la suddivisione in proiezione statica e dinamica, per poi scendere via via nei particolari, con un approccio tipicamente top down. In questa trattazione si deciso di non attribuire eccessiva attenzione al flusso delle azioni (descrizione del comportamento dinamico degli use case) cos come definito dai Tres Amigos in quanto, nella pratica, non infrequente il ricorso a tecniche sensibilmente divergenti da quelle standard in grado di apportare ambti benefici. Tali tecniche sono oggetto del capitolo successivo. Prima di entrare nel merito delloggetto di studio del capitolo, si ritenuto opportuno presentare una breve digressione su cosa si intenda con la famosa spesso misteriosa definizione di requisiti utente e in cosa consista il relativo processo di analisi: tutti i tecnici ne hanno una percezione pi o meno intuitiva, ma spesso ci che chiaro a livello intuitivo non in definitiva facile da rendere a livello pratico. Nel corso del capitolo si utilizzano i termini use case e la relativa traduzione in lingua italiana casi duso con significato assolutamente equivalente.

I requisiti utente
La realizzazione di un qualsiasi manufatto, e quindi anche di un nuovo sistema software, dovrebbe cominciare dalla raccolta dei relativi requisiti, la quale innesca il processo denominato ciclo di vita del software. Tipicamente la primissima fase denominata analisi del business, in cui le informazioni raccolte e opportunamente elaborate (modello del business) costituiscono i prodotti di input della fase di analisi dei requisiti vera e propria. Visto lo stretto legame esistente tra le due fasi e le sovrapposizioni, non sempre possibile effettuare una netta ripartizione tra le due. Liter inizia tipicamente con il team degli esperti analisti, corredato da qualche commerciale, che si reca presso il cliente. A dire il vero, nelle organizzazioni pi complesse il compito interamente demandato ad appositi team composti quasi esclusivamente dai famosi Business Analyst: persone esperte dellattivit economica del cliente. Obiettivi della prima spedizione sono essenzialmente due: 1. capire (o carpire) le esigenze che determinano la necessit di un nuovo sistema informatico o dellaggiornamento di quello esistente; 2. analizzare lo scenario del cliente con particolare attenzione alle risorse disponibili: umane, tecnologiche (parco macchine, connessioni, reti, software utilizzati) e, perch no, anche di budget. consigliabile iniziare con una serie di interviste ai manager, sia perch essi sono in grado di fornire una buona visione di insieme dellorganizzazione e della relativa attivit economica, sia per evitare di urtarne da subito la suscettibilit.

Capitolo 3. Introduzione agli Use Case

Gli analisti pi esperti fanno precedere a ogni intervista linvio di un documento riportante i quesiti e gli argomenti di cui si intende discutere: proprio come taluni giornalisti politici italiani (trascurabili pretese dei cosiddetti politici). In questo contesto, tuttavia, si tratta di un buon espediente sempre che i manager leggano il questionario.

Terminata la tornata iniziale, si redige un primo documento, corredato da un glossario, con la spiegazione degli acronimi e dei termini tecnici utilizzati (vocabolario del dominio del problema). Il passo successivo, purtroppo spesso trascurato, consiste nello scendere via via di livello nellorganigramma dellorganizzazione del cliente, fino a intervistare coloro che dovranno interagire direttamente con il sistema: i poveri utenti finali. Tipicamente, questi mancano di una visione dinsieme, ma in compenso conoscono ogni dettaglio sul modo in cui le procedure vengono realmente eseguite: dalla teoria alla pratica. Durante le interviste pu sorgere qualche problema: alcuni dipendenti, sentendosi minacciati dallintroduzione di un nuovo sistema e magari indagati in qualche modo sulle relative mansioni, tendono a divenire improvvisamente reticenti ed enigmatici. Terminata anche questa fase, si redige una seconda versione del documento e qui cominciano le dolenti note. Il problema che pu emergere a questo punto che le versioni fornite dai manager potrebbero risultare discordanti o addirittura contraddittorie rispetto a quelle fornite da coloro che eseguono fisicamente le varie procedure. A chi credere? Si tratta di affrontare leterno dilemma tra teoria e pratica. Cosa fare? Si reiterano le interviste, cercando di dettagliare maggiormente i punti controversi nel tentativo di rendere il tutto coerente, si riscrivono i vari documenti, ecc. Nei casi pi estremi necessario giungere a confronti allamericana si mettono i manager faccia a faccia con i subalterni nei quali, stranamente, le versioni dei manager tendono a prevalere. Si riorganizza di nuovo quello che ormai diventato un enorme ammasso di appunti e si redige un ennesimo documento che man mano ha acquistato anchesso di corposit. In questo documento sono condensati i famosi requisiti utente: le richieste legittime del cliente, le sue elucubrazioni mentali in termini tecnici si possono trovare sinonimi pi incisivi le distorsioni, le aspettative, tanti omissis Quando ci sono da esprimere pareri o suggerimenti, nessuno riesce a fare a meno di fornire la propria visione: ognuno vorrebbe dimensionare il nuovo sistema a propria immagine e somiglianza. Quando poi giunge il fatidico momento di firmare il documento delle specifiche, si assiste al gioco del fuggi fuggi meglio noto come secondo sport nazionale: lo scaricabarile. Infine, ottenuta la validazione dal cliente, non infrequente unattivit di rielaborazione: si comincia a lavorare sul serio.

UML e ingegneria del software: dalla teoria alla pratica

Il primo embrione di analisi dei requisiti tuttavia di grande interesse per i commerciali, in quanto d unidea del giro daffari che ruota intorno al progetto: fa capire quanto ci si possa guadagnare

Obiettivi dellanalisi dei requisiti utente


Durante la conduzione del processo di analisi dei requisiti utente risulta importante tenere bene a mente quali siano gli obiettivi che si vuole raggiungere, ossia: decidere e descrivere le specifiche, funzionali e non, concordate con il cliente le quali confluiscono nel contratto che lazienda sviluppatrice sottoscrive con il cliente; fornire una descrizione chiara e consistente delle funzionalit che il sistema dovr realizzare: prodotto guida delle altri fasi del ciclo di vita del software; generare un modello che consenta di eseguire il test del sistema; iniziare a progettare linterfaccia utente del sistema; disporre, attraverso le varie versioni degli use case, di una traccia dellevoluzione del sistema e/o dei requisiti utente (i quali, tipicamente, si automodificano a ogni ciclo lunare); eseguire la stima dei tempi e quindi dei costi; pianificare il processo di sviluppo del sistema (attribuzione delle priorit, definizione delle iterazioni, ecc.). Per poter realizzare la vista dei casi duso, necessario definire precisamente il sistema (in termine dei suoi confini), identificare correttamente gli attori, definire le funzioni dei vari diagrammi, determinare le relazioni tra use case e validare il sistema stesso. Si tratta di unattivit che richiede unelevata interazione con il cliente e con le persone che rappresentano gli attori del sistema stesso.

Sebbene ogni qualvolta venga proposto uno strumento dedicato allanalisi concettuale di un sistema si affermi che esso possa essere facilmente compreso da clienti con nessuna esperienza informatica (vedi diagrammi E-R e/o DFD), nella realt ci si verifica molto raramente: almeno questa la personale esperienza dellautore. Pertanto lanalisi dei requisiti deve essere comunque espres-

Capitolo 3. Introduzione agli Use Case sa anche per mezzo di strumenti non eccessivamente formali, quali per esempio opportuni template o addirittura il buon classico documento in linguaggio naturale. Inoltre sempre consigliabile pianificare opportune sessioni di training relative al formalismo utilizzato (per esempio use case), allo scopo di fornire agli utenti/clienti i requisiti necessari per leggere e interpretare i vari modelli che dovranno validare.

Pu succedere ogni riferimento alla vita reale dellautore puramente casuale di sviluppare elegantissimi diagrammi dei casi duso ben strutturati, colmi di relazioni e di generalizzazioni, giungere al momento di revisionarli con il team del cliente, e di vedere poi comparire progressivamente nei loro volti un certo sconforto di fronte al livello di astrazione prodotto.

bene ricordare che, seppure anche la vista dei casi duso debba essere un modello Object Oriented a tutti gli effetti, talvolta ahim necessario sacrificare parzialmente la propria formalit al fine di favorire il dialogo con il cliente.

Da tener presente che lo UML (secondo quanto riportato nei libri dei Tres Amigos) prevede di descrivere il comportamento dinamico dei casi duso per mezzo del relativo flusso di eventi, il quale specifica quando uno use case inizia, quando termina, quando interagisce con un attore, quali oggetti vengono scambiati, ecc. Il ruolo dei vari diagrammi dei casi duso, per tutta una serie di motivazioni, dovrebbe, in qualche modo, venir dimensionato a rappresentarne una sorta di overview. La speranza che lutilizzo di un formalismo grafico renda il tutto pi accattivante, immediato e comprensibile al cliente.

Chiaramente, attraverso una serie di grafici non possibile una completa descrizione di tutti i requisiti del cliente. Il monito da tenere sempre a mente che una deficienza grave nellanalisi dei requisiti pu generare grandi problemi nel processo di sviluppo del software. Ci per non deve neanche generare la paralisi del processo di sviluppo dovuta al timore di proseguire nelle fasi successive mentre i requisiti non sono ancora completi: in ultima analisi si utilizzano processi iterativi e incrementali anche per mitigare questi rischi. In ogni modo, la rappresentazione grafica decisamente utile e molto accattivante, ma assolutamente non sufficiente.

UML e ingegneria del software: dalla teoria alla pratica

Un ultimo solo in senso temporale di esposizione aspetto da tenere bene a mente che i requisiti utente variano: bisogna rassegnarsi allidea che, per quanto meticolosi, esperti e scaltri si possa essere, impossibile prevedere tutti i dettagli fin dallinizio. Sebbene ci possa apparire in contrasto con gli insegnamenti ricevuti nei banchi delluniversit, la realt che levoluzione insita nel destino delluniverso e che i sistemi informatici non esulano da tale regola. Il sogno di alcuni manager informatici consiste nel congelare le specifiche prima di proseguire nellattivit di codifica. Sebbene ci possa sembrare logico, si corre linsignificante rischio di realizzare un sistema, magari bellissimo, che per semplicemente non era quello desiderato dal cliente e che non di alcun aiuto: con un esempio, lutente ha bisogno di una scaletta per arrampicarsi sullalbero e gli viene fornito un ascensore adatto a un grattacielo.

Dunque, invece di investire un tempo eccessivo nellanalisi dei requisiti nel vano tentativo di studiare ogni dettaglio per realizzare un modello perfetto prima di procedere alla fase successiva, paralizzando tra laltro lintero processo, forse potrebbe essere opportuno cercare s di fare del proprio meglio, ma comunque avanzare con un processo di sviluppo di tipo iterativo e incrementale. Ovviamente ci non significa realizzare un prodotto di scarsa qualit tanto dovr cambiare. necessario anticipare il problema progettando sistemi flessibili, cercando di circoscrivere le aree pi a rischio di variazione, studiando opportuni piani per la gestione dei temutissimi change requirements. Indipendentemente dalla fase del ciclo di vita in cui ci si trova, il sistema varier e il desiderio di cambiare persister per tutto il ciclo di vita E.H. BERSOFF

Diagramma di diritti e doveri del cliente


Uno dei problemi storici nel mondo della progettazione dei sistemi informatici risiede nel difficile rapporto, in genere di carattere comunicativo, che spesso si instaura tra tecnici informatici e committenti che necessitano di sistemi informatici per migliorare la qualit e lefficienza del proprio lavoro. Si tratta di problematiche antiche che rivivono sotto forme moderne. Materia certamente nota: la conoscono tutti fin dai primi corsi di programmazione, eppure si continua a perseverare nellerrore in modo decisamente diabolico (con accezione latina). Obiettivo del presente paragrafo, giocando un po con i diagrammi dello UML, di illustrare quelli che dovrebbero essere diritti e doveri delle due parti in causa: team tecnici e utenti/clienti. Si deciso di presentare largomento utilizzando un espe-

Capitolo 3. Introduzione agli Use Case

diente tecnico: interfacce e componenti nel tentativo di rendere pi piacevole la trattazione. (Ci si augura che ci non disturbi leterno sonno delleccelso Cesare Beccaria A dire il vero ci sarebbero altri motivi ben pi reali del presente paragrafo per turbare il riposo del sommo pensatore). Uninterfaccia (in termini di classi) a tutti gli effetti un contratto tra classi client che utilizzano i servizi e la classe server che li fornisce. Nel contesto della presente trattazione, entrambi i componenti (team tecnico e cliente) espongono una propria interfaccia (si impegnano a erogare determinati servizi: quelli appunto definiti nella propria interfaccia) e utilizzano i servizi esposti dallinterfaccia dellaltro componente. Quindi entrambi presentano sia comportamento da client (utilizzano determinati servizi), sia da server (implementano i servizi dichiarati dalla propria interfaccia). Il componente Cliente, poich quello che alloca le risorse economiche, pu pretendere di accettare la sottoscrizione da un componente che esponga linterfaccia desiderata (offre precisi servizi). Quanto riportato nei prossimi paragrafi una rivisitazione tecnica di vari libri e articoli. Il contributo maggiore comunque dovuto, strano ma vero, alla rivista Microsoft Press e in particolare al Software Requirements di Karl Wiegers. Con riferimento alla fig. 3.1, di seguito viene presentata una disamina commentata dei vari metodi esposti nelle interfacce. La descrizione dei servizi esposti spesso si presta ad

Figura 3.1 Diagramma dei componenti di diritti e doveri dei clienti.

DoveriCliente
+clarifyRequirements( requirements ) +makeTimelyDecision( requirements ) +makeTimelyDecision( solutions ) +respectTimeAndCosts() +setRequirementsPriorities( requirements ) +reviewModel() +reviewPrototype() +notifyChangeRequirements() +respectSWDevelopmentsProcess()

Cliente

TeamTecnico

DoveriTeamTecnico
+setContextLanguage( businessLanguage ) +setBusinessRules( businessRules ) +setObjectives( objectives ) +getRequirementsModel() +getRequirementsModelExplanation() +getSolutionIdeas( requirements ) +getSolutionIdeas( newProblem ) +setClientRespect() +setProductEasyToUse( characteristics ) +changeRequirements( newRequirements ) +getChangeReqRealEstimation() +getQualitySystem()

UML e ingegneria del software: dalla teoria alla pratica

essere illustrata per mezzo della tecnica denominata design by contract (trattato in maggior dettaglio nel capitolo dedicato ai principi base dellObject Oriented), e in particolare attraverso: 1. prerequisiti: quando un client generico utilizza un determinato servizio esposto da un server deve impegnarsi a rispettarne le relative eventuali precondizioni; 2. requisiti durante lutilizzo: responsabilit dei server che espongono servizi garantire il soddisfacimento di determinate condizioni durante la fruizione del servizio stesso; 3. post condizioni: sempre i server, per ogni servizio esposto, devono assicurare, al termine dellerogazione dello stesso, il conseguimento dei risultati decretati nelle post condizioni, a patto chiaramente che i prerequisiti siano soddisfatti.

setContextLanguage(BusinessLanguage : Language)

Questo metodo indica che il componente TeamTecnico dovrebbe fornire un servizio che permetta di sincronizzare il proprio linguaggio con quello utilizzato dal cliente, in altre parole diritto di questi ultimi attendersi che il team degli analisti parli il linguaggio tecnico utilizzato nel proprio ambiente di business. Ci per comporta il dovere dei clienti di provvedere le risorse necessarie (in termini di personale, di strutture, di documentazione nonch di tempo) affinch il team tecnico possa raggiungere lobiettivo di appropriarsi del linguaggio. Utilizzando il design by contract si pu asserire: 1. i prerequisiti sono: il Cliente deve impegnarsi ad allocare le risorse necessarie per insegnare e verificare lesatto apprendimento del linguaggio tecnico del business; 2. i requisiti durante lutilizzo sono: il TeamTecnico garantisce di compiere ogni sforzo necessario per acquisire il linguaggio tecnico; 3. post condizioni sono: il team tecnico padronegger il linguaggio tecnico dellarea business nei limiti imposti dalle relative necessit e dal tempo a disposizione.

setBusinessRules(businessRules : businessRule[]) setObjectives(objectives : objective[])

10

Capitolo 3. Introduzione agli Use Case

In modo completamente analogo al caso precedente, del tutto legittimo attendersi che il cliente pretenda che il team tecnico acquisisca le regole vigenti nel proprio business e, in qualche modo, ne condivida gli obiettivi finanziari e strategici: i sistemi informatici, essendo parte importante di quelli informativi, recitano un ruolo di primaria importanza nel conseguimento degli obiettivi strategici delle aziende. Basti pensare ad esempio a siti e-commerce o a sistemi per la gestione degli investimenti bancari (area treasury).

RequirementsModel : getRequirementsModel() ModelExplanation : getRequirementsModelExplanation()

Altro diritto/dovere del cliente richiedere di visionare il modello dei requisiti e di ricevere tutte le spiegazioni del caso. Per quanto riguarda il primo metodo (getRequirementsModel), le precondizioni che deve rispettare il cliente sono di aver provveduto a invocare i metodi precedenti, ossia aver facilitato lapprendimento del proprio linguaggio, aver illustrato in maniera precisa e puntuale le business rules, aver spiegato i propri obiettivi ecc., mentre le condizioni durante luso, garantite dal TeamTecnico, sono che il modello verr prodotto in accordo alle informazioni fornite dal cliente e la post condizione che il modello fornito sar completo, rispondente alle esigenze del cliente e di elevata qualit tecnica. Per ci che riguarda il secondo metodo (getRequirementsModelExplanation), le precondizioni sono che il cliente abbia eseguito il metodo precedente, ossia abbia ottenuto una istanza del RequirementsModel. Le condizioni durante lutilizzo e le post condizioni sono piuttosto evidenti: il TeamTecnico deve adoperarsi per chiarire i dubbi espressi dal cliente e verificare se questi celino qualche requisito non detto e quindi fornire una spiegazione puntuale, precisa ed esauriente.

setClientRespect()

Questo metodo, in prima istanza, potrebbe sembrare piuttosto banale, e invece proprio il caso di commentarlo. Spesso i team tecnici sembrano non nutrire il dovuto rispetto per il cliente (in questo contesto si fa riferimento allutente finale). Troppo spesso si considerano i clienti come gli zucconi di turno agli ordini del cursore lampeggiante, i quali, per definizione, non riescono mai a impostare i dati in maniera corretta. Suggeriscono nulla uno dei primissimi assiomi della programmazione: il cliente uno sciocco o i famosi test dellasino da farsi per verificare se il sistema sia o meno a prova di utente? Talune volte sarebbe opportuno provare compassione (anche qui, accezione latina ovviamente) per la frustrazione spesso provata dai clienti che interagiscono con nuovi

UML e ingegneria del software: dalla teoria alla pratica

11

sistemi. Qualora tale frustrazione esista veramente, sarebbe il caso si interrogarsi se si fatto del tutto per neutralizzarla o quantomeno minimizzarla. Naturalmente, se gli utenti/clienti forniscono indicazioni (requisiti) errati, difficilmente verificabili, c poco da fare (vige lacronimo GIGO, Garbage In, Garbage Out ovvero entra spazzatura, esce spazzatura; a questo acronimo viene spesso preferita la pi prosaica versione SISO la cui traduzione viene demandata alla fantasia del lettore), ma se i tecnici si ingannano con unidea preconcetta basata sulla propria, sopravvalutata esperienza e trascurano lattivit di convalida con gli stessi utenti, allora difficilmente il sistema risulter soddisfare le reali necessit degli stessi. Per entrare nel giusto spirito si provi a immaginare di dover realizzare un sistema complesso utilizzando un framework esistente, magari fornito da terze parti, non intuitivo e con scarsa documentazione tecnica: a chi non capitato?

getSolutionIdeas(newProblem : Problem) getSolutionIdeas(requirement : Requirement)

Questi metodi decretano che il team di sviluppo deve essere in grado di comprendere le reali necessit del cliente eventualmente anche non dette o non pensate dal cliente ma comprese attraverso la sfera di cristallo chiamata esperienza e provvedere idee e alternative relative sia ai requisiti specificati dal clienti, sia a dubbi e perplessit palesate. In altre parole diritto del cliente ottenere proposte di soluzioni relative ai propri problemi e requisiti basate su esperienza e competenza del team tecnico. Qualora la famosa esperienza manchi, non comunque la fine del mondo: possibile sopperire con una buona dose di impegno e intelligenza; ma se mancano anche queste qualit la situazione diviene davvero complicata.

setProductEasyToUse(characteristics : Characteristic[])

Visto e considerato che il cliente finanzia il sistema e sar lui a utilizzarlo, dovrebbe essere del tutto comprensibile che si attenda di ricevere un prodotto il quale, ovviamente, assolva alle problematiche che ne hanno generato la necessit e che, al tempo stesso, sia semplice da utilizzarsi in funzione dei propri parametri/necessit. Talune volte i team tecnici costruiscono interfacce utente incomprensibili e disordinate o magari semplicemente ottimizzate in funzione della struttura del sistema o in base a quelle che erano considerate le esigenze dellutente dal team tecnico. Si tende banalmente a dimenticare chi sar il fruitore ultimo del sistema stesso. Non infrequente anche imbattersi in situazioni in cui lutente, per eseguire determinate funzionalit ricorrenti, sia costretto a eseguire tortuosi giri e incomprensibili procedu-

12

Capitolo 3. Introduzione agli Use Case

re, mentre sarebbe del tutto legittimo attendersi un utilizzo pi lineare, eventualmente ottimizzato in base ai servizi richiesti pi frequentemente. Nei casi peggiori, sempre molto frequenti, le complicatissime interfacce utente sono solo la punta delliceberg Accade che lintero modello del sistema sia basato su intuizioni tecniche, magari anche interessanti, ma lontanissime dalla realt Nella fase di consegna si assiste alle crisi isteriche dellintuitore: Ma come? Non si riesce a forzare la realt alla struttura del sistema?.

ChangeRequirements(newRequirements : Requirements[])

Questo indubbiamente il metodo che incute pi paura di tutti: basta il nome per generare tremori nel team tecnico. Sfortunatamente si tratta di una pretesa legittima del cliente: lobiettivo comune delle parti dovrebbe essere quello di progettare un sistema di qualit che effettivamente soddisfi il cliente e non di consegnare qualcosa di eseguibile. In altri ambienti, per esempio nella costruzioni di edifici, risultano accettabili incursioni nel cantiere dei committenti con eventuali richieste di modifiche. Pertanto non c da stupirsi che, iniziando a vedere il sistema reale e cominciando a interagirvi il cliente possa chiederne dei cambiamenti, perch per esempio non era riuscito a capire in anticipo eventuali problematiche o semplicemente perch erano state fraintese. Come al solito necessario un mea culpa: quando lutente invoca il fastidiosissimo metodo changeRequirements, quanta colpa ha veramente il cliente? Spesso accade anche che il team tecnico, pur avvertendo difficolt o incongruenze, semplicemente le ignori dimenticando che prima o poi il problema si ripresenter, ma questa volta amplificato dal fattore tempo. Continuando con lesempio delledificio, un po come se la squadra che lo sta costruendo si rende conto che gli spazi lasciati per le tubature sono assolutamente insufficienti, ma prosegue ugualmente nella costruzione, dimenticando che prima o poi bisogner demolire il tutto e ricostruire e questa volta con pochissimo tempo a disposizione. Limportante fornire ledificio per la data di presentazione prevista, e poi Poi sempre possibile inserire delle toppe.

Estimation : getChangeReqRealEstimation(newReq : Requirement)

Questo metodo strettamente collegato a quello precedente. In caso di richiesta di cambiamenti dei requisiti, sarebbe naturale da parte del cliente ottenere una stima attendibile e onesta dei tempi necessari per soddisfare tali richieste. Nella realt accade che le richieste ritenute pi divertenti e meno ostiche tendano a ricevere una stima ottimistica, mentre altre, magari anche molto importanti, tendano a venir sovrastimate. A onor del vero va detto che, indubbiamente, uno dei principali moti-

UML e ingegneria del software: dalla teoria alla pratica

13

vi di sollecitudine dei team tecnici consiste nel giocare con nuovi giocattoli. Qualora venga fiutata la possibilit di poter cogliere loccasione per utilizzare nuove tecnologie, le stime tendono improvvisamente a divenire molto ottimistiche, mentre il caso contrario implica stime funeste.

System : getQualitySystem().

Il commento di questo metodo viene deliberatamente lasciato al lettore. Esaurita lanalisi dei diritti del cliente, si passa ora a esaminarne i doveri Alcuni di essi sono gi stati espressi per mezzo di precondizioni dei metodi del TeamTecnico. In particolare dovere del cliente insegnare il linguaggio tecnico, le regole dellambiente oggetto di analisi, cercare di spiegarsi nel modo pi chiaro possibile, ecc. A tal fine il cliente deve allocare tutte le risorse necessarie, tra cui il tempo, per illustrare, spiegare, verificare e cos via.

Clarification[] : clarifyRequirement(requirements : Requirement[])

Responsabilit dei clienti fornire i requisiti al TeamTecnico, allocando il tempo necessario per chiarire quelli ritenuti meno evidenti. importante che sia i requisiti, sia le relative spiegazioni siano precise e concise.

Decision[] : makeTimelyDecision(requirements : Requirement[]) Decision[] : makeTimelyDecision(solutions : Solution[])

Altra responsabilit dei cliente consiste nel prendere decisioni e nel farlo in tempi umani e non geologici. In generale le decisioni del cliente dovrebbero essere relative sia alla selezione delle ipotesi di soluzioni ritenute pi valide tra quelle esposte dal TeamTecnico, sia relative a requisiti non chiari o di costoso ottenimento. In merito alla selezione delle varie alternative di soluzioni viene alla mente il film La vita bella Cosa gradisce? Del maiale grasso grasso grasso con patate cotte in olio grasso grasso grasso oppure del salmone leggero leggero leggero con uninsalata leggerissima?. Cosa sceglier mai il cliente? La vocina presente nellautore afferma che molti clienti sceglierebbero comunque il maiale grasso grasso grasso

respectTimeAndCosts()

14

Capitolo 3. Introduzione agli Use Case

Questo metodo pu essere visto come lo speculare del metodo setRespect(): cos come il TeamTecnico deve rispettare il cliente, allo stesso modo, questultimo deve rispettare la stima dei tempi e dei costi fornita dal TeamTecnico, e produrre ogni sforzo per limitare le proprie richieste di ridurre i tempi per la messa in opera del sistema. Quando le pressioni del cliente cominciano a essere eccessive, si vede la differenza tra capi progetto allaltezza del proprio ruolo e quelli che credono che il capo progetto colui che inserisce una serie di numeri nelle caselline del progetto realizzato per mezzo di Microsoft Project. Un altro problema tipico, che si verifica di sovente, relativo al fatto che clienti/utenti desidererebbero esporre molto rapidamente, si intende, le funzionalit richieste, o magari addirittura solamente nominarle, per poi vedersele perfettamente incorporate nel sistema nellarco di qualche giorno. Come dire che i clienti tendono a non rispettare il processo di sviluppo del software adottato dal team tecnico. Da un lato si richiede elevata qualit e dallaltro si pretende di ottenerla subito.

setRequirementsPriorities(priorities : RequirementsPriority[])

Su questo argomento si ritorner pi in dettaglio nel paragrafo dedicato al processo di sviluppo. Per adesso basti pensare che necessario che il cliente corredi i vari requisiti con le relative priorit. importante per sottolineare che queste devono ritenersi a carattere prettamente indicativo, in quanto lordine con cui le varie funzionalit verranno realizzate deve dipendere dal piano di suddivisione del processo in iterazioni: compito dellarchitetto e del capo progetto decidere tale piano in funzione anche di altri parametri, quali per esempio la riduzione dei rischi.

reviewModel() reviewPrototype()

Altro compito molto importante dei clienti consiste nel revisionare i modelli prodotti dal TeamTecnico. Spesso si tratta di unattivit tediosa e non priva di elementi di frustrazione, per di importanza fondamentale per il processo di sviluppo del sistema. Una volta validati i vari modelli si prosegue con lo sviluppo del sistema ed eventuali errori nelle specifiche possono generare conseguenze notevoli. Chiaramente il colloquio tra il team tecnico e il cliente non si esaurisce qui: sempre cosa buona e giusta chiedere ai clienti ulteriori chiarificazioni in caso di incertezze relative ai requisiti o proporre nuove idee. Ci dovrebbe essere del tutto naturale: si assiste spesso a persone che volendo costruire la propria casa, cominciano non solo a visionare i vari progetti, ma anche a metterci le

UML e ingegneria del software: dalla teoria alla pratica

15

mani in prima persona. Chiaramente se dovesse accadere che, per esempio, la cucina risulti troppo piccola, sarebbe compito dellarchitetto, in funzione della propria esperienza, evidenziare lanomalia. Per ci che concerne il metodo reviewPrototype(), non ci sono dubbi: il cliente adora a sua volta giocare con i nuovi giocattoli e quindi sicuramente spender il tempo necessario, se non di pi, per analizzare i prototipi in tutti i suoi dettagli. I limiti dei prototipi sono stati evidenziati nel capitolo precedente, e li si pu sintetizzare riproponendo il commento di Stroustrup: il loro difetto principale di somigliare terribilmente al sistema finale.

notifyChangeRequirements()

Questo metodo evidenzia una responsabilit fondamentale del cliente: comunicare i cambiamenti di specifiche non appena avvertiti. Nel caso in cui, eseguendo unincursione nella casa in costruzione, il cliente si accorga che la cucina effettivamente troppo piccola, lo dovrebbe comunicare immediatamente senza attendere che i vari muri divisori siano edificati e che quindi una loro risistemazione diventi piuttosto gravosa se non impossibile.

respectSWdevelopmentProcess()

Spesso una delle manchevolezze dei clienti di non rispettare il processo di sviluppo del software, nel senso che loro tendenza naturale di desiderare la botte piena e la moglie ubriaca: sistema di qualit corredato dai vari modelli e realizzato in un paio di fasi lunari. I sistemi software, alla stregua degli altri prodotti ingegneristici, prevedono opportune fasi e diversi modelli da produrre, ognuno dei quali richiede un certo quantitativo di tempo. Spesso sono gli stessi clienti che richiedono di codificare direttamente per poter giocare il prima possibile con il sistema. In ogni modo, il sogno dei clienti/utenti di comunicare le funzioni da realizzare, magari semplicemente citandone il nome, e poi iniziare a effettuare i vari test dopo qualche giorno. Spesso palesare linattuabilit di questo sogno diviene impossibile da parte di qualche commerciale di turno, ansioso forse di mascherare o farsi perdonare qualche marachella magari commessa in fase di fatturazione. La relativa decisione, a questo punto obbligatoria, di tenersi buono il cliente porta a promettere cose la cui portata esula assolutamente dalle reali possibilit Iterato poi il comportamento per un almeno un paio di generazioni, si ottiene la mutazione genetica anche dei clienti. Daltronde si immagini di voler costruire la propria casa e per questo convocare due ditte edili per ottenere altrettanti preventivi. Si supponga ancora che laddetto commer-

16

Capitolo 3. Introduzione agli Use Case

Figura 3.2 Rappresentazione schematica della proiezione statica della use case view.
STATIC PERSPECTIVE
USE CASE DIAGRAM

ACTOR

USE CASE VIEW


DINAMIC PERSPECTIVE
DOCUMENT

USE CASE

RELATIONSHIP

DESIGN VIEW

TEMPLATE

SEQUENCE DIAGRAM

COMPONENT VIEW
ACTIVITY DIAGRAM

IMPLEMENTATION VIEW

DEPLOYMENT VIEW

ciale della prima vi dica: Non c problema, in un paio di settimane inizieremo i lavori. La mia azienda dispone di squadre di muratori e carpentieri che sono degli artisti. Lavoreranno come forsennati per consegnarvi la casa dopo sei mesi. Il tutto per un costo di centomila euro, migliaio in pi o in meno. Laddetto commerciale della seconda ditta, invece, vi dir: In effetti necessario capire che tipo di casa si vuole e quale sia conveniente costruire, verificare il terreno, esaminare il piano regolatore, realizzare qualche progetto di massima insieme. Solo allora sar possibile una stima appropriata. In ogni modo lo studio iniziale di fattibilit le coster sui cinquemila euro. Ora, quanti di voi affiderebbero la costruzione della casa alla seconda azienda?

Use Cases View


Le use case view (viste dei casi duso) nei processi di sviluppo del software assumono un ruolo di primaria importanza, sia perch vengono sottoposte alla firma del cliente generalmente quella dei requisiti utente e, per la firma, si consiglia di richiedere lutilizzo del sangue come inchiostro , sia perch le restanti viste si occupano di modellare

UML e ingegneria del software: dalla teoria alla pratica

17

quanto specificato in quella dei requisiti. La proiezione statica della vista dei casi duso si basa sugli omonimi diagrammi, frutto del lavoro svolto da Ivar Jacobson durante la sua collaborazione con la Ericsson nellambito dello sviluppo di un sistema denominato AXE. Visto il successo riscosso dai diagrammi e percepitene le relative potenzialit, i Tres Amigos hanno pensato bene di inglobarli nello UML. Gli use case diagram sono utilizzati per dettagliare le funzionalit del sistema, dando particolare rilievo agli attori che interagiscono con esse. Le singole funzionalit vengono rappresentate graficamente attraverso elementi ellittici denominati use case. A questo punto si corre il rischio di fare confusione. In effetti, la prima vista logica, i relativi diagrammi, o meglio quelli che si occupano della proiezione statica, e alcuni elementi di questi ultimi, quelli che rappresentano le funzioni del sistema, si chiamano tutti, grazie a un sovrumano lavoro di fantasia, use case. Per tentare di far chiarezza si consideri il diagramma riportato in fig. 3.2. La prima vista quindi composta da pi diagrammi, di cui quelli derogati a modellarne la proiezione statica sono gli use case diagram, i quali permettono di specificare le funzioni del sistema per mezzo di elementi grafici a forma di ellissi detti use case. La vista dei casi duso, come gran parte dei modelli, prevede due componenti: statica e dinamica, di cui solo la prima rappresentabile per mezzo dei use case diagram. Quindi, al fine di colmare la lacuna e modellare anche la proiezione dinamica, fanno la loro apparizione gli interaction e activity diagram (diagrammi di interazione e diagrammi di attivit), utilizzati per rappresentare particolari istanze dei casi duso dette scenari. Entrambi sono oggetto di studio di appositi capitoli; per ora basti sapere che servono per modellare aspetti dinamici del sistema. Nei paragrafi seguenti si evidenzia che il ricorso a tali diagrammi, sebbene permetta di illustrare il comportamento dinamico delle funzioni del sistema, pu risultare decisamente laborioso e non sempre di facile lettura. Probabilmente opportuni template dei casi duso finiscono per essere lo strumento migliore: sono chiari, immediati e decisamente facili da aggiornare. Quando i diagrammi di interazione vengono utilizzati nella use cases view, ne realizzano gli scenario: versioni a elevato grado di astrazione dei flussi di azioni racchiusi nei casi duso. Tipicamente, degli stessi diagrammi vengono realizzate versioni di maggior dettaglio nella design view allo scopo di rappresentare il flusso dei messaggi che gli oggetti si scambiano per produrre un determinato risultato. Semplificando al massimo il concetto, possibile affermare la seguente proporzione: gli scenari stanno agli use case come gli oggetti stanno alle classi. Talune volte pu capitare di incontrare in opportune versioni degli use case view anche diagrammi delle classi: ci una buona norma a patto che il grado di astrazione degli stessi rimanga al livello concettuale e che le classi identificate siano quelle appartenenti al mondo reale e non allinfrastruttura del sistema (si parla di modello del dominio). Lobiettivo quello di modellare e quindi studiare le relazioni esistenti tra le varie entit presenti nellarea di business del cliente (dominio del problema).

18

Capitolo 3. Introduzione agli Use Case

A lavoro concluso, i diagrammi dei casi duso devono rappresentare tutte le funzioni del sistema, a partire dal relativo avvio, o richiesta, che tipicamente viene generata da un attore del sistema, fino alla relativa conclusione. Le propriet che tutti i modelli dovrebbero possedere (accuratezza, consistenza, semplicit e manutenibilit) in questo contesto assumono unimportanza imprescindibile. Gli attori, sono entit esterne al sistema che hanno interesse a interagire con esso. Pertanto, contrariamente a quanto lascerebbe pensare il nome, e a memorie derivanti da metodologie quali DFD (Data Flow Diagram, diagramma del flusso dei dati), gli attori sono sia persone fisiche, sia sistemi o dispositivi hardware che interagiscono con il sistema. Va sottolineato, per lennesima volta, che a questo livello di analisi, il sistema va visto come una scatola nera, pertanto si deve descrivere cosa fa il sistema senza specificare il come: ci si deve occupare dello spazio del problema e non di quello delle soluzioni. Limpegno proprio nel cercare di isolarsi, di astrarsi il pi possibile da dettagli realizzativi il cui studio demandato alle apposite fasi.

Perch utilizzare i diagrammi dei casi duso?.


Linterrogazione posta nel titolo potrebbe risultare piuttosto retorica e la risposta piuttosto convenzionale potrebbe essere: perch fanno parte dello UML. Allora si provi a porla in questi termini perch i Tres Amigos hanno inserito i diagrammi dei casi duso nello UML? Quali sono i vantaggi?. Molto brevemente le principali peculiarit dei casi duso possono ricondursi ai seguenti punti: si tratta di uno strumento facilmente comprensibile dagli utenti e quindi appropriato per comunicare con essi e per ottenere le necessarie validazioni. si prestano a essere utilizzati con diversi livelli di formalit. Generalmente, nella primissime fasi si concentrati nel comprendere pi intimamente le necessit dellutente e quindi si conferisce minore importanza ai principi dellObject Oriented, anche perch spesso non facilmente comprensibili dallutente medio. Nelle fasi successive invece si anche coinvolti nel processo di sviluppo del sistema e quindi il livello di formalit deve essere necessariamente elevato. permettono di definire molto chiaramente i confini del sistema e di evidenziarne gli attori sia umani che non. evidenziano il comportamento del sistema, permettendo di evidenziare eventuali incoerenze e lacune nellanalisi dei requisiti.

UML e ingegneria del software: dalla teoria alla pratica

19

permettono di realizzare unottima documentazione. i casi duso opportunamente strutturati si prestano a essere utilizzati come scenari di test (i test case).

Fruitori della use case view


La vista dei casi duso oggetto di interesse per un vasto insieme di figure professionali coinvolte nel ciclo di vita del sistema: dai clienti ai capi progetto, dagli architetti ai tester, dagli addetti al marketing ai commerciali e cos via. I primi, in ordine cronologico, a fruire della vista dei casi duso sono i clienti, i capi progetto e i business analysts: le use case view specificano le funzionalit che il sistema dovr realizzare e come queste verranno fruite. In questottica le viste sono necessarie per riuscire a carpire i requisiti utente: reali necessit, sogni pi o meno consci, eventuali reticenze In molte organizzazioni sono previsti opportuni team che si occupano unicamente di analizzare lattivit economica del cliente, di capire i requisiti del sistema e di redigere il documento dei requisiti. Sono i padroni della use case view. Queste figure professionali vengono tipicamente denominate business analysts. La vista dei casi duso necessaria poi al team degli sviluppatori (architetti, disegnatori, codificatori) poich fornisce direttive, chiare e precise un sogno su come realizzare il modello. In questo contesto, con il termine di architetti si fa riferimento a quelli software, ossia a coloro che si occupano di disegnare il sistema in termini di classi. Ovviamente anche gli architetti hardware hanno interesse a fruire della vista degli use case perch fornisce le prime disposizioni su come organizzare il sistema in termini di dispositivi fisici (server, connessioni, proxy, ecc.). Come si avr modo di vedere nel capitolo dedicato, nei processi di sviluppo use case driven e architecture centric esiste una mutua dipendenza tra la use case view e la vista fisica del sistema: le funzionalit da realizzare forniscono lorientamento iniziale su come organizzare linfrastruttura hardware cos come questultima influenza la modalit con la quale le diverse funzioni possono essere fruite. Da tener presente che la proiezione dinamica oltre a dettagliare la sequenza di azioni da svolgere, nel caso in cui tutto funzioni correttamente, dovrebbe riportare anche la casistica completa degli inconvenienti che potrebbero verificarsi durante lesecuzione del caso duso e le relative contromisure che il sistema dovrebbe attuare come risposta. Pertanto durante la progettazione e limplementazione del sistema, il team di sviluppatori dovrebbe aver ben presente i casi duso a cui si riferisce la parte del sistema oggetto di disegno o implementazione. Altra categoria di utilizzatori costituita dalle persone che dovranno effettuare le verifiche finali (note anche come test di sistema): lutilizzo di tale vista consente di verificare che il sistema prodotto realizzi pienamente ci che stato sancito con il cliente.

20

Capitolo 3. Introduzione agli Use Case

Sebbene in molte organizzazioni i test vengano eseguiti solo dagli sviluppatori e dallorganizzazione presente presso il committente, nelle organizzazioni pi strutturate sono previsti appositi team (detti martellatori in quanto il loro obiettivo prendere a martellate il sistema) che si occupano della delicata fase di test. In generale, non un buon principio far eseguire i test allo stesso personale che ha prodotto lo specifico artifact: i programmatori non dovrebbero essere i soli a verificare il proprio codice. Il problema che chi realizza un prodotto tende, inconsciamente, a trascurare verifiche di situazioni critiche e meno chiare che, per questo, divengono pi soggette a errori. A tal fine, chi effettua i test deve possedere una buona conoscenza dei requisiti utente e quindi della use case view. A dire il vero, solo per la fase di test, si dovrebbero realizzare apposite versioni delle use case view denominate test case. Dallelenco dei fruitori si vogliono poi escludere i commerciali? Ma certo che no. Anzi, sarebbe auspicabile che taluni commerciali e addetti al marketing dessero unocchiata a quanto prodotto, giusto quel tanto che basta per capire di cosa dovranno parlare nelle varie riunioni con i clienti ed evitare di basare i propri giudizi unicamente sulla scelta dei colori presenti nelle interfacce utente. Si potrebbe addirittura correre il rischio di evitare di vendere congelatori agli esquimesi ed impianti di riscaldamento a chi vive allequatore. Oppure potrebbero evitarsi frasi del tipo Perch ci vuole cos tanto a realizzare un sistema?. Ma chi glielo fa fare di stare a competere con questi tecnici paranoici e schizoidi? In fondo, esistono centinaia di lavori migliori di questo Gestire un banco di frutta difficile, le mele hanno la brutta abitudine di andare a male Troppo complicato, meglio il software, l si pu buttare tutto in caciara e un responsabile esterno si riesce sempre a trovarlo.

Processo di sviluppo, useless case e IDP


Il processo di sviluppo del software una delle risorse come tale dovrebbe essere considerato pi importanti delle aziende produttrici di software: tra le varie caratteristiche, fornisce al progettista e ai vari elementi del team direttive precise su cosa fare, quando farlo, come, dove e perch. In sintesi la corretta adozione di un processo, da sola, pu fare la differenza tra un progetto di buona riuscita e un insuccesso. Sebbene non esista il processo valido in assoluto o che risulta ottimale per ogni progetto, non sono infrequenti aziende software che si affidano al famoso processo di sviluppo denominato IDP (Irrational Development Process, processo di sviluppo irrazionale), tipicamente composto da tre fasi: 1. analisi dei requisiti;

UML e ingegneria del software: dalla teoria alla pratica

21

2. codifica; 3. test. A complicare ulteriormente la situazione spesso interviene unanalisi dei requisiti sommaria magari effettuata solo parzialmente (gli useless case, casi inutili) da migliorarsi durante il processo di codifica, o addirittura durante e/o dopo i test. Limperativo dellIDP, da trentanni a questa parte, sempre lo stesso: liquidare le fasi iniziali per dedicarsi alla codifica e solo alla codifica. Parlando seriamente, i processi di sviluppo razionali prevedono invece una successione eventualmente iterata per uno sviluppo incrementale del sistema decisamente pi articolata (analisi business, requisiti utente, analisi, disegno, codifica, test). Nei processi iterativi e incrementali, le prime iterazioni (tipicamente due o tre) sono focalizzate quasi esclusivamente sullanalisi dei requisiti, attivit che, naturalmente, dovrebbe tendere gradualmente a zero nelle successive iterazioni. Realizzare un buon modello dei casi duso non assolutamente semplice, tuttavia esiste una serie di regole e accorgimenti che aiutano a prevenire la realizzazione dei succitati useless cases. Ci che assolutamente non va dato per scontato che gli utenti sappiano effettivamente quello di cui hanno bisogno: ci si verifica raramente. Molto pi frequentemente i clienti diventano pienamente consapevoli delle proprie necessit solo durante il processo di sviluppo o addirittura a sistema ultimato: per questo cosa buona decomporre il processo in una successione ponderata di iterazioni che permettano di controllare i rischi. In altri casi semplicemente pretestuoso pensare di riuscire a catturare le necessit di tutti gli utenti fin dallinizio. Si provi a immaginare un nuovo sistema che non preveda simili nel suo genere o sistemi Internet destinati a un potenziale e vastissimo pubblico. Logica conseguenza di ci limpossibilit sia di definire completamente i requisiti prima di poter passare alle fasi successive del processo di sviluppo, sia di poterli congelare. Questo concetto, particolarmente caro ai manager, purtroppo non applicabile: il sistema destinato a evolvere e i requisiti diventano pi chiari con lo sviluppo del sistema. Ci non significa assolutamente che le fasi di analisi e disegno siano inutili, o che sia sufficiente procedere con unanalisi grossolana dei requisiti utente, sebbene ci farebbe piacere a molti tecnici. Compito del team tecnico, e in particolare degli analisti, aiutare lutente a comprendere pi approfonditamente le proprie esigenze e a rifinire i requisiti. Questi obiettivi diventano raggiungibili realizzando opportuni modelli (use case, domain object model, ecc.). Onde evitare problemi di incomprensione e analisi dei requisiti completamente assurde, spesso intervengono nel processo particolari tipologie di utenti: i business analyst, persone esperte della realt oggetto di studio con qualche background tecnico. Per la particolare tipologia delle loro mansioni, si tratta prevalentemente di consulenti.

22

Capitolo 3. Introduzione agli Use Case

Possono essere paragonati a sistemi di wrapper: da un lato parlano lo stesso linguaggio del cliente regola basilare nellanalisi dei requisiti e dallaltro riescono a interagire con sistemi decisamente pi tecnici. Risulta importantissimo adattarsi il pi possibile al linguaggio dei clienti, i quali devono essere in grado di leggere e comprendere quanto emerso dallanalisi dei requisiti al fine di essere in grado di fornire il relativo preziosissimo feedback e, dal punto di vista dei project manager, di firmare il documento delle specifiche.

Durante questa fase fortemente consigliato redigere un glossario dei termini utilizzati soprattutto con riferimento allarea del cliente (business). Il glossario offre una serie di vantaggi e in particolare: 1. permette di verificare che si stia effettivamente utilizzando lo stesso gergo del cliente e che non ci siano equivoci relativi al significato dei termini; 2. offre un punto di riferimento per le fasi successive e in particolare rende pi difficile attribuire i nomi alle classi con un criterio noto con il neolatinismo ad cacchium.

Il risultato dellindagine dei business analyst consta, tipicamente, di un voluminoso documento, il quale, nella maggioranza dei casi, risulta stracarico di business rules (regole e procedure dellambiente oggetto di studio) ma povero non potrebbe essere altrimenti dal punto di vista dellapporto tecnico, spesso non completamente consistente e non privo di lacune: difficile riuscire a essere chiari e coerenti in documenti cos voluminosi, spesso infarciti di singolarissimi e incomprensibili diagrammi utilizzanti formalismi creati alluopo dagli autori del documento stesso. Nel mondo dei sogni, i business analyst dovrebbero essere in grado di produrre totalmente o parzialmente la use case view Si tratta per del mondo dei sogni. Ci nonostante, il documento fornito dai business analyst risulta preziosissimo per la successiva fase: realizzazione della vera e propria use case view. I modellatori spesso, anche se non dovrebbe essere cos, si tratta degli stessi architetti dovrebbero razionalizzare e trasformare il precedente documento nel modello della vista dei casi duso, la quale, nella fase di analisi, deve risultare decisamente formale: si tratta comunque di un modello Object Oriented. Durante questo processo possibile eliminare immancabili incoerenze presenti nel documento dei requisiti, colmare eventuali lacune, aumentare la componente tecnica e incorporare elementi provenienti dalle prime versioni del disegno dellarchitettura. Indipendentemente dai nomi che si vogliono attribuire alle varie fasi, di solito si prevedono almeno due versioni di modelli dei casi duso:

UML e ingegneria del software: dalla teoria alla pratica

23

il primo (tipicamente denominato business) pi astratto caratterizzato da un livello tecnico informatico contenuto e da un linguaggio e un formalismo adeguati a quelli del cliente; il secondo (generalmente denominato di sistema) decisamente pi particolareggiato derivante sia dallapprofondimento del modello precedente, sia dallassorbimento di direttive provenienti dal disegno dellarchitettura tecnica. Nella seconda versione dei casi duso, generalmente, si cerca di far confluire direttive provenienti dai requisiti di tipo non funzionale, ossia requisiti che non dipendono direttamente dal cliente e dai servizi che si vogliono ottenere dal sistema, bens da fattori di ordine pi tecnico: performance, affidabilit, robustezza, flessibilit, estensibilit, ambiente, e cos via. Per esempio, non infrequente riportare nellanalisi delle singole funzionalit il lasso di tempo entro il quale il sistema dovrebbe essere in grado di erogare i servizi forniti. Quindi la versione del modello dei casi duso a livello di sistema deve incorporare vincoli e indicazioni provenienti dal disegno dellarchitettura fisica. Il problema che potrebbe sorgere che a sua volta larchitettura del sistema dovrebbe poter essere stabilita solo dopo che la use case view sia disponibile. Si corre pertanto il rischio di innescare un circolo vizioso. La soluzione che tipicamente viene adottata consiste nel realizzare prime versioni di casi duso delle funzionalit ritenute pi importanti e quindi fornirle allarchitetto del sistema. Questultimo, analizzando la versione embrionale della use case view e cercando di riadattare precisi pattern architetturali, dovrebbe essere in grado di realizzare un disegno iniziale dellarchitettura. Cos facendo, lavorando per approssimazioni successive, si rimuove il rischio di generare un circolo vizioso. Linterazione tra le due viste continua fino al completamento di entrambe in cui il tutto deve necessariamente risultare coerente (fig. 3.3).

Figura 3.3 Mutua dipendenza tra modello dei casi duso e quello dellarchitettura fisica.

Modello use case

Architettura fisica

24

Capitolo 3. Introduzione agli Use Case

Tabella 3.1 Modulo per la ricapitolazione dei requisiti frutto del brainstorming.
CODICE: codice Descrizione: Impatto sul sistema: Stima del rischio Priorit cliente Durata Breve nome mnemonico Descrizione del requisito Aree interessate dalla funzionalit e conseguenze basso/medio/elevato bassa/media/alta ordine di grandezza del tempo stimato per la realizzazione Personale figura tecnica richiesta Giorni uomo gg gg gg gg Data: Versione: 0.00.000

Costo stimato:

questa valutazione deriva direttamente dal punto precedente Autore Stato proposta / respinta / approvata / da variare Data data

Iter:

iniziali autore

Tabella 3.2 Esempio di compilazione di un modulo di ricapitolazione.


CODICE: IR_ATSND_0010 Descrizione: Autenticazione mittente / certezza integrit messaggio Nellambito della ricezione dei messaggi relativi alle quotazioni finali dellattivit borsistica, si esige la certezza dellidentit del mittente, la relativa autenticazione, e lintegrit del messaggio. Sistema di sicurezza. (Verosimilmente necessario memorizzare, in maniera centralizzata e crittografata, la chiave pubblica dei sistemi esterni abilitati a scambiare messaggi con il sistema e fornire appositi servizi che siano gli unici a poter accedere a tali informazioni). Sistema di interfacciamento con i sistemi esterni. Elevato. Media (Per le prime release del sistema non indipensabile) 27 giorni uomo. Personale Business Analyst Chief architect Architect Programmatore Tester 10 000,00 Autore L.V.T. A.R: Data: 2/II/2000 Versione: 0.00.002

Impatto sul sistema

Stima del rischio Priorit cliente Durata:

Giorni uomo 4 3 10 15 5 Stato Proposta Approvato Data 2/II/2000 10/III/2000

Costo stimato: Iter:

UML e ingegneria del software: dalla teoria alla pratica

25

Sebbene lesperienza insegni che ogni sistema unico, esiste tuttavia un certo numero di pattern accomunabili e quindi riciclabili: tutti i tecnici, a qualsiasi livello del processo di sviluppo, tendono a riutilizzare soluzioni dimostratesi efficaci in precedenti progetti. A questa legge empirica non si sottraggono i casi duso e tantomeno i modelli per larchitettura fisica. In altre parole, se i modelli vengono organizzati propriamente, probabile che diverse parti risultino riutilizzabili in progetti futuri. Il processo di analisi dei requisiti richiede esperienza e competenza specifica sul business del cliente e sulla tecnologia di riferimento. necessario capire di cosa abbia effettivamente bisogno il cliente: talune volte necessario convincerlo delle relative necessit, imparare a leggere tra le righe a afferrare ci che non viene detto per esempio, razionalizzare un processo potrebbe nuocere a societ amiche , suggerirgli eventuali soluzioni facendole magari passare per sue e cos via. Una buona idea per cercare di affrontare nel miglior modo possibile lanalisi dei requisiti consiste nel procedere con un brainstorming iniziale allo scopo di redigere un documento con lelenco di tutti i potenziali requisiti che passano per la mente dei vari personaggi coinvolti nel processo. Ovviamente tale lista andrebbe rielaborata al fine di catalogare tutte le idee emerse, valutarne la fattibilit, il costo orientativo, il rischio e cos via (tab. 3.1). Stranamente, i requisiti pi odiati dal personale tecnico riportano dei costi esorbitanti. Il risultato di questa sottofase dovrebbe consistere in un documento riportante: codice o un breve nome mnemonico, descrizione, stima del rischio e impatto nel sistema, valutazione del personale coinvolto e del tempo necessario (quindi costo), approvazione e priorit. La priorit dovrebbe essere assegnata dal business analyst in funzione delle direttive fornite dal cliente. Da tenere presente che queste dovrebbero avere un valore essenzialmente di tipo indicativo: non ci si pu attendere che le funzionalit vengano completamente realizzate secondo lordine stabilito dal cliente. Lordine finale dato dal piano delle iterazioni nelle quali si intende scindere lintero processo. evidente che esso debba tener presente sia le richieste del cliente sia di altri fattori come neutralizzare o perlomeno minimizzare i fattori di rischio, delle dipendenze tra le varie parti componenti, e cos via. Quindi la decisione finale delle priorit dovrebbe essere presa con la collaborazione del capo architetto. In genere si cerca di bilanciare le priorit definite dallutente con quelle dovute da fattori tecnici. Tipicamente i processi di sviluppo pi comuni consigliano di affrontare per primi gli use case (o solo alcuni scenari: magari quelli di successo) pi complicati o comunque pi rischiosi, come dire: se deve andare tutto a rotoli meglio accorgersene prima possibile. Come si pu ben notare, un documento riportante schede come quella precedente risulta essere un valido ausilio al project manager per poter effettuare la stima dei tempi e dei costi in maniera meno avventurosa. Nella tab. 3.2 presentata la descrizione di un requisito utente che potrebbe scaturire nel contesto della realizzazione di un sottosistema bancario dedicato alla gestione degli

26

Capitolo 3. Introduzione agli Use Case

investimenti (trading system). In particolare, sistemi di questo tipo necessitano di ricevere e memorizzare, da appropriate fonti esterne, informazioni relative alle quotazioni di mercato di determinati insiemi di titoli, valute, azioni ecc. Le informazioni delle quotazioni sono necessarie sia in tempo reale, sia come resoconto di fine giornata borsistica al fine di essere in grado di compiere tutta una serie di processi di rivalutazione, analisi rischi, previsioni, ecc. Il requisito specificato nella tabella fa riferimento essenzialmente ai messaggi di fine giornata e in particolare si esige di avere lassoluta certezza sia in merito allindennit del mittente, sia allintegrit del messaggio. Si provi ad immaginare i risultati che potrebbero conseguire da un attacco hacker o semplicemente da un errore di trasmissione.

Use Cases Diagram


Il sistema
Sebbene possa sembrare unattivit piuttosto banale, il primo passo nella realizzazione dei modelli dei casi duso consiste nello stabilire con precisione il confine del sistema. Molto spesso, analizzando modelli dei casi duso, non si riesce a comprendere chiaramente quale ne sia il dominio: un sistema informativo, un sistema informatico, un sottosistema, un modulo e cos via. Ovviamente tutto valido a patto che si stabilisca con precisione loggetto di studio e si realizzi un modello coerente. Verosimilmente gli attori di un sistema informativo sono ben diversi da quelli di un componente: lo stesso livello di dettaglio dovrebbe risultare completamente differente. In un tipico processo di sviluppo del software esistono diversi modelli dei casi duso e, indipendentemente da quale sia quello oggetto di studio (business, requirements, ecc.), importante che i confini siano ben definiti. Se per esempio loggetto di studio il modello business dei casi duso, verosimilmente larea di interesse parte di una struttura economica pi vasta, e quindi evidente limportanza di definire precisamente la porzione del business che il sistema finale dovr risolvere. La corretta definizione dei confini del sistema riduce il rischio di commettere un errore spesso presente nei modelli dei casi duso: la modellazione delle entit esterne. Si tratta di un malinteso che comporta una serie di problemi: rende difficile lindividuazione degli attori del sistema; si corre il rischio di definire comportamenti non rispondenti alla realt e/o requisiti non concretizzabili in quanto non sotto controllo; si spreca tempo, ecc.

UML e ingegneria del software: dalla teoria alla pratica

27

Non sempre immediato stabilire i confini del sistema; non sempre si riesce a determinare esattamente se talune attivit sia pi opportuno eseguirle manualmente o automatizzarle: quante volte capita di sentire un operatore esclamare che unattivit x prima dellintroduzione del computer veniva svolta in pochi secondi, mentre ora, con lautomazione, necessita di ore? Quante volte colpa esclusivamente degli orizzonti limitati delloperatore? La vocina interna direbbe quasi mai Chiss come mai riflessioni di questo tipo sono particolarmente frequenti in istituti ben precisi. Unaltra considerazione da farsi quanto grande si vuole realizzare il sistema nelle sue prime versioni. Una buona idea quella di iniziare con lidentificazione delle funzionalit ritenute indispensabili: il core del nuovo sistema, rimandando a sviluppi futuri le restanti. Procedendo con approccio di questo tipo, possibile concentrarsi su un insieme limitato di funzioni con la speranza di riuscire a realizzare una prima versione del sistema soddisfacente. Raggiunto lobiettivo, e convinto il cliente della qualit del lavoro prodotto, sempre possibile aggiungere altre funzioni ritenute di secondaria importanza (altro passaggio del confine, altro fiorino). Approcci iterativi e incrementali incontrano tipicamente il consenso del cliente: sebbene nel complesso si trovi a elargire una somma superiore, lo fa a rate e ci sono maggiori garanzie di successo del sistema. Graficamente il sistema dovrebbe essere evidenziato per mezzo di un rettangolo che ne contenga gli use case e ne lasci allesterno gli attori: un vero e proprio confine. Per esigenze di rendering grafico e lacune di taluni tools, la delimitazione del sistema viene quasi sempre omessa.

Attori
Definizione
Un attore definisce un insieme coerente di ruoli che un utente di un caso duso recita quando interagisce con esso. Un attore non necessariamente una persona: pu essere un sistema automatizzato o un qualsiasi dispositivo fisico; in generale unentit esterna al sistema che interagisce con esso. Si tratta dellidealizzazione di un persona, di un processo, o di qualsiasi cosa interagisca con il sistema inviando e/o ricevendo messaggi: scambiando informazioni. Alcuni esempi di attori, come mostrato in fig. 3.4, possono essere un amministratore, il cliente, uno studente universitario, un insegnante, un sensore di livello, un missile, un legacy system, un sito e-commerce, ecc. Come si spiega pi avanti, esiste per gli attori una rappresentazione grafica standard ma, come illustrato nel Capitolo 2, nulla vieta di ricorrere a opportuni stereotipi al fine di evidenziare le caratteristiche salienti dei vari attori e le relative funzionalit. Un errore tipico che spesso si rappresentano persone o descrizioni di incarichi invece che attori veri e propri. Pertanto, nellindividuare gli attori del sistema necessario

28
Figura 3.4 Esempi di attori.

Capitolo 3. Introduzione agli Use Case

Amministratore

Cliente

Studente universitario

Insegnante

@
m Sensore di livello Legacy system Missile Sito e-commerce

prestare attenzione al fatto che in particolari organizzazioni diversi utenti possono impersonare lo stesso attore logico, cos come uno stesso utente pu recitare il ruolo di pi attori. Gli attori vengono rappresentati graficamente nello UML attraverso sagome di omini stilizzati (stick man), ribattezzati in gergo tecnico scarabocchi o pi teneramente scarabocchietti con il relativo nome riportato alla base. Nella fig. 3.5 vengono riportati alcuni esempi di attori. Come evidenziato precedentemente, non necessariamente un attore deve essere una persona fisica: anche altri sistemi o dispositivi hardware possono assurgere al ruolo di attore. Se per esempio si dovesse modellare un sistema darma di artiglieria contraerei, i vari radar, la sezione lancio e, spesso, i missili stessi avrebbero tutta la dignit per assumere il ruolo di attori. Ancora, se si dovesse progettare un sistema di wrapper (layer di comunicazione) tra un sito per il commercio elettronico e il relativo Legacy System del cliente, entrambi i sistemi avrebbero tutta la dignit di essere considerati attori. Un sensore in grado di rilevare e comunicare al sistema il livello dellacqua presente in una diga anchesso a tutti gli effetti un attore per il relativo sistema di monitoraggio e cos via.

UML e ingegneria del software: dalla teoria alla pratica

29

Un errore tipico che si commette nel realizzare il modello dei casi duso e in particolare nellindividuare gli attori, utilizzare nomi diversi per identificare lo stesso ruolo e quindi lo stesso attore. Questo problema particolarmente frequente quando uno stesso modello dei casi sia realizzato da diversi team. Si assiste quindi al proliferare di sinonimi del tipo: banconista, addetto allo sportello, sportellista, ecc. Il problema pu essere risolto aggiornando la lista degli attori utilizzati con relativa descrizione, magari inserendoli tutti in uno stesso package condiviso del proprio modello. Pertanto prima di inventare un nuovo attore sarebbe sufficiente effettuare una breve verifica tra quelli individuati.

Per ci che concerne le relazioni, un attore viene connesso ai casi duso con i quali interagisce per mezzo di una relazione di associazione, e pu prendere parte a relazioni di generalizzazione in cui una descrizione astratta di un attore pi essere condivisa e specializzata da una pi specifica. Ogni attore, durante la fase di disegno, deve in qualche modo essere rappresentato allinterno del sistema con cui interagisce: come si vedr meglio nel capitolo dedicato ai class diagram: in ultima analisi un attore tende a essere rappresentato attraverso una particolare classe, la cui implementazione interna non rilevante nel contesto dei casi duso. Gli attori comunicano con il sistema inviando o ricevendo messaggi: forniscono lo stimolo (trigger) agli use case; ci equivale a dire che ogni caso duso deve essere avviato da unesplicita richiesta di un attore. Una tecnica utilizzata per semplificare il processo di individuazione degli attori consiste nel classificarli in primari e secondari. I primari sono quelli che utilizzano le funzioni Figura 3.5 Esempi di attori con rappresentazione classica UML.

Amministratore

Cliente

Studente Universitario

Insegnante

Sensore di Livello

Missile

Legacy System

Sito eCommerce

30

Capitolo 3. Introduzione agli Use Case

proprie del sistema (per un use case diagram sono quelli che lo avviano), e pertanto vengono anche definiti attivi; i secondi, tipicamente, fruiscono di informazioni o notifiche generate da use case eseguiti da altri attori. Per esempio un manager riceve la notifica che un proprio subalterno ha compilato il modulo per la richiesta delle ferie e pertanto dovr eseguire la funzione per validare o rifiutare la richiesta stessa (da notare che per lo use case relativo a tale funzionalit, il manager assurgerebbe al ruolo di attore primario); oppure, in un sistema di protocollazione, i destinatari di un documento in input, ricevono la notifica di visionare lo stesso. Questi sono i cosiddetti attori secondari o passivi. da tener presente che attori primari per uno use case possono essere sendondari per un altro e viceversa. La differenza sostanziale tra i due tipi che, mentre gli attori primari avviano delle funzionalit proprie del sistema, i secondari ricevono dei messaggi e non forniscono un vero e proprio stimolo. Linsieme completo degli attori presenti nei diagrammi dei casi duso evidenzia tutte le entit che necessitano di scambiare informazioni con il sistema stesso.

Relazione di generalizzazione tra attori


Nella realizzazione di use case diagram pu verificarsi il caso in cui pi attori presentino diverse e significative similitudini, come per esempio interagiscano con un insieme di casi duso con le stesse modalit. In questi casi, come i princpi del paradigma Object Oriented insegnano, possibile dar luogo a un nuovo attore, magari astratto, che raccolga a fattor comune tali similitudini, esteso dagli altri per mezzo di apposite relazioni di generalizzazione. Chiaramente non sempre necessario introdurre un nuovo attore; anzi, la maggior parte delle volte si verifica il caso pi semplice di un attore che ne estende un altro: un attore specializzato eredita il comportamento del genitore e lo estende in qualche maniera. Coerentemente con la definizione di relazione di generalizzazione (o meglio con il relativo principio di sostituibilit), un attore che ne specializza un altro pu sempre essere utilizzato al posto di quello esteso (genitore o padre). Ci abbastanza chiaro: se per esempio in un team di sviluppo necessario allocare un ulteriore analista programmatore Object Oriented e viene un dottore laureato in scienze tecniche proveniente da qualche famosa azienda di consulting e che vanta la partecipazione in mille ruoli di rilievo, magari anche in riviste di prestigio, il tutto dovrebbe funzionare benissimo: oltre a capacit analitiche e programmative, richieste allattore base, dovrebbe possedere una serie di esperienze (comportamenti e attributi aggiuntivi, particolarmente appetibili). Chiss perch poi le cose nella realt non sono mai cos lineari Si consideri il caso di un sistema con due attori: operatore e amministratore. Lamministratore risulta caratterizzato dallo svolgere tutte le funzioni delloperatore e da dallesse-

UML e ingegneria del software: dalla teoria alla pratica

31

Figura 3.6 Esempio di relazione di generalizzazione tra attori.


Gestione ordini

Venditore

Validazione ordini rischiosi

Supervisore

re gravato da un insieme di funzioni aggiuntive ritenute sensibili per il sistema. In questo caso, immediato asserire che lattore Amministratore eredita dallattore Operatore. Si consideri lesempio di fig. 3.6. Si tratta di un sistema automatizzato di vendita utilizzato, dal lato back office, essenzialmente da due attori: Venditore e Supervisore. Entrambi possono gestire un ordine, ma lattore Supervisore estende il Venditore, in quanto ha la responsabilit di validare ordini che, in base a determinati fattori, vengono considerati rischiosi. La notazione grafica utilizzata in UML per rappresentare una relazione di generalizzazione quella standard e prevede un segmento che unisce lattore estendente a quello esteso; in prossimit di questultimo viene riportato un triangolo vuoto a mo di freccia.

Molto spesso analizzando modelli use case possibile notare una rete densissima di collegamenti tra attori e casi duso. Per esempio pu capitare di osservare che una serie di use case risultino tutti connessi con un insieme ben definito di attori (fig. 3.7) Fitte reti di collegamento attori/casi duso possono costituire sintomi del fatto che non si sia proceduto ad una appropriata organizzazione gerarchica degli attori. Probabilmente possibile ristrutturare i vari attori secondo unopportuna relazione gerarchica. Ci ottenibile definendo un nuovo attore padre connesso con tutti i casi duso comuni agli altri e quindi specializzarlo con i vari attori, ognuno dei quali, eventualmente connesso ad altri casi duso di pi specifica pertinenza (fig. 3.8).

Il diagramma mostrato rievoca nella mente dellautore un simpatico aneddoto. Realizzata la primissima versione del modello dei casi duso di un sistema piuttosto complesso, bisognava definire chiaramente ruoli e responsabilit dei relativi attori umani. Trat-

32

Capitolo 3. Introduzione agli Use Case

Figura 3.7 Esempio di mancata astrazione nellidentificazione degli attori.

Inserimento ordine

Venditore

Verifica stato ordine

Annullamento ordine

Supervisore

Generazione report

Figura 3.8 Diagramma ristrutturato evidenziando la relazione di generalizzazione tra attori.

Inserimento ordine

Venditore

Verifica stato ordine

Annullamento ordine

Supervisore

Generazione report

UML e ingegneria del software: dalla teoria alla pratica

33

Figura 3.9 Frammento di unorganizzazione gerarchica degli attori umani di un sistema.

Utente

.
Utente Esterno Utente Interno

.
Addetto Gestione Clienti Addetto Sicurezza

.
Direttore Gestione Clienti Direttore Sicurezza

Direttore Dipartimento

tandosi di un sistema completamente nuovo, lattivit risultava abbastanza importante: si trattava di definire il profilo delle figure professionali da reclutare oltre ai manager gi assegnati per lentrata in esercizio del sistema. La prima versione dellorganizzazione dei ruoli risultava simile a quella presentata in fig. 3.9. La logica alla base della struttura di figura era di astrarre ruoli con comportamento comune ossia raggruppare attori che interagivano con un insieme condiviso di casi duso. Per esempio, era importante disporre di un attore utente generico (Utente) per descrivere le funzioni che tutti gli attori utilizzavano (login, cambiamento di password, richiesta nuova password, ecc.). Allinterno di ogni dipartimento era poi importante mostrare le differenze tra gli addetti e i manager in quanto questi, oltre a poter espletare tutte le

34

Capitolo 3. Introduzione agli Use Case

mansioni dei propri subalterni (ereditano dagli addetti del reparto), sono gravati da responsabilit supplementari tipiche del ruolo manageriale (ereditano dallattore Direttore Dipartimento). Per esempio avviano il servizio di richiesta del profilo utente per i propri dipendenti, hanno lobbligo di validarne i time sheet, ecc. Una volta sottoposto il diagramma allattenzione dei clienti (manager), successe la rivoluzione Orrore!!! Come!? I manager nellorganigramma compaiono a un livello inferiore dei propri subalterni!?. A questo punto il pasticcio era fatto. Tutte le spiegazioni tecniche non sortivano alcun effetto Cosa fare? Prima idea: ribaltare il diagramma Per questa soluzione era troppo tardi e comunque rimaneva il concetto poco gradito della doppia piramide. La soluzione fu la realizzazione di un diagramma illeggibile Si decise di portare tutti i manager su una riga superiore come mostrato in fig. 3.10.

Figura 3.10 Modifiche a un frammento dellorganizzazione gerarchica degli attori presentata nel diagramma precedente.

Direttore Dipartimento

.
Direttore Gestione Clienti Direttore Sicurezza

Utente

.
Utente Esterno Utente Interno

.
Addetto Gestione Clienti Addetto Sicurezza

UML e ingegneria del software: dalla teoria alla pratica

35

Figura 3.11 Esempio di relazioni di associazione.

Reperimento dati cliente


include

Reperimento articoli
include

Effettua ordine

Cliente

Controlla ordine

Venditore

Relazione di associazione tra attori e casi duso


Gli attori sono entit esterne al sistema che interagiscono con esso. Le interazioni si materializzano attraverso scambi di messaggi. Pertanto ogni attore connesso con un insieme di casi duso (funzioni del sistema) che ne ricevono gli stimoli e che producono i dati richiesti dallattore stesso. Il legame tra attore e use case realizzato per mezzo di una relazione di associazione. La situazione pi tipica che un singolo attore associato a molti casi duso. Graficamente le relazioni di associazione vengono visualizzate per mezzo di un segmento che unisce lattore con il relativo caso duso. Nella fig. 3.11 viene riportato un semplice diagramma dei casi duso rappresentante una porzione di un sistema automatizzato di vendita online. Per ora si attribuisca alla relazione include (inclusione) un significato del tutto intuitivo: lesecuzione della funzione Effettua ordine necessita dellesecuzione delle funzioni Reperimento dati cliente e Reperimento articoli. Dunque, un cliente, previa opportuna identificazione, pu compilare degli ordini selezionando gli articoli di interesse. Lattore Venditore ha il compito di visionare gli ordini e lesito del controllo viene comunicato al cliente che ha emesso lordine oggetto di verifica.

Come identificare gli attori del sistema


Identificare gli attori del sistema unattivit molto importante: si identificano le entit interessate a usare e interagire con il sistema. Tipicamente si tratta di unattivit non smisuratamente complessa che lesperienza tende a rendere ancora meno complicata. Tuttavia esistono casi particolari in cui anche il processo di individuazione degli attori pu generare pi di qualche incertezza.

36

Capitolo 3. Introduzione agli Use Case

In ultima analisi un attore , almeno, una classe per il sistema e quindi si intuisce limportanza sia dellidentificare i singoli attori, sia nellassegnargli un nome corretto. Nel caso in cui lattribuzione del nome possa causare qualche problema, ci potrebbe essere un buon campanello di allarme che qualcosa non funzioni correttamente: si sono raggruppati pi attori in uno solo (magari perch nella realt di interesse diversi ruoli vengono fisicamente recitati da una sola persona) o, problema diametralmente opposto, lo stesso ruolo diviso in pi attori (caratteristica peculiare di particolari istituti). Lerrore tipico che si commette nellindividuare gli utenti del sistema che si prendono in considerazione unicamente gli operatori umani: i famosi signori con i manicotti seduti di fronte ai monitor. Spesso ci si dimentica che un attore qualsiasi entit che ha interesse a interagire con il sistema: anche dispositivi fisici. Un altro errore ricorrente quello di considerare il sistema da subito e unicamente con una prospettiva molto tecnica e non con una pi vicina al business del cliente. In altre parole, spesso ci si dimentica dei veri utenti del sistema i quali, molto frequentemente, sono i clienti del committente stesso. Premesso ci, rispondere alle domande riportate di seguito pu aiutare ad identificare/verificare gli attori del sistema: Chi sono gli utilizzatori delle principali funzioni del sistema? Ossia, chi sono gli attori principali? Chi usufruir giornalmente del supporto del sistema? Chi si occuper di mantenere, amministrare il sistema? Esistono sistemi esterni (sia software, sia hardware) che necessitano di interagire con il sistema? Quali di essi iniziano il colloquio con il sistema e quali invece ricevono i risultati dellesecuzione di opportuni processi? Esiste qualche ulteriore entit che ha interesse a essere informata sui risultati prodotti da opportune elaborazioni del sistema?

Modello per la documentazione degli attori


Spesso conveniente, gi durante i colloqui iniziali con gli utenti del sistema, cominciare a redigere una lista riportante gli aspiranti attori. Tale elenco destinato a essere riesaminato e corretto man mano che si procede con le varie interviste e quindi, pi in generale, con la comprensione dellarea di business che il sistema, in qualche percentuale, intende risolvere. Una volta terminata la serie delle interviste necessario eseguire una fase di verifica della lista degli aspiranti attori al fine di individuarne eventuali ridondanti, ambigui, non ben definiti, mancanti e cos via.

UML e ingegneria del software: dalla teoria alla pratica

37

Effettuata anche questa verifica la lista costituisce un ottimo prodotto di input per la costruzione dei vari diagrammi dei casi duso. Ci, tra laltro, dovrebbe favorire la realizzazione di un glossario, preciso circa gli attori del sistema. Al fine di supportare il processo di costruzione del modello dei casi duso, si ritiene utile, per ogni attore, compilare una scheda come quella riportata in tab. 3.3. Molto importante definire le responsabilit di un attore anche se tipicamente si tende a specificarne le operazioni. Queste permettono di chiarire le regole del business vigenti nel sistema oggetto di studio. Talune volte, invece di specificare i casi duso in cui un attore coinvolto, si preferisce descriverne le aspettative. Ci risulta particolarmente utile quando ci si trova in una delle primissime fasi del ciclo di vita, quando i modelli dei casi duso non sono ancora definiti. Per ci che concerne la frequenza dellutilizzo dei casi duso, si tratta di uninformazione utilissima in molti contesti, quali ottimizzazione delle operazioni, pianificazione dei test, ecc.

I casi duso
Definizione
Uno use case (caso duso) rappresenta una funzionalit completa cos come viene percepita da un attore. Si tratta di un costrutto utilizzato per definire il comportamento di un sistema o di unaltra entit semantica senza rivelarne la struttura interna. In termini pi formali, un caso duso un tipo di Classificatore (UseCase eredita da Classifier) che rappresenta ununit coerente di funzionalit fornita da una specifica entit (sistema, sottosistema, classe) e descritta sia dalla serie di messaggi scambiati tra lentit stessa e unaltra interagente esterna (attore), sia dalla sequenza di azioni svolte. Ogni caso duso pertanto definito da una sequenza di azioni (comportamento dinamico) che lentit esegue interagendo con il relativo attore, necessarie per erogare un

Tabella 3.3 Scheda per la definizione degli attori del sistema.


Nome dellattore: Responsabilit 1. 2. USE CASE CON CUI INTERAGISCE Nome use case Primario Frequenza Versione: Data:

38

Capitolo 3. Introduzione agli Use Case

servizio. Tale sequenza pu prevedere delle varianti come sequenze alternative, comportamento eccezionale, gestione degli errori, e cos via. Gli use case specificano servizi che unentit fornisce ai relativi utilizzatori: ognuno di questi servizi deve essere completo e avviato da un attore. Le implicazioni della propriet di completezza sono essenzialmente due: 1. lentit, dopo aver erogato il relativo servizio, deve transitare in uno stato tale che il servizio possa essere fruito nuovamente; 2. pi casi duso che specificano la stessa entit non possono comunicare tra loro, perch ciascuno di essi deve, individualmente, descrivere completamente lutilizzo dellentit stessa. I casi duso possono essere raggruppati in gruppi (package) per questioni di comodit e facilit di reperimento. Sebbene gli use case siano impiegati quasi esclusivamente per specificare i requisiti esterni di unentit, essi possono anche essere utilizzati per documentare le funzionalit offerte da unaltra entit (esistente) del sistema, anche se per tali fini sarebbe preferibile utilizzare altri diagrammi messi a disposizione dallo UML (diagrammi di sequenza, collaborazione, attivit e di stato). Indirettamente ciascun caso duso stabilisce i requisiti che ogni entit esige dai relativi utilizzatori, come per esempio le modalit con cui essi devono interagire con lentit stessa per fruire dei relativi servizi offerti. Nel caso che lentit sia il sistema o un sottosistema, i relativi utenti sono gli attori; se invece si fa riferimento a sottosistemi e classi interne al sistema, tipicamente, gli utenti non vengono definiti. La notazione grafica dello UML prevede di rappresentare gli use case attraverso ellissi con allinterno specificato il nome. Essi possono essere connessi ad altri use case o agli attori. In tal caso la connessione prende il nome di associazione o comunicazione di associazione. Nellindividuazione degli use case, lesperienza insegna che molto importante risulta la selezione del relativo nome. Si tratta dellelemento pi discusso dagli utenti/clienti. I nomi dovrebbero essere unici, sintetici e al tempo stesso capaci di definire completamente il relativo concetto. Ci risulta particolarmente utile per i modelli a livello di dominio in cui il nome da solo dovrebbe essere in grado di giustificare il caso duso dal punto di vista del business. Oltre a facilitarne la lettura, nomi di questo tipo assicurano che il relativo use case rappresenti un reale requisito e non uno supposto o unincomprensione. Probabilmente la sintassi ideale prevede una breve frase formata da un sostantivo indicante lazione e da un sostantivo indicante loggetto della stessa (Inserimento ordine, Invio conferma, Annullamento ordine, Inserimento utente, Variazione profilo, Selezione domicilio, ecc.).

UML e ingegneria del software: dalla teoria alla pratica

39

Poich un modello dei casi duso, in ultima analisi, rappresenta linsieme dei servizi forniti agli attori del sistema, nella selezione dei nomi dei casi duso opportuno mettersi nellottica degli attori.

Relazione di associazione
Si faccia riferimento al paragrafo denominato Relazione di associazione tra attori e casi duso.

Relazione di generalizzazione
Nel disegnare i diagrammi dei casi duso si verifica spesso che diversi use case presentino delle somiglianze e condividano del comportamento (analogamente a quanto illustrato per gli attori). Come in precedenza, gli insegnamenti dellObject Oriented prescrivono di raggruppare il comportamento comune in un apposito use case genitore (eventualmente astratto) e di estenderlo per mezzo di altri casi duso figli che lo specializzino per gli usi originariamente individuati. La propriet a cui si fa riferimento ovviamente leredit e la relazione dello UML la generalizzazione. Nel contesto dei casi duso, la generalizzazione (Generalization) una relazione tassonomica tra un use case, figlio, e un altro, chiamato genitore, che descrive le caratteristiche che il caso duso divide con altri use case che hanno lo stesso genitore.

Figura 3.12 Esempio di relazione di generalizzazione tra use case: Upload ordine.

Validazione utente
include

Verifica ordine
include

Upload ordine
Cliente Legacy System

Upload ordine standard

Invio ordine prioritario


include

Upload ordine prioritario

40

Capitolo 3. Introduzione agli Use Case

Un caso duso genitore pu essere specializzato in uno o pi figli che ne rappresentano forme pi specifiche. Lo Use Case figlio eredita gli attributi, le operazioni, il comportamento del genitore, e pertanto pu sovrascrivere (override) o aggiungere comportamento (attributi, operazioni, e cos via). Come da standard UML, anche in questo contesto, la notazione grafica utilizzata per la relazione di generalizzazione prevede una linea continua, terminata con un triangolo vuoto posto a mo di freccia in prossimit dello use case genitore. Da notare che la presenza di una relazione di generalizzazione implica che lesecuzione di use case fratelli pu avvenire unicamente in alternativa. Si consideri lesempio di generalizzazione illustrato nella fig. 3.12. Si tratta di uno use case che descrive la funzione che supporta linvio (upload) automatico ordini, ad una determinata organizzazione commerciale, tramite browser Internet. Si immagini un sito per il commercio elettronico il quale, tra le varie funzionalit, permetta di ricevere ordini preparati dagli utenti secondo opportuni formati (ASCII, XML, ecc. ecc.). Questa funzionalit di upload potrebbe funzionare in modo del tutto equivalente al modo con cui i server di posta elettronica, fruibili via comune browser, consentono di allegare file (attachment) in una e-mail: si seleziona localmente il percorso del file da allegare e quindi si preme il tasto di upload. Si supponga che il sistema preveda due tipologie di ordini: normali e prioritari. La peculiarit dei secondi di richiedere una gestione immediata: appena caricati vengono spediti al sistema di back office (Legacy System) che provvede a gestirli immediatamente, mentre i primi prevedono un iter rallentato dovuto sia a vincoli architetturali presenti nel sottosistema Internet sia in quello di back office operante presso lorganizzazione del cliente. Il diagramma in figura mostra il caso duso di Upload ordine. In particolare la presenza delle relazioni di generalizzazione implicano che possibile eseguire uno solo di tali casi: lesecuzione di un fratello esclude quella dei rimanenti. Quindi o si esegue lupload di un ordine standard oppure si esegue quello di un ordine prioritario. Il diagramma in figura indica unicamente la proiezione statica della funzionalit: specifica che il caricamento di un ordine richiede la validazione dellutente e la verifica dellordine stesso; evidenzia che lutente pu richiedere due tipologie diverse di servizio: standard e prioritario. Nel secondo caso previsto limmediato invio al sistema di legacy. Il diagramma evidentemente non specifica nulla circa la dinamica delloperazione, non specifica altres precondizioni e postcondizioni, non fornisce alcuna direttiva su come trattare i casi anomali: cosa fare se il formato dellordine risulta errato o se il prezzo di un prodotto presente nellordine non corrisponde a quello impostato nel sistema? E si potrebbe continuare. Per sopperire a tale lacuna possibile specificare il flusso delle attivit illustrato in fig. 3.13. Dallanalisi del diagramma possibile notare che il caso duso base A, pu prevede-

UML e ingegneria del software: dalla teoria alla pratica

41

Figura 3.13 Flusso degli eventi di due casi duso uniti dalla relazione di generalizzazione.

Use case A

Flusso degli eventi Use case A ..................... ....................... passo astratto ....................... .............. ........ ............. passo generico ....................... .............. ........ ............. fine use case

Flusso degli eventi Use case B definizione passo astratto ..................... ....................... fine segmento ridefinizione passo ....................... .............. ........ fine segmento definizione passo aggiuntivo ................... ........................ fine use case

Use case B

re dei punti astratti mischiati a generici passi di esecuzione. Un use case specializzante pu sia definire il comportamento per le sezioni astratte (utilizzo canonico), sia sovrascrivere quello sancito in passi generici, sia aggiungere altro comportamento dopo la fine del flusso di eventi del caso duso base. Per esempio, con riferimento allo use case di fig. 3.12, Upload ordine, un possibile flusso di eventi potrebbe essere quello riportato di seguito.
Use case base Upload ordine: 1. include (Riconoscimento utente) 2. if riconoscimento fallito then 2.1. if riconoscimento fallito per tre volte consecutive then 2.1.1. mostra messaggio. 2.1.2. termina lo use case con errore.

42
2.2. else

Capitolo 3. Introduzione agli Use Case

2.2.1.mostra messaggio. 2.2.2.torna al punto 1. 3. impostazione file da parte dellutente. 4. conferma caricamento file da parte dellutente. 5. caricamento file nel sistema. 6. if errore nel caricamento then 6.1. 6.2. mostra opportuno messaggio. torna al punto 3.

7. memorizzazione temporanea del file (ordini da verificare) 8. include (Verifica ordine) 9. if verifica fallita then 9.1. 9.2. 9.2. mostra opportuno messaggio. eliminazione dellordine. torna al punto 3.

10. memorizzazione permanente del file (ordine verificato) Use case Upload ordine standard: 10. memorizzazione permanente del file nella directory ordini standard. Use case Upload ordine prioritario: 10. memorizzazione permanente del file nella directory ordini prioritari. 11. include (Invio ordine prioritario).

Si pu immaginare il sistema strutturato in modo tale da prevedere un servizio cadenzato che si occupi, a intervalli prestabiliti di tempo (una/due volta/e al giorno) di prelevare gli ordini standard per inviarli al legacy system (sistema automatizzato di back office presente presso lorganizzazione del cliente: la struttura che in ultima analisi fornisce i prodotti che vengono venduti tramite il sito di e-commerce).

Figura 3.14 Invio ordini standard.

Invio ordini standard


Timer Venditore

UML e ingegneria del software: dalla teoria alla pratica

43

Lo use case di una funzionalit cos concepita offre un interessante motivo di riflessione: lavvio dello use case avverrebbe automaticamente (a istanti temporali predefiniti) senza lo stimolo di un vero attore esterno. A questo punto nasce un dilemma: il tempo pu essere considerato un attore o no? Probabilmente si tratta pi di uno sceneggiatore o di un regista. Applicando rigorosamente le direttive dello UML, il tempo non dovrebbe poter essere considerato un attore; come punto a favore si pu invece asserire che si tratta di unentit indubbiamente esterna al sistema e altrettanto sicuramente non controllabile dallo stesso. In altre parole lattore Tempo non solo unassunzione decisamente accettabile ma contribuisce anche a rendere i diagrammi pi leggibili In ultima analisi gli stessi use case non dovrebbero venir sempre avviati da un attore?

Nella fig. 3.14 stato riportato lesempio del tempo come attore evidenziandolo per mezzo di apposito stereotipo al fine di far risaltare ulteriormente il concetto dellavvio temporizzato. Per ci che concerne invece gli ordini prioritari, la specifica del comportamento dinamico ne prevede limmediato invio al legacy system. Come si vedr successivamente, probabilmente il formalismo utilizzato per specificare il comportamento dinamico dei casi duso (cos come proposto dai Tres Amigos) nella pratica non risulta essere il pi efficace: forse sarebbe pi opportuno utilizzare specifici template scegliendoli tra quelli proposti. Come si pu notare gli use case figli ereditano la sequenza comportamentale del genitore e vi aggiungono comportamento specifico. Potenzialmente sia il caso duso genitore, a meno che non preveda opportune sezioni astratte, sia quello figlio sono istanziabili. Differenti specializzazioni dello stesso genitore sono completamente indipendenti contrariamente a quanto avviene con le relazioni di estensione (illustrato nellapposito paragrafo) in cui i diversi use case estendenti modificano il comportamento dello stesso use case e possono essere invocati in sequenza. Il comportamento specifico di un caso duso figlio pu essere indicato inserendo opportune sezioni o sovrascrivendone altre, in modo del tutto analogo a quanto avviene con i metodi delle classi, nella sequenza di azioni ereditate dallo use case genitore. In questo contesto consigliabile ricorrere con parsimonia al meccanismo di sovrascrittura onde non stravolgere gli intenti dello use case genitore. Quando il caso duso genitore astratto, nella relativa sequenza di azioni sono previste apposite sezioni lasciate volutamente incomplete e alle quali lo use case ereditante deve provvedere. La propriet di sostituibilit propria della relazione di generalizzazione applicata ai casi duso implica che la sequenza di azioni dello use case figlio deve includere quella del genitore.

44

Capitolo 3. Introduzione agli Use Case

Figura 3.15 Flusso degli esempi della relazione di inclusione.

Use case A

include

Flusso degli eventi Use case A ..................... ....................... ....................... include( Use case B) .............. ........ ............. ....................... .............. ........ ............. fine use case

Use case B

Flusso degli eventi Use case B ..................... ....................... ....................... .............. ........ ................... ........................ ........................ ........................ fine use case

Relazione di inclusione
Linclusione una relazione tra un use case base e uno incluso che specifica come il comportamento di questultimo possa essere inserito in quello definito nello use case base, il quale, pu avere visione dellincluso e, tipicamente, dipende dagli effetti da esso generati durante la relativa esecuzione. In termini della sequenza delle azioni, che ciascun caso duso esegue per erogare un servizio, la relazione di Include comporta lesecuzione della sequenza di azioni dello use case incluso sotto il controllo e nella locazione specificata dello use case base, come mostrato nella fig. 3.15. Il concetto di inclusione per molti versi analogo a quello di invocazione di funzione: viene eseguita la sequenza di azioni dello use case base; quando viene raggiunto un punto di inclusione, il controllo viene passato al caso duso ivi indicato (incluso) e ne viene eseguita completamente la sequenza delle azioni, quindi il controllo ritorna allo use case base. Volendo essere pi precisi bisognerebbe paragonare la relazione di inclusione al meccanismo delle macro presente in molti linguaggi di programmazione: si definisce una macro e

UML e ingegneria del software: dalla teoria alla pratica

45

la si copia (si espande il codice) in tutti i punti in cui ci si riferisce alla macro stessa. Lo use case incluso pu avere accesso agli attributi ed alle operazioni di quello base. La relazione di inclusione ha avuto una genesi piuttosto complicata; inizialmente si trattava di uno stereotipo della relazione di generalizzazione e, pertanto, veniva rappresentata per mezzo dello stesso simbolo grafico con affianco letichetta <<uses>>(nome dello stereotipo). Nella versione 1.3 dello UML, per fortuna, le cose sono un po cambiate e linclusione stata pi opportunamente convertita in una relazione a s stante. La notazione grafica prevede una freccia tratteggiata con letichetta <<include>>. Probabilmente era poco opportuno indicare una relazione di uso o di inclusione attraverso uno stereotipo della relazione di generalizzazione in quanto questultima implica la propriet di sostituibilit; nel contesto della relazione di inclusione indicava che lo use case utilizzatore poteva sempre essere sostituito al posto di quello utilizzato, il che evidentemente lungi da rispondere a verit. Una relazione di inclusione indica che lo use case base (lutilizzatore) incorpora esplicitamente il comportamento di un altro use case (lutilizzato), il quale, tipicamente, non vive di vita propria, ma deve necessariamente essere istanziato come parte di un altro caso duso. Lo use case utilizzato ha visione completa del suo utilizzatore con il quale pu scambiare parametri e comunicare risultati. La relazione di inclusione molto utile in quanto evita di dover ripetere pi volte uno stesso flusso di sequenza. In particolare, per specificare nel flusso dello use case utilizzatore il punto in cui inserire quello dello use case incluso, sufficiente premettere lidentificatore include seguito dal nome dello use case. Chiaramente, poich il caso duso incluso a tutti gli effetti uno use case, pu essere associato ad altri per mezzo di proprie relazioni di inclusione, estensione e cos via. Si consideri lesempio riportato in fig. 3.16. Si tratta di uno use case per la compilazione ordini. In particolare vi lattore Cliente che inserisce gli ordini nel sistema. Come si Figura 3.16 Esempio di relazione di inclusione: use case per la compilazione di un ordine.
Reperimento dati cliente
include

Reperimento articoli
include

Compila ordine

Cliente

46

Capitolo 3. Introduzione agli Use Case

pu evidenziare, la funzionalit Compila ordine prevede il Reperimento dei dati del cliente e la ricerca degli articoli (Reperimento articolo) che andranno a costituire lordine stesso. Nel redigere i diagrammi dei casi duso necessario porre attenzione a non essere eccessivamente prescrittivi: ci non sarebbe di alcun aiuto e, paradossalmente, finirebbe con il rendere il diagramma inutilmente complicato e con lobbligare eccessivamente il team di sviluppo durante le fasi successive a rispettarne i dettagli; si ricordi che la use case view anche un documento utilizzato nei test di accettazione. Per esempio nello use case di fig. 3.17 si sarebbero potute evidenziare ulteriori funzionalit come Verifica disponibilit articolo o Reperimento prezzo cliente generalizzazione della funzionalit di ricerca articolo Ricerca per codice, Ricerca per descrizione, Ricerca per categoria, ecc. Ci sarebbe stato del tutto ingiustificato e avrebbe complicato un use case intrinsecamente semplice. Linconveniente pu non sembrare cos serio nel diagramma di figura, ma si tenga presente che, in una situazione reale, esso sarebbe parte di un modello decisamente pi complesso; consigliabile, quindi, non perdere tempo nel dettagliare eccessivamente gli use case diagram: si corre unicamente il rischio di renderli inutilmente complessi: come si suol dire ogni cosa a suo tempo. Assumendo che lutente sia stato precedentemente autenticato dal sistema e autorizzato a eseguire la funzione, il flusso di azione del diagramma (fig. 3.16) potrebbe assumere una forma del tipo:
Use case base Compila Ordine: 1. include (Reperimento dati cliente) 2. if reperimento fallito then 2.1. 2.2. mostra messaggio termina use case.

3. include (Ricerca articolo) 4. if reperimento fallito then 4.1. 4.2. mostra messaggio torna al punto 3.

5. Lutente selezione operazione da eseguire sullordine 6. if ordine annullato then 6.1. 6.2. mostra messaggio termina use case.

7. if utente aggiorna quantit articolo then 7.1. il sistema ricalcala i totali. 7.2. il sistema aggiorna lordine. 7.3. torna al punto 5. 8. if utente elimina una riga then 8.1. il sistema ricalcala i totali.

UML e ingegneria del software: dalla teoria alla pratica

47

Figura 3.17 Come complicare un affare semplice.

Reperimento cliente per codice

Reperimento cliente per denominazione

Reperimento dati cliente


include

Verifica disponibilita' articolo


include

Compila ordine

Cliente

include

include

Reperimento articolo

Reperimento prezzo cliente

Reperimento articolo per codice

Reperimento articolo per categoria

Reperimento articolo per descrizione

8.2. il sistema aggiorna lordine. 8.3. torna al punto 5. 9. if utente richiede aggiunta ulteriore articolo then 9.1. torna al punto 3. 10. if utente conferma ordine then 10.1. Memorizza ordine 11. Fine use case Use case Reperimento dati cliente: 1. acquisizione codice cliente. 2. reperimento dati cliente per codice. 3. if reperimento fallito then 3.1. 3.2. acquisizione denominazione cliente. reperimento dati cliente per denominazione.

48
3.3. if reperimento fallito then

Capitolo 3. Introduzione agli Use Case

3.3.1.termina con errore. 4. restituisci dati reperiti. Use case Ricerca ordine: 1. acquisizione codice articolo. 2. reperimento articolo per codice 3. if reperimento fallito then 3.1. 3.2. 4.1. acquisizione descrizione articolo reperimento dati articolo per descrizione termina con insuccesso

4. if reperimento fallito then 5. reperimento prezzo articolo da applicare al cliente 6. if reperimento fallito then 6.1. termina con insuccesso 7. riporta dati reperiti

Volendo si sarebbe potuto rendere i flussi di azione decisamene pi eleganti e complessi, ma proprio non il caso; anzi consigliabile impiegare meglio il tempo nel contesto delleconomia dellintero progetto.

Relazione di estensione
Una relazione di estensione (Extend) una relazione tra un caso duso estendente e uno base che specifica come il comportamento definito dal primo (lestendente) debba essere inserito nel comportamento di quello base. A questo punto i lettori non molto esperti della vista dei casi duso potrebbero essere scossi da pi di qualche turbamento: il comportamento dello use case estendente viene incorporato in quello base? In effetti cos. Il problema risiede unicamente nel nome scelto per tale relazione: Extend. Considerato erroneamente come relazione di estensione canonica, il comportamento sarebbe assolutamente contrario alle convenzioni pi classiche dellObject Oriented, ma non bisogna farsi confondere dal nome e ricordare che per specificare relazioni di ereditariet tra casi duso prevista lappropriata relazione di generalizzazione. Si tenga comunque presente che la vista dei casi duso prevede come fruitori anche persone che, per definizione, hanno pochissima o nessuna esperienza del mondo Object Oriented: se si fortunati, tali individui appartengono unicamente alla categoria dei clienti, e la relazione di estensione cos definita finisce probabilmente per risultar loro pi naturale e comprensibile. Nel diagramma riportato in fig. 3.18 viene illustrata la differenza tra una relazione di inclusione e una di estensione. Si considerino due use case generici A e B, in cui il primo necessita in qualche modo del secondo. Nel caso in cui:

UML e ingegneria del software: dalla teoria alla pratica

49

Figura 3.18 Differenza di notazione tra la relazione di inclusione e quella di estensione.

Verifica formato on-line

Verifica formato on-line

include

extend

Visualizza eccezione

Visualizza eccezione

lo use case A include quello B, la freccia va dal primo al secondo; lo use case B estende quello A, la freccia va riportata esattamente al contrario del caso precedente. Una relazione di estensione contiene una lista dei nomi dei punti in cui lo use case base pu e deve essere esteso (consultare figura seguente). Chiaramente ciascuno di essi deve essere esteso da opportuni segmenti presenti nello e nei casi duso estendenti. Un punto di estensione rappresenta una locazione o un insieme nello use case base, nel quale lestensione pu essere inserita. Come evidenziato nella fig. 3.19, lo use case base A prevede due punti di estensione, mentre il caso duso estendente ne fornisce lapposita definizione. Il punto interrogativo serve a indicare che leffettiva estensione avviene sotto il controllo di una condizione di guardia. Per questo motivo, spesso le relazioni di estensione sono utilizzate per modellare delle parti di use case che rappresentano delle azioni facoltative in modo da distinguerle esplicitamente dal flusso delle azioni non opzionali. In questo modo possibile distinguere il comportamento opzionale da quello obbligatorio del sistema. Il funzionamento prevede che quando unistanza dello use case base raggiunge una locazione referenziata da un punto di estensione, la condizione viene valutata: se lesito positivo (valore true) il flusso delle azioni specificate nel relativo caso duso estendente viene eseguito, altrimenti si procede oltre nellesecuzione del flusso delle azioni dello use case base.

50

Capitolo 3. Introduzione agli Use Case

Figura 3.19 Flusso degli eventi della relazione di estensione.

Use case A

extend

Flusso degli eventi Use case A ..................... ....................... dich. segmento di estensione i ....................... .............. ........ dich. segmento di estensione ii ....................... .............. ........ fine use case

?
Flusso degli eventi Use case B def. segmento di estensione i ..................... ....................... fine segmento def. segmento di estensione ii ....................... .............. ........ fine segmento fine use case

Use case B

Figura 3.20 Prenotazione appelli di esami universitari: esempio di relazioni di estensione.

validazione utente include Prenota appello extensions points


Studente Universitario transazione abilitata verifica idoneita'

(transazione abilitata) [studente abilitato]

extend

(verifica idoneita') [appello selezionato]

extend

Seleziona esame

Verifica idoneita' studente

UML e ingegneria del software: dalla teoria alla pratica

51

Lassenza di una condizione corrisponde a un valore sempre true. Nel caso in cui la relazione di estensione preveda diversi punti di estensione, la condizione viene verificata solo la prima volta, ossia prima dellesecuzione del primo frammento. Chiaramente uno stesso use case pu essere esteso da diversi altri, cos come un caso duso pu estenderne molteplici.

Spesso, analizzando i vari flussi degli eventi che descrivono il comportamento dinamico dei singoli casi duso, ci si imbatte in vere e proprie procedure scritte in linguaggio di programmazione (la patologia della programmite sempre in agguato) infarcite di comandi for, while, if, ecc. Questa soluzione tipicamente non riscuote i consensi dei clienti i quali, per definizione, non sono tecnici informatici e tendono a sentirsi a disagio quando il formalismo tecnico prende il sopravvento. Lesperienza insegna che preferibile cercare di utilizzare un linguaggio quanto pi vicino possibile a quello dei clienti e rendere le varie descrizioni dei casi duso lineari. Per esempio, qualora uno use case sia molto esteso o troppo complicato, possibile semplificarne la struttura inserendo alcuni flussi alternativi in appositi caso duso, connessi a quello oggetto di studio per mezzo di una relazione di estensione. Ovviamente, utilizzando questo espediente bisogna sempre fare attenzione a non eccedere nella granularit.

Il diagramma riportato in fig. 3.20 corrisponde a una funzione che permette a studenti universitari di prenotarsi per gli appelli delle sedute desame previste, magari comodamente seduti nella poltrona di casa, oppure interagendo con opportuni chioschi presenti presso le varie facolt delluniversit (!?). Come si pu notare, il caso duso prenota appello prevede due punti di estensione denominati rispettivamente transazione abilitata e verifica idoneit. Il comportamento del primo punto viene definito dallo use case seleziona esame. Nella relativa relazione di estensione viene esplicitamente dichiarato il punto, o meglio, il segmento che il caso duso estendente specifica nello use case base: transazione abilitata. Sempre nella relazione di estensione definita la condizione che deve essere soddisfatta affinch il flusso del caso duso possa essere eseguito, ossia: lo studente deve essere stato preventivamente riconosciuto e quindi abilitato dal sistema. Un discorso completamente analogo vale per il caso duso verifica idoneit studente il cui obiettivo quello di verificare che lutente sia in possesso di tutti i requisiti (di tipo sia amministrativo, sia di curriculum) per potersi prenotare per la sessione di esami prescelta. In questo caso la condizione da soddisfare che lo studente

52

Capitolo 3. Introduzione agli Use Case

abbia precedentemente selezionato lappello di interesse e il punto in cui viene esteso il caso duso base verifica idoneit.

Ancora una volta, probabilmente non il caso di sprecare energie andando a definire nei diagrammi i punti in cui ogni caso duso estendente estende quello base: possibile fare ci nel flusso di azioni. Probabilmente, non solo si perde molto tempo, ma si finisce anche per complicare inutilmente i diagrammi.

Il flusso di azioni dello use case di fig. 3.20 potrebbe assumere una forma del tipo:
Use case base Prenota appello: 1. include (validazione studente) 2. if studente non riconosciuto then 2.1. if fallita autenticazione studente per tre volte consecutive then 2.1.1.lock the user. 2.1.2.termina con insuccesso. 2.2. 2.2. mostra messaggio utente. torna al punto 1.

3. reperimento dati studente (facolt, anno di corso, ecc.) 4. if dati studente non reperiti then 4.1. 4.2. mostra messaggio termina sessione

5. <transazione abilitata> 8. acquisisci appello selezionato dallo studente 9. <verifica idoneit> 10. fine Extension use case Seleziona esame: definzione segmento <transazione abilitata> 1. acquisisci anno di corso relativo allesame di interesse per lo studente 4. if nessun dato impostato then 5. termina sessione con insuccesso 2. visualizza elenco degli esami relativi allanno impostato 3. acquisisci esame selezionato 4. if nessun esame selezionato then 5. termina sessione con insuccesso 6. restituisci esame selezionato

UML e ingegneria del software: dalla teoria alla pratica


7. mostra appelli previsti per lesame selezionato 8. if nessun appello previsto then 8.1. 8.2. mostra messaggio torna al punto 1.

53

Extension use case Verifica idoneit studente: definzione segmento <verifica idoneit> 1. verifica idoneit amministrativa. 2. if anomalie amministrative riscontrate then 2.1. 2.2. visualizza messaggio termina sessione

3. verifica propedeuticit esame selezionato 4. if riscontro propedeuticit fallito then 4.1. 4.2. visualizza messaggio termina sessione

5. restituisci esito verifica positivo

Lo Use Case estendente pu avere accesso e modificare gli attributi definiti nello use case base mentre questultimo non ha visione dei casi duso estendenti e quindi non pu averne accesso ai relativi attributi/operazioni. Con riferimento al caso presentato, lo use case seleziona esame, per poter visualizzare lelenco degli esami di interesse dello studente per lanno specificato, deve essere in grado di accedere ad informazioni presenti nello use case base come la facolt a cui lo studente risulta iscritto. Quando si ricorre ad una relazione di estensione possibile immaginare lo use case base come un framework modulare in cui le estensioni possono essere inserite, modificandone implicitamente il comportamento, senza che esso ne abbia visione. La differenza tra la relazione di generalizzazione e quella di estensione dovrebbe essere fin troppo chiara ma si ribadisce repetita juvant che nel primo caso il comportamento specializzato presente nelle istanze che generalizzano lo use case mentre nel secondo caso riportato direttamente nello use case esteso. Come gi menzionato, la relazione di estensione viene rappresentata graficamente per mezzo di una freccia tratteggiata corredata dalletichetta <<extend>>. sempre consigliabile organizzare i diagrammi dei casi duso estraendo il comportamento comune (utilizzo delle relazioni di inclusione) e distinguendo le varianti (relazione di estensione). Inoltre opportuno ricordare che uno degli obiettivi dei modelli rappresentare completamente il sistema evitando per di appesantirne inutilmente i diagrammi.

Inclusione o estensione?
Nel processo di progettazione degli use case diagram, prassi comune strutturare i casi duso associandoli tra loro per mezzo di relazioni di inclusione ed estensione. Ci

54

Capitolo 3. Introduzione agli Use Case

permette di realizzare diagrammi pi eleganti, chiari e quindi, in ultima analisi, pi facilmente comprensibili. Il ricorso alle relazioni test enunciate equivale ad affermare che la sequenza delle azioni di un use case necessita, rispettivamente, dellesecuzione di quella espressa in eventuali use case inclusi e che la stessa viene variata da eventuali casi duso estendenti. Non infrequente il caso in cui non si sappia bene quale sia la tipologia di relazione pi appropriata: Quale stereotipo utilizzare: include o extend?.

Prima di procedere in questa disquisizione si ritiene opportuno rimarcare due concetti molto importanti: 1. il tempo una risorsa di massima importanza da utilizzarsi con oculatezza (questo termine racchiude una sua diabolicit): quando non esistono motivazioni lampanti per preferire luna allaltra relazione, probabilmente non vale la pena dedicarsi a elucubrazioni mentali. Spesso si impiega molto tempo cercando di capire quale sia la relazione pi appropriata per un particolare contesto: si ricordi che ancora non stato istituito il premio per il diagramma dei casi duso pi elegante; 2. non si pu pretendere di esprimere i requisiti del sistema unicamente per mezzo del formalismo grafico; probabilmente pi opportuno relegarlo a una sorta di overview (questo argomento viene trattato approfonditamente nel capitolo successivo). Ancora una volta meglio operare economie di tempo anche perch le fasi successive del ciclo di vita del software, e in particolare il disegno, lasciano ampio margine per avvalersi di tutta la propria cultura e skill.

Premesso ci, la prima macrodifferenza tra le due relazioni risiede nellopzionalit: se lesecuzione del flusso di azioni di uno use case invocato deve avvenire solo al verificarsi di particolari condizioni, ossia se rappresenta una variante del flusso di azioni, allora non vi dubbio: bisogna ricorrere alla relazione di estensione. Per esempio nello use case di fig. 3.20 lo studente viene abilitato a selezionare lesame di interesse e quindi a procedere nelliter solo se preventivamente riconosciuto e quindi autorizzato dal sistema. Probabilmente, lopzionalit dellesecuzione il concetto pi importante a cui bisogna prestare particolare attenzione nel selezionare la relazione pi opportuna da utilizzarsi: le altre differenze potrebbero rivelarsi piuttosto marginali. Per tutti gli altri casi di incertezza di seguito viene riportato un elenco di riflessioni che potrebbero rivelarsi utili nella selezione della relazione pi adeguata. Una prima considerazione da farsi relativa allintegrazione: se un caso duso viene invocato solo da un altro, probabilmente opportuno utilizzare il costrutto di estensio-

UML e ingegneria del software: dalla teoria alla pratica

55

ne, se invece possibile riutilizzarlo nel flusso di azioni di svariati casi duso invocanti, allora potrebbe essere preferibile ricorrere a una relazione di inclusione. La relazione di inclusione ricorda molto uninvocazione di procedura (o metodo) e pertanto, nel caso in cui uno use case incluso necessiti di attributi, questi dovrebbero essere forniti dallo use case base. Nel caso di use case estendenti, data la loro natura, del tutto legittimo che essi accedano agli attributi dello use case base. Unaltra argomentazione che potrebbe risultare utile relativa alla conoscenza che un caso duso ha dellaltro utilizzato. Nel caso della relazione di inclusione, lo use case che include ha conoscenza di questultimo, in modo del tutto analogo a quanto avviene nella fase di codifica: un metodo conosce un altro invocato. Nel caso invece della relazione di estensione, lo use case esteso contiene il flusso primario degli eventi e non ha conoscenza diretta di eventuali altri casi duso estendenti (ovviamente predispone esplicitamente i punti il cui comportamento deve essere esteso). Ci implica che lo use case base o esteso deve essere ben formato anche senza la presenza di use case estendenti. Per molti tecnici lo use case estendente paragonabile al comportamento di un editor che aggiorna solo particolari parti di un testo, sia correggendo, sia inserendo nuovi paragrafi. Per concludere largomento, si vuole sottolineare ancora che ogni qualvolta non sussistano evidenti motivazioni per propendere per luna o laltra relazione consigliabile non perdere troppo tempo; lunica cosa che sempre opportuno tenere a mente che uno degli obiettivi primari rendere il tutto il pi semplice possibile: i diagrammi dei casi duso dovrebbero risultare facilmente fruibili anche da personale con scarsa conoscenza di informatica.

Relazioni precede e invoca


Analizzando molti use case diagram prodotti in diverse aziende possibile imbattersi in molteplici stereotipizzazioni delle relazioni base o addirittura in alcune completamente nuove non previste nel metamodello. In particolare nel libro Use Case Driven Object Modeling with UML (vedi Bibliografia) ne vengono proposte due interessanti: invokes (invoca) e precedes (precede), che tra laltro non sono neanche stereotipi. Circa lutilizzo di nuovi elementi esistono diverse correnti di pensiero tutte pi o meno plausibili. Un concetto da tenere bene a mente che ogni qualvolta si ricorre allutilizzo di stereotipi non standard sempre necessario pensare che, se da un lato vero che si tratta di strumenti messi a disposizione dello UML e quindi da utilizzarsi, dallaltro stereotipizzazioni importanti e non standard rendono i modelli meno fruibili, il che evidentemente non esattamente un obiettivo dello UML. Il tutto viene poi amplificato quando ci si riferisce a elementi del tutto nuovi. Quindi il ricorso agli stereotipi va sempre ponderato. Chiaramente non si fa riferimento a stereotipi semplici come licona di Exception per le relative classi, o particolari versioni di attori raffigurati per mezzo di sagome pi specifiche.

56

Capitolo 3. Introduzione agli Use Case

Il consiglio allora pu essere di utilizzare opportuni stereotipi (non quelli banali) ogni qualvolta sia veramente necessario e concorrano effettivamente ad aumentare la qualit e leggibilit del modello, in tutti gli altri casi, probabilmente consigliabile forzarsi a utilizzare elementi standard. Per ci che concerne invece elementi non standard che non siano frutto di stereotipizzazioni, il consiglio non pu che essere di utilizzarli solo in casi di estrema necessit.

Premesso ci, lidea alla base della relazione di invokes molto semplice: un caso duso pu invocarne un altro, analogamente a quanto avviene con le funzioni. Un vantaggio nel ricorrere a relazioni di questo tipo che permettono di focalizzare lattenzione su ci che racchiuso in un caso duso (in termini di sequenza di funzioni). Probabilmente spesso si viene distratti dal come si arrivi a un caso duso (precondizioni) e da cosa accade quando si lascia lo stesso (postcondizioni), senza dare il giusto rilievo allo use case stesso. Per quanto concerne la relazione precedes (precede) essa semplicemente evidenzia che la sequenza di operazioni eseguite da un caso duso deve essere preceduta dallesecuzione di quella presente in un altro. Probabilmente il motivo che rende particolarmente vantaggiose queste relazioni che spesso si cerca di modellare attraverso i casi duso anche aspetti che esulano dal relativo campo di pertinenza (dinamici) nellerrata convinzione che gli use case diagram da soli siano sufficienti a catturare tutti i requisiti funzionali. Come riportato successivamente necessario calarli nella giusta dimensione di overview grafico: in questo contesto il buon testo ancora lo strumento migliore. Probabilmente il diagramma in fig. 3.21 non dovrebbe essere sottoposto al vaglio di unanalisi eccessivamente critica: in fin dei conti si tratta di un esempio e pertanto dovrebbe essere considerato come tale: nessuno vuole commettere lerrore dello stolto che guarda il dito del saggio che indica la luna. Comunque, poich il fine del presente libro sicuramente didattico forse qualche considerazione lecita. Leggendo il diagramma si corre il rischio di capire che il mediatore (Assistente Trader) nellinserire un nuovo ordine nel sistema debba prima impostare il codice per la transazione di vendita (Imposta trade di vendita), poi quello per la transazione di acquisto (Imposta trade di acquisto) e infine definire in dettaglio linvestimento (Definisce investimento). Evidentemente questa sarebbe una conclusione errata, in quanto, nellesempio non si tratta di uno scambio come nella compravendita di valuta Foreign eXchange un singolo trade pu essere o di acquisto o di vendita ma non entrambi. Il problema che le relazioni di precedes sembrerebbero non possedere alcuna semantica che ne indichi lesecuzione alternativa che, invece, presente nelle relazioni di generalizzazione. Pertanto, probabilmente una versione pi chiara del diagramma potrebbe essere quella riportata nella fig. 3.22.

UML e ingegneria del software: dalla teoria alla pratica

57

Figura 3.21 Esempio di un frammento di un trading system. Relazioni di precedes e invokes.

Imposta trade di vendita


precedes

Validazione utente
precedes invokes

Imposta trade di acquisto

Verifica idoneita' studente


Assistente Tader

Esegue perfezionamento trade

Figura 3.22 Versione dello use case inserisce nuovo ordine con la relazione di generalizzazione.

Definisce investimento
include

Inserisce nuovo ordine

Assistente Trader

Ordine di acquisto

Ordine di vendita

58

Capitolo 3. Introduzione agli Use Case

In questo caso evidentissimo che un ordine pu essere o di vendita o di acquisto ma non di entrambe le tipologie.

Come identificare i casi duso


Il processo di identificazione dei casi duso, sebbene possa sembrare unattivit di livello di complessit contenuto, nel contesto del processo di sviluppo del software riveste unimportanza notevole; basti pensare che il cliente alla fine pretende che il sistema realizzi correttamente tutte le funzionalit descritte nella vista dei casi duso. Come illustrato in precedenza, gli attori sono persone o sistemi interessati al comportamento dei casi duso: ne avviano lesecuzione e vi scambiano messaggi. Quindi, poich le funzioni che il sistema deve fornire sono intimamente connesse con gli attori che interagiscono con i casi duso, molto probabilmente possibile semplificare il processo facendo precedere lattivit di identificazione degli attori. Un primo problema che si pone il livello di dettaglio da raggiungere. Spesso lindividuazione e la descrizione dei casi duso viene affrontata con una metodologia di tipo top down iterata fino a raggiungere uneccessiva granularit. Si ricordi che ci non sempre auspicabile perch si investe male il tempo a disposizione, si imprigiona prematuramente il processo di sviluppo, e cos via. Probabilmente preferibile tendere costantemente alla semplicit e alla chiarezza dei diagrammi. Il consiglio pertanto non pu che essere di mostrare unicamente gli use case veramente importanti per il corrente livello di astrazione e per il sottosistema oggetto di studio. Osservando il sistema secondo la prospettiva di cui dispongono gli attori, possibile individuare le funzioni che lo stesso deve implementare rispondendo ai seguenti interrogativi: Quali funzioni sono richieste al sistema da ciascun attore? Quali azioni esegue lattore con particolare riferimento al sistema informatico? Quali sono le informazioni elaborate dal sistema oggetto di interesse dellattore? Che tipo di interazione esiste tra lattore e le informazioni stesse? Le produce, scrive, legge, modifica? Lattore ha necessit di inviare o di ricevere notifiche dal sistema? Quali sono le funzionalit necessarie per ricevere, e/o produrre gli eventi relativi lattore? Il lavoro degli attori, specie quello pi ricorrente, pu essere semplificato o reso pi efficiente? Di quali input e output ha bisogno il sistema? Quale il relativo flusso?

UML e ingegneria del software: dalla teoria alla pratica

59

Una volta esaurito il precedente questionario possibile verificare quanto emerso ponendosi questa volta nellottica del sistema: Di quali input e output il sistema ha bisogno? Da dove provengono questi input e dove sono destinati gli output? Nel caso che gi esista un sistema, quali sono i suoi problemi maggiori nell'implementazione esistente? (Questo quesito potrebbe considerarsi piuttosto marginale: le lamentele sono le prime cose comunicate dagli utenti quando si inizia la serie di interviste). Un approccio differente, che di solito riscuote molto successo, consiste nel cominciare a individuare le funzioni che il sistema dovr realizzare e poi gli attori che vi interagiscono, utilizzando il formalismo degli activity diagram. Questi offrono il grande vantaggio di somigliare moltissimo ai progenitori flow chart e quindi di essere familiari a persone con pochissima esperienza tecnica: chi non ha mai realizzato un flow chart? Pertanto si pu richiedere agli utenti del sistema di redigere prime versioni di tali diagrammi e da questi poi ricavare i casi duso. Chiaramente non pensabile che le versioni prodotte dagli utenti siano quelle definitive, ma comunque esistono due vantaggi: si individua un formalismo di dialogo tra cliente e team tecnici; forniscono un ottimo inizio. In particolare si potr riscontrare che una o pi attivit (a seconda del livello di dettaglio dellactivity diagram e dello use case da produrre) confluir in uno o pi casi duso. Il lato negativo che tipicamente si assister a tutto un fiorire di activity diagram molto simili tra loro; come dire: il dono della generalizzazione tipicamente non alberga presso i clienti. Questa tecnica verr descritta pi in dettaglio nel Capitolo 4.

Organizzazione dei casi duso


I modelli dei casi duso di sistemi non semplici sono generalmente costituiti da svariate decine di diagrammi e da centinaia di singoli casi duso. A questo punto si pone il problema di come strutturare il modello in package. Il consiglio migliore probabilmente di organizzare il tutto nel modo pi naturale possibile. Una buona tecnica realizzare un primo package nel quale inserire tutti gli attori (magari ordinati per nome al fine di semplificarne lindividuazione), seguiti da tanti altri package ognuno dedicato a un diagramma. In questi casi si parla di business functional packages. Nel caso in cui per non sia ben chiaro come organizzare i diagrammi, la linea guida da seguire di utilizzare il vecchio criterio della coesione funzionale: ogni diagramma do-

60

Capitolo 3. Introduzione agli Use Case

vrebbe modellare completamente uno specifico servizio, ossia lobiettivo fondamentale che lefferente attore si aspetta di raggiungere dalla relativa fruizione. Dovendo modellare le funzioni, o pi in generale, il valore offerto dal sistema (o dal business) ai relativi attori, in linea di massima opportuno realizzare un diagramma per ogni singolo servizio erogato al relativo attore. Qualora poi una funzione risulti particolarmente complessa, probabilmente opportuno verificare la possibilit di rappresentarla attraverso diversi diagrammi. Spesso risulta molto conveniente definire un diagramma supplementare, inserito nellapposito package, riportante una sorta di overview un indice dellintero modello. Sebbene non sia pratica consigliata procedere con esercizi di decomposizione funzionale, realizzare un diagramma di tipo top-level risulta molto utile. In questo diagramma dovrebbero comparire tutti gli attori del sistema connessi con i casi duso ritenuti pi significativi. Alcuni tecnici consigliano di realizzare diverse versioni di questo tipo, una per ogni attore. Lautore considera questo esercizio un sovraccarico di lavoro (overhead) che tipicamente provvede un valore aggiunto piuttosto limitato. Il problema non risiede tanto nella realizzazione quanto nella manutenzione dei vari diagrammi.

La classe negli use case


Sebbene il gioco di parole utilizzato nel titolo del presente paragrafo possa far pensare a chiss quali diagrammi, lobiettivo fornire una serie di consigli operativi, tratti dallesperienza, atti ad accrescere il livello qualitativo dei grafici dei casi duso. Il relativo formalismo, sebbene risulti piuttosto intuitivo, viene in ogni caso avvertito come estraneo dal cliente. Pertanto consigliabile sia pianificare delle sessioni di addestramento del personale non tecnico coinvolto nellattivit di revisione del modello dei casi duso si tratta comunque di un formalismo relativamente recente sia ricorrere a una serie di espedienti al fine di rendere i diagrammi pi ordinati e accattivanti: ci se non elimina le iniziali idiosincrasie, sicuramente non le aumenta.

Leleganza uno stato mentale e come tale lo si applica indistintamente allambiente che ci circonda. Esaminare un diagramma ordinato, possibilmente senza linee che si incrociano, con le varie sagome ben allineate e con colori scelti accuratamente sicuramente sortisce un effetto positivo sul cliente. Sebbene labito non faccia il monaco, la prima cosa che si percepisce proprio labito. In ultima analisi, si tratta di stabilire delle convenzioni e, limitatamente a questo caso, ogni team pu decidere liberamente di utilizzare quelle ritenute pi opportune; la parola chiave per coerenza. Una volta scelte delle convenzioni, diventa necessario rispettarle. Riconoscere rapidamente pattern ripetitivi, infatti, ben si adatta alla naturale tendenza

UML e ingegneria del software: dalla teoria alla pratica

61

della mente umana. Tra laltro, sempre da studi di ricercatori in psicologia eseguiti intorno agli anni Settanta, sembrerebbe che sia sette il numero magico di elementi di cui un diagramma dovrebbe essere composto, per risultare pi comprensibile alla mente umana. Pertanto, qualora possibile, risulta preferibile ridurre a sette il numero di elementi presenti in uno stesso diagramma. Lautore viola sistematicamente questa regola. Un altro fattore di psicologia della percezione da tenere sempre presente il valore delle simmetrie (qualche esempio? La splendida Piazza San Giovanni a Roma). Qualora possibile consigliabile organizzare il diagramma cercando di enfatizzare forme simmetriche. Ad onor del vero esiste una gara (non ufficiale) tra gli architetti il cui obiettivo realizzare diagrammi le cui forme ricordino oggetti reali. Molto quotate sono forme ad albero e a missile. Altro elemento da considerare che, sebbene lordine con cui i vari casi duso compaiono nei diagrammi non abbia alcuna relazione con lordine con il quale gli stessi dovranno essere eseguiti per realizzare le funzionalit che descrivono, viene abbastanza spontaneo leggere i diagrammi rispettando lordine di apparizione degli stessi. Dunque, disegnando i casi duso, consigliabile tenere a mente che il lettore sar portato, in qualche modo, a rispettare la sequenza con cui i singoli use case sono collocati nei relativi diagrammi. Qualora possibile opportuno posizionare i casi duso in base al relativo ordine di utilizzo. Rispettare tale orientamento potrebbe risultare in contrapposizione con la necessit di realizzare i famosi diagrammi ordinati; in caso di conflitti, probabilmente pi opportuno assegnare la priorit allarmonia: lordine di esecuzione viene evidenziato nei flussi di azione, nei template e nei diagrammi dinamici. Un altro fattore da considerare la dimensione degli elementi grafici. Anche se questa non dovrebbe fornire informazioni supplementari, come priorit, importanza, ecc. ovvio che lattenzione del lettore tender a essere rapita dagli elementi di dimensioni superiori. Pertanto, se per le caratteristiche di un particolare tool (p.e.: iscrizione del nome del caso duso allinterno dellellisse, come da definizione standard) necessario visualizzare elementi di dimensioni diverse, si consiglia di utilizzare tale inconveniente a proprio vantaggio, per esempio ingrandendo artificiosamente lelemento a cui si vuole attribuire maggiore enfasi e/o importanza.

Per ci che concerne lattivit di selezione dei nomi consigliabile seguire delle convenzioni, semantiche e stilistiche. Per quanto riguarda le prime, preferibile iniziare la descrizione con dei verbi e porsi nellottica degli attori: i nomi devono descrivere gli obiettivi che gli utenti intendono conseguire interagendo con il sistema e non ci che il sistema stesso esegue. Questo sia perch i fruitori principali dei modelli dei casi duso sono gli utenti, sia perch obiettivo del formalismo stesso conferire particolare attenzione alla prospettiva che gli attori hanno del sistema.

62

Capitolo 3. Introduzione agli Use Case

Figura 3.23 Convenzione del posizionamento degli stereotipi a destra rispetto al verso delle frecce.

Figura 3.24 Diagramma illustrante le convenzioni citate.

Reperimento DVD
include

Prenota DVD
include extend

Validazione utente
Cliente
include

Aggiorna disponibilita'
extend

Annulla prenotazione
extend

Addebita penale

Business rule: L'addebito della penale avviene solo in caso di recidivita' (2 ricorrenze nell'arco dello stesso mese)

UML e ingegneria del software: dalla teoria alla pratica

63

Quindi se una funzionalit consiste, ad esempio, nel caricare un file nel sistema, pi opportuno battezzarla Invia file piuttosto che Ricevi file. Per ci che concerne la forma, la praticit suggerirebbe di riportare tutto in minuscolo, mentre dal punto di vista dello stile, probabilmente pi elegante riportare solo la prima lettera in maiuscolo. Per ci che attiene alle direttive da utilizzarsi per gli attori consigliabile utilizzare le convenzioni de facto esistenti per le classi (un attore in ultima analisi pu essere considerato come una classe particolare): nomi con le prime lettere maiuscole e ricordanti il ruolo recitato dallattore e non le singole istanze. Per quanto concerne il ricorso ai colori opportuno evidenziare che, se utilizzati correttamente, concorrono ad aumentare il fascino del diagramma, mentre se usati male o in eccesso tendono a tramutarsi nella classica zappa sui piedi. Colori troppo forti e diagrammi eccessivamente sfarzosi sono decisamente fuori luogo: Carnevale, sebbene sia un periodo piacevole, ha una collocazione temporale piuttosto definita nellarco dellanno. In primo luogo possibile utilizzare i colori al fine di attribuire la giusta enfasi ai vari oggetti presenti nei diagrammi. Per esempio, i campi note, pur contenendo importanti informazioni, raramente risultano vitali e quindi consigliabile attenuarne limpatto. Ci si pu ottenere utilizzando, per esempio, un colore grigio chiaro per la sagoma del foglio, per il font e per la linea tratteggiata che li connette allelemento relativo. La precedente convenzione non vale nel caso si tratti di unannotazione temporanea, riportante un dubbio o comunque unargomentazione transitoria da discutere con il cliente. Per quanto riguarda gli stereotipi associati alle relazioni di estensione e di inclusione, consigliabile riportarli con un font di dimensione abbastanza ridotta. Poich poi le relazioni di estensioni tendono a essere utilizzate per rappresentare comportamenti opzionali, al contrario delle relazioni di inclusione, che invece sono comportamenti obbligatori, risulta molto elegante evidenziare le prime con una gradazione scura di grigio e le seconde con un colore nero. Il tocco finale dato dalla posizione in cui riportare le etichette degli stereotipi: non bisogna lasciare nulla al caso, anzi opportuno trasmettere al cliente la sensazione che tutto sia stato oggetto di lungo e accurato studio. Il consiglio quello di scegliere una convenzione (come per esempio quella in fig. 3.23, in cui le etichette vengono riportate a destra rispetto il verso della freccia), stamparla e quindi osservarla ogni qualvolta sia necessario posizionare uno stereotipo. Un esempio di utilizzo di quanto appena detto riscontrabile in fig. 3.24.

Alcuni esempi
Esempio 1: sistema darma
A conclusione della trattazione sui diagrammi dei casi duso, ossia della proiezione statica della use case view, si fornisce un esempio, forse un po artificioso, ma sicuramente originale, relativo a una versione molto semplificata di un sistema darma contraerei.

64

Capitolo 3. Introduzione agli Use Case

Lungi dallidea di voler fornire una descrizione esaustiva di un sistema cos complesso, altro che il famoso vitto ed alloggio a carico dello Stato si deciso comunque di proporre questo esempio essenzialmente per due motivi: 1. mostrare la peculiarit dello UML di poter essere utilizzato proficuamente in ambienti tra i pi diversificati; 2. fornire un esempio accattivante ed originale non ancora usurato dallinflazione della manualistica. Da una prima analisi del diagramma in fig. 3.25 si pu notare che esistono due tipologie di attori: 1. operatori umani: Comandante e Operatore radar (nei sistemi reali esistono diversi altri attori, ad esempio altri operatori radar, ognuno addetto a interagire con uno specifico dispositivo); 2. dispositivi fisici: Sistema di lancio e Radar, che prevede le specializzazioni in: scoperta, acquisizione, identificazione e puntamento (o guida). Come si pu notare il missile non viene considerato un attore del sistema in quanto la relativa interazione con lo stesso indiretta, ossia viene sempre mediata da altri attori. In fase di lancio i comandi arrivano al relativo dispositivo che si occupa di interagire localmente con il missile. Durante la fase di crociera (tipicamente composta da una fase iniziale di volo cieco e dalla fase guidata) il missile riceve le coordinate del bersaglio sia dal radar di puntamento, sia, tipicamente, da unantenna installata sulla testata del missile stesso. Per terminare, leventuale ordine di autodistruzione viene impartito ancora attraverso apposito segnale radio inviato dal radar. Ovviamente tutti i missili hanno un proprio sistema di autodistruzione temporizzato: se il bersaglio non viene colpito entro un opportuno lasso di tempo (che dipende dalla gittata del missile, dalla sua velocit, ecc.) il missile esplode automaticamente. Un discorso del tutto analogo vale per gli aerei intercettati dai radar: la loro interazione con il sistema viene mediata da altri attori (i radar, appunto). In genere sistemi di questo tipo prevedono una serie di radar di scoperta il cui obiettivo monitorare continuamente e con un ampio raggio di azione lo spazio aereo circostante. Tipicamente ci sono due tipologie di radar di scoperta: quelli per alte e altissime quote (raggiungono distanze superiori ai 100 km) e quelli per le basse quote il cui raggio di azione limitato ai 40/50 km. Una volta individuata una traccia, i relativi dati vengono forniti al sistema (Comunica traccia sospetta) che prevede a inoltrarli sia al Radar di acquisizione il

UML e ingegneria del software: dalla teoria alla pratica

65

Figura 3.25 Use case diagram di un improbabile sistema darma contraerei.

Comunica traccia "sospetta"


Radar di Scoperta

Abbandono traccia Avvia sequenza identificazione


extend

Radar di Acquisizione

Assegna priorita' identificazione Modifica priorita' identificazione Comunica traccia acquisita


Operatore Radar

Radar

Identifica tipologia traccia


Radar di Identificazione

Comunica dati traccia aggiornati

Comando di autodistruzione Avvio sequenza lancio


extend

Radar di Puntamento

Avvio sequenza lancio


Comandante

Modifica priorita' di lancio Distruzione missile Coordinate missile

Abbandono sequenza lancio Coordinate target Sistema pronto per il lancio Comando di lancio
Radar di Puntamento

66

Capitolo 3. Introduzione agli Use Case

quale, se non occupato con altri bersagli, si predispone a puntare la traccia, sia allOperatore radar, il quale in ogni momento pu decidere di abbandonare la sequenza di identificazione (Abbandono traccia), perch magari nel frattempo si scoperto un jet pi minaccioso o perch laereo oggetto di attenzione si sta allontanando dallarea protetta dal sistema darma, e cos via. Nel caso si ritenga necessario procedere con lidentificazione della traccia, lOperatore radar conferma lavvio della sequenza di identificazione (Avvia sequenza identificazione). Tipicamente i caccia nemici eseguono manovre di attacco in squadriglie secondo opportune tattiche. In questi casi il sistema, in base ai dati ricevuti, prevede ad assegnare le priorit di identificazione delle tracce (Assegna priorit identificazione; da notare che si utilizzata la relazione di extend anzich una di include, perch la funzione deve essere eseguita solo nel caso in cui le tracce scoperte siano pi di una). Ovviamente loperatore pu sempre decidere di variare lassegnazione effettuata dal sistema (Modifica priorit identificazione) ed eventualmente decidere nuovamente di abbandonarne una perch magari si tratta di un aereo accertato amico (riconoscibile per esempio dal relativo corridoio aereo di volo). Avviata la sequenza di identificazione i dati della traccia vengono forniti (Comunica traccia acquisita) sia al Comandante sia al Radar di identificazione (comunemente denominato IFF, Identification Friend or Foe) il quale provvede a interrogare il transponder del jet sospetto. In particolare il radar invia un treno di impulsi e si attende una precisa sequenza di risposta la cui analisi permette di stabilire se si tratta di un aereo amico o meno (Identifica tipologia target). Chiaramente i jet nemici, nellatto di unazione offensiva spengono i relativi transponder, pertanto un radar IFF in grado di stabilire se si tratta di un jet amico (codice di ritorno corretto) o di uno non identificato (transponder non risponde). Tra laltro, allatto dellinterrogazione del transponder, il jet nemico viene gentilmente informato di essere oggetto delle amorevoli attenzioni di un radar nemico. Se il jet procede per la sua rotta e non si tratta di un soggetto amico, allora si d inizio alla sequenza di lancio dei missili (Avvio sequenza di lancio). A questo punto nelle cure dellaereo, sicuramente non amico, viene coinvolto anche il Radar di puntamento il quale assolve diversi compiti, ossia gravato dalle seguenti responsabilit: fornire i dati iniziali al sistema di lancio: poich, la fase di volo iniziale di un missile (circa un secondo) cieca (non viene guidato da alcun segnale) si cerca di lanciarlo nella direzione di intercetto stimato del jet nemico; fornire costantemente al missile coordinate aggiornate del punto di intercetto stimato, sia per permettergli di raggiungerlo sia affinch esploda in prossimit al bersaglio: tipicamente questo tipo di missili non cerca limpatto bens lesplosione

UML e ingegneria del software: dalla teoria alla pratica

67

nelle vicinanze del bersaglio, in modo da tentare di colpire, con schegge generate dalla deflagrazione, pi nemici possibili nel caso che ne siano presenti pi di uno nella zona; inviare al missile, in casi estremi, il segnale di autodistruzione. Nel caso tipico di una attacco portato da diversi jet il sistema provvede nuovamente a riassegnare le priorit di intercettamento (Assegna priorit di lancio) le quali, come lecito attendersi, possono essere sempre variate a discrezione del Comandante (Modifica priorit di lancio). Da tener presente che un sistema darma possiede diversi radar di puntamento, svariati sistemi di lancio, ognuno dei quali armato con diversi missili ecc. Una volta che il sistema di lancio viene stimolato per il lancio, riceve le coordinate di intercetto stimato (Coordinate target), si predispone nellopportuna direzione e quindi notifica al Comandante di essere pronto per il lancio vero e proprio (Sistema pronto per il lancio): il pulsante rosso comincia a lampeggiare. A questo punto il Comandante pu decidere di abbandonare la sequenza di lancio (Abbandono sequenza di lancio) o selezionare uno dei missili disponibili sul sistema di lancio prescelto (Comando di lancio). La sequenza potrebbe essere annullata perch per esempio nel frattempo un altro target si reso pi minaccioso, perch lo stesso stato abbattuto da un precedente lancio, ecc. Una volta lanciato il missile il Comandante pu decidere in ogni istante di distruggerlo (Distruzione missile). Nei precedenti paragrafi stato descritto molto superficialmente il modo in cui potrebbe funzionare un ipotetico sistema darma contraerei. Come si potr ben notare il diagramma dei casi duso di per s non sufficiente a specificare completamente le funzionalit del sistema: assolutamente necessario disporre anche della descrizione del comportamento dinamico, nonch della descrizione delle azioni da seguire nel caso in cui si verifichino delle anomalie (per esempio il sistema di lancio ha un bug e non riesce a lanciare il missile selezionato dal Comandante).

Esempio 2: noleggio DVD


Viene qui fornita la proiezione statica, corredata da opportuna spiegazione, dei requisiti utente di un ipotetico sistema di gestione di un esercizio commerciale noleggio DVD. Il sistema finale sfrutter una tecnologia web based al fine di disporre di un unico sistema fruibile sia tramite connessione Internet sia per mezzo di apposite installazioni (chioschi), presenti presso i vari punti vendita. Lintero servizio risulter basato su appositi account virtuali assegnati allutente allatto della relativa iscrizione e accessibili attraverso il tradizionale sistema di login e password. Ogni qualvolta un cliente nolegger un DVD, il relativo account verr decrementato di

68

Capitolo 3. Introduzione agli Use Case

Figura 3.26 Overview delle funzionalit del sistema.

Richiede iscrizione via web Inserisce nuovo cliente Gestione account Ricezione esito Ricarica account Verifica disponibilita' DVD
Utente Cliente Commesso Credit Card Authority Amministratore

Prenota DVD Annulla prenotazione Noleggio DVD Riconsegna DVD Aggiorna stock

un importo proporzionale a specifici parametri decisi in base a DVD prescelto, tempo di noleggio, ecc. La ricarica dellaccount potr essere effettuata online dai clienti tramite carta di credito oppure utilizzando metodi pi tradizionali direttamente presso lesercizio. Prima di iniziare la disamina delle varie funzionalit, stata riportata nella fig. 3.26 una sorta di overview dei servizi disponibili. In particolare possibile notare la visualizzazione dei confini del sistema, evidenziati per mezzo di apposito rettangolo. Obiettivo della fig. 3.26 fornire una sorta di indice dei servizi e, considerato il fine del diagramma, i casi duso mostrati possono risultare leggermente diversi dalla realt. Per esempio lo use case Gestione account viene illustrato associato allattore Credit Card Authority mentre nella realt non esattamente cos. In particolare il caso duso Invia richiesta autorizzazione, non mostrato nelloverview, che effettua uno scambio con la Credit Card Authority.

UML e ingegneria del software: dalla teoria alla pratica

69

Figura 3.27 Adesione del cliente allesercizio commerciale.


Richiede iscrizione via web

Utente

Inserisce nuovo cliente

Amministratore

Figura 3.28 Gestione account.


Validazione utente
include

Gestione account
Cliente
extend extend extend

Aggiornamento dati

Visualizzazione transazioni Ricarica importo

Pagamento via carta di credito

Ricezione autorizzazione
extend [Richiesta autorizzata]

Credit Card Authority

Ricarica importo

Figura 3.29 Ricarica account.


Validazione utente
include

Ricarica account
Amministratore Commesso extend

Reperimento account

70

Capitolo 3. Introduzione agli Use Case

La prima operazione (fig. 3.27) che un potenziale cliente deve compiere per poter acquisire lo status di cliente del servizio di noleggio DVD consiste nel registrarsi (Richiede iscrizione via Web). Chiaramente la relativa richiesta deve essere convalidata dallamministratore del sistema (Inserisce cliente); in altre parole, egli ne ha la completa responsabilit. Qualora il potenziale cliente non disponga di una connessione Internet, la relativa richiesta dovrebbe essere effettuata per mezzo dei chioschi ubicati presso lesercizio commerciale, eventualmente con il supporto del relativo personale. Uno dei primi servizi a disposizione del cliente la gestione del proprio account (fig. 3.28). Chiaramente si tratta di una funzione sensibile e quindi laccesso prevede il riconoscimento cliente eseguito tramite immissione della coppia di valori codice cliente e password. Questo servizio consente al cliente di verificare gli addebiti effettuati sul relativo account (Visualizza transazioni), di modificare i propri dati (Aggiornamento dati) o di incrementare limporto (Ricarica importo). Chiaramente, questultima funzionalit pu essere fruita solo dai clienti in possesso di carta di credito. Le relative transazioni necessitano la conferma di apposite autorit esterne. Qualora il cliente non disponga di carta di credito, la ricarica dellefferente account pu essere espletata direttamente nellesercizio. In questo caso, come mostrato da fig. 3.29, il commesso a interagire con il sistema anche se fa le veci del cliente. Le metodologie tradizionali, quali per esempio DFD, prescrivono che lattore colui che ha interesse nella fruizione di un servizio (in questo caso quindi dovrebbe essere ancora il cliente) e non chi interagisce fisicamente con lo stesso, mentre lo UML prevede lesatto contrario: lattore colui che interagisce direttamente con il sistema anche se fa le veci di unaltra persona. La ricarica dellaccount del cliente eseguita presso lesercizio commerciale di solito una funzione di competenza dei commessi, ma nulla vieta che a espletarla sia lamministratore. Dal punto di vista degli use case, lamministratore risulta essere una specializzazione del commesso: in grado di eseguire tutte le stesse funzionalit, ma in pi gravato da ulteriori responsabilit. Anche il servizio di ricarica account rientra nella categoria delle funzioni ritenute sensibili per il sistema, quindi la sua fruizione prevede il riconoscimento dellutente. La ricarica prevede il reperimento dellaccount del quale si vuole incrementare limporto (Reperimento account) che potrebbe essere effettuato sia specificando il codice dellaccount sia utilizzando i dati del cliente, ecc. Unaltra funzionalit resa disponibile dal sito la verifica della disponibilit di specifici DVD. Nel diagramma riportato in fig. 3.30 si deciso di indicare un attore generico (Utente) per indicare che tale funzione disponibile per qualsiasi fruitore del sito e anche per utenti occasionali. In altre parole la funzionalit di Verifica disponibilit non considerata sensibile per il sistema e quindi pu essere usufruita senza la necessit di riconoscere lutente.

UML e ingegneria del software: dalla teoria alla pratica

71

Figura 3.30 Verifica disponibilit.

Commesso

Verifica disponibilita' DVD


Commesso include

Reperimento DVD
Cliente

La verifica della disponibilit prevede lutilizzo della funzione di reperimento DVD (Reperimento DVD). La ricerca pu avvenire utilizzando diversi criteri: specificando il titolo eventualmente anche in maniera incompleta, alcuni interpreti, il regista o il periodo di uscita. Un altro servizio messo a disposizione della propria clientela la possibilit di prenotare DVD (fig. 3.31). Si tratta ovviamente di un servizio appartenente alla categoria di quelli considerati sensibili e pertanto la relativa abilitazione subordinata alla validazione del cliente. La funzione prevede la validazione del cliente, il reperimento del DVD da prenotare ed eventualmente, nel caso che il DVD sia disponibile, la prenotazione vera e propria con conseguente aggiornamento della disponibilit. In maniera del tutto analoga un cliente pu disdire una prenotazione. In questo caso potrebbe essere prevista una penale economica da applicarsi in funzione a opportuni parametri, quali, per esempio, la recidivit, la durata della relativa prenotazione ecc. Queste regole dovrebbero essere illustrate dettagliatamente nella descrizione delle business rules. Una delle funzionalit di vitale importanza per lesercizio il noleggio vero e proprio di DVD, il quale, nellesempio illustrato, pu essere eseguito unicamente presso i punti vendita dellesercizio stesso, attraverso appositi dispositivi. In sostanza non si presa in considerazione la possibilit di consegna a domicilio. Chiaramente si tratta di una funzionalit sensibile per il sistema e quindi fruibile previa validazione dellutente. Un DVD pu venir noleggiato a seguito di precedente prenota-

72
Figura 3.31 Prenotazione DVD.

Capitolo 3. Introduzione agli Use Case

Reperimento DVD
include

Prenota DVD
include extend

Validazione utente
include

Aggiorna disponibilita'
extend

Cliente

Annulla prenotazione
extend

Addebita penale

zione oppure sperando che sia disponibile allatto della richiesta stessa. Si pu notare che i due comportamenti alternativi, in quanto tali, sono evidenziati per mezzo di relazione di generalizzazione (fig. 3.32). Nel primo scenario necessario dapprima reperire la prenotazione (Reperimento prenotazione) e quindi, nel caso che le varie verifiche abbiamo esito positivo e si possa procedere per il noleggio, rimuovere la prenotazione stessa (Chiudi prenotazione). Nel secondo scenario invece necessario reperire il DVD (Reperimento DVD) che si intende noleggiare. In entrambi i casi, se la funzione di noleggio viene eseguita con successo, necessario aggiornare la disponibilit di copie del DVD (Aggiorna quantit). Il servizio di noleggio prevede la verifica del credito del cliente (Verifica credito) ma non il relativo addebito; questo viene effettuato in fase di riconsegna in quanto limporto pu dipendere da fattori quali il tempo di noleggio. Specularmente al servizio precedente, ma con le stesse modalit, vi la riconsegna del DVD noleggiato. Come si pu notare dallanalisi del diagramma in fig. 3.33, in questa fase avviene laddebito dellimporto dovuto per il noleggio del DVD (Addebito importo). Unaltra funzionalit presa in considerazione quella che consente a commessi e amministratori di aggiornare gli stock a disposizione (fig. 3.34). Ci pu avvenire o perch si acquistano nuove copie di DVD o perch se ne deteriorano altre e quindi esse non risul-

UML e ingegneria del software: dalla teoria alla pratica

73

Figura 3.32 Noleggio DVD.

Aggiorna disponibilita' Validazione utente


include extend extend

Verifica credito

Noleggio DVD
Cliente

Noleggio prenotato
include extend

Noleggio ex-novo
include

Reperimento prenotazione Chiusura prenotazione

Reperimento DVD

Figura 3.33 Riconsegna DVD.

Validazione utente
include

Riconsegna DVD
Cliente extend extend

Aggiorna disponibilita'

Addebito importo

74
Figura 3.34 Aggiorna stock.

Capitolo 3. Introduzione agli Use Case

Validazione utente
include

Aggiorna stock
Commesso

Inserimento nuovo DVD

Modifica stock
include

Inserimento nuova copia

Eliminazione copia

Reperimento DVD

tano pi disponibili per la clientela. In particolare, laggiornamento dello stock pu essere relativo a copie di DVD gi presenti nel database del sistema, nel qual caso si aggiornano unicamente il numero di copie e i codici delle istanze, o a DVD del tutto nuovi. Il primo scenario si differenzia operativamente dal secondo perch richiede il reperimento del DVD di cui si vuole aggiornare il numero di copie disponibili. In questi paragrafi stato presentato un ulteriore esempio di proiezione statica dei casi duso per un servizio di noleggio DVD. In particolare si presentata una sua frazione. Ovviamente possibile estendere i servizi disponibili con ulteriori possibilit, specialmente per quanto concerne il lato back office. Per esempio si potrebbero inserire ulteriori funzionalit per la generazione di dati statistici, altre per verificare inadempienze di clienti, e cos via. Ci nonostante, si spera di aver fornito al lettore una panoramica abbastanza esauriente dei casi duso. Nel Capitolo 4 verranno affrontate tematiche relative a un uso pi esteso del formalismo dei casi duso, con sensibili allontanamenti dalle direttive standard.

Verifiche dei casi duso


Verificare una vista dei casi duso significa sostanzialmente eseguire due attivit di test: verifica vera e propria e validazione. Il primo processo serve a confermare che la vista sia stata realizzata correttamente e in accordo alle specifiche raccolte. Obiettivo della

UML e ingegneria del software: dalla teoria alla pratica

75

validazione accertare che il sistema, cos come lo si modellato, sia effettivamente ci di cui il cliente e gli utenti finali hanno bisogno. I processi di validazione dovrebbero essere eseguiti, di regola, immediatamente dopo la conclusione di ogni singolo processo con lobiettivo di neutralizzare il prima possibile eventuali errori, lacune, ecc. Nel contesto degli use case, verosimilmente, opportuno procedere con le attivit di revisione non appena i primi diagrammi siano disponibili. Essi andrebbero sottoposti al e discussi con il cliente: in altre parole la validazione dovrebbe essere eseguita essenzialmente dagli stessi clienti, anche se nella pratica ci non sempre possibile.

Un buon criterio per la realizzazione del modello dei casi duso consiste nellutilizzare lormai classico approccio iterativo ed incrementale. Invece di dettagliare globalmente ogni singolo use case prima di passare al successivo, potrebbe risultare pi opportuno procedere per passi successivi. Per esempio si potrebbe iniziare con una prima versione globale ad alto livello di astrazione, nella quale includere, per ciascun caso duso, una breve descrizione. Quindi si potrebbe procedere realizzando una seconda versione associando a ciascun caso duso la descrizione del flusso in cui tutto funziona correttamente, ossia trascurando la gestione delle eccezioni, e cos via.

Lintento di tale tecnica quello di riesaminare continuamente i vari modelli prodotti prima di procedere nelle fasi successive. Tale approccio aiuta a neutralizzare uno dei classici problemi della progettazione dei sistemi software: i requisiti solo in casi rarissimi sono chiari e completamente corretti fin dallinizio. Chiaramente non si tratta di un approccio di decomposizione-funzionale, che come si vedr di seguito pu comportare non pochi problemi, bens di un modo di procedere basato su continui feedback: sottoponendo modelli, anche se non ancora ben definiti, agli utenti e agli esperti del dominio, si permette di neutralizzare il prima possibile eventuali lacune, errori di specifiche, ridondanze ecc. Tra laltro la modellazione dei casi duso, per sistemi non banali, non certamente un compito elementare, e quindi, difficilmente ipotizzabile pensare di riuscire a realizzare un modello valido alla prima iterazione. Lobiettivo del processo di validazione dimostrare che il modello corretto, completo, rispondente alle aspettative del sistema, e cos via. A tal fine necessario assicurarsi che i fruitori non tecnici dei diagrammi siano effettivamente in grado di comprenderli. I processi di verifica, vitali per i sistemi software, indipendentemente dal contesto in cui li si effettua, dovrebbero essere condotti con una visione pessimistica delle cose: errare humanum est. Dunque lobiettivo dovrebbe consistere nellindividuare il maggior nu-

76

Capitolo 3. Introduzione agli Use Case

mero di incongruenze ed errori possibili e non semplicemente nellassicurare che tutto funzioni correttamente e sia rispondente. Un buon processo di verifica dovrebbe evidenziare problemi: meglio iterare pi volte la progettazione di uno use case che ridursi a correre ai ripari a progetto in fase di consegna o addirittura ultimato. Come ripetuto pi volte, errori o manchevolezze sfuggiti nella fase di analisi dei requisiti utente possono generare ripercussioni devastanti nelle fasi di codifica e soprattutto di test.

Metodologia Walking the use case


Una tecnica di validazione degli use case diagram frequentemente utilizzata specie negli USA (come sbagliarsi?) prende il nome di Walking the use case. Si tratta di un gioco di ruolo, da praticare in gruppo (sempre molto in stile USA), in cui diverse persone recitano il ruolo degli attori presenti dei diagrammi duso e il master recita il ruolo del sistema stesso. Lesperienza li rende in grado anche di recitare il ruolo di attori non umani, come: sensori, radar, missili Tale tecnica viene presa cos seriamente, e spesso tale limmedesimazione, che durante la simulazione si corre il rischio che taluni attori, impersonando ruoli non umani, siano portati a esprimersi con voce metallica Il gioco comincia con i partecipanti che studiano le loro parti, e quindi sottopongono al sistema gli stimoli previsti dallattore che stanno impersonando. Gli sviluppatori non prendono parte attiva del gioco come al solito il divertimento e le glorie agli altri ma fungono da arbitri. Armati di blocchetti pardon di portatili prendono nota di ci che accade e cercano di individuare eventuali deficienze (sempre quelle dei diagrammi, si intende). Attraverso lutilizzo di questa tecnica si evidenzia che talune alternative non sono sufficientemente dettagliate, che taluni stimoli risultano lacunosi, ecc.

Anomalie tipiche del disegno degli use case diagram


Nei paragrafi successivi vengono illustrate imprecisioni commesse frequentemente nel disegno dei diagrammi dei casi duso. Per molti tecnici si tratta di veri e propri problemi attribuibili al formalismo dei casi duso, mentre per lautore si tratta di equivoci, del tutto comprensibili, nellutilizzo. Il malinteso basilare che verosimilmente genera diversi inconvenienti lerrata convinzione, radicata in alcuni progettisti, che i diagrammi dei casi duso da soli siano in grado di catturare tutti gli aspetti dei requisiti del cliente: gli use case diagram sono ottimi strumenti per la modellazione della proiezione statica delle funzionalit che il sistema dovr realizzare, mentre non possiedono alcuna caratteristica che li renda in grado di visualizzare il relativo comportamento dinamico. Per tale proiezione esistono altri formalismi pi efficaci (lo si sar ripetuto a sufficienza?).

UML e ingegneria del software: dalla teoria alla pratica

77

In sintesi si pu affermare che probabilmente non il caso di perdere molto tempo nel disegnare raffinati e onnicomprensivi diagrammi dei casi duso, forse pi opportuno relegarli a una funzione di overview per dedicarsi con maggiore attenzione allanalisi del comportamento dinamico delle relative funzionalit. Limperativo categorico sempre lo stesso: ottimizzare il tempo questa maledetta entit che incapsula le nostre vite a disposizione. Probabilmente opportuno non dimenticarsi mai che il tempo una risorsa, sempre troppo limitata, e lanalisi dei requisiti utente propedeutica alle restanti fasi del ciclo di vita del software: fintanto che il relativo documento non pronto, diversi elementi del team corrono il rischio di rimanere in uno stato di stand-by per poi essere gravati da una elevata mole di lavoro per via dello scarso tempo a disposizione. Alcuni consigli potrebbero sembrare in contraddizione tra loro. Per esempio si pu commettere lerrore di generare use case eccessivamente astratti cos come lopposto, ovvero use case privi di astrazione. Ci non deve sorprendere, linformatica insegna sempre a cercare il giusto mezzo. Per esempio si ambisce sempre a un disegno in grado di generare un sistema molto flessibile, salvo scoprire che uneccessiva flessibilit possa condurre a un sistema in grado di fare nulla.

Eccessiva scomposizione
Non infrequente il caso di architetti che approdino allo UML dopo aver maturato esperienza e successi nellutilizzo della metodologia di analisi nota con il nome di analisi strutturata, e tendano a riadattare al nuovo formalismo gli ormai consolidati schemi mentali. Ci per non genera sempre buoni risultati. Spesso il vecchio modo di operare porta a organizzare gli use case come si faceva con i DFD: si realizza un primo use case molto generale, poi si produce tutta una serie di diagrammi che aumentano il dettaglio delle singole funzioni e si prosegue fino a giungere a use case abbastanza elementari o atomici. Sebbene ci sia possibile, non sempre auspicabile in quanto si tende a provocare diversi e ben noti inconvenienti, non ultimo linadeguato utilizzo del tempo a disposizione. In primo luogo si corre il rischio di far somigliare gli use case allorganizzazione del codice. La scomposizione funzionale porta a ragionare in termini di eccessivo dettaglio, dimenticando che non c alcun bisogno che la struttura interna (il disegno) del sistema assomigli a quella esterna. Si pecca di mancata astrazione, ci si lega immediatamente al come realizzare le funzioni (in una fase in cui tra laltro non sia hanno ancora informazioni a sufficienza per le soluzioni), vincolando fortemente le successive fasi del ciclo di vita del software. Scomponendo ogni singolo use case, ottimizzandolo, conferendogli un opportuno aspetto grafico e cos via, forse si utilizza male tempo prezioso che potrebbe essere sfruttato

78

Capitolo 3. Introduzione agli Use Case

proficuamente per le altre attivit. Si ricordi che il prodotto della use case view assolutamente propedeutico alle altre fasi del ciclo di vita software. Lesperienza insegna che verosimilmente nelle fasi iniziali pi importante analizzare i rischi pi elevati, demandando i dettagli alle fasi successive. Quando lautore inizi a collaborare con una grande azienda londinese, alle sue affermazioni riguardo limportanza di adottare gli use case nel contesto dellanalisi dei requisiti, si ribatteva che i clienti non erano molto contenti di utilizzare il formalismo dei casi duso. Ci suonava molto strano: di solito i clienti sono felici di giocare con gli omini stilizzati. Visionando poi i diagrammi, labnorme quantit di pi di qualche migliaio di casi duso facilit decisamente la comprensione del sentimento di rifiuto provato dai clienti.

Mancanza di astrazione
Frequentemente un fattore che causa non pochi inconvenienti nella produzione di sistemi software di qualit la difficolt di instaurare una piattaforma di conversazione tra il cliente e il personale tecnico. Spesso, al fine di circoscrivere questo fattore di rischio, si tenta di procedere nellanalisi dei requisiti fornendo al cliente opportuni prototipi del sistema finale. Ci permette di concretizzare lattenzione e di eliminare alla radice diversi malintesi. Si tratta di un escamotage che correttamente applicato pu produrre i suoi buoni frutti, a patto che i prototipi non diventino magicamente versioni definitive ma che talune volte pu invece generare diversi problemi. Lidea alla base molto semplice: poich esistono validi strumenti per realizzare in breve tempo una serie di interfacce utente, possibile pensare di costruire un primissimo prototipo basato sulle sole schermate di interazione utente/sistema. Si tratta di un vero prototipo usa e getta, da utilizzarsi unicamente allo scopo di migliorare il processo di analisi dei requisiti del cliente. Logica conseguenza di ci che lo use case viene realizzato in base al prototipo e alle osservazioni scaturite dai colloqui con il cliente. I vantaggi prodotti da tale approccio sono essenzialmente la possibilit di condurre il cliente a ragionare su elementi concreti forse , di riuscire a isolarsi da dettagli, di delineare proiezioni meno astratte del sistema finale. Gli svantaggi possono essere diversi. In primo luogo si rischia di ingenerare nel cliente lidea che il sistema sia ormai pressoch pronto e che quindi la relativa progettazione sia giunta alle fasi finali: parafrasando Stroustrup, i prototipi possiedono il diabolico difetto di somigliare al sistema finale. Mentre invece manca ancora tutto. A quel punto non c nulla da fare: tutti i tentativi di convincere il cliente del contrario tendono a cadere nel vuoto. Un altro inconveniente che si rischia di legarsi troppo al prototipo, di non analizzare aspetti ritenuti di secondaria importanza, magari semplicemente perch non previsti dal prototipo realizzato in fasi ancora molto acerbe, e di sottostimare i tempi.

UML e ingegneria del software: dalla teoria alla pratica

79

Una buona idea potrebbe essere quella di presentare prototipi molto grossolani, cosicch anche il gradimento del sistema finale ne verr favorito, eventualmente composti di soli disegni, magari realizzati per mezzo di carta e penna, o documento elettronico. Resta comunque forte il timore che, anche in questo caso, si possano trovare commerciali in grado di trasformarli magicamente, nel giro di pochi secondi, in prodotti finiti.

Eccessiva astrazione
Tutti coloro che operano nel settore dellObject Oriented in maniera seria (!?), prima o poi, tendono a diventare adepti della setta dellastrazione: ogni cosa pu essere astratta, anche i familiari. Schemi mentali siffatti sono pi che positivi, a patto che non si sconfini in livelli di astrazione eccessivi: ci nel contesto dei casi duso, e non solo, pu generare non pochi problemi. Non va mai dimenticato che i principali fruitori della use case view sono i clienti, e pertanto, uno degli obiettivi fondamentali della vista facilitare un sano scambio informativo tra cliente e team di analisti: non a caso si utilizzano gli scarabocchietti. I clienti molto raramente si trovano a loro agio quando il discorso si eleva sul piano dellastratto, e quindi si corre il rischio di dover impiegare non poco tempo nel tentativo di illustrare, spiegare e argomentare le varie astrazioni. Ci diventa ancora pi drammatico quando, durante i meeting, non si parla in lingua madre. Pertanto, astrarre i diagrammi pi di quanto sia effettivamente necessario potrebbe confondere inutilmente il cliente e, in ultima analisi, limitare o addirittura inibire, linstaurazione di un dialogo costruttivo. La parola dordine per gli use case sicuramente la concretezza: la mancanza di astrazione a questo livello non incide minimamente sul livello di astrazione delle restanti viste.

Ricapitolando
Il presente capitolo stato dedicato allillustrazione dei concetti forniti dallo UML per supportare il delicato processo dellanalisi dei requisiti utente: lattenzione stata pertanto focalizzata sulla prima vista dello UML: la use case view (vista dei casi duso). Obiettivo di questa fase, descrivere quali servizi dovr fornire il sistema senza specificarne il come. Limpegno cercare di isolarsi, di astrarsi il pi possibile da dettagli realizzativi il cui studio demandato alle fasi successive. I processi di sviluppo del software pi popolari incorporano approcci di tipo use case driven (guidati dai casi duso), per cui la vista dei casi duso diviene il punto di riferimento per tutto il ciclo di sviluppo del sistema, dalla progettazione allo sviluppo ai test. Uno degli obiettivi della use case view quello di agevolare il processo di analisi dei famosi requisiti utente, ossia le richieste legittime del cliente, le sue elucubrazioni mentali, le distorsioni, le aspettative

80

Capitolo 3. Introduzione agli Use Case

La proiezione statica della vista use case si basa sugli omonimi diagrammi frutto del lavoro svolto da I. Jacobson durante la sua collaborazione con la Ericsson nellambito dello sviluppo di un sistema denominato AXE. Visto il successo riscosso dai diagrammi e percepitene le potenzialit, i Tres Amigos hanno pensato bene di inglobarli nello UML. Gli use case diagram sono utilizzati per dettagliare le funzionalit del sistema, rappresentate graficamente attraverso elementi ellittici denominati anchessi use case, dando particolare rilievo agli attori che interagiscono con esse. Da tener presente che i diagrammi dei casi duso permettono di analizzare la proiezione statica delle funzionalit del sistema mentre, per modellare quella dinamica, possibile far ricorso agli interaction e activity diagram. In questa fase del ciclo di vita del software vengono utilizzati per rappresentare particolari istanze dei casi duso dette scenari. Semplificando al massimo il concetto, possibile affermare la proporzione: gli scenari stanno agli use case come gli oggetti stanno alle classi. Il ricorso ai suddetti diagrammi, sebbene presenti diversi vantaggi attribuibili essenzialmente allimmediatezza della notazione grafica, pu presentare alcuni inconvenienti come la difficolt di manutenzione, la difficolt di lettura al crescere delle entit coinvolte, ecc. Probabilmente opportuni template dei casi duso finiscono per essere lo strumento migliore: sono chiari e decisamente facili da manutenere. La vista dei casi duso oggetto di interesse per un vasto insieme di figure professionali coinvolte nel ciclo di vita del sistema: dai clienti ai capi progetto, dagli architetti ai programmatori, ai tester, agli addetti al marketing, ai commerciali e cos via. Una delle principali entit oggetto di studio nella use case view lattore, il quale definisce un insieme coerente di ruoli che un utente di un caso duso recita quando interagisce con esso. Un attore non necessariamente una persona: pu essere un sistema automatizzato o un qualsiasi dispositivo fisico; in generale unentit esterna al sistema che interagisce con esso. Si tratta dellidealizzazione di un persona esterna, di un processo, o di qualsiasi cosa che interagisce con il sistema inviando e/o ricevendo messaggi: scambiando informazioni. Gli attori vengono rappresentati graficamente nello UML attraverso sagome di omini stilizzati (stick man). Nella realizzazione di use case diagram pu verificarsi il caso in cui pi attori presentino diverse e significative similitudini: per esempio interagiscano con un insieme di casi duso con le stesse modalit. In questi casi come insegnato dai princpi del paradigma Object Oriented possibile dar luogo a un nuovo attore, magari astratto, che raccolga a fattor comune tali similitudini, esteso dagli altri per mezzo di apposite relazioni di generalizzazione. Ogni attore deve essere necessariamente connesso con un insieme di casi duso (funzioni del sistema) che ne ricevono gli stimoli e che producono i dati richiesti dallattore stesso. Identificare gli attori del sistema unattivit molto importante: si identificano le entit interessate a usare e interagire con il sistema e quindi i servizi di cui vogliono usufruire.

UML e ingegneria del software: dalla teoria alla pratica

81

Un caso duso rappresenta una funzionalit completa cos come viene percepita da un attore. Si tratta di un costrutto utilizzato per definire il comportamento di un sistema o di unaltra entit semantica senza rivelarne la struttura interna. In termini pi formali, un caso duso un tipo di Classificatore (UseCase eredita da Classifier) che rappresenta ununit coerente di funzionalit fornita da una specifica entit (sistema, sottosistema, classe) e descritta sia dalla serie di messaggi scambiati tra lentit stessa ed unaltra interagente esterna (attore), sia dalla sequenza di azioni svolte. Ogni caso duso pertanto definito da una sequenza di azioni (comportamento dinamico) che lentit esegue interagendo con il relativo attore, necessarie per erogare un servizio. La generalizzazione (generalization) applicata ai casi duso rappresenta una relazione tassonomica tra un use case, figlio, e un altro, chiamato genitore, che descrive le caratteristiche che il caso duso divide con altri use case che hanno lo stesso genitore. Un caso duso genitore pu essere specializzato in uno o pi figli che ne rappresentano forme pi specifiche. Lo use case figlio eredita gli attributi, le operazioni, il comportamento del genitore, e pertanto pu sovrascrivere (override) o aggiungere comportamento (attributi, operazioni). Da notare che la presenza di una relazione di generalizzazione implica che lesecuzione di use case fratelli pu avvenire unicamente in alternativa. Linclusione una relazione tra uno use case base e uno incluso che specifica come il comportamento di questultimo possa essere inserito in quello definito nello use case base, il quale, pu avere visione dellincluso e dipende dagli effetti da esso generati durante la relativa esecuzione. In termini della sequenza delle azioni che ciascun caso duso esegue per erogare un servizio, la relazione include comporta linserimento della sequenza di azioni dello use case incluso in quella del caso duso base sotto il controllo e nella locazione specificata dello use case base. Una relazione di estensione (extend) una relazione tra un caso duso estendente ed uno base che specifica come il comportamento definito dal primo (lestendente) debba essere inserito nel comportamento di quello base. Spesso, le relazioni di estensione sono utilizzate per modellare delle parti di use case che rappresentano delle azioni facoltative in modo da distinguerle esplicitamente dal flusso delle azioni non opzionali. In questo modo possibile distinguere il comportamento opzionale da quello obbligatorio del sistema. Quando si ricorre ad una relazione di estensione possibile immaginare lo use case base come un framework modulare in cui le estensioni possono essere inserite, modificandone implicitamente il comportamento, senza che esso ne abbia visione. Unistanza di un caso duso (scenario) lesecuzione dello stesso, avviata dalla ricezione di un messaggio inviato da unistanza di un attore. Come effetto dello stimolo, lo use case esegue la sequenza delle azioni da esso identificate, eventualmente scambiando messaggi con attori diversi da quello che ha prodotto lo stimolo iniziale. I diagrammi dei casi duso permettono di illustrare le singole funzionalit del sistema attraverso opportune relazioni tra use case al fine di rilevare, a grandi linee, la struttura statica degli stessi, evidenziando eventuali sottofunzioni di particolare importanza, men-

82

Capitolo 3. Introduzione agli Use Case

tre non possiedono alcuna caratteristica intrinseca che li renda in grado di rilevare il comportamento dinamico; inoltre necessario ricorrere a diversi artifici per tentare di evidenziare eventuali condizioni anomale, non possibile specificare le azioni da intraprendere per la relativa gestione, e cos via. Come gi evidenziato possibile esprimere il comportamento dinamico dei casi duso sia attraverso il formalismo dei flussi di azione, sia utilizzando appositi diagrammi messi a disposizione dallo UML per la modellazione della componente dinamica del sistema (diagrammi di interazione, activity diagram, e cos via). Lesperienza quotidiana suggerisce che lo strumento pi opportuno da utilizzarsi per dettagliare il comportamento dinamico dei casi duso probabilmente rimane il buon vecchio template: semplice, veloce da realizzare e da far comprendere ai clienti, agevole da manutenere e cos via. Una volta realizzato il modello della use case view necessario procedere alla relativa fase di verifica che implica sostanzialmente due processi di test: verifica vera e propria e validazione. Il primo processo serve a confermare che la vista stata realizzata correttamente e in accordo alle specifiche raccolte. Obiettivo della validazione accertare che il sistema, cos come lo si progettato, sia effettivamente ci di cui il cliente e gli utenti finali hanno bisogno. Spesso la realizzazione della use case view avviene con un tipico approccio top down: si realizza un primo use case molto generale, poi si produce tutta una serie di diagrammi che aumentano il dettaglio delle singole funzioni e si prosegue fino a giungere a use case elementari. Sebbene ci sia possibile, non sempre auspicabile in quanto tende a provocare diversi e ben noti inconvenienti: si rischia di far somigliare gli use case allorganizzazione del codice, si pecca di mancata astrazione, si spreca tempo prezioso nel realizzare diagrammi molto dettagliati, e cos via. Un fattore che storicamente causa grossi inconvenienti nella produzione di sistemi software di qualit la difficolt di instaurare una piattaforma di conversazione tra il cliente e il personale tecnico. Per cercare di arginare questa lacuna, spesso si preferisce realizzare veri e propri prototipi usa e getta, da utilizzarsi unicamente allo scopo di migliorare il processo di analisi dei requisiti del cliente. Logica conseguenza di ci che lo use case viene realizzato in base al prototipo e alle osservazioni scaturite dai colloqui con il cliente. A fronte dei ben noti vantaggi (si riesce a condurre il cliente a ragionare su elementi concreti, a isolarsi da dettagli, a delineare proiezioni meno astratte del sistema finale, ecc.), gli svantaggi possono essere diversi; si rischia di ingenerare nel cliente lidea che il sistema sia ormai pressoch pronto, di legarsi troppo al prototipo e quindi di non analizzare aspetti ritenuti di secondaria importanza magari semplicemente perch non previsti dal prototipo realizzato in fasi ancora molto acerbe, di sottostimare i tempi, e cos via. Infine importante tener presente che i clienti, molto raramente si trovano a loro agio quando il discorso si eleva sul piano dellastratto e quindi probabilmente non opportu-

UML e ingegneria del software: dalla teoria alla pratica

83

ni realizzare casi duso a elevato grado di astrazione: si corre il rischio di dover impiegare non poco tempo in lunghi meeting nel tentativo di illustrare, spiegare e argomentare le varie astrazioni. Pertanto, astrarre i diagrammi pi di quanto sia effettivamente necessario potrebbe confondere inutilmente il cliente e, in ultima analisi, limitare o addirittura inibire, linstaurazione di un dialogo costruttivo. La parola dordine per gli use case sicuramente la concretezza: la mancanza di astrazione a questo livello non incide minimamente sul livello di astrazione delle restanti viste.

Capitolo

4
Uno dei peggiori sprechi di energie che si possa produrre realizzare un sistema, magari impeccabile dal punto di vista tecnico, che per semplicemente non quello di cui aveva bisogno lutente. Cliente: Vorrei un mezzo di trasporto in grado di teletrasportare persone da Roma a NY in 5 minuti. Architetto: OK, si pu fare Sono necessari 103 anni-uomo e 1020 dollari.

Modellazione avanzata degli Use Case

Introduzione
Nel capitolo precedente sono stati illustratati in dettaglio i diagrammi dei casi duso e in particolare si visto come siano lo strumento ideale per modellare la proiezione statica dei requisiti utente. Obiettivo del presente capitolo illustrarne un utilizzo pi operativo anche se, a volte, sensibilmente distante dalle direttive standard: ancora una volta il conflitto tra pratica e teoria. Modellare sistemi reali mette in luce una serie di problemi e lacune raramente trattati nei libri e nelle specifiche ufficiali dello UML. Nel presente capitolo viene riportato un esempio completo di modello dei casi duso di un sistema per il commercio elettronico. Logica conseguenza che il capitolo risulta decisamente corposo Il lato positivo che non assolutamente necessario studiare attentamente tutto lesempio. Il pregio che rende particolarmente attraenti gli use case probabilmente risiede nel formalismo amichevole e nella notazione grafica quasi banale: tutto viene rappresentato a meno di stereotipizzazioni attraverso omini stilizzati, ellissi e opportune relazioni.

Capitolo 4. Modellazione avanzata degli Use Case

Il problema che spesso tale pregio si tramuta in difetto. La relativa semplicit spinge tecnici a cimentarsi con la notazione dei casi duso senza possederne unadeguata conoscenza. Il risultato che si commettono svariati errori, ben noti. Esempio tipico un utilizzo procedurale: si utilizza il formalismo dei casi duso, ma con una metodologia riconducibile alla famosa analisi strutturata. In altre parole si d luogo a una decomposizione funzionale, si realizzano use case via via pi raffinati fino a giungere a dettagli implementativi: in sostanza le descrizioni dei singoli casi duso risultano essere delle vere e proprie procedure, i vari use case vengono connessi a catena: use case A include use case B, che include use case C e cos via. La principale anomalia generata da tale approccio distorto relativa al fatto che si disegna il sistema con un formalismo inadeguato in una fase in cui non si dispone di una sufficiente conoscenza del sistema. Il formalismo dei casi duso, sebbene possa sembrare molto semplice o addirittura banale, richiede un adeguato studio teorico e molta sperimentazione pratica, al fine di riuscire a realizzare modelli validi di use case. I diagrammi dei casi duso permettono di illustrare le singole funzionalit del sistema, conferendo particolare risalto alla percezione che ne ha lutente. Il problema per che talune volte si tenta di utilizzare strumenti per usi non propri; nel caso degli use case, diffusa lopinione che essi siano in grado di catturare ogni dettaglio della vista dei casi duso. Nulla di pi inesatto: infatti non possiedono alcuna caratteristica intrinseca che li renda in grado di rilevare il comportamento dinamico; inoltre necessario ricorrere a diversi artifici per tentare di evidenziare eventuali condizioni anomale; non possibile specificare le azioni da intraprendere per la relativa gestione, e cos via. Una prima soluzione a questi inconvenienti lutilizzo della tecnica dei flussi di azione, cos come prescritto dalle direttive dei Tres Amigos. Opinione comune in molti tecnici compreso lautore ovviamente che nelle pratica quotidiana anche questo formalismo non risulta sempre adeguato e privo di lacune; per esempio non vengono menzionate pre- e postcondizioni, probabilmente non viene conferita abbastanza enfasi agli attori coinvolti nel caso duso, non vengono specificate le garanzie, il tempo stimato per lesecuzione dello use case e cos via. Unulteriore alternativa potrebbe essere quella di ricorrere ad altri diagrammi messi a disposizione dallo UML per la modellazione del comportamento dinamico del sistema (diagrammi di sequenza, di attivit, ecc). In sostanza si potrebbero utilizzare questi diagrammi, selezionando di volta in volta quello in grado di evidenziare pi adeguatamente laspetto (il tempo, lorganizzazione il parallelismo, ecc.) ritenuto pi importante per la particolare interazione attore/sistema oggetto di studio. Dovendo descrivere il comportamento dinamico di casi duso, il livello di astrazione dei diagrammi realizzati dovrebbe essere necessariamente molto elevato ricordando che lobiettivo descrivere cosa il sistema dovr fare e non il come: bisogna impegnarsi a non guardare il sistema al suo interno.

UML e ingegneria del software: dalla teoria alla pratica

Lutilizzo dei diagrammi succitati per non solo non risolve tutte le lacune evidenziate per i flussi di azione, ma anzi aggiungerebbe altri inconvenienti, quali per esempio laumento significativo del tempo necessario per realizzare i diagrammi stessi, lestrema difficolt di manutenzione, ecc. Lesperienza quotidiana suggerisce che, molto spesso, lo strumento pi opportuno da utilizzarsi per dettagliare il comportamento dinamico dei casi duso rimane il buon vecchio template: semplice, veloce da realizzare e da far comprendere ai clienti, agevole da manutenere e cos via. Ai lettori lardua sentenza.

Template
In questa sezione viene presentato un primo esempio di template dimostratosi particolarmente efficace nella documentazione della proiezione dinamica degli use case. La versione illustrata frutto di una lunga genesi costituita da continui miglioramenti resisi necessari in corso duso, sia per saturare le lacune evidenziate dallutilizzo delle versioni precedenti, sia per includere suggerimenti ricavati dallo studio di vari testi (quali per esempio [BIB10]). Nel Capitolo 7 viene presentato un esempio di modello a oggetti del dominio atto a rappresentare formalmente l'organizzazione delle entit (classi) in grado di modellare la struttura del template. Pertanto, al termine dei paragrafi in cui esso presentato, l'esame di tale modello potrebbe contruibuire a chiarire le idee e a risolvere eventuali dubbi. In prima analisi, il modello (template) riportato in template 1 pu essere suddiviso in quattro macrosezioni: lintestazione, le informazioni generali, gli scenari (che a loro volta si dividono in: principali, alternativi e di errore) e la sezione per eventuali annotazioni. Nellintestazione necessario riportare un codice simbolico univoco da utilizzarsi per riferirsi al caso duso, una descrizione breve (il nome), la data dellultima modifica e la versione. Il codice si rivela particolarmente utile sia per evidenti questioni di catalogazione e facilit di reperimento, sia nellutilizzo di tool per la produzione di diagrammi UML: automatico associare al nome del diagramma il codice del caso duso. Durante le primissime fasi di studio dei requisiti utente e le relative stesure dei casi duso piuttosto normale che non si abbiano le idee completamente chiare, spesso anche per via di un certo smarrimento tipico di alcuni clienti in merito alle funzionalit che il caso duso dovr fornire, alle relative modalit, e quindi, in ultima analisi, ai suoi reali obiettivi. Spesso vi una certa difficolt iniziale nel definire i confini dei casi duso; ci non deve preoccupare pi di tanto in quanto di solito la versione definitiva di un use case il risultato di un certo numero di revisioni. Anche a sistema rilasciato, si pu assistere a devastanti variazioni dei casi duso: le temutissime change requests (cambiamenti delle specifiche).

Capitolo 4. Modellazione avanzata degli Use Case

Template 1 Esempio di template

CASO DUSO: Codice Descrizione: Priorit: Durata: Attore primario: Attori secondari: Precondizioni: Garanzie: Avvio: Scenario principale. 1. 2. 3. 4. 1.1. <STEP 1> <STEP 2> <STEP 3> <STEP 4>

Nome del caso duso.

Data: Versione: 0.00.000

Descrizione generale del caso duso (scope). Indica la priorit attribuita al caso duso. Ordine di grandezza stimata della durata del caso duso. Nome Interessi nellesecuzione del caso duso Nome Interessi nellesecuzione del caso duso Descrizione. Minime: descrizione. Successo: descrizione. Evento che innesca lavvio del caso duso.

Primo scenario alternativo. Elenco delle azioni da eseguire come alternativa a quanto prescritto nel primo passo. Elenco delle azi oni da eseguire come alternativa a quanto prescritto nel terzo passo. Elenco delle azioni da eseguire nel caso in cui si verifichi una condizione di errore durante lesecuzione del secondo passo. Annotazioni relative al punto 4 dello scenario principale.

Secondo scenario alternativo. 3.1.

Primo scenario di errore. 2.1.

Annotazioni. 4.

Nella pratica si evidenzia lesistenza di una certa proporzionalit tra il numero di versioni di un caso duso, le riunioni effettuate con i clienti e gli attori presenti presso la relativa organizzazione abilitati a esternare la propria opinione sul sistema. Al risultato andrebbe poi aggiunto qualche fattore correttivo da imputarsi ai commerciali presenti presso la propria societ.

UML e ingegneria del software: dalla teoria alla pratica

La convenzione generalmente accettata per lattribuzione del numero di versione a un caso duso quella di fatto utilizzata nella gestione delle diverse versioni del codice sorgente, che prevede un formato del tipo 0.00.000. La cifra pi significativa viene aggiornata solo nel caso in cui, tra una versione e quella successiva, si proceda alla completa riscrittura del caso duso. Le due cifre centrali si modificano a seguito di variazioni significative del comportamento del caso duso, come per esempio introduzione di passi aggiuntivi o eliminazione di altri presenti. Infine le ultime tre cifre si variano nel caso di correzioni (bugs fixing) e quindi per aggiornamenti di minor rilievo. Nella sezione dedicata alle informazioni generali necessario specificare una breve descrizione del caso duso, la priorit (il che equivale a dire limportanza), lordine di grandezza della durata dellesecuzione dello stesso, gli attori divisi tra principali e secondari, le precondizioni, le garanzie e la causa innescante (il trigger).

Per ci che concerne la descrizione necessario riportare una breve illustrazione dei servizi offerti dal caso duso oggetto di studio. Probabilmente non il caso di spendere molto tempo cercando di descrivere dettagliatamente lintero use case: poche righe di descrizione riportanti le attivit pi significative, eventualmente corredate dalle relative condizioni di fallimento, nella pratica, si dimostrano essere pi che sufficienti. La descrizione iniziale non la sede pi opportuna per dilungarsi: per la specifica di dettaglio prevista la sezione dedicata agli scenari.

La priorit permette di evidenziare limportanza assegnata alle funzionalit che il sistema dovr fornire, al fine sia di suddividere gli use case in unopportuna gerarchia di importanza, sia per poter assegnare in maniera pi opportuna i vari casi duso alle fasi di sviluppo.

Poich tipicamente il livello di importanza di una funzionalit proporzionale al relativo rischio, la priorit finisce per fornire un criterio molto importante per il delicato processo di pianificazione delle iterazioni. Da una parte si vuole cercare di affrontare il prima possibile le parti con fattore di richio pi elevato, ma dall'altra non e' opportuno concentrarle tutte in un'unica iterazione, in quanto si finirebbe per non avere pi un processo iterativo ed incrementale, bens un processo classico, caratterizzato da un rilascio molto importante e da qualche iterazione minore. Tipicamente le priorit vengono riportate in unapposita tabella in un foglio elettronico separato, in cui lidentificativo delle varie righe dovrebbe essere dato al codice del caso duso. La priorit dovrebbe essere

Capitolo 4. Modellazione avanzata degli Use Case assegnata dal business analyst, rispecchiando le direttive del cliente. buona prassi mediare tali priorit con un coefficiente a disposizione dellarchitetto, sia perch ha una visione tecnica del sistema e delle dipendenze tra le varie parti componenti, sia perch dovrebbe essere in grado di effettuare le attribuzioni tenendo conto delle direttive provenienti dal processo di sviluppo utilizzato.1

Come ormai dovrebbe essere arcinoto, un attore una qualsiasi entit, persona o sottosistema, interessato al comportamento del sistema in generale e di un insieme di use case in particolare. Tipicamente gli attori, nel contesto di uno stesso caso duso, vengono suddivisi in primari e secondari. Le peculiarit degli attori primari, molto brevemente, sono di fornire lo stimolo iniziale che avvia lesecuzione del caso duso, e di fruire del relativo servizio. Sono quindi interessati a ricevere i principali messaggi inviati dal sistema, ossia i risultati dellesecuzione del servizio. I servizi temporizzati costituiscono tipici casi duso non avviati esplicitamente da attori. Lavvio viene innescato automaticamente dal sistema stesso a un prestabilito istante di tempo. In tal caso, per rendere i casi duso pi chiari e comprensibili, si ricorre allartificio di considerare il tempo come un attore. In merito a questa soluzione si potrebbe aprire un dibattito: probabilmente, secondo le direttive standard dello UML il tempo non potrebbe essere considerato un vero e proprio attore; per, in casi particolari, questa soluzione permette di rendere diagrammi pi chiari e comprensibili.

Pertanto, in tali contesti, la personificazione del tempo come attore pi che legittima. Importante non esagerare iniziando a visualizzare come attore anche un servizio schedulatore che, evidentemente un processo interno al sistema. Considerando attori funzionalit interne del sistema (come per esempio

Qualora si utilizzasse un processo di sviluppo di tipo iterativo e incrementale sempre consigliato in quanto

permette di controllare i fattori di rischio del progetto necessario tener presente che ogni iterazione dovrebbe essere guidata da un gruppo ben definito di use case, o addirittura, da un insieme prestabilito di scenario. Per esempio non infrequente il caso in cui in una determinata iterazione, verosimilmente una di quelle iniziali, si sia interessati a realizzare unicamente il best scenario (scenario in cui tutto funziona bene: si trascura momentaneamente la gestione delle anomalie) di un certo numero di casi duso. Ci ha una sua logica: si interessati a mostrare al cliente, il prima possibile, una versione del sistema, o per ottenere preziosi riscontri o semplicemente per provare che larchitettura progettata efficace. Si capisce allora che il processo di assegnazione delle priorit degli use case unattivit molto importante e finisce per influenzare la pianificazione delle iterazioni che, a sua volta, unattivit molto sensibile in quanto ha a che fare con i rischi e il loro controllo.

UML e ingegneria del software: dalla teoria alla pratica uno schedulatore appunto), si commette errore in quanto non si analizzano opportunamente servizi che dovranno essere stimati, progettati, implementati ecc. Sempre nel caso dello scheduler, mostrandolo come attore, non si attribuirebbe sufficiente enfasi alle funzioni di prenotazione di eventi, alle eventuali condizioni di avvio, alla relativa comunicazione, cancellazione e cos via, che, viceversa sarebbe opportuno analizzare con un certo dettaglio.

Premesso ci, opportuno sottolineare che dal punto di vista della progettazione del sistema, ci che interessa non molto la ripartizione degli attori in primari o secondari (forse neanche tanto gli attori stessi) n tantomeno i nomi da attribuire ad essi (sebbene ci possa far risparmiare molto tempo nelle riunioni con i clienti), bens gli obiettivi che questi intendono raggiungere per mezzo dellesecuzione del caso duso: la funzionalit da dover realizzare. Chiaramente sempre conveniente scegliere nomi appropriati per le varie entit del sistema; in particolare, nel caso degli attori: i nomi permettono di sintetizzare descrizione del lavoro svolto, background e skill relativi, e cos via. Una volta prodotto un caso duso, non infrequente il caso in cui si scopra che magicamente la funzione descritta sia oggetto di interesse per una molteplicit di attori; si consideri per esempio il servizio di Ricarica account descritto in fig. 18. Ebbene questa dovrebbe essere eseguita dal commesso per ricaricare laccount del cliente, ma nulla vieta allamministratore di espletare lo stesso servizio. Le precondizioni sono i requisiti che devono essere soddisfatti per poter eseguire il caso duso al quale si riferiscono: compito del sistema verificarne ladempimento prima di avviare lesecuzione dellefferente caso duso, mentre responsabilit dellutilizzatore assicurarne il soddisfacimento. Lesempio di precondizione pi classico, quasi onnipresente nelle use case view, lottenimento da parte dellutente dellabilitazione del sistema per lesecuzione di funzioni considerate sensibili. La celebre frase cita letteralmente precondizione: lutente abbia eseguito il login e sia stato riconosciuto dal sistema. Il riscontro pratico delle precondizioni che limplementazione dellefferente caso duso preveda una serie di controlli iniziali atti a verificare appunto il relativo soddisfacimento. Si consideri ancora un qualsivoglia sito di e-commerce che offra ai propri utenti la possibilit di acquistare prodotti e/o servizi stando seduti comodamente nella ultracitata poltrona di casa. Si prenda in esame il caso duso in grado di effettuare un ordine che contempli prodotti precedentemente inseriti nel carrello della spesa. Le precondizioni per un caso duso del genere potrebbero essere che: 1. lutente abbia eseguito con successo il login e sia quindi stato riconosciuto dal sistema;

Capitolo 4. Modellazione avanzata degli Use Case

2. il carrello della spesa non sia vuoto.

Un errore che spesso capita di commettere confondere condizioni che solo in particolari casi devono essere esaudite, con le precondizioni che invece devono essere sempre soddisfatte.

Per ci che concerne le garanzie necessario citare esplicitamente sia quelle minime, sia quelle di successo. Le prime, come suggerisce il nome, sono le pi basilari assicurate dallesecuzione del caso duso. Tipicamente si tratta delle garanzie assicurate dal sistema nel caso in cui non sia possibile fornire il servizio specificato (scopo del caso duso non raggiunto) in quanto lesecuzione viziata da condizioni di errore o comunque da anomalie rispetto al flusso principale del caso duso (best scenario). In condizioni di fallimento nel conseguimento degli obiettivi del caso duso, le condizioni minime dovrebbero almeno prevedere il mantenimento di uno stato consistente: tipicamente quello immediatamente antecedente allavvio dello use case.

Non infrequente il caso in cui si compilino lunghe liste di condizioni minime. Un errore comune quello di specificare le condizioni minime per ogni possibile fallimento dellesecuzione del caso duso. Probabilmente non il caso di dilungarsi e di creare problemi di sincronizzazione tra la lista delle garanzie e le possibili anomalie che possono insorgere nellesecuzione di un caso duso: tutte le condizioni di eccezione hanno un insieme minimo comune di garanzie, pertanto sufficiente e opportuno riportare unicamente tale insieme minimo.

Spesso per semplificare il compito, invece di riportare le garanzie minime, si sostituisce la dicitura con garanzie in caso di fallimento: entrambe sono legittime e la scelta deve ricadere sullalternativa che fornisce un migliore grado di comprensione. Con riferimento al caso del sito di commercio elettronico, una garanzia minima dellesecuzione della funzione di compilazione degli ordini potrebbe essere: limporto dellordine viene addebitato solo a seguito di totale convalida dello stesso, mentre la relativa versione di garanzia in caso di fallimento potrebbe essere lordine non viene preso in carico e nessun importo viene addebitato al cliente. Specularmente a quelle minime, le garanzie di successo specificano ulteriori condizioni soddisfatte dal completamento dellesecuzione del relativo caso duso, ossia dopo lesecuzione dello scenario principale o al termine dellesecuzione di una sua variante comunque di successo (flussi alternativi).

UML e ingegneria del software: dalla teoria alla pratica

Mentre nel caso delle precondizioni compito dellutilizzatore del caso duso assicurarle, nel caso delle garanzie compito del sistema, qualora le prime siano soddisfatte, assicurarne il conseguimento. Come si pu notare ci permette di evidenziare e dividere nettamente le responsabilit tra le varie entit che partecipano a un caso duso (purtroppo non sempre possibile richiedere lo stesso a talune organizzazioni). Le garanzie di successo implicano il soddisfacimento di quelle minime con lintroduzione di ulteriori condizioni rese possibili dal raggiungimento di almeno uno degli obiettivi del caso duso.

Figura 1 Schematizzazione degli scenario di un caso duso.

Scenario principale

Scenario alternativo

Scenario alternativo

Scenario di errore

Scenario di errore

10

Capitolo 4. Modellazione avanzata degli Use Case

Nel caso della compilazione di un ordine di acquisto in un sito di commercio elettronico, le garanzie di successo potrebbero prevedere laccettazione e la presa in carico, da parte dellorganizzazione, dellordine effettuato con addebito del relativo importo allutente. Per ci che concerne il campo Avvio necessario descrivere levento che determina linizio dellesecuzione del sistema. Per esempio considerando il caso duso di interazione tra lutente e un sistema ATM (il nostrano Bancomat), lo use case viene avviato a seguito dellintroduzione da parte dellutente della relativa carta di credito. Prendendo in considerazione funzioni eseguite periodicamente dal sistema, lavvio generato dallo scadere di un determinato intervallo di tempo. Si consideri per esempio il sito per il commercio elettronico ed in particolare il caso duso che permette di inviare gli ordini effettuati dal cliente al legacy system dellorganizzazione. Nel caso in esame lavvio del caso duso avviene o a intervalli di tempo prestabiliti: ogni n ore, oppure a orari ben stabiliti: alle ore 13 e alle 24, e cos via. La sezione successiva del modello dedicato agli scenari. Tipicamente si distinguono tre tipologie (fig. 1): 1. scenario principale di successo (main success scenario): lo scenario che produce il servizio richiesto dallattore primario nel caso in cui tutto funzioni correttamente: dati di ingresso validi, nessuna eccezione scaturisce durante lo svolgimento, ecc.; 2. scenari alternativi (alternative scenario) si tratta di flussi di azioni che rappresentano diramazioni dello scenario principale la cui funzionalit per non sia la gestione di condizioni di errore. Si ancora in un flusso di successo, ma lesecuzione del servizio richiede un percorso diverso. In sostanza una forma pi elegante per evitare diramazioni nel flusso principale (il famoso costrutto if then else) che comunque restano legittime; 3. scenari di fallimento o di errore (failure scenario): gli scenari che specificano le azioni da intraprendere nel caso in cui nellesecuzione delle azioni dello scenario principale o alternativi sia impossibilitata dallinsorgere di condizioni di errore. Si tratta di illustrare il comportamento da eseguire in modo del tutto simile a quello utilizzato dai linguaggi di programmazione per specificare la gestione delle eccezioni. Da tener presente che ogni qualvolta in un passo dei flussi precedenti si menziona un verbo del tipo verifica, controlla, valida, ecc. verosimilmente esiste un flusso alternativo o di errore associato con la verifica negativa del test. Talune volte capita di non riuscire a distinguere chiaramente flussi alternativi da quelli di errore. Per esempio intervengono condizioni anomale che per possono essere gestite. Una regola semplice semplice a volte banale e inutile consiste nellinterrogarsi se il

UML e ingegneria del software: dalla teoria alla pratica

11

flusso oggetto del conteso generi o meno il fallimento dello use case. In caso di fallimento si tratta evidentemente di un flusso di errore, altrimenti di uno alternativo.

La descrizione dei flussi alternativi o di errore molto importante e permette di evidenziare delle dinamiche che invece tenderebbero a essere rilevate solamente durante la fase di test. Qualora alcuni comportamenti non siano ben specificati o mancanti, tendenza naturale di molti programmatori assumere comportamenti pi consoni alle proprie esigenze di implementazione, di tempo, ecc.

La struttura utilizzata nel template oggetto di studio prevede di specificare inizialmente la sequenza di azioni da compiere nel caso in cui tutto funzioni correttamente, dallavvio del caso duso al relativo compimento, per poi fornire le condizioni anomale che possono intervenire e le azioni da intraprendere. Vi una stretta similitudine con la pratica quotidiana quando necessario illustrare a unaltra persona un qualche sistema o una disposizione: si inizia fornendo le istruzioni sulla sequenza corretta e poi si spiega come gestire eventuali casi eccezionali che potrebbero intervenire: necessario fare questo, quello e quellaltro ma, nel caso in cui si verifichi questaltro ancora, allora necessario comportarsi in tale maniera ecc.. Spesso, piuttosto che nominare i flussi alternativi e di errore con numeri ordinali indicanti la sequenza temporale di apparizione, si preferisce attribuire una descrizione che precisi la condizione che ne genera lesecuzione. Chiaramente ci non avrebbe alcun senso per ci che concerne il flusso principale (il nome sarebbe sempre lo stesso!). Il vantaggio offerto da tale tecnica legato alla maggiore comprensibilit della descrizione del caso duso, alla minimizzazione del lavoro richiesto da eventuali aggiornamenti (per esempio, dovendo inserire un nuovo flusso o eliminarne un altro non sarebbe necessario numerare nuovamente i successivi), e allutilizzo pi proficuo di strumenti da utilizzarsi per la catalogazione e gestione dei requisiti (lelenco dei flussi mostrerebbe una descrizione autoesplicativa piuttosto che un anonimo numero). Tale approccio stato utilizzato nellesempio relativo al sito per il commercio elettronico. Nella stesura degli scenari probabilmente pu risultare utile strutturarli come una successione di azioni o transazioni limitate. Molto importante evidenziare chiaramente quale entit (attore, sistema) svolge ciascuna azione. Molto spesso si utilizzano particolari versioni di template nei quali la sezione dedicata agli scenari viene suddivisa orizzontalmente in un numero di colonne equivalenti alle entit che prendono parte al caso duso. Ci permette di riportare in ciascuna colonna unicamente le azioni eseguite dallentit di appartenenza. Nella definizione di un caso duso, oltre a quello principale necessario riportare tutta la sequenza di casi di errore o comportamento anomalo che potrebbero verificarsi con le

12

Capitolo 4. Modellazione avanzata degli Use Case

relative azioni da compiere. Esistono diverse modalit per specificare gli scenari di fallimento. La pi classica quella che utilizza uno stile del tutto simile al codice scritto con linguaggi di programmazione che non supportano la gestione delle eccezioni (C like): dopo ogni azione che pu causare un errore viene eseguito un test esplicito e quindi vengono dettagliate le azioni da compiere nel relativo blocco. Pertanto il tutto viene specificato nella stessa sequenza. Una tecnica alternativa prevede invece di utilizzare uno stile simile alla stesura del codice utilizzando il meccanismo delle eccezioni: nelle apposite sezioni vengono riportate le eccezioni che si intende gestire e le relative operazioni da compiere. Pertanto per ogni azione che pu generare anomalie sono presenti tante sezioni alternative, una per ciascuna tipologia di anomalia, riportanti sia la dichiarazione dellanomalia stessa sia le azioni da compiere. Questa organizzazione particolarmente utile anche per lattivit di pianificazione del processo di sviluppo del software: le varie versioni (build) possono essere schedulate considerando solo specifici flussi di determinati casi duso, rimandando a iterazioni future quelli tralasciati. Lillustrazione degli scenari alternativi effettuata attraverso opportuni template evidenzia il grande vantaggio offerto da questo formalismo rispetto a quello grafico ove, tipicamente, necessario disegnare un nuovo diagramma per ogni alternativa, il che richiede una quantit decisamente superiore di tempo per la realizzazione e rende difficoltosa la gestione delle relative modifiche. Lultima sezione, del tutto opzionale, prevede di riportare eventuali annotazioni, che possono essere riferite sia allintero use case, sia a singole azioni. Qualora si decida di ricorrere ai template, c da tener presente che molte persone ritengono tali modelli complicati, fuorvianti perch distolgono lattenzione dai contenuti e cos via. Probabilmente le stesse persone, dopo aver utilizzato un programma di video scrittura, lascerebbero tracce di bianchetto sullo schermo. Il vantaggio dei template quello di conferire una migliore organizzazione alle informazioni, renderne pi facile il reperimento, infondere maggiore coerenza alla descrizione dei casi duso ecc. Qualora, per le idiosincrasie dovessero rimanere, si consiglia di stampare le varie descrizioni senza i bordi tipici delle tabelle. Invece, per i nostalgici delle schede perforate, i bordi vanno benissimo Anzi, magari si potesse fare a meno anche dei grafici.

Flussi alternativi e sottoflussi (subflow)


Uno dei problemi storicamente pi critici insito nei processi di sviluppo di sistemi informatici consiste nella adeguata comprensione delle esatte necessit dellutente. Lavvento del formalismo dei casi duso, la cui escogitazione si deve prevalentemente al lavoro portato avanti da Ivar Jacobson (lo svedese dei Tres Amigos) tra la fine degli anni Ottanta e gli inizi degli anni Novanta, sembrerebbe aver contribuito in modo decisivo a risolvere il problema, sebbene il formalismo da solo non basti.

UML e ingegneria del software: dalla teoria alla pratica

13

Lesperienza dellautore mostra che, bench la notazione dei casi duso sia piuttosto diretta e relativamente semplice, molte organizzazioni considerano il ricorso ai casi duso molto complicato, oneroso e difficile da capire e gestire. Dove risieder mai il problema? La vocina interna suggerirebbe di cercare in diverse direzioni. La scarsa voglia di un aggiornamento non superficiale, ma anche il mettere tutto nero su bianco e la relativa necessit di chiarezza implica responsabilit che ben pochi si vogliono assumere; e cosa dire di coloro che fanno roccaforte dei quattro concetti da loro conosciuti? In ogni modo, la definizione iniziale del formalismo prevedeva quasi esclusivamente la notazione grafica, che, tra laltro, contemplava un insieme piuttosto limitato di elementi per strutturare i casi duso. Ben presto per si cap che queste ellissi, troppo vuote, erano eccessivamente leggere per specificare le funzionalit che il sistema doveva prevedere: il solo nome non aiutava granch. Nella definizione iniziale del formalismo dei casi duso, dunque, il ruolo del comportamento dinamico era ridotto quasi al minimo, affidato a un testo generico. Attualmente, grazie anche ai template provvisti dal processo della Rational, si assiste al problema diametralmente opposto (fig. 2). In molte organizzazioni si tende a ridurre ecFigura 2 Il diagramma mostra una verosimile evoluzione dellutilizzo tipico del formalismo dei casi duso, nellarco del decennio (inizi degli anni Novanta a oggi), nelle organizzazioni informatiche.

Organizzazione diagramma

Prima introduzione del formalismo

Tendenza non infrequente

Descrizione del comportamento

14

Capitolo 4. Modellazione avanzata degli Use Case

cessivamente la strutturazione del diagramma dei casi duso a favore della descrizione del relativo comportamento dinamico. Vi un attore che interagisce con un caso duso in maniera piuttosto lineare, salvo per poi accedere alla descrizione dello stesso e trovarsi di fronte a decine di pagine di specifiche, in cui compaiono flussi alternativi, sottoflussi, e cos via. A questo punto ci si interroga sulla necessit di disegnare il diagramma che perde completamente, o quasi, il suo valore. Da tener presente che la definizione di flussi alternativi, sottoflussi, ecc., allinterno della descrizione di un singolo caso duso non perfettamente in linea con le direttive standard dello UML. I flussi alternativi, se non utilizzati per mostrare in maniera pi elegante un costrutto if then else , e quindi se eccedenti le 3-4 righe, dovrebbero essere evidenziati per mezzo di un ulteriore caso duso associato a quello di partenza tramite una relazione di extend. Per ci che riguarda i sottoflussi, essi rappresentano veri e propri use case da associarsi a quello oggetto di studio per mezzo della relazione di include. A questo punto, le domande che potrebbero sorgere sono essenzialmente due: 1. perch potrebbe risultare importante non inglobare pi casi duso in uno solo? 2. perch invece spesso si preferisce procedere con tale approccio? Per ci che concerne il secondo interrogativo, la risposta potrebbe essere legata alla necessit di contenere il numero dei casi duso e la complessit dei relativi diagrammi. Uno dei principali motivi per cui importante modellare risiede nella necessit di sostenere la comunicazione. Si tratta di un problema molto rilevante specie nelle fasi iniziali del ciclo di vita del software, ove gli interlocutori sono gli utenti, i quali, tipicamente, dispongono di un background profondamente diverso da quello dei tecnici.

Contenere la complessit dei diagrammi, pertanto, aiuta il processo di comunicazione. Da tenere presente che, sebbene il formalismo dei casi duso sia piuttosto accattivante, comunque avvertito come estraneo dagli utenti.

Inoltre, disporre di una fitta rete di use case potrebbe generare non pochi problemi al processo mentale di ricostruzione della dinamica del servizio descritto: bisognerebbe interrompere pi volte la lettura della descrizione di un caso duso per saltare a quella di un altro e cos via. Infine, molto spesso gli utenti, che per definizione devono riesaminare i modelli dei casi duso, sono intimoriti da elevate quantit degli stessi.

UML e ingegneria del software: dalla teoria alla pratica

15

Tale abnorme proliferazione per, spesso dovuta ad alcuni modellatori di casi duso, i quali dimenticandosi che questo formalismo non appartiene alla fase di analisi e disegno del sistema, danno luogo a vere e proprie attivit di progettazione della struttura interna del sistema attraverso i casi duso. Comprese le ragioni per le quali alcune volte si tenta di inglobare la descrizione dei casi duso in uno solo, vediamo ora di capire perch ci non sia auspicabile, rispondendo quindi alla prima domanda. In primo luogo si rischia di attenuare limportanza della dichiarazione di pre- e postconditions. Dovendo soddisfare un gruppo di casi duso, queste dovrebbero necessariamente subire un processo di estrapolazione del massimo comune divisore: ossia si correrebbe il rischio di evidenziare solo pre- e postcondizioni condivise da tutti i casi duso, rinunciando al necessario dettaglio. Qualora, invece si decidesse di specificarle tutte le pre- e postcondizioni attraverso apposita lista, si correrebbe il rischio di generare confusione circa lassociazione di ciascuna di esse al relativo use case di appartenenza. Ci rappresenterebbe un problema specie per le precondizioni che in ultima analisi costituiscono dei controlli da dover effettuare allavvio del relativo servizio. Se invece si decidesse di ripetere la sezione di pre- e post-conditions per la descrizione di ciascun caso duso, verrebbe meno la necessit di raggrupparli in un unico documento/ modello. Inglobare descrizioni di casi duso, inoltre, non ne semplifica il riutilizzo e tantomeno permette di evidenziare importanti sezioni di comportamento condiviso. Doug Rosenberg e Kendall Scott autori dei testi Applied Use Case-Driven Object Modeling (Addison-Wesley, 2001) e Use Case-Driven Object Modeling with UML (AddisonWesley, 2001) asseriscono che bisogna preoccuparsi qualora le descrizioni dei casi duso siano lunghe quattro pagine. Lo scenario principale dovrebbe essere lungo due-tre paragrafi al massimo. Ogni flusso alternativo dovrebbe essere di una-due frasi. Qualche volta pu capitare di avere casi duso molto brevi, specie quando sono utilizzati come tessuto di collegamento, altre volte potrebbe esserci bisogno di use case di maggiori dimensioni. Ma necessario utilizzare tecniche [] atte a raggruppare a fattore comune il comportamento condiviso per scrivere use case pi concisi che meglio si prestano al riutilizzo. Ancora, la priorit assegnata potrebbe non essere chiaramente scindibile tra i vari casi duso specificati allinterno di una stessa descrizione del comportamento dinamico, con conseguenze sul processo di decisione dei casi duso/scenari da incorporare in ciascuna iterazione. Per finire, inglobare i casi duso pu complicare sia le attivit di realizzazione dei test case, sia la pianificazione del processo (stima della complessit, delle risorse da allocare, ecc.) e cos via. A questo punto cosa fare? Probabilmente la soluzione migliore consiste nel tentare di trovare il giusto mezzo, sebbene lautore sia un sostenitore della antiglobalizzazione dei casi duso, come si avr ben modo di costatare successivamente.

16

Capitolo 4. Modellazione avanzata degli Use Case

Sezioni aggiuntive
Analizzando modelli, relativi alla descrizione del comportamento dinamico dei casi duso, presenti in varie organizzazioni informatiche, possibile imbattersi in versioni con un numero di sezioni supplementari non sempre indispensabili. In questi casi, linutile e noioso lavoro aggiuntivo rende possibile intuire le ragioni dei tecnici che tendono a rinnegare i processi accademici di sviluppo del software.

Una delle sezioni a cui possibile rinunciare senza troppo sacrificio quella dedicata alla descrizione delle relazioni che coinvolgono il caso duso oggetto di specifica. Non solo si tratta di un gruppo di informazioni poco proficue (quindi trattasi di meri dati): sufficiente ispezionare visivamente il diagramma dei casi duso per evincerle. Esse tendono anche a generare lavoro extra gratuito: ogni qualvolta si aggiornano delle relazioni nel diagramma (per esempio si decide che una determinata relazione sia pi conveniente visualizzarla per mezzo di un extend anzich di un include) necessario rivedere le varie descrizioni del comportamento dinamico dei casi duso.

Un gruppo di informazioni che invece pu valere la pena di riportare quello relativo ai cosiddetti requisiti speciali (special requirements). Si tratta di descrizioni testuali che raggruppano linsieme di requisiti non funzionali che influenzano limplementazione dello use case oggetto di specifica. Da tener presente che per questi dati tipicamente previsto un opportuno manufatto, documento e/o foglio elettronico, denominato NFR (Non Functional Requirements, requisiti non funzionali).

Riportare gli NFR nel dettaglio degli use case soggetti a tali vincoli pu risultare molto comodo, ma solo se il repository rimane il relativo documento e negli use case c un link alla sezione desiderata. Ci al fine di minimizzare le ripercussioni dovute a variazioni dei requisiti non funzionali (individuare tutti gli use case in cui sono riportati tali requisiti, aggiornarli, ecc.).

Esempi tipici possono essere relativi allarea: sicurezza: la parola chiave deve avere una dimensione superiore ai 6 caratteri e contenere caratteri speciali; la password non deve appartenere allinsieme delle ultime 4 utilizzate;

UML e ingegneria del software: dalla teoria alla pratica

17

lalgoritmo di criptazione prevede chiavi asimmetriche di lunghezza 128 bit; performance: lutente non deve attendere pi di x secondi per lespletamento del servizio; in condizioni di regime il sistema deve essere in grado di supportare la connessione di y utenti contemporanei;

Un semplice processo per produrre la descrizione dei casi duso


Di seguito illustriamo un processo essenziale, frutto dellesperienza personale dellautore, in grado di agevolare la produzione di appropriate descrizioni del comportamento dei casi duso. In effetti, unattivit spesso non banale e, verosimilmente, non del tutto corretto asserire che si tratti di una mera attivit di descrizione (altrimenti sarebbero necessari tecnici dotati unicamente di skill linguistico, magari scrittori), bens necessario eseguire un vero e proprio processo di investigazione e scoperta dei requisiti utenti. Il processo, sinteticamente, si articola sui seguenti passi: 1. definizione del goal; 2. definizione delle precondizioni; 3. produzione del dettaglio dello scenario principale; 4. specificazione degli scenari alternativi; 5. inclusione delle rimanenti informazioni. In primo luogo consigliabile definire chiaramente quale sia lo scopo dei casi duso che si vuole descrivere, ossia le post-conditions (alcuni esempi sono: autorizzare lutente ad accedere al sistema, validare il carrello della spesa, eseguire un ordine, ecc.). Qualora anche questa attivit dovesse presentare incertezze, sarebbe il primo campanello dallarme che qualcosa sia stato definito in modo non accurato. Dichiarati gli obiettivi dei caso duso importante iniziare a definire le precondizioni: importante in quanto si tratta di requisiti che devono essere soddisfatti da tutti i flussi. Qualora, nel procedimento di individuazione e descrizione di flussi alternativi ci si dovesse accorgere che ci non vero, ci si troverebbe di fronte a due eventualit: 1. le precondizioni non sono state definite con molta precisione, e quindi sufficiente correggerle;

18

Capitolo 4. Modellazione avanzata degli Use Case

2. i flussi rappresentano effettivamente casi duso diversi e quindi necessario procedere con unattivit di ristrutturazione dellorganizzazione degli use case. Il passo successivo consiste nel dettagliare lo scenario principale. In sostanza si definisce come giungere allobiettivo sancito dal caso duso nellipotesi in cui tutto funzioni meravigliosamente bene. Per questo motivo, spesso, ci si riferisce allo scenario principale con la definizione di happy days scenario (scenario dei giorni felici). Per esempio nello use case di login, nello scenario principale si potrebbe assumere che il profilo dellutente esista gi, la password inserita concordi con quella definita nel profilo, e cos via. Qualora la descrizione dello use case sia troppo prolissa o, viceversa, eccessivamente breve, potrebbe essere opportuno verificare se sia possibile scomporre ulteriormente il caso duso (prima evenienza) estraendo comportamento comune o ripetitivo o, (seconda evenienza) se sia possibile inglobare lo stesso in altri casi duso, tenendo conto anche di quanto sancito precedentemente. In molti processi di sviluppo del software, si preferisce utilizzare un approccio iterativo e incrementale anche nella costruzione del modello dei casi duso. Invece di definire completamente ogni singolo caso duso prima di passare al successivo, si preferisce realizzare una certa percentuale di ciascuno di essi (magari solo lo scenario principale) al fine di produrre rapidamente una prima versione da rivedere con gli utenti. Approcci di questo tipo sono particolarmente utili qualora il sistema da realizzare preveda un numero non trascurabile di casi duso.

Definito lo scenario principale, altra attivit importante consiste nellindividuare i flussi alternativi o di errore. Si tenga in mente che la presenza di questi flussi del tutto normale, mentre la loro assenza potrebbe essere imputabile alla mancata individuazione di percorsi possibili.

Qualora esistano diversi flussi alternativi (flussi comunque in grado di conseguire lobiettivo dichiarato) dovrebbe risultare abbastanza intuitivo utilizzare quello pi frequente come flusso principale Il condizionale dobbligo perch capita comunque di imbattersi in situazioni opposte.

Ogniqualvolta nel flusso principale siano presenti frasi del tipo il sistema verifica, controlla, valida, si accerta, ecc. la presenza di flussi alternativi diventa obbligatoria. Spesso si commette lerrore di non evidenziare questi verbi. Per esempio invece di affermare il sistema tenta di reperire il profilo utente, si asserisce il sistema reperisce il profilo utente. Frasi s congegnate tendono a

UML e ingegneria del software: dalla teoria alla pratica rendere pi difficile lindividuazione di flussi alternativi e/o di errore. In generale, un buon criterio per individuare i flussi alternativi consiste nello scorrere il flusso principale, punto per punto, e nellinterrogarsi se, per ciascuno di essi sia possibile che qualcosa non funzioni come ci si aspetti, che il sistema si comporti diversamente, che lattore agisca in modo diverso da quanto sancito e cos via.

19

Definiti anche i flussi alternativi e di errore, le rimanenti attivit sono completamente volte allindividuazione delle restanti informazioni che, a questo punto, non dovrebbero pi creare eccessivi problemi.

Esempio: Internet University Booking System


In questa sezione viene fornito un esempio relativo a una parte di un sistema universitario atto a fornire a studenti e docenti universitari una serie di servizi fruibili attraverso un comune browser Internet. Obiettivo del progetto realizzare sia un sito Internet/Intranet dinamico e interattivo, sia uno strato di comunicazione (wrapper) tra il sito stesso e il sistema gestionale delluniversit (unistanza di legacy system). In questo paragrafo, lattenzione viene focalizzata sul sito Internet e in particolare sulla funzione di prenotazione sessioni di esami. Gli utenti (studenti universitari) collegati al sito universitario, dopo essere stati opportunamente riconosciuti dal sistema (attraverso la

Figura 3 Use case prenotazione Internet sessioni desame.

Prenota appello

Studente Universitario

extend [funzione abilitata]

include

Selezione posizione scaletta di accettazione

Verifica propedeudicita'
extend [previsto vincolo di singola prenotazione per appello]

Verifica singola prenotazione per sessione

20

Capitolo 4. Modellazione avanzata degli Use Case

classica coppia login + password), possono consultare le varie sessioni di appello previste per gli esami appartenenti alla propria facolt, ed eventualmente possono prenotarsi. Si inizi con il considerare lo use case diagram riportato nella fig. 3. che illustra graficamente la proiezione statica del caso duso per la prenotazione Internet degli esami universitari. Dalla relativa analisi possibile evincere lunico attore, chiaramente principale, (lo Studente Universitario), e le principali funzioni e la relativa organizzazione strutturale.

Si ricordi che probabilmente non il caso di perdere troppo tempo nel realizzare diagrammi dei casi duso eccessivamente dettagliati. Leccessivo dettaglio oltre a incidere negativamente sul tempo necessario per produrre la versione iniziale del diagramma, ne complica inutilmente la manutenzione e genera tutta una serie di effetti indesiderati, come il tentativo di definire larchitettura del sistema con strumenti sbagliati, vincolare improduttivamente le restanti fasi del processo e cos via.

I diagrammi dei casi duso sono assolutamente soggettivi: la struttura evidenzia le sottofunzioni ritenute pi significative dal progettista in funzione di quelle che sono le esigenze del cliente. Pu capitare per esempio che un cliente pretenda di vedere visualizzato uno specifico use case, anche se dal punto di vista tecnico risulta assolutamente insignificante e non coerente Come al solito bisogna mettere il padrone dove vuole lasino (spesso molto pi razionale del contrario). Molto probabilmente, se si fornissero esattamente le stesse specifiche a dieci tecnici diversi, si otterrebbero altrettante diverse legittime versioni. Tuttavia, verosimilmente, sarebbe possibile evidenziarne alcune, per cos dire, pi corrette o almeno pi convenienti di altre. Per esempio nello use case Prenota Appello visualizzato nella fig. 3 si deciso di evidenziare le funzioni di Verifica propedeuticit, Selezione posizione scaletta di prenotazione e Verifica singola prenotazione per sessione. In altre parole si deciso di evidenziare che lo studente per potersi prenotare a una determinata sessione di appello deve aver superato gli eventuali esami propedeutici a quello a cui si vuole iscrivere e, nei limiti legati alla disponibilit, pu selezionare la posizione desiderata nella scaletta di accettazione. altres possibile evincere che per talune sessioni di esame, a discrezione dellinsegnante, possibile iscriversi a uno solo degli appelli previsti nella relativa sessione (per esempio quando ne sono previsti diversi a scadenze piuttosto ravvicinate). Un servizio cos concepito correrebbe il rischio di essere eccessivamente rigido e particolarmente odiato dagli studenti. Una soluzione conveniente potrebbe consistere nel dare

UML e ingegneria del software: dalla teoria alla pratica

21

Figura 4 Use case eccessivamente dettagliato per la prenotazione automatica sessioni desame.

Verifica posizione amministrativa studente

Selezione materia d'esame

include

include

Prenota appello
Studente Universitario

include

Verifica propedeuticita'
include include include

Reperimento propedeuticita'

Selezione posizione scaletta di accettazione

Selezione sessione d'appello

Selezione posizione specifica

Selezione posizione in coda

la possibilit agli studenti di effettuare prenotazioni con riserva. Questa tipologia verrebbe selezionata automaticamente dal sistema nel caso in cui la posizione amministrativa dello studente e/o la verifica delle propedeuticit non risultassero completamente in regola. Nel diagramma in fig. 4 viene illustrata la stessa funzionalit ma attraverso un diagramma dei casi duso decisamente pi dettagliato. Sebbene esso sia a tutti gli effetti corretto comprensibile che il relativo livello di dettaglio sia eccessivo. Per il proseguimento della trattazione si faccia riferimento al diagramma di fig. 3. A questo punto, definita la proiezione statica dello use case prenotazione Internet sessioni di esami necessario passare allo studio del comportamento dinamico. Una prima alternativa potrebbe essere quella di utilizzare i diagrammi dello UML preposti per lo studio/documentazione degli aspetti dinamici del sistema. Ovviamente il livello di astrazione dovrebbe essere elevato al fine di risultare compatibile con i principali fruitori: gli utenti. Anche se i diagrammi mostrati di seguito non sono stati ancora oggetto di una presentazione organica, il relativo utilizzo, almeno in questa fase, cos intuitivo da non richiedere spiegazioni di dettaglio.

22

Capitolo 4. Modellazione avanzata degli Use Case

In particolare in fig. 5 presentato un diagramma di sequenza (sequence diagram) che illustra un ipotetico scenario di successo per la funzione di prenotazione esami.

Figura 5 Esempio di sequence diagram relativo unicamente allo scenario di successo della funzione di prenotazione esame.
:Interfaccia database server

:Sistema :Studente Universitario


1. Esegue funzione

2. Ottiene dati sessione studente

3. Richiede dati studente (dettaglio) 4. Reperisce dati studente 5. Verifica posizione amministrativa studente

6. Richiede elenco esami 7. Reperisce elenco esami 8. Visualizza pagina "elenco esami" 9. Seleziona esame 10. Richiede propedeuticita' esame 11. Reperisce prop. esame 12. Richiede esami superati dallo studente 13. Reperisce esami superati dallo studente 14. Verifica rispetto propedeuticita'

15. Richiede dati sessioni d'appello 16. Reperisce sessioni d'appello 17. Visualizza sessioni previste 18. Seleziona sessione 19. Richiede dati appelli 21. Visualizza elenco appelli 20. Reperisce appelli

22. Seleziona appello

23. Richiede lista di accettazione 24. Reperisce lista di accettazione 25. Verifica rispetto singola prenotazione per appello

26. Visualizza ordine di accettazione

27. Seleziona posizione nella lista 28. Richiede memorizzazione prenotazione 29. Esegue prenotazione 30. Comunica esito prenotazione

UML e ingegneria del software: dalla teoria alla pratica

23

Molto brevemente, nella prima riga vengono riportati gli oggetti che partecipano alla realizzazione della funzione, lasse verticale illustra il trascorrere del tempo e le varie frecce illustrano lo scambio di messaggi tra i vari oggetti. Il vantaggio offerto dai sequence, e dai diagrammi in generale, lessere particolarmente accattivanti grazie al formalismo grafico che ne facilita notevolmente comprensione e memorizzazione. Per, ahim a fronte di questo vantaggio esiste una serie di svantaggi che probabilmente ne sconsigliano lutilizzo a favore di strumenti pi pragmatici. In primo luogo necessario pi tempo per produrli e il loro processo di manutenzione piuttosto oneroso. Il diagramma presentato in figura illustra unicamente lo scenario di successo; oltre ad esso sarebbe necessario produrne diversi per illustrarne gli scenari alternativi. Volendo sarebbe anche possibile specificare i vari flussi alternativi nello stesso diagramma: sebbene ci da un lato limiterebbe il numero di diversi diagrammi da dover realizzare, dallaltro renderebbe il diagramma decisamente pi complicato e quindi pi difficilmente interpretabile. Questo approccio consigliabile qualora sia presente un numero limitato di flussi alternativi; eventualit che per non corrisponde al caso in questione. Tipicamente si preferisce realizzare lo scenario di successo e tanti altri diagrammi quanti sono gli scenari alternativi. In questo caso si capisce bene che una modifica allo scenario principale potrebbe ripercuotersi in tutti i rimanenti diagrammi. Un altro inconveniente legato al fatto che tali diagrammi mostrano il comportamento dinamico di oggetti del sistema, quindi, anche se molto ma molto superficialmente, necessario dare una prima sbirciata allinterno dello stesso. Probabilmente linconveniente principale rimane limpossibilit di specificare ulteriori informazioni molto importanti quali precondizioni, garanzie, durata, ecc. Ovviamente nulla vieta di inserirle come note aggiuntive, nonostante il risultato sarebbe comunque meno formale e meno standardizzato e quindi completamente demandato alla buona volont dei singoli tecnici. Per via di questi inconvenienti, nella pratica si preferisce illustrare il comportamento dinamico dei casi duso attraverso strumenti pi vicini al testo. Come gi menzionato si potrebbe ricorrere al flusso di azioni cos come da direttive standard UML, sebbene per sia pi agevole e frequente lutilizzo di opportuni template. Lanalisi del sequence diagram in fig. 5 potrebbe originare nei lettori pi attenti unobiezione degna di rilievo: se il sistema interagisce con un server, questultimo allora dovrebbe essere un attore nel caso duso in questione. In uno scenario logico la risposta sicuramente affermativa. Chiaramente nessuno vorrebbe replicare i dati di ciascun studente in pi sistemi bench, tipicamente, i clienti risultino abbastanza restii nel concedere laccesso diretto ai propri database. Sistemi del genere, progettati accortamente (!?), dovrebbero presentare diverse soluzioni di accesso (server socket, CORBA, EJB, COM+, ecc.). In casi sempre frequenti di progettazione non completamente lungimirante pu capitare di dover interagire con sistemi legacy

24

Capitolo 4. Modellazione avanzata degli Use Case

(per esempio attraverso emulatore 3270) simulando la modalit delloperatore (screen scrapling): si sottopone un opportuno comando al sistema, si attende la schermata di risposta, la si analizza e, se i dati forniti sono completi, si termina la transazione, altrimenti si prosegue con il successivo comando, si rianalizza la schermata di risposta e cos via. Nel caso in questione invece si suppone di avere un database ridondante a disposizione del solo sistema Internet non assolutamente un caso improbabile e quindi essendo parte integrante del sistema, il povero DB server non ha dignit di assurgere al ruolo di attore. Nella fig. 6 riportato un esempio di activity diagram utilizzato per descrivere la funzione prenotazione esami. Si tenga presente che nella fase del processo di sviluppo relativa alla cattura dei requisiti utente spesso si assiste a una sorta di guerra tra gli utenti e il team tecnico e quindi tutti i mezzi che permettono di instaurare una valida piattaforma di dialogo sono benvenuti. Nella pratica come sar dettagliato nel capitolo successivo molto spesso si rivela provvidenziale utilizzare i diagrammi delle attivit per descrivere il comportamento dinamico dei casi duso per tutta una serie di motivi, tra i quali 1. trattandosi di un formalismo grafico ne condivide i vantaggi: la mente umana tende a comprendere e memorizzare una maggiore percentuale del contenuto informativo laddove presentato attraverso opportuno formalismo grafico; 2. visualizza in maniera inequivocabile la suddivisione di responsabilit tra le varie entit e le operazioni che eventualmente possono essere compiute in parallelo; 3. nelle fasi di cattura dei requisiti li si utilizza con un livello di astrazione molto elevato che ne evidenzia le affinit con il progenitore flowchart e anche il cliente pi ignorante informaticamente parlando of course ha familiarit con tale notazione: chi non ha mai realizzato un flowchart in vita sua? A fronte dei succitati vantaggi, rimangono le condizioni sfavorevoli comuni alle varie notazioni grafiche 1. allaumentare della complessit, i diagrammi tendono a diventare inevitabilmente confusi, nonostante il grande dispendio di tempo ed energia profuso dai realizzatori nel vano tentativo di rendere il tutto pi lineare possibile; 2. problemi pratici di visualizzazione che vanno tenuti presenti: diagrammi di dimensioni medio-grandi sono difficili da stampare (spesso richiedono modelli A3 non facilmente reperibili);

UML e ingegneria del software: dalla teoria alla pratica

25

Figura 6 Esempio di activity diagram della funzione di prenotazione esame.

Studente
esegue servizio prenotazione appelli

Sistema

ottiene id. studente reperisce dati di dettaglio dello studente verifica posizione amministrativa
[posizione amministrativa irregolare] [posizione amministrativa regolare]

memorizza anomalia

reperisce elenco esami visualizza elenco esami seleziona esame valuta selezione
[termina funzione] [selezionato esame]

reperisce propedeuticita' esame


[lista propedeuticita' vuota] [lista propedeuticita' non vuota]

reperisce esami sostenuti dallo studente verifica rispetto propedeuticita'


[propedeuticita' non rispettate] [propedeuticita' rispettate]

memorizza anomalia

reperisce sessioni d'appello


[sessioni di appello non reperite] [sessioni di appello reperite]

visualizza messaggio di errore

visualizza sessioni d'appello seleziona sessione d'appello valuta selezione


[nessuna sessione selezionata] [sessione desiderata selezionata]

reperisce appelli visualizza appelli seleziona sessione d'appello valuta selezione


[nessuna sessione selezionata] [sessione desiderata selezionata]

verifica vincolo singola prenotazione


[(vincolo singola prenotazione presente) & (prenotazione dell'appello selezionato gia' effettuata)]

visualizza messaggio di errore reperisce elenco prenotazioni visualizza elenco prenotazioni seleziona posizione lista prenotazione valuta selezione
[nessuna posizione selezionata] [posizione selezionata]

blocca posizione richiesta


[posizione non piu' disponibile] [(posizione amministrativa corretta) & (vincolo propedeuticita' soddisfatto)] [posizione richiesta disponibile] [(posizione amministrativa non corretta) or (vincolo propedeuticita' non soddisfatto)]

effettua prenotazione

effettua prenotazione con riserva

visualizza esito prenotazione

26

Capitolo 4. Modellazione avanzata degli Use Case

3. tipicamente richiedono un periodo di tempo maggiore e talune volte decisamente spropositato per la manutenzione, tempo peraltro amplificato poi dallaumentare della complessit degli stessi. Nella pratica il formalismo che alla fine risulta pi conveniente decisamente quello dei template, di cui nelle pagine seguenti viene riportata lapplicazione al caso in esame.

Template 2
CASO DUSO: UC_IUBS03 Descrizione: Data: 10/01/2001

Prenotazione automatica sessioni desame.

Versione: 0.01.002

Priorit: Durata: Attore primario:

Consente agli studenti universitari, preventivamente autorizzati, di visualizzare le sessioni di esami previste per la materia di interesse ed eventualmente prenotarsi. Laccettazione incondizionata della prenotazione vincolata al rispetto di eventuali vincoli di propedeuticit previsti dai singoli esami e dalla regolarit posizione amministrativa. Elevata. Minuti. Studente universitario. Ha interesse nel ricevere informazioni relative alle sessioni di appello previste per gli esami relative al proprio corso di studi ed eventualmente, ha interesse nel prenotarsi per gli appelli previsti per specifici esami.

Attori secondari:

Amministratore del sistema Viene informato qualora si verifichino gravi condizioni di anomalie del sistema. Lo studente deve essere stato preventivamente riconosciuto dal sistema nel corso dell a sessione. disponibile il profilo dello stesso (amministrativo e studi). Minime: La sessione avviata dello studente rimane valida. Successo: Lo studente prenota la sessione di appello desiderata. Lo studente richiede espli citamente lesecuzione del servizio di prenotazione sessioni di esame.

Precondizioni:

Garanzie:

Avvio:

UML e ingegneria del software: dalla teoria alla pratica

27

Template 3

Scenario principale. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Sistema: Reperisce dati studente. Sistema: Verifica posizione amministrativa studente. Sistema: Reperisce le materie relative alla facolt/corso a cui lo studente risulta iscritto. Sistema: Visualizza lelenco delle materie precedentemente reperite. Studente: Selezione la materia di interesse. Include(Verifica propedeuticit). Sistema: Reperisce lelenco delle sessioni di appello previste per la materia selezionata. Sistema: Visualizza lelenco delle s essioni di appello reperite. Studente: Selezione la sessione ritenuta soddisfacente. Sistema: Visualizza i diversi appelli previsti per la sessione. Studente: Selezione lappello desiderato. Punto di estensione: Verifica singola prenotazione per sessione. Condizione: Lappello prevede il vincolo di singola prenotazione allinterno di una stessa sessione Sistema: Reperisce lelenco delle prenotazioni per la sessione prescelta. Sistema: Visualizza lordine di accettazione visualiz zando unicamente quali posti sono disponibili e quali no. Studente: Seleziona ordine di accettazione (in coda o posizione specifica) Punto di estensione: Selezione ordine di accettazione. Condizione: Funzione abilitata Sistema: Effettua prenotazione. Sistema: Comunica avvenuta prenotazione. Sistema: Termina lesecuzione con successo.

13. 14. 15. 16. 17. 18. 19.

28
Template 4
I scenario alternativo. 2.1. 2.2.

Capitolo 4. Modellazione avanzata degli Use Case

Sistema: La posizione amministrativa dello studente non risulta in regola. Sistema: Memorizza condizione di riserva. esami

II scenario alternativo. 6.1. Sistema: La propedeuticit prevista dallesame non rispettata dagli sostenuti dallo studente. 6.2. Sistema: Memorizza condizione di riserva. III scenario alternativo. 17.1. Sistema: Presenti condizioni di riserva nella sessione. 17.2. 17.3.

Sistema: Effettua prenotazione con riserva. Sistema: Comunica allo stude nte la tipologia della prenotazione e le cause.

IV scenario alternativo. 17.1. Sistema: Fallita prenotazione per conflitto di posizione prescelta. 17.2. 17.3. Sistema: Comunica situazione anomala. Sistema: Riprende dal punto.

I scenario di errore. Punti: 5, 9, 11, 15. 5.1. Studente: Seleziona la terminazione dellesecuzione del caso duso. 5.2. Sistema: Termina lesecuzione del caso duso con insuccesso. II scenario di errore. 7.1. Sistema: Sessioni di appello per la materia selezionata non disponi bili. 7.2. 7.3. Sistema: Comunica allo studente lassenza delle sessioni di appello. Sistema: Termina lesecuzione del caso duso con insuccesso.

III scenario di errore. 12.1. Sistema: (Prevista singola prenotazione per appello nellambito della stessa sessione) e (lo studente risulta gi prenotato ad un appello per la materia nella sessione corrente). 12.2. 12.3. Sistema: Comunica linibizione della funzionalit allo studente. Sistema: Propone la schermata di cui al punto 4.

Annotazioni. 14. Per questioni di tutela della privacy, la funzione di visualizzazione della prenotazione dellordine di accettazione dovrebbe visualizzare unicamente le posizioni ancora disponibili e quelle gi riservate senza fornire informazioni relative allidentit degli studenti prenotati.

UML e ingegneria del software: dalla teoria alla pratica

29

Dallesame dello use case si pu notare che in svariati punti la fruizione del servizio pu fallire per problemi di carattere tecnico e non per questioni relative allapplicazione delle regole di business. Per esempio il sistema pu fallire nellottenere una sessione di connessione al database necessaria per ottenere i dati relativi alla situazione amministrativa dello studente, nel reperire lelenco degli esami previsti, la stessa connessione al database potrebbe non funzionare, ecc. In breve possono verificarsi eccezioni per cos dire di sistema.

La domanda se il caso o meno di inserire eccezioni di sistema nella descrizione dei casi duso. La risposta dellautore : probabilmente no. Finirebbe unicamente per rendere i casi duso pi complessi, pesanti da leggere, ecc. senza peraltro fornire alcuna informazione. Il consiglio pertanto di non inserire questi casi (a meno di situazioni veramente particolari da trattare in maniera non standard) nei casi duso e prevedere un documento incluso nel modello dei requisiti utente in cui specificare il trattamento di questa tipologia di eccezione. Tale documento si presterebbe a essere rielaborato nelle fasi pi tecniche con una sezione relativa alle direttive per il programmatore.

Come si pu notare, gran parte della descrizione del comportamento dinamico del caso duso stata assorbita dalla descrizione dellutilizzo della GUI. Diversi autori consigliano di non perdere troppo tempo in dettagli di questo tipo e di demandarli al relativo modello/prototipo, qualora presente. Chiaramente sempre consigliato realizzare qualche forma di navigazione della GUI (da quella completamente automatica detta anche prototipo a quella rappresentata per mezzo di tabelle di un qualsivoglia editor grafico) poich semplifica il processo di individuazione dei casi duso e di flussi alternativi. Altro processo che risente positivamente del prototipo della GUI quello di verifica: qualora la descrizione di un use case non dovesse essere consistente con la descrizione della relativa GUI, probabilmente qualche problema potrebbe sussistere.

Lautore dellopinione che la specifica delle azioni che un utente tipico esegue interagendo con le schermate del terminale aiuti ad accrescere il livello di comprensione della percezione del punto di vista dellutente. Non opportuno tuttavia riferirsi a dettagli, per cos dire, cosmetici della GUI: lutente seleziona la materia dalla relativa lista video, preme quindi il pulsante per la visualizzazione della finestra relativa alla descrizione di dettaglio, ecc.

Template 5

30
Template 5

Capitolo 4. Modellazione avanzata degli Use Case

Requisiti speciali. 1. In condizioni di massimo utilizzo, il servizio di prenotazione dovrebbe essere fruito, contemporaneamente, da 80/100 studenti. In condizioni di regime il numero si dovrebbe ridurre a 20/30 unit. 2. In numero di conflitti, dovuti a studenti impegnati a realizzare una prenotazione per lo stesso appello relativo ad una specifica materia di esame, non dovrebbe mai eccedere le 10 unit.

Di questo avviso non sono tutti coloro che, non riuscendo mai a dire un loro parere, visto il relativo livello di professionalit, si prodigano in guerre di religione, degne delle crociate, sulle interfacce utente (colore delletichetta, dimensione del tasto, ecc.). In sintesi, la descrizione dellinterazione utente/GUI semplifica la comprensione della prospettiva del sistema posseduta dallo stesso. Volendo incorporare i cosiddetti requisiti speciali, si potrebbe riportare una tabella come il template 5.

Dichiarazione di include ed extend nel template


Si vedranno ora le convenzioni di notazione utilizzate allinterno del template dei casi duso per evidenziare dichiarazioni di inclusione e di estensione. Tali convenzioni possono essere estese a qualsiasi altro tipo di documento. In primo luogo, per entrambi i casi si tratta di unoperazione che pu essere esclusivamente a carico del sistema non avrebbe molto senso evidenziare inclusioni ed estensioni del comportamento degli attori pertanto inutile riportare la dichiarazione che il sistema a eseguire il punto (Sistema :). Per quanto concerne le clausole di inclusione c ben poco da dire: sufficiente riportare nel punto desiderato la dichiarazione include, magari in corsivo per conferire pi enfasi, con il caso duso incluso racchiuso tra parentesi tonde: include (<nome caso duso>) Per ci che attiene la relazione di estensione, la situazione pi complessa per tutta una serie di motivi, quali: lestensione avviene sotto il controllo di una condizione; un caso duso estendente pu estenderne svariati in diversi punti; un singolo caso duso pu essere esteso negli stessi punti da diversi casi duso.

UML e ingegneria del software: dalla teoria alla pratica

31

Le ultime due argomentazioni possono essere sintetizzate riportando che esiste una relazione n a n tra i punti che possono essere estesi di un caso duso esteso e i segmenti che ne specificano il comportamento nei casi duso estendenti. La prima considerazione genera il problema di quale use case (esteso o estendente) debba ospitare la condizione di estensione. La risposta corretta sarebbe: nessuno dei due. Si tratta infatti di una condizione relativa alla relazione stessa e non ai singoli casi duso. Pragmaticamente per, conveniente specificarla nel caso duso esteso, ci perch uno stesso caso duso estendente pu estenderne svariati in funzione di diverse condizioni. Quindi inserire tale clausola nello use case esteso pu dare luogo a ripetizioni (pi use case estesi da uno stesso in funzione della medesima condizione) e pu dar luogo a noiosi elenchi di condizioni (pi use case ne estendono uno nello stesso punto, quindi per ogni relazione di estensione va riportata la clausola) per si tratta di una tecnica consistente. La circostanza in cui uno stesso use case estendente ne estende altri in diversi punti si risolve dichiarando: 1. allinterno dei casi duso estesi, uno specifico nome (magari riportato ancora in carattere corsivo per evidenziarlo) per ogni punto il cui comportamento pu essere esteso. Chiaramente tale nome deve essere univoco allinterno di ogni caso duso. Inoltre, come illustrato pocanzi, opportuno riportare anche la condizione: Punto di estensione: <nome punto di estensione> Condizione: <definizione condizione> 2. allinterno dei casi duso estendenti, per ogni segmento definito, il punto dello use case esteso: Punto di estensione: <nome punto di estensione> Quindi, se la condizione risulta soddisfatta, si pu immaginare che nello use case esteso vengano sostituiti tutti i punti di estensione dichiarati, con i segmenti corrispondenti nel caso duso estendente (labbinamento avviene attraverso il parametro <nome punto di estensione>). Per quanto concerne la relazione di generalizzazione il discorso abbastanza semplice. Lo use case che specializza quello base deve menzionare tutti i punti in cui il comportamento base va specializzato, eventuali punti aggiuntivi, punti da non eseguire, ecc.

Esempio: sistema di banking


Di seguito viene preso in esame lo studio di uninfrastruttura per il supporto dellarea finanziaria (finance) di una banca (investment bank and market). Lautore si scusa se le varie parti presentate in questo paragrafo appaiono inquadrate in maniera non completa in

32

Capitolo 4. Modellazione avanzata degli Use Case

un contesto difficilmente riconoscibile. La ragione di certe reticenze esiste: come al solito incombono vitto e alloggio a spese del Governo, e inoltre, trattandosi in questo caso di quello britannico, la qualit delle due componenti rispettivamente scarsissima e scarsa, e il tutto assume tinte decisamente pi tragiche del solito Prima di addentrarsi nellesame dei vari casi duso selezionati si ritiene opportuno presentarne brevemente lambiente. Tipicamente le strutture informatiche di sistemi complessi come quelli bancari/di investimento prevedono una serie di sottosistemi, ognuno specializzato nella erogazione di un insieme ben definito di servizi, che cooperano (scambiandosi messaggi) al fine di raggiungere lobiettivo comune di fornire determinati servizi (situazione del sistema di sistemi esaminata nel Capitolo 2 UML: struttura, organizzazione, utilizzo). Esempi tipici di sottosistemi (fig. 7) che si possono trovare in un sistema bancario sono quello Internet (il famoso .com), il sottosistema specializzato per la gestione del front office (sportello), quello demandato allaccounting, altri finalizzati alla gestione degli investimenti e relativi controlli, quello dedicato alla sicurezza, quello atto a controllare che il sistemi funzioni correttamente (health monitoring), altri ancora dedicati alla gestione in tempo reale dei dati delle quotazioni di mercato dei prodotti finanziari e cos via. Linterconnessione tra i vari sistemi ottenuta di solito attraverso opportuni middleware indicati con lacronimo MOM (Messaging Oriented Middleware, sistemi orientati alla gestione della messaggistica). Lobiettivo disaccoppiare il pi possibile i vari sistemi: una volta il problema era a livello di classi o al pi di package, ma oggigiorno il livello di astrazione in crescita continua. Al momento in cui questo libro viene redatto si assiste sempre pi frequentemente allutilizzo di MOM di nuova generazione basati su architetture JMS come da specifiche Sun (Java Messaging System, sistema di messaggistica Java), in grado di funzionare sia in modalit point to point (PTP, punto a punto), sia in publish and subscribe (Pub&Sub, pubblica e sottoscrivi). Secondo questo scenario, il bus di comunicazione (MOM) viene ripartito in una serie di canali logici in funzione della tipologia di messaggi da scambiare (dati dinamici, dati statici, dati necessari per fini statistici, dati riportanti segnalazioni di anomalie, ecc.). Un sistema per emettere/ricevere messaggi deve necessariamente e preventivamente registrarsi (subscribe) al o ai canali sui quali intende, rispettivamente, trasmettere (publish) o ricevere. Come evidenziato in figura, lattuazione di architetture di questo tipo prevede la necessit di adattare legacy system di vecchia concezione ad architetture pi moderne. Il problema viene affrontato cercando di incapsulare il sistema stesso in un apposito layer (wrapper, ancora una volta) in grado di comunicare con i due mondi: MOM da una parte e legacy system dallaltra.

UML e ingegneria del software: dalla teoria alla pratica

33

Figura 7 Frammento di un esempio di architettura di un sistema bancario. Nello scenario mostrato, alcuni sistemi risultano ex-novo (Static Data Manager, Market Data System, Banking on-line) e quindi sono realizzati direttamente per dialogare via MOM con altri sistemi. Gli altri, essendo di vecchia generazione (Investment Management System, Exception Management System, Accounting System, Data Warehouse) necessitano di un apposito strato di wrapping.

System healt monitoring

Banking on-line

Accounting System

Data Warehouse

Security Manager

Messaging services JMS

MOM
JMS Messaging services

Static Data Manager

Investiment Management System

Exception Management System

Market Data System

Legacy System Wrapper

Altri sistemi invece (come per esempio quello di banking online) essendo di nuova generazione, dovrebbero venir progettati per poter naturalmente interagire con middleware di comunicazione e quindi non hanno bisogno di particolari strutture di wrapping. Analizzando gli attori che interagiscono con i vari sottosistemi, potrebbe nascere un dilemma. Per ci che concerne gli utenti veri e propri, non ci sarebbe nulla di nuovo, ma per quanto riguarda linterazione con altri sottosistemi, potrebbe nascere il dubbio se visualizzare unicamente il MOM come attore tecnologico oppure, di volta, in volta menzionare i vari sottosistemi. Lalternativa ritenuta pi corretta dallautore la seconda. In primo luogo perch lattore MOM sarebbe troppo legato allo spazio delle soluzioni e poco a quello del problema:

34

Capitolo 4. Modellazione avanzata degli Use Case

si tratta di un meccanismo di comunicazione e probabilmente sarebbe come dire che il modem o il telefono potrebbero, a loro volta, assurgere al ruolo di attori. Trattandosi poi di un attore unico scudo di ciascun sottosistema, quindi assolutamente privo di volont e necessit proprie, renderebbe pi difficile inquadrare i servizi in un contesto organico di cooperazione tra sottosistemi. Unaltra argomentazione contraria al MOM come attore relativa al fatto che lutente medio, che, per definizione, non dispone di conoscenze informatiche, tende a non comprendere dettagli di soluzioni tecnico-architetturali e quindi ad aver problemi nellidentificare il MOM come attore.

Wrapper sistema di gestione dei trade


Si cominci con lanalizzare un frammento di un dispositivo di wrapper atto a gestire la manutenzione dei dati statici nel sistema di gestione dei trade (Trade Management System, TMS). Compito della sezione del wrapper preso in esame ricevere i dati statici e incorporare gli aggiornamenti nel TMS. Analizzando lo schema dellarchitettura (fig. 7), possibile evidenziare un sistema denominato Static Data Manager (Gestore dei Dati Statici), il cui compito assicurare luniformit dei dati, definiti tecnicamente statici, utilizzati dallintero sistema. Esempi di dati statici sono le informazioni relative alle controparti (entit che prendono parte in un trade, acquistano e/o vendono prodotti finanziari), alle valute (Euro, Sterlina, ecc.), alle istruzioni per i settlement, ai prodotti finanziari, ecc. In particolare, lo Static Data Manager, tipicamente prevede tre macro componenti: 1. uninterfaccia utente (tipicamente web-based), atta a consentire allutente la gestione dei dati statici (presentation layer); 2. un middle-tier di comunicazione con le tabelle del database. Espone una serie di servizi atti a reperire i dati da mostrare nellinterfaccia utente e conseguentemente per memorizzare dati nelle tabelle (business logic); 3. un sistema di messaggistica atto a pubblicare i dati, attraverso opportuni messaggi immessi sul MOM, in risposta agli aggiornamenti effettuati. Per lo scambio dei messaggi si preferisce ricorrere a formati non proprietari, quali per esempio XML (al momento in cui viene scritto il libro a tutti gli effetti lo standard de facto) per consentire a sistemi utilizzanti tecnologie diverse di comunicare tra loro. Ci implica la necessit per di effettuare il parsing e la conversione dello stesso in una forma pi vicina al sistema (oggetti opportunamente relazionati). A questo punto si consideri la porzione del wrapper che consente di aggiornare i dati relativi ai libri (book) del sistema finanziario.

UML e ingegneria del software: dalla teoria alla pratica

35

Brevemente i book sono le pi piccole unit di unorganizzazione finanziaria, utilizzate per organizzare i trade. Ognuno di essi appartiene a una sottoorganizzazione (Processing Organization, specializzazione di una LegalEntity) dellistituto finanziario, sita in una citt ben definita. Questa associazione molto importante perch permette sia di stabilire molte informazioni, quali lorario della chiusura delle attivit finanziare della citt di riferimento e quindi lorario di avvio di opportune procedure batch (come per esempio rivalutazioni di fine giornata, end of day revaluation), il calendario delle festivit (Holiday Calendar) la cui conoscenza permette di evitare che specifiche date (maturazione trade) cadano in giorni festivi, ecc. Da tener presente che non sempre le Processing Organisation utilizzano la valuta della citt/nazione in cui sono ubicate e che il calendario delle festivit di una determinata citt, non coincide con quello della nazione di appartenenza (si considerino, per esempio, le feste patronali). Per ciascun Book anche necessario poi specificare la valuta base di riferimento. Figura 8 Frazione del modello a oggetti del dominio relativo al book.

City
- id : String * - name : String - description : String ... ... observes 1 is located 1 *

LegalEntity
- id : String - name : String - description : String ... ... *
s up gro

AccountingBook
- id : String - name : String - description : String ... ... 1

ult efa ad as h

Currency
- isoCode : String - value : float - name : String - decimal : byte - symbol : char ... ...

Book
- id : String

Trade
holds

has base currency - name : String

- endOfDay : Time ... ...

- id : String - date : Date - time : Time ... ...

HolidayCalendar
- id : String - description : String ... 1 ... ...
includes

Holiday
- holidayDate : Date - name : String *

36

Capitolo 4. Modellazione avanzata degli Use Case

Sebbene il formalismo del diagramma delle classi mostrato (fig. 8) non sia stato ancora illustrato in dettaglio, il suo significato dovrebbe essere sufficientemente chiaro. Si tratta di un frammento (quello relativo ai book ovviamente) di un modello del dominio. Su questo argomento si avr modo di spendere pi tempo nel corso del Capitolo 7 e in particolare nel Capitolo 8. Per ora basti sapere che il modello del dominio una rappresentazione concettuale delle entit coinvolte nellarea business oggetto di studio. Si tratta di un manufatto di estrema importanza. Fornisce una prima versione utile per il modello di disegno, per lorganizzazione in componenti del sistema, per la progettazione del database e dellinterfaccia utente, ecc.

Nel contesto dei casi duso si consiglia vivamente di riferirsi ai diagrammi a oggetti del dominio o del business qualora presenti. Ci favorisce una migliore comprensione dellarea oggetto di studio, permette di bilanciare gli stessi diagrammi dei casi duso, favorisce il conferimento della giusta enfasi ai dati principali di eventuali interfacce, aiuta ad evidenziare la necessit di pianificare specifiche funzioni, e cos via. Con il termine bilanciare, si intende dire che, una volta catturati i requisiti del sistema, si vuole disporre di diagrammi dei casi duso e del dominio (o business) corretti e completi.

Un modo per ottenere ci, consiste nel verificare che: 1. tutti gli oggetti menzionati nei casi duso siano presenti nel modello a oggetti del dominio, opportunamente relazionati (bilanciamento del modello del dominio rispetto ai casi duso); 2. tutte le classi presenti nel modello del dominio, siano, in qualche misura riferite nei diagrammi dei casi duso, con particolare riferimento alle funzionalit di cui hanno bisogno (inserimento, aggiornamento, ecc.) e/o che sono in grado di provvedere bilanciamento dei casi duso rispetto al modello a oggetti del dominio. Per esempio, nel caso in cui non fosse ben chiara la relazione tra le entit Book e Trade, analizzando le funzioni necessarie per lelaborazione di un messaggio relativo a un Book, e in particolare relativo alla eliminazione dello stesso, si potrebbe correre il rischio di non considerare alcune casistiche (flussi) di una certa importanza e, conseguentemente, lasciare inesplorate diverse aree. Potrebbe ad esempio sfuggire la necessit di prevedere una funzione di reperimento dei Trade associati a un Book. Questa funzione necessaria per assicurare che non siano presenti Trade appartenenti al Book da eliminare, in quanto in caso contrario, procedendo con leliminazione del Book, si perderebbero tutti i dati dei

UML e ingegneria del software: dalla teoria alla pratica

37

Trade ad esso associati (magari qualche milione di Euro). A tal fine sarebbe necessaria una semplice operazione di check (Trade presenti o meno); invece si ricorre a un reperimento, in quanto qualora presenti dei Trade associati al book da eliminare, i relativi Id andrebbero comunicati al sistema di risoluzione delle eccezioni. Ci al fine di far precedere alla procedura di eliminazione di un Book, quella di spostamento dei Trade dal Book da rimuovere a un altro. Gli use case di fig. 9 mostrati con una tonalit pi intensa di giallo, mostrano le funzionalit comuni (pattern) eseguite a seguito della ricezione di un messaggio, indipendentemente dalla natura dello stesso. Verosimilmente, con riferimento alla descrizione dellarchitettura riportata in fig. 7, i primi quattro use case rappresentano lo strato ribattezzato Messaging services utilizzabile dai vari sistemi di wrapper. Prima di descrivere il comportamento dinamico inevitabile una breve disquisizione (probabilmente pi opportuno definirlo soliloquio, anche perch trattandosi di un libro un po complicato gestire un dibattito) relativa al livello di dettaglio del diagramma di casi duso presentato in figura. Il punto focale efferente la questione: il diagramma dei casi duso troppo descrittivo?. Figura 9 Diagramma dei casi duso relativo allelaborazione del messaggio inerente ad aggiornamenti relativi allentit book.

Conversione messaggio

Elaborazione messaggio

include

include

Comunica messaggio dati statici

extend

Static Data Manager

extend

extend

Invia messaggio di errore

Elaborazione messaggi relativi a book

Exception Management System


Aggiornamento book Eliminazione book

TMS

Inserimento nuovo book


include

Reperimento Trade associati al book

38

Capitolo 4. Modellazione avanzata degli Use Case

Bench per molti tecnici la risposta potrebbe essere affermativa, si considerino i seguenti elementi: System use case. La versione presa in esame quella che generalmente viene denominata di sistema. Ci facilmente comprensibile poich il confine del diagramma uno specifico sottosistema e non lintero sistema. I fruitori non sono pi esclusivamente gli utenti, ma anche il team di sviluppo e quindi, in questa fase del processo di sviluppo, un livello di astrazione non eccessivamente elevato non assolutamente vietato. I singoli use case esistono sebbene non li si mostri esplicitamente. Nella descrizione del comportamento dinamico degli elementi appartenenti al diagramma, comunque possibile evidenziare specifiche sezioni relative ai casi duso mostrati in fig. 9. Chiaramente mostrare tutti i diagrammi derivanti dal raggruppamento logico di sezioni della descrizione del comportamento dinamico sarebbe una follia e potrebbe generare problemi visti nel capitolo precedente. Mostrare quelli pi importanti, per agevola levidenziazione di comportamenti comuni. Da tener presente che, non sempre possibile realizzare tutte le fase del processo di sviluppo del software per questioni legate a vincoli temporali. In questi casi, tipicamente la fase che pi frequentemente viene sacrificata quella di analisi. In tal caso evidenziare qualche elemento in pi nei diagrammi dei casi duso risulta molto conveniente. Una preoccupazione che induce gli analisti del business a condensare i casi duso loverhead (extra lavoro) per descrivere i singoli casi duso richiesto da taluni template. Dallanalisi del caso duso di template 6, si pu notare che per i punti di estensione 2.2 e 3.2, non sono state riportate le condizioni di estensione: queste sono implicite dal fatto che sono comportamenti appartenenti a un flusso di eccezione. La condizione quindi quella del flusso stesso. Qualora si abbia a che fare con sistemi di messaggistica utile riportare uno o pi specifici use case per la comunicazione di messaggi in quanto semplificano il processo di individuazione e bilanciamento dei messaggi presenti nel sistema. Lo use case descritto in template 7 potrebbe appartenere alla categoria di quelli non strettamente necessari. Si invece deciso di riportarlo separatamente sia perch evidenzia una funzionalit comune e importante che vale la pena evidenziare, sia perch essendo comune a tutte le tipologie di messaggio viene definito una sola volta ed utilizzato in molti contesti. Come si pu notare, le sezioni ritenute non significative (Attori, Avvio, ecc.) in questo contesto, sono state placidamente omesse. In genere ha senso specificare il campo Avvio solo nel caso in cui lo use case richieda uninterazione con un attore; in tutti gli altri casi si tratterebbe dellinvocazione da parte di un altro caso duso.

UML e ingegneria del software: dalla teoria alla pratica

39

Template 6
CASO DUSO: Comunica messaggio dati statici UC_BNK_FRM_01 Descrizione: Data: 13/02/2001

Versione: 0.01.000

Il sottosistema SDM notifica (attraverso opportuno messaggio pubblicato sul MOM) lavvenuta variazione del proprio stato (variazione di dati statici) al fine di consentire agli altri sottosistemi di sincronizzare il proprio stato. Media. (Nelle prime versioni questa funzionalit pu essere simulata attraverso un sistema di GUI). Secondi. SDM (Static Data Manager). Ha interesse nel pubblicare messaggi contenenti informazioni relative ad aggiornamenti effettuati nel dominio dei dati statici. Il sistema si sia precedentemente sottoscritto per la tipologia del messaggio disponibile. Minime: Il messaggio rimane disponibile. Successo: Il sistema prende correttamente in carico il messaggio ed riflette le relative operazioni nella propria base dati Viene pubblicato un messaggio appartenente ad una delle tipologia per la quale il sistema si sottoscritto.

Priorit: Durata: Attore primario:

Precondizioni: Garanzie:

Avvio:

Scenario principale. 1. SDM: Pubblica un nuovo messaggio relativo a variazioni dei dati statici per la quale il sistema si sia precedentemente registrato. 2. 3. 4. 2.1. 2.2. 2.3. Sistema: Acquisisce il messagg io. Sistema: Include(Conversione messaggio) Sistema: Include(Elaborazione messaggio) Il sistema fallisce nellacquisizione del messaggio Punto di estensione: Notifica condizione di errore. Termina lo use case in maniera anomala

Primo scenario di errore.

Secondo scenario di errore. 3.1. Il sistema fallisce la conversione del messaggio 3.2. 3.3. Punto di estensione: Notifica condizione di errore. Termina lo use case in maniera anomala

40

Capitolo 4. Modellazione avanzata degli Use Case

Template 7
CASO DUSO: Conversione messaggio UC_BNK_FRM_02 Descrizione: Data: 13/02/2001

Versione: 0.00.003

Priorit: Durata: Precondizioni: Garanzie:

Esegue la conversione del messaggio. Se il messaggio ricevuto conforme al formato atteso, viene trasformato in quello previsto dal sistema (tipicamen te si assiste ad una trasformazione dal formato XML ad una rappresentazione ad aggetti) Media. Secondo. Il sistema abbia ricevuto un nuovo messaggio. Minime: Il messaggio non viene convertito. Successo: Il messaggio viene correttamente trasformato nel formato previsto dal sistema.

Scenario principale. 1. Sistema: Acquisisce la tipologia del messaggio. 2. 3. Sistema: Reperisce le regole che consentono di convertire la particolare tipologia di messaggio. Sistema: Converte il messaggio in base alle regole reperite.

Primo scenario di errore. 2.1. Il sistema fallisce il reperimento delle regole 2.2. Termina lo use case in maniera anomala Secondo scenario di errore. 3.1. Il sistema fallisce la conversione del messaggio 3.2. Termina lo use case in maniera anomala

UML e ingegneria del software: dalla teoria alla pratica

41

Template 8
CASO DUSO: Invio messaggi di errore UC_BNK_FRM_03 Descrizione: Priorit: Durata: Attore primario: Precondizioni: Garanzie: Scenario principale. 1. 2. 3. 3.1. 3.2. Punto di estensione: Notifica condizione di errore. Sistema: Struttura secondo il formato previsto il messaggio di errore. Sistema: Pubblica il messaggio. Il sistema fallisce linvio del messaggio. Termina lo use case in maniera anomala. Data: 14/02/2001

Versione: 0.00.001

Pubblica un apposito messaggio al fine di notificare allException Management System il verificarsi di unanomalia. Media. Secondi. Exception Management System. Riceve il messaggio di errore emesso dal sistema. Il sistema disponga dei dati atti a descrivere lerrore verificatosi. Minime: I dati efferenti lerrore restano inalterati. Successo: Il messaggio viene correttamente pubblicati.

Primo scena rio di errore.

Annotazioni. 3.1. Cosa fare quando si fallisce la pubblicazione di un errore? Sufficiente registrare lanomalia in un opportuno file di log?

42
Template 9
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Elaborazione messaggio

16/02/2001

UC_BNK_FRM_04 Descrizione: Priorit: Durata: Attore primario:

Versione: 0.00.001

Elabora il messaggio ricevuto in base alla tipologia dei dati presenti e della funzione da eseguire. Media. Secondi. Trade Management System (TMS) Il sistema di gestione dei trade esegue la transizione r ichiesta dallelaborazione del messaggio al fine di sincronizzare i pr opri dati statici con quelli presenti presso il SDM. Sono disponibili i da ti relativi al messaggio ricevuto nel formato atteso dal sistema (rappresentazione ad oggetti). Minime: I dati relativi al messaggio non vengono alterati. Successo: Il messaggio viene elaborato correttamente in funzione alla sua tipologia e la relativa transazione originata viene eseguita correttamente dal TMS.

Precondizioni: Garanzie:

Scenario principale. 1. Sistema: Acquisisce la rappresentazione ad oggetti del messaggio. 2. Punto di estensione: Elabora il messaggio. (Il messaggio elaborato in funzione della relativa tipologia) Condizione: Relazione con use case Elabora messaggi relativi ai book (Tipologia messaggio = book) Relazione con use case Elabora messaggi relativi a Trade (Tipologia messaggio = trade) ... Sistema: Rifinisce il formato de i dati per adattarlo a quello previsto dalla transazione da richiedere al sistema TMS. Sistema: Richiede al sistema TMS di eseguire la transazione predisposta al punto 2. TMS: Riceve ed esegue la transazione. TMS: Comunica esisto transazione. Sistema: Verifica che la transazione sia stata eseguita correttamente

3. 4. 5. 6. 7.

Primo scenario di errore. 2.1. Sistema: La funzione di elaborazione del messaggio fallisce. 2.2. 2.3. Punto di estensione: Notifica condizione di errore. Sistema: Termina lo use case in maniera anomala

Secondo scenario di errore. 7.1. Sistema: Transazione fallita 7.2. 7.3. Punto di estensione: Notifica condizione di errore. Sistema: Termina lo use case in maniera anomala.

UML e ingegneria del software: dalla teoria alla pratica

43

Template 10
CASO DUSO: UC_BNK_BKM_01 Descrizione: Priorit: Durata: Attore primario: Data: 18/02/2001

Reperimento dati trade associati al book

Versione: 0.01.000

Reperisce dal sistema di gestione dei trade le informazioni relative ad eventuali Trade associati al Book specificato. Media. Secondi. TMS Esegue la funzione di reperimento dei Trade associati al Book specificato. disponibile nel sistema il codice del Book del quale si vuole reperire i dati dei Trade associati. Minime: Nessun dato viene alterato. Successo: La funzione di reperimento viene eseguita correttamente.

Precondizioni: Garanzie:

Scenario principale. 1. Sistema: Acquisisce il codice del Book da reperire. 2. 3. Sistema: Richiede il reperimento dei trade associati al book. TMS: Reperisce le informazioni dei trade richiesti.

4. Sistema: Memorizza le informazioni dei Trade reperiti. Primo scenario alternativo. 4.1. 4.2. 4.3 Non esistono nel sistema Trade associati al Book richiesto. Nessun informazione relativa ai Trade viene memorizzata. Termina lo use case senza comunicare alcun errore.

44
Template 11
CASO DUSO: UC_BNK_BKM_02 Descrizione:

Capitolo 4. Modellazione avanzata degli Use Case

Elaborazione messaggi relativi a book

Data:

16/02/2001

Versione: 0.00.004

Priorit: Durata: Attore primario: Precondizioni: Garanzie:

Elabora il messaggio inerente il Book specificato. In particolare, in funzione della tipologia del messaggio, il sistema deve eseguire una delle seguenti transazioni: - inserimento di un nuovo Book; - aggiornamento di uno esistente; - eliminazione di un Book. Media. Secondo. TMS Comunica i dati relativi al Book richiesto. Il messaggio ricevuto relativo ad un Book i cui dati sono disponibili nella rappresentazione attesa dal sistema. Minime: I dati relativi al messaggio non vengono alterati. Successo: Il messaggio viene elaborato correttamente, e vengono preparati i dati in funzione della transazione da eseguire.

Scenario principale. 1. 2. 3. 4. 5. Punto di estensione: Elabora il messaggio. Sistema: Acquisisce il codice del Book. Sistema: Richiede al sistema TMS le informazione relative al Book. TMS: Comunica le informazioni relative al Book specificato.

Punto astratto: Organizza le informazioni in funzione della transazione da eseguire sui dati del Book Primo scenario di errore. 5.1. 5.2. Sistema: Lo use case concreto che definisce il comportamento astratto termina con insuccesso. Sistema: Termina lo use case in maniera anomala

Nella pratica, la corretta applicazione di processi di sviluppo richiede una buona dose di pragmatismo: tutto ci che non concorre ad aumentare il livello conoscitivo pu essere trascurato.

UML e ingegneria del software: dalla teoria alla pratica

45

Use case astratti sono i pi difficili da far comprendere agli utenti, quindi il loro utilizzo andrebbe opportunamente ponderato. In sostanza quello pocanzi descritto fornisce una procedura comune per tutte le funzioni relative alla gestione dei dati dei book. Il primo punto sancisce che la relativa esecuzione avviene solo nel caso in cui i dati contenuti nel messaggio siano relativi a un oggetto book. I seguenti due contengono del comportamento comune, mentre lultimo punto rappresenta un passo astratto. Pertanto compito degli use case specializzanti fornirne il comportamento concreto in base alla funzione da eseguire.

Template 12
CASO DUSO: Inserimento nuovo book UC_BNK_BKM_04 Descrizione: Priorit: Durata: Precondizioni: Garanzie: Data: 18/02/2001

Versione: 0.00.001

Organizza i dati per eseguire una transazione di inserimento di un nuovo Book. Media. Secondo. Sono disponibili i dati del nuovo Book da inserire nel sistema di gestione trade (TMS). Minime: I dati relativi inerenti il nuovo Book non vengono modificati. Successo: I dati vengono organizzati correttamente in funzione alla transazione di inserimento da es eguire.

Scenario principale. 1. Definizione punto astratto Organizza le informazioni in funzione della transazione da eseguire sui dati del Book 2. Sistema: Verifica che la funzione di reperimento dati Book non abbia indiv iduato alcuna istanza. (In sostanza non esiste un Book con lo stesso codice di quello da inserire)

3. Sistema: Organizza i dati per eseguire una transazione di inserimento. Primo scenario di errore. 2.1. 2.2. Sistema: Un Book con codice equivalente a quello da inserire gi pr esente nel sistema. Sistema: Termina lo use case in maniera anomala

46

Capitolo 4. Modellazione avanzata degli Use Case

Template 13
CASO DUSO: Aggiornamento book UC_BNK_BKM_05 Descrizione: Priorit: Durata: Precondizioni: Garanzie: Data: 18/02/2001

Versione: 0.00.001

Organizza i dati per eseguire una transazione di aggiorn amento di un Book. Media. Secondo. Sono disponibili i dati del Book da aggiornare. Minime: I dati relativi inerenti il Book non vengono modificati. Successo: I dati vengono organizzati correttamente in funzione alla transazione di aggiornamento da eseguire.

Scenario principale. 1. Definizione punto astratto: Organizza le informazioni in funzione della transazione da eseguire sui dati del Book. 2. 3. Sistema: Verifica che la funzione di reperimento dati Book abbia ind ividuato listanza richiesta. (Il Book da modificare presente nel TMS) Sistema: Organizza i dati per eseguire una transazione di aggiorname nto Book.

Primo scenario di errore. 2.1. Sistema: Non presente nel TMS un Book con codice equivalente a quello da specificato nel messaggio. 2.2. Sistema: Termina lo use case in maniera anomala

UML e ingegneria del software: dalla teoria alla pratica

47

Template 14
CASO DUSO: Eliminazione book UC_BNK_BKM_06 Descrizione: Priorit: Durata: Precondizioni: Garanzie: Data: 18/02/2001

Versione: 0.00.002

Organizza i dati per eseguire una transazione di eliminazi one di un Book. Media. Secondo. Sono disponibili i dati rela tivi ad un Book da eliminare. Minime: I dati relativi inerenti il Book non vengono modificati. Successo: I dati vengono organizzati correttamente in funzione alla transazione di eliminazione da eseguire.

Scenario principale. 1. Definizione punto astratto: Organizza le informazioni in funzione della transazione da eseguire sui dati del Book 2. Sistema: Verifica che la funzione di reperimento dati Book abbia ind ividuato listanza richiesta. (Il Book da modificare presente nel sistema TMS) Sistema: Include(Reperimento dei dati associati al Book) Sistema: Verifica che non ci siano Trade associati al Book da eliminare. (La precedente funzione restituisce una lista vuota) Sistema: Organizza i dati per eseguire una transazione di eliminazione Book.

3. 4. 5.

Primo scenario di errore. 2.1. Sistema: Non presente nel sistema TMS un Book con codice equivalente a quello da specificato nel messaggio. 2.2. Sistema: Termina lo use case in maniera anomala Seconfo scenario di errore. 4.1. Sistema: Sono presenti dei dati associati al Book da eliminare 4.2. 4.3. Sistema: Memorizza tutti gli Id dei Trade in unapposita lista da inserire nel messaggio di errore. Sistema: Termina lo use case in maniera anomala

48

Capitolo 4. Modellazione avanzata degli Use Case

Figura 10 Dipendenze tra gli use case a livello di sistema e gli altri manufatti. Chiaramente la dipendenza del modello dei casi duso e di quelli non funzionali non implica che questi confluiscano nei casi duso, bens che alcune funzionalit potrebbero essere, per cos dire, riviste in funzione di altri vincoli.

use case Modello Business

Requisiti non funzionali


refine

use case Modello di Sistema

Modello di Architettura

Sistema di banking online


Si illustrer uno dei servizi offerti dal sistema di banking online; in particolare viene presentata la funzione che consente ai clienti accreditati di acquistare azioni (shares) online. Tali clienti devono possedere un conto corrente presso la banca e aver ottenuto conferma alla relativa richiesta di fruizione del servizi di trading online. Si tratta del solito ozioso utente condannato a starsene seduto comodamente a casa sua e a navigare in Internet. Questo servizio non stato selezionato casualmente, ma in virt degli spunti che in grado di offrire. In particolare viene evidenziato come gli use case appartenenti al modello di sistema, oltre a inglobare indicazioni provenienti dallarchitettura dello stesso, incorporano sezioni, o meglio suggerimenti, derivanti dai requisiti non funzionali. Una struttura online, destinata a operare secondo le specifiche del protocollo sincrono HTTP, difficilmente potrebbe funzionare utilizzando unicamente i meccanismi offerti da

UML e ingegneria del software: dalla teoria alla pratica

49

sistemi MOM. In particolare, il sistema dovrebbe soddisfare anche precisi requisiti non funzionali, come per esempio stringenti tempi di risposta non garantiti dai sistemi di messaggistica. Questi, tipicamente, si fanno carico di una serie di assicurazioni (i messaggi vengono consegnati correttamente e solo una volta), ma non forniscono alcuna certezza sulle prestazioni, sebbene poi nella stragrande maggioranza dei casi riescano a effettuare la consegna nellarco dei secondi. Ulteriore considerazione relativa al tempo necessario per costruire i vari messaggi in formato XML (in spedizione) e per trasformarli nuovamente in un apposito grafo di oggetti (in ricezione). Tempi che non sempre sono trascurabili. Il vincolo di ricevere informazioni molto rapidamente una restrizione decisamente pressante non solo per motivi legati alla fruizione del servizio in Internet, ma anche per la natura del servizio stesso. Per esempio, dovendo visualizzare le quotazioni in tempo reale delle azioni, non si pu di certo tollerare di ricevere i dati con una latenza tale da rendere gli stessi non pi attendibili. Le precedenti considerazioni sono state illustrate graficamente nella fig. 10.

Figura 11 Use Case relativo allacquisto online di shares.

Comunica dati shares

Verifica fattore di rischio

Market Data System

include

include

Acquisto shares on-line

Cliente
include extend extend

Invia dati conto corrente cliente

Invia messaggio di errore

Accounting System

Exception Management System

Invia messaggio dati transazione

TMS

50

Capitolo 4. Modellazione avanzata degli Use Case

Ricapitolando, i diagrammi dei casi duso della fase di sistema devono sia dettagliare i corrispondenti al livello dei requisiti (o di business, se si preferisce), sia incorporare eventuali suggerimenti derivanti dai requisiti non funzionali (NFR, non functional requirements, consultare il Capitolo successivo) e direttive provenienti dallarchitettura. Questultima a sua volta deve dipendere dai NFR nonch dagli use case stessi. A questo punto si prenda in considerazione (finalmente) il diagramma dei casi duso riportato nella fig. 11. Gli attori previsti dallo use case sono: il cliente (linvestitore); Market Data System, utilizzato per reperire i dati relativi alle quotazioni di mercato in tempo reale di determinati prodotti finanziari. Tipicamente si tratta di un sistema interno alla banca alimentato da servizi offerti da terze parti; Accounting System, necessario per reperire la situazione finanziaria dellinvestitore che richiede di acquistare le varie azioni; Exception Management System, al quale vengono inviati eventuali messaggi relativi a gravi anomalie occorse; Trade Management System, al quale vengono affidate, attraverso opportuni messaggi, le transazioni effettuate online. Per quanto concerne la descrizione del comportamento dinamico del precedente caso duso, il template adottato sensibilmente differente da quello utilizzato in precedenza. In questo caso la parte dedicata allo scenario principale ripartita in tante sezioni quante sono le entit coinvolte (gli attori pi il sistema stesso). La peculiarit della nuova versione proposta di evidenziare chiaramente le azioni svolte dalle varie entit e quindi le efferenti responsabilit. Per molti versi ricorda molto gli activity diagram. A fronte di questo vantaggio, presenta lo svantaggio di occupare molto pi spazio. Spesso, il non riuscire a visualizzare tutto un flusso in una pagina pu creare dei problemi di comprensione dello stesso.

UML e ingegneria del software: dalla teoria alla pratica

51

Template 15
CASO DUSO: Acquisto share on line UC_BKL_BKS_01 Descrizione: Data: 03/12/2000

Versione: 0.09.003

Durata: Priorit: Attore primario:

Fornisce ai clienti abilitati il servizio on-line di acquisto di titoli azionari. Lutente, previa opportuna autorizzazione, fruendo del servizio attraverso un comune browser Internet, in grado di ricevere informazioni ed eventualmente acquistare prodotti finanziari. Minuti. Elevata. Cliente della banca. Ha interesse a ricevere informazioni relative a parti prodotti finanziari ed eventualmente ad acquistarli. colari

Precondizioni:

Garanzie minime:

Garanzie successo:

Il cliente dispone di almeno un conto corrente presso la banca, abilitato alla fruizione del servizio, ed stato precedentemente autorizzato dal sistema nellambito dell a sessione (corretta esecuzione della procedura di log-in). Lo situazione azionaria ed il conto corrente del cliente non vengono modificate: permangono nello stato presente prima dellesecuzione. Il cliente effettua una transazione di acquisto di titoli azionari. Le informazioni relative alle transazioni vengono inviate per mezzo di opportuno messaggio al sistema di back office. Il cliente richiese esplicitamente lesecuzione del servizio di acquisto di titoli azionari.

Avvio:

52

Capitolo 4. Modellazione avanzata degli Use Case

Template 16
Scenario principale. 1. 2. 3. Visualizza linsieme delle azioni appartenenti alla specializzazione selezionata. Seleziona il titolo di interesse. Include(Comunica dati shares) Visualizza i dati aggiornati relativi al titolo selezionato 6. 7. 8. 9. 10. 11. 12. Include(Comunica dati shares) Visualizza i dettagli economici ed in particolare lultimo prezzo dis ponibile per il titolo oggetto di acquisto. Chiede conferma a procedere con la transazione. Accetta la transazione Punto di estensione: Invio messaggio dati transazione Condizione: Utente accetta transazione Include(Verifica fattore di rischio) Include(Invia dati conto c orrenti cliente). Visualizza dati conto correnti int estati al cliente Seleziona il conto corrente da utilizzarsi per la transazione Imposta la quantit desiderata. SISTEMA Visualizza le specializzazioni in cui si suddividono le azioni disponibili. CLIENTE

Seleziona la specializzazione di int eresse.

4. 5.

14. 15. 16.

UML e ingegneria del software: dalla teoria alla pratica

53

Template 17
I scenario alternativo. 15.1. Utente: Non conferma la transazione nei limiti di tempo prestabiliti. 15.2. 15.3. Sistema: Comunica apposito messaggio allutente. Sistema: Torna ad eseguire dal punto 10.

I scenario di errore. Punti: 2, 4, 6, 15. 2.1. Utente: Non imposta i dati attesi e richiede la terminazione della funzione. 2.2. Sistema: Termina lo use case con insuccesso. II scenario di errore. 7.1. Sistema: Fattore di rischio delloperazione richiesta superiore ai limiti previsti. 7.2. 7.3 Sistema: Visualizza apposito messaggio allutente. Sistema: Termina lo use case con insuccesso.

III scenario di errore. 5.1. Sistema: Errore nel reperimento dati share. 5.2. 5.3. 5.4. Sistema: Comunica momentanea non disponibilit del sistema. Extension point: Invio messaggio di errore Sistema: Termina lesecuzione della funzione con insuccesso.

IV scenario di errore. 8.1. Sistema: Errore nel reperimento dati conto correnti utente. Resto come da scenario di errore precedente. V scenario di errore. 11.1. Sistema: Errore nel reperimento dati share. Resto come da scenario di errore precedente. VI scenario di errore. 16.1. Sistema: Fallisce invio messaggio dati transazione. Resto come da scenario di errore precedente.

54
Template 18
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Comunica dati shares

03/12/2000

UC_BKL_BKS_02 Descrizione: Durata: Priorit: Attore primario:

Versione: 0.01.002

Permette di reperire le quotazioni di mercato in tempo reale dei prodotti finanziari richiesti. Secondo. Elevata. Market Data System (MDS). Fornisce le quotazioni di mercato in tempo reale relative ai prodotti specificati. Sia disponibile una connessione con il Market Data System e sia disponibile il codice del prodotto da reperire. ?. Vengono reperite le quotazioni dei prodotti richiesti. Market Data System

Precondizioni: Garanzie minime: Garanzie successo: Scenario principale. 1.

2.

SISTEMA Reperisce il codice del prodotto del quale si vuole reperire la quotazione. Richiede il servizio forni tura quotazioni di mercato in tempo reale delle azioni.

3. 4. 5. 6. 7. Memorizza i dati ricevuti.

Riceve la richiesta di esecuzione del servizio. Estrae il codice del prodotto del quale si intende reperire la quotazione. Reperisce i dati della quotazione Restituisce i dati di quotazione del prodotto reperiti.

I scenario di errore. 6.1. MDS: Fallisce il reperimento dei dati relativi al prodotto specificato (codice non riconosciuto, problemi di connessione, ecc). Restituisce un mes saggio di errore. 6.2. Sistema: Termina lesecuzione della funzione con insuccesso. II scenario di errore. 7.1. Sistema: Scade il time -out associato alla fruizione del servizio. 7.2. Sistema: Termina lesecuzione della funzione con insuccesso.

UML e ingegneria del software: dalla teoria alla pratica

55

Template 19
CASO DUSO: UC_BKL_BKS_03 Descrizione: Invia messaggio dati transazione Data: 03/12/2000

Versione: 0.01.002

Durata: Priorit: Attore primario:

Invia al sistema di gestione trade un messaggio relativo alla transazione effettuata on-line dallutente. (Chiaramente la stessa verr considerata effettiva solo a seguito della relativa elaborazione effettuata nel TMS). Secondi. Elevata. TMS. Riceve il messaggio con i dati relativi alla transazione on-line eseguita dallutente. Lutente abbia impostato e confermato una transazione, i relativi dati siano disponibili ed il sistema abbia eseguito correttamente tutti i controlli. I dati della transazione non subiscono alcuna variazione. I dati della transazione vengono organizzati in un opportuno messaggio, e lo stesso viene inviato al TMS. TMS

Precondizioni:

Garanzie minime: Garanzie successo: Scenario principale.

SISTEMA Punto di estensione: Invio messaggio dati transazione Reperisce i dati della transa zione. Tra cui: codice cliente; codice prodotto acquistato; quantit e quotazione in tempo reale del prodotto; data e orario della conferma della transazione; Organizza i dati secondo il formato previsto (per esempio in base ad uno schema XML) . Pubblica il messaggio

1.

2.

3. 4.

Prende il carico il messaggio Sistema: Fallisce la pubblicazione del messaggio. Sistema: Termina lesecuzione della funzione con insuccesso.

I scenario di errore. 3.1. 3.2.

56
Template 20
CASO DUSO: UC_BKL_BKS_04 Descrizione: Durata: Priorit: Attore primario: Precondizioni: Garanzie minime: Garanzie successo: Scenario principale. 1. 2. 3. 4. 5. 6. 7. 6.1.

Capitolo 4. Modellazione avanzata degli Use Case

Reperisce dati conto corrente cliente

Data:

03/12/2000

Versione: 0.01.002

Permette di reperire le informazioni relative ai conto corrente intestati allutente. Secondi. Elevata. Accounting System (AS). Fornisce i dati relativi ai conto corrente intestati allutente. Sia disponibile il codice del cliente e questi disponga di almeno un conto corrente gestito dalla banca. La sessione avviata dal cliente rimane valida. Vengono reperiti i dati relativi ai conto corrente del cliente compresi i relativi saldi. Accounting System

SISTEMA Reperisce il codice dellutente. Richiede il servi zio fornitura dati conto corrente utente.

Riceve la richiesta di esecuzione del servizio Estrae il codice del cliente Reperisce i dati relativi ai conto corrente corredati dai rispettivi saldi Restituisce i dati relativi ai con to corrente del cliente Memorizza i dati ricevuti. AS: Fallisce il reperimento dei dati relativi ai conto corrente intestati allutente (codice cliente non riconosciuto, problemi di conne ssione, ecc). Restituisce un messa ggio di errore. Sistema: Termina lesecuzione della funzione con insuccesso.

I scenario di errore.

6.2.

II scenario di errore. 7.1. Sistema: Scade il time -out associato alla fruizione del servizio. 7.2. Sistema: Termina lesecuzione della funzione con insuccesso.

UML e ingegneria del software: dalla teoria alla pratica

57

Template 21
CASO DUSO: Invia messaggio di errore UC_BKL_BKS_05 Descrizione: Durata: Priorit: Attore primario: Data: 03/12/2000

Versione: 0.01.002

Invia al sistema di gestione delle eccezioni un messaggio con i dati relativi allanomalia verificatasi. Secondi. Elevata. Exception Management System (EMS). Riceve il messaggio con i dati relativi allanomalia verificatasi. Nel sistema si sia verificata una anomalia grave e i dati identificanti la stessa siano disponibili . I dati efferenti restano disponibili nel sistema. I dati della anomalia vengono organizzati in un opportuno messaggio, secondo il formato previsto, e lo stesso viene inviato al relativo sistema di gestione. EMS

Precondizioni: Garanzie minime: Garanzie successo:

Scenario principale. SISTEMA Extension point: Invio messaggio di errore Reperisce i dati relativi allanomalia verificatasi. Organizza i dati secondo il formato previsto (per esempio in base ad uno schema XML). Pubblica il messaggio. Prende il carico il messaggio Sistema: Fallisce la pubblicazione del messaggio. Sistema: Termina lesecuzione della funzione con insuccesso.

1. 2.

3. 4.

I scenario di errore. 3.1. 3.2.

58
Template 22
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Verifica fattore di rischio

03/12/2000

UC_BKL_BKS_07 Descrizione: Durata: Priorit: Precondizioni: Garanzie minime: Garanzie successo: Scenario principale. 1. 2. 3. 4. 4.1. 4.2. SISTEMA Reperisce i dati relativi al profilo dellutente.

Versione: 0.01.002

Verifica che il fattore di rischio associato con la transazione richiesta dal cliente rientri nei limiti previsti dal relativo profilo. Secondi. Elevata. Nel sistema siano disponibili i dati relativi alla transazione richiesta dallutente ed il relativo fattore di rischio calcolato. I dati relativi al rischio restano disponibili nel sistema. Viene eseguita la valutazione del fattore di rischio.

Calcola il valore del rischio connesso con la transazione richiesta dallutente. Verifica la compatibilit del fattore di rischio calcolato con quello impostato nel profilo utente. Restituisce la conferma del rispetto del fattore di rischio Sistema: Fattore di rischio della transazione fuori dai limiti di tolle ranza. Sistema: Termina lesecuzione restituendo esito negativo della verifica.

I scenario alternativo.

Annotazioni. 3. Per le specifiche formali relative al calcolo dei fattori di rischio si consulti il d ocumento delle business rule sezione 3.2.

Iterazioni nella costruzione del modello dei casi duso


Indipendentemente dalla modalit stabilita per descrivere il comportamento dinamico dei casi duso importante considerare che difficilmente un buon modello si ottiene con ununica iterazione. Nella pratica necessario effettuarne diverse, per dar modo agli stessi utenti di chiarirsi le idee, per riuscire a considerare situazioni meno frequenti, per raggiungere un livello qualitativo omogeneo ed elevato (tipicamente la qualit dei primi casi duso pessima), ecc. Per questi motivi, buona norma organizzare la fase di analisi dei requisiti secondo un processo iterativo e incrementale.

UML e ingegneria del software: dalla teoria alla pratica

59

La validit o meno di ricorrere ad un simile processo anche per la costruzione del modello dei casi duso, stato argomento di dibattito in diversi simposi tenuti tra lautore del presente libro e Frank Armour (coautore del testo [BIB13]), mangiando un surrogato di pizza londinese accompagnata da un discreto Chianti. In particolare, nel suo libro, Frank, illustra un processo ben definito per realizzare il modello dei casi duso basato su tre macroiterazioni: 1. initial use case description (descrizione iniziale dei casi duso), denominata cos in quanto prevede la definizione, per ogni use case, di pochi basilari elementi, come il nome, gli attori e la descrizione. Si tratta chiaramente di una fase iniziale da avviare congiuntamente allanalisi dei requisiti; 2. base use case description (descrizione base dei casi duso). La versione precedente viene estesa focalizzando lattenzione sullo scenario principale, ossia si considera il percorso ideale, trascurando per il momento flussi alternativi e di eccezione; 3. elaborated use case description (descrizione elaborata dei casi duso). Si tratta dellultima fase nella quale vengono aggiunti tutti i restanti dettagli che permettono di terminare (almeno fino alla prossima variazione dei requisiti), la descrizione dei casi duso. Quindi vengono inglobate la descrizione e gestione delle situazioni di errore, eventuali flussi alternativi, ecc. In questo processo, i veri use case (i diagrammi) risultano opzionali da utilizzarsi per una prospettiva ad alto livello.
Il ricorso a un processo di questo tipo sarebbe piuttosto opinabile in sistemi di dimensioni contenute, mentre agevola moltissimo la vita in sistemi di dimensioni medio-grandi. In particolare, permette di dare maggior tempo agli utenti per riflettere sul funzionamento dei casi duso ed eventualmente cambiare idea prima che papiri di documentazione siano realizzati: non necessario attendere la completa realizzazione del caso duso, ma possibile riesaminarli gi dalla seconda versione (base). Lo stesso team di management pu iniziare in anticipo la pianificazione dellintero processo con particolare riferimento alle varie iterazioni (con la speranza di mettere numeri non casuali nelle caselline del GANTT). Prima di definire completamente una funzionalit possibile avere un quadro pi chiaro del funzionamento dellintero sistema. Ci permette sia di aumentare il livello di consistenza delle varie funzionalit, sia di fornire abbastanza materiale al team degli architetti per avviare la progettazione del sistema.

60

Capitolo 4. Modellazione avanzata degli Use Case

A fronte di questi vantaggi esistono alcuni inconvenienti. Per esempio dover ritornare pi volte su questioni gi affrontate con i clienti (generalmente questa cosa tende a infastidirli, soprattutto quando si parla con i manager Ah, novelli Paganini), e quindi sprecare tempo per fare mente locale, riorganizzare workshop, ricontrollare il materiale, ecc. Poi, sebbene il processo realizzato in modo iterativo sia pi flessibile e aiuti ad aumentare il livello qualitativo, anche vero che apparentemente tende a richiedere pi tempo, che non sempre si ha a disposizione. Dopo lunghe argomentazioni, qualora si utilizzi un approccio basato sui casi duso come ariete da sfondamento (nel capitolo successivo ne viene presentato uno diametralmente opposto basato sugli activity diagram), si convenuto che un buon approccio potrebbe essere: 1. iniziare il processo realizzando un modello basato quasi esclusivamente sui diagrammi dei casi duso con eventualmente una descrizione molto sintetica di due, tre righe (dice nulla questo inizio?). Nellevenienza in cui si tratti di clienti con difficolt a comprendere i meccanismi della relazione di estensione, saggio avvalersi di un approccio pragmatico che consideri lutilizzo della sola relazione di inclusione; 2. realizzare una prima descrizione che contempli, ovviamente il main scenario, gli attori, le precondizioni, le varie garanzie e i flussi alternativi e di eccezioni pi semplici ed evidenti; 3. concludere il tutto incorporando suggerimenti provenienti dal team degli architetti, dalla revisione con i clienti, ecc. Dopo la fase iniziale, qualora si verifichi la necessit, necessario ristrutturare i diagrammi dei casi duso. Nel caso in cui si decida di ricorrere a processi iterativi e incrementali anche per lanalisi dei requisiti, utile prevedere una serie di informazioni supplementari, da associare ai vari manufatti prodotti, necessarie per tener traccia della relativa evoluzione. Queste informazioni dovrebbero riportare le varie versioni dei manufatti (in questo caso use case), gli autori, la data di prevista o avvenuta consegna, la descrizione e cos via. Chiaramente non c alcuna necessit di specificarle per ogni singolo caso duso (singolo ellisse), ma sufficiente riportarle solo per le macrofunzionalit (in altre parole al livello di use case diagram). Con riferimento allesempio del sistema di banking online, sarebbe utile visualizzare levoluzione dello use case diagram acquisto share on-line, mentre sarebbero di scarso interesse per tutti i singoli casi duso coinvolti verifica fattore di rischio, Invia messaggio di

UML e ingegneria del software: dalla teoria alla pratica

61

errore, e cos via. Ovviamente le informazioni specificate per lo use case generale si riferiscono anche a tutti i casi duso di cui composto. Come suggerito anche dal processo della Rational Software Corporation (RUP Rational Unified Process) consigliabile riportare, per ogni use case diagram, un template come il seguente:

Template 23
n. Iterazione 1A 1A 1B Autore LVT RV LVT Consegna 10 II 2001 12 II 2001 20 II 2001 Descrizione Initial draft Diagramma e descrizione Base Definizione del main scenario Elaborated Inclusione degli scenari alternativi e di errore. Revisione Aggiunta feed back utente

1B

AR

22 II 2001

Probabilmente potrebbe risultare altrettanto conveniente disporre di un altro template, in qualche modo speculare al primo, collocato alla fine della descrizione del comportamento dinamico di ogni use case diagram. Lo scopo di ospitare, in un sol punto, eventuali considerazioni del personale coinvolto nello sviluppo e nel controllo della qualit del modello. Sebbene sia possibile specificare eventuali considerazioni anche nel modulo utilizzato per descrivere il comportamento dinamico di ogni singolo caso duso, probabilmente comodo disporre anche di uno pi generale. Ci consente di raggruppare le varie note in un solo punto evitando di doverle cercare per tutto il progetto. Un altro vantaggio consiste nella semplificazione della gestione dello stato di avanzamento delle osservazioni. Si supponga che durante il processo di revisione dei casi duso nascano delle perplessit o suggerimenti: le relative descrizioni andrebbero riportate nel template conclusivo di ogni use case diagram. Pertanto possibile verificare se ci siano o meno quesiti in attesa di risposta, accedendo direttamente a questi template. Template 24
n. 1 Osservazione Come comportarsi nel caso x,y,z Autore R.V. Stato Risolto. Consultare punto a.

62

Capitolo 4. Modellazione avanzata degli Use Case

La sicurezza nel modello dei casi duso


Prima di procedere con lesempio conclusivo del capitolo, si ritenuto utile esaminare largomento relativo allincorporazione della sicurezza nel modello dei casi duso. In primo luogo va ricordato che si tratta di requisiti non funzionali che come tali costituiscono una parte, anche molto importante, dellapposito manufatto (tale manufatto presentato al capitolo successivo). Inoltre si tratta di un vincolo che, tipicamente, si applica a tutti i sistemi e quindi alla stragrande maggioranza di casi duso. Ora si potrebbe utilizzare lapproccio pi tradizionale, ossia includere i relativi casi duso in tutti gli use case che devono applicare i requisiti di sicurezza. Esempi di questi use case potrebbero essere autenticazione utente (serve per accertarsi che lutente sia effettivamente quello che dichiara di essere), autorizzazione ad eseguire la funzionalit selezionate, autorizzazione a trattare i dati richiesti, scrittura di appositi log per tener traccia della navigazione dellutente, ecc. Per ci che concerne lautenticazione, da notare che il problema si pone anche per lo scambio di messaggio con altri sistemi. Per quanto attiene alle autorizzazioni evidente che se un utente viene autorizzato a espletare un servizio (per esempio Visualizzazione estratto conto) ci non significa che lo potr richiedere per qualsiasi insieme di dati (per esempio estratto conto di unaltra persona). Questo approccio, sebbene molto semplice, pone una serie di svantaggi: altera la logica business mostrata dai vari diagrammi dei casi duso. Includendo in un apposito use case, quelli relativi allautenticazione e/o autorizzazione, le relazioni con gli altri inclusi di carattere business tendono a diventare automaticamente degli extend: vengono eseguiti solo se si ottiene lautorizzazione; la descrizione dei casi duso viene inutilmente complicata con dettagli gi conosciuti al livello dellintero sistema.

Il consiglio pertanto consiste nel ricorrere alla seguente tecnica: 1. riportare gli use case della sicurezza isolati dagli altri. Ci molto utile per specificare particolari comportamenti/requisiti. Per esempio, dopo che lutente stato riconosciuto, si potrebbe richiedere di verificare se il relativo profilo sia stato bloccato, oppure se la relativa password sia scaduta, ecc. 2. redigere la sezione del manufatto dei requisiti non funzionali (o eventualmente un apposito documento) descrivendo dettagliatamente anche il comportamento da applicare ai diversi casi duso.

UML e ingegneria del software: dalla teoria alla pratica 3. eventualmente nelle precondizioni dei vari use case citare le clausole standard: lutente stato riconosciuto (autenticato) e autorizzato a eseguire il servizio (da notare che la seconda clausola implica la prima) e nella descrizione del comportamento dinamico, far riferimento alla specifiche sezioni menzionate nel punto precedente.

63

Per esempio in un sistema Internet/Intranet di unorganizzazione potrebbe essere presente il vincolo che gli utenti possano accedere unicamente ai dati relativi al proprio dipartimento. Questa restrizione si potrebbe suddividere in due sezioni: reperimento: i dati da mostrare allutente devono essere filtrati in base al relativo dipartimento di appartenenza; inserimento: tutti i dati devono riportare linformazione relativa al dipartimento di appartenenza. Nel documento NFR potrebbe essere opportuno riportare queste due sezioni (ovviamente con maggiori dettagli) e quindi riferirle nei casi duso in ogni punto in cui si effettui una ricerca o si aggiorni il database.

e-commerce: un esempio
In questo paragrafo viene presentata unampia sezione della use case view di un sistema del tutto originale: sito e-commerce. Visto che stato citato abbondantemente negli esempi, si deciso di presentarlo finalmente in maniera pi organica. Quella che viene fornita evidentemente una versione iniziale, uno scheletro facilmente espandibile per la descrizione di scenari reali (la realt sempre pi complessa di quanto riportato nei libri). Per esempio non sono presi in considerazione servizi di supervisione, di risoluzioni anomalie, statistiche, ecc. Tipicamente, sistemi di questo tipo possono essere scomposti almeno in tre sottosistemi: il sito Internet ovviamente, il legacy system, e il layer di interfacciamento (wrapper) necessario per consentire ai due precedenti sistemi di interagire. Molto raramente accade che unazienda decida di lanciarsi nel commercio elettronico partendo da zero, ossia avendo contestualmente la necessit di allestire il sito Internet e la propria infrastruttura informatica gestionale. Queste rarissime occasioni costituiscono il sogno s proprio di sogno si deve parlare dei tecnici in quanto consentono di realizzare il tutto attraverso tecnologie omogenee e moderne ossia permettono di far giocare i tecnici con nuovi giocattoli e soprattutto evitano tanti problemi di connessione che si generano tra sistemi costruiti con tecnologie eterogenee.

64

Capitolo 4. Modellazione avanzata degli Use Case

Spesso i sistemi gestionali presenti presso i clienti (legacy system) risultano privi di meccanismi di interfacciamento con altri sistemi automatizzati, oppure risultano dotati di incomprensibili modalit di funzionamento con le quali, ahim, necessario interagire. Per esempio pu capitare il caso di utilizzare sistemi che prevedano la quotazione degli articoli inseriti in un ordine solo dopo la conferma dellordine stesso. Come dire prima si effettua lordine e poi si viene a conoscenza del relativo importo. Il caso decisamente pi frequente rappresentato da aziende di dimensioni mediograndi, gi dotate di ben collaudati sistemi di gestione dei propri processi interni (si tratta, tipicamente, di sistemi funzionanti su architetture hardware del tipo Mainframe, IBM AS400, IBM AIX, HP UX, Bull, ecc.), che decidono di sfruttare i vantaggi offerti dal commercio elettronico. In tutti questi casi necessario realizzare, oltre al sito Internet, anche il famoso sistema wrapper in grado di realizzare la comunicazione con il legacy system. Chiaramente lungi dalla volont delle organizzazioni introdurre nuovi sistemi con la necessit di replicare i processi manuali di manutenzione dati. Per esempio ovvio che si cerchi di evitare linserimento dei dati efferenti nuovi prodotti dapprima nel legacy system e poi nel sistema per il commercio elettronico, cos come non si desidera reinserire manualmente nel sistema di legacy ordini effettuati online. Si esige chiaramente che i dati presenti in un sistema vengano replicati automaticamente negli altri. I sistemi di wrapper offrono un insieme di servizi prestabilito, ottenibili essenzialmente da quelli disponibili nel legacy system, presentandoli al mondo esterno attraverso opportune interfacce sfruttanti tecnologie moderne (CORBA, RMI, server socket, ecc.). Si Figura 12 Schema di un sistema di wrapping.
Interfacce CORBA/RMI/COM+ Protocollo proprietario

X1

Legacy Wrapper System


Xn

oggetti/componenti java/C++/ ...

stored procedure routine RPG ...

UML e ingegneria del software: dalla teoria alla pratica

65

tratta di un layer proxy in grado di offrire una percezione diversa e decisamente pi moderna di un sistema di legacy. In altre parole sono sistemi paragonabili ai politici del Belpaese: facce nuove che celano vecchie logiche. Nel caso presentato si considerata unicamente lipotesi semplificata di sistemi che necessitino solo di uno scambio asincrono di informazioni. Nella realt, spesso si verifica contestualmente la necessit di uno scambio sincrono e asincrono di informazioni tra sistemi. Si supponga per esempio di dover realizzare il sito Internet del legacy system in grado di quotare gli ordini solo dopo averne ricevuto conferma. In tal caso il sistema Internet dovrebbe inviare i dati dellordine e quindi attendere la risposta dellelaborazione avvenuta nel legacy system al fine di visualizzare allutente limporto dellordine effettuato (Sembra assurdo vero? Non si sente la vocina interna dellesperienza sbraitare?). Figura 13 Macro funzioni del sistema oggetto di studio.

Gestione carrello della spesa

Consulta catalogo

Consulta offerte

Ricerca articolo

Effettua ordine

Utente

Spedizione ordini

Credits Authority

Ricezione esito elaborazione ordini

Effettua sottoscrizione

Aggiorna profilo

Legacy System

Invia dati catalogo

66

Capitolo 4. Modellazione avanzata degli Use Case

Prima di procedere con lillustrazione dei vari diagrammi, risulta molto utile riportare lelenco di tutti gli attori previsti con le relative descrizioni, come illustrato nel capitolo precedente (modello per la documentazione degli attori). Si tratta di un semplice esercizio demandato ai lettori. Non infrequente anche lillustrazione di un primo use case diagram con i vari macroservizi offerti dal sistema. Lobiettivo appunto mostrare le principali funzioni, senza per fornirne alcun dettaglio: una sorta di indice grafico. Volendo possibile paragonarlo al diagramma Top Level previsto dalla metodologia DFD. Ovviamente si tratta di un solo livello di decomposizione: guai altrimenti; si rischierebbe di cadere nella trappola della decomposizione funzionale. Nel sistema oggetto di studio la relativa struttura dovrebbe risultare simile a quella riportata nella fig. 13. Si cominci con il considerare le prime due funzionalit basilari fornite dal sito Internet: registrazione di un nuovo utente (effettua sottoscrizione) e aggiornamento del relativo profilo (aggiorna profilo). Template 25
n. Iterazione 1 Autore LVT Consegna 10 II 2001 Initial draft Descrizione

Figura 14 Servizi di sottoscrizione e aggiornamento profilo utente.

Effettua sottoscrizione

extend

Invia conferma e password via e-mail


include

Reperisce offerte

Utente
Validazione utente

Aggiorna profilo

UML e ingegneria del software: dalla teoria alla pratica

67

Template 26
CASO DUSO: Effettua sottoscrizione. UC_ECMMRC01 Descrizione: Durata: Priorit: Attore primario: Data: 01/II/2001

Versione: 0.00.002

Consente agli utenti di registrarsi al fine di poter effettuare ordini di acquisto on-line presso il sito. Minuti. Elevata. Utente. Ha interesse di registrarsi presso il sito per poter fruire dei servizi offerti dal sistema. Lutente dispone di una connessione Internet. Lutente non viene registrato. Il sistem a visualizza un appropriato messaggio di errore. Lutente viene registrato correttamente ed il sistema provvede ad inviargli le-mail di conferma sottoscr izione. Lutente richiede esplicitamente di registrarsi. UTENTE SISTEMA

Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1. 2. 3. 4. 5. 6. 7. 8.

Esegue esplicitamente la funzione di registrazione presso il sito. Visualizza gli accordi commerciali (il contratto) e chiede conferma a procedere Conferma la propria volont di procedere. Visualizza la pagin a con la richiesta dati dellutente (profilo) Imposta i proprio dati e quindi e ffettua un click sul bottone procedi. Verifica i dati dellutente. Genera password iniziale Punto di estensione: Invia conferma e password via e-mail Condizione Lutente confermi la registrazione Memorizza i dati permanentemente nel database del sistema Visualizza messaggio di avvenuta registrazione.

9. 10.

68
Template 27

Capitolo 4. Modellazione avanzata degli Use Case

Scenario alternativo: I dati impostati dallutente non risultano corretti. 6.1. 6.2. Sistema: Visualizza un messaggio indicante i dati ritenuti non corretti. Sistema: Riprende dal punto 4.

Scenario di errore: Lutente richiede di terminare anticipamene il servizio. Punti: 3, 5. 3.1. Sistema: Visualizza apposito messaggio. 5.2. Sistema: Termina lesecuzione dello use case con insuccesso. Scenario di errore: Tentativo di invio e-mail fallito. 8.1 Sistema: Comunica momentanea non disponibilit del sist ema. 8.2. 8.3. Sistema: Esegue procedura di notifica situazione anomala Sistema: Termina lesecuzione dello use case con insuccesso.

Annotazioni. 6 Per quanto concerne i dati da impostare fa riferimento al prototipo di interfaccia utente XX.YY. I dati relativi la registrazione di un utente rimangono confinati nel database del sito fino alleffettuazione del primo ordine. Il relativo invio al sistema di legacy avviene associandoli ai dati relativi al primo ordine effettuato dellutente. A questo punto lutente viene memorizzato anche nel sistema di back office operante presso lorganizzazione e quindi lutente ne diviene un cliente a tutti gli effetti.

Un primo elemento di riflessione potrebbe essere relativo alla necessit di dettagliare nei casi duso i campi appartenenti al profilo utente. Ebbene nella pratica, purtroppo, risulta fondamentale stabilire anche dettagli di questo tipo. A dire il vero essi dovrebbero essere specificati nel modello del business attraverso opportuno diagramma delle classi e nel modello della GUI. Eventualmente, queste informazioni andrebbero inserite nel template illustrato nel capitolo successivo (Modello per le interfacce), nel quale possibile specificare quali dati sono obbligatori e quali no. Riportare questi dettagli comunque permette di evitare continue richieste di variazione del disegno della pagina HTML dipendenti dal personaggio dellorganizzazione del cliente che la analizzi. Poich per comunque diritto del cliente variare le specifiche e quindi anche i campi da visualizzare, nelleventualit che ci accada possibile dimostrare, prove alla mano, che si tratta di un vero e proprio change request e come tale implica specifiche conseguenze come per esempio la dilatazione dei tempi di consegna. Un secondo motivo di riflessione potrebbe scaturire dallanalisi del comportamento del sistema in caso di gravi anomalie quali per esempio impossibilit di inviare e-mail o di

UML e ingegneria del software: dalla teoria alla pratica

69

memorizzare i dati del nuovo cliente (questultima non stata neanche citata). In tal caso prevista una generica funzione di notifica situazione anomala. Verosimilmente questa funzione dovrebbe prevedere laggiornamento di un apposito file di log e linvio di messaggi a un operatore umano (quale per esempio webmaster) al fine di avvisarlo dellanomalia. Questa considerazione potrebbe suggerire di inserire tale operatore nel ruolo di attore. Si deciso di non visualizzare questi aspetti sia perch attinenti allarea tecnica, sia perch si tratta di comportamenti che dovrebbero essere dichiarati in un apposito documento e quindi applicati consistentemente ogniqualvolta occorra un problema tecnico. La considerazione finale relativa alla comunicazione descritta tra lutente e il sistema. Come si pu facilmente notare sia nel precedente diagramma, sia in quelli mostrati di seguito, si tratta di scambi di messaggi interattivi e prolungati nel tempo.

In base alle direttive formali dello UML le comunicazioni tra attori e sistema dovrebbero essere modellate, quanto pi possibile, in modo asincrono. Logica conseguenza sarebbe che ogni diversa tipologia di messaggio originata da un attore dovrebbe avviare uno specifico caso duso. In questo contesto si deciso di non ricorrere a tale approccio perch avrebbe finito per complicare notevolmente la fruizione dei requisiti senza apportare alcun reale vantaggio.

Considerando la descrizione nel precedente template e volendo aderire il pi possibile alle direttive formali, sarebbe stato necessario riportare un caso duso atto a inviare allutente le informazioni relative gli accordi commerciali (punto 2), un altro per ricevere il relativo feedback (punto 3), un altro ancora per la richiesta dei dati profilo utente (punto 4), un altro per lacquisizione dei relativi dati (punto 6) e cos via. Come al solito il premio per il diagramma pi formale non ancora stato istituito, mentre lo stress generato da problemi di comunicazione con il cliente pi che reale. Come si pu notare, se il presente caso duso di template 28 termina con insuccesso non viene preso alcun provvedimento, in quanto si tratta di una responsabilit dello use case chiamante.

70
Template 28
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Reperisce offerte

01/II/2001

UC_ECMMRC03 Descrizione: Durata: Priorit: Precondizioni: Garanzie di fallimento: Garanzie di successo:

Versione: 0.00.001

Verifica se siano presenti delle offerte commerciali valide da comunicare al cliente. Secondo. Elevata. Nessuna offerte viene reperta. Vengono reperite le offerte commerciali preparate secondo un opportuno formato (per esempio pagine HTML).

Scenario principale. SISTEMA 1. Verifica se nel sistema sono presenti offerte valide. 2. 3. Preleva i dati relativi le offerte commerciali Impagina i dati offerte in funzione al template specificato.

Scenario alternativo: Nel sistema non sono presenti offerte valide. 1.1. Sistema: Termina lesecuzione senza caricare alcuna offerta.

Template 29
CASO DUSO: Reperisce offerte UC_ECMMRC03 Descrizione: Durata: Priorit: Precondizioni: Garanzie di fallimento: Garanzie di successo: Data: 01/II/2001

Versione: 0.00.001

Verifica se siano presenti delle offerte commerciali valide da comunicare al cliente. Secondo. Elevata. Nessuna offerte viene reperta. Vengono reperite le offerte commerciali preparate secondo un opportuno formato (per esempio pagine HTML).

Scenario principale. SISTEMA 1. Verifica se nel sistema sono presenti offerte valide. 2. 3. Preleva i dati relativi le offerte commerciali Impagina i dati offerte in funzione al template specificato.

Scenario alternativo: Nel sistema non sono presenti offerte valide. 1.1. Sistema: Termina lesecuzione senza caricare alcuna offerta.

UML e ingegneria del software: dalla teoria alla pratica

71

Questo use case appartiene alla categoria di quelli che, dal punto di vista del comportamento dinamico, potrebbero essere tranquillamente omessi dal relativo diagramma dei casi duso: sarebbe sufficiente citare un paio di righe nella descrizione del caso duso invocante. Durante la realizzazione della use case view si incontrano molti esempi di questo tipo.

Nel dubbio se evidenziare o meno alcuni casi duso, bisogna prestare attenzione a non commettere lerrore di pensare in termini implementativi. Ci che dal punto di vista tecnico potrebbe essere poco rilevante, perch magari richiederebbe solo alcune linee di codice, dal punto di vista del cliente, potrebbe avere unimportanza elevata. Questo il caso dello use case in questione. Il cliente interessato a evidenziare che lutente, allatto della registrazione, venga informato di eventuali offerte promozionali. Bisogna sempre tendere al giusto compromesso. Se da un lato mostrare lorganizzazione di alcune funzioni nei diagrammi dei casi duso ne pu facilitare la comprensione, allo stesso tempo, eccedendo nel dettaglio si corre unicamente il rischio di generare diagrammi eccessivamente complicati e di non facile comprensione. Ancora pi grave, si corre il rischio di iniziare a disegnare il sistema (per decomposizione funzionale) con gli strumenti errati e senza tener presenti aspetti molto importanti non ancora analizzati/disponibili.

Dallesame della descrizione dello use case riportato in template 30 possibile constatare che non si menziona mai esplicitamente il numero massimo di fallimenti consecutivi consentiti allutente. Si tratta di un buon espediente sia per non vincolare la funzione stessa, sia per limitare il lavoro le correzioni da svolgere in caso di variazioni. Il dettaglio di queste informazioni andrebbe riportato nel documento delle regole di business.

72
Template 30
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Validazione utente

01/II/2001

UC_ECMMRC04 Descrizione: Durata: Priorit: Precondizioni: Garanzie di fallimento:

Versione: 0.00.001

Si occupa di eseguire le funzioni necessarie per riconoscere lutente connesso. Minuti. Elevata. Lutente non viene riconosciuto e quindi non viene abilitato a fruire delle funzioni ritenute sensibili per il sistema. Lutente viene riconosciuto e quindi viene create la relativa sessione. Lutente esegue la procedura di log-in.

Garanzie di successo: Avvio: Scenario principale.

UTENTE SISTEMA Segmento di estensione: valida utente 1. Verifica che il numero di tentativi effettuati dal cliente sia inferiore a quello previsto. Visualizza la finestra con la richiesta della login e password. Imposta login e password. Verifica che la coppia di valori (login, password) individui un cliente nel database del sistema Verifica che il profilo utente non sia stato bloccato. Verifica che la password dellutente non sia scaduta Trasferisce in memoria i dati del clie nte.

2. 3. 4.

5. 6. 7.

Scenario alternativo: Verifica login e password fallita. 3.1. Sistema: Riprende dal punto 1. Scenario di errore: Tentativi effettuati pari al numero massimo previsto. 1.1. Sistema: Termina lesecuzione dello use case con insuccesso. Scenario di errore: Lutente decide di non impostare login e password. 3.1. Sistema: Termina lesecuzione dello use case con insuccesso. Scenario di errore: Profilo utente bloccato. 5.1. Sistema: Termina lesecuzione dello use case con insuccesso. Scenario di errore: Password scaduta. 6.1. Sistema: Termina lesecuzione dello use case con insuccesso. Annotazioni. 6.1. Cosa fare nel caso che la password dellutente sia scaduta? non autorizzarlo oppure forzarlo a cambiare password?. Semplicemente

UML e ingegneria del software: dalla teoria alla pratica

73

Template 31
CASO DUSO: Aggiorna profilo UC_ECMMRC05 Descrizione: Durata: Priorit: Attore primario: Data: 01/II/2001

Versione: 0.00.001

Permette ad un utente precedentemente registrato di modificare i dati efferenti il proprio profilo. Minuti. Media. Utente. Ha interesse ad aggiornare i dati efferenti il proprio profilo. Lutente registrato nel sistema (esista il relativo prof ilo) e sia stato autorizzato ad eseguire il servizio. Il profilo dellutente non viene aggiornato. Le modifiche apportate dallutente al proprio profilo vengono memorizzate permanentemente nel sistema. Lutente richiede di eseguire aggiornamento del proprio profilo. la funzione di

Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1.

UTENTE Lutente richiede esplicitamente di eseguire la funzione di aggiornamento profilo.

SISTEMA

2. 3. 4. 5. Modifica i dati del pr opri profilo, eventualmente anche la password

Visualizzazione della pagina profilo utente con i relativi dati impostati

Verifica i dati impostati dallutente. Aggiorna il profilo dellutente

Scenario alternativo: Utente annulla la funzione di aggiornamento del proprio profilo. 3.1. Sistema: Termina lesecuzione dello use case con insuccesso. Scenario alternativo: Dati impostati non corretti. 5.1. Sistema: Visualizza un messaggio con indicati i dati ritenuti non corre tti. 5.2. Sistema: Riprende lesecuzione dal punto 3.

Dallanalisi della descrizione del comportamento dinamico del presente caso duso emerge chiaramente che esiste una sezione comune con lo use case di registrazione utente. Ci potrebbe spingere a cercare di strutturare ulteriormente i casi duso per mezzo di relazioni di generalizzazione. Bench possibile, probabilmente, in questo caso non opportuno. Si ricordi che lobiettivo di questa fase catturare i requisiti del cliente, capire

74

Capitolo 4. Modellazione avanzata degli Use Case

cosa dovr fare il sistema e non disegnare lo stesso. Eventuali mancanze di astrazione presenti in questa fase non incidono assolutamente sulle restanti e tantomeno sul disegno del sistema.

Template 32
n. 1 Osservazione Autore Pending Stato

Necessario decidere il comport a- RV mento da adottare qualora la password dellutente sia scaduta. (UC_ECMMRC04)

Da notare che, sebbene non specificato esplicitamente, la modalit con cui i casi duso sono raggruppati e presentati, ne riflette lorganizzazione in package. Un altro insieme di use case presi in esami quello relativo al reperimento delle informazioni relative agli articoli venduti nel sito per il commercio elettronico. Come evidenziato dal diagramma riportato nella descrizione dei casi duso, le funzioni di consultazione sono ritenute non sensibili per il sistema e quindi fruibili da tutti gli utenti anche da quelli non registrati. Chiaramente, qualora lutente manifesti interesse per uno specifico articolo e desideri aggiungerlo nel proprio carrello della spesa, in quel caso si entrerebbe nellinsieme delle funzionalit ad accesso limitato ai soli utenti registrati. Questo passo si renderebbe necessario anche per reperire la specifica istanza (quella appartenente al cliente) del carrello della spesa in cui inserire larticolo. Si tratta ovviamente di regole richieste dal committente del sito, ma nulla vieta di averne diverse.

Template 33

n. Iterazione 1

Autore LVT

Consegna 12 II 2001 Initial draft

Descrizione

UML e ingegneria del software: dalla teoria alla pratica

75

Template 34
CASO DUSO: Consulta catalogo UC_ECMMRC10 Descrizione: Data: 05/II/2001

Versione: 0.00.001

Permette ad un utente di consultare i prodotti mercanteggiati nel sito con modalit sia sequenziale, simile a quella con cui si sfogliano i cataloghi cartacei, sia ipertestuale (navigazione basata sui link presenti nelle varie pagine HTML). Nelleventualit che un utente fosse interessato ad uno specifico articolo, la funzione ne consente inserimento nel carrello. Minuti. Elevata. Utente. Ha interesse nel ricevere informazioni relative al catalogo degli articoli. Disponibilit del catalogo degli articoli. Nessun dato viene alterato. Lutente naviga allinterno del catalogo ed eventualmente aggiunge specifici articoli nel proprio carrello della spesa. Lutente richiede di consultare il catalogo degli art icoli. SISTEMA

Durata: Priorit: Attore primario:

Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1. 2. 3. 4. 5.

UTENTE Richiede esplicitamente di eseguire la funzione di consultazione articoli. Seleziona la pagina da esaminare.

Visualizza la pagina indice del catalogo. Visualizza la pagina richiesta. Prosegue nella navigazione scorre ndo (avanti e indietro) le varie pagine, seguendo i link presenti nella stessa, tornando allindice generale, oppure terminando la consultazione. Visualizzala pagina richiesta dallutente SISTEMA

6.

Scenario alternativo: Utente seleziona un articolo specifico. UTENTE 5.1. 5.2. 5.3. 5.4. Seleziona un articolo specifico.

Visualizza la pagina di dettaglio dellarticolo selezionato. Seleziona lopzione di inserimento del prodotto nel carrello della spesa. Punto di estensione: aggiungi articolo nel carrello della spesa. Condizione: lutente decide di aggiungere larticolo al proprio carrello

76

Capitolo 4. Modellazione avanzata degli Use Case

Figura 15 Use case per il reperimento delle informazioni.


Consulta catalogo
extend

Consulta offerte

extend

Aggiungi articolo al carrello della spesa

Utente Ricerca articolo


extend

Una funzionalit che potrebbe essere interessante aggiungere quella relativa alle segnalazioni di offerte: un utente potrebbe indicare uno specifico articolo come oggetto di proprio interesse e quindi richiedere al sistema di ricevere una comunicazione qualora, nellarco di tempo specificato, larticolo sia oggetto di specifiche offerte commerciali.

Template 35
CASO DUSO: UC_ECMMRC11 Descrizione: Durata: Priorit: Precondizioni: Aggiungi articolo al carrello della spesa Data: 06/II/2001

Versione: 0.00.003

Permette di aggiungere larticolo selezionato al carrello della spesa. Secondi. Elevata. Lutente sia stato autenticato dal sistema, e abbia selezionato larticolo che intende aggiungere al relativo carrello della spesa. Nessuna modifica viene apportata al carrello della spesa. Larticolo sele zionato dallutente viene correttamente inserito nel relativo carrello della spesa. Lutente richiede esplicitamente di inserire larticolo selezionato nel relativo carrello della spesa.

Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1. 2. 3.

SISTEMA Reperisce il carrello della spesa dellutente Ottiene i dati salienti dellarticolo (compreso il prezzo) Memorizza i dati dellarticolo nel carrello della spesa.

Scenario alternativo: Il cliente non dispone di un carrello della spesa. 1.1. Il sistema genera una nuova istanza vuota del carrello.

UML e ingegneria del software: dalla teoria alla pratica

77

Template 36
CASO DUSO: Consulta offerte UC_ECMMRC12 Descrizione: Data: 06/II/2001

Versione: 0.00.001

Durata: Priorit: Attore primario:

Permette allutente di consultare eventuali offerte commerciali proposte nel sito ed eventualmente di inserire gli articoli oggetto di offerta nel carrello della spesa. Minuti. Elevata. Utente. Ha interesse nel ricevere informazioni relative ad eventuali prodotti in offerta. Siano presenti le tabelle relative alle promozioni commerciali. Il carrello della spesa del cliente non viene modific ato. Lutente fruisce della lista degli articoli in offerta ed eventualmente ne aggiunge alcuni nel proprio carrello della spesa. Lutente richiede di consultare la lista degli articoli in offerta. SISTEMA

Precondizioni: Garanzie di fallimento: Garanzie di successo:

Avvio:

Scenario principale. UTENTE 1. Richiede esplicitamente di consultare le offerte commerciali disponibili. 2. 3. 4. Naviga le pagine delle offerte, eventualmente segue i link presenti e/o seleziona determinati articoli, oppure decidere di terminare la consultazione.

Reperisce la lista degli articoli in o fferta Visualizza la pagina commerciali valide. con le offerte

Scenario alternativo: Offerte commerciali non di sponibili. SISTEMA 2.1. 2.2. Non sono presenti offerte commerciali (oppure quelle presenti non soddisfano i criteri di applicabilit, come per esempio periodo scaduto). Visualizza apposito messaggio e conclude la funzione.

Scenario alternativo: Lutente seleziona un articolo specifico. UTENTE SISTEMA 4.1. 4.2. 4.3. 4.4. Seleziona un articolo specifico. Visualizza la pagina di dettaglio dellarticolo selezionato. Seleziona lopzione di inserimento dellarticolo nel carrello della sp esaPunto di estensione: aggiungi articolo nel carrello della spesa. Condizione: lutente decide di aggiungere larticolo al proprio carrello

78
Template 37
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Ricerca articolo

06/II/2001

UC_ECMMRC13 Descrizione: Durata: Priorit: Attore primario:

Versione: 0.00.001

Permette allutente di reperire uno specifico articolo ed eventualmente inserirlo nel proprio carrello della spesa. Minuti. Elevata. Utente. Ha interesse nel reperire informazioni relative a specifici articoli. Il catalogo degli articoli non sia vuoto. Il carrello della spesa del cliente non viene modific ato. Lutente reperisce larticolo desiderato ed eventualmente lo inserisce nel proprio carrello della spesa. Lutente richiede di eseguire la funzione di reperimento articoli.

Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1. 2. 3.

UTENTE Richiede esplicitamente lesecuzi one della funzione di reperimento articoli

SISTEMA

Visualizza la pagina per la richiesta dei criteri di ricerca. Imposta il criterio di ricerca desiderato (codice, descrizione, categoria, limiti di prezzo, ecc.). Reperisce larticolo risp ondente al criterio impostato dal cliente. Visualizza la pagina con lelenco degli articoli rispondenti ai dati forniti dallutente. UTENTE Seleziona l opzione di inserimento dellarticolo nel carrello della sp esa. SISTEMA

4. 5.

Scenario alternativo: Richiede linserimento dellarticolo nel carrello della spesa. 6. 7.

Punto di estensione: aggiungi articolo nel carrello della spesa. Condizione: lutente decide di aggiungere larticolo al proprio carrello

Scenario di errore: Lutente termina lesecuzio ne della funzione. UTENTE SISTEMA 3.1. Non imposta alcun criterio e richiede di terminare lesecuzione della funzione. Termina lesecuzione della funzione.

3.2.

Scenario di errore: Nessun articolo risulta rispondente alla chiavi di ricerca. SISTEMA 4.1. 4.2. Non sono presenti nel catalogo articoli rispondenti al criterio impostato dallutente. Termina lesecuzione dello use case con errore.

UML e ingegneria del software: dalla teoria alla pratica

79

Template 38
n. Osservazione Autore Stato

Template 39
n. Iterazione 1A Autore LVT Consegna 10 II 2001 Initial draft Descrizione

Figura 16 Use case gestione carrello della spesa.

Verifica carrello della spesa


include

Gestione carrello della spesa

Rimuove articolo dal carrello della spesa Svuota carrello

Aggiorna quantit

Utente

80
Template 40
CASO DUSO: UC_ECMMRC17 Descrizione:

Capitolo 4. Modellazione avanzata degli Use Case

Gestione carrello della Spesa

Data:

08/II/2001

Versione: 0.00.003

Durata: Priorit: Attore primario:

Permette allutente di gestire lelenco degli articoli inseriti nel relativo carrello della spesa, rimovendone alcune, modificando le quantit di altri, e cos via. Minuti. Elevata. Utente. Ha interesse nel gestire le informazioni efferenti il proprio carrello della spesa. Lutente sia stato autorizzato ad eseguire il servizio e disponga di unistanza del carrello della spesa. Il carrello della spesa non viene modificato. Lutente apporta le modifiche desiderate ai dati relativi agli articoli presenti nel relativo carrello della spesa. Lutente richiede di eseguire la funzione di gestione del carrello della spesa.

Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1.

UTENTE Lutente richiede esplicitamente lesecuzione del servizio di gestione del carrello della spesa.

SISTEMA

2. 3. 4. 5. Punto astratto: Modifica dati carrello della sp esa

Reperisce il carrello della spesa relativo allutente. Include(verifica carrello della spesa) Visualizza la pagina con i dati del carrello della spesa.

Scenario di errore: Carrello della spesa dellutente vuoto. 2.1. 2.2. Visualizza apposito messaggio e conclude la funzione. Termina lesecuzione dello use case con insuccesso.

UML e ingegneria del software: dalla teoria alla pratica

81

Template 41
CASO DUSO: Verifica carrello della spesa UC_ECMMRC18 Descrizione: Data: 08/II/2001

Versione: 0.00.003

Durata: Priorit: Precondizioni: Garanzie di fallimento: Garanzie di successo: Scenario principale. SISTEMA 1. 2. 3. 4.

Esamina il carrello della spesa al fine di verificare se vi siano variazioni sostanziali nei dati impostati (prezzi degli articoli variati, artico li non pi disponibili, offerte scadute ecc.). Minuti. Elevata. Il carrello della spesa del cliente disponibile e vi sono degli articoli inseriti. Il carrello della spesa del cliente non viene modific ato. Il carrello della spesa viene analizzato ed eventuali incoerenze vengono opportunamente segnalate.

Preleva lelenco degli articoli inseriti nel carrello della spesa. Verifica che tutti gli articoli siano ancora disponibili nel catalogo. Reperisce i dati di tutti gli articoli ancora disponibili. Verifica che il prezzo degli articoli non sia variato nellintervallo di tempo che va dal momento in cui larticolo stato in serito nel carrello della spesa al momento attuale. Verifica che le eventuali offerte presenti non siano scadute. Verifica che per gli articoli inseriti non siano disponibili eventuali offerte non considerate.

5. 6.

Scenario alternativo: Presenti articoli nel carrello della spesa rimossi dal catal ogo. 2.1. Ognuno di essi viene segnalato ed un opportuno messaggio di non disponibilit viene aggiunto. Scenario alternativo: Il prezzo di alcuni articoli variato. 4.1. Mostra il nuovo prezzo ed aggiunge opportuno messaggio informativo. Scenario alternativo: Alcune offerte presenti allatto dellinserimento dellarticolo nel carrello della spesa sono cessate. 5.1. Mostra il prezzo ordinario ed aggiunge opportuno messaggio informativo. Scenario alte rnativo: Per alcuni articoli disponibile unofferta non disponibile allatto dellinserimento dellarticolo nel carrello della spesa. 6.1. Aggiunge messaggio di segnalazione.

82
Template 42
CASO DUSO: UC_ECMMRC19 Descrizione: Durata: Priorit: Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1. 2. 3. 4. 5.

Capitolo 4. Modellazione avanzata degli Use Case

Rimuove articolo dal carrello della spesa

Data:

08/II/2001

Versione: 0.00.001

Permette allutente di rimuovere articoli precedentemente inseriti nel carrello della spesa. Minuti. Elevata. Il carrello della spesa del cliente disponibile e vi sono degli articoli inseriti. Il carrello della spesa del cliente non viene modific ato. Dal carrello della spesa vengono rimossi gli a rticoli selezionati dallutente. Lutente richiede esplicitamente di rimuovere degli articoli presenti nel carrello della spesa.

UTENTE Seleziona uno o pi articoli presenti nel carrello della spesa Preme il tasto di eliminazione degli articoli selezionati

SISTEMA

Chiede conferma a procedere. Conferma leliminazione degli articoli Elimina gli articoli selezionati

Scenario di errore: Lutente non conferma leliminazione degli articoli. 4.1. Termina lo use case con insuccesso.

Il presente use case e i successivi dispongono di una descrizione del comportamento dinamico piuttosto ridotta. Ci potrebbe portare alla conclusione che probabilmente si scelto un eccessivo livello di granularit. Si tratta di unopinione del tutto plausibile; in questo contesto si deciso di riportare comunque questi use case per poter visualizzare, direttamente dallanalisi visiva dello use case diagram, quali funzioni siano disponibili nel men di gestione del carrello della spesa.

UML e ingegneria del software: dalla teoria alla pratica

83

Template 43
CASO DUSO: Aggiorna quantit UC_ECMMRC20 Descrizione: Durata: Priorit: Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. 1. UTENTE Seleziona aggiorna il campo quantit riportato a fianco degli articoli presenti nella lista. Preme il tasto di aggiornamento delle quantit Memorizza le nuove quantit Ricalcala i vari totali SISTEMA Data: 08/II/2001

Versione: 0.00.001

Permette allutente di variare la quantit di un articolo inserito nel carrello della spesa. Minuti. Elevata. Il ca rrello della spesa del cliente disponibile e vi sono degli articoli inseriti. Il carrello della spesa del cliente non viene modific ato. Viene variata la quantit di alcuni articoli presenti nel carrello della spesa. Lutente varia la quantit di uno specifico articolo presente nel carrello della spesa.

2. 3. 4.

84
Template 44
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Svuota carrello

08/II/2001

UC_ECMMRC21 Descrizione: Durata: Priorit: Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio: Scenario principale. UTENTE 1. 2. 3. 4. Preme il tasto di eliminazione degli articoli presenti nel carrello.

Versione: 0.00.001

Permette allutente di eliminare tutti gli articoli presenti nel carrello della spesa. Secondi. Elevata. Il carrello della s pesa del cliente disponibile e vi sono degli articoli inseriti. Il carrello della spesa del cliente non modificato. Il carrello della spesa viene svuotato. Lutente richiede esplicitamente di sv uotare il carrello della spesa. SISTEMA

Chiede conferma a procedere. Conferma leliminazione degli articoli Elimina gli tutti gli arti coli dal carrello.

Scenario di errore: Lutente non conferma leliminazione degli articoli. 3.1. Termina lo use case con insuccesso.

Template 38
n. Osservazione Autore Stato

Template 39
n. Iterazione 1A Autore LVT Consegna 10 II 2001 Initial draft Descrizione

UML e ingegneria del software: dalla teoria alla pratica

85

Figura 17 Use case effettua ordine.


Verifica carrello della spesa
include

Seleziona articoli dal carrello della spesa


include

Effettua ordine Utente


extend extend

Credits Authority

Modifica dati utente

Esegue transazione

Lattore identificato con il nome generico Credits Authority rappresenta uno di quei sistemi che offrono servizi automatici di controllo ed esecuzione di transazioni economiche digitali effettuate tramite carta di credito. Utenti di tali servizi sono prevalentemente organizzazioni commerciali. Il ciclo di vita tipico degli ordini non prevede limmediato invio presso il legacy system: essi vengono invece parcheggiati in una cartella dedicata ove soggiornano attendendo che un apposito servizio temporizzato li prelevi, li organizzi in un messaggio e quindi, finalmente, li spedisca al legacy system. Template 45
CASO DUSO: Effettua ordine UC_ECMMRC22 Descrizione: Data: 10/II/2001

Versione: 0.01.001

Durata: Priorit: Attore primario: Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio:

Permette allutente di effettuare un ordine selezionando gli articoli precedentemente inseriti nel carrello della spesa. Minuti. Elevata. Utente. Ha interesse nelleffettuare un ordine di acquisto on-line. Lutente stato autorizzato ad eseguire il servizio ed il carrello della spesa dellutente non vuoto. Lordine non vi ene effettuato e nessun importo viene addebitato al cliente. Lordine viene confermato ed il relativo importo viene debitamente ascritto al cliente. Lutente richiede di eseguire la funzione di compilazione ordini.

86
Template 46
Scenario principale. UTENTE 1. 2. 3. 4. 5. 6. 7.

Capitolo 4. Modellazione avanzata degli Use Case

SISTEMA

Richiede esplicitamente di effettuare un ordine. Reperisce il carrello della spesa relativo allutente. Include(seleziona articoli dal carrello della spesa) Reperisce i dati relativi al profilo dellutente. Visualizza la pagina con i dati dellordine impostati. Verifica i dati ed eventualmente d ecide di modificare i propri. Punto di estensione: modifica dati utente. Condizione: Lutente intende modificare i propri dati. Richiede conferma a procedere. Conferma dati ordine Punto di estensione: esegue transazione condizione: lutente conferma lordine Memorizza lordine. Svuota il carrello della spesa. Punti 6,9:

8. 9. 10.

11. 12.

Scenario di errore: Lutente richiede di terminare anticipa tamente il servizio. 6.1. 6.2. Visualizza apposito messaggio. Termina lo use case con insuccesso.

Scenario di errore: La selezione degli articoli presenti nel carrello della spesa termina con errore. 3.1. Visualizza apposito messaggio. 3.2. Termina lo use case con insuccesso. Scenario di errore: Credits Authority nega autorizzazione a procedere con la transazi one. 11.1. Visualizza apposito messaggio. 11.2. Termina lo use case con insuccesso.

Da notare che non viene eseguita alcuna verifica in merito alla presenza di articoli nel carrello della spesa, in quanto ci rappresenta una precondizione.

UML e ingegneria del software: dalla teoria alla pratica

87

Template 47
CASO DUSO: UC_ECMMRC23 Descrizione: Seleziona articoli dal carrello della spesa Data: 10/II/2001

Versione: 0.00.003

Durata: Priorit: Attore primario:

Permette allutente di selezionare gli articoli presenti nel carrello della spesa da incorporare nellordine di acquisto, eventualmente modificandone la quantit. Minuti. Elevata. Utente. Ha interesse nel selezionare gli articoli da inserire nellordine di acquisto. Il carrello della spesa dellutente disponibile e non vuoto. Il carrello della spesa non viene modificato. Lutente seleziona la lista degli articoli da impostare nellordine, eventualmente variandone la quantit. SISTEMA Include(verifica carrello della spesa) Visualizza lelenco degli articoli presenti nel carrello della spesa con eventuali segnalazioni scaturite dal controllo eseguito nel punto precedente.

Precondizioni: Garanzie di fallimento: Garanzie di successo: Scenario principale. UTENTE 1. 2.

3.

Seleziona gli articoli che intende far confluire nellordine e ventualmente variandone la quantit. Preme il tasto di conferma. Genera la lista con selezionati dallutente gli articoli

4. 4.

Scenario di errore: Lutente richiede di terminare anticipatamente la funzione. Punti 3, 4 3.1. Termina lo use case ritornando la lista degli articoli vuota.

88
Template 48
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Modifica dati utente

10/II/2001

UC_ECMMRC24 Descrizione:

Versione: 0.00.003

Durata: Priorit: Attore primario: Precondizioni: Garanzie di fallimento: Garanzie di successo:

Permette allutente di modificare i propri dati e di impostarne altri di carattere fiscale (codice della carta di credito). Minuti. Elevata. Utente. Ha interesse a modificare i propri dati. disponibile il profilo utente. I dati dellutente non subisco alcuna modifica. Lutente imposta i dat i fiscali ed eventualmente modifica altri dati (quali per esempio indirizzo di spedizione, fascia oraria, ecc.) SISTEMA Visualizza la pagina con i dati dellutente presenti nel sistema. Richiede di inserire i dati fiscali.

Scenario principale. UTENTE 1. 2. 3. 4. 5. 6. 7. Seleziona uno degli indirizzi presenti oppure ne imposta un altro. Imposta i dati fiscali ed eventua mente modifica quelli generali. Preme il tasto di conferma. l-

Richiede di selezionare lindirizzo di spedizione.

Memorizza i dati impostati Punti 3,4,7

Scenario di errore: Lutente richiede di terminare anticipatamente il servizio. 3.1. 3.2. Visualizza apposito messaggio Termina lo use case con insuccesso.

UML e ingegneria del software: dalla teoria alla pratica

89

Template 49
CASO DUSO: Esegue transazione UC_ECMMRC26 Descrizione: Data: 10/II/2001

Versione: 0.00.003

Durata: Priorit: Attore primario:

Il sistema richiede lautorizzazione ad eseguire transazioni commerciali per mezzo di carta di credito al fine di accreditare limporto dellordin e. Secondi. Elevata. Credits Authority. Ha interesse nel riceve il messaggio di richiesta autorizzazione della transazione economica. I dati fiscali dellordine sono disponibili. Non viene eseguito alcun addebito al cliente. La transazione viene accettata e quindi limporto dellordine viene accreditato sulla carta di credito del cliente. SISTEMA Preleva tutti i dati necessari per la transazione. Organizza la richiesta secondo le specifiche della Credits Authority. Effettua la richiesta.

Precondizioni: Garanzie di fallimento: Garanzie di successo:

Scenario principale. CREDITS AUTHORITY 1. 2. 3. 4. 5. 6. 7. 4.1. 4.2.1. 4.2.2. 4.3. 4.3.1. 4.3.2.

Riceve la richiesta. Esegue le verifiche del caso. Invia esito. Verifica esito positivo autorizzazione. Se si sono effettuati un numero di tentativi pari a quello definito. Esegue procedura di notifica situazione anomala. Visualizza apposito messaggio e conclude la funzione con insuccesso. Numero di tentativi inferiore a quello definito. Incrementa il contatore di tentativi Attende t secondi e ritenta lesecuzione del punto 4.

Scenario di errore: Fallisce la richiesta del servizio.

Scenario di errore: Scaduto time -out. 7.1. La risposta della credit authority non perviene entro lintervallo di tempo stabilito. 8.2. 8.3. Esegue procedura di notifica situazione anomala. Visualizza apposito messaggio e conclude la funzione con insuccesso.

Scenario di errore: Transazione rifiutata. 8.1. Comunica opportuno messaggio allutente. 8.2. Termina lo use case con insuccesso. Annotazioni. 7.1. Nel caso di time -out necessario investigare le misure da attuare. Reiterare la richiesta potrebbe portare ad un addebitamento ripetuto.

90
Template 38
n. Osservazione

Capitolo 4. Modellazione avanzata degli Use Case

Autore

Stato

Template 39
n. Iterazione 1A Autore LVT Consegna 10 II 2001 Initial draft Descrizione

Figura 18 Use case spedizione ordini.

Spedizione ordini
extend [primo ordine effettuato dal cliente]

Timer Reperimento dati utente

Legacy System

Invio e-mail
extend

Cliente Ricezione esito elaborazione ordini

Lo use case illustrato in fig. 18 mostra il processo che permette al sistema di comunicare al Legacy System gli ordini effettuati online. Il Legacy System, dal canto suo, origina messaggi relativi allo stato di avanzamento degli ordini (in lavorazione, spedizione merce, ecc.) con le efferenti informazioni. Si deciso di visualizzare come attore il Legacy system anzich il sistema di wrapper in quanto si suppone che il software presente presso lorganizzazione del cliente sia predisposto per lacquisizione/invio di messaggi tipicamente effettuati per mezzo di protocolli FTP.

UML e ingegneria del software: dalla teoria alla pratica

91

Template 50
CASO DUSO: Spedizione ordini UC_ECMMRC30 Descrizione: Durata: Priorit: Attore primario: Precondizioni: Garanzie di fallimento: Garanzie di successo: Data: 10/II/2001

Versione: 0.00.002

Consente al sistema di inviare al legacy system gli ordini effettuati ed ancora residenti nel sito. Secondi. Elevata. Legacy system Riceve un messaggio con gli ordini effettuati on -line. Siano disponibili degli ordini non ancora inviati al legacy system. Nessun ordine viene inviato al legacy system e gli stessi permangono nellapposita directory del sistema. Tutti gli ordini in attesa di essere inviati vengono opportunamente organizzati in un messaggio e quindi trasferiti al legacy sytem Attivazione temporizzato del processo di invio ordini. SISTEMA Verifica che ci siano ordini da trasferire al legacy system. Reperisce tutti gli ordini da inviare Per ciascuno di essi organizza i dati secondo un apposito formato predefinito. Punto di estensione: Reperimento dati utente. Condizione: Si tratta del primo ordine del cliente. Trasferisce (tipicamente tramite protocollo FTP) il file al sistema l egacy.

Avvio: Scenario principale. LEGACY SYSTEM 1. 2. 3.

4.

5. 6. 7. Riceve il file con lelenco dei recenti ordini effettuati dagli utenti del sito.

Aggiorna lo stato degli ordini trasferiti (stato=inviati). Se si sono effettuati un numero di tentativi pari a quello definito. Esegue procedura di notifica situazione anomala. Visualizza apposito messaggio e conclude la funzione con insuccesso. Numero di tentativi inferiore a quello definito. Incrementa il contatore di tentativi Attende t secondi e ritenta lesecuzione del punto 5.

Scenario di errore. Il sistema fallisce il trasferimento del file degli ordini. 5.1. 5.2.1. 5.2.2. 5.3. 5.3.1. 5.3.2.

92
Template 51
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Reperimento dati utente

10/II/2001

UC_ECMMRC31 Descrizione: Durata: Priorit: Precondizioni: Garanzie di fallimento: Garanzie di successo: Scenario principale. SISTEMA Segmento di estensione: reperimento dati utente. 1. 2. Secondo. Elevata.

Versione: 0.00.001

Reperisce i dati efferenti uno specifico utente.

disponibile il codice dellutente del quale si desiderano reperire i dati. Nessun informazione viene reperita. Vengono reperiti i dati relativi allutente specificato.

Preleva il codice dellutente del quale si desidera reperire le relative info rmazioni. Reperisce le informazioni dellutente.

Figura 19 Ciclo di vita di un ordine

memorizzazione ordine transazione rifiutata

REGISTRATO
transazione accettata modificato

CONFERMATO

transazione accettata

PENDING

inviato al Legacy System ordine non accettato

RESPINTO

INVIATO
protocollato dal Legacy System

PRESO IN CARICO
ordine spedito annullato

UML e ingegneria del software: dalla teoria alla pratica

93

Template 52
CASO DUSO: UC_ECMMRC32 Descrizione: Ricezione esito elaborazione ordini Data: 10/II/2001

Versione: 0.00.002

Durata: Priorit: Attore primario:

Consente al sistema di ricevere il file proveniente dal legacy sytem con lelenco laggiornamento dello stato di elaborazione degli ordini inviati in precedenza. Per ognuno di essi prevista apposita comunicazione via email allutente. Secondi. Elevata. Legacy system Invia un messaggio con lo stato di avanzamento degli ordini effettuati on-line. Diversi ordini effettuati on -line siano stati precedent emente inviati al Legacy system. Nessun ordine viene aggiornato. Lo stato degli ordini presenti nel file ricevuto viene aggiornato ed opportune comunicazione via e -mail vengono inviate agli utenti che hanno effettuato gli ordini. Il legacy system invia il file degli esiti dellelaborazione degli ordini ricevuti. SISTEMA

Precondizioni: Garanzie di fallimento: Garanzie di successo:

Avvio: Scenario principale. LEGACY SYSTEM 1. 2. 3.

Invia il file con gli esiti degli ordini inviati in precedenza Acquisisce il file inviato dal legacy system Scorre tutto uno per uno tutti i record del file. Per ogni record letto: - reperisce il relativo ordine dal db; - aggiorna lo stato dellordine letto in funzione a quanto specificato nel record del file; Punto di estensione: Invio notifica al cliente. Condizione: Aggiornamento ordine effettuato.

3.1. 3.2.

3.3.

Scenario alternativo: Il sistema fallisce il reperimento dellordine d al proprio database. 3.1.1. Esegue la procedura di comunicazione situazione anomala. 3.1.2. Continua lo use case esaminando il record successivo. Scenario alternativo: Il sistema fallisce linvio delle -mail al cliente. 3.3.1. Esegue la procedura di comunicazione situazione anomala. 3.3.2. Continua lo use case esaminando il record successivo.. Scenario di errore: Il file ricevuto risulta vuoto. 2.1. Esegue la procedura di comunicazione situazione anomala. 2.2. Termina con insuccesso lo use case.

94

Capitolo 4. Modellazione avanzata degli Use Case

Volendo dettagliare il ciclo di vita di un ordine, ossia gli stati nei quali pu transitare e gli eventi che ne determinano la transizione da uno stato allaltro, si potrebbe allegare alla use case view un diagramma di stato abbastanza generale come quello visualizzato nella fig. 19.

Ogni qualvolta si ha a che fare con entit del business degne di nota, il cui ciclo di vita limitato a un insieme ben definito di stati (in altre parole descrivibile per mezzo di un automa a stati finiti), opportuno tracciarne lo state chart diagram. Questo offre il vantaggio di chiarire specifici requisiti (stati in cui pu transitare, eventi che ne generano il cambiamento stato, ecc.) in maniera chiara, molto intuitiva. Questi diagrammi permettono inoltre di verificare cammini che altrimenti potrebbero rimanere celati. In genere il diagramma di stato del ciclo di vita di un oggetto vale 1000 parole e fornisce documentazione molto valida anche per le fasi di costruzione del sistema.

Si tratta di un diagramma molto semplice e di facile comprensione: un ordine dopo essere stato memorizzato localmente nel sito si trova nella stato di registrato. Da questo stato transita in quello di confermato a seguito del ricevimento dellautorizzazione della transazione da parte del Credits Authority. Una volta inviato al Legacy System, lordine passa allo stato di inviato permanendovi fino alla ricezione della risposta dellelaborazione da parte del Legacy System. Ci genera la transizione allo stato di preso in carico. Il ciclo di vita di un ordine termina quando lorganizzazione invia, al cliente, la mercanzia specificata nellordine stesso. Il diagramma visualizza lesistenza di due stati di errore: pending ossia il sistema non riesce a effettuare la transazione; respinto quando il Legacy System per qualche motivo ha respinto lordine.
n. Osservazione Autore Stato

n. Iterazione 1A

Autore LVT

Consegna 10 II 2001 Initial draft

Descrizione

UML e ingegneria del software: dalla teoria alla pratica

95

Figura 20 Use case ricezione dati catalogo.

Invia dati catalogo

Legal System

La funzione Invia dati catalogo permette, come suggerito dal nome, di aggiornare il catalogo presente presso il sistema per il commercio elettronico con i dati inviati dal Legacy System. Gli aggiornamenti possono essere relativi allinserimento di nuovi articoli, alleliminazione di altri, alla modifica di alcune informazioni come il prezzo di un articolo o la relativa immagine e cos via. Qualora si fosse realizzato lo use case per consentire la richiesta delle segnalazioni (ciascun cliente poteva selezionare un determinato articolo e quindi specificare le condizioni per ricevere segnalazioni di offerte ad esso efferenti, come per esempio riduzione del prezzo del 10%, oppure offerte 3 2, ecc.) lo use case relativo alla funzione di segnalazione vera e propria sarebbe stato un extend del presente.

96
Template 53
CASO DUSO:

Capitolo 4. Modellazione avanzata degli Use Case

Data: Invia dati catalogo

10/II/2001

UC_ECMMRC33 Descrizione:

Versione: 0.02.001

Durata: Priorit: Attore primario:

Consente al sistema di ricevere il file con gli aggiornamenti da apportare al catalogo dei prodotti. Nello stesso file potrebbero essere presenti anche dati relativi ad offerte promozionali relativa a particolare prodotti. Secondi. Elevata. Legacy system Invia un messaggio con i dati relativi agli aggiornamenti da apportare al catalogo prodotti presente nel sito. Il sistema disponga di un catalogo articoli. Non viene modificato alcun prodotto. Gli aggiornamenti relativi al catalogo correttamente inglobati nel s istema. vengono

Precondizioni: Garanzie di fallimento: Garanzie di successo: Avvio:

Il legacy system invia il file con gli aggiornamenti del catalogo. SISTEMA

Scenario principale. LEGACY SYSTEM 1. Invia il file con gli aggiornamenti del catalogo 2. 3.

Acquisisce il file inviato dal legacy system. Scorre t utto uno per uno tutti i record del file. Per ogni record letto: - reperisce il relativo articolo dal db; - aggiorna larticolo letto in funzione a quanto specificato nel record del file; Esegue la procedura di comunicazione situazione anomala. Continua lo use case esaminando il record successivo.

3.1. 3.2.

Scenario alternativo: Il sistema fallisce il reperime nto dellarticolo dal proprio database. 3.1.1. 3.1.2.

Scenario di errore: Il file ricevuto risulta vuoto. 2.1. Esegue la procedura di comunic azione situazione anomala. 2.2. Termina con insuccesso lo use case.

UML e ingegneria del software: dalla teoria alla pratica

97

Ricapitolando
Nel presente capitolo vengono illustrate una serie di tecniche di modellazione dei casi duso, di orientamento specificamente operativo anche se, a volte, sensibilmente distante dalle direttive standard. Modellare sistemi reali mette in luce una serie di problemi e lacune raramente trattati nei libri e nelle specifiche ufficiali dello UML. La prima sezione dedicata alla presentazione di un modello atto a descrivere il comportamento dinamico dei casi duso. Tale modello, in prima analisi, pu essere suddiviso in quattro macrosezioni: lintestazione, le informazioni generali, gli scenari che a loro volta si dividono in principali, alternativi e di errore, e la sezione per eventuali annotazioni. Nellintestazione viene impostato un codice simbolico univoco per il caso duso, il nome, la data dellultima modifica e la versione. La sezione dedicata alle informazioni generali ospita la descrizione del caso duso (non pi di qualche riga), la priorit, vincoli temporali relativi allesecuzione dello stesso, gli attori divisi tra principale e secondari, le precondizioni, le garanzie e levento innescante (il trigger). Per ci che concerne la descrizione necessario riportare una breve illustrazione dei servizi offerti dal caso duso oggetto di studio senza per dilungarsi troppo: la descrizione completa viene specificata nei vari scenari. La priorit permette di evidenziare limportanza assegnata alle funzionalit che il sistema dovr fornire, al fine sia di suddividere gli use case in unopportuna gerarchia di importanza, sia per poter assegnare in maniera pi opportuna i vari casi duso alle varie iterazioni di cui si compone tipicamente un processo di sviluppo del software. Il processo di assegnazione delle priorit degli use case unattivit molto importante e sensibile per lesito dellintero progetto software in quanto si ripercuote sulla pianificazione delle iterazioni dello stesso. Gli attori, come gi indagato precedentemente, sono entit, persone o sottosistemi, interessati al comportamento del sistema. Tipicamente, nel contesto di uno stesso caso duso, gli attori vengono suddivisi in primari e secondari. I primi tipicamente forniscono lo stimolo iniziale che avvia lesecuzione del caso duso e fruiscono del relativo servizio, i secondi invece, in genere, ricevono comunicazioni, dati, ecc. generati dallo stesso. Le precondizioni sono i requisiti che devono essere soddisfatti per poter eseguire il caso duso al quale si riferiscono: compito del sistema verificarne ladempimento prima di avviare lesecuzione dellefferente caso duso, mentre responsabilit dellutilizzatore di assicurarne il soddisfacimento. Il riscontro pratico delle precondizioni che limplementazione dellefferente caso duso preveda una serie di controlli iniziali atti a verificare appunto il relativo soddisfacimento. Per ci che concerne le garanzie necessario citare esplicitamente oltre a quelle minime anche quelle di successo. Le prime, come suggerito dal nome, sono le pi basilari assicura-

98

Capitolo 4. Modellazione avanzata degli Use Case

te dallesecuzione del caso duso. Tipicamente si tratta delle garanzie assicurate dal sistema nel caso in cui non sia possibile fornire il servizio specificato in quanto lesecuzione viziata da condizioni di errore o comunque da anomalie rispetto al flusso principale del caso duso (best scenario). Specularmente alle garanzie minime, quelle di successo specificano ulteriori condizioni soddisfatte dal completamento dellesecuzione del relativo caso duso, ossia dopo lesecuzione dello scenario principale o al termine dellesecuzione di una sua variante comunque di successo. Mentre compito dellutilizzatore del caso duso assicurare il soddisfacimento delle precondizioni, responsabilit del sistema adempiere alle garanzie, qualora le prime siano soddisfatte. Per ci che concerne il campo Avvio necessario descrivere levento che determina linizio dellesecuzione del sistema. La sezione successiva del modello dedicata agli scenario. Tipicamente si distinguono tre tipologie: 1. scenario principale di successo (main success scenario): lo scenario che produce il servizio richiesto dallattore primario in cui tutto funzione perfettamente; 2. scenari alternativi (alternative scenario) si tratta di flussi di azioni che rappresentano diramazioni dello scenario principale la cui funzionalit per non sia la gestione di condizioni di errore. 3. scenari di fallimento o di errore (failure scenario): gli scenari che specificano le azioni da intraprendere nel caso in cui lesecuzione di azioni dello scenario principale sia impossibilitata dal verificarsi di condizioni di errore. La struttura utilizzata nel template oggetto di studio prevede di specificare inizialmente la sequenza di azioni da compiere nel caso in cui tutto funzioni correttamente, dallavvio del caso duso al relativo compimento, per poi fornire le condizioni anomale che possono intervenire e le azioni da intraprendere. Molto importante evidenziare chiaramente quale entit (Attore, Sistema) svolge ciascuna azione. Spesso si utilizzano particolari versioni di template nei quali la sezione dedicata agli scenari viene suddivisa orizzontalmente in un numero di colonne equivalenti alle entit che prendono parte al caso duso. Ci permette di riportare in ciascuna colonna unicamente le azioni eseguite dallentit di appartenenza. Lillustrazione degli scenari alternativi effettuata attraverso opportuni template evidenzia il grande vantaggio offerto da questo formalismo rispetto a quello grafico, ove, tipicamente, necessario disegnare un nuovo diagramma per ogni alternativa, il che richiede una quantit decisamente superiore di tempo per la realizzazione e rende difficoltosa la gestione delle relative modifiche.

UML e ingegneria del software: dalla teoria alla pratica

99

Lultima sezione del modello prevede limpostazione di eventuali annotazioni, che possono sia essere riferite allintero use case, sia a singole azioni. Lutilizzo del modello descritto viene illustrato per mezzo di un primo esempio: sottosistema universitario atto a fornire a studenti e a docenti universitari una serie di servizi fruibili attraverso un browser Internet. In questa sede vengono considerati anche gli altri strumenti utilizzabili per modellare il comportamento dinamico dei casi duso, quali i diagrammi di sequenza e quelli di attivit. Sebbene i formalismi grafici offrano tutta una serie di vantaggi (forma pi intuitiva ed accattivante, superiore grado di memorizzazione ecc.), presentano anche una serie di svantaggi tali da renderli non preferibili al modello descritto in precedenza. In particolare, allaumentare della complessit i diagrammi tendono a diventare inevitabilmente confusi, richiedendo una quantit di tempo maggiore e talune volte decisamente spropositata per realizzazione e successiva manutenzione. Il caso oggetto di studio successivo prevede lanalisi di alcuni componenti di un sistema di banking. Questo esempio offre tutta una serie di spunti importanti tra i quali quelli relativi al processo di sviluppo del software. In particolare si evidenzia come i diagrammi dei casi duso della fase di analisi debbano sia dettagliare i corrispondenti al livello dei requisiti (o di business come si preferisca), sia incorporare direttive provenienti dai requisiti non funzionali (NFR, non functional requirements) e dallarchitettura, la quale a sua volta dipende dai NFR, nonch dagli use case stessi. Indipendentemente dalla modalit stabilita per descrivere il comportamento dinamico dei casi duso, qualora si decida di ricorrere a processi di sviluppo iterativi e incrementali, utile prevedere una serie di informazioni supplementari, da associare ai vari manufatti prodotti, necessarie per tener traccia della relativa evoluzione. Queste informazioni dovrebbero riportare le varie versioni del manufatto, gli autori, la data di prevista o avvenuta consegna, la descrizione e cos via. Chiaramente non c alcuna necessit di specificarle per ogni singolo caso duso, sufficiente riportarle solo per le macrofunzionalit (in altre parole al livello di use case diagram). Probabilmente potrebbe risultare altrettanto conveniente disporre di un altro template, in qualche modo speculare al primo, collocato alla fine della descrizione del comportamento dinamico di ogni use case diagram. Lo scopo di ospitare in un sol punto eventuali considerazioni del personale coinvolto nello sviluppo e nel controllo della qualit del modello. Il terzo caso di studio che conclude il capitolo prevede unampia sezione della use case view di un sistema del tutto originale: sito e-commerce. Si tratta di un sistema molto citato in tutto il libro, per cui si deciso di presentarlo finalmente in maniera pi organica.

Capitolo

5
Una modifica che eseguita in fase di analisi dei requisiti costa un dollaro, potrebbe costarne 1000 dopo il rilascio. [LVT]

Completamento dellanalisi dei requisiti

Introduzione
Il presente capitolo si pone un duplice obiettivo: presentare una tecnica dimostratasi particolarmente valida nellarduo compito dellanalisi dei requisiti, e illustrare ulteriori manufatti (artifact) che permettono di completare il modello dellanalisi dei requisiti. Per quanto concerne il primo punto, lungi dallidea di voler affrontare per lennesima volta le problematiche connesse con le analisi dei requisiti, in questo paragrafo si focalizza lattenzione sul problema della fatale incomunicabilit che a volte si instaura tra i clienti, competenti della propria area di business, e il team dei tecnici esperti nella costruzione di sistemi informatici. Il problema, in ultima analisi, si riconduce al trovare una piattaforma di dialogo comune e costruttiva, una tecnica che rappresenti un valido raccordo tra i due diversi linguaggi tecnici: quello dellarea business utilizzato dagli utenti e quello informatico parlato dagli esperti di sistemi software. Come si avuto modo di constatare nei capitoli precedenti, il problema dei diversi linguaggi cos importante da influenzare anche le diverse versioni del modello dei casi duso caratterizzate dal transitare via via dal mondo business a quello tecnico informatico. Un valido strumento di analisi indubbiamente rappresentato dagli activity diagram; essi, oltre ai nomali vantaggi offerti da ogni formalismo grafico (aspetto accattivante, facilit di comprensione e memorizzazione, immediatezza, ecc.), ne offrono un altro tutto

Capitolo 5. Completamento dellanalisi dei requisiti

particolare e insuperabile: sono molto simili agli antenati flow chart. Chi non ne ha mai realizzato o interpretato uno? Chi non in grado di comprenderli? (Qui la costante vocina dellautore si fa sentire) Pertanto, i diagrammi di attivit si delineano come strumento ideale di dialogo tra utenti e team tecnico, almeno nelle prime fasi del ciclo di vita del software. Muovendosi da queste considerazioni, possibile escogitare una tecnica molto efficace per catturare i requisiti utente, anche se un po agli antipodi con quelle classiche. Generalmente si tenta di descrivere la proiezione statica del modello dei requisiti per mezzo dei casi duso, poi se ne dettaglia la descrizione dinamica e infine si uniforma il tutto. Nella tecnica presentata lapproccio diametralmente opposto: prima si cerca di capire il comportamento dinamico della funzione oggetto di studio per mezzo degli activity diagram e poi si risale alla relativa proiezione statica. Naturalmente, una volta redatti gli activity diagram, i vari template e/o flussi degli eventi assumono un interesse molto relativo: mostrerebbero le stesse informazioni con un formalismo diverso. Ovviamente consigliabile evitare manufatti ridondanti essenzialmente per questioni di manutenzione: ogni modifica va ripetuta per i vari manufatti. Gran parte dei capitoli precedenti sono stati dedicati allillustrazione della vista dei casi duso i quali, attraverso un formalismo amichevole e relativamente semplice, favoriscono i processi di analisi e descrizione delle funzionalit del sistema, conferendo particolare attenzione alla percezione che ne hanno gli attori. Il modello dei casi duso, pur essendo un artifact molto importante, da solo non assolutamente in grado di fornire sufficienti informazioni per il pieno svolgimento delle restanti fasi del ciclo di vita del sistema. Inoltre, nello sviluppo di progetti Object Oriented guidati dal modello dei casi duso, esiste il rischio potenzialedi produrre modelli funzionali: tale rischio, oltretutto, accresciuto da personale non espertissimo del formalismo ed era ben noto fin dallinizio allo stesso Jacobson, tanto che egli stesso evidenzi (1991-92) la necessit di bilanciare il modello dei casi duso con altri manufatti, quali: il Domain Object Model, il documento di specifica delle interfacce, il documento di architettura (o meglio la versione disponibile nella fase di analisi dei requisiti) e cos via. La completa realizzazione della vista dei requisiti del sistema, dunque, prevede la produzione di ulteriori manufatti complementari al modello dei casi duso.
Il Domain Object Model, molto in breve una versione del diagramma delle classi volto a fornire la rappresentazione Object Oriented del vocabolario vigente nello spazio del problema. In esso dovrebbero essere presenti unicamente entit appartenenti al mondo concettuale di business che il sistema in qualche modo dovr automatizzare. A questo particolare modello dedicato ampio spazio nel Capitolo 8.

Nei paragrafi successivi sono presentati i manufatti relativi alla specificazione delle interfacce, i test case, il documento dei requisiti non funzionali e le business rule.

UML e ingegneria del software: dalla teoria alla pratica

Una tecnica di analisi dei requisiti basata sugli activity diagram


Presentazione
Prima di addentrarsi nellillustrazione della tecnica, si ritiene opportuno presentare un primo basilare esempio. Si consideri di studiare un sottosistema di workflow atto a gestire situazioni di malfunzionamento (eccezioni) che potrebbero insorgere nei vari componenti di un qualsivoglia sistema. Strumenti di questo tipo sono di frequente applicazione in sistemi a elevata disponibilit e con pressanti esigenze di recupero di situazioni anomale. In altre parole in sistemi come quelli bancari. Apparati di questo tipo prevedono che, a seguito del verificarsi di una anomalia di un certo rilievo non risolvibile automaticamente venga generata opportuna comunicazione da inviare al workflow. Compito di questo dispositivo ricevere i dati relativi a tali anomalie, registrarle, assegnarvi la priorit e quindi convogliarle a un opportuno operatore umano in grado di risolvere lanomalia. Lassegnazione della priorit tipicamente avviene in funzioni a parametri configurabili e la selezione delloperatore a cui convogliare lanomalia deve avvenire indirizzandosi a chi ha le competenze necessarie per risolvere quel particolare tipo di anomalia. Il diagramma di fig. 5.1 abbastanza semplice e non richiede particolari spiegazioni: proprio questo il vantaggio di utilizzare i diagrammi di attivit! Il sistema riceve i dati relativi ad unanomalia, genera il relativo work item (in sostanza vengono estratti i dati significativi), li memorizza, effettua lanalisi di quelli ritenuti salienti: codice identificativo del sistema che ha generato leccezione, stadio in cui si verificato lerrore, tipologia, ecc. Quindi verifica se sia possibile raggruppare il work item con altri pendenti originati dalla stessa anomalia. Nel caso in cui la verifica sia positiva, avviene il raggruppamento e quindi la priorit del gruppo di appartenenza viene estesa al nuovo work item, mentre in caso negativo (il raggruppamento non possibile) necessario assegnare la priorit in base sia ai dati salienti dellanomalia, sia ad opportuni criteri presenti nel sistema; come si vedr di seguito, le regole utilizzate per calcolare la priorit sono esempi di business rule. Una volta superata anche questa fase, viene selezionato loperatore appropriato, ancora una volta combinando i dati salienti dellanomalia con quelli relativi agli operatori connessi al sistema considerando ovviamente anche il carico di lavoro pendente su di essi e quindi lanomalia viene assegnata. Tipicamente, gran parte del lavoro viene risolto in fase di configurazione: tutte le tipologie di anomalie previste dal sistema vengono catalogate e raggruppate. Per ciascun gruppo identificato si predispone unopportuna coda in cui inserire i dati delle varie anomalie. Le code sono quindi associate a ruoli da assegnare ai vari addetti. Loperatore riceve la segnalazione e, in base alle informazioni contenute, esegue determinate procedure atte a risolvere il problema. Risolta lanomalia, notifica lavvenuto assolvimento, eventualmente descrivendo le operazioni eseguite. Il sistema quindi riceve la segnalazione di avvenuta risoluzione del problema e, per anomalie non note, ne memorizza la soluzione.

Capitolo 5. Completamento dellanalisi dei requisiti

Figura 5.1 Activity diagram di un gestore di anomalie.

Sistema
Comunicazione errore

Errors Workflow System


Ricezione segnalazione errore

Operatore

Generazione work item

Memorizzazione work item

Analisi dati work item

Verifica regole di raggruppamento


[Raggruppamento possibile]

[Raggruppamento non possibile]

Raggruppamento work item

Attribuzione priorita'

Selezione operatore

Emissione comunicazione operatore Presa in carico work item

Soluzione anomalia

Comunica conferma soluzione work item Analisi descrizione soluzione

[Nuova tipologia]

[Soluzione nota]

Memorizza soluzione

UML e ingegneria del software: dalla teoria alla pratica

Figura 5.2 Activity diagram di un sistema di gestione delle anomalie con evidenziati i diversi flussi.
Sistema
Comunicazione errore Ricezione segnalazione errore

Errors Workflow System

Operatore

Generazione work item

Memorizzazione work item

Analisi dati work item

Verifica regole di raggruppamento

Raggruppamento work item

Attribuzione priorita'

Selezione operatore

Emissione comunicazione operatore Presa in carico work item

Soluzione anomalia

Comunica conferma soluzione work item Analisi descrizione soluzione

Memorizza soluzione

Capitolo 5. Completamento dellanalisi dei requisiti

Un passo propedeutico da utilizzarsi per estrarre i diagrammi dei casi duso dai relativi dallactivity diagram consiste nellevidenziare i messaggi che il sistema scambia con i relativi attori. Generalmente, il percorso compreso tra due messaggi consecutivi rappresenta ununica funzionalit da descriversi attraverso uno use case.

Per esempio la parte di activity diagram compresa tra la ricezione di una segnalazione di errore e la comunicazione del relativo work item allOperatore rappresenta logicamente uno use case. Ora, verosimilmente, tale use case risulterebbe notevolmente complesso da rappresentare attraverso un solo caso duso, e quindi opportuno ripartire alcune funzionalit in altri casi duso inclusi o estesi. Analogamente la porzione di activity diagram compresa dalla ricezione del messaggio di conferma soluzione fino alla fine delle attivit si presta a essere rappresentata per mezzo di un caso, eventualmente da espandere.

La parte di percorso relativa alla diramazione del flusso quella generata dagli elementi condizionali che nella fig. 5.2 sono mostrati con una tonalit pi scura rispetto a quella del flusso principale rappresenta verosimilmente unalternativa rispetto al flusso base. Tali flussi si prestano a essere descritti o attraverso specifici use case estendenti o, pi semplicemente, attraverso dei flussi alternativi. La decisione dipende da vari fattori, come per esempio limportanza che si desidera assegnare al flusso (use case distinti conferiscono maggiore enfasi), la corposit del comportamento da descrivere, gli obiettivi che permettono di raggiungere (se le post-condizioni sono diverse da quelle del flusso base allora molto probabilmente si tratta di uno use case separato) ecc.

Come si pu riscontrare dallanalisi del diagramma dei casi duso mostrato in fig. 5.3, il relativo livello di dettaglio decisamente inferiore a quello presente nellactivity diagram (ci sono meno informazioni). Molte attivit ritenute di secondaria importanza (Memorizza work item, Analisi dati work item, ecc.) sono state inglobate in uno use case pi generale (Gestione work item). A questo punto pu insorgere qualche problema. Gli utenti, nellesaminare i diagrammi dei casi duso ottenuti da quelli delle attivit realizzati con il loro contributo, tipicamente si attendono di vedere una corrispondenza biunivoca tra i casi duso e le attivit presenti nei relativi diagrammi. Ci chiaramente non sempre consigliabile. Diversi tool commerciali permettono di tenere traccia automaticamente di tali corrispondenze. In casi

UML e ingegneria del software: dalla teoria alla pratica

Figura 5.3 Use case del sistema di gestione anomalie.

Assegna priorit Esegue raggruppamento


extend extend include

Selezione operatore

Gestione work item


include

Invia notifica errore Operatore Conferma soluzione anomalia


extend

Sistema "Assistito"

Memorizzazione soluzione

estremi possibile realizzare apposite matrici di corrispondenza, in cui si specifica lallocazione delle attivit ai casi duso. Il problema, ancora una volta, che la gestione di tali tabelle unattivit decisamente dispendiosa. Si consiglia pertanto di evitare per quanto possibile il ricorso a queste tabelle: richiedono molto tempo per essere realizzate e necessitano di essere riviste ogniqualvolta si ristrutturano i diagrammi dei casi duso a cui si riferiscono. Unaltra constatazione relativa alle attivit inserite in diramazioni del flusso (costrutti if then else) presenti negli activity diagram (attivit da svolgere solo al verificarsi di precise condizioni come per esempio Assegna priorit ed Esegui raggruppamento ). Come specificato precedentemente, quelle ritenute importanti, e quindi da visualizzare anche nel diagramma dei caso duso (Memorizzazione soluzione), si prestano ad essere riprodotte per mezzo della relazione di estensione. In alcuni casi si pu ricorrere anche a relazioni di generalizzazione. Ci, quando possibile e badando bene al significato semantico, permette di rappresentare pi chiaramente lesecuzione alternativa di precise attivit. Per esempio nel diagramma dei casi duso precedente si sarebbe potuto ricorrere a questo espediente per strutturare le attivit di Assegna priorit ed Esegui raggruppamento. A essere onesti, in questo caso lutilizzo sarebbe stato artificioso

Capitolo 5. Completamento dellanalisi dei requisiti

Tabella 5.1 Matrice di mapping tra use case e activity.


Invia notifica errore Gestione work item Esegue Raggruppamento Assegna priorit Selezione operatore Conferma risoluzione anomalia Memorizzazione soluzione
Use Case

Activity

Comunicazione errore Ricezione segnalazione errore Generazione work item Memorizzazione work item Analisi dati work item Verifica regole di raggruppamento Raggruppamento work item Attribuzione priorit Selezione operatore Emissione comunicazione operatore Presa in carico work item Soluzione anomalia Conferma soluzione anomalia Memorizzazione soluzione

e quindi non di facile comprensione: il raggruppamento non pu essere considerato una specializzazione dellassegnazione della priorit sebbene, qualora eseguito, generi come effetto collaterale lassegnazione automatica della priorit. Literazione con lattore Operatore stata suddivisa in due use case: uno inserito in quello denominato Gestione work item per linvio della comunicazione allattore e laltra nel caso duso Conferma risoluzione anomalia al fine di ricevere il relativo feedback.

Si ricordi che nello UML preferibile modellare le interazioni in modo asincrono. Ci per non implica necessariamente che il sistema le realizzi secondo tale criterio: nel contesto dellanalisi dei requisiti necessario catturare i requisiti utente e non le soluzioni.

UML e ingegneria del software: dalla teoria alla pratica

Figura 5.4 Frammento semplificato di un activity diagram utilizzato per dettagliare la procedura di approvazione di primo livello delle richieste di variazione profilo utente.
Supervisore sicurezza

Addetto Sicurezza

Sistema

Team Leader

Esegue la funzione di approvazione richieste

Reperisce i dati dell'utente

Reperisce le richieste in coda dell'addetto Visualizza la lista con le richieste pendenti Eventualmente seleziona una richiesta dalla lista Valuta i dati impostati dall'utente [richiesta terminazione servizio] [l'utente seleziona una richiesta] Reperisce i dati di dettaglio della richiesta Verifica che la richiesta non sia relativa allo stesso addetto Sia in caso di approvazione, sia di rigetto, l'utente puo' associare propri commenti. Business rule X.Y: Non e' permesso ad un addetto alla sicurezza di approvare una richiesta a lui riferita.

[richiesta riferita allo stesso utente] [richiesta riferita ad un altro utente] Visualizza i dettagli dell'utente e della richiesta

Effettua la selezione Valuta la selezione operata dall'utente [richiesta terminazione servizio] [effettuata selezione] Aggiorna lo stato della richiesta

Verifica esito della selezione

Invia comunicazione al supervisore della sicurezza Riceve notifica Memorizza motivazione

Invia comunicazione al supervisore al team leader Riceve notifica

10

Capitolo 5. Completamento dellanalisi dei requisiti

Figura 5.5 Frammento dello use case diagram relativo allactivity riportato nella fig. 5.4.

Reperisce richieste pendenti in carico all'utente


include

Valuta richieste pendenti Addetto Sicurezza

Approva richiesta

Rigetta richiesta

Supervisore Sicurezza

Team Leader

Riflessione conclusiva di questo primo esempio: tipicamente necessario riportare un ulteriore caso duso generale (Gestione work item) con funzioni sia di collante dei vari casi duso (una sorta di main che invoca sottoroutine), sia di raccoglitore delle funzionalit ritenute di eccessivo livello di dettaglio (il contenitore del flusso principale o main scenario). Il secondo esempio presentato stato introdotto al fine di illustrare lutilizzo della relazione di generalizzazione. In particolare viene riportato un frammento del processo, vigente presso unipotetica organizzazione (per esempio una banca), atto ad assegnare ai propri dipendenti i profili (profile) per laccesso al sistema. In questo contesto si suppone che ogni utente disponga di un solo profilo operativo.Tale profilo stabilisce quali funzioni lutente pu eseguire e su quali dati. Per esempio, se un utente dispone di un profilo che abilita lesecuzione del servizio di verifica dei conti correnti dei clienti di una determinata filiale, non detto che lo stesso utente possa eseguire tale servizio per i conti correnti dei clienti di altre filiali. Il flusso ipotizzato che il Team Leader, ogniqualvolta gli sia assegnato un nuovo dipendente, o quando questi cambi di funzione/ruolo, compili

UML e ingegneria del software: dalla teoria alla pratica

11

unapposita richiesta di assegnazione di un nuovo profilo per tale dipendente. Si ipotizza poi che tale richiesta debba passare attraverso due livelli di approvazione: una prima a carico di un addetto della sicurezza appartenente al dipartimento dellutente e una seconda a carico del supervisore della sicurezza. La funzione analizzata di seguito relativa alla prima approvazione. Si consideri ora il diagramma delle attivit riportato nella fig. 5.6. Si tratta della funzione denominata Monitor of Off-Market Transactions, ossia di un processo batch a carico del back office di un sistema finanziario atto a verificare che i tassi applicati ai Trade stipulati nel sistema di Front Office siano consistenti con quelli di mercato.
Brevemente, con il termine Trade ci si riferisce a contratti di scambio di prodotti (in questo contesto finanziario e tipicamente in valuta), tra due parti: cliente e una organizzazione finanziaria.

In altre parole si vuole controllare che ai Trade siano applicati tassi compatibili con quelli di mercato. Per esempio, se un Trade relativo a un prodotto FX (Foreign eXchange, scambio di valuta) tra EUR (Euro) e GBP (Sterlina del Regno Unito), e il relativo tasso di mercato nellistante della stipula era uguale a x, si vuole accertare che quello realmente applicato sia allinterno di un opportuno intervallo (per esempio, 10%) del valore di mercato pi le commissioni. Il Monitor of Off-Market Transactions uno dei controlli che avvengono presso le banche alla chiusura della attivit di mercato. In ultima analisi si controlla loperato dei vari dealer (personale addetto alla contrattazione e gestione dei Trade finanziari), con lobiettivo di accertare che gli stessi non effettuino, per qualche misterioso motivo, condizioni di favore, magari ancora vantaggiose per lorganizzazione finanziaria ma comunque eccessivamente vantaggiose per il cliente (controparte). Tipicamente, i Trade risultati OffMarket vengono trasmessi al manager del Front Office ed al controllore finanziario, i quali hanno la responsabilit di effettuarne la revisione
Per questioni di completezza necessario dire che esistono dei casi di eccezione non riportati nella trattazione al fine di contenere la complessit e mantenere lobiettivo sulla tecnica e non sul business bancario solitamente denominati Historical Rate Rollovers. Brevemente, in alcuni casi pu capitare che un cliente probabilmente di particolare rilievo stipuli un contratto con precise quotazioni di mercato in un istante determinato di tempo e, alla scadenza dello stesso, il cliente chieda di prolungarne il termine. Per esempio un cliente stipula un contratto per 1 000 000 di dollari da pagare in Euro. Alla scadenza, lo stesso richiede di prolungare il contratto per un altro mese. La procedura corretta sarebbe di chiudere il primo contratto e di effettuarne uno nuovo con i tassi di mercato aggiornati. Per specifici mercati e particolari clienti invece permesso di stipulare un nuovo contratto con i tassi di quello precedente.

12

Capitolo 5. Completamento dellanalisi dei requisiti

Figura 5.6 Diagramma delle attivit del processo di controllo dei valori di tolleranza dei Trade.
Servizio Telematico Dati Quotazioni Prodotti Finanziari Sistema Sistema di Gestione delle Eccezioni
AVVIO: Schedulatore PRECONDIZIONI: Disponibili dati relativi ad un nuovo Trade

Preleva primo Trade in coda Verifica necessita' di applicare il controllo di tolleranza

[controllo richiesto] Verifica disponibilita' dati quotazione Trade (data ora del Trade) [quotazioni aggiornate non disponibili] Richiesta quotazioni di mercato Ricezione richiesta Verifica richiedente [richiedente non autenticato o non autorizzato] [richiedente autenticato ed autorizzato] Reperisce dati Invia risposta Ricezione responso Verifica responso [responso conforme] [responso non conforme] Comunica eccezione "Reperimento dati quotazioni fallito" Memorizza dati quotazioni ricevuti Reperisce tabelle relative alla tolleranza Trade [tabelle reperite] Messaggio di errore

Controllo di tolleranza non richiesto per tipologie di Trade: - option take-up - consegna fisica di opzioni relative a valute

[tabelle non reperite] Reperisce tabelle valori di default [tabelle reperite] [tabelle non reperite] Comunica eccezione "Tabelle tolleranza non disponibili" Calcola quotazione di mercato del Trade Memorizza i valori calcolati Verifica rispetto dei livelli di tolleranza [Livelli di torellaranza rispettati] [Livelli di torellaranza non rispettati] Comunica eccezione "Livelli di tolleranza non rispettati" Verifica presenza di Trade in coda [presenti Trade in coda da analizzzare] preleva Trade in coda [Analizzati tutti i Trade] Gestione eccezioni

Ricezione dati eccezione

UML e ingegneria del software: dalla teoria alla pratica

13

Si tenga presente che lobiettivo del presente paragrafo ancora una volta illustrare la tecnica descritta in precedenza e non modellare una porzione del back office della banca, pertanto lautore si scusa per eventuali approssimazioni. Nel diagramma riportato in fig. 5.6 sono presenti imprecisioni ed errori tipici di un diagramma reale. Si deciso di presentarli sia per avere ulteriori spunti di riflessione, sia per riportare situazioni pi vicine alla realt. In primo luogo un errore tipico in cui facile incorrere consiste nel tentare di modellare o comunque di descrivere le specifiche di sistemi al di fuori di quello oggetto di studio. In questo equivoco, a dire il vero, i clienti sono maestri: non appena cominciano a prendere dimestichezza con strumenti di analisi, quali essi siano (use case, activity diagram, ecc.), vengono affetti dalla sindrome denominata specificomania: vorrebbero scrivere le specifiche per ogni entit incontrata Anche di sembianze umane! Nel diagramma in questione il fantomatico servizio denominato Servizio Telematico Dati Quotazioni Prodotti Finanziari rappresenta evidentemente un sistema esterno a quello oggetto di studio: un attore a tutti gli effetti, il cui comportamento stato per impropriamente modellato anche se solo parzialmente. Ci non un peccato mortale fintantoch sia ben chiaro che tali dettagli hanno unicamente valenza descrittiva e quindi non devono confluire negli use case diagram. Un altro elemento di interesse potrebbe essere la presenza del sistema di gestione delle eccezioni descritto in precedenza. Ad esso vengono convogliate tutte le segnalazioni di situazioni anomale: problemi con la comunicazione con il sistema esterno, impossibilit di reperimento delle tabelle di tolleranza, ecc. Tornando al processo Monitoring Off-Market Transactions, esso ha inizio alla chiusura della giornata finanziaria. La prima verifica da effettuarsi relativa alla necessit di eseguire il processo di controllo del rispetto dei limiti di tolleranza. In caso di esito negativo si passa ad esaminare leventuale Trade successivo, altrimenti si prosegue verificando se nel sistema siano disponibili i dati relativi alle quotazioni di mercato inerenti il particolare Trade in un accettabile intervallo temporale del momento in cui avvenuta la stipula del Trade stesso: si interessati al valore di mercato del Trade allatto della stipula. Nel caso in cui i dati siano disponibili si procede con il processo, altrimenti si richiedono le quotazioni a un ipotetico Servizio Telematico Dati Quotazioni Prodotti Finanziari. Tale sistema esterno a quello oggetto di studio (outside scope), sebbene riportarne la descrizione nel diagramma delle attivit non sia peccato mortale. Ricevuto il messaggio di ritorno, questo viene analizzato. Se la struttura e i contenuti attesi non sono conformi a quelli attesi viene generata una segnalazione di errore, inviata poi al Sistema di Gestione delle Eccezioni. Se invece la risposta ottenuta risulta conforme a quanto atteso, si salvano i dati contenuti e si prosegue per il normale flusso del processo. Si tenga presente che il fatto che nelle specifiche utente il dominio del processo di verifica sia il singolo Trade non deve essere considerato un vincolo per il sistema finale.

14

Capitolo 5. Completamento dellanalisi dei requisiti

Gli use case dei requisiti utente servono appunto per specificare cosa si attende lutente e non come ottenerlo. Per esempio nulla vieta che il sistema finale presenti alcune ottimizzazioni, come per esempio accumulare le richieste di quotazioni in un apposito messaggio da inviare ad intervalli predefiniti invece di richiedere ogni singolo valore di quotazione appena necessario. Ottenuti i dati si prosegue tentando di reperire le tabelle di tolleranza del particolare Trade; nel caso di impossibilit si procede tentando di reperire quelle standard. Fallendo anche questo secondo tentativo, si emette relativa segnalazione di errore ed il processo prosegue con lesame del Trade successivo. Ottenuti anche i dati relativi alle tabelle, si effettuano i vari calcoli, li si salva e quindi si effettua il tanto agognato controllo del rispetto dei vincoli di tolleranza. Se il Trade risulta al di fuori dei limiti previsti, come al solito si emette opportuna segnalazione al Sistema di Gestione delle Eccezioni, altrimenti il processo termina placidamente. Il Sistema di Gestione delle Eccezioni dovrebbe riconoscere la tipologia del messaggio e quindi inserire appositi WorkItem nelle code relative al Manager del Front Office e al controllore finanziario, i quali sono formalmente chiamati a intrapren-

Figura 5.7 Use case diagram del processo di controllo dei livelli di tolleranza.

Timer

Monitoring Off-Market transactions


extend [Dati quotazioni di mercato non disponibili nel sistema] extend extend

Comunicazione correnti quotazioni di mercato

include

Invia notifica errore

Reperimento tabelle di tolleranza

Controllo livelli tolleranze

Sistema Telematico Dati Prodotti Finanziari

Sistema di Gestione delle Eccezioni

UML e ingegneria del software: dalla teoria alla pratica

15

dere opportune azioni (verifiche, sanzioni, ecc.) il cui esito deve essere memorizzato nel sistema. In fig. 5.7 viene mostrato il caso duso, che non dovrebbe presentare grosse sorprese. Una perplessit che potrebbe sorgere analizzando i due diagrammi riguarda la ripetizione del ciclo di analisi per tutti i trade stipulati nellarco del giorno. In particolare, mentre nel diagramma delle attivit ben evidente, nel rispettivo diagramma dei casi duso non lo . Poco male, la ripetizione verr definita nella descrizione del main scenario dello use case Monitoring Off-Market Transactions.

Vantaggi e svantaggi
I vantaggi del metodo dovrebbero essere ormai chiari: 1 semplifica il processo di instaurazione di una piattaforma comune di dialogo tra gli utenti e il team che dovr sviluppare il sistema;

2. riduce il tempo necessario per addestrare il personale non tecnico allutilizzo del formalismo dei diagrammi delle attivit, e ne aumenta lentusiasmo (in genere molto pi divertente giocare con dei diagrammi piuttosto che scrivere del testo); 3. la presenza di requisiti descritti tramite diagrammi li rende pi chiari e pi immediati e quindi riduce il rischio di incomprensioni; 4. agevola lo scambio delle informazioni e fornisce uneccellente documentazione da utilizzare per addestrare il personale sia dellarea tecnica, sia di quella business; 5. i tool commerciali supportano bene questa strategia. A fronte di questi vantaggi a dire il vero se ne potrebbero riportare diversi altri esiste per una serie di inconvenienti: 1. superata una certa complessit, i diagrammi delle attivit tendono a divenire confusi e bisogna investire molto tempo nel tentativo di renderli lineari e comprensibili; 2. gli activity diagram, tipicamente, non riescono a sopperire completamente allesigenza di redigere la descrizione dei casi duso. Ci perch non immediato inserire tutte le informazioni (trigger, pre- e postcondizioni, requisiti speciali, ...) ed difficile specificare i dettagli di tutti i flussi nei diagrammi stessi; 3. disponendo sia della descrizione dei casi duso, sia dei diagrammi delle attivit, diviene molto costoso mantenere sincronizzati i due modelli;

16

Capitolo 5. Completamento dellanalisi dei requisiti

4. il processo di aggiornamento dei diagrammi di attivit richiede molto pi tempo rispetto allaggiornamento del testo di un diagramma dei casi duso.

Dallanalisi dei vantaggi e degli svantaggi del metodo possibile constatare che nonostante gli inevitabili inconvenienti, il metodo possiede delle peculiarit (maggiore coinvolgimento degli utenti, facilit di scambio delle informazioni, ...) che, specie in progetti non banali, sarebbe veramente un peccato non sfruttare. Il consiglio allora potrebbe essere quello di utilizzare comunque la tecnica dei diagrammi delle attivit almeno fino al punto in cui i requisiti, e quindi i relativi modelli, raggiungono unaccettabile stato di stabilit. A questo punto si potrebbero placidamente trascurare questi diagrammi, concentrandosi unicamente sui diagrammi dei casi duso e sulla relativa descrizione.

Modello per le interfacce


Un aspetto molto importante della progettazione di un sistema legato alla definizione del confine dello stesso. Un manufatto che ne favorisce la determinazione, e che agevola la definizione formale delle responsabilit che attori e sistema assumono gli uni nei confronti dellaltro, il modello di specifica delle interfacce. Questo, una volta completato, dovrebbe rendere immediata la definizione delle classi boundary presenti nel modello di analisi (cui si accenna nel Capitolo 2 e che viene trattato nel Capitolo 8). Spesso le entit esterne al sistema non sono esclusivamente utenti in carne e ossa, bens altri sistemi (legacy system, moduli agent, sensori, software forniti da terze parti, sistemi di fornitura di servizi on demand, ecc.). In questi casi ancora pi sentita la necessit di definire formalmente le interfacce tra il sistema e gli attori poich, essendo dispositivi, potrebbero davvero essere meno accomodanti degli attori umani (almeno teoricamente!). Analizzare tali interfacce molto importante anche perch finiscono per influenzare direttamente lelaborazione del modello dei casi duso: dovendo interagire con sistemi esterni di cui non si ha il controllo, pi facile che il sistema oggetto di studio si adatti alle interfacce predefinite piuttosto che il viceversa. Considerando infine che il paradigma preferenziale dei sistemi di nuova generazione il famoso component-based, secondo il quale il sistema definito in termini di specifici componenti in grado di erogare servizi definiti nelle relative interfacce, si comprendono ancora pi approfonditamente i vantaggi derivanti dalliniziare a definire formalmente le interfacce del sistema gi durante le prime fasi del processo di sviluppo del software. Sebbene le due tipologie di interfacce presentino un diverso livello di astrazione e obbiettivi sensibilmente diversi, esiste una chiara dipendenza delle interfacce dei componenti dalle rispettive del sistema: in ultima analisi i componenti realizzano i servizi richiesti al sistema.

UML e ingegneria del software: dalla teoria alla pratica

17

Comunque, la definizione delle interfacce fornisce sia ulteriori requisiti da utilizzare per iniziare la modellazione del sistema in termini pi architetturali, sia importanti informazioni per levoluzione del Domain Object Model: lecito attendersi che i dati scambiati con gli attori siano opportuni sottoinsiemi di quelli presenti nel modello a oggetti. In caso contrario, probabilmente opportuno accertarsi che nel Domain Object Model non siano presenti lacune. La relazione tra le interfacce del sistema e il modello del dominio cos forte che spesso il processo di analisi delle interfacce viene eseguito dopo aver accertato la validit del modello a oggetti del dominio: daltronde lecito attendersi di comunicare informazioni a propria disposizione e di ricevere informazioni in grado di essere trattate. Come ultimo punto si consideri il successo che stanno incontrando le infrastrutture di messaggistica (i famosi MOM, Messaging Oriented Middleware) nei sistemi di nuova generazione e il protocollo XML: evidentissimo come molte delle interfacce quelle relative allo scambio di messaggi tra dispositivi fisici risultino prime versioni dei messaggi che viaggeranno nel sistema. Dunque iniziare a progettare anticipatamente questi messaggi agevola il processo di produzione del software.

Ricapitolando, vantaggioso realizzare la definizione formale delle interfacce gi durante la fase di analisi dei requisiti, perch: favorisce la definizione dei confini del sistema; offre ottimi spunti al modello dei casi duso; fornisce preziose informazioni o permette di bilanciare il modello a oggetti dominio; agevola lindividuazione delle interfacce dei sistemi basati sui componenti; favorisce la definizione dei messaggi circolanti nel sistema, qualora si ricorra ad uninfrastruttura di messaggistica.

La tab. 5.2 presenta un template rivelatosi utile per lanalisi iniziale delle interfacce sistema/attori. Qualora si desideri analizzare interazioni, specificatamente sistema/attori umani, probabilmente potrebbe risultare pi opportuno, considerati i vari tool a disposizione, definire un prototipo di interfaccia utente con tutti i rischi del caso (cliente che confonde il prototipo con il sistema finale, perdita di generalit, ecc.) esaminati nei capitoli precedenti. Nella sezione dedicata alle informazioni generali necessario riportare il nome dellinterfaccia, il codice, la data e la versione. Per ci che concerne il campo codice, tipicamente, si preferisce ricorrere a identificatori mnemonici. Un possibile sistema di selezione del codice potrebbe consistere nellutilizzare:

18

Capitolo 5. Completamento dellanalisi dei requisiti

Tabella 5.2 Template utilizzato per lanalisi iniziale delle interfacce.


Informazioni generali.
NOME PROPOSTO: CODICE PROPOSTO: DATA: VERSIONE:

BREVE DESCRIZIONE:

Attori.
NOME: BREVE DESCRIZIONE: FORNITORE/ FRUITORE

OBIETTIVI:

Casi duso.
NOME: BREVE DESCRIZIONE: FORNITORE/ FRUITORE

OBIETTIVI:

Definizione interfaccia.
GRUPPO CLASSE NEL DOM (Se presente) NOME ATTRIBUTO TIPO/DIM OBBL. DESCRIZIONE

Occorrenze
GRUPPO NOME ATTRIBUTO # DESCRIZIONE

Osservazioni:
CODICE AUTORE DESCRIZIONE STATO DATA

le prime tre lettere fisse al fine di indicare che si tratta della definizione di uninterfaccia (per esempio INT);

UML e ingegneria del software: dalla teoria alla pratica

19

un carattere atto ad individuare la fase del ciclo di vita di appartenenza del documento (ad esempio B = business, R = requirements, A =analysis, ecc.); tre lettere indicanti lattore principale (per esempio AMM = amministratore); sei lettere indicante il contenuto (per esempio PRFUTN = per profili utente). Nella sezione attori, come lecito attendersi, si dichiarano le entit esterne al sistema che utilizzano linterfaccia, la relativa descrizione e i motivi che inducono lutente ad utilizzare linterfaccia stessa (obiettivi). In particolare opportuno specificare se si tratta di un attore che fornisce i dati specificati nellinterfaccia o se li riceve dal sistema. Lintera sezione va ripetuta per tutti gli attori che interagiscono attraverso linterfaccia stessa. Per ci che concerne la sezione dedicata ai casi duso, il discorso del tutto analogo a quanto riportato pocanzi per gli attori. Nel caso generale, linterfaccia pu essere utilizzata da diversi attori e casi duso. Nella definizione degli attributi che compongono linterfaccia, necessario tener