Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Sergio Di Martino » 5.Introduzione ad UML: Gli Use Case Diagrams


Obiettivi della lezione

  • Cos’è UML: scopi, storia, obiettivi.
  • Fornire alcuni elementi di base su UML.
  • Introdurre i diagrammi principali.
  • Fornire indicazioni sulle modalità di utilizzo di UML.

Nelle lezioni successive si entrerà maggiormente in dettaglio sui formalismi.

Unified Modeling Language (UML)

Other Placeholder: Linguaggio (e notazione) universale, per rappresentare qualunque tipo di sistema (software, hardware, organizzativo, …).
Standard OMG (Object Management Group), dal nov. 1997.
Creatori:

  • Grady Booch, Ivar Jacobson e Jim Rumbaugh;
    • noti come “los gringos” dell’Ingegneria del SW.

Definizione Ufficiale:
Un linguaggio per specificare, visualizzare, e realizzare i prodotti di sistemi software, e anche per il business modeling. L’ UML rappresenta una collezione di “best engineering practices” che si sono dimostrate utili nella progettazione di sistemi complessi e di grandi dimensioni.”

UML

Cos’è UML?

  • E’ un linguaggio di modellazione e specifica di sistemi, basato sul paradigma object-oriented.
  • Serve a specificare le caratteristiche di un nuovo sistema, oppure a documentarne uno già esistente.
  • E’ uno strumento di comunicazione tra i diversi ruoli coinvolti nello sviluppo e nell’evoluzione dei sistemi.
  • UML svolge un’importantissima funzione di lingua franca nella comunità della progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa UML per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico.

Cosa non è UML?

  • Non è una “metodologia”.
  • E’ un linguaggio, non un metodo completo :notazione, sintassi e semantica sono standard.
  • Ma UML non è legato ad uno specifico processo, e non fornisce indicazioni sul proprio utilizzo.
  • Quindi può essere (ed è) utilizzato da persone e gruppi che seguono approcci diversi (è “indipendente dai metodi”).
  • UML è indipendente dal linguaggio di programmazione utilizzato.

Breve Storia

I linguaggi per la modellazione object-oriented iniziano a svilupparsi negli anni ‘80.
Si trattava di notazioni di varia natura, per descrivere la struttura di un sistema software a oggetti (in termini di classi e relazioni fra classi) ed il suo comportamento dinamico.
La proliferazione di queste notazioni diede luogo a quelle che furono poi battezzate “guerre dei metodi” (method wars), con diverse organizzazioni,che adottavano e sostenevano una particolare notazione a scapito delle altre.
Nella metà degli anni ‘90 diversi metodi e linguaggi iniziarono a fondersi, e si iniziò a delineare la possibilità di una integrazione dei principali formalismi in una notazione universalmente accettabile.
Fra le metodologie e le notazioni più apprezzate e diffuse del periodo spiccavano OMT (Object Modeling Technique) di Rumbaugh, e il cosiddetto metodo Booch di Grady Booch, entrambi ricercatori presso Rational Software.
Il lavoro di unificazione iniziò con loro; in seguito si unì a questo sforzo Jacobson.
Il primo risultato congiunto di questo team fu OOSE (Object Oriented Software Engineering).
Mentre “i tre gringos” operavano per unificare i propri approcci all’analisi e alla progettazione a oggetti, il progetto fu accolto sotto l’egida dell’OMG (Object Management Group).
Nel 1995, l’OMG raccolse tutti i principali metodologisti del settore in un incontro internazionale per discutere della notazione unificata.
Nel 1996 l’OMG emise una RFP (Request for Proposal) per tale notazione.
Nello stesso anno, Booch, Rumbaugh e Jacobson misero a punto le release 0.9 e 0.91 di UML.

Breve Storia (segue)

Il progetto fu ben accolto dalla comunità internazionale e molte grandi organizzazioni si unirono a Rational per proseguirlo.
Questo gruppo esteso realizzò, nel 1997, UML 1.0, che fu sottoposto alla OMG come risposta alla RFP dell’anno precedente.
La release 1.1 di UML contribuì a consolidare la semantica del linguaggio e incluse elementi tratti da una proposta avanzata indipendentemente all’OMG da un gruppo composto da IBM, ObjectTime, Ptech e altre.
La versione 2.0 di UML, ufficializzata da OMG nel 2005, presenta numerose novità rispetto alla precedente versione 1.5, che resta comunque quella più diffusamente supportata dai tool di modellazione e citata nella letteratura.
Principali novità di UML 2.0:

  • ampliamento, razionalizzazione e revisione del metamodello, permettendo una maggiore flessibilità;
  • introduzione del linguaggio formale OCL come parte integrante di UML;
  • numerosi nuovi elementi per la costruzione dei diagrammi tradizionali;
  • alcuni nuovi tipi di diagrammi.

Aspetti della modellazione

UML consente di descrivere un sistema secondo tre aspetti principali.
Ciascuno ha un insieme di tipi di diagrammi specifici.
Sono tutti in relazione fra loro!

  1. Il modello funzionale rappresenta il sistema dal punto di vista dell’utente, ovvero ne descrive il suo comportamento così come esso è percepito all’esterno, prescindendo dal suo funzionamento interno. Questo tipo di modellazione serve nell’analisi dei requisiti. La modellazione funzionale utilizza gli Use Case Diagram.
  2. Il modello a oggetti rappresenta la struttura e sottostruttura del sistema utilizzando i concetti object-oriented di classe, oggetto, le relazioni fra classi e fra oggetti. Questo tipo di modellazione può essere utilizzata sia nella fase di analisi del dominio che nelle varie fasi di progetto a diversi livelli di dettaglio. Utilizza class diagram, object diagram, e deployment diagram.
  3. Il modello dinamico rappresenta il comportamento degli oggetti del sistema, cioè le dinamiche delle loro interazioni. È strettamente legato al modello a oggetti e viene impiegato negli stessi casi. Utilizza i sequence diagram, gli activity diagram e gli statechart diagram.

Diagrammi che vedremo ad Ingegneria del SW

  • Use case Diagrams: descrivono il comportamento funzionale del sistema, come visto dall’utente.
  • Class diagrams: descrivono la struttura statica del sistema, in termini di Objects, Attributes, Associations.
  • Sequence diagrams: descrivono il comportamento dinamico tra attori e/o oggetti del sistema.
  • Statechart diagrams: descrivono il comportamento dinamico di un singolo oggetto (essenzialmente sono un’estensione degli automi a stati finiti).
  • Activity Diagrams: modellano il comportamento dinamico del sistema, focalizzandosi sul workflow.

UML – considerazioni

UML rappresenta un’evoluzione dei modelli preesistenti, più che una rivoluzione.

E’ adatto a esprimere modelli di varia tipologia, creati per obiettivi diversi: può descrivere un sistema software a diversi livelli di astrazione, dal piano più svincolato dalle caratteristiche tecnologiche fino all’allocazione dei componenti software nei diversi processori in un’architettura distribuita.

UML è sufficientemente complesso per rispondere a tutte le necessità di modellazione, ma è opportuno “ritagliarlo” in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto.
“For 80% of all software, only 20% of UML”
“keep the process as simple as possible!”

UML Core Conventions

I Rettangoli sono classi o istanze.
Gli ovali sono funzioni o Use Case.
Le istanze sono denotate dal nome sottolineato:

  • myWatch: SimpleWatch;
  • joe: Firefighter.

I tipi sono denotati da nomi NON sottolineati:

  • SimpleWatch;
  • Firefighter.

I diagrammi sono dei grafi:

  • i nodi sono le entità;
  • gli archi sono relazioni tra le entità.

Requisiti e casi d’uso

Il primo passo di “qualsiasi” processo di sviluppo è la definizione dei requisiti.
Jacobson (OOSE) propone una notazione particolare che è confluita in UML: i casi d’uso.
Catturano il comportamento esterno del sistema da sviluppare, senza dover specificare come tale comportamento viene realizzato (sistema = black-box).
Forniscono una descrizione delle “modalità” di utilizzo del sistema da parte di un utilizzatore (attore).

Caso d’uso

  • Una sequenza di azioni, incluse le varianti, che un sistema compie per produrre un risultato osservabile che ha un valore per un attore.
  • Un caso d’uso corrisponde a un compito che l’attore vuole eseguire (l’attore inizia il caso d’uso) o il sistema deve eseguire (il sistema inizia il caso d’uso).
  • La descrizione di un caso d’uso definisce cosa accade nel sistema in seguito all’evento di innesco.
  • Generalmente lo stimolo di inizio parte dall’attore ma può anche essere il sistema stesso a iniziare il caso d’uso (es. produzione cedolini a fine mese, ricarico automatico di un magazzino).
  • È una funzionalità dal punto di vista di chi la utilizza.

Diagramma dei Casi d’Uso

Contiene:

  1. attori;
  2. casi d’uso;
  3. relazioni di associazione, dipendenza e generalizzazione.

Usato per modellare il contesto di un sistema:

  • gli attori sono esterni al sistema;
  • i  casi d’uso sono all’interno del sistema.

Esempio di Diagramma dei Casi d’Uso.

Esempio di Diagramma dei Casi d'Uso.


Diagramma dei Casi d’Uso (segue)

Usato per modellare (visualmente) i requisiti funzionali:

  • ogni caso d’uso corrisponde a uno o più requisiti funzionali;
  • ogni caso d’uso è coinvolto in una qualche relazione;
  • diversi livelli di dettaglio;
  • decomposizione gerarchica.

Mostra:

  • le modalità di utilizzo del sistema (casi d’uso);
  • gli utilizzatori e coloro che interagiscono con il sistema (attori);
  • le relazioni tra attori e casi d’uso.
Esempio di Diagramma dei Casi d’Uso.

Esempio di Diagramma dei Casi d'Uso.


Elementi grafici del modello dei casi d’uso

Attore: è qualcuno (utente) o qualcosa (sistemi esterni – dispositivi hardware) che:

  • controlla le funzionalità;
  • fornisce input o riceve output dal sistema;
  • un attore modella un’entità esterna che comunica con il sistema;
  • ogni attore ha un nome univoco.

Use Case: è un’unità funzionale parte del sistema.
Un caso d’uso rappresenta una funzionalità offerta dal sistema, in termini di un flusso di eventi.
Ogni caso d’uso ha un nome univoco.


Relazioni principali

  • Association: identifica relazioni semplici tra attori e casi d’uso.
  • Include: fattorizza proprietà comuni.
  • Extend: identifica comportamenti simili (varianti). A può essere visto come una variante di B.
  • Generalization: si applica sia ad attori che a use case. A eredita il comportamento di B. A può essere sostituito ad ogni occorrenza di B.
Relazioni negli Use Case Diagrams.

Relazioni negli Use Case Diagrams.


Relazione di Inclusione

Un comportamento comune a più casi d’uso diventa un caso d’uso che è incluso nei casi d’uso di partenza.
L’inclusione avviene in un punto preciso della descrizione del caso d’uso includente. Il caso incluso non ha senso da solo.
Rappresentato graficamente come una dipendenza stereotipata come <<include>>
Può essere usata per migliorare la decomposizione funzionale o per esplicitare il riuso di UC.

Problema Decomposizione Funzionale

Una funzione nella definizione originale del problema è troppo complessa per essere descritta atomicamente.
Riuso: Molti UC eseguono dei sottopassi in comune. Esempio di relazione di Inclusione.

Esempio di relazione di Inclusione.

Esempio di relazione di Inclusione.


Relazione di Estensione

La relazione di estensione accade quando uno UC estende il comportamento di un altro.
Lo use case base deve specificare graficamente i punti di estensione (extension points) cioè i punti in cui il comportamento viene esteso.
Si indica con una freccia aperta con linea tratteggiata sormontata dallo stereotipo <<extend>>.

Esempio di relazione di Estensione.

Esempio di relazione di Estensione.


Generalizzazione

Si indica con una linea continua e freccia con la punta non riempita.
Deve sempre valere il principio di sostituzione.

Si può applicare:
Tra Attori
La relazione di generalizzazione fra attori si applica quando un attore è un sottotipo di un altro e questo comporta delle differenze nel rapporto con il sistema.
La relazione viene indicata da una freccia con la punta non riempita.

Tra Casi d’Uso
Un caso d’uso figlio eredita il comportamento ed il significato del caso d’uso padre.
La relazione di generalizzazione fra use cases si ha quando un caso d’uso è un caso particolare di un altro, per questo è utile per rappresentare i percorsi alternativi di un’interazione complessa con il sistema.

Generalizzazione tra Attori.

Generalizzazione tra Attori.

Generalizzazione tra Casi d’Uso.

Generalizzazione tra Casi d'Uso.


Esercizio: Sportello Bancomat

Vi si chiede di realizzare il sw per uno sportello bancomat automatico.

  • L’utente deve essere in grado di depositare assegni sul suo conto.
  • L’utente deve essere in grado di prelevare i soldi dal suo conto.
  • L’utente deve poter interrogare il Sistema sul saldo del suo conto.
  • Se lo richiede, l’utente deve poter ottenere la ricevuta per la transazione.
  • I tipi di transazione sono prelievo o deposito.
  • La ricevuta deve indicare la data della transazione, il numero del conto, il saldo precedente e successivo la transazione.
  • Dopo ogni transazione, il nuovo saldo deve essere visualizzato all’utente.

Costruzione del modello dei casi d’uso

Gli use case possono essere ricavati dalle interviste con gli utenti. Si identificano:

  • gli obiettivi: ciò che il sistema dovrebbe fare secondo gli utenti;
  • le interazioni: cosa vorrebbero (potrebbero) fare i diversi utenti.

Gli use case di alto livello sono volutamente generici. I dettagli vanno aggiunti raffinando le funzionalità del sistema. Bisogna esplorare le diverse possibilità per non introdurre prematuramente scelte progettuali.
Il processo di definizione degli use case è iterativo:

  • si inizia identificando il comportamento più semplici;
  • si descrivono i comportamenti alternativi e più complessi.

Quando smettere?

  • Un buon livello di dettaglio facilita tutte le attività successive;
  • Troppi dettagli;
  • Complicherebbero inutilmente la descrizione;
  • Introdurrebbero prematuramente scelte progettuali;
  • Precluderebbero la visione d’insieme.

Passi per la costruzione di uno Use Case Diagram

  1. Identificazione degli attori
  2. Identificazione dei casi d’uso
  3. Definizione delle associazioni fra attori e casi d’uso
  4. Descrizione dei casi d’uso
  5. Strutturazione dei casi d’uso

Dettaglio Passi

1: Identificazione degli attori
Identificare le persone che interagiscono con il sistema per eseguire qualche compito: persone che necessitano del sistema per svolgere qualche compito, persone che il sistema richiede per svolgere qualche compito; considerare sia i compiti principali che quelli di supporto al sistema, quali manutenzione ed amministrazione.
Raggruppare le persone identificate secondo i loro ruoli (responsabilità) rispetto al sistema.
Identificare altri sistemi software e dispositivi esterni che interagiscono con il sistema per svolgere qualche compito.

2: Identificazione dei casi d’uso
Per ogni attore:

  • identificare i compiti o funzioni che l’attore deve essere in grado di eseguire;
  • identificare i compiti che il sistema richiede che l’attore esegua.

Raggruppare compiti e funzioni in casi d’uso

  • i casi d’uso devono corrispondere ad un obiettivo specifico per l’attore o per il sistema;
  • raggruppare funzioni che sono eseguite in sequenza o che sono innescate dallo stesso evento;
  • il caso d’uso non deve essere né troppo grande né troppo piccolo.

Assegnare al caso d’uso un nome significativo che sintetizzi la/le funzionalità svolta/e.

Dettaglio Passi (segue)

3: Definizione delle associazioni fra attori e casi d’uso
Ogni attore deve partecipare in almeno un caso d’uso.
Ogni caso d’uso deve avere almeno un attore con cui comunica.
Se due attori partecipano agli stessi casi d’uso considerare la possibilità di combinarli in un unico attore.

4: Descrizione dei casi d’uso
Considerare sia lo scenario principale che scenari alternativi ed eccezionali.
Per ogni scenario specificare:

  • come e quando il caso d’uso inizia;
  • chi avvia il caso d’uso;
  • interazione tra attore/i e caso d’uso e cosa viene scambiato;
  • come e quando c’è bisogno di dati memorizzati o di memorizzare dati;
  • come e quando il caso d’uso termina.

Se due casi d’uso hanno comportamenti leggermente diversi e gli stessi attori, considerare la possibilità di avere un unico caso d’uso con scenari alternativi.

Dettaglio Passi (segue)

5: Strutturazione dei casi d’uso
Identificare le relazioni di generalizzazione ed estensione:

  • specializzare i casi d’uso che hanno molti scenari alternativi;
  • collegare i nuovi casi d’uso a quelli di partenza mediante relazioni di generalizzazione o di <<extend>>.

Identificare le relazioni di inclusione:

  • individuare parti comuni in casi d’uso diversi;
  • collegare i casi d’uso che condividono una parte comune al nuovo caso d’uso (rappresentante il comportamento condiviso) mediante l’associazione <<include>>.
  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion