Sei sulla pagina 1di 76

MODELLAZIONE E PROGETTAZIONE

CON UML

INTRODUZIONE

Introduzione a UML
DEFINIZIONE DI UML

Unified Modeling Language (UML) è una notazione per analizzare, specificare,


visualizzare e documentare lo sviluppo dei documenti di progetto di un sistema ad
oggetti.
Più precisamente, UML è un linguaggio con specifica semantica semiformale che
include sintassi astratta, rigorose regole grammaticali e semantica dinamica.
In sintesi, UML è una notazione associata ad un metamodello (ontologia) che
descrive la notazione stessa.

Introduzione a UML
OBIETTIVI DI UML

Booch, Rumbaugh, Jacobson si posero precisi obiettivi nella definizione di UML, espressi
nella “dichiarazione di intenti” di UML.
1. Fornire agli utenti un linguaggio di modellazione visuale, pronto all’uso ed espressivo, che
permetta loro di sviluppare e di scambiarsi modelli significativi.

2. Offrire meccanismi di estensibilità e di specializzazione per estendere i concetti fondamentali


3. Essere indipendenti da particolari linguaggi di programmazione e processi di sviluppo

4. Offrire una base formale per comprendere il linguaggio di modellazione

5. Supportare concetti di sviluppo di livello più alto quali collaborazioni, framework, pattern e
componenti

6. Integrare i processi migliori. UML integra le best practices in processi che abbracciano livelli di
astrazione, domini, architettura, stadi del ciclo di vita, tenologie di implementazione.

Introduzione a UML
PERCHÈ MODELLARE IL SOFTWARE?

Produrre software non è affatto facile: anche i sistemi apparentemente semplici tendono a
raggiungere un notevole grado di complessità.
MODELLO = semplificazione della realtà
UML è stato progettato per agevolare il processo di elaborazione di modelli:
• visualizzare in forma grafica il sistema
• specificarne la struttura ed il comportamento
• implementarlo
• documentarne tutte le decisioni prese durante le varie fasi di lavoro

Introduzione a UML
PERCHÈ MODELLARE IL SOFTWARE? VISUALIZZAZIONE

UML è stato progettato per agevolare la comunicazione fra gli attori che partecipano
allo sviluppo di un progetto software.
La maggior parte delle caratteristiche di un sistema si presta meglio per essere rappresentata
in modo grafico piuttosto che con un testo.
UML definisce un insieme di diagrammi standard attraverso i quali ogni membro del
processo di sviluppo ha la possibilità di comprendere lo stato di sviluppo del sistema, in
maniera chiara ed univoca, riducendo il rischio di interpretazioni non corrette.

Introduzione a UML
PERCHÈ MODELLARE IL SOFTWARE? SPECIFICA

Fornire la specifica di un modello = definirlo in modo preciso, completo e privo di


ambiguità.
I modelli costruiti nelle prime fasi del progetto servono a definire i requisiti dei committenti.
Addentrandosi nell’analisi è necessario arricchire i modelli iniziali per definire il sistema con
maggior grado di dettaglio. Questi modelli intermedi definiscono i concetti chiave del sistema
ed i meccanismi con i quali tali concetti verranno poi espressi.
I modelli più dettagliati descrivono completamente le caratteristiche del progetto.

Introduzione a UML
PERCHÈ MODELLARE IL SOFTWARE? COSTRUZIONE

Fine ultimo di un progetto = implementazione di codice


Molti elementi di UML sono in relazione diretta con i costrutti propri dei linguaggi di
programmazione ad oggetti (C++, Java).
Altri elementi di UML agevolano la progettazione di database o la progettazione di sistemi
distribuiti.
(vedremo esempi di creazione di codice da UML e viceversa)

Introduzione a UML
PERCHÈ MODELLARE IL SOFTWARE? DOCUMENTAZIONE

UML facilita il processo di stesura di documentazione di progetto.


Alcuni diagrammi costituiscono una buona base per la stesura di manuali utente
Altri diagrammi agevolano la definizione dei test del sistema
Chi non è stato coinvolto nel processo di modellazione ha la possibilità di comprendere i
concetti fondamentali del sistema.
I modelli ben documentati possono essere riutilizzati, in tutto o in parte, in progetti successivi.

Introduzione a UML
UML: UN PO’ DI STORIA

1989: la modellazione software con metodologie O-O si impone all’attenzione della comunità
scientifica
1991: Jim Rumbaugh, “Object Oriented Modeling and Design” (Prentice Hall). Definisce la
Object Modeling Tecnique (OMT), primo esempio di analisi nello spazio dei problemi. Molti
degli attuali diagrammi UML derivano da concetti ivi espressi.
1992: Ivar Jacobson, “Object Oriented Software Engineering” (Addison- Wesley) detto “libro
bianco” o OOSE. Definisce il processo Objectory e per la prima volta parla di Use Cases, uno
dei fondamenti di UML.
1994: Grady Booch, “Object Oriented Analysis and Design with Applications” (Addison-
Wesley). Definisce in maniera molto rigorosa ai dettagli della costruzione di un sistema
software con metodologia O-O (“metodo di Booch”). I diagrammi UML più dettagliati e più
vicini alle fasi di sviluppo sono stati definiti in questo testo.

Introduzione a UML
UML: UN PO’ DI STORIA

Fine 1994: Rumbaugh raggiunge Booch alla Rational 1995: Rational acquista la società di
Jacobson
1995: nasce la versione 1.0 di UML, che viene sottoposta all’Object Management Group
(OMG), ente preposto alla definizione degli standard in molte branche dell’informatica
1997: Booch, Rumbaugh, Jacobson, UML User Guide (Addison-Wesley). UML 1.1 diventa il
linguaggio standard per la modellazione O-O.
Gli autori vengono spesso indicati con il nickname “I tre amigos”.
Oggi: UML 1.5 - è in fase di definizione UML 2.0

Introduzione a UML
UML NON È UN LINGUAGGIO DI PROGRAMMAZIONE

• Uno degli obiettivi di UML è astrarre dalla macchina fisica, cioé:


• pensare in termini del problema e non della soluzione
• (memoria, registri, CPU... livello di astrazione troppo basso per risolvere I problemi di
grande complessità)
• UML serve per “far parlare” il problema e il progetto,
• mostrando solo l’informazione essenziale
• in base allo scopo del singolo diagramma
• UML fornisce viste multiple di uno stesso artefatto
• adattando il livello di dettaglio in base al compito affrontato dal progettista

Introduzione a UML
TIPI DI DIAGRAMMA IN UML

• Diagramma dei casi d'uso (Use case Diagram)


• Diagramma delle classi (Class Diagram)
• Diagramma di sequenza (Sequence Diagram)
• Diagramma degli oggetti (Object Diagram)
• Diagramma di stato (State Diagram)
• Diagramma di attività (Activity Diagram)

Introduzione a UML
DIAGRAMMA DEI CASI D’USO (USE CASE DIAGRAM)

Questo tipo di diagramma è molto utile per modellare il funzionamento dinamico di una
certa funzionalità del sistema. Uno dei vantaggi di questi diagrammi è il fatto di essere
estremamente semplici da leggere anche da chi non ha esperienze di UML in quanto
sono molto intuitivi.
Per fare un esempio pratico di diagramma di un caso d'uso potrebbe essere quello di
modellare l'azione di prelievo di soldi da uno sportello di una banca: l'utente inserisce la carta,
selezione la funzionalità "prelievo", inserisci il pin relativo alla carta, digita l'importo, prende i
soldi e ritira la carta.

Introduzione a UML
DIAGRAMMA DELLE CLASSI (CLASS DIAGRAM)

È il diagramma più importante nella modellazione UML e rappresenta la struttura intera


del nostro progetto.
Come dice la parola stessa, il diagramma delle classi, rappresenta le varie classi presenti
collegate tra di loro dalle rispettive relazioni.
Proprio grazie al diagramma delle classi è possibile tradurre il progetto modellato in progetto
concreto con la stesura del codice.

Introduzione a UML
DIAGRAMMA DI SEQUENZA (SEQUENCE DIAGRAM)

È un diagramma legato al diagramma dei casi d’uso ed a quello delle classi.


Il diagramma di sequenza mostra le varie azioni compiute dall'utente e dal sistema
quando viene richiesto un determinato servizio, mostrando tutte le interazioni tra i due
e tra eventuali sotto-sistemi.

Introduzione a UML
MODELLAZIONE E PROGETTAZIONE
CON UML

PRINCIPALI DIAGRAMMI

Introduzione a UML
UML
DIAGRAMMA DEI CASI D’USO

Introduzione a UML
CASI D’USO

— Visione d’insieme del sistema che si sta analizzando


— Fondamentali nelle fasi iniziali del progetto

— Rappresentano il sistema visto dall’utilizzatore


— Modellano il dialogo tra l’utilizzatore e il sistema stesso
— Descrivono l’interazione tra attori e sistema
— Non la logica propria della funzione (sono astratti)
— Espressi in forma testuale (comprensibili anche ai non addetti)
— Diversi livelli di definizione (sistema complessivo o sue parti)
— Rappresentano le modalità d’uso del sistema da parte di uno o più attori

Introduzione a UML
CASI D’USO

— Consentono di scoprire i requisiti funzionali


— Rappresentano un valido ausilio nel dialogo con l’utente
— Fondamentali con esponenti non tecnici

— Vengono rappresentati da un diagramma.

— Non tu'o è caso d’uso: condizione necessaria affinché una funzionalità venga considerata
come un caso d'uso è che abbia una relazione dire;a con l'utente.

Introduzione a UML
DIAGRAMMA DEI CASI D’USO

— Rappresenta i casi d’uso, gli attori e le associazioni che li legano.

— Visualizzano le modalità d’utilizzo del del sistema da parte di uno o più utilizzatori, che
vengono definiti attori.

— I singoli casi d’uso descrivono le iterazioni tra sistema e attori (non la logica delle
funzioni).

— Un attore è un elemento esterno al sistema che fornisce un input a cui il sistema deve
rispondere.

Introduzione a UML
ESEMPIO

Introduzione a UML
ATTORE

— Utilizzatore del sistema che interagisce con i casi


d’uso
— Può essere umano oppure un altro sistema

— Rappresenta un ruolo di un oggetto


— Un oggetto fisico (classe) può assumere ruoli
diversi e quindi essere modellato da più attori.
— Nel caso di attori umani, il nome di un attore
identifica il ruolo che l’attore svolge in quel
contesto, non il suo incarico o mansione.

Introduzione a UML
RELAZIONI TRA ATTORI E USE CASE

— La relazione indica l’esistenza di un’associazione tra un attore ed un caso d’uso.

— Quindi una particolare persona (o sistema) che si trova in un certo ruolo comunica
con specifiche istanze del caso d’uso, partecipando agli eventi rappresentati dal caso.

Introduzione a UML
ESEMPIO: E-COMMERCE

Introduzione a UML
RAPPRESENTAZIONI ACCESSORIE

— Con i diagrammi dei casi d’uso si possono inoltre rappresentare:


— Generalizzazioni tra casi d’uso
— Generalizzazioni tra attori
— Relazioni di inclusione tra casi d’uso (include)
— Relazioni di estensione tra casi d’uso (extend)

Introduzione a UML
GENERALIZZAZIONE TRA CASI D’USO

— Può esistere più di una versione di un caso d’uso, aventi ognuna alcune azioni in
comune ed altre uniche per ciascun caso.

— Nel diagramma si associano i casi d’uso con una freccia puntata verso il caso
d’uso più generale.

— Il caso d’uso specializzato eredita parte delle funzionalità del caso d’uso generico

Introduzione a UML
ESEMPIO GENERALIZZAZIONE UC

Introduzione a UML
GENERALIZZAZIONE TRA ATTORI

— L’attore specializzato eredita parte delle caratteristiche dell’attore generico.

Introduzione a UML
INCLUSIONE TRA CASI D’USO

— Un caso d’uso comprende le funzionalità di un altro caso.

— Una relazione di inclusione da un caso d’uso A (base) ad un caso d’uso B


(incluso) indica che le funzionalità del caso d’suo B saranno sempre presenti in
un istanza del caso d’uso A.

Introduzione a UML
ESTENSIONE DI UN CASO D’USO

— Un caso d’uso può essere esteso nella sua funzionalità ad un altro caso

— Una relazione di estensione da un caso d’uso A ad un caso d’uso B indica che


un istanza del caso d’uso B può essere maggiorata, sotto determinate
condizioni specificate nell’estensione, dal comportamento di A.

Introduzione a UML
DIFFERENZE TRA EXTEND ED INCLUDE

— Una relazione di inclusione (A include B)


— indica che ogni istanza del caso d’uso A include sempre il comportamento di
B

— Una relazione di estensione (A estende B)


— indica che al verificarsi di opportune condizioni (condizioni di guardia) il
comportamento di B può essere esteso dal comportamento di A.

Introduzione a UML
SPECIFICA COMPORTAMENTALE

— Ogni caso d’uso costituisce una sequenza di attività che generano un risultato per
l’attore che con esso interagisce.

— La sequenza di attività viene descritta in una specifica comportamentale


— Può essere un diagramma di attività, di sequenza, di stato o una descrizione
informale.
— Generalmente si sceglie quest’ultima.

Introduzione a UML
DESCRIZIONE DEL CASO D’USO

— Ogni descrizione di un caso d’uso è caratterizzata dalla descrizione di informazioni


di base che permettono di specificare il contesto, chi utilizza il caso d’suo, cosa
succede allo stato del sistema prima e dopo l’attivazione del caso d’uso ed uno o
più scenari di interazione.

— A loro volta gli scenari di interazione si suddividono in:


— Base, quando il caso d’uso esegue il suo compito correttamente andando
opportunamente a modificare lo stato del sistema.
— Alternativi, quando il caso d’uso termina con esiti positivi, con complicazioni o
va incontro ad errori, cioè fallisce il suo compito.

Introduzione a UML
CREARE IL DIAGRAMMA USE CASE

— Si parte da appunti e trascrizioni di interviste e colloqui con il cliente.

— Si procede per fasi


— Definizione attori e casi d’uso
— Chi utilizzerà il sistema per il data entry?
— Chi è il destinatario delle informazioni fornite dal sistema?
— Quali altri sistemi devono interagire con questo?

— Organizzare secondo priorità i casi d’uso individuati


— Sviluppare prima i più importanti

Introduzione a UML
CREARE IL DIAGRAMMA USE CASE

— Sviluppare ciascun caso d’uso


— Creare la specifica dettagliata di ogni caso d’uso

— Strutturare il diagramma dei casi d’uso


— Aggiunta di attori e casi d’uso
— Generalizzazioni
— Inclusioni
— Estensioni
— Raggruppamento in unità logiche (package)

Introduzione a UML
UML
DIAGRAMMA DELLE CLASSI

Introduzione a UML
DIAGRAMMA DELLE CLASSI

Forniscono una vista strutturale (statica) del sistema in termini di


• Classi
• Attributi
• Operazioni
• Relazioni tra classi (associazioni, generalizzazioni, .......)
Un class diagram rappresenta uno schema concettuale
• se una classe A è in relazione con una classe B, allora ogni istanza di A sarà in relazione
con un’istanza di B

Introduzione a UML
DIAGRAMMA DELLE CLASSI

La prospettiva con cui si realizza il diagramma può essere


• concettuale: studia i concetti propri del dominio, senza preoccuparsi della loro successiva
implementazione.
• di specifica: studia il software ma a livello di interfaccia e non di implementazione. Quindi
l’attenzione è concentrate sulle responsabilità delle classi ma non sui dettagli concreti.
• implementativa: il diagramma fa riferminento alle classi effettivamente realizzate con un
linguaggio OO e alle strutture dati effettivamente impiegate.

Introduzione a UML
ESEMPIO

Introduzione a UML
SIMILITUDINI

• Entità / Relazioni
• E’ una estensione dei diagrammi Entità / Relazioni.
• Introduce classificazione, istanziazione e aggregazione.
• Definisce non solo gli attributi, ma anche le operazioni.

• Altri modelli OO (Booch, OMT)


• Differenze sintattiche

Introduzione a UML
CONCETTO DI CLASSE

• Una classe descrive un gruppo di oggetti con caratteristiche comuni


• attributi
• comportamento

• Gli oggetti (istanze) di una stessa classe differiscono tra loro per I valori degli attributi che
e per le relazioni che li legano ad altri oggetti.

Introduzione a UML
CONCETTO DI CLASSE

• Una classe descrive un gruppo di oggetti con


caratteristiche comuni Nome della classe
• attributi
• comportamento

Nome della classe


• Gli oggetti (istanze) di una stessa classe differiscono
tra loro per I valori degli attributi che e per le relazioni attributo:tipo[0..1] = valoreIniziale
che li legano ad altri oggetti.
operazione(arg list): tipo ritorno

Introduzione a UML
CONCETTO DI CLASSE

Nome della classe (maiuscolo camelCase)

Libro
A1ributo privato
- codice : Integer
A1ributo pubblico + ?tolo : String A1ribu4
Metodo privato - cambiaCodice (newCode: Integer): Boolean
Metodo pubblico + getTitolo() : String Metodi

Introduzione a UML
ATTRIBUTI

visibilità nome: tipo molteplicità = default {proprietà}

— Visibilità attributo pubblico (+) o privato (-)


— Nome nome della variabile
— Tipo tipo di dato (String, Integer, Classe, ...)
— Molteplicità numero di elementi (vedi slide successive)
— Default valore iniziale dell’attributo
— Proprietà proprietà aggiuntive (const, readOnly, ...)

Introduzione a UML
ATTRIBUTI

visibilità nome: tipo molteplicità = default {proprietà}

— Visibilità attributo pubblico (+) o privato (-) nome della


— Nome variabile
— Tipo tipo di dato (String, Integer, Classe, ...) numero di
— Molteplicità
elementi (vedi slide successive)

— Default valore iniziale dell’attributo


— Proprietà proprietà aggiuntive (const, readOnly, ...)

Introduzione a UML
OPERAZIONI (FIRMA)

visibilità nome (nomeParametro:tipo,...): tipoRestituito

— Visibilità pubblico (+) o privato (-)


— Nome nome del metodo (camelCase)
— Parametri elenco nome e tipo di dato
— TipoRestituito tipo di dato restituito

— Ogni operazione di una classe deve avere una firma univoca (signature).

Introduzione a UML
VISIBILITÀ

— Un elemento è visibile all’esterno del namespace o della classe che lo contiene a


seconda della sua visibilità.
— Concetto fondamentale della OOP: incapsulamento o information hiding.

+ public altri elementi possono vedere ed usare


# protected solo dai suoi discendenti (ereditarietà)
- private solo dagli elementi nell’elemento stesso
~ package solo dagli elementi nello stesso package

Introduzione a UML
ASSOCIAZIONE BINARIA

Introduzione a UML
ASSOCIAZIONE BINARIA

Introduzione a UML
ASSOCIAZIONE: RUOLI

Introduzione a UML
ASSOCIAZIONI E GERARCHIA

Introduzione a UML
ASSOCIAZIONI: MOLTEPLICITA’

Introduzione a UML
MOLTEPLICITA’

— Nelle associazioni e nelle dichiarazioni UML consente di specificare la molteplicità


(nota anche come cardinalità).

— Specificata da Limite inferiore..Limite Superiore (N..M)

— Opzionale Limite inferiore = 0


— Obbligatorio Limite inferiore = 1
— Un solo valore Limite superiore = 1
— Più di un valore Limite superiore > 1
— Zero o più *
— Uno o più +

— Ad esempio 1, 0..1, N..M, +, *


Introduzione a UML
MOLTEPLICITA’

Introduzione a UML
ESEMPIO

Introduzione a UML
CLASSI DI ASSOCIAZIONE

* *
Azienda Persona

— Data questa associazione, aggiungiamo la regola per cui ogni Persona percepisce
uno stipendio da ogni Azienda in cui è impiegata.

— L’attributo stipendio è proprio dell’associazione tra Azienda e Persona.

Introduzione a UML
CLASSI DI ASSOCIAZIONE

* *
Azienda Persona

Posizione
+ stipendio: double

— La classe associazione che connette due classi e definisce un insieme di caratteristiche


proprie della associazione stessa

1 * Posizione * 1
Azienda Persona
+ s?pendio: double

Introduzione a UML
AGGREGAZIONE

— Speciale forma di associazione


— Relazione tra l’aggregato e le parti che lo compongono
— Relazione debole: le parti esistono anche senza il tutto

— L'aggregato può in alcuni casi esistere indipendentemente dalle parti, ma in altri casi
no.
— Più aggregati possono condividere la stessa parte
— Transitiva e asimmetrica

Computer Periferica
0..1 0..*

Introduzione a UML
COMPOSIZIONE

— Speciale forma di associazione


— Relazione molto forte: le parti dipendono dall’aggregato.
— Ogni parte può appartenere ad un solo composito per volta
— Il composito è l'unico responsabile di tutte le sue parti: questo
— vuol dire che è responsabile della loro creazione e distruzione
— Se il composito viene distrutto, devono essere distrutte anche le sue parti
*
Foglie
1 *
Albero Rami

1
Tronco

Introduzione a UML
GENERALIZZAZIONE

— La relazione di generalizzazione indica che una delle due classi considerate è


sottotipo (specializzazione) di dell’altra (supertipo).
— Ogni istanza del sottotipo è anche istanza del supertipo (polimorfismo).
— In UML la generalizzazione viene indicata con una freccia con la testa vuota.

Introduzione a UML
GENERALIZZAZIONE

Introduzione a UML
EREDITARIETÀ E SOVRASCRITTURA

— Per ridefinire una operazione della superclasse, una sottoclasse deve avere una propria
operazione con identica firma.
— Questa operazione è nota come overriding.

Introduzione a UML
DIPENDENZA

— Forma debole di relazione


— Sta ad indicare che una classe dipende da un’altra, in quanto quest’ultima viene utilizzata
dalla prima.
— Esiste dipendenza se una classe è un parametro o una variabile di un metodo di
un’altra classe.

Introduzione a UML
CLASSI ASTRATTE

— Una classe astratta è una classe che non può essere istanziata direttamente.
— Per poterla istanziare è necessario estenderla e realizzarne quindi una classe
concreta.

— Analogamente esistono le operazioni astratte, che definiscono la firma ma non


l’implementazione.

— Le operazioni e le classi astratte sono indicate scrivendo il nome in corsivo.

NomeDellaClasseAstra-a

attributo:tipo[0..1] = valoreIniziale

operazioneAstratta(arg list): tipo

Introduzione a UML
INTERFACCE

— Insieme dei metodi visibili dall’esterno di un oggetto.


— L’interfaccia è intesa come astrazione per la fruizione dall’esterno.
— Questo consente di separare la dichiarazione delle firme dall’implementazione reale,
favorendo, generalizzazione e polimorfismo.
— Rappresentata come una classe con lo sterotipo <<interface>>.

NomeInterfaccia
<<interface>>
+ nomeOperazione

Introduzione a UML
REALIZZAZIONE

— Una relazione di realizzazione tra una classe o un componente e una o più interfacce,
mostra che la classe realizza le operazioni offerte dall’interfaccia.
— Nella modellazione UML la relazione, nella quale un elemento realizza il
comportamento specificato dall’elemento fornitore, viene indicata da una freccia vuota
con linea tratteggiata.
— A partire da UML 2.0 è possibile visualizzare la relazione utilizzando anche i
cosiddetti “lecca-lecca”, specificando il nome dell’interfaccia implementata.

Introduzione a UML
REALIZZAZIONE

— Una relazione di realizzazione tra una classe o un componente e una o più interfacce,
mostra che la classe realizza le operazioni offerte dall’interfaccia.
— Nella modellazione UML la relazione, nella quale un elemento realizza il
comportamento specificato dall’elemento fornitore, viene indicata da una freccia vuota
con linea tratteggiata.
— A partire da UML 2.0 è possibile visualizzare la relazione utilizzando anche i
cosiddetti “lecca-lecca”, specificando il nome dell’interfaccia implementata.

Introduzione a UML
REALIZZAZIONE

Introduzione a UML
REALIZZAZIONE

Introduzione a UML
UML
DIAGRAMMA DELLE SEQUENZE

Introduzione a UML
DIAGRAMMA DELLE SEQUENZE: INTRODUZIONE

I diagrammi dei casi d'uso forniscono informazioni sulle interazioni tra gli utenti e il
nostro sistema, ma il caso d'uso in se non ci dava informazioni su cosa avvenisse
realmente all'interno del nostro sistema.

I diagrammi di sequenza servono per descrivere, in maniera dinamica, ciò che accade,
all'interno del sistema, quando si compie una determinata operazione.

ESEMPIO
L'utente effettua le ricerche necessarie prima di trovare il libro che vuole in prestito. Se il
libro è disponibile il sistema effettua il controllo sul numero dei prestiti già erogati per
l'utente. Se si è raggiunto il numero massimo di prestiti non è possibile prendere i libro. In
caso contrario il prestito viene concesso e il sistema aggiorna la lista dei libri in prestito.

Introduzione a UML
DIAGRAMMA DELLE SEQUENZE: ESEMPIO

Il nostro obiettivo è quello di modellare ciò che avviene quando un utente richiede un
prestito del libro e per far ciò spieghiamo le interazioni presenti all'interno del sistema per
poter espletare la funzione richiesta.

Introduzione a UML
DIAGRAMMA DELLE SEQUENZE: COMPONENTI

- ogni blocco rappresenta un oggetto già istanziato.


- sotto ogni blocco, è presente una linea tratteggiata che rappresenta lo scorrere del
tempo: un'azione che è rappresentata più vicina al blocco rispetto ad un altra significa
che quell'azione è stata compiuta prima.
- i rettangoli bianchi da dove partono le frecce rappresentano il punto esatto nel quale
l'oggetto entra realmente in gioco effettuando una operazione.
- le frecce che partono dai rettangoli e vanno a finire in un altro rettangolino di un
oggetto rappresentano l'operazione effettuata.
- informazioni sulla freccia: un numero progressivo che indica quando viene eseguita
l'operazione e l'operazione eseguita.
- dall'oggetto libro è presente una freccia tratteggiata in direzione dell'oggetto gestore
prestiti. Qesto tipo di freccia non rappresenta un'operazione che deve essere eseguita,
bensì rappresenta il risultato dell'esecuzione dell'operazione eseguita
precedentemente.

Introduzione a UML
DIAGRAMMA DELLE SEQUENZE: ESEMPIO COMPLETO

Introduzione a UML
DIAGRAMMA DELLE SEQUENZE: CONSIDERAZIONI

È buona norma modellare anche gli scenari in cui per esempio l'utente ha superato il
numero massimo di prestiti oppure che il libro non è disponibile.

La costruzione dei diagrammi di sequenza è abbastanza semplice e segue i seguenti step:

- Per prima cosa si posizionano gli oggetti che già sono stati istanziati al
momento della rappresentazione del diagramma.
- Si creano le chiamate da un oggetto ad un altro. Nel caso in cui la chiamata
istanzi un oggetto questo deve essere posto in quella posizione per
mantenere la correttezza di esecuzione dal punto di vista temporale.
- Dopo ogni chiamata si inserisce nel diagramma il ritorno relativo
descrivendo brevemente il risultato.
- Si itera il processo per ogni chiamata da un oggetto ad un altro.

Introduzione a UML
DIAGRAMMA DELLE SEQUENZE: ESEMPIO COMPLETO

Introduzione a UML

Potrebbero piacerti anche