1 Uniﬁed Modelling Language - unirc.it · Ovviamente oﬀre un supporto eccellente per i...

1

Unified Modelling Language

In questo capitolo illustreremo i fondamenti di UML (Unified Modelling Language). Dopo una bre-ve introduzione presenteremo le caratteristiche generali di UML. Successivamente descriveremo unarapida storia di UML. Dopo di cio presenteremo i costituenti fondamentali di UML e i meccanismicomuni di tale linguaggio.

1.1 Cos’e UML

Lo Unified Modelling Language (nel seguito, UML) e un linguaggio visuale di modellazione dei sistemi,di uso generico.

Anche se UML viene tipicamente associato alla modellazione dei sistemi software Object Orien-ted (nel seguito, OO), in realta ha un campo di utilizzo molto piu ampio, grazie ai meccanismi diestendibilita di cui e provvisto.

UML e stato studiato per incorporare tutte le migliori pratiche di modellazione e di ingegneria delsoftware correntemente utilizzate. I diagrammi UML sono, per noi umani, leggibili, se non immediati,eppure possono essere facilmente generati da computer.

E importante comprendere che UML non fornisce alcuna metodologia di modellazione. Ovviamente,alcuni aspetti metodologici sono impliciti negli elementi che costituiscono un modello UML; tuttaviaUML fornisce esclusivamente la sintassi da utilizzare per la costruzione dei modelli.

Lo Unified Process (nel seguito, UP), invece, e una metodologia: indica le risorse, le attivita e imanufatti che devono essere utilizzati, effettuati e creati per modellare un sistema software.

UML non vincola all’uso di una specifica metodologia e, anzi, puo essere utilizzato con tutte lemetodologie esistenti. UP utilizza UML come sintassi visuale di modellazione e si potrebbe dunquepensare che UP sia la metodologia preferita da utilizzare assieme ad UML. Anche se sicuramente UPe la metodologia che meglio si adatta ad UML, UML stesso puo fornire (e fornisce) supporto allamodellazione visuale anche ad altre metodologie1.

Lo scopo di UML e di UP e sempre stato quello di supportare e incorporare le migliori prati-che utilizzate dall’ingegneria del software basandosi sull’esperienza maturata nell’ultimo decennio. Perassolvere questo scopo UML e UP unificano i precedenti tentativi di definire un linguaggio di model-lazione visuale e un processo di ingegneria del software in quella che rappresenta la migliore soluzioneevolutiva.

1.2 Una breve storia di UML

Prima del 1994 c’era molta confusione nel mondo dei metodi OO. Esistevano diversi linguaggi dimodellazione visuale e diverse metodologie, ciascuno con i propri punti di forza e le proprie debolezze,ciascuno con i propri sostenitori e i propri detrattori.

Per quanto riguarda i linguaggi di modellazione visuale, i leader riconosciuti erano Booch (con ilmetodo Booch) e Rumbaugh (con il metodo Object Modelling Technique, OMT) che si spartivano piudella meta del mercato.1 Un esempio specifico di metodologia matura che utilizza UML come sintassi visuale e OPEN (Object-

oriented Process, Environment and Notation).

6 1 Unified Modelling Language

Per quanto riguarda le metodologie, Jacobson era di gran lunga avanti a tutti dato che, anche semolti autori sostenevano di avere un “metodo”, in realta in molti casi si trattava solo di una sintassidi modellazione visuale affiancata da un insieme di aforismi e indicazioni piu o meno utili.

Nel 1994 ci fu il primo tentativo di unificazione, il metodo Fusion di Coleman. Tuttavia, per quantolodevole, questo tentativo non coinvolse affatto gli autori originali dei metodi costituenti (Booch,Jacobson e Rumbaugh) e, inoltre, ci volle troppo tempo per giungere alla pubblicazione di un libroche spiegasse il metodo.

Fusion venne rapidamente sopraffatto dal corso degli eventi quando, sempre nel 1994, Booch eRumbaugh si unirono alla Rational Corporation per lavorare su UML.

Nel 1996, l’Object Management Group (nel seguito, OMG) produsse una RFP (Request forProposal) per un linguaggio di modellazione visuale OO, a cui venne sottoposto UML.

Nel 1997 l’OMG approvo UML e nacque cosı il primo standard non proprietario dell’industria perun linguaggio di modellazione visuale. Da allora tutti gli altri metodi che facevano concorrenza adUML sono caduti in disuso e UML resta l’unico linguaggio di modellazione OO standard dell’industria.

Dalla meta degli anni 2000 e stato rilasciato UML 2.0. In questa versione UML e un linguaggio dimodellazione maturo.

UML 2 ha introdotto una nuova sintassi visuale, che in parte sostituisce e chiarisce la sintassi diUML 1.x e in parte e completamente nuova e da semantica al linguaggio. UML ha sempre messo adisposizione varie opzioni di visualizzazione per ogni specifico elemento del modello; non tutte questemodalita saranno supportate da ogni strumento di modellazione.

Sebbene UML 2 presenti parecchi cambiamenti sintattici rispetto a UML 1.x, l’aspetto positivo eche i principi fondamentali sono rimasti uguali.

I modellatori che sono abituati a usare le versioni precedenti di UML non avranno problemi conUML 2. I cambiamenti piu radicali introdotti in UML, infatti, sono stati apportati al meta-modelloUML, quindi la maggior parte dei modellatori non dovra preoccuparsene. Il metamodello UML e unmodello del linguaggio UML che viene espresso in un sottoinsieme di UML e definisce con precisione lasintassi e la semantica di tutti gli elementi di modellazione UML. Questi cambiamenti al meta-modellohanno aumentato di molto la precisione e la coerenza della specifica di UML.

1.3 Caratteristiche generali dell’UML

L’unificazione operata da UML non deve essere vista esclusivamente in senso storico. UML vuole essereun linguaggio unificante anche sotto altri aspetti:

• Ciclo di sviluppo: UML fornisce una sintassi visuale per la modellazione di tutte le fasi del ciclo disviluppo, dall’analisi dei requisiti all’implementazione.

• Domini applicativi: UML e stato utilizzato per modellare un’ampia gamma di sistemi, da quelliembedded, che lavorano in tempo reale, a quelli gestionali, per il supporto alle decisioni.

• Linguaggi e piattaforme di sviluppo: UML e indipendente dal linguaggio di sviluppo e dalla piat-taforma. Ovviamente offre un supporto eccellente per i linguaggi OO puri (Smalltalk, Java, C#),ma e anche utile per linguaggi OO ibridi, come il C++, o linguaggi basati sugli oggetti, come ilVisual Basic. E stato anche utilizzato per la modellazione basata su linguaggi non OO, come il C.

• Processi di sviluppo: anche se UP e le sue varianti sono i processi di sviluppo preferiti per i sistemiOO, UML puo supportare (e supporta) molti altri processi di sviluppo del software.

La premessa fondamentale di UML e la possibilita di modellare i sistemi software (ma non solo)come insiemi di oggetti che collaborano tra loro. Questo approccio ovviamente e molto adatto ai sistemisoftware e ai linguaggi OO, ma si presta molto bene per modellare i processi aziendali e altri settoriapplicativi.

Un modello UML ha due aspetti:

• struttura statica: riguarda i tipi di oggetti necessari per modellare il sistema e come sono tra lorocorrelati;

• comportamento dinamico: riguarda il ciclo di vita di questi oggetti e come collaborano per fornirele funzionalita richieste al sistema.

1.5 Struttura di UML 7

Questi due aspetti del modello UML sono complementari: nessuno dei due e completo senza l’altro.Un oggetto puo essere visto come un insieme aggregato di dati e comportamenti. In altre parole,

gli oggetti possono contenere informazioni e possono eseguire funzioni.

1.4 La Model Driven Architecture

Il futuro di UML puo essere definito da una recente iniziativa dell’OMG chiamata Model DrivenArchitecture (nel seguito, MDA).

La MDA definisce una visione di come il software puo essere sviluppato partendo da un modello.L’essenza di questa visione e che i modelli guidano la produzione dell’architettura software eseguibile.In un certo senso cio accade oggi, ma la MDA consente un grado di automazione di questo processoche finora raramente e stato raggiunto.

Secondo la MDA il software viene prodotto applicando al modello una serie di trasformazioni conl’aiuto di uno strumento di modellazione MDA.

Un Computer-Independent Model (nel seguito, CIM) astratto viene usato come base per unPlatform-Independent Model (nel seguito, PIM). Il PIM viene poi trasformato in un Platform-SpecificModel (nel seguito, PSM) che viene trasformato in codice.

La nozione di modello dell’MDA e abbastanza generale e il codice e considerato un tipo moltoconcreto di modello.

Il CIM e un modello di astrazione molto elevato che contiene i requisiti base del sistema e ilvocabolario del dominio del problema in un modo indipendente dai computer. Si tratta in realta diun modello di quella parte del business che si vorrebbe automatizzare. La creazione di questo modelloe opzionale ma, una volta creato, puo essere usato come base per produrre il PIM.

Il PIM e un modello che esprime la semantica di business del sistema indipendentemente dallapiattaforma software (ad esempio, .NET). Questa completezza e indispensabile perche il PIM devefornire una base sufficientemente completa per essere trasformata in un PSM, da cui puo esseregenerato il codice.

Strumenti MDA diversi supportano livelli diversi di indipendenza dalla piattaforma.Il PIM deve essere arricchito da informazioni specifiche della piattaforma per creare il PSM.Il codice sorgente e generato per la piattaforma di destinazione a partire dal PSM. In teoria il

100% del codice sorgente e tutti gli altri artefatti, quali documentazione, strutture di test, file diconfigurazione e descrittori di deployment possono essere generati partendo da un PSM sufficiente-mente completo. Se cio accade, il modello UML deve essere reso computazionalmente completo; inaltre parole la sua semantica deve essere completamente specificata usando un linguaggio di azione.

Alcuni strumenti MDA comprendono gia un linguaggio di azione. Per esempio, lo strumento iUMLfornisce l’Action Specification Language (nel seguito, ASL) che soddisfa la semantica di azione di UML2. Questo linguaggio di azione e a un livello piu elevato rispetto a linguaggi come Java e C++ e puoessere usato per crare modelli UML computazionalmente completi.

Altri strument MDA come ArcStyler consentono la generazione del 70%-90% del codice e dialtri manufatti, ma il corpo delle operazioni dovra ancora essere completato nel linguaggio diimplementazione (per esempio, Java).

Nella visione dell’MDA il codice sorgente, per esempio il codice Java e C#, e solo il “codicemacchina” che si ottiene dalla compilazione di modelli UML. Questo codice e generato direttamentedal PSM. Il codice, quindi, nello sviluppo dell’MDA ha un valore intrinsecamente inferiore ai modelliUML. L’MDA sposta i modelli UML dal loro ruolo attuale di precursori del codice sorgente creatomanualmente al ruolo di meccanismo primario per la produzione di codice.

Sempre piu fornitori di strumenti di modellazione aggiungono capacita MDA ai loro prodotti. Peri dettagli piu recenti si puo consultare il sito Web dell’MDA di OMG. Esistono anche alcune iniziativeopen source sull’MDA molto promettenti, per esempio Eclipse Modeling Framework o AndroMDA.

1.5 Struttura di UML

Per capire come UML possa funzionare come linguaggio visuale, possiamo iniziare a esaminarne lastruttura. Questa e composta da:


• costituenti fondamentali: gli elementi, le relazioni e i diagrammi di base di UML;• meccanismi comuni: tecniche comuni per raggiungere specifici obiettivi con UML;• architettura: il modo in cui UML esprime l’architettura del sistema.

1.5.1 Costituenti fondamentali UML

UML e composto da tre soli costituenti fondamentali:

• entita: sono gli elementi di modellazione;• relazioni: legano tra loro le entita; le associazioni definiscono come due o piu entita sono

semanticamente correlate;• diagrammi: le viste dei modelli UML mostrano insiemi di elementi che “raccontano una storia”

che riguarda un sistema software; sono lo strumento da usare per visualizzare cosa fara un sistema(diagramma di analisi) e come lo fara (diagramma di progettazione).

Nelle prossime tre sottosezioni saranno approfonditi meglio i concetti di entita, relazioni ediagrammi.

Entita

Le entita in UML possono essere suddivise in quattro categorie:

• entita strutturali: rappresentano i sostantivi di un modello UML, quali classe, interfaccia, collabo-razione, caso d’uso, classe attiva, componente, nodo;

• entita comportamentali: denotano i verbi di un modello UML, quali interazioni e macchine a stati;• entita di raggruppamento: essa consiste nel package che viene utilizzato per raggruppare elementi

semanticamente correlati in unita coese;• entita informative: essa consiste nell’annotazione, che puo essere aggiunta al modello per fornire

informazioni particolari, in modo simile a un post-it.

Questi elementi saranno esaminati piu da vicino nel seguito del corso.

Relazioni

In un modello le relazioni mostrano come due o piu entita sono correlate tra loro. Per farsi un’idea delruolo che le relazioni rivestono nei modelli UML, basta pensare a una famiglia e a tutte le relazionitra i vari familiari.

Le relazioni consentono di fissare i legami significativi (semantici) tra gli elementi. In un modello,le relazioni si possono applicare alle entita strutturali e alle entita di raggruppamento.

Diagrammi

In tutti gli strumenti di modellazione basati sull’UML, le nuove entita e relazioni che vengono createsono aggiunte al modello. Il modello e l’archivio di tutte le entita e le relazioni che sono state createper descrivere il comportamento del sistema software che si vuole progettare.

I diagrammi sono viste o finestre che consentono di vedere il contenuto del modello. Il diagrammanon e il modello! Questa distinzione e fondamentale. Un’entita o una relazione puo essere eliminatada un diagramma o anche da tutti i diagrammi, ma puo continuare ad esistere nel modello. In effetti,resta nel modello fin quando non ne viene esplicitamente eliminata. I principianti spesso commettonol’errore di eliminare le entita dei diagrammi, ma non dal modello.

Esistono tredici diversi tipi di diagrammi UML, mostrati nella Figura 1.1. Nella figura ogni riquadrorappresenta un diverso tipo di diagramma. Quando il testo nel riquadro e in corsivo, rappresenta unacategoria astratta di tipi di diagrammi. Il testo normale indica un diagramma concreto che si puorealmente creare. I riquadri in grigio indicano tipi concreti di diagramma introdotti in UML 2.

Di solito questi diagrammi vengono suddivisi tra quelli che modellano la struttura statica delsistema (il cosiddetto modello statico) e quelli che modellano la struttura dinamica del sistema (ilmodello dinamico). Il modello statico fissa le entita e le relazioni strutturali tra le entita; il modello


Figura 1.1. I diversi tipi di diagrammi UML

dinamico fissa il modo in cui le entita interagiscono per generare il comportamento richiesto al sistemasoftware.

Non e necessario seguire un determinato ordine nella creazione dei diagrammi UML, anche setipicamente si comincia con un diagramma dei casi d’uso, per definire lo scopo del sistema. In effetti,spesso si lavora in parallelo su piu diagrammi, ridefinendo meglio ciascuno di essi, man mano chesi scoprono e si mettono a fuoco informazioni e dettagli aggiuntivi sul sistema software che si staprogettando.

I diagrammi costituiscono, dunque, non solo una vista del modello ma anche il principale strumentoper aggiungere nuove informazioni al modello.

UML 2 introduce una nuova sintassi per i diagrammi, illustrata in Figura 1.2. Ogni diagrammapuo avere un frame, un’area di intestazione e un’area dei contenuti.

Figura 1.2. La sintassi per i diagrammi UML

L’area di intestazione e un pentagono irregolare che contiene il tipo del diagramma (opzionale), ilnome e i parametri (opzionali).

Il tipo specifica il tipo del diagramma che, in genere, dovrebbe appartenere alla lista dei tipidi diagrammi specificati nella Figura 1.1. La specifica di UML specifica che il nome del tipo si puoabbreviare ma non fornisce un elenco di abbreviazioni standard. Comunque, non e quasi mai necessariospecficiare il tipo esplicitamente perche di solito e chiaro dalla sintassi.

Il nome dovrebbe descrivere la semantica del diagramma.I parametri forniscono le informazioni necessarie per includere gli elementi del modello presenti nel

diagramma.Opzionalmente un diagramma puo contenere un frame implicito. Questo accade quando il frame e

sottointeso perche delimita l’area del diagramma nello strumento di modellazione.

1.5.2 Meccanismi comuni di UML

UML prevede quattro meccanismi comuni che vengono applicati in modo consistente in tutto il lin-guaggio. Esse descrivono quattro diverse strategie alla modellazione OO che possono essere applicatee riapplicate in diversi contesti UML.

Specifiche

I modelli UML possiedono almeno due dimensioni: una grafica, che consente di visualizzare il mo-dello utilizzando diagrammi e icone, e una testuale, costituita dalle specifiche dei vari elementi dimodellazione.


Le specifiche sono la descrizione testuale della semantica di un elemento.Si puo, per esempio, rappresentare graficamente una classe, in questo caso la classe ContoBancario,

come un rettangolo suddiviso in rettangoli piu piccoli (Figura 1.3). Tuttavia, questa semplice rappre-sentazione non da alcuna informazione sul significato funzionale di quella classe. La semantica sotto-stante gli elementi di modellazione e fissata nelle loro specifiche, e senza queste specifiche non si puofar altro che tentare di indovinare cio che gli elementi di modellazione rappresentano effettivamente.

Figura 1.3. Un esempio di specifiche

L’insieme delle specifiche costituisce il vero “contenuto” del modello, quel substrato semantico chetiene insieme il modello e lo riempie di significato. I diagrammi sono solo viste o proiezioni visuali delcontenuto del modello.

Questo substrato semantico viene tipicamente aggiornato utilizzando uno strumento di modellazio-ne UML che consente l’immissione, la visualizzazione e la modifica delle specifiche di ciascun elementodi modellazione.

UML offre una grande flessibilita durante la costruzione di un modello. In particolare, un modellopuo essere:

• parzialmente nascosto: alcuni elementi possono esistere nel modello, ma essere nascosti in alcunidiagrammi, in modo da semplificarne la visualizzazione;

• incompleto: alcuni elementi del modello possono essere del tutto assenti;• inconsistente: il modello puo contenere incongruenze.

E molto importante che i vincoli di completezza e consistenza non siano rigidi. Si vedra, infatti, chei modelli evolvono nel tempo e sono sottoposti a molte modifiche. Tuttavia e pur sempre necessarioaspirare ad un modello sufficientemente consistente e completo, in modo da consentire la costruzionedi un sistema software.

Una pratica UML diffusa e quella di cominciare con un modello per lo piu grafico, che consente diiniziare a visualizzare il sistema, e successivamente aggiungere significato al substrato semantico manmano che il modello si evolve.

Tuttavia, affinche un modello possa essere considerato utile o completo, e necessario che le speci-fiche del modello siano presenti. Se non lo fossero non si ha veramente un modello ma solo un insiemesenza significato di rettangoli e figure connessi da linee!

In effetti, un errore di modellazione comunemente commesso dai principianti e proprio la “morteda diagrammi”: il modello ha troppi diagrammi e troppe poche specifiche.

Ornamenti

Una caratteristica molto utile di UML e che ogni elemento di modellazione viene rappresentato da unsimbolo a cui e possibile aggiungere degli ornamenti che rendono visibili gli aspetti particolari dellaspecifica dell’elemento.

Usando tale meccanismo si puo adattare la quantita di informazioni presenti nel diagramma allespecifiche necessita.

Questo vuol dire che si puo iniziare a costruire un modello molto astratto usando i simboli base,aggiungendo magari uno o due ornamenti, per poi rifinire progressivamente il diagramma aggiungendonuovi ornamenti, fin quando il modello non contiene tutti i dettagli che servono.


E importante ricordarsi che ogni diagramma e solo una vista sul modello. Per questo motivosi dovrebbero visualizzare solo quegli ornamenti che evidenziano le piu importanti caratteristichedel modello e aumentano la chiarezza e la leggibilita del diagramma. Non e necessario far vederetutto su ciascun diagramma: e molto piu importante che il diagramma sia comprensibile, che illustriesattamente cio che deve illustrare e che sia di facile lettura.

La Figura 1.4 mostra che il simbolo minimo per rappresentare una classe e un rettangolo conte-nente il nome della classe. Tuttavia e possibile estendere questa vista minimalista, esponendo ulterioricaratteristiche del modello sottostante utilizzando degli ornamenti. Il testo grigio della figura indicadei possibili ornamenti facoltativi.

Figura 1.4. Un esempio di ornamenti

Distinzioni comuni

Le distinzioni comuni descrivono i diversi modi di ragionare sul mondo che ci circonda. UML prevededue distinzioni comuni: classificatore/istanza e interfaccia/implementazione.

Classificatore e istanza

UML consente di definire sia la nozione astratta di un certo tipo di entita (per esempio, un contobancario), sia le specifiche e concrete istanze di quella stessa astrazione (il “mio conto bancario” o il“tuo conto bancario”).

La nozione astratta di un tipo di entita e un “classificatore”, mentre le entita specifiche e concretesono “istanze”. Questo e un concetto molto importante ma, al tempo stesso, facile da comprendere.Siamo circondati da esempi di classificatori e istanze. La distinzione classificatore/istanza e un concettofondamentale che permea UML.

In UML un’istanza, di solito, ha la stessa icona del corrispondente classificatore, ma il nome del-l’icona, nel caso di un’istanza, e sottolineato. Questa piccola distinzione grafica puo essere, all’inizio,difficilmente notata.

UML definisce una ricca tassonomia formata da 33 classificatori. I classificatori piu comuni sonoriportati nella Tabella 1.1.

Classificatore Descrizione

Attore Un ruolo svolto da un utente esterno del sistema a cui il sistema fornisce del valore aggiuntoClasse Una descrizione di un insieme di oggetti che condividono le stesse caratteristicheComponente Una parte modulare e sostituibile di un sistema che incapsula i suoi contenutiIntefaccia Un insieme di operazioni che vengono usate per definire il servizio offerto da una classe o da un componenteNodo Un elemento fisico presente a run time che rappresenta una risorsa computazionale, per esempio un PCSegnale Un oggetto asincrono che viene passato da un oggetto ad un altroCaso d’uso Una descrizione di una sequenza di azioni che un sistema effettua per fornire ad un utente un valore aggiunto

Tabella 1.1. I classificatori piu comuni


Interfaccia e implementazione

Questa distinzione serve per separare cosa fa un oggetto (la sua interfaccia) da come lo fa (la suaimplementazione). Per esempio, guidando un’automobile si interagisce con un’interfaccia molto sem-plice e ben definita. Questa interfaccia puo essere implementata in modo molto differente da ogniautomobile.

Un’interfaccia definisce un contratto (che ha molto in comune con un contratto legale) che lespecifiche implementazioni garantiscono di rispettare. La separazione tra quanto un oggetto promettedi fare e l’effettiva implementazione di quella promessa e un concetto UML molto importante.

E facile trovare intorno a noi esempi concreti di interfacce e implementazioni. Per esempio, ipulsanti sul pannello di un videoregistratore forniscono un’interfaccia (relativamente) semplice dicio che in realta e un meccanismo piuttosto complesso. L’interfaccia protegge l’utente da questacomplessita, nascondendola.

Meccanismi di estendibilita

Gli ideatori di UML si resero conto che era impossibile progettare un linguaggio di modellazionecompletamente universale, che potesse soddisfare le esigenze di tutti, oggi e domani.

Per questo motivo, UML incorpora tre semplici meccanismi di estendibilita; questi vengonoapprofonditi nelle prossime sottosezioni.

Vincoli

Un vincolo e una frase di testo racchiusa tra parentesi graffe che definisce una condizione o una regolache riguarda l’elemento di modellazione e che deve risultare sempre vera.

In altre parole, il vincolo limita in qualche modo qualche caratteristica dell’elemento in questione.UML definisce un linguaggio di vincoli chiamato Object Constraint Language (nel seguito, OCL).

Stereotipi

Uno stereotipo rappresenta una variazione di un elemento di modellazione esistente che ha la stessaforma (quali attributi e relazioni) ma un diverso scopo.

Gli stereotipi consentono di introdurre nuovi elementi di modellazione basandosi sugli elementiesistenti.

Si usano facendo seguire al nuovo elemento il nome dello stereotipo tra parentesi angolari (≪ ... ≫).Ogni elemento di modellazione puo non avere stereotipi o averne molti.

Ogni stereotipo puo definire un insieme di valori e di vincoli che saranno applicati all’elementostereotipato. Si puo anche associare allo stereotipo una nuova icona, un colore o un motivo di sfondo.

Dato che gli stereotipi introducono nuovi elementi di modellazione con un diverso scopo, e necessa-rio definire la semantica di questi nuovi elementi. A tal fine, qualora lo strumento di modellazione nonfornisca supporto per la documentazione degli stereotipi, la maggior parte dei modellatori aggiungeun’annotazione al modello o inserisce un collegamento a un documento esterno in cui viene definitolo stereotipo.

Attualmente il supporto per gli stereotipi offerto dagli strumenti di modellazione e incompleto:anche se molti strumenti offrono un supporto limitato per l’uso degli stereotipi, non tutti consentonola definizione della parte semantica.

Valori etichettati

In UML si definisce proprieta un qualunque valore associato a un elemento di modellazione.Molti elementi hanno un gran numero di proprieta predefinite. Alcuni di queste sono visualizzabili

nei diagrammi mentre altre fanno parte esclusivamente del substrato semantico del modello.UML consente di utilizzare i valori etichettati per aggiungere nuove proprieta agli elementi di

modellazione.Il valore etichettato e un concetto molto semplice: e un nome o un identificatore a cui e possibile

associare un valore. La sintassi e la seguente: { etichetta1 = valore1, etichetta2 = valore2, ..., etichettaN = valoreN }.


Alcune etichette rappresentano semplicemente informazioni aggiuntive da applicare agli elementidi modellazione.

Tuttavia altre etichette possono definire proprieta di nuovi elementi di modellazione definiti dauno stereotipo. In questo caso non si dovrebbero associare i valori etichettati agli elementi modellatima direttamente allo stereotipo stesso. In questo modo, quando lo stereotipo sara applicato ad unelemento di modellazione questi sara automaticamente arricchito con tutte le corrispettive etichette.

Profili UML

Un profilo UML e un insieme di stereotipi, valori etichettati e vincoli.I profili si usano per personalizzare UML per un uso specifico.Per esempio, se si desidera usare UML per modellare un’applicazione .NET si puo utilizzare il

profilo UML per .NET.Ogni stereotipo in un profilo estende uno degli elementi del meta-modello UML (per esempio,una

Classe o un’Associazione) per creare un nuovo elemento personalizzato. Lo stereotipo puo definirenuove etichette e vincoli che non facevano parte dell’elemento originale.

2

Lo Unified Process

Questo capitolo e dedicato allo Unified Process, un processo di ingegneria del software ideato daglistessi autori di UML. Dopo una breve introduzione dell’UP, illustreremo la sua storia. Dopo di ciodescriveremo la differenza tra UP e RUP, il modo di istanziare l’UP su un progetto, gli assiomi dell’UP,il processo iterativo e incrementale alla base dell’UP, la struttura dell’UP e le sue fasi.

2.1 Introduzione allo Unified Process

Un Software Development Process (nel seguito, SDP), detto anche Software Engineering Process (nelseguito, SEP), definisce il chi, il cosa, il quando e il come dello sviluppo del software.

Lo Unified Software Development Process (nel seguito, USDP) e il SEP ideato dagli stessi autoridi UML; tale SEP viene comunemente chiamato Unified Process (nel seguito, UP).

In origine il progetto UML doveva fornire sia un linguaggio visuale sia un processo di ingegneriadel software. Cio che oggi conosciamo UML rappresenta solo la parte relativa al linguaggio visuale;UP e, invece, la parte relativa al processo.

Tuttavia, vale la pena sottolineare che mentre UML e stato standardizzato dall’OMG, UP non estato standardizzato. Non esiste, percio, ancora alcun SEP standard basato su UML.

UP si basa sul lavoro relativo al processo software svolto dalla Ericsson (Ericsson approach) nel1967, dalla Rational (Rational Objectory Process) tra il 1996 e il 1997, e su altre esperienze. Per questomotivo UP e un metodo per lo sviluppo del software pragmatico e maturo, che incorpora le migliorepratiche messe a punto dai suoi predecessori.

2.2 Storia di UP

Studiando la storia di UP si puo sostenere che il suo sviluppo e principalmente legato alla carrieradi una persona, Ivar Jacobson. In effetti molti considerano Jacobson il padre di UP. Con questaaffermazione non si vuole minimizzare il lavoro di tutti gli altri individui (specialmente di Booch) chehanno partecipato allo sviluppo di UP. Piuttosto si vuole evidenziare il contributo insostituibile diJacobson.

UP ha le sue origini nel lontano 1967, con l’approccio della Ericsson, che intraprese la strada ra-dicale di modellare un sistema complesso con un insieme di blocchi interconnessi. Blocchi piu piccolivenivano collegati tra loro a formare blocchi sempre piu grandi i quali, infine, costituivano e descrive-vano un sistema completo. Questa tecnica, oggi conosciuta come Component-Based Development (nelseguito, CBD), ha le sue radici nel concetto di divide et impera.

Un’altra innovazione introdotta dalla Ericsson era il modo in cui identificava questi blocchi, creandodei “casi di traffico” che descrivevano come il sistema doveva essere usato. Questi “casi di traffico” sisono evoluti in cio che oggi, nell’UML, vengono chiamati “casi d’uso”.

La successiva e piu importante dell’ingegneria del software Object Oriented accadde nel 1980 quan-do il CCITT, ente internazionale per gli standard, rilascio lo Specification and Description Language(nel seguito, SDL). L’SDL fu uno dei primi linguaggi di modellazione visuale basato sugli oggetti. Nel1992 fu ampliato con classi ed ereditarieta per farlo diventare orientato agli oggetti. L’SDL-92 fu ilprimo standard per la modellazione a oggetti universalmente accettato e viene utilizzato ancora oggi.

16 2 Lo Unified Process

Nel 1987 Jacobson fondo a Stoccolma la Objectory AB. Questa societa sviluppo e mise sul mercatoun processo per l’ingegneria del software, basato sull’approccio della Ericsson, che si chiamava Objec-tory (da Object Factory: Fabbrica degli Oggetti). Il SEP Objectory era costituito da un insieme didocumentazione standard, uno strumento CASE di non immediato utilizzo e un servizio di consulenzadella Objectory AB, di cui probabilmente era difficile fare a meno.

Objectory era un framework di processo e richiedeva una notevole attivita di personalizzazione pri-ma di poter essere applicato a uno specifico progetto. Anche se il processo Objectory veniva distribuitocorredato da alcuni modelli standard da applicare ai diversi tipi di progetti di sviluppo software, eraquasi sempre necessario personalizzarlo ulteriormente. Jacobson intuı che tutti i progetti di svilupposoftware sono diversi e che non era ne ipotizzabile, ne auspicabile riuscire a mettere a punto un SEP“per tutti gli usi”.

Quando la Rational acquisı la Objectory AB nel 1995, Jacobson inizio a dedicarsi all’unificazionedel processo Objectory con tutto il lavoro relativo al processo software che era stato svolto in Rational,che non era poco. Sviluppo cosı una vista “4+1” dell’architettura, basata, appunto, su quattro vistedistinte (logica, di processo, fisica e di sviluppo) piu una vista dei casi d’uso che teneva insieme lealtre. Questa idea si trova ancora oggi alla base dell’approccio che UP e UML hanno nei confrontidell’architettura del sistema.

Venne formalizzato, inoltre, il concetto di sviluppo iterativo, basato su una sequenza di fasi (avvio,elaborazione, costruzione e transizione), che combina la rigidita del ciclo di vita a “cascata” con ladinamicita e la capacita di reazione dello sviluppo iterativo incrementale.

I personaggi che hanno maggiormente contribuito a questo metodo sono stati: Walker Royce, RichReitmann, Grady Booch (ideatore del metodo Booch) e Philippe Krutchen. In particolare, nell’Approc-cio Rational fu incorporata gran parte dell’esperienza di Booch e delle sue idee innovative concernentil’architettura.

Rational Objectory Process (nel seguito, ROP) fu il risultato dell’unificazione di Objectory e dellavoro sul processo software svolto dalla Rational. ROP, in particolare, apporto dei miglioramentiladdove Objectory era piu debole: requisiti diversi dai casi d’uso, implementazione, test, gestione delprogetto, deployment, gestione della configurazione e ambiente di sviluppo.

Fu introdotto il concetto di rischio come elemento che pilota il processo, fu definita l’architettura e siformalizzo la sua qualita di manufatto consegnabile chiamato “descrizione dell’architettura”. Durantequesto periodo, in Rational, Booch, Jacobson e Rumbaugh stavano sviluppando UML che divenne illinguaggio utilizzato per esprimere sia i modelli ROP, sia ROP stesso.

A partire dal 1997 la Rational acquisı molte altre societa e con esse altri esperti di analisi deirequisiti, gestione della configurazione, test e altro. Fu cosı che si giunse, nel 1998, al rilascio delRational Unified Process (nel seguito, RUP). Da allora si sono susseguite diverse nuove versioni diRUP, ciascuna delle quali ha apportato notevoli migliorie.

Nel 1999 e stato pubblicato un testo importante “The Unified Software Development Process” chedescrive UP. Mentre RUP e un prodotto della Rational, UP e un SEP non proprietario creato dagliautori d UML. Non sorprende certo che UP e RUP siano parenti molto stretti.

2.3 UP e RUP

RUP e una versione commerciale di UP creata da IBM che rilevo la Rational Corporation nel 2003.Esso mette a disposizione tutti gli standard, gli strumenti e altri elementi che non sono inclusi in

UP ma che sarebbe “comunque” necessario procurarsi. Esso fornisce via Web anche un ricco ambientedi supporto che include un’ampia documentazione del processo e dei tool mentor (esperti di strumento)per ciascuno degli strumenti Rational.

Nel non lontano 1999 RUP veniva generalmente considerato come una semplice implementazionecommerciale di UP. Tuttavia, da allora RUP ha fatto molta strada e oggi estende UP significativamentein molti modi. Oggi UP deve essere considerato come una classe base generica non proprietaria di cuiRUP e una sottoclasse commerciale specifica che estende e ridefinisce alcune delle caratteristiche diUP.

RUP e UP restano, comunque, fondamentalmente piu simili che diversi. La differenza principaleriguarda la completezza e il livello di dettaglio e non le differenze semantiche o ideologiche.

2.3 UP e RUP 17

I flussi di lavoro di base per l’analisi e la progettazione Object Oriented sono sufficientemente similie una discussione impostata dal punto di vista di UP e del tutto valida anche per chi gia conosce eutilizza RUP.

UP e RUP modellano entrambi il chi, il quando e il cosa del processo di sviluppo del software malo fanno in modo leggermente diverso.

L’ultima versione di RUP (RUP 2001) presenta alcune differenze di termini e di sintassi rispettoa UP, anche se mantiene essenzialmente la stessa semantica degli elementi del processo.

La Figura 2.1 illustra come le icone di processo di RUP 2001 corrispondano alle icone UP.

Figura 2.1. Icone di processo di RUP e UP

Si osservi l’uso della relazione <<traccia>> tra l’icona RUP 2001 e l’icona originale di UP. In UMLla relazione <<traccia>> e una dipendenza particolare tra elementi di modellazione che indica chel’elemento iniziale della relazione e uno sviluppo storico dell’elemento indicato dalla freccia. Questodescrive perfettamente la relazione tra gli elementi di modellazione di UP e RUP.

Per modellare il chi del SEP, UP introduce il concetto di risorsa. Questo concetto descrive il ruoloche un individuo o un gruppo ha all’interno di un progetto. Ogni risorsa umana puo consistere in piuindividui o gruppi e ciascun individuo puo contribuire a piu risorse divers. In RUP le risorse vengonochiamate ruoli, ma la semantica resta invariata.

UP modella il cosa come attivita e manufatti. Le attivita sono compiti che verranno eseguiti dagliindividui o dai gruppi che partecipano al progetto. Questi ultimi assumeranno un ruolo specifico pereseguire ciascuna attivita. UP (e RUP) indica, dunque, le risorse (ruoli) che partecipano a ciascunasingola attivita. Quando e necessario ottenere un maggior livello di dettaglio e possibile scomporre leattivita in sottoattivita piu piccole. Sia UP che RUP definiscono il flusso di lavoro come una sequenzadi attivita correlate.

RUP e UP descrivono il cosa di un SEP come manufatti. I manufatti sono materiale, di qualunquenatura, richiesto o prodotto dal progetto: codice sorgente, eseguibili, standard, documentazione, ecc.Per rappresentare i manufatti si possono utilizzare icone diverse. La Figura 2.1 mostra l’icona deldocumento generico.

UP modella il quando usando i flussi di lavoro, sequenze di attivita correlate che vengono eseguitedalle risorse umane. In RUP i flussi di lavoro di alto livello, per esempio Requisiti e Test, sono chiamatidiscipline. E possibile scomporre i flussi di lavoro in uno o piu dettagli che descrivono le attivita, iruoli e i manufatti coinvolti nel flusso di lavoro. In UP si fa riferimento a questi dettagli per nomementre in RUP viene assegnata a essi una specifica icona.


2.4 Istanziazione di UP su un progetto

UP e un processo generico di sviluppo del software e deve essere istanziato per ciascuna organizzazionee anche per ciascun progetto specifico. Questo e necessario perche tutti i progetti software sono traloro differenti. Semplicemente non esiste un SEP “per tutte le misure”.

Il processo di istanziazione consiste nella definizione e integrazione di:

• standard per il gruppo di lavoro;• modelli di documento standard;• strumenti, quali compilatori, gestori della configurazione, etc.;• archiviazione, per quanto riguarda la gestione dei difetti, la gestione del progetto, etc.;• modifiche del ciclo di vita, per esempio, strumenti piu sofisticati per il controllo del livello di qualita

per sistemi “safety-critical”.

Anche se RUP e molto piu completo di UP, e comunque necessario personalizzarlo e istanziarlo.La quantita di lavoro che si deve eseguire, pero, e decisamente inferiore a quella richiesta partendo daUP.

In effetti, per qualsiasi processo di ingegneria del software, in genere, bisogna investire una certaquantita di tempo e di denaro per l’istanziazione. Inoltre puo essere necessario preventivare alcuneconsulenze da parte del fornitore del SEP.

2.5 Assiomi di UP

UP e basato su tre assiomi fondamentali:

• e pilotato dai casi d’uso e dai fattori di rischio;• e incentrato sull’architettura;• e iterativo e incrementale.

I casi d’uso sono un modo per fissare i requisiti di un sistema. E, quindi, corretto dire che UP epilotato dai requisiti.

L’altro fattore che pilota UP e il rischio. L’idea di fondo e che se non vengono affrontati attiva-mente tutti i rischi individuati in un progetto, questi possono “aggredire” il progetto e consumarlo dadentro! Chiunque abbia lavorato in un progetto di sviluppo software sara sicuramente d’accordo conla precedente affermazione. UP affronta questo punto suggerendo una costruzione del software basatasull’analisi dei rischi.

UP prevede che lo sviluppo di un sistema software richieda la messa a punto di una solida ar-chitettura. L’architettura descrive gli aspetti strategici di un sistema, come questo sia scomposto incomponenti e come tali componenti interagiscano tra loro e debbano essere dislocati sui diversi nodihardware. E, dunque, ovvio che un’architettura di sistema di buona qualita potra consentire lo svi-luppo di un sistema di buona qualita e non, invece, di un insieme poco coeso di codice sorgente mesoinsieme con poca attenzione.

Infine, UP e iterativo e incrementale. Esso prevede, infatti, che il progetto venga scomposto in sot-toprogetti (o iterazioni) ciascuno dei quali portera al rilascio di qualche nuova funzionalita giungendo,dunque, al completamento del sistema in modo incrementale.

In altre parole il software viene costruito con un processo a passi successivi, ciascuno dei quali ciavvicina sempre piu all’obiettivo finale del progetto.

Questo approccio e profondamente diverso dal vecchio ciclo di vita a cascata, il quale prevede chele fasi di analisi, progettazione e costruzione si susseguano in modo rigido.

Sviluppando un progetto con UP si ripetono, invece, diverse volte, in tempi diversi, i flussi dilavoro principali, quali, per esempio, quello dell’analisi.

Pertanto, con UP, un progetto di sviluppo software viene scomposto in un certo numero di “mi-niprogetti” piu piccoli, ma piu facili da gestire e completare con successo. Ciascun “miniprogetto”diventa un’iterazione.

Il concetto chiave e che ciascuna iterazione contiene tutti gli elementi di un tipico progetto disviluppo software:

• pianificazione;

2.6 Iterazioni e flussi di lavoro 19

• analisi e progettazione;• costruzione;• integrazione e test;• un rilascio (esterno o interno).

Ogni iterazione porta al raggiungimento di una baseline, la quale comprende una versione parzial-mente completa del sistema finale, oltre alla relativa documentazione di progetto.

Le baseline si accumulano una sull’altra man mano che le iterazioni si susseguono, fino ad ottenereil sistema finale completo.

La differenza tra due baseline consecutive viene chiamata incremento: questo e il motivo per cuiUP e conosciuto come un ciclo di vita iterativo e incrementale.

Nel seguito si vedra che le iterazioni sono raggruppate in fasi. Le fasi forniscono la macrostrutturadi UP.

2.6 Iterazioni e flussi di lavoro

Esistono cinque fondamentali flussi di lavoro che specificano quali attivita debbano essere svolte inciascuna iterazione e le competenze richieste.

Oltre a questi cinque, esistono anche altri flussi di lavoro, quali quello della pianificazione e quellodella valutazione, che possono pero non essere applicabili a tutte le iterazioni.

UP, tuttavia, tratta esclusivamente dei cinque flussi di lavoro fondamentali:

• requisiti: fissa cio che il sistema dovrebbe fare;• analisi: mette a punto i requisiti e aggiunge loro struttura;• progettazione: concretizza i requisiti in un’architettura del sistema;• implementazione: costruisce il software;• test: verifica che l’implementazione rispetti i requisiti.

La Figura 2.2 illustra alcuni possibili flussi di lavoro per un’iterazione.

Figura 2.2. Alcuni possibili flussi di lavoro per un’iterazione

Anche se ciascuna iterazione puo prevedere tutti e cinque i flussi di lavoro, la collocazione dell’i-terazione all’interno del ciclo di vita del progetto determina una maggiore enfasi su uno dei flussi dilavoro.

La scomposizione del progetto in una serie di iterazioni consente di gestire la pianificazione diprogetto in modo piu flessibile.

L’approccio piu semplice e quello di sistemare le iterazioni in sequenza sulla scala temporale, inmodo che ciascuna iterazione abbia inizio quando quella precedente e conclusa

Tuttavia e spesso possibile pianificare le iterazioni in parallelo. Questo richiede una comprensionedelle dipendenze esistenti tra i manufatti che interessano ciascuna iterazione, ovvero implica che lo


sviluppo software venga basato sullo studio e la modellazione dell’architettura. Le iterazioni parallelepossono offrire diversi benefici, tra cui un minore tempo di rilascio e un migliore impiego delle risorse,tuttavia richiedono anche una migliore pianificazione.

Ogni iterazione UP genera una baseline. Questo e il rilascio (interno o esterno) dell’insieme dimanufatti, previsti e approvati, che sono stati generali da quell’iterazione. Ogni baseline:

• fornisce una base approvata per le successive attivita di analisi e sviluppo;• puo essere modificata esclusivamente tramite procedure formali di gestione della configurazione e

delle modifiche.

Gli incrementi, tuttavia, sono solo la differenza tra una baseline e quella successiva. Costituisconoun passo avanti verso il rilascio finale del sistema completo.

2.7 Struttura di UP

La Figura 2.3 illustra la struttura di UP.

Figura 2.3. Struttura di UP

Il ciclo di vita del progetto e suddiviso in quattro fasi:

• Avvio: riguarda gli obiettivi del ciclo di vita;• Elaborazione: riguarda l’architettura del ciclo di vita;• Costruzione: riguarda la capacita operativa iniziale;• Transizione: riguarda il rilascio del prodotto.

Ciascuna di queste fasi si conclude con un’importante milestone.Ogni fase puo essere composta da una o piu iterazioni. In ogni iterazione vengono eseguiti i cinque

flussi di lavoro fondamentali, oltre a eventuali flussi di lavoro aggiuntivi.Il numero esatto di iterazioni per fase dipende dalle dimensioni del progetto; le singole iterazioni

non dovrebbero, comunque, durare piu di due o tre mesi. L’esempio puo essere considerato tipico perun progetto di medie dimensioni della durata complessiva di circa 18 mesi.

La quantita di lavoro richiesta per ciascuno dei cinque flussi di lavoro fondamentali varia alpassaggio del progetto attraverso le diverse fasi d UP.

La Figura 2.4 e la chiave per comprendere come funzioni UP. In alto sono indicate le fasi delprocesso; sul lato sinistro ci sono i cinque flussi di lavoro fondamentali; in basso sono elencate alcu-ne iterazioni. Le curve rappresentano la quantita di lavoro dedicata a ciascuno dei flussi di lavorofondamentali man mano che il progetto procede, attraversando le diverse fasi.

La Figura 2.4 mostra che nella fase Avvio la maggior parte del lavoro viene svolto sul flusso deirequisiti e dell’analisi. Durante l’Elaborazione l’enfasi si sposta sui requisiti e, in parte, sulla progetta-zione. Durante la Costruzione l’enfasi e chiaramente sulla progettazione e sull’implementazione. Infine,durante la fase di Transizione l’enfasi e decisamente sull’implementazione e sui test.

Una delle principali caratteristiche di UP e quella di essere un processo basato su obiettivi e nonun processo basato su manufatti consegnabili. Ogni fase termina con una milestone che consiste in uninsieme di condizioni da soddisfare. Le milestone possono comportare la creazione di un manufattoparticolare, a seconda delle specifiche necessita del progetto.

2.8 Le fasi di UP 21

Figura 2.4. Quantita di lavoro dedicata a ciascuno dei flussi di lavoro fondamentali

2.8 Le fasi di UP

Ciascuna fase di UP ha un obiettivo, si concentra su una o piu attivita e flussi di lavoro e si concludecon una milestone. Nel seguito di questa sezione esamineremo le varie fasi.

2.8.1 Avvio

Obiettivi

L’Avvio ha come obiettivo quello di “far decollare” il progetto.L’Avvio comporta:

• stabilire la fattibilita: cio potrebbe richiedere la messa a punto di un prototipo tecnico o di unaprova di fattibilita per validare i requisiti funzionali;

• creare un caso di business per dimostrare che il progetto apportera un beneficio quantificabile dalbusiness;

• fissare i requisiti essenziali per definire l’ambito del sistema;• identificare i rischi piu critici.

Le principali risorse coinvolte in questa fase sono il capoprogetto e l’architetto di sistema.

Flussi di lavoro

L’Avvio enfatizza principalmente i flussi di lavoro dei requisiti e dell’analisi.Tuttavia potrebbe anche richiedere attivita di progettazione e implementazione nel caso si decidesse

di costruire un prototipo tecnico o una prova di fattibilita.Il flusso di lavoro dei test non e solitamente applicabile in quanto gli unici manufatti software

prodotti sono prototipi che verranno poi scartati.

Milestone: Obiettivo del Ciclo di Vita

La milestone dell’Avvio e proprio costituita dalla definizione degli Obiettivi del Ciclo di Vita.La Tabella 2.1 elenca le condizioni che devono essere soddisfatte per raggiungere questa milestone.

Viene suggerito anche un insieme di manufatti consegnabili che si devono creare per soddisfare questecondizioni. Va ricordato, tuttavia, che e consigliabile creare un manufatto solo quando aggiunge valoreal progetto.


Condizione da soddisfare Manufatto

Concordare con le parti interessate gli obiettivi Documento di alto livello con i principalidel progetto requisiti, caratteristiche e vincoli di progettoDefinire l’ambito del progetto concordandolo Modello dei casi d’uso iniziale (completato al 10-20%)con le parti interessateFissare i principali requisiti concordandoli con Glossario di progettole parti interessateConcordare con le parti interessate le stime dei Prima pianificazione del progettocosti e dei tempiIl capoprogetto ha creato un caso di business Caso di businessIl capoprogetto ha effettuato una valutazione dei rischi Documento o archivio di valutazione dei rischiLa fattibilita e stata confermata da uno o piu studi Uno o piu prototipi (da scartare)tecnici e/o prototipi

E stato individuato uno schema di architettura Documento iniziale di architettura

Tabella 2.1. Condizioni e Manufatti della milestone dell’Avvio

2.8.2 Elaborazione

Obiettivi

L’Elaborazione ha i seguenti obiettivi:

• creare una baseline eseguibile;• perfezionare la valutazione dei rischi;• definire gli attributi di qualita (velocita di individuazione dei difetti, densita massima di difetti

accettabile, etc.);• fissare i casi d’uso relativi a circa l’80% dei requisiti funzionali;• creare un piano dettagliato della fase di costruzione;• formulare una valutazione iniziale delle risorse, del tempo, degli strumenti, del personale e dei

costi richiesti.

L’obiettivo principale dell’Elaborazione e quello di produrre una baseline eseguibile. Si tratta di unvero e proprio sistema eseguibile costruito seguendo l’architettura specificata.

La baseline eseguibile non e un prototipo (e non verra quindi scartato), ma piuttosto una pri-ma approssimazione del sistema desiderato. Questa baseline eseguibile costituisce le fondamenta sucui verranno progressivamente aggiunte le altre funzioni e che, durante le fasi di Costruzione e diTransizione, si evolvera nel sistema finale completo che verra rilasciato.

Dato che le successive fasi si basano sui risultati dell’Elaborazione, quest’ultima e senza dubbio lafase piu critica di tutto il processo.

Flussi di lavoro

La fase di Elaborazione prevede i seguenti scopi per ciascuno dei cinque flussi di lavoro fondamentali:

• requisiti: fissare la maggior parte dei requisiti e definire meglio l’ambito del sistema;• analisi: definire cio che deve essere costruito;• progettazione: creare un’architettura stabile;• implementazione: costruire una baseline eseguibile;• test: verificare la baseline eseguibile.

L’Elaborazione si concentra, ovviamente, sui flussi di lavoro dei requisiti, dell’analisi e della pro-gettazione, anche se l’implementazione comincia ad assumere un maggior peso verso la fine della fase,quando si produce la baseline eseguibile.

Milestone: Architettura del Ciclo di Vita

La milestone dell’Elaborazione e l’Architettura del Ciclo di Vita.La Tabella 2.2 elenca le condizioni che devono essere soddisfatte per raggiungere quella milestone.

2.8 Le fasi di UP 23


Creare una baseline robusta ed eseguibile La baseline eseguibileLa baseline eseguibile dimostra che i rischi Modello statico UML; modello dinamico UML;principali sono stati identificati e risolti modello dei casi d’uso UMLLa visione d’insieme del sistema si e stabilizzata Un documento descrittivo del sistemaRivedere la valutazione dei rischi Valutazione dei rischi aggiornataRivedere e riconcordare il caso di business con le Caso di business aggiornatoparti interessateLa pianificazione di progetto ha raggiunto un Pianificazione di progetto aggiornatadettaglio tale da consentire la formulazione diuna stima realistica dei tempi, dei costi e dellerisorse richieste dalle fasi successiveLe parti interessate hanno approvato lapianificazione di progettoIl caso di business e stato verificato e confrontato Caso di businesscon la pianificazione di progetto

E stato raggiunto un accordo con le parti Accordo firmatointeressate per continuare il progetto

Tabella 2.2. Condizioni e Manufatti della milestone dell’Elaborazione

2.8.3 Costruzione

Obiettivi

L’obiettivo della Costruzione e quello di completare tutti i requisiti, l’analisi e la progettazione e di farevolvere la baseline eseguibile generata dall’Elaborazione nel sistema completo finale.

E essenziale che durante la Costruzione si mantenga l’integrita dell’architettura del sistema. Quan-do sul progetto inizia a sentirsi la presssione del futuro rilascio e si giunge al culmine del lavoro diimplementazione del codice sorgente, capita spesso che si cominci anche a prendere qualche scorcia-toia. In questo modo si puo presto perdere di vista l’architettura prevista per il sistema, con il rischiodi produrre un sistema finale di qualita scadente, con elevati costi di manutenzione. E, ovviamente,consigliabile evitare che un progetto finisca in questo modo.

Flussi di lavoro

L’enfasi in questa fase si sposta decisamente sul flusso di lavoro dell’implementazione. Gli altri flussidi lavoro prevedono il minimo di attivita necessarie per finire di fissare i requisiti e completare l’analisie la progettazione.

Anche i test diventano prioriari: dato che ogni nuovo incremento si basa su quello precedente,diventa necessario effettuare sia i test che i test di integrazione.

Possiamo sintetizzare il tipo di attivita previsto per ciascun flusso di lavoro nel modo seguente:

• requisiti: portare alla luce tutti i requisiti mancanti;• analisi: ultimare il modello di analisi;• progettazione: ultimare il modello di progettazione;• implementazione: costruire la capacita operativa iniziale;• test: verificare la capacita operativa iniziale.

Milestone: Capacita Operativa Iniziale

In pratica questa milestone e molto semplice: il sistema software deve essere completato e predispostoin modo che gli utenti possano eseguire il beta test.

La Tabella 2.3 elenca le condizioni che devono essere soddisfatte per raggiungere questa milestone.

2.8.4 Transizione

Obiettivi

La fase di Transizione inizia quando il beta test e ultimato e il sistema deve essere finalmente rilasciatoagli utenti.

Comporta, quindi, l’eliminazione dei difetti scoperti durante il beta test e la preparazione delrilascio a tutti gli utenti.

Gli obiettivi di questa fase possono essere sintetizzati in:



Il software ha una stabilita e qualita giudicata Prodotto software; modello UML; suite di testsufficiente per essere rilasciato agli utentiLe parti interessate hanno accettato che il software venga Manuale utente; descrizione del rilasciorilasciato agli utenti e sono pronte per la transizioneI costi reali confrontati con i costi previsti Pianificazione del progettorisultano accettabili

Tabella 2.3. Condizioni e Manufatti della milestone della Costruzione

• correggere i difetti;• preparare i siti utente per il nuovo software;• adattare il software in modo da operare correttamente presso i siti utente;• modificare il software qualora insorgessero problemi non previsti;• creare i manuali utente ed eventuale altra documentazione;• fornire consulenza agli utenti;• eseguire un riepilogo di fine progetto.

Flussi di lavoro

L’enfasi in questa fase e sui flussi di lavoro dell’implementazione e dei test.Si esegue un minimo di progettazione per correggere eventuali errori di progettazione scoperti

durante il beta test.A questo punto del ciclo di vita del progetto e auspicabile che non ci sia quasi nulla da fare sui

flussi di lavoro dei requisiti e dell’analisi. Se non e cosı, vuol dire che il progetto e a rischio.Possiamo sintetizzare il tipo di attivita previsto per ciascun flusso di lavoro nel modo seguente:

• requisiti: non applicabile;• analisi: non applicabile;• progettazione: rivedere il modello se sono insorti problemi durante il beta test;• implementazione: adattare il software al rilascio presso i siti utente e correggere i difetti scoperti

durante il beta test;• test: beta test e test di accettazione eseguito presso i siti utente.

Milestone: Rilascio del Prodotto

Questa e la milestone finale: si conclude il beta test e il test di accettazione, si correggono i difetti eil prodotto finito viene rilasciato e accettato dagli utenti.

La Tabella 2.4 elenca le condizioni che devono essere soddisfatte per raggiungere questa milestone.


Il beta test e ultimato, le necessarie modifiche al software sono state effettuate, Il prodotto softwaregli utenti concordano nell’affermare che il sistema e stato rilasciato con successoGli utenti stanno attivamente utilizzando il prodotto Pianificazione del supportoSono state concordate con gli utenti e implementate le strategie Manuali utente aggiornatidi supporto per il prodotto

Tabella 2.4. Condizioni e Manufatti della milestone della Costruzione

Parte II

Gestione dei Requisiti

27

Questa parte del corso si concentra sulle attivita di gestione dei requisiti. In particolare, nel Capitolo3 vengono introdotte le varie forme di requisiti e ne viene descritto il flusso di lavoro. Nel Capitolo 4,invece, viene illustrata la modellazione dei requisiti tramite i casi d’uso.

3

Il flusso di lavoro dei requisiti

Questo capitolo spiega come comprendere i requisiti di un sistema. Esso introduce il concetto di re-quisiti e analizza il flusso di lavoro dei requisiti, cosı come previsto da UP. Esso presenta, inoltre, unestensione ad UP che consente di fissare i requisiti senza utilizzare i casi d’uso UML.

3.1 Il flusso di lavoro dei requisiti

La Figura 3.1 illustra come la maggior parte delle attivita relative al flusso di lavoro dei requisiti sianosvolte durante le fasi di Avvio ed Elaborazione, proprio all’inizio del ciclo di vita del progetto. Questonon deve sorprendere, dato che non ha molto senso procedere oltre la fase di Elaborazione se non sisa cosa si vuole costruire!

Figura 3.1. Quantita di lavoro dedicata a ciascuno dei flussi di lavoro fondamentali

Prima ancora di iniziare le attivita di analisi e progettazione Object Oriented, e necessario averequalche idea su cosa si vuole ottenere, ed e proprio questo lo scopo ultimo del flusso di lavoro deirequisiti.

Dal punto di vista del progettista e dell’analista Object Oriented lo scopo e scoprire e accordarsi sucio che il sistema dovrebbe fare, esprimendolo nel linguaggio degli utenti del sistema.

La creazione di una specifica di alto livello di cio che il sistema dovrebbe fare fa parte dell’ingegneriadei requisiti.

In ogni sistema specifico possono esistere molte parti interessate: diversi tipi di utente, ingegneridella manutenzione, personale per il supporto e l’assistenza, commerciali, dirigenti, etc.

30 3 Il flusso di lavoro dei requisiti

L’ingegneria dei requisiti e la disciplina che si occupa della raccolta dei requisiti che queste partiinteressate hanno per il sistema e dell’assegnazione delle priorita a questi stessi requisiti.

Si tratta di un processo di negoziazione, dato che spesso e necessario trovare il giusto compromessotra requisiti tra loro contrastanti.

Per esempio, un gruppo potrebbe avere l’esigenza di rendere il sistema accessibile a molti utenti,il che potrebbe generare un traffico non gestibile dalle infrastrutture di comunicazione o di databaseesistenti. Questo tipo specifico di contrasto tra requisiti e molto comune ora che molte societa hannonecessita di rendere parte dei loro sistemi accessibili via Internet a una base molto estesa di utenti.

Molti affermano che i casi d’uso previsti da UML sono l’unico strumento valido per fissare irequisiti; tuttavia non e difficile confutare questa affermazione.

In realta i casi d’uso sono in grado di fissare esclusivamente i requisiti funzionali, ovvero quelli chedescrivono cosa debba fare il sistema.

Esiste un altro insieme di requisiti, non funzionali, che descrive i vincoli che il sistema deve rispet-tare (prestazioni, affidabilita, etc.). Questi requisiti non possono essere espressi correttamente tramitei casi d’uso.

Nel nostro caso utilizzeremo, invece, un approccio robusto da “ingegneria dei requisiti”, checomprende tecniche potenti e complementari per fissare i requisiti di entrambe le categorie.

Nonostante il fatto che il comportamento di un sistema e, quindi, in ultima analisi, anche lasoddisfazione dell’utente finale, dipenda moltissimo dall’ingegneria dei requisiti, molte societa, ancoraoggi, non la considerano una disciplina importante. Come si e visto, la principale causa di fallimentodei progetti software e dovuta ai requisiti.

Requisiti incompleti e mancanza di coinvolgimento degli utenti sono le due principali cause difallimento dei progetti software. Entrambi, inoltre, sono l’effetto di fallimento nell’ingegneria deirequisiti.

3.2 Requisiti del software: meta-modello

La Figura 3.2 mostra il meta-modello del nostro approccio per l’ingegneria dei requisiti. Esso contienediversi elementi di sintassi UML non ancora spiegati; essi saranno trattati piu avanti.

Figura 3.2. Meta-modello del nostro approccio per l’ingegneria dei requisiti

Per il momento bastera anticipare che:

• Le icone che assomigliano a cartelline sono package UML. I package sono il meccanismo che UMLutilizza per raggruppare elementi di modellazione. In effetti, hanno un ruolo simile a quello delle car-telline di un sistema di archiviazione, ovvero consentono di organizzare e raggruppare informazionio elementi correlati.Se il package ha un piccolo triangolo nell’angolo superiore destro, significa che esso contiene unmodello.

3.3 Flusso di lavoro dei requisiti in dettaglio 31

• L’icona ad ancora indica che l’elemento che si trova di fianco al cerchio crociato contiene l’elementoche si trova all’altra estremita della linea

Il meta-modello mostra che la Specifica dei Requisiti del Software (Software Requirements Specifi-cation, SRS) contiene un Modello dei Requisiti e un Modello dei casi d’uso. Questi due modelli sonometodi diversi, ma complementari, per fissare i requisiti del sistema.

E possibile che il Modello dei requisiti contenga sia Requisiti funzionali (requisiti che specificano cioche il sistema dovrebbe fare) sia Requisiti non funzionali (requisiti che esprimono vincoli non funzionalisul sistema).

Il Modello dei casi d’uso puo contenere vari package (nella Figura 3.2 ne abbiamo mostrati solotre), attori (ruoli esterni che interagiscono direttamente con il sistema) e relazioni.

Nel resto di questo capitolo saranno trattati i requisiti, mentre nel prossimo capitolo tratteremo icasi d’uso e gli attori.

3.3 Flusso di lavoro dei requisiti in dettaglio

La Figura 3.3 illustra le specifiche attivita previste da UP per il flusso di lavoro dei requisiti. Questo tipodi diagramma si chiama dettaglio del flusso di lavoro in quanto elenca tutte le attivita che compongonoun flusso di lavoro specifico.

Figura 3.3. Specifiche attivita previste da UP per il flusso di lavoro dei requisiti

In UP i dettagli di flusso di lavoro vengono modellati utilizzando risorse (le icone sul lato sinistro) eattivita (le icone a forma di ingranaggio). Le varianti di UP, quali RUP, possono usare icone differenti,ma hanno comunque il medesimo significato.

Le frecce sono relazioni che illustrano il flusso di lavoro normale tra un’attivita e quella successiva.E utile ricordare che questo tipo di diagramma vuole solo illustrare il flusso di lavoro, cosı come

dovrebbe svolgersi “tipicamente”; potrebbe non essere sempre una rappresentazione esatta di quelloche succede veramente.

In un progetto reale puo succedere che alcune attivita vengano effettuate in un ordine diverso daquello illustrato, o magari in parallelo, a seconda delle circostanze.

Dal momento che lo scopo del corso sta soprattutto nell’analisi e nella progettazione Object Orien-ted, nel seguito ci si concentrera sulle attivita piu importanti per gli analisti e i progettisti ObjectOriented.

In questo caso le attivita di interesse sono le seguenti:

• individuare attori e casi d’uso;• descrivere un caso d’uso;• strutturare il modello dei casi d’uso.

Le altre attivita del flusso di lavoro dei requisiti non riguardano molto gli analisti/progettisti. “As-segnare priorita ai casi d’uso” e un’attivita che concerne piu che altro l’architettura e la pianificazionedi progetto, mentre “Prototipare l’interfaccia utente” e un’attivita di programmazione.


La Figura 3.3 evidenzia come il flusso di lavoro standard di UP si concentri sui casi d’uso, esclu-dendo qualunque altra tecnica di raccolta dei requisiti. Questo va bene solo fino a un certo puntoperche, come gia detto, non consente di gestire in modo ottimale l’aspetto non funzionale di alcunirequisiti.

Per gestire in modo completo tutti i requisiti, si estende in modo semplice il flusso di lavoro deirequisiti di UP, introducendo le seguenti nuove attivita:

• individuare i requisiti funzionali;• individuare i requisiti non funzionali;• assegnare priorita ai requisiti;• estrarre i casi d’uso dai requisiti.

E stata, inoltre, introdotta una nuova risora: l’ingegnere dei requisiti. La Figura

Figura 3.4. Nuove attivita e risorse coinvolte rispetto al flusso di lavoro standard di UP

3.4 Definire i requisiti

Un requisito puo essere definito come “una specifica che dovrebbe essere implementata”. I requisitisono (o, almeno, dovrebbero essere) cio su cui si basano tutti i sistemi.

Essi sono essenzialmente un’affermazione di cio che il sistema dovrebbe fare. In teoria, i requisitidovrebbero essere un’affermazione esclusivamente di cosa un sistema deve fare, e non di come lo devefare. Si tratta di una precisazione molto importante. E possibile specificae cosa debba fare un sistemae quale comportamento debba mostrare senza precisare nulla di come debba essere realizzata questafunzionalita.

Anche se in teoria e desiderabile separare il cosa dal come, in pratica un qualunque insieme direquisiti (noto come Specifiche dei Requisiti di Sistema o, piu semplicemente, Specifiche dei Requisiti)ha la tendenza a mischiare i due elementi.

In parte questo e dovuto al fatto che la definizione astratta di un problema (il cosa) puo essere piudifficile da scrivere e comprendere della descrizione dell’implementazione (il come).

In secondo luogo possono effettivamente esistere dei vincoli sull’implementazione del sistema chepredeterminano, almeno in parte, il come.

3.4.1 Il modello dei requisiti

Molte societa non hanno ancora una nozione formale dei requisiti o di un modello dei requisiti. Ilsoftware e specificato in uno o piu “documenti dei requisiti” informali, che vengono tipicamente scrittiin linguaggio naturale. Tali documenti sono di ogni forma e dimensione e hanno diversi gradi di utilita.

Per qualsiasi documento dei requisiti in qualunque forma le domande fondamentali da porsi sono:“quanto e utile?” e “aiuta a capire cosa dovrebbe fare il sistema o no?”. Sfortunatamente molti diquesti documenti informali sono di utilita limitata.

L’UP ha un approccio formale ai requisiti basato su un modello dei casi d’uso. Quest’ultimo puoessere creato usando uno strumento di modellazione di UML, per esempio Rational Rose o EnterpriseArchitect. I casi d’uso verranno trattati dettagliatamente nel Capitolo 4.

3.4 Definire i requisiti 33

Il modello dei requisiti puo essere creato con strumenti di ingegneria dei requisiti speciali o testuali,quali RequisitePro (www.ibm.com) o DOORS (www.telelogic.com). Sarebbe opportuno utilizzarequesti strumenti di ingegneria dei requisiti, se possibile! Nelle prossime sottosezioni verra descrittocome formulare i requisiti.

3.4.2 Formulazione dei requisiti

UML non fornisce alcuna indicazione su come scrivere i requisiti. In effetti, UML si occupa dei requisitiesclusivamente tramite il meccanismo dei casi d’uso. Tuttavia molti modellatori credono che i casi d’usonon siano sufficienti e che siano ancora necessarie le SRS e gli strumenti di gestione dei requisiti.

Per la formulazione dei requisiti, si consiglia l’uso di un formato molto semplice (Figura 3.5).Ogni requisiti ha un identificatore univoco (tipicamente un numero), una parola chiave (“dovra”) el’affermazione di una funzione. Formulando i requisiti con un formato cosı rapido e uniforme, si ha ilvantaggio che alcuni strumenti di gestione dei requisiti, quali DOORS, sono in grado di interpretarefacilmente le SRS.

Figura 3.5. Un formato semplice per la formulazione dei requisiti

3.4.3 Requisiti funzionali e non funzionali

E utile separare i requisiti funzionali da quelli non funzionali. Esistono molti altri modi di classificare irequisiti, ma, almeno inizialmente per semplificare il piu possibile, ci si limitera a queste due categorie.

Un requisito funzionale specifica cosa fara il sistema: e l’affermazione di una funzione del sistema.Per esempio, raccogliendo i requisiti per uno sportello automatico tipo bancomat, alcuni requisitifunzionali potrebbero essere i seguenti:

• il sistema dovra controllare la validita della tessera inserita;• il sistema dovra validare il codice PIN inserito dal cliente;• il sistema dovra erogare non piu di 250 euro a fronte della stessa carta, in un unico periodo di 24

ore.

Un requisito non funzionale e un vincolo imposto dal sistema. Requisiti non funzionali per lo stessosportello automatico potrebbero essere cosı descritti:

• il sistema dovra essere scritto in C++;• il sistema dovra comunicare con la banca utilizzando un algoritmo di cifratura a 256 bit;• il sistema dovra validare la carta entro tre secondi;• il sistema dovra validare il PIN entro tre secondi.

Dall’esempio risulta evidente che i requisiti non funzionali specificano, o limitano, come il sistemadebba essere implementato.


3.4.4 Organizzare i requisiti

Se si usa uno strumento di gestione dei requisiti, si possono organizzare questi ultimi in una tassonomia,ovvero in una gerarchia di tipi che si puo usare per classificare i requisiti.

Il motivo principale per utilizzare i tipi di requisiti e che grazie ad essi si possono organizzare grandiquantita di requisiti non strutturati in domini piu piccoli e piu gestibili. Cio consente di lavorare coni requisiti in modo piu efficace.

La distinzione di base tra requisiti funzionali e non funzionali descritta precedentemente e una tas-sonomia molto semplice; tuttavia, si possono suddividere i requisiti in ulteriori categorie, estendendo,per esempio, la tassonomia come mostra la Figura 3.6.

Figura 3.6. Una possibile tassonomia per i requisiti

I tipi specifici di requisiti da utilizzare dipendono al tipo di software che si sta creando. Cio valesoprattutto per i requisiti funzionali. Per i requisiti non funzionali, l’insieme di tipi di requisiti mostratonella Figura 3.6 e uno standard e rappresenta un buon punto di partenza.

Organizzare i requisiti per tipo e un approccio utile se si ha a che fare con molti requisiti (piu dicento). E utile soprattutto se si usa uno strumento di ingegneria dei requisiti perche questo consentiradi usare i tipi per interrogare il modello dei requisiti e trarre informazioni utili.

In teoria, la gerarchia dei tipi di requisiti puo essere arbitrariamente profonda; in pratica, due otre livelli sono sufficienti, a meno che non si lavori con un sistema molto complesso.

3.4.5 Attributi dei requisiti

Ogni requisito puo avere un insieme di attributi che fornisce informazioni aggiuntive (metadati) adesso relative.

Ciascun attributo ha un nome descrittivo e un valore. Per esempio, un requisito puo avere unattributo denominato dataScadenza che ha come valore la data in cui il requisito deve essere rilasciato.Il requisito potrebbe avere anche un attributo sorgente che ha come valore la decrizione della fonteda cui il requisito deriva.

L’insieme di attributi che si decide di usare dipende dalla natura e dalle esigenze del proprioprogetto e puo cambiare con il tipo di requisito.

Forse l’attributo piu abituale dei requisiti e la priorita. Il valore di questo attributo e la prioritadel requisito rispetto a tutti gli altri requisiti. Uno schema comune per assegnare priorita e l’insiemedi criteri MoSCoW descritto nella Tabella 3.1.

Quando viene usato il paradigma MoSCoW, ogni requisito ha un attributo Priorita che puoassumere uno dei valori M, S, C o W. Gli strumenti di ingegneria dei requisiti in genere consentono

3.5 Individuare i requisiti 35

Valori dell’attributo priorita Descrizione

Must have Requisiti obbligatori che sono fondamentali per il sistemaShould have Requisiti importanti che possono essere omessiCould have Requisiti che sono veramente opzionali (da realizzare se c’e tempo)Want to have Requisiti che possono aspettare versioni successive al sistema

Tabella 3.1. Insieme di criteri MoSCoW

di interrogare il modello dei requisiti in base al valore dell’attributo. Per esempio, e possibile creareun elenco di tutti i requisiti di massima priorita (Must have).

L’aspetto positivo del paradigma MoSCoW e la sua semplicita, ma confonde due attributi diun requisito: l’importanza e la precedenza. L’importanza di un requisito, una volta fissata, tende arimanere relativamente costante. La precedenza di un requisito, invece, quando viene stabilita rispettoagli altri requisiti, puo cambiare nel corso del progetto, per motivi non correlati all’importanza, comela disponibilita di risorse o la dipendenza da altri requisiti.

RUP definisce un insieme piu completo da attributi dei requisiti che scinde l’importanza (Benefici)e la precedenza (VersioneDestinazione). Gli attributi di RUP vengono presentati nella Tabella 3.2.

Attributo Descrizione

Stato Puo avere uno dei seguenti valori:Proposto (Proposed): requisiti che sono ancora in fase di discussione e non sono stati concordati.Rifiutato (Refused): requisiti la cui implementazione e stata rifiutata.Approvato (Approved): requisiti la cui implementazione e stata approvata.Incorporato (Incorporated): requisiti che sono stati implementati in una particolare versione.

Vantaggi Puo avere uno dei seguenti valori:Critico (Critical): il requisito deve essere implementato; altrimenti il sistema non sara

accettabile per le parti interessati.Importante (Important): il requisito potrebbe essere omesso, ma, contrariamente influenzerebbe

l’usabilita del sistema e la soddisfazione delle parti interessate.Utile (Useful): il requisito potrebbe essere omesso senza alcun impatto significativo

sull’accettabilita del sistema.Sforzo Una stima del tempo e delle risorse necessarie per implementare la caratteristica, valutata

in giorni persona o con un’altra unita di misura come i punti funzione (www.ifpug.org).Rischio Il rischio implicito nell’aggiunta di questa caratteristica: alta, media o bassa.Stabilita Una valutazione delle probabilita che il requisito cambi: alta, media o bassaVersioneDestinazione La versione del prodotto in cui il requisito dovrebbe essere implementato

Tabella 3.2. Gli attributi di RUP

Il fatto si usare MoSCoW, RUP o un altro insieme dei requisiti dipende dal proprio particolareprogetto.

Quando si definisce un insieme di attributi, l’elemento fondamentale e che bisogna mantenerlo il piusemplice possibile. Si devono scegliere solo quegli attributi che portano vantaggi al proprio progetto.Se un attributo non comporta alcun beneficio, non va usato.

3.5 Individuare i requisiti

I requisiti derivano dal contesto del sistema che si cerca di modellare. Questo contesto include:

• utenti diretti del sistema;• altre parti interessate (per esempio, manager, gestori, installatori);• altri sistemi con cui esso interagisce;• dispositivi hardware con cui esso interagisce;• vincoli contrattuali e legali;• vincoli tecnici• obiettivi di business.

L’ingegneria dei requisiti in genere inizia con un documento di visione che sottolinea cio che ilsistema fara e quali vantaggi portera a un insieme di parti interessate. L’idea di questo documento equella di fissare gli obiettivi essenziali del sistema dal punto di vista delle parti interessate.

Il documento di visione e prodotto dall’analista del sistema durante la fase di Avvio di UP.


Una volta redatto il documento di visione, l’ingegneria dei requisiti inizia davvero. Nelle prossimesottosezioni saranno trattate alcune tecniche di raccolta dei requisiti.

3.5.1 Raccolta dei requisiti

Ogni volta che si lavora con qualcuno per raccogliere e fissare i requisiti di un sistema software, sicerca di ottenere un’immagine precisa, o mappa, del modello che hanno del mondo.

Noam Chomsky, nel suo libro del 1975: Syntactic Structures, che tratta della grammatica dellatrasformazione, sostiene che questa mappa viene creata tramite tre processi: rimozione, distorsione egeneralizzazione.

Questi processi sono necessari, in quanto non abbiamo le capacita cognitive per fissare ogni singolodettaglio del mondo reale in una mappa mentale altrettanto dettagliata: dobbiamo dunque essereselettivi.

Sopraffatti da una quantita eccessiva di informazioni, si selezionano quelle giudicate importantiapplicando tre filtri:

• rimozione: l’informazione viene scartata;• distorsione: l’informazione viene modificata tramite i meccanismi della creazione e dell’allucina-

zione;• generalizzazione: l’informazione viene incorporata in una regola, assioma o principio che riguarda

i concetti di verita e falsita.

Questi filtri danno forma al linguaggio naturale. E importante rendersene conto quando si effettuala raccolta o l’analisi di requisiti molto dettagliati perche potrebbe essere necessario individuarli emetterli in discussione, per riuscire a risalire a informazioni precise.

Seguono alcuni esempi tratti da un sistema di gestione di una biblioteca. Per ciascun esempio siriporta anche come e stato messo in discussione un possibile filtro e una possibile risposta.

Esempio 3.1. “Utilizzano il sistema per prendere in prestito i libri; rimozione.

• Messa in discussione: Chi utilizza il sistema per prendere in prestito i libri?• Risposta: Gli utenti della biblioteca, altre biblioteche e bibliotecari.

2

Esempio 3.2. “Non e possibile prendere in prestito un altro libro se non sono stati restituiti tutti ilibri il cui periodo di prestito sia gia scaduto; distorsione.

• Messa in discussione: Non esiste alcuna situazione in cui qualcuno puo prendere in prestito unnuovo libro prima di aver restituito tutti i libri in prestito il cui periodo di prestito sia gia scaduto?

• Risposta: Effettivamente esistono due situazioni in cui viene ripristinato il diritto di un utente aprendere nuovi libri in prestito. Quando restituisce tutti i libri il cui periodo di prestito sia scaduto,oppure quando paga per quelli che non ha restituito.

2

Esempio 3.3. “Tutti devono avere una tessera per prendere i libri in prestito; generalizzazione.

• Messa in discussione: Non esiste un utente del sistema che possa operare senza essere fornito ditessera?

• Risposta: Alcuni utenti del sistema, quali per esempio le altre biblioteche, possono non averebisogno di una tessera, oppure possono aver bisogno di una tessera di tipo speciale soggetta atermini e condizioni diverse.

2

Gli ultimi due casi sono particolarmente interessanti, in quanto esemplificano uno schema lingui-stico molto comune: il quantificatore universale. I quantificatori universali sono parole come:

• tutto;• ogni;

3.5 Individuare i requisiti 37

• sempre;• mai;• nessuno;• niente.

Ogni volta che si incontra un quantificatore universale ci si puo trovare dinanzi a una rimozione,una distorsione o una generalizzazione. La presenza di queste parole potrebbe indicare che e statoraggiunto il limite, i confini della mappa mentale dell’interlocutore. Per questo motivo, quando sieffettua un’analisi, e spesso una buona idea mettere in discussione i quantificatori universali.

3.5.2 Interviste

Intervistare le parti interessate e il modo piu diretto per raccogliere requisiti. Di solito, dove possibile,e meglio fare interviste individuale e tenere presenti i seguenti punti fondamentali.

• Non si deve aver gia immaginato una soluzione: si puo pensare di avere un’idea perfetta di cio dicui le parti interessate hanno bisogno, ma durante l’intervista si deve ignorare tale preconcetto.Questo e l’unico modo in cui si scoprira cio di cui veramente necessitano.

• E necessario porre domande indipendenti dal contesto: queste domande non presuppongono alcunaparticolare risposta e incoraggiano l’intervistato a parlare del problema. Per esempio, la domanda“chi usa il sistema?” e indipendente dal contesto e incoraggia la discussione, mentre la domanda“usa il sistema?” richiede una risposta affermativa o negativa e chiude la discussione.

• Si deve ascoltare: questo e l’unico modo per scoprire che cosa vogliono le parti interessate, quindibisogna dare loro il tempo di parlare. Se si cercano risposte a domande specifiche, significa che sie gia immaginata una soluzione e si stanno ponendo domande chiuse in base ad essa.

• Non bisogna leggere nel pensiero: anche se in effetti tutti, in un certo senso, cercano di leggere nelpensiero degli altri. Leggere nel pensiero vuol dire presupporre di sapere cio che un individuo sente,vuole o pensa basandosi cu cio che egli ha sentito, voluto o pensato in una situazione simile. Questae un’abilita umana importante, perche e la base dell’empatia. Inoltre diventa rilevante quando unapersona cerca di raccogliere requisiti, ma poi finisce per rappresentare cio che lei vuole e non cioche le parti interessate vogliono.

• E indispensabile avere tanta pazienza!

Il contesto dell’intervista puo avere un grosso impatto sulla qualita delle informazioni che si otten-gono. Sono da preferirsi i contesti informali, quali un bar, perche consentono sia all’intervistatore siaall’intervistato di rilassarsi e aprirsi.

Il modo migliore di fissare le informazioni durante un’intervista e prendere appunti su carta!L’inserimento di dati in un portatile, in genere, distrae entrambe le parti e puo anche intimidirel’intervistato.

Le mappe mentali sono un metodo flessibile, non intimidante e graficamente ricco di raccogliereinformazioni. E possibile reperire ulteriori informazioni a riguardo sul sito www.mind-map.com.

Dopo un’intervista, si possono analizzare le informazioni e costruire i requisiti candidati.

3.5.3 Questionari

I questionari non sostituiscono le interviste. Se si decide di usare i questionari senza fare alcunaintervista, ci si puo trovare in una situazione impossibile in cui si deve scegliere tra un elenco dipossibili domande prima di conoscere le domande corrette da porre.

I questionari possono essere un’integrazione utile alle interviste. Sono perfetti per ottenere rispostespecifiche a domande chiuse. E possibile ricavare le domande fondamentali dalle interviste e includerlein un questionario che poi puo essere distribuito a un pubblico piu ampio. Questo puo aiutare amigliorare la propria comprensione dei requisiti.

3.5.4 Workshop sui requisiti

Questo e uno dei modi piu efficaci di fissare i requisiti. Per identificare i requisiti fondamentali sidevono convincere le principali parti interessate a partecipare a un workshop.


Il workshop dovrebbe focalizzarsi sul brainstorming, che e una tecnica potente per raccogliereinformazioni.

I partecipanti alla riunione dovrebbero essere i committenti, un ingegnere dei requisiti, le principaliparti interessate e gli esperti del dominio.

La procedura e la seguente:

1. Spiegare ai partecipanti che si tratta di una sessione di brainstorming.

a) Tutte le idee saranno considerate buone.b) Le idee vengono registrate, ma non dibattute: non si discute nulla, ci si limita a scrivere tutto

e a proseguire. Tutto verra analizzato successivamente.

2. Chiedere ai partecipanti di assegnare un nome ai requisiti fondamentali per il sistema.3. E possibile scegliere poi di prendere in considerazione una seconda volta i requisiti identificati e

annotare ulteriori attributi per ciascuno.

Dopo la riunione, e necessario analizzare i risultati e trasformarli in requisiti come si e vistoprecedentemente nel capitolo; infine, e necessario far circolare i risultati per eventuali commenti.

L’ingegneria dei requisiti e un processo iterativo in cui i requisiti vengono diffusi mentre si definiscela propria conoscenza delle esigenze delle parti interessate. Per approfondire questa conoscenza epossibile che si debbano tenere piu workshop.

4

Modellazione dei casi d’uso

In questo capitolo ci concentreremo sulla modellazione dei casi d’uso. In particolare, vedremo come epossibile esprimere un singolo caso d’uso e come e possibile costruire un diagramma dei casi d’uso.Quest’ultimo strumento verra esaminato inizialmente in modo generale e successivamente in modoapprofondito.

4.1 Introduzione

La modellazione dei casi d’uso e una forma di ingegneria dei requisiti. Nella Sezione 3.4 abbiamovisto come creare un modello dei requisiti che include requisiti funzionali e non funzionali in quelloche si puo chiamare il modo “tradizionale”. La modellazione dei casi d’uso e una tecnica diversa ecomplementare per raccogliere e documentare i requisiti.

La modellazione dei casi d’uso prevede tipicamente i seguenti passi:

• individuare un potenziale confine del sistema;• individuare gli attori;• individuare i casi d’uso; questo passo si suddivide, a sua volta, nei seguenti sottopassi:

– specificare il caso d’uso;– identificare le principali sequenze degli eventi alternative.

Generalmente si parte da una valutazione iniziale di dove si trova il confine del sistema per definirel’ambito dell’attivita di modellazione. Le azioni poi vengono eseguite iterativamente e, spesso, inparallelo. Queste attivita producono il modello dei casi d’uso.

Il modello e composto da quattro componenti:

• attori: i ruoli assunti dalle persone e dalle cose che usano il sistema;• casi d’uso: quello che gli attori possono fare con il sistema;• relazioni: relazioni significative tra gli attori e i casi d’uso;• confine del sistema: un rettangolo disegnato intorno ai casi d’uso per indicare il confine del sistema

oggetto del modello.

Inoltre, il modello dei casi d’uso costituisce una fonte primaria di oggetti e classi. Costituisce l’inputpiu importante per la modellazione delle classi.

4.2 Attivita UP: individuare attori e casi d’uso

In questa sezione ci si concentra sull’attivita “Individuare attori e casi d’uso” del flusso di lavoro deirequisiti, descritto nel Capitolo 3. Questa attivita e illustrata in Figura 4.1.

Esaminiamo attentamente gli input di questa attivita:

• Modello di business: puo capitare di avere a disposizione un modello di business relativo al sistemache si sta modellando. Il modello e un’eccellente fonte di requisiti.

40 4 Modellazione dei casi d’uso

Figura 4.1. L’attivita di individuazione degli attori e dei casi d’uso in UP

• Modello dei requisiti: la creazione di questo modello e stata descritta nel Capitolo 3. I requisitiforniscono l’input utile per il processo di modellazione dei casi d’uso. In particolare, i requisitifunzionali suggeriscono casi d’uso e attori, mentre i requisiti non funzionali suggeriscono elementiche bisogna ricordare quando si costruiscono i modelli dei casi d’uso.

• Elenco delle feature: un insieme di potenziali requisiti che puo assumere la forma di un documentodi visione o simili.

4.2.1 Il subject (confine del sistema)

Quando si comincia a pensare di costruire un sistema, la prima cosa da fare e stabilire quali siano isuoi confini. In altre parole, e necessario decidere cosa fa parte del sistema (dentro i suoi confini) ecosa non ne fa parte (fuori dai suoi confini).

Questa affermazione puo sembrare banale e ovvia, ma in molti progetti sono sorti problemi proprioa causa di un confine di sistema non ben definito. Il posizionamento del confine del sistema puo avereun enorme impatto sui requisiti funzionali (e, a volte, anche su quelli non funzionali).

In UML 2 si fa riferimento al confine del sistema come subject e questo e il termine che d’ora inpoi useremo.

Il subject e definito da chi o cosa usa il sistema (ovvero gli attori) e dagli specifici benefici o funzioniche il sistema offre ai suoi attori (ovvero i casi d’uso).

Il subject viene rappresentato da un rettangolo, etichettato con il nome del sistema. Gli attorivengono posizionati all’esterno del rettangolo mentre i casi d’uso finiscono all’interno.

Quando si inizia a effettuare la modellazione dei casi d’uso si ha un’idea piuttosto vaga di dove sitrovi effettivamente il subject. Man mano che si individuano gli attori e i casi d’uso, il subject diventasempre piu definito.

4.2.2 Cosa sono gli attori

Un attore identifica il ruolo che un’entita esterna assume quando interagisce direttamente con ilsistema.

Un attore puo rappresentare il ruolo di un utente o di un altro sistema, che in qualche modointeressa il confine del sistema. In UML 2, gli attori possono rappresentare anche altri subject econsentire di collegare modelli dei casi d’uso diversi.

Per capire gli attori e importante capire il concetto di ruolo. Si pensi a un ruolo come a un cappelloche una persona indossa in un contesto particolare. Le persone, pero, possono avere simultaneamentee nel tempo molti ruoli, il che significa che un dato ruolo puo essere interpretato da piu personecontemporaneamente e nel tempo. Per esempio, se abbiamo identificato per il sistema l’attore Cliente,le persone Jim, Ila, Wolfgang, Roland e molte altre, possono avere tutte quel ruolo, ma possono

4.2 Attivita UP: individuare attori e casi d’uso 41

ricoprire anche ruoli diversi. Per esempio, Roland potrebbe essere anche l’amministratore del sistemaoltre a usarlo da Cliente.

Nella modellazione dei casi d’uso, l’errore fondamentale che i principianti commettono e confondereun ruolo svolto da qualcosa nel contesto del sistema con la cosa stessa. Bisogna sempre chiedersi“quale ruolo svolge questa cosa rispetto al sistema?”. In questo modo e possibile individuare uncomportamento comune tra molte cose diverse e pertanto semplificare il modello dei casi d’uso.

La Figura 4.2 illustra come vengono rappresentati gli attori in UML. Come si evince dalla figuraessi possono essere raffigurati come un’icona della classe stereotipata quale ¡¡attore¿¿ o come iconadell’attore a forma di “uomo stilizzato”. Entrambe le forme utilizzate per l’elemento attore sonovalide, ma molti modellatori preferiscono la forma a “uomo stilizzato” per rappresentare i ruoli cheprobabilmente verranno interpretati da persone umane, e la forma a icona della classe per i ruoli cheprobabilmente verranno interpretati da altri sistemi.

Figura 4.2. Rappresentazione degli attori in UML

E importante rendersi conto che gli attori devono sempre essere esterni al sistema. Quando, peresempio, un utente utilizza un sistema di commercio elettronico (quale una libreria online per l’acquistodi un libro) si ritrova ad essere all’esterno di quel sistema.

E tuttavia interessante osservare che anche se gli attori veri e propri restano sempre esterni a unsistema, spesso i sistemi mantengono una qualche rappresentazione interna di uno o piu attori. Peresempio, la libreria online puo tenere traccia di informazioni sulla maggior parte dei clienti: nome,indirizzo, etc. Questa e una rappresentazione interna dell’attore esterno Cliente. E importante chesia ben chiara la differenza: l’attore Cliente e esterno al sistema ma il sistema puo utilizzare unaclasse DettaglioCliente, che e una rappresentazione interna degli individui che interpretano il ruolodell’attore Cliente.

Individuare gli attori

Per individuare gli attori e necessario capire chi o cosa utilizzi il sistema e quali ruoli rivestano mentreinteragiscono con il sistema.

Per fissare i ruoli che le persone e le cose rivestono nei confronti di un sistema, si puo iniziare aprendere in considerazione persone o cose specifiche e quindi generalizzare.

Le risposte alle seguenti domande possono aiutare a individuare gli attori:

• Chi o cosa usa il sistema?• Quale ruolo rivestono durante l’interazione con il sistema?• Chi installa il sistema?• Chi o cosa avvia e ferma il sistema?• Chi effettua la manutenzione del sistema?• Quali altri sistemi interagiscono con il sistema?• Chi ottiene informazioni dal sistema e chi ne fornisce?• Esistono funzioni che vengono eseguite a intervalli, orari o date prestabiliti?

Per modellare correttamente gli attori occorre ricordare i sottoelencati punti:

• Gli attori sono sempre esterni al sistema: non possono quindi essere controllati.• Gli attori interagiscono direttamente con il sistema: e cosı che aiutano a fissare il subject.• Gli attori rappresentano i ruoli generici che persone o cose possono rivestire nei confronti del

sistema: non rappresentano persone o cose specifiche.• Una persona puo rivestire, contemporaneamente o in tempi diversi, piu ruoli nei confronti del

sistema. Per esempio, dal punto di vista di un sistema di pianificazione dei corsi, un’unica personache scrive corsi, ma li tiene anche, ha due ruoli distinti: “Responsabile di corso” e “Autore delcorso”.


• Ogni attore deve essere identificato da un nome breve, che abbia senso dal punto di vista delbusiness.

• Ogni attore deve essere caratterizzato da una breve descrizione (un paio di righe) che lo definiscadal punto di vista del business.

• L’icona di un attore, come quella di una classe, puo essere caratterizzata da una sottosezione cheelenca i suoi attributi e da una che elenca gli eventi a cui puo rispondere. Queste sottosezioni sonoutilizzate molto di rado nei diagrammi dei casi d’uso e non saranno da noi utilizzate.

Il tempo come attore

Per modellare qualcosa che avviene nel sistema in un certo momento noto, e che non sembra essere pro-vocato da alcun attore specifico, si puo ricorrere a un attore speciale chiamato Tempo. Questa tecnicae, per esempio, indicata per modellare una procedura di backup del sistema che viene automaticamenteeseguita tutte le sere.

4.2.3 Cosa sono i casi d’uso

I casi d’uso sono definiti come:

“La specifica di una sequenza di azioni, incluse eventuali sequenze alternative e sequenze di errore,

che un sistema, un sottosistema o una classe puo eseguire interagendo con attori esterni.”

Il caso d’uso e qualcosa che un attore vuole che il sistema faccia. I casi d’uso vengono sempreavviati da un attore. I casi d’uso vengono sempre descritti dal punto di vista degli attori.

Si e abituati a ragionare sui casi d’uso a livello di sistema ma in realta, come afferma la definizioneriportata, ci si puo anche occupare di casi d’uso a livello di sottosistema o, addirittura, di singolaclasse. I casi d’uso possono anche essere molto efficaci per modellare i processi di business, anche sequest’aspetto non verra considerato in questo corso.

La Figura 4.3 illustra l’icona che UML utilizza per rappresentare i casi d’uso. Il nome del casod’uso puo essere riportato indifferentemente dentro o sotto l’ovale.

Figura 4.3. Rappresentazione di un caso d’uso in UML

Individuare i casi d’uso

Il migliore modo per individuare i casi d’uso e di partire dall’elenco degli attori e di ragionare su cio checiascun attore fa per utilizzare il sistema. Questa strategia consente di ottenere un elenco di potenzialicasi d’uso. E, quindi, necessario assegnare a ogni caso d’uso una frase corta e descrittiva compostaessenzialmente da un verbo.

Identificando i casi d’uso potrebbe spuntare qualche nuovo attore: e normale. A volte e necessarioapprofondire le funzionalita del sistema prima di riuscire a individuare tutti gli attori o tutti gli attorigiusti.

La modellazione dei casi d’uso e un’operazione iterativa che viene effettuata per approssimazionisuccessive.

Per ciascun caso d’uso inizialmente si fissa solo il nome. I dettagli vengono completati successiva-mente; inizialmente si ha una prima descrizione sintetica che viene in seguito raffinata fino a diventareuna specifica completa.

Le risposte alle seguenti domande possono aiutare a individuare i casi d’uso:

• Quali funzioni si aspetta dal sistema ciascun attore?

4.2 Attivita UP: individuare attori e casi d’uso 43

• Il sistema archivia e recupera informazioni? Se si, quali attori provocano questo comportamento?• Che cosa accade quando il sistema cambia stato (per esempio, all’avvio e all’interruzione del

sistema)? Esistono attori che vengono notificati?• Esistono eventi esterni che producono effetti sul sistema? Chi o cosa notifica al sistema questi

eventi?• Il sistema interagisce con un sistema esterno?• Il sistema genera un report?

Il diagramma dei casi d’uso

Nel diagramma dei casi d’uso, il subject del modello dei casi d’uso viene rappresentato da un rettangoloidentificato dal nome del subject. Questo rettangolo e il subject e rappresenta il confine del sistemamodellato dai casi d’uso. Gli attori sono collocati fuori dal subject (esterni al sistema) e i casi d’uso,che costituiscono il comportamento del sistema, sono collocati dentro il confine del sistema (interni alsistema). Questo diagramma e illustrato nella Figura 4.4.

Figura 4.4. Il Diagramma dei casi d’uso in UML

La relazione tra un attore e un caso d’uso e rappresentata da una linea solida, il simbolo UMLdell’associazione. L’associazione tra attore e caso d’uso indica che l’attore e il caso d’uso comunicanoin qualche modo.

4.2.4 Il Glossario di Progetto

Il Glossario di Progetto e sicuramente uno dei manufatti piu importanti del progetto. Il Glossario diProgetto e il dizionario che contiene i principali termini del dominio e le loro definizioni. Dovrebberisultare comprensibile a tutti i partecipanti e a tutte le parti interessate al progetto.

Oltre a definire i principali termini, il Glossario di Progetto deve anche risolvere i casi di sinonimiae omonimia.

• I sinonimi sono vocaboli diversi che hanno lo stesso significato. L’analista OO del progetto dovrascegliere uno di questi vocaboli (quello che sembra essere piu utilizzato dalle parti interessate) eusare solo quello. Gli altri vocaboli non dovranno assolutamente comparire nei modelli. L’uso disinonimi puo, infatti, facilmente portare a implementare classi con funzionalita molto simili, macon nomi diversi. Laddove si consente l’uso di diversi sinonimi all’interno dello stesso modello, sipuo star certi che, col tempo, il significato di questi vocaboli cominciano a divergere.

• L’omonimia si presenta quando lo stesso vocabolo assume un diverso significato per diverse per-sone. Questo fenomeno produce sempre seri problemi di comunicazione, dato che le diverse partiinteressate si ritrovano in effetti a parlare lingue diverse, pur convinte, invece, di parlare tutte lastessa. Anche in questo caso, sara compito dell’analista scegliere uno dei significati per il vocabolo,magari introducendo nuovi vocaboli per gestire gli altri significati.


Le scelte di vocaboli e di significato effettuate devono essere riportate nel Glossario di Proget-to, assieme all’eventuale elenco dei sinonimi individuati. Questa pratica potrebbe richiedere che siinsista con alcune parti interessate affinche si abituino a utilizzare una diversa terminologia. Non efacile convincere le parti interessate a cambiare il loro uso del linguaggio eppure, con un minimo diperseveranza, e possibile.

UML non impone alcuno standard per il Glossario di Progetto. E buona norma utilizzare unasoluzione semplice e concisa. Si consiglia un formato simile a quello di un dizionario, con un elenco divocaboli, ordinato alfabeticamente, accompagnati dalle relative definizioni.

Puo essere sufficiente un documento di solo testo, ma nei progetti grandi potrebbe essere richiestoche il glossario sia disponibile online, in formato HTML o XML, o magari addirittura in un semplicedatabase. Si ricordi che l’impatto che il glossario avra sul progetto sara tanto piu positivo quanto piuil glossario sara accessibile e facile da utilizzare.

Un esempio di Glossario di Progetto e riportato nella Tabella 4.1. Per una questione di stile, senon esistono ne sinonimi ne omonimi, invece di lasciare lo spazio bianco, si scrive “Nessuno”. In questomodo si dimostra che ci si e posti il problema.

Vocaboli Descrizione

Catalogo Un elenco di tutti i prodotti che attualmente vengono venduti da Clear View Training.Sinonimi: Nessuno.Omonimi: Nessuno.

Cassa La controparte elettronica di una cassa di un supermercato.Il luogo in cui i clienti possono pagare i prodotti che hanno nel carrello.Sinonimi: Nessuno.Omonimi: Nessuno.

Clear View Training Una societa a responsabilita limitata specializzata nella vendita di libri e CD.Sinonimi: CVT.Omonimi: Nessuno.

Carta di credito Una carta di credito, per esempio Visa o Mastercard, che si puo usare per pagare i prodotti.Sinonimi: Carta.Omonimi: Nessuno.

Cliente Una parte che acquista prodotti o servizi da Clear View Training.Sinonimi: Nessuno.Omonimi: Nessuno.

Tabella 4.1. Un esempio di Glossario di Progetto valido per la piattaforma di commercio elettronico dellaSocieta Clear View Training

Un punto di attenzione che riguarda il Glossario di Progetto e che gli stessi vocaboli e le stessedefinizioni vengano anche utilizzati in tutto il modello UML. E necessario assicurarsi che i due docu-menti risultino sempre allineati e sincronizzati. Sfortunatamente, la maggior parte degli strumenti dimodellazione UML non fornisce alcun supporto per questo tipo di documento ed e quindi solitamentenecessario aggiornarlo manualmente.

4.3 Attivita UP: descrivere un caso d’uso

Dopo aver creato un diagramma dei casi d’uso e aver individuato gli attori e i casi d’uso piu importanti,e necessario iniziare a definire le specifiche di ciascun caso d’uso. Questa attivita dell’UP, nota come“Descrivere un caso d’uso”, viene illustrata nella Figura 4.5.

A questo punto e importante osservare che tipicamente queste attivita non vengono svolte secon-do una sequenza rigida. E possibile descrivere alcuni, o tutti, i casi d’uso man mano che vengonoindividuati.

Questa attivita produce un caso d’uso corredato di maggiori dettagli. E necessario perlomenoincludere il nome del caso d’uso e le sue specifiche. Opzionalmente di puo anche aggiungere una brevedescrizione.

UML non fornisce nessuno standard per la formulazione delle specifiche del caso d’uso. Tuttaviail modulo illustrato nella Figura 4.6 e di uso piuttosto comune.

Qualcuno utilizza moduli piu dettagliati e complessi ma, in linea generale, e consigliabile che lamodellazione dei casi d’uso resti il piu semplice possibile.

4.3 Attivita UP: descrivere un caso d’uso 45

Figura 4.5. L’attivita di descrizione di un caso d’uso in UP

Figura 4.6. Un possibile modulo per la descrizione di un caso d’uso

E importante che un’azienda decida uno standard per le specifiche del caso d’uso che possa essereusato in modo consistente all’interno dei progetti. Nelle aziende in cui tale standard non esiste l’interoprocesso di modellazione dei casi d’uso diventa inutilmente difficile.

Ci possono essere molti formati, livelli di dettaglio e anche interpretazioni di quello che un casod’uso e o non e, anche all’interno di un medesimo progetto. Uno standard semplice ed efficace per laspecifica dei casi d’uso puo assicurare che il progetto raggiunga i suoi obiettivi per quanto riguardal’analisi dei casi d’uso.

Il modulo per specificare i casi d’uso contiene le seguenti informazioni:

• nome del caso d’uso;• identificatore del caso d’uso;• breve descrizione; in questo caso si inserisce un paragrafo che fissa l’obiettivo del caso d’uso;• attori coinvolti nel caso d’uso;• precondizioni: condizioni che devono essere vere prima che il caso d’uso possa essere eseguito; sono

vincoli sullo stato iniziale del sistema;• sequenza degli eventi principale: rappresenta i passi che costituiscono il caso d’uso;• postcondizioni: condizioni che devono essere vere quando il caso d’uso termina l’esecuzione;• sequenze degli eventi alternative: un elenco di alternative alla sequenza principale.

Quando esamineremo casi d’uso piu complicati renderemo piu dettagliato il modulo affinche possacontenere altre informazioni.


Il caso d’uso della Figura 4.6 riguarda il pagamento dell’IVA. Nell’esempio riportato, il fisco ottienesempre le tasse che gli spettano, in un modo o nell’altro, e quindi questa e stata specificata comepostcondizione al caso d’uso.

4.3.1 Nomi dei casi d’uso

Non esiste nessuno standard UML per denominare i casi d’uso.Il nome di un caso d’uso viene scritto sempre con lettere maiuscole e minuscole ma iniziando

sempre con una lettera maiuscola. Questo modo di scrivere viene detto “UpperCamelCase”; questotermine deriva da “Camel”, cioe cammello, perche vengono prodotte parole con le gobbe.

I casi d’uso descrivono il comportamento del sistema, quindi il loro nome dovrebbe essere sempreun verbo o un predicato verbale, per esempio PagaIVA, e dovrebbe essere breve ma descrittivo. Illettore del diagramma dei casi d’uso dovrebbero riuscire a capire il processo o la funzione di businessche il caso d’uso sta modellando attraverso il solo nome.

Il nome fornisce un identificatore univoco per il caso d’uso all’interno del modello.

4.3.2 Identificatore del caso d’uso

Sebbene il nome del caso d’uso debba essere univoco nel modello del caso d’uso, e possibile che cambinel tempo.

Quindi, si puo decidere di aggiungere un altro identificatore fisso che distingue un particolare casod’uso all’interno del processo. Spesso viene utilizzato un numero.

Quando si usano le sequenze degli eventi alternative (Sezione 4.3.7) e possibile adottare un sistemanumerico gerarchico in modo che la sequenza alternativa possa essere facilmente collegata alla sequenzaprincipale. Per esempio, se a un caso d’uso viene assegnato il numero X, le sequenze alternativesaranno: X.1, X.2, . . . , X.n.

4.3.3 Breve descrizione

Dovrebbe essere un paragrafo che riassume brevemente l’obiettivo del caso d’uso. In questo punto enecessario fissare l’essenza del caso d’uso, ovvero i vantaggi che ne traggono i suoi attori.

4.3.4 Attori

Dal punto di vista di uno specifico caso d’uso esistono due tipi di attori:

• attori primari: gli attori che avviano effettivamente il caso d’uso;• attori secondari: gli attori che interagiscono con il caso d’uso dopo che questo e stato avviato.

Ogni caso d’uso e sempre avviato da un singolo attore. Tuttavia, lo stesso caso d’uso puo essereavviato da attori diversi in momenti diversi. Ciascun attore che puo dare inizio al caso d’uso e unattore primario; tutti gli altri sono attori secondari.

4.3.5 Precondizioni e postcondizioni

Le precondizioni e le postcondizioni sono vincoli.Le precondizioni vincolano lo stato del sistema prima che il caso d’uso possa iniziare l’esecuzione.

Possono essere immaginate come dei guardiani che impediscono all’attore di far scattare il caso d’usoa meno che siano state soddisfatte tutte le condizioni previste.

Le postcondizioni vincolano lo stato del sistema quando il caso d’uso ha terminato la propriaesecuzione.

Da un altro punto di vista, le precondizioni specificano cosa debba esser vero prima che il casod’uso possa essere avviato mentre le postcondizioni specificano cosa debba essere vero dopo che il casod’uso e stato eseguito.

Le precondizioni e le postcondizioni possono aiutare a progettare sistemi che funzionano corretta-mente.


Le precondizioni e le postcondizioni dovrebbero sempre essere espresse come semplici affermazionisullo stato del sistema, che possono essere vere o false; queste affermazioni sono anche dette condizionibooleane.

Se il caso d’uso non ha alcuna precondizione o postcondizione, nella sezione appropriata dellaspecifica dei casi d’uso e meglio scrivere “Nessuno”. Questo dimostra che il problema e stato preso inconsiderazione, mentre il fatto di lasciare lo spazio vuoto e sempre ambiguo.

4.3.6 Sequenza degli eventi principale

Una sequenza degli eventi principale elenca i passi che compongono un caso d’uso.Puo essere utile immaginare che un caso d’uso sia simile al delta di un fiume da cui si diramano molti

canali. Ciascun caso d’uso ha una sequenza degli eventi principale (flusso di eventi) che costituisceil fiume vero e proprio. Gli altri canali piu piccoli sono i flussi alternativi (sequenze degli eventialternative) che descrivono gli errori, le ramificazioni e le interruzioni nella sequenza degli eventiprincipale.

Quest’ultima si chiama scenario principale mentre le sequenze degli eventi alternative sono anchedette scenari secondari.

La sequenza degli eventi principale elenca i passi di un caso d’uso che costituiscono lo scenarioda “mondo perfetto”, in cui tutto avviene come previsto e desiderato e non ci sono errori, deviazioni,interruzioni o ramificazioni.

Le deviazioni rispetto alla sequenza degli eventi principale possono essere modellate in due modi:

• deviazioni semplici: creano ramificazioni alla sequenza principale;• deviazioni complesse: scrivono sequenze degli eventi alternative.

La sequenza degli eventi principale inizia sempre con l’attore primario che fa qualcosa per dareinizio al caso d’uso. Un buon modo per iniziare la sequenza degli eventi e il seguente:

1. Il caso d’uso inizia quanto un <attore> <funzione>.

Come abbiamo detto precedentemente, l’attore potrebbe anche essere il tempo. In questo caso il casod’uso puo iniziare con un’espressione temporale al posto di <attore> <funzione>, come nell’esempiodella Figura 4.6.

La sequenza degli eventi e costituita da un elenco di passi che devono essere concisi, dichiarativi,numerati e ordinati temporalmente.

Ogni passo del caso d’uso dovrebbe avere la seguente struttura:

<numero> || <qualcosa> <qualche azione>.

E possibile esprimere la sequenza degli eventi del caso d’uso in maniera testuale, ma e sconsigliabilein quanto solitamente risulta veramente troppo impreciso.

E possible illustrare le alternative nella sequenza degli eventi di un caso d’uso utilizzando le rami-ficazioni o elencando dei frammenti di comportamento nella sezione “Sequenza Alternativa” del casod’uso.

Ecco un esempio di un paio di passi della sequenza degli eventi del caso d’uso NuovoOrdine:

1. Il caso d’uso inizia quando il cliente seleziona la funzione ‘‘ordina libro’’.

2. Il cliente inserisce nel modulo il suo nome e il suo indirizzo.

Questi passi sono ben strutturati. Entrambi sono semplici affermazioni che dichiarano che unqualcosa eseguira una qualche azione.

Ecco, invece, un esempio di caso d’uso mal strutturato:


2. Vengono inseriti i dati del cliente.

In effetti, un passo descritto con un’affermazione in forma passiva di solito e mal strutturato.Questo particolare passo, in realta, ha subito tre rimozioni importanti:

• Chi inserisce i dati del cliente? Chi da inizio al caso d’uso?• Dove vengono inseriti i dati?• Quali sono esattamente i “dati del cliente”?

Quando si descrive una sequenza degli eventi di un caso d’uso e molto importante riconoscere unarimozione ed evitarla. Non importa se l’informazione mancante puo sembrare desumibile dal contestoo facilmente intuibile. Il problema e che ogni caso d’uso deve essere una dichiarazione precisa di unadelle funzionalita del sistema.

Quando, durante le attivita di analisi, capita di riscontrare vaghezza, imprecisione, rimozione ogeneralizzazione, puo essere utile insistere, formulando alcune domande. Tipicamente queste sono:

• Esattamente chi ... ?• Esattamente cosa ... ?• Esattamente quando ... ?• Esattamente dove ... ?

Ramificazione di una sequenza

La specifica di UML non indica come visualizzare le ramificazioni di una sequenza.Noi useremo uno stile che consente di mostrare le diramazioni in modo semplice senza dover creare

una sequenza degli eventi alternativa a parte; in questo stile, per indicare una ramificazione, vieneutilizzata la parola chiave If.

E il caso di notare che alcuni modellatori non accettano l’uso delle ramificazioni all’interno di uncaso d’uso. Questi sostengono che ogni ramificazione dovrebbe essere espressa introducendo una nuovasequenza degli eventi alternativa.

In teoria, questa tesi ha dei meriti; tuttavia, noi utilizzeremo un approccio piu pragmatico.Una quantita non eccessiva di ramificazioni semplici e desiderabile in quanto riduce il numero

complessivo di sequenze degli eventi alternative consentendo una rappresentazione piu compatta deirequisiti.

La Figura 4.7 illustra un esempio di sequenza degli eventi ben strutturata che contiene due rami.Ogni ramo inizia con la parola chiave If seguita da una semplice espressione booleana che potra

risultare vera o falsa.Il testo indentato che si trova sotto questa dichiarazione stabilisce cosa succedera quando l’espres-

sione booleana diventa vera. L’indentazione del testo e la numerazione esprimono chiaramente lastruttura del ramo If e non e necessario ricorrere ad espliciti costrutti sintattici di chiusura del ramoquali, per esempio, EndIf.

La ramificazione puo ridurre il numero di postcondizioni del caso d’uso perche i passi all’internodi una ramificazione possono avvenire o meno a seconda delle circostanze; pertanto, questi passi nonpossono generare postcondizioni, che sono cose che devono essere vere e non cose che possono esserevere.

Ripetizione all’interno di una sequenza

A volte e necessario che un’azione venga ripetuta in una stessa sequenza di eventi.E piuttosto raro ricorrere a questo tipo di specifica nella modellazione dei casi d’uso ma quando

capita e utile disporre di una strategia adatta allo scopo.La specifica di UML non indica come mostrare le ripetizioni all’interno di una sequenza degli eventi;

generalmente, pero, per questo scopo si utilizzano le parole chiave For e While.Per modellare la ripetizione si usa la parola chiave For. Il formato e:


Figura 4.7. Esempio di sequenza degli eventi ben strutturata che contiene due rami

n. For (espressione di iterazione)

n.1. Fai qualcosa

n.2. Fai qualcos’altro

n.3. ...

n+1.

L’espressione di iterazione e una qualche espressione che indica il numero, intero e positivo, diiterazioni che devono essere eseguite.

Le azioni riportate sulle righe indentate che seguono la dichiarazione For verranno ripetute ilnumero di volte indicato dall’espressione di iterazione.

La Figura 4.8 illustra un esempio.La parola chiave While serve per modellare una serie di azioni che devono essere ripetute all’interno

di una sequenza di eventi fintantoche e vera una certa condizione booleana.Il formato e il seguente:

n. While (condizione booleana)

n.1. Fai qualcosa

n.2. Fai qualcos’altro

n.3. ...

n+1.

Questa parola chiave non e molto utilizzata, proprio come la parola chiave For.La Figura 4.9 illustra un esempio.Le azioni riportate sulle righe indentate che seguono la dichiarazione While verranno ripetute fino

a quando l’espressione booleana non diventa falsa.


Figura 4.8. Esempio di utilizzo della parola chiave For

Figura 4.9. Esempio di utilizzo della parola chiave While


4.3.7 Come modellare le sequenze degli eventi alternative

Ogni caso d’uso ha una sequenza degli eventi principale e puo avere molte sequenze alternative. Questeultime sono percorsi alternativi che nel caso d’uso descrivono gli errori, le ramificazioni e le interruzioninella sequenza degli eventi principale.

Come si e visto la specifica di un caso d’uso contiene la sequenza principale e un elenco dei nomidelle sequenze alternative.

Una caratteristica importante delle sequenze degli eventi alternative e che queste spesso non ri-tornano alla sequenza principale. Cio accade perche esse spesso gestiscono errori ed eccezioni dellasequenza principale e tendono ad avere postcondizioni diverse.

E possibile documentare a parte le sequenze degli eventi alternative oppure aggiungerle alla finedel caso d’uso; nel nostro caso noi utilizzeremo la tecnica di documentarle a parte.

Nella Figura 4.10 e riportato un esempio di come modellare un caso d’uso con sequenze degli eventialternative. E possibile che questo caso d’uso abbia tre sequenze alternative: IndirizzoPostaElettroni-caNonValido, ParolaChiaveNonValida e Annulla.

Figura 4.10. Esempio di un caso d’uso con sequenze degli eventi alternative

La Figura 4.11 documenta la sequenza degli eventi alternativa IndirizzoPostaElettronicaNonValido.Si osservi che vengono apportati molti cambiamenti al modulo del caso d’uso per adattarlo alle

sequenze alternative.La struttura del modulo e la seguente:

• Nome: per le sequenze degli eventi alternative viene usata la seguente convenzione di denomina-zione:

Sequenza degli eventi alternativa: CreaNuovoAccountCliente : IndirizzoPosta-

ElettronicaNonValido


Figura 4.11. La sequenza degli eventi alternativa IndirizzoPostaElettronicaNonValido

Questo indica che si tratta di una sequenza alternativa denominata IndirizzoPostaElettronicaNon-Valido per il caso d’uso CreaNuovoAccountCliente.

• ID: si osservi che e stato utilizzato un sistema di numerazione gerarchico per correlare la sequenzadegli eventi alternativa al caso d’uso principale.

• Attori: vengono elencati gli attori utilizzati dalla sequenza degli eventi alternativa.• Precondizioni e postcondizioni: le sequenze degli eventi alternative possono avere il proprio insieme

di precondizioni e postcondizioni che e diverso da quello del caso d’uso. Se la sequenza alternativaritorna alla sequenza principale, le sue postcondizioni vengono aggiunte a quelle della sequenzaprincipale.

• Sequenza degli eventi alternativa: i passi della sequenza degli eventi alternativa.• Una sequenza degli eventi alternativa non dovrebbe avere a sua volta sequenze degli eventi

alternative, altrimenti la specifica puo diventare troppo complessa.

Le sequenze degli eventi alternative possono essere attivate in tre modi:

• La sequenza degli eventi alternativa puo essere attivata al posto della sequenza degli eventiprincipale.

• La sequenza degli eventi alternativa puo essere attivata dopo un particolare passo della sequenzadegli eventi principale.

• La sequenza degli eventi alternativa puo essere attivata in qualunque momento nel corso dellasequenza degli eventi principale.

Quando una sequenza degli eventi alternativa e in esecuzione al posto della sequenza degli eventiprincipale, viene attivata dall’attore principale e sostituisce integralmente il caso d’uso.

Quando la sequenza degli eventi alternativa e attivata dopo un particolare passo della sequenzadegli eventi principale, dovrebbe iniziare nel modo seguente:

1. La sequenza degli eventi alternativa inizia dopo il passo X della sequenza

degli eventi principale.

Questo pero e un tipo di ramificazione diverso da quello trattato nella Sezione 4.3.6 perche e unadeviazione primaria dalla sequenza degli eventi principale e potrebbe non ritornarvi.

Quando una sequenza degli eventi alternativa puo essere attivata in qualunque momento nel corsodella sequenza degli eventi principale dovrebbe iniziare nel modo seguente:


1. La sequenza degli eventi alternativa inizia in qualunque momento.

Si usa questo tipo di sequenza degli eventi alternativa per modellare qualcosa che potrebbe accaderein qualunque istante della sequenza degli eventi principale prima del passo finale.

Per esempio, nel caso d’uso CreaNuovoAccountCliente, il Cliente puo decidere di annullare lacreazione dell’account in qualunque momento. E possibile documentare Annulla come mostra la Figura4.12.

Figura 4.12. La sequenza degli eventi alternativa Annulla

Se si desidera che la sequenza degli eventi alternativa ritorni alla sequenza principale, lo si puoesprimere nel modo seguente:

N. La sequenza degli eventi alternativa ritorna al passo M della sequenza degli

eventi principale.

In questo esempio la sequenza degli eventi alternativa esegue il suo ultimo passo N e poi l’esecuzionedella sequenza degli eventi principale continua al passo M .

Individuare le sequenze degli eventi alternative

E possibile individuare le sequenze degli eventi alternative analizzando la sequenza degli eventiprincipale.

Ad ogni passo della sequenza principale si cerchino:

• possibili alternative alla sequenza degli eventi principale;• errori possibili nella sequenza degli eventi principale;• interruzioni che potrebbero verificarsi dopo un particolare passo della sequenza degli eventi princi-

pale;• interruzioni che potrebbero verificarsi in qualunque punto della sequenza degli eventi principale.

Ciascuno di questi casi puo dare origine ad una sequenza degli eventi alternativa.


Quante sequenze degli eventi alternative?

Tornando alla metafora della foce del fiume: oltre al fiume stesso, possono esistere moltissimi canalialternativi ramificati e contorti. Non ci si puo veramente permettere di mapparli tutti, quindi ci silimita a quelli piu importanti. Inoltre molti di questi canali scorrono tra loro in parallelo, con lievidifferenze di percorso. E possibile mapparne uno solo in modo dettagliato, fornendo delle indicazionisu come gli altri canali se ne discostino. Questa e una tecnica molto efficace per modellare un casod’uso complesso.

Il principio di base della modellazione dei casi d’uso e di fissare sempre la quantita minimaindispensabile di informazioni.

Questo significa che molte sequenze degli eventi alternative possono anche non essere specificate:sul caso d’uso compare comunque una loro descrizione formata da una riga che potrebbe essere undettaglio sufficiente per comprendere il funzionamento del sistema.

Questo e un punto importante: e molto facile ritrovarsi sommersi di sequenze degli eventi alterna-tive ed e capitato piu di una volta che l’attivita di modellazione dei casi d’uso sia fallita proprio perquesto motivo.

Si ricordi che la descrizione dei casi d’uso deve servire per capire il comportamento desiderato delsistema e non, invece, per produrre un loro modello completo. L’attivita di modellazione deve, quindi,essere interrotta non appena si abbia la sensazione di aver compreso questo comportamento.

Inoltre, dato che UP prevede un ciclo di vita iterativo, nel caso in cui ci si accorga che qualcheaspetto del sistema non e molto chiaro, si puo sempre ritornare sui relativi casi d’uso per approfondirli.

4.4 Mappatura dei requisiti

Usando un modello dei requisiti e uno dei casi d’uso, di fatto ci si ritrova ad avere due distinti “archivi”di requisiti funzionali.

E molto importante incrociare il contenuto dei due archivi per scoprire se esistono dei requisiti nelmodello dei requisiti che non sono coperti dal modello dei casi d’uso e viceversa.

Questa problematica e una di quelle affrontate dalla mappatura dei requisiti.La mappatura dei requisiti funzionali sui casi d’uso e ulteriormente complicata dal fatto che la

relazione e del tipo molti-a-molti. Un singolo caso d’uso puo coprire diversi requisiti funzionali e unsingolo requisito funzionale puo manifestarsi in casi d’uso distinti.

E consigliabile utilizzare uno strumento di modellazione che supporti la mappatura dei requisiti.Effettivamente diversi strumenti di ingegneria dei requisiti, quali RequisitePro e DOORS, consentonodi associare i singoli requisiti funzionali inseriti nel loro database dei requisiti a diversi casi d’uso, eviceversa. Anche UML offre un buon supporto per la mappatura dei requisiti. E possibile associarea un caso d’uso un insieme di requisiti funzionali inserendo i loro identificativi in una lista di valorietichettati. Nello strumento di gestione dei requisiti e possibile associare uno o piu identificatori dicaso d’uso a specifici requisiti.

Se non si dispone di un supporto adeguato da parte dello strumento di modellazione, allora enecessario fare questo lavoro manualmente.

Una buona soluzione puo essere quella di creare una Matrice di Mappatura dei Requisiti. Si trattadi una semplice griglia che riporta gli identificativi numerici dei singoli requisiti su un’asse, e i nomidei casi d’uso (e/o i loro identificativi numerici) sull’altro. Si colloca, quindi, una crocetta in ogni cellacorrispondente a un requisito e a un caso d’uso tra loro associati.

Le Matrici di Mappatura dei Requisiti possono essere facilmente create con un qualunque strumentoche gestisca fogli elettronici. La Tabella 4.2 ne fornisce un esempio.

La Matrice di Mappatura dei Requisiti e uno strumento molto utile per controllare la consistenza.Se esiste un requisito che non corrisponde ad alcun caso d’uso, allora manca almeno un caso d’uso.D’altra parte, se esistono dei casi d’uso che non corrispondono ad un requisito, allora l’elenco deirequisiti e incompleto.

Se una parola nel glossario di progetto si presenta sia in un requisito sia in un caso d’uso, laprobabilita che i due siano in qualche modo correlati e molto alta.

Questo crea una potenziale matrice di mappature dei requisiti. La matrice viene definita “potenzia-le” perche questa semplice analisi testuale avra errori e omissioni e la matrice deve essere esaminatamanualmente.

4.6 Generalizzazione tra attori 55

UC1 UC2 UC3 UC4

R1 X

R2 X X

R3 X

R4 X

R5 X

Tabella 4.2. Un esempio di Matrice di Mappatura dei Requisiti

Inoltre, consente di risparmiare molto tempo e puo aiutare gli ingegneri dei requisiti a eseguire uncompito laborioso che altrimenti non potrebbe essere realizzato.

4.5 Quando applicare la modellazione dei casi d’uso

Dato che i casi d’uso fissano le funzionalita del sistema dal punto di vista degli attori, sono ovviamentepoco efficaci per un sistema che abbia un attore solo, o magari anche nessuno.

I casi d’uso fissano i requisiti funzionali e sono, quindi, anche poco indicati per i sistemi dominatida requisiti non funzionali.

I casi d’uso sono il miglior modo di fissare i requisiti se:

• il sistema e dominato da requisiti funzionali;• il sistema fornisce diverse funzionalita a molti tipi di utente (esistono molti attori);• il sistema ha molte interfacce con altri sistemi (esistono molti attori).

I casi d’uso non sono molto indicati se:

• il sistema e dominato da requisiti non funzionali;• il sistema ha pochi tipi di utente;• il sistema ha poche interfacce con altri sistemi.

Esempi di sistemi poco adatti alla modellazione dei casi d’uso sono i sistemi embedded e i sistemiricchi di algoritmi complessi, ma poveri di interfacce. Per questi sistemi conviene di gran lunga ripiegaresu tecniche di ingegneria dei requisiti piu convenzionali. E proprio solo una questione di sceglieresempre lo strumento piu adatto per il lavoro che si vuole fare.

4.6 Generalizzazione tra attori

Nell’esempio riportato nella Figura 4.13 si puo vedere come esista una certa somiglianza tra i dueattori Cliente e Agente nel modo in cui interagiscono con il sistema vendite (in questo sistema eprevisto che l’Agente possa gestire una vendita per conto di un Cliente).

Entrambi gli attori danno inizio ai casi d’uso ListinoProdotti, OrdinaProdotti e AccettaPagamento.In effetti, l’unica differenza tra i due attori e che l’Agente da anche inizio al caso d’uso CalcolaCommissioni.

A parte il fatto che questa sovrapposizione genera una serie di linee incrociate sul diagramma,sembra anche indicare la presenza di un comportamento comune ai due attori che puo essere scorporatoe gestito definendo un attore piu generico.

La Figura 4.14 illustra come si possa utilizzare la generalizzazione tra attori per scorporare questocomportamento comune. Si puo creare un attore astratto Acquirente che interagisce con i casi d’usoListinoProdotti, OrdinaProdotti e AccettaPagamento.

Cliente e Agente vengono detti attori concreti perche rappresentano ruoli che potrebbero esserecoperti da persone (o sistemi esterni) reali. Acquirente, invece, e un attore astratto in quanto rap-presenta esclusivamente un’astrazione introdotta per fissare meglio il comportamento comune dei dueattori concreti.

Cliente e Agente ereditano tutti i ruoli e le relazioni che l’attore generalizzato (o genitore) astrattoha nei confronti dei casi d’uso.


Figura 4.13. Un esempio di attori simili

Figura 4.14. Un esempio di generalizzazione tra attori

Quindi, interpretando la Figura 4.14, Cliente e Agente hanno entrambi una relazione con i casid’uso ListinoProdotti, OrdinaProdotti e AccettaPagamento che ereditano dal loro attore genitorecomune Acquirente.

Agente, inoltre, ha un’altra interazione con il caso d’uso CalcolaCommissioni che non e ereditata,ma specifica dell’attore specializzato Agente.

Si osserva, quindi, come l’uso attento di attori generalizzati possa semplificare i diagrammi dei casid’uso. Esso consente di semplificare anche la semantica del modello dei casi d’uso, perche si possonotrattare aspetti diversi nello stesso modo.

Vale la pena notare che, in una generalizzazione di attori, l’attore genitore non deve necessariamenteessere astratto; potrebbe benissimo essere un ruolo concreto da far interpretare a una persona o sistemaesterno reale. Tuttavia, per una questione di stile e di leggibilita, si consiglia di utilizzare per lo piuattori generalizzati astratti.

Gli attori specializzati (o figli) ereditano i ruoli e le relazioni dell’attore generalizzato.E possibile utilizzare un attore specializzato in qualunque punto ci si aspetti l’utilizzo di un suo

attore generalizzato. Questo viene detto principio di sostituibilita ed e un ottimo modo per verificarel’uso corretto della generalizzazione, con qualunque tipo di classificatore.

In questo esempio e ragionevole aspettarsi che sia possibile sostituire un Agente o un Cliente ovun-que sia richiesta l’uso di un Acquirente (ovvero nell’interazione con i casi d’uso ListinoProdotti,OrdinaProdotti e AccettaPagamento), quindi la generalizzazione e una strategia applicabile.

4.7 Generalizzazione tra casi d’uso 57

4.7 Generalizzazione tra casi d’uso

La generalizzazione tra casi d’uso viene utilizzata quando esistono uno o piu casi d’uso specializzazionidi un caso d’uso piu generalizzato.

Come la generalizzazione tra attori, andrebbe utilizzata esclusivamente nel caso in cui semplifichio renda piu comprensibili i diagrammi dei casi d’uso.

Nella generalizzazione tra casi d’uso, i casi d’uso specializzati (figli) rappresentano delle variantipiu specifiche del caso d’uso generalizzato (genitore) da cui ereditano.

I casi d’uso figli possono:

• ereditare caratteristiche del caso d’uso genitore;• aggiungere nuove caratteristiche;• ridefinire (modificare) caratteristiche ereditate.

Il caso d’uso figlio eredita automaticamente tutte le caratteristiche del caso d’uso genitore. Tuttavianon tutti i tipi di elemento di caso d’uso sono ridefinibili.

La Tabella 4.3 illustra le restrizioni esistenti sulla ridefinizione degli elementi.

Modello dei requisiti Ereditare Aggiungere Ridefinire

Relazione Si Si No

Punto di estensione Si Si No

Precondizione Si Si Si

Postcondizione Si Si Si

Passo della sequenza principale Si Si Si

Sequenza Alternativa Si Si Si

Tabella 4.3. Le restrizioni esistenti sulla ridefinizione degli elementi

In UML 1.5 i casi d’uso avevano anche attributi e operazioni che in UML 2 non hanno. In effetti,attributi e operazioni non sembravano aggiungere alcun valore reale ai casi d’uso; essi erano usatiraramente e non sempre erano supportati negli strumenti UML. Secondo la specifica UML 1.5 leoperazioni di un caso d’uso non erano neanche invocabili dall’esterno, quindi era difficile immaginareil motivo della loro esistenza.

Come si documenta la generalizzazione tra casi d’uso nelle specifiche dei casi d’uso.Le specifiche UML non rispondono in alcun modo a questo quesito, ma esistono diverse tecniche

abbastanza diffuse.Una delle tecniche piu concrete consiste nell’utilizzo di un semplice linguaggio di marcatura che

evidenzi le cinque casistiche che si possono presentare nel caso d’uso specializzato.Per l’applicazione di questo linguaggio vanno seguite due regole:

• Nel caso d’uso figlio, dopo il numero di ciascun passo viene aggiunto il numero del passocorrispondente nel caso d’uso genitore, se ne esiste uno.

• Se il passo nel caso d’uso figlio ridefinisce un passo del caso d’uso genitore, e seguito da “o”(overridden, ridefinito) e dal numero del passo nel genitore.

La Tabella 4.4 illustra la sintassi per le cinque opzioni nei casi d’uso figli.

La caratteristica e ... Esempio di marcatura

Ereditata senza modifiche 3.(3.) Il cliente inserisce i criteri di ricerca richiestiEreditata e rinumerata 6.2(6.1) Il sistema comunica al Cliente che non sono stati trovati prodotti

che soddisfano i criteri specificatiEreditata e ridefinita 1.(o1) Il cliente seleziona “trova prodotto”

Ereditata, ridefinita e rinumerata 5.2(o5.1) Il sistema mostra una pagina con i dati di non piu di cinque libriAggiunta 6.3 Il sistema visualizza nuovamente la pagina di ricerca “trova libro”

Tabella 4.4. La sintassi per le cinque operazioni nei casi d’uso figli


La Figura 4.15 illustra un particolare del diagramma dei casi d’uso di un sistema di vendite. C’eun caso d’uso generalizzato TrovaProdotto da cui discendono due casi d’uso specializzati TrovaLibroe TrovaCD.

Figura 4.15. Un particolare del diagramma dei casi d’uso di un sistema di vendite

La Figura 4.16 riporta le specifiche del caso d’uso TrovaProdotto; si osservi che e descritto inmodo molto astratto.

Figura 4.16. Le specifiche del caso d’uso TrovaProdotto

Uno dei casi d’uso figli, TrovaLibro, e riportato nella Figura 4.17. L’esempio illustra l’applicazionedel linguaggio di marcatura per indicare le caratteristiche ridefinite e quelle aggiunte.

Come mostrato nella Figura 4.17, il caso d’uso figlio TrovaLibro e molto piu concreto. Essospecializza il caso d’uso genitore piu astratto per gestire un particolare tipo di prodotto, ovvero ilibri.

Se un caso d’uso generalizzato non ha una sequenza degli eventi, oppure ne ha una incompleta,allora si dice che e un caso d’uso astratto. I casi d’uso generalizzati astratti sono molto comuni inquanto consentono di fissare un comportamento ad un altissimo livello di astrazione.

Dal momento che i casi d’uso astratti non hanno una sequenza degli eventi completa non potrannomai essere eseguiti dal sistema.

4.8 <<include>> 59

Figura 4.17. Le specifiche del caso d’uso TrovaLibro

I casi d’uso astratti potrebbero avere, al posto della sequenza degli eventi, anche solo una semplicedescrizione testuale del comportamento tipico che ci si aspetta che venga implementato nei casi d’usospecializzati che ne derivano. Questo testo puo essere inserito nella sezione “Breve descrizione” delcaso d’uso.

Come si e visto, nei casi d’uso figli e difficile visualizzare le caratteristiche ereditate. Si deve usareun tipo di linguaggio di marcatura o una convenzione tipografica che tipicamente le parti interessatetrovano poco chiari. Questo, pero, e un inconveniente serio perche i casi d’uso servono proprio acomunicare con le parti interessate.

Un altro svantaggio e che si deve mantenere manualmente la consistenza tra i genitori e i figliquando uno di essi cambia. Questo e un compito complesso e soggetto a errori.

Un modo di affrontare questo problema consiste nel limitare il caso d’uso genitore cosı che nonabbia una sequenza degli eventi principale ma solo una breve descrizione della sua semantica. In questocaso non ci si deve preoccupare dell’ereditarieta o della ridefinizione.

Questo approccio semplifica la generalizzazione del caso d’uso ed e un modo molto efficace dimostrare che uno o piu casi d’uso sono veramente solo varianti specifiche di un caso d’uso piu generale.Quest’ultimo consente di concepire il sistema in modo astratto e puo consentire di semplificare ilsistema software.

4.8 <<include>>

Scrivere i casi d’uso puo diventare un’attivita molto ripetitiva.Si supponga, per esempio, di modellare un sistema per il Personale (Figura 4.18).A fronte di quasi tutte le operazioni che chiederemo al sistema sara prima necessario individuare

uno specifico impiegato sui cui dati operare.


Figura 4.18. Modello di un sistema per il Personale

Se fosse necessario scrivere questa sequenza di eventi (autenticazione utente, inserimento degliesremi identificativi dell’impiegato, etc.) ogni volta che serve reperire le informazioni di un impiegato,i diversi casi d’uso risulterebbero piuttosto ripetitivi.

La relazione <<include>> tra casi d’uso consente di includere il comportamento di un caso d’usoin un punto della sequenza di eventi di un altro caso d’uso.

Il caso d’uso che include il comportamento e detto caso d’uso base. Il caso d’uso il cui comporta-mento e incluso viene detto caso d’uso di inclusione.

Deve essere indicato il punto preciso del caso d’uso base dove e richiesta l’inclusione del compor-tamento del caso d’uso di inclusione.

La sintassi <<include>> e simile alla chiamata di una funzione e, in effetti, anche il suo significatoe molto simile.

La semantica di una relazione <<include>> e piuttosto semplice (Figura 4.19). Il caso d’uso baseesegue la propria sequenza di eventi fino al punto di inclusione, quindi l’esecuzione passa al caso d’usodi inclusione. Quando il caso d’uso di inclusione ha terminato la propria esecuzione, il controllo tornanuovamente al caso d’uso base.

Figura 4.19. La semantica della relazione <<include>>

Il caso d’uso base non e completo senza tutti i suoi casi d’uso di inclusione. Il caso d’uso di inclusionee parte integrante del caso d’uso base.

Tuttavia il caso d’uso di inclusione puo anche non essere completo. Questo succede se il caso d’usodi inclusione contiene una sequenza di eventi parziale e non ha un proprio significato se non vieneincluso in un caso d’uso base predisposto. Ci si riferisce spesso a questo tipo di caso d’uso come a unframmento di comportamento.

Si puo anche dire che in questa situazione il caso d’uso non e istanziabile: non puo essere avviatodirettamente da un attore ma puo essere esclusivamente eseguito quando viene incluso in un casod’uso base.

Se, invece, il caso d’uso di inclusione e di per se completo, allora si tratta di un normale caso d’usoed e istanziabile. E, infatti, ragionevole che possa essere avviato da un attore.

4.9 <<extend>> 61

La Figura 4.20 riporta il caso d’uso di inclusione TrovaDatiImpiegato che e incompleto e quindinon istanziato.

Figura 4.20. Il caso d’uso di inclusione TrovaDatiImpiegato

4.9 <<extend>>

La relazione <<extend>> fornisce un modo di aggiungere comportamento a un caso d’uso esistente(Figura 4.21).

Figura 4.21. Esempio di utilizzo della relazione <<extend>>

Il caso d’uso base mette a disposizione un insieme di punti di estensione a ciascuno dei quali epossibile agganciare un nuovo comportamento.

Il caso d’uso di estensione fornisce, invece, un insieme di segmenti inseribili che possono essereagganciati ai punti di estensione del caso d’uso base.

La stessa relazione <<extend>> puo essere utilizzata per specificare esattamente quali punti diestensione del caso d’uso base vengono estesi al caso d’uso di estensione.

Cio che rende interessante la relazione <<extend>> e che il caso d’uso base non sa assolutamenteniente del caso d’uso di estensione: fornisce solo dei punti di inserzione di comportamento.

In effetti, il caso d’uso base e del tutto completo anche senza le sue estensioni.


Questo e molto diverso dalla relazione <<include>> in cui il caso d’uso base e incompleto senzai casi d’uso inclusi.

L’altro elemento interessante e che i punti di estensione non fanno propriamente parte della se-quenza di eventi del caso d’uso base, come un qualunque passo, ma vengono inseriti tra due passisuccessivi della sequenza.

I punti di estensione sono indicati nella sequenza di eventi del caso d’uso base come mostrato nellaFigura 4.22. E, inoltre, possibile indicare i punti di estensione anche sul diagramma dei casi d’usoelencandoli in una nuova sottosezione dell’icona del caso d’uso base.

Figura 4.22. Formalismo utilizzato per indicare i punti di estensione

Si osservi che i punti di estensione presenti nella sequenza degli eventi non sono numerati. Vengonoinseriti tra due passi successivi della sequenza.

Con la relazione <<extend>> il caso d’uso base si comporta come un framework modulare in cuie possibile inserire estensioni in punti di estensione predefiniti.

Nell’esempio riportato nella Figura 4.22 si puo vedere che il caso d’uso base RestituzioneLibro

ha un punto di estensione chiamato PrestitoScaduto tra il passo 3 e il passo 4 della sequenza dieventi.

Si puo, quindi, capire come la relazione <<extend>> sia un buon modo di risolvere casi eccezionalio casi in cui non sia possibile conoscere a priori tutte le possibili estensioni.

4.9.1 Il caso d’uso di estensione

I casi d’uso di estensione solitamente sono incompleti e non possono quindi essere istanziati. Essisono tipicamente costituiti da uno o piu frammenti di comportamento, chiamati segmenti inseribili.La relazione <<extend>> specifica il punto di estensione del caso d’uso base in cui verra inserito ilsegmento inseribile.

La relazione e soggetta alle seguenti regole:

• La relazione <<extend>> deve specificare uno o piu punti di estensione del caso d’uso base; incaso contrario resta sottinteso che la relazione <<extend>> si riferisce a tutti i punti di estensione.

• Il caso d’uso di estensione deve avere tanti segmenti inseribili quanti sono i punti di estensionespecificati nella relazione <<extend>>.

• E consentito avere due casi d’uso di estensione che “estendano” lo stesso punto di estensione dellostesso caso d’uso base ma, se succede, l’ordine in cui verranno eseguiti i due segmenti inseribili eindeterminato.

4.9 <<extend>> 63

La Figura 4.23 mostra il caso d’uso di estensione EmissioneMulta che contiene un segmentoinseribile.

Figura 4.23. Le specifiche del caso d’uso EmissioneMulta

E previsto che il caso d’uso di estensione possa avere precondizioni e postcondizioni. Le precondi-zioni devono essere soddisfatte altrimenti il segmento inseribile non viene eseguito. Le postcondizionirappresentano un vincolo sullo stato del sistema che deve essere vero quando termina l’esecuzione delsegmento inseribile.

Anche i casi d’uso di estensione possono avere casi d’uso di estensione o casi d’uso di inclusione.Tuttavia, si tende ad evitarlo perche cio rende il modello dei casi d’uso troppo complesso.

4.9.2 Segmenti inseribili multipli

Un caso d’uso d’estensione puo contenere piu di un segmento inseribile.Questo e utile quando non e possibile effettuare l’estensione in modo semplice in un unico segmento

inseribile perche e necessario intercalare alcuni passi del caso d’uso base tra quelli del segmentoinseribile.

Nell’esempio riportato nella Figura 4.24 si vede che dopo aver registrato e stampato una multail controllo torna alla sequenza di eventi principale del caso d’uso base per processare la riconsegnadi eventuali altri libri in prestito scaduto, quindi, infine, al punto di estensione <pagamentoMulta>,viene gestito l’eventuale incasso complessivo di tutte le multe.

Senza segmenti inseribili multipli sarebbe stato necessario combinare le operazioni di emissione,stampa e incasso della multa, con la conseguenza che ogni multa sarebbe stata gestita singolarmente...un processo che risulta sicuramente meno efficiente.

Come illustra la Figura 4.24, quando si creano casi d’uso di estensione con piu segmenti ciascunsegmento deve essere identificato con un numero. Questo perche l’ordine dei segmenti e importante:il primo segmento viene inserito al primo punto di estensione, etc. Si deve fare attenzione percio ascrivere i segmenti nell’ordine corretto e mantenere sempre questo ordine.

4.9.3 Estensioni condizionali

La Figura 4.25 riporta un sistema di gestione di una biblioteca leggermente meno aggressivo, in cui laprima volta che si restituisce un libro in ritardo si riceve solo un avviso, mentre dalla seconda voltain poi si viene multati.

E possibile modellare questo sistema aggiungendo un nuovo caso d’uso di estensione EmissioneAvvisoe assoggettando le relazioni <<extend>> a delle nuove condizioni.

Le condizioni sono espressioni booleane e ciascun segmento eseguibile verra eseguito soltanto se larelativa espressione risulta vera.

Si osservi che il nuovo caso d’uso di estensione EmissioneAvviso estende soltanto il punto diestensione <PrestitoScaduto>.


Figura 4.24. Un esempio di utilizzo di segmenti multipli

Figura 4.25. Esempio di utilizzo delle estensioni condizionali

D’altra parte il caso d’uso di estensione EmissioneMulta estende sia il punto <PrestitoScaduto>

che il punto <PagamentoMulta>.In questo modo e immediato capire che il caso d’uso EmissioneAvviso (Figura 4.26) deve contenere

esattamente un segmento inseribile mentre il caso d’uso EmissioneMulta deve contenerne due.

4.10 Quando usare le tecniche avanzate

Le tecniche avanzate devono essere utilizzate soltanto se semplificano il modello dei casi d’uso.L’esperienza dimostra che i migliori modelli di casi d’uso sono semplici e immediati.E importante ricordarsi che il modello dei casi d’uso e una dichiarazione di requisiti e, in quanto

tale, deve essere accessibile non solo ai modellatori, ma anche a tutte le parti interessate.Un modello dei casi d’uso semplice che utilizza queste tecniche avanzate con parsimonia e, sotto

ogni aspetto, preferibile a uno che ne utilizza troppe, anche se quest’ultimo, almeno per un modellatore,puo risultare in qualche modo piu elegante.

L’esperienza di modellazione di casi d’uso, maturata su molti e diversi progetti, insegna che:

• solitamente le parti interessate riescono a capire facilmente attori e casi d’uso, anche se e necessarioun minimo di formazione;

4.11 Suggerimenti su come scrivere i casi d’uso 65

Figura 4.26. Le specifiche del caso d’uso EmissioneAvviso

• le parti interessate hanno maggiori difficolta a capire la generalizzazione tra attori;• un uso eccessivo di relazioni <<include>> puo rendere i modelli dei casi d’uso difficili da com-

prendere: le parti interessate e i modellatori devono studiare piu casi d’uso per avere un buonquadro d’insieme;

• le parti interessate difficilmente riescono ad afferrare il concetto di relazione <<extends>>:questo anche a fronte di approfondite e chiare spiegazioni;

• anche un numero sorprendentemente elevato di modellatori non capisce bene la semantica dellarelazione <<extends>>;

• la generalizzazione tra casi d’uso andrebbe evitata, a meno che vengano utilizzati casi d’uso gene-ralizzati astratti (e non concreti): in caso contrario e necessario aggiungere troppa complessita aicasi d’uso specializzati.

4.11 Suggerimenti su come scrivere i casi d’uso

In questa sezione vengono forniti alcuni consigli su come scrivere i casi d’uso.

4.11.1 Mantenere i casi d’uso brevi e semplici

Il criterio fondamentale dei casi d’uso e che devono essere brevi e semplici e includere solo i datinecessari per fissare i requisiti.

Purtroppo, in alcuni progetti si coglie la tendenza a diffidare delle cose brevi e semplici e prediligeregrosse quantita di documentazione. Grady Booch chiama questa tendenza “passione per la carta”.

Una buona regola pratica e assicurarsi che la sequenza degli eventi principale di un caso d’usooccupi una sola pagina. Se si estende su piu di una pagina, quasi certamente il caso d’uso e troppolungo. In effetti, si scoprira che molti casi d’uso non arrivano a meta pagina.

Bisogna iniziare semplificando il testo (a questo proposito si deve ricordare di usare frasi brevi).Va eliminato qualunque dettaglio di progettazione. Se il caso d’uso e ancora troppo lungo il problemava analizzato nuovamente. Magari c’e piu di un caso d’uso? Si possono magari scorporare sequenze diflussi alternative?

4.11.2 Il cosa e il come

E importante ricordare che si scrivono casi d’uso per stabilire cosa gli attori richiedono che il si-stema faccia e non come il sistema dovrebbe farlo. Il come entra in gioco nel flusso di lavoro dellaprogettazione.

Confondere il cosa con il come e un problema che emergera piu volte. Quando si scrive il casod’uso si immagina una soluzione.

Per esempio, si consideri il seguente frammento di codice:


...

4. Il sistema chiede al cliente di confermare l’ordine.

5. Il Cliente preme il pulsante OK.

...

In questo passo l’autore del caso d’uso ha immaginato una sorta di interfaccia utente: un modulocon un pulsante OK. A causa di cio il caso d’uso non e piu una semplice dichiarazione di requisiti mauna progettazione primitiva.

Un modo migliore per esprimere il passo 5 e il seguente:

...

5. Il Cliente accetta l’ordine.

...

I dettagli della progettazione (che non si conoscono ancora!) vanno tenuti fuori dal caso d’uso.

4.11.3 Evitare la scomposizione funzionale

Un errore comune nell’analisi dei casi d’uso e creare un insieme di casi d’uso “di alto livello” e poidividerlo in un insieme di casi d’uso di livello inferiore e cosı via fino a ottenere casi d’uso primitivisufficientemente dettagliati per l’implementazione. Questo approccio alla progettazione software e notocome scomposizione funzionale ed e sempre sbagliato quando viene applicato alla modellazione dei casid’uso.

Nella Figura 4.27, l’analista ha definito l’operazione di un sistema bibliotecario che usa un unicocaso d’uso di alto livello, ConduzioneBiblioteca, e poi l’ha scomposto in casi d’uso a livelli semprepiu dettagliati creando una scomposizione funzionale.

Figura 4.27. Un esempio di scomposizione funzionale

Molti analisti non OO considererebbero la Figura 4.27 plausibile. Tuttavia, come modello dei casid’uso ha molti aspetti inaccettabili:

4.11 Suggerimenti su come scrivere i casi d’uso 67

• Invece di concentrarsi sulla raccolta dei requisiti, il modello si focalizza sulla strutturazione di questirequisiti in modo artificiale: esistono molte scomposizioni possibili.

• Il modello descrive il sistema come un insieme di funzioni annidate. Tuttavia, i sistemi OOsono insiemi di oggetti cooperanti che inviano messaggi. Qui chiaramente c’e un’incongruenzaconcettuale.

• Solo i livelli piu bassi dei casi d’uso (AggiuntaLibro, EliminazioneLibro, AggiuntaTessera,EliminazioneTessera, PrestitoLibro, RestituzioneLibro) hanno una specifica interessante. Ilivelli piu alti chiamano quelli piu bassi e non aggiungono nulla al modello in termini di raccoltadei requisiti.

• Per le parti interessate e difficile capire il modello: ci sono molti casi d’uso piuttosto astratti(ConduzioneBiblioteca, GestioneLibri, GestioneTessere, GestionePrestiti) e molte rela-zioni <<include>> con livelli piu bassi.

L’uso di un approccio di scomposizione funzionale suggerisce che l’analista ha pensato al siste-ma in modo sbagliato. Spesso cio indica che l’analista e preparato professionalmente in tecniche diprogrammazione procedurale piu tradizionali e non conosce ancora bene il paradigma OO. In questocaso, in genere, e consigliabile utilizzare un modellatore di casi d’uso esperto che fornisca valutazionie supervisioni.

Non tutti gli esempi di scomposizione funzionale sono ovvi come quello dell’esempio della Figura4.27. Spesso si scopre che parti del modello dei casi d’uso sono corrette, mentre altre sono statescomposte.

E buona norma controllare una qualsiasi parte del modello dei casi d’uso che ha una profondagerarchia per possibili scomposizioni funzionali.

Infine, bisogna sottolineare che nella modellazione dei casi d’uso le gerarchie si formano natural-mente. Tuttavia, queste gerarchie naturali non sono quasi mai profonde piu di uno o al massimo duelivelli e l’intero modello non si basa mai su un solo caso d’uso.

1 Uniﬁed Modelling Language - unirc.it · Ovviamente oﬀre un supporto eccellente per i...

Documents

Transcript of 1 Uniﬁed Modelling Language - unirc.it · Ovviamente oﬀre un supporto eccellente per i...