Altra Tesina in UML - Progettoatena.It
Altra Tesina in UML - Progettoatena.It
Altra Tesina in UML - Progettoatena.It
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Università degli studi di Modena e Reggio Emilia<br />
Facoltà di Ingegneria Informatica<br />
<strong>Tes<strong>in</strong>a</strong> di Ingegneria del Software<br />
(Anno accademico 2000 – 2001)<br />
Gestione Automatizzata di una Biblioteca<br />
Notazione: <strong>UML</strong><br />
Macchia Angelo (1652)
Indice<br />
I SRS:Specifiche del Problema 5<br />
II Use Case Diagram 9<br />
II.1 Utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
II.2 Biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
II.3 Diagramma degli attori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
III Class Diagram 13<br />
III.1 Utenti del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
III.2 Package Diagram del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
III.3 Testo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
III.4 Acquisto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
III.5 Ord<strong>in</strong>azione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
III.6 Prestito di un Testo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
III.7 Class Diagram riassuntivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
IV Sequence Diagram 19<br />
IV.1 Acquisto di un libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
IV.2 Prestito di un libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
V Activity Diagram 23<br />
V.1 Acquisto di un libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
V.2 Prestito di un libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
VI State Diagram 25<br />
VI.1 Stato del dipendente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Indice<br />
VIIData Flow Diagram 27<br />
VII.1 Prestito di un libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
A Breve richiami all’<strong>UML</strong> 29<br />
A.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
A.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
A.2.1 V<strong>in</strong>coli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
A.2.2 Specializzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
A.2.3 Aggregazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
A.2.4 Qualificatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
A.2.5 Associazione di classe . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
A.2.6 Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
A.3 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
A.4 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
A.5 Sate Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
A.6 Uno strumento non previsto: DFD . . . . . . . . . . . . . . . . . . . . . . 40<br />
Elenco delle figure 43<br />
Indice
Capitolo I<br />
SRS:Specifiche del Problema<br />
1 INTRODUZIONE<br />
1.1 Scopo si vuole progettare un software <strong>in</strong> grado di gestire una biblioteca automatizzata<br />
che tratta testi che possono essere libri o riviste on–l<strong>in</strong>e.<br />
1.2 Validità: il sistema si occupa pr<strong>in</strong>cipalmente di gestire un archivio sugli utenti, sui<br />
testi e sui dipendenti della biblioteca ma non si considera di mantenere la “storia”<br />
dei prestiti.<br />
1.3 Def<strong>in</strong>izioni e abbreviazioni:<br />
Tesserati: sono i soli che possono usufruire dei servizi della biblioteca.<br />
Ricercatori: sono a loro volta tesserati ma hanno la possibilità di ord<strong>in</strong>are dei testi<br />
attualmente non disponibili.<br />
Direttore che controlla l’operato dei dipendenti della biblioteca e gestisce un fondo<br />
monetario per la manutenzione della biblioteca.<br />
Responsabili degli ord<strong>in</strong>i: si occupano di contattare i fornitori per acquistare i libri<br />
ord<strong>in</strong>ati e di registrare le fatture una volta acquistato un testo.<br />
Responsabili del prestito: dipendenti che si occupano di registrare il prestito, notificare<br />
l’avvenuta restituzione di un libro e <strong>in</strong>f<strong>in</strong>e di tesserare un nuovo utente della<br />
biblioteca.<br />
1.4 Referenze: Statuto della Biblioteca<br />
2 DESCRIZIONE GENERALE<br />
2.1 Prospettive: il sistema potrà essere ampliato nelle sue funzionalità aggiungendo delle<br />
statistiche sugli argomenti maggiormente richiesti al f<strong>in</strong>e di orientare la direzione<br />
nella cura di derm<strong>in</strong>ati settori culturali.<br />
2.2 Funzioni<br />
Tesserati: il sistema permette di conoscere quali libri ha <strong>in</strong> prestito istante per<br />
istante e permette la tesserazione di nuovi utenti.
6<br />
Dipendenti: il sistema permette la registrazione dei dipendenti e di conoscere il loro<br />
stato attuale di carriera.<br />
Testi: il sistema permette la ricerca di libri e di riviste on–l<strong>in</strong>e e di sapere se sono<br />
presenti <strong>in</strong> biblioteca; <strong>in</strong> caso contrario dà la possibilità di ord<strong>in</strong>arli e <strong>in</strong> seguito di<br />
archiviare la fattura d’acquisto.<br />
Fondo: il sistema permette di conoscere la disponibilità economica della biblioteca<br />
per l’acquisto di nuovi testi.<br />
2.3 Utenti<br />
Direttore: sono richieste conoscenze sulla gestione contabile.<br />
Altri utenti: non sono richieste particolari conoscenze per l’utilizzo del software.<br />
3 SPECIFICA DEI REQUISITI<br />
3.1 Requisiti Funzionali<br />
3.1.1 Requisito #1<br />
3.1.1.1 Introduzione: <strong>in</strong>serimento di un tesserato.<br />
3.1.1.2 Input: cognome, nome, codice fiscale, recapito e categoria di<br />
studio <strong>in</strong> caso si registri un ricercatore.<br />
3.1.1.3 Process<strong>in</strong>g: il sistema memorizza i dati del tesserato ed elabora<br />
un codice identificativo della tessera.<br />
3.1.1.4 Output: stampa la nuova tessera.<br />
3.1.2 Requisito #2<br />
3.1.2.1 Introduzione: <strong>in</strong>serimento di un dipendente.<br />
3.1.2.2 Input: cognome, nome, codice fiscale, stipendio mansione.<br />
3.1.2.3 Process<strong>in</strong>g: il sistema memorizza i dati del dipendente.<br />
3.1.2.4 Output: nessuno.<br />
3.1.3 Requisito #3<br />
3.1.3.1 Introduzione: ricerca di un testo.<br />
3.1.3.2 Input: autore, titolo, argomento, casa editrice.<br />
3.1.3.3 Process<strong>in</strong>g: il sistema ricerca il testo e controlla la sua disponibilità.<br />
3.1.3.4 Output: visualizza la collocazione se è disponibile.<br />
3.1.4 Requisito #4<br />
3.1.4.1 Introduzione: Produce le copie di riviste on–l<strong>in</strong>e<br />
3.1.4.2 Input: autore, argomento, titolo.<br />
3.1.4.3 Process<strong>in</strong>g: il sistema ricerca la rivista controllando la sua disponibilità<br />
e copia l’articolo della rivista su un su un supporto magnetico<br />
esterno.<br />
Capitolo I<br />
SRS:Specifiche del Problema
7<br />
3.1.4.4 Output: nessuno.<br />
3.1.5 Requisito #5<br />
3.1.5.1 Introduzione: acquisto di riviste on–l<strong>in</strong>e<br />
3.1.5.2 Input: codice rivista<br />
3.1.5.3 Process<strong>in</strong>g: il sistema acquisisce on–l<strong>in</strong>e la rivista attraverso l’<strong>in</strong>terazione<br />
con un software (chiamato “Review”) già fornito da una ditta<br />
specializzata nelle spedizioni di riviste per via telematica.<br />
3.1.5.4 Output: visualizza la spesa.<br />
3.1.6 Requisito #6<br />
3.1.6.1 Introduzione: effettua un prestito<br />
3.1.6.2 Input: codice tesserato,collocazione libro<br />
3.1.6.3 Process<strong>in</strong>g: il sistema controlla che il tesserato sia abilitato al<br />
prestito; <strong>in</strong>fatti ogni tesserato può avere <strong>in</strong> prestito al massimo 3 libri<br />
nello stesso periodo e ogni prestito può ha durata massima 30 giorni non<br />
r<strong>in</strong>novabili (cioè se si vuole tenere ancora il libro, lo si deve consegnare e<br />
poi richiedere un nuovo prestito).<br />
3.1.6.4 Output: <strong>in</strong> caso di fattibilità del prestito si stampa la ricevuta<br />
del prestito con la data di scadenza.<br />
3.1.7 Requisito #7<br />
3.1.7.1 Introduzione: Assunzione di un nuovo dipendente<br />
3.1.7.2 Input: dati dell’utente<br />
3.1.7.3 Process<strong>in</strong>g: <strong>in</strong>serisce nuovo dipendente considerato come responsabile<br />
dei prestiti (primo livello di carriera)<br />
3.1.7.4 Output: stampa la tessera del dipendente<br />
3.1.8 Requisito #8<br />
3.1.8.1 Introduzione: Avanza di carriera [1] un dipendente<br />
3.1.8.2 Input: codice identificativo del dipendente<br />
3.1.8.3 Process<strong>in</strong>g: computa il nuovo stipendio e registra la promozione<br />
del dipendente.<br />
3.1.8.4 Output: visualizza nuovo stipendio<br />
[1]<br />
il dipendente viene assunto come responsabile dei prestiti, poi può essere promosso a responsabile<br />
degli ord<strong>in</strong>i e <strong>in</strong>f<strong>in</strong>e a direttore<br />
SRS:Specifiche del Problema<br />
Capitolo I
8<br />
Capitolo I<br />
SRS:Specifiche del Problema
Capitolo II<br />
Use Case Diagram<br />
Come prima cosa mi acc<strong>in</strong>gerò a descrivere i vari casi <strong>in</strong> cui il software viene utilizzato.<br />
Questa fase è molto utile per mettere a fuoco gli obiettivi del progetto. Visti che questi<br />
ultimi sono l’<strong>in</strong>teresse primario del committente, è opportuna la sua presenza <strong>in</strong> questa<br />
fase. A tale scopo l’<strong>UML</strong> mette a disposizione un tipo di grafico molto <strong>in</strong>tuitivo e che<br />
qu<strong>in</strong>di può essere facilmente compreso dal cliente stesso.<br />
II.1<br />
Utenti<br />
Ho <strong>in</strong>nanzitutto analizzato il sistema dal punto di vista degli utenti della biblioteca e ho<br />
ottenuto il grafico <strong>in</strong> figura II.1.<br />
Ho messo <strong>in</strong> evidenza come un ricercatore abbia tutte le possibilità d’uso previsto per un<br />
tesserato normale con <strong>in</strong> più la possibilità di ord<strong>in</strong>are un testo ma solo se esso non risulta<br />
disponibile. Proprio per rispettare tale v<strong>in</strong>colo lo use case Ord<strong>in</strong>a testo disponibile dovrà<br />
avere al suo <strong>in</strong>terno il controllo della disponibiltà (come espresso nel grafico tramite la<br />
relazione di “<strong>in</strong>clude”). Un discorso analogo è stato fatto nel considerare i casi “copia<br />
rivista on–l<strong>in</strong>e” e “richiede prestito libro”; <strong>in</strong> quest’ultimo caso, <strong>in</strong>oltre, è stato prevista<br />
una relazione di extends su “limita prestito” per <strong>in</strong>dicare che, oltre a richiedere il libro,<br />
limitare il prestito stesso.
10 Diagramma degli attori<br />
Ord<strong>in</strong>a testo<br />
<strong>in</strong>disponibile<br />
"<strong>in</strong>clude"<br />
Limita<br />
prestito<br />
"<strong>in</strong>clude"<br />
"extends"<br />
Richiede<br />
prestito<br />
libro<br />
"<strong>in</strong>clude"<br />
Controlla<br />
disponibilità<br />
Ricercatore<br />
Ricerca<br />
testo<br />
Restituisce<br />
libro<br />
Tesserato<br />
normale<br />
Copia rivista<br />
on-l<strong>in</strong>e<br />
disponibile<br />
Figura II.1: Use Case Utenti<br />
II.2<br />
Biblioteca<br />
Successivamente ho analizzato il sistema secondo il punto di vista dei dipendenti della<br />
biblioteca analizzando le possibiltà d’uso per ogni tipo di attore. Ho così ottenuto il<br />
seguente diagramma.<br />
Registra<br />
prestito<br />
Aggiorna<br />
fondo<br />
Notifica<br />
restituzione<br />
Direttore<br />
"<strong>in</strong>clude"<br />
Responsabile<br />
prestito<br />
Registra<br />
nuovo tesserato<br />
Acquista<br />
orid<strong>in</strong>e<br />
Fornitore<br />
Cataloga<br />
nuovi<br />
testi<br />
Responsabile<br />
orid<strong>in</strong>i<br />
Acquista<br />
ord<strong>in</strong>e<br />
rivista<br />
sw: "Review"<br />
Figura II.2: Use Case Biblioteca<br />
Capitolo II<br />
Use Case Diagram
Diagramma degli attori 11<br />
II.3<br />
Diagramma degli attori<br />
Una volta dist<strong>in</strong>ti tutti i possibili utenti del sistema, è utile prima di passare al class<br />
diagram classificarli attraverso il seguente diagramma (che non esiste nell’<strong>UML</strong>).<br />
Persona<br />
Fornitore<br />
il fornitore<br />
è una azienda<br />
Tesserato<br />
Impiegato<br />
Ricercatore<br />
Direttore R. ord<strong>in</strong>e R. prestito<br />
Figura II.3: diagramma degli attori del sistema<br />
Use Case Diagram<br />
Capitolo II
12 Diagramma degli attori<br />
Capitolo II<br />
Use Case Diagram
Capitolo III<br />
Class Diagram<br />
III.1<br />
Utenti del sistema<br />
Una prima modellazione delle classi è quella discende direttamente dal diagramma degli<br />
attori (a pag<strong>in</strong>a 11).<br />
Persona<br />
+nome: str<strong>in</strong>g<br />
+cognome: str<strong>in</strong>g<br />
+<strong>in</strong>idirizzo: str<strong>in</strong>g<br />
+telefono: str<strong>in</strong>g<br />
+stato: str<strong>in</strong>g<br />
+addPersona()<br />
+delPersona()<br />
ruolo<br />
{sovrapposto,<strong>in</strong>completo}<br />
Fornitore<br />
+azienda: str<strong>in</strong>g<br />
+PIVA: long<br />
+telefono: str<strong>in</strong>g<br />
+<strong>in</strong>dirizzo: str<strong>in</strong>g<br />
+addFornitore()<br />
+delFornitore()<br />
+editFornitore()<br />
Tesserato<br />
-codice_tessera: str<strong>in</strong>g<br />
+libri_prestati(): <strong>in</strong>teger<br />
+set_tessera()<br />
+get_tessera(): str<strong>in</strong>g<br />
Impiegato<br />
-CoficeFiscale: str<strong>in</strong>g<br />
+stipendio: <strong>in</strong>teger<br />
+set_cf()<br />
+get_cf(): str<strong>in</strong>g<br />
impiego<br />
{disgiunto,completo,<br />
dimaico}<br />
Ricercatore<br />
-categoria: str<strong>in</strong>g<br />
+set_categoria()<br />
+get_categoria(): str<strong>in</strong>g<br />
Direttore<br />
R_ord<strong>in</strong>e<br />
R_prestito<br />
Figura III.1: Class Diagram Utenti del Sistema<br />
In questo class diagram verranno mantenute le stesse generalizzazioni <strong>in</strong>trodotte dal<br />
diagramma degli attori ma saranno aggiunte le <strong>in</strong>formazioni sul tipo di generalizzazione.<br />
In particolare voglio mettere <strong>in</strong> evidenza che la gerarchia “ruolo” è <strong>in</strong>completa poichè<br />
una persona può essere istanziata anche se non è un tesserato o un impiegato (per esempio<br />
può essere una persona disoccupata che prima di essere assunta sta facendo un periodo<br />
di prova). Questa gerarchia risulta <strong>in</strong>oltre sovrapposta per dare maggiore flessibilità al<br />
sistema che potrà qu<strong>in</strong>di prevedere un impiegato a sua volta tesserato.
14 Testo<br />
Un altra cosa che voglio mettere <strong>in</strong> evidenza è che la gerarchia “impiego” è d<strong>in</strong>amica, per<br />
prevedere la possibiltà di carriera.<br />
III.2<br />
Package Diagram del sistema<br />
A questo punto è possibile <strong>in</strong>dividuare alcuni gruppi di classi (o pacchetti) che <strong>in</strong>teragiscono<br />
all’<strong>in</strong>terno del sistema.<br />
prestito<br />
testo<br />
acquisto<br />
utentiSistema<br />
ord<strong>in</strong>azione<br />
Figura III.2: Package Diagram del sistema<br />
Questo diagramma è stato ottenuto generalizzando un abbozzo [1] di class diagram (approccio<br />
bottom–up) con lo scopo di trattare i s<strong>in</strong>goli pacchetti (approccio top–down) rendendoli<br />
il più possibile elastici, <strong>in</strong>troducendo eventualmente anche delle classi che non<br />
servono per la risoluzione del problema ma che saranno utili per la riusabilità del lavoro<br />
svolto.<br />
III.3<br />
Testo<br />
Trattando <strong>in</strong> maniera generica la classe Testo mi sono accorto che essa poteva essere<br />
specializzata <strong>in</strong> “disponibile” o <strong>in</strong> “<strong>in</strong>disponibile”.<br />
Un’altra dist<strong>in</strong>zione su Testo all’<strong>in</strong>terno di questo sistema è tra libri e riviste.<br />
Avevo dunque la scelta di classificare <strong>in</strong> libri e riviste e poi dist<strong>in</strong>guere ognuno di queste<br />
classi <strong>in</strong> disponibili o <strong>in</strong>disponibili, oppure dist<strong>in</strong>guere subito secondo la disponibilità e<br />
poi <strong>in</strong> libri e riviste.<br />
Ho preferito optare per questa seconda possibilità poiché mi sembrava più agevole per le<br />
<strong>in</strong>terazioni con le classi degli altri pacchetti e ho così ottenuto il diagramma seguente.<br />
[1] questo grafico non viene riportato come <strong>in</strong>izialmente pensato ma presenterò una sua versione più<br />
raff<strong>in</strong>ata <strong>in</strong> figura III.7 a pag<strong>in</strong>a 17<br />
Capitolo III<br />
Class Diagram
Ord<strong>in</strong>azione 15<br />
Testo<br />
+Titolo: str<strong>in</strong>g<br />
+addTesto()<br />
+delTesto()<br />
+editTesto()<br />
disponibilità<br />
{completo,disgiunto}<br />
T_disponibile<br />
+collocazione: str<strong>in</strong>g<br />
+get_collocazione(): str<strong>in</strong>g<br />
tipologia<br />
{completo,disgiunto}<br />
T_<strong>in</strong>disponibile<br />
tipologia<br />
{completo,disgiunto}<br />
Libro<br />
+autori: str<strong>in</strong>g<br />
+editore: str<strong>in</strong>g<br />
+anno: <strong>in</strong>teger<br />
+Num_copie(): <strong>in</strong>teger<br />
Rivista<br />
+tipo: str<strong>in</strong>g<br />
+articolo: 1..max<strong>in</strong>t<br />
+autore: str<strong>in</strong>g<br />
Rivista_Indisponibile<br />
Libro_Indisponibile<br />
Figura III.3: Class Diagram dei Testi<br />
III.4<br />
Acquisto<br />
In questo diagramma viene trattato il problema dell’acquisto di un libro e della registrazione<br />
di una fattura da parte di un Responsabile degli ord<strong>in</strong>i.<br />
Fornitore<br />
(from utentiSistema)<br />
1..1<br />
1..*<br />
Ord<strong>in</strong>azione<br />
(from ord<strong>in</strong>azione)<br />
0..*<br />
PIVA<br />
Fattura<br />
+data: date<br />
+numero: <strong>in</strong>teger<br />
+importo: <strong>in</strong>teger<br />
+addFattura()<br />
+modFattura()<br />
+delFattura()<br />
0..1<br />
0..*<br />
1..1<br />
registra<br />
R_ord<strong>in</strong>e<br />
(from utentiSistema)<br />
Figura III.4: Class Diagram di Acquisto<br />
La relazione tra Fattura e Ord<strong>in</strong>azione è stata messa come composizione per evidenziare che<br />
questo legame è sì opzionale (poiché ci può essere una ord<strong>in</strong>azione ancora non soddisfatta)<br />
ma una volta <strong>in</strong>staurato l’oggetto di Ord<strong>in</strong>azione “muore” con questo legame: cioè non<br />
ha senso tenere traccia dell’ord<strong>in</strong>azione se si cancella la fattura a cui si riferisce. Questo<br />
non avviene per Fornitore oltretutto perché una ord<strong>in</strong>azione può appartenere ad una sola<br />
fattura, mentre un fornitore può comparire anche su più fatture.<br />
III.5<br />
Ord<strong>in</strong>azione<br />
Il diagramma diventa semplicemente il seguente.<br />
Class Diagram<br />
Capitolo III
16 Class Diagram riassuntivo<br />
T_<strong>in</strong>disponibili<br />
(from testo)<br />
0..*<br />
Ord<strong>in</strong>azione<br />
+data_ord<strong>in</strong>azione: date<br />
0..*<br />
Ricercatore<br />
(from utentiSistema)<br />
Figura III.5: Class Diagram Ord<strong>in</strong>azione<br />
III.6<br />
Prestito di un Testo<br />
Libro<br />
(from testo)<br />
0..* 0..*<br />
Prestito<br />
+data_prestito: date<br />
+get_scadenza(): date<br />
Tesserato<br />
(from utentiSistema)<br />
0..*<br />
0..*<br />
Rivista<br />
(from testo)<br />
copia<br />
{prestito::get_scadenza():date<br />
pre: self.data_prestito>=oggi()<br />
post: result=aggiungiGiorni(self.data_prestito,30)}<br />
Figura III.6: Class Diagram Prestito<br />
In questo grafico ho <strong>in</strong>trodotto anche una espressione OCL per determ<strong>in</strong>are la scadenza<br />
del prestito di un libro. Osservo che per quanto riguarda di riviste on–l<strong>in</strong>e si parla di copia<br />
più che di prestito e qu<strong>in</strong>di non ha senso porsi il problema della scadenza e di conseguenza<br />
non ho trovato necessario registrare la data di duplicazione della rivista on–l<strong>in</strong>e.<br />
III.7<br />
Class Diagram riassuntivo<br />
Per concludere nella pag<strong>in</strong>a successiva un class diagram mostrerà le <strong>in</strong>terazioni tra le varie<br />
classi dei diversi pacchetti<br />
Capitolo III<br />
Class Diagram
Class Diagram riassuntivo 17<br />
T_disponibile<br />
+collocazione: str<strong>in</strong>g<br />
+get_collocazione()<br />
Libro<br />
(from testo)<br />
Rivista<br />
(from testo)<br />
0..*<br />
0..*<br />
copia<br />
0..*<br />
Tesserato<br />
(from utentiSistema)<br />
0..*<br />
Prestito<br />
+data_prestito: date<br />
+get_scadenza(): date<br />
0..*<br />
modifica<br />
0..*<br />
R_prestito<br />
T_<strong>in</strong>disponibili<br />
(from testo)<br />
Fornitore<br />
(from utentiSistema)<br />
1..1<br />
0..*<br />
PIVA<br />
Fattura<br />
+data: date<br />
+numero: <strong>in</strong>teger<br />
+importo: <strong>in</strong>teger<br />
+addFattura()<br />
+modFattura()<br />
+delFattura()<br />
Testo<br />
+Titolo: str<strong>in</strong>g<br />
+addTesto()<br />
+delTesto()<br />
+editTesto()<br />
0..* 0..*<br />
Ord<strong>in</strong>azione<br />
+data_ord<strong>in</strong>azione: date<br />
1..*<br />
0..1<br />
0..* registra 1..1<br />
Ricercatore<br />
(from utentiSistema)<br />
R_ord<strong>in</strong>e<br />
(from utentiSistema)<br />
Figura III.7: Class Diagram Sistema<br />
Class Diagram<br />
Capitolo III
18 Class Diagram riassuntivo<br />
Capitolo III<br />
Class Diagram
Capitolo IV<br />
Sequence Diagram<br />
In questo capitolo, come nei successivi non descriverò tutti i possibili casi d’uso tramite i<br />
sequence diagram ma cercherò di analizzare quei casi che ho ritenuto più significativi per<br />
evidenziare le potenzialità dell’<strong>UML</strong>.<br />
IV.1<br />
Acquisto di un libro<br />
In questa azione <strong>in</strong>tervengono le figure di Responsabile degli ord<strong>in</strong>i e dei Fornitori secondo<br />
le seguenti modalità<br />
• Il responsabile degli ord<strong>in</strong>i considera una ord<strong>in</strong>azione ancora <strong>in</strong>soluta.<br />
• Attraverso un opportuno metodo della classe Ord<strong>in</strong>azione si chiederà al fornitore il<br />
preventivo dell’ord<strong>in</strong>azione stessa.<br />
• Si aggiorna il fondo monetario e si registra la fattura<br />
Schematizzando queste <strong>in</strong>terazioni ho ottenuto il diagramma <strong>in</strong> figura IV.1.<br />
Dall’analisi di questo nuovo diagramma si ev<strong>in</strong>ce la necessità di aggiungere i seguenti<br />
metodi:<br />
1. +preventivo() per la classe Ord<strong>in</strong>azione<br />
2. +calcola preventivo() per la classe Fornitore
20 Prestito di un libro<br />
una ord<strong>in</strong>azione<br />
R_ord<strong>in</strong>i<br />
prezzo:=preventivo()<br />
calcola_preventivo()<br />
Fornitore<br />
add_spesa(prezzo)<br />
fondo<br />
new<br />
fattura<br />
kill<br />
Figura IV.1: Sequence Diagram sull’acquisto di un libro<br />
Inf<strong>in</strong>e osservo che è necessario aggiungere la seguente classe:<br />
Fondo<br />
-Totale: <strong>in</strong>teger = 0<br />
+add_spesa(prezzo:<strong>in</strong>teger)<br />
+get_totale(): <strong>in</strong>teger<br />
+add_fondo(fondo:<strong>in</strong>teger): <strong>in</strong>teger<br />
IV.2<br />
Prestito di un libro<br />
Nel chiedere un testo, il tesserato farà <strong>in</strong>direttamente eseguire un particolare metodo della<br />
classe Testo che controllerà se esso è ancora disponibile (ossia se è <strong>in</strong> biblioteca). In caso<br />
affermativo verrà istanziata un nuovo oggetto della classe T disponibile che il tesserato<br />
provvederà a <strong>in</strong>viare al responsabile dei prestiti (tramite un opportuno metodo). Sarà<br />
compito di quest’ultimo controllare che il tesserato sia effettivamente abilitato ad ottenere<br />
il prestito (cioè deve avere un numero massimo di libri <strong>in</strong> prestito <strong>in</strong> quello stesso periodo).<br />
Dallo studio di questo caso ho ottenuto il diagramma mostrato nella pag<strong>in</strong>e seguente.<br />
Capitolo IV<br />
Sequence Diagram
Prestito di un libro 21<br />
Tesserato<br />
new<br />
Testo : testo chiesto<br />
ok:=chk_disponibile()<br />
[disponibile] new<br />
T_disponibile : richiesto<br />
return<br />
[ok] chiedi_testo(richiesto)<br />
R_prestito<br />
ok2:=controlla_limite()<br />
[ok2] new<br />
nuovo prestito<br />
stampa_ricevuta()<br />
Figura IV.2: Sequence Diagram del prestito di un libro<br />
Sequence Diagram<br />
Capitolo IV
22 Prestito di un libro<br />
Dall’analisi di questo nuovo diagramma si ev<strong>in</strong>ce la necessità di aggiungere i seguenti<br />
metodi:<br />
1. +chk disponibile() per la classe Testo<br />
2. -disponibile() per la classe Testo<br />
3. +chiedi testo(richiesto:T disponibile) per la classe R prestito<br />
4. -controlla limite() per la classe R prestito<br />
5. -stampa ricevuta() per la classe Prestito<br />
Capitolo IV<br />
Sequence Diagram
Capitolo V<br />
Activity Diagram<br />
In questo capitolo andrò ad analizzare una serie di stati d’azione tramite lo strumento<br />
<strong>UML</strong> dell’activity diagram. Infatti per attività si <strong>in</strong>tende un processo reale che avviene<br />
nel mondo reale (come chiedere un preventivo) o l’esecuzione di una rout<strong>in</strong>e del software<br />
(come un metodo di una classe).<br />
In particolare si è esam<strong>in</strong>ato il caso l’acquisto di un libro e il prestito di un libro a favore<br />
di un tesserato.<br />
V.1 Acquisto di un libro<br />
Analizzando il caso dell’acquisto di un libro ho ottenuto il seguente diagramma:<br />
Considera<br />
una ord<strong>in</strong>azione<br />
Chiedi preventivo<br />
[else]<br />
[prezzo
24 Prestito di un libro<br />
V.2 Prestito di un libro<br />
Nel caso di un prestito di un libro (analizzato per certi aspetti nel capitolo del Sequence<br />
Diagram) il diagramma seguente:<br />
Controlla disponibilità<br />
[else]<br />
[disponibile]<br />
Controlla limite prestito<br />
[fuori_limite]<br />
[else]<br />
Aggiorna<br />
limite<br />
Registra<br />
prestito<br />
Aggiorna<br />
disponibilità<br />
Stampa<br />
ricevuta<br />
Figura V.2: Activity Diagram Acquisto di un libro<br />
Capitolo V<br />
Activity Diagram
Capitolo VI<br />
State Diagram<br />
VI.1<br />
Stato del dipendente<br />
In questo paragrafo ho analizzato lo stato di carriera di un dipendente osservando che si<br />
vuole avere la possibilità di registrare anche i possibili candidati o persone che sono <strong>in</strong> un<br />
periodo di prova e che non sono attualmente assunti. Queste categorie di persone vengono<br />
considerate dal sistema come disoccupati.<br />
Quando si viene assunti def<strong>in</strong>itivamente si diventa Responsabile prestito poi, <strong>in</strong> seguito ad<br />
una promozione, Responsabile ord<strong>in</strong>i e <strong>in</strong>f<strong>in</strong>e Direttore.<br />
Dalla mia analisi risulta il seguente diagramma:<br />
licenziamento<br />
Disoccupato<br />
assunzione<br />
R_prestito<br />
do/timbra cartell<strong>in</strong>o<br />
[età>65]<br />
licenziamento<br />
promozione<br />
R_ord<strong>in</strong>e<br />
entry/aumenta stipendio<br />
do/timbra cartell<strong>in</strong>o<br />
[età>65]<br />
Pensionato<br />
entry/ricevi liquidazione<br />
licenziamento<br />
promozione<br />
Direttore<br />
[età>65]<br />
entry/aumenta stipendio<br />
Figura VI.1: State Diagram sullo stato del dipendente
26 Stato del dipendente<br />
Capitolo VI<br />
State Diagram
Capitolo VII<br />
Data Flow Diagram<br />
Anche se questo strumento non esiste nel <strong>UML</strong>, risulta comunque utile a evidenziare il<br />
flusso di dati tra i vari processi (che possono ad esempio essere dei metodi di classe).<br />
VII.1<br />
Prestito di un libro<br />
Come molti strumenti anche il DFD può avere vari livelli di dettaglio, qu<strong>in</strong>di <strong>in</strong> questo<br />
caso analizzerò il prestito di un libro riservandomi di dettagliare <strong>in</strong> seguito il processo<br />
“Gestore Prestito”.<br />
chiede_testo<br />
Tesserato<br />
Getsore prestito<br />
R_prestito<br />
collocazione<br />
ricerca<br />
visualizza_esito<br />
cerca_testo<br />
Db_Testi<br />
Figura VII.1: Data Flow Diagram di un prestito<br />
Dettagliando il processo “Gestore Prestito” ho ottenuto il diagramma nella figura seguente.
28 Prestito di un libro<br />
collocazione<br />
Tesserato<br />
cerca_testo<br />
Db_Testi<br />
visualizza_esito<br />
chiede_testo<br />
visualizza_esito<br />
chk_disponibile<br />
chiede_testo<br />
disponibile<br />
chiedi_testo<br />
ricerca<br />
Db_Testi_<strong>in</strong>_bibleoteca<br />
controlla<br />
limite<br />
Gestore<br />
tesserato<br />
aggiorna<br />
limite<br />
R_prestito<br />
visualizza<br />
richiesta<br />
aggiorna<br />
disponibilità<br />
Db_Stato_tesserato<br />
Gestore<br />
disponibilità<br />
Db_Testi_<strong>in</strong>_bibleoteca<br />
Figura VII.2: Data Flow Diagram dettagliato<br />
Capitolo VII<br />
Data Flow Diagram
Appendice A<br />
Breve richiami all’<strong>UML</strong><br />
L’<strong>UML</strong> è un modello semi <strong>in</strong>formale, orientato ad oggetti ed utile specialmente per sistemi<br />
real time.<br />
A.1 Use Cases<br />
La use case è il modello rudimentale utile nella fase <strong>in</strong>iziale della progettazione. Più<br />
precisamente è un complesso di funzioni elementari che risponde <strong>in</strong> maniera completa alle<br />
esigenze dell’utente. Per capire meglio il concetto faccio un esempio:<br />
gestione di un contocorrente:<br />
1 o scenario [1] : un cliente chiede <strong>in</strong>formazioni sul contocorrente per cambiare un assegno<br />
2 o scenario: l’operatore può registrare l’operazione<br />
3 o scenario: l’operatore può resp<strong>in</strong>gere l’operazione<br />
In questo caso la use case è “cambio assegno” e rappresenta le operazioni appunto necessarie<br />
per cambiare un assegno. Il grafico sul quale viene rappresentato è detto UCD (Use<br />
Case Diagram) dove viene disegnato l’attore a forma di om<strong>in</strong>o e la use case racchiusa <strong>in</strong><br />
un ovale. In questo esempio diventa l’UCD semplicemente:<br />
cambio assegno<br />
Banchiere<br />
[1] si dice scenario una sessione di lavoro di un software che ha un <strong>in</strong>izio e una f<strong>in</strong>e
30 Use Cases<br />
Questo è un esempio molto banale; tuttavia potremmo avere un UCD più complesso<br />
dove ci sono più relazioni tra una use case ed un’altra come v<strong>in</strong>coli (disegnati frecce<br />
tratteggiate) o specializzazioni (<strong>in</strong>dicate con una freccia cont<strong>in</strong>ua). Per esempio potremmo<br />
avere qualcosa di simile:<br />
cambio assegno<br />
"<strong>in</strong>clude"<br />
stato del c/c<br />
Cassere<br />
"<strong>in</strong>clude"<br />
Gestione prestito<br />
Valorizzazione<br />
Presto<br />
"<strong>in</strong>clude"<br />
Gestione prestito agricolo<br />
Respons.<br />
prestito<br />
Direttore<br />
oltre alle relazioni di <strong>in</strong>clude possiamo avere anche relazioni di extends come nell’esempio<br />
seguente:<br />
cliente regolare<br />
"extends"<br />
(pagamento,<br />
spedizione)<br />
Acq. Prodotto<br />
extension po<strong>in</strong>ts: pagamento<br />
spedizione, garanzie<br />
"extends"<br />
(garanzie)<br />
Rapporti banca<br />
tuttavia questo tipo di relazione si usa solo qualche volta, giusto per evidenziare aspetti<br />
rispetto al concetto generale; nell’esempio i metodi che meritano di essere ridef<strong>in</strong>iti sono<br />
i 3 dell’extension po<strong>in</strong>ts.<br />
Anche se <strong>UML</strong> non lo prevede, risulta utile fare un grafico dove si dist<strong>in</strong>guono le categorie<br />
di attori, come ad esempio:<br />
Appendice A<br />
Breve richiami all’<strong>UML</strong>
Class Diagram 31<br />
supporto tecnico<br />
Politig<br />
(fa richieste di<br />
query standard)<br />
Attore<br />
Interno<br />
Tecnico<br />
utente<br />
Esterno<br />
Inf<strong>in</strong>e bisogna osservare che nell’UCD non sono solo gli attori che possono <strong>in</strong>teragire con le<br />
use cases, ma anche altri software (racchiusi <strong>in</strong> un rettangolo) come si ev<strong>in</strong>ce dal seguente<br />
esempio:<br />
Use Case 1<br />
Use Case 2<br />
Attore<br />
"actor" sw XK41<br />
Use Case 3<br />
A.2 Class Diagram<br />
È un grafico di tipo statico per la modellazione delle classi [2] . Ogni classe è rappresentata<br />
<strong>in</strong>ternamente <strong>in</strong> una scatola con i suoi attributi (dati) e i suoi metodi, come da esempio:<br />
[2] una classe è un <strong>in</strong>sieme di oggetti che hanno una struttura, un comportamento e delle relazioni simili<br />
Breve richiami all’<strong>UML</strong><br />
Appendice A
32 Class Diagram<br />
Conto corrente<br />
identificatore:0..100<br />
fliale:(A,B,C)<br />
fido:0..1000<br />
apri<br />
stampa saldo<br />
prelievo<br />
deposito<br />
Più precisamente <strong>in</strong> testa a questa scatola ci sta:<br />
1. Uno stereotipo racchiuso tra virgolette (”) e/o la sua icona<br />
2. Il nome della classe <strong>in</strong> grassetto e centrato<br />
3. Una lista di proprietà della classe separate da virgole e racchiuse tra parentesi graffe<br />
(es. {abstract}).<br />
Possiamo avere delle associazioni tra classi <strong>in</strong>dicate con una l<strong>in</strong>ea se è bidirezionale, con<br />
una freccia se è unidirezionale. Sopra questa l<strong>in</strong>ea bisogna specificare la molteplicità della<br />
relazione secondo la seguente notazione:<br />
• lower–bound..upper–bound<br />
• il carattere asterisco (*) come upper–bound sta ad <strong>in</strong>dicare +∞<br />
ad esempio la seguente molteplicità:<br />
Conto corrente<br />
+identificatore: 0..100<br />
+filiale: (A,B,C)<br />
+fido: 0..1000<br />
+apri()<br />
+stampa saldo()<br />
+prelievo()<br />
+deposito()<br />
Cliente<br />
0..* 1..1 +Nome:<br />
+Cognome:<br />
-CF:<br />
+set CF()<br />
+get CF()<br />
sta ad <strong>in</strong>dicare che un contocorrente appartenere ad uno e un solo cliente mentre un cliente<br />
può avere a 0 a +∞ conto correnti.<br />
Davanti ai metodi o agli attributi può esserci uno dei tag seguenti:<br />
+ metodo/attributo pubblico<br />
Appendice A<br />
Breve richiami all’<strong>UML</strong>
Class Diagram 33<br />
# metodo/attributo protetto [3]<br />
– metodo/attributo privato [4]<br />
se non c’è nessun tag allora si tratta di una implementazione<br />
Osservazione: non abbiamo bisogno, come nell’E/R, di cercare la chiave primaria perché<br />
<strong>in</strong> realtà ad ogni oggetto è associato un object id (<strong>in</strong>terno al sistema e <strong>in</strong>visibile) e lo stato<br />
dei suoi attributi. Paritamente non abbiamo problemi di normalizzazione.<br />
A.2.1<br />
V<strong>in</strong>coli<br />
Possiamo avere la necessità di esprimere dei vicoli sugli attributi di una classe, allora<br />
convenzionalmente racchiudiamo questi v<strong>in</strong>coli tra parentesi graffe fuori dalla classe e<br />
colleghiamo il v<strong>in</strong>colo al suo attributo tramite una l<strong>in</strong>ea tratteggiata. Ad esempio:<br />
Persona<br />
+Nome: str<strong>in</strong>g<br />
+Cognome: str<strong>in</strong>g<br />
+Nascita: date<br />
+Età: 0..200<br />
+Nazionalità: str<strong>in</strong>g<br />
+Sesso: (M,F)<br />
+Età Media()<br />
{Età=Differenza(Nascita-Oggi)}<br />
A.2.2<br />
Specializzazione<br />
Le classi possono essere specializzate <strong>in</strong> sottoclassi attraverso una freccia (con punta a<br />
triangolo vuoto) e una etichetta vic<strong>in</strong>o a essa che comprende il nome della partizione della<br />
superclasse che si sta specializzando e uno o più v<strong>in</strong>coli separati da una virgola, racchiusi<br />
<strong>in</strong> parentesi graffe. I v<strong>in</strong>coli più noti sono:<br />
• sovrapposto: se lo stato della partizione può discendere da più sottoclassi<br />
• disgiunto: se lo stato della partizione discende da una sola sottoclasse<br />
• completo: se le sottoclassi rappresentate coprono tutti i casi e non mi aspetto di<br />
cadere al di fuori di essi<br />
• <strong>in</strong>completo: se le sottoclassi rappresentate non coprono tutti i casi<br />
[3] si ricorda che un metodo è protetto quando è visibile solo dalla classe stessa e dalle classi appartenenti<br />
allo stesso package<br />
[4] un metodo è privato se è visibile solo all’<strong>in</strong>terno della sua classe<br />
Breve richiami all’<strong>UML</strong><br />
Appendice A
34 Class Diagram<br />
Possono essere aggiunti anche altri v<strong>in</strong>coli come il d<strong>in</strong>amico dell’esempio seguente che sta<br />
ad <strong>in</strong>dicare che lo stato di appartenenza della partizione ad una sottoclasse può variare<br />
d<strong>in</strong>amicamente nel tempo:<br />
Persona<br />
+Nome: str<strong>in</strong>g<br />
+Cognome: str<strong>in</strong>g<br />
+Sesso:<br />
+Professione:<br />
Professione<br />
{d<strong>in</strong>amico,<strong>in</strong>completo}<br />
Disoccupato<br />
Studente<br />
Sesso<br />
{disgiunto,completo}<br />
Pensionato<br />
Maschio<br />
Femm<strong>in</strong>a<br />
A.2.3<br />
Aggregazione<br />
È una relazione del tipo parte di. L’Esempio classico è quella del motore e dell’auto:<br />
un motore è parte dell’auto. L’aggregazione è rappresentata attraverso un rombo vuoto<br />
attaccato ad una freccia che lo collega al componente. Nell’esempio dell’auto e del motore:<br />
Auto<br />
Motore<br />
+Matricola: str<strong>in</strong>g<br />
Anche sulle aggregazioni si possono <strong>in</strong>serire v<strong>in</strong>coli di card<strong>in</strong>alità. Un caso particolare<br />
dell’aggregazione è la composizione: cioè quando il componente può fare parte di un<br />
solo oggetto composto e una volta creato il v<strong>in</strong>colo, il componente muore con il legame.<br />
Un esempio è quella della f<strong>in</strong>estra grafica che ha come componenti 2 scroll bar, un titolo e<br />
un corpo. È chiaro che si tratta di una composizione perché le scroll bars (come anche il<br />
titolo e il corpo) non possono fare parte di più di una f<strong>in</strong>estra grafica e, quando muore la<br />
f<strong>in</strong>estra si deallocano anche gli oggetti che la compongono. Al dire il vero anche l’esempio<br />
dell’auto e del motore sembrerebbe una composizione. Invece un esempio più chiaro di<br />
aggregazione semplice è il giocatore nella squadra se ammettiamo che un giocatore può<br />
giocare <strong>in</strong> più squadre.<br />
La composizione si annerendo il rombo.<br />
Appendice A<br />
Breve richiami all’<strong>UML</strong>
Class Diagram 35<br />
A.2.4<br />
Qualificatori<br />
Il Qualificatore è un attributo (o una tupla di attributi) il cui valore mi identifica una<br />
parte degli oggetti della classe che sono proprio quelli associati all’oggetto [5] dall’altra<br />
parte della associazione.<br />
Consideriamo ad esempio:<br />
Banca<br />
Numero_conto<br />
*<br />
0..1<br />
Persona<br />
ho che un numero di conto mi identifica un <strong>in</strong>sieme di oggetti della classe Banca che<br />
possono essere associati (0..1) ad un oggetto della classe Persona.<br />
Come visto <strong>in</strong> questo esempio il qualificatore è racchiuso <strong>in</strong> un quadrato sotto (o a s<strong>in</strong>istra<br />
oppure a destra) la scatola che contiene la classe.<br />
A.2.5<br />
Associazione di classe<br />
È una associazione che ha le proprietà di una classe (come quella di essere associata<br />
ad un’altra classe). Graficamente si disegna con una l<strong>in</strong>ea cont<strong>in</strong>ua tra due classi e dal<br />
centro di questa l<strong>in</strong>ea si fa partire una l<strong>in</strong>ea ortogonale tratteggiata che si collega alla<br />
classe descrittrice dell’associazione. Nel seguente esempio Proprietà è una associazione di<br />
classe:<br />
Persona<br />
+Nome: Str<strong>in</strong>g<br />
+Cognome: Str<strong>in</strong>g<br />
+Nascita: Date<br />
+<strong>in</strong>it()<br />
1..n<br />
0..n<br />
Casa<br />
+Via: Str<strong>in</strong>g<br />
+Mq: Integer<br />
+Costruita: Date<br />
+valore()<br />
Proprietà<br />
+Data_<strong>in</strong>izio: Date<br />
+Data_f<strong>in</strong>e: Date<br />
Notaio<br />
o 1<br />
[5] se parliamo di oggetto al s<strong>in</strong>golare vuol dire che la card<strong>in</strong>alità da questa parte dell’associazione è 0..1<br />
Breve richiami all’<strong>UML</strong><br />
Appendice A
36 Sequence Diagram<br />
A.2.6<br />
Object Diagram<br />
È un caso particolare del diagramma delle classi e viene usato per esprimere qualche<br />
esempio. Si disegna come una classe solo che il nome viene sottol<strong>in</strong>eato e non vengono<br />
mostrati i metodi, ma solo gli attributi nella forma:<br />
Nome=Valore<br />
A.3 Sequence Diagram<br />
Si parla di <strong>in</strong>teraction diagram come un diagramma dove si mostrano le <strong>in</strong>terazioni<br />
tra gli oggetti. Tale diagramma ha due forme che evidenziano aspetti diversi: sequence<br />
diagram (o diagramma delle sequenze) e collaboration diagram.<br />
Nel sequence diagram si mostrano le <strong>in</strong>terazioni tra oggetti ord<strong>in</strong>ate rispetto al tempo.<br />
Più precisamente gli oggetti che partecipano all’<strong>in</strong>terazione sono disegnati su delle “l<strong>in</strong>ee<br />
di vita” e i messaggi che si scambiano sono <strong>in</strong>dicati da delle frecce.<br />
La differenza tra sequence diagram e collaboration diagram è che il primo mostra <strong>in</strong><br />
esplicito la sequenza di messaggi ed è dunque meglio per le specifiche real–time o per<br />
scenari complessi. Invece il secondo mostra la parentela tra gli oggetti ed è qu<strong>in</strong>di più<br />
<strong>in</strong>dicato per studiare tutti gli effetti di un dato oggetto <strong>in</strong> un progetto procedurale.<br />
Qui si parlerà del solo diagramma delle sequenze.<br />
Questo diagramma ha due dimensioni: una verticale dove si rappresenta il tempo (attraverso<br />
la l<strong>in</strong>ea di vita) ed una orizzontale dove vengono rappresentati gli oggetti. Normalmente<br />
il tempo procede dall’alto verso il basso. Vic<strong>in</strong>o alle transazioni possono essere<br />
<strong>in</strong>serite delle etichette per vari scopi come ad esempio quello di marcare il tempo o quello di<br />
spiegare una <strong>in</strong>terazione. Anche sui messaggi vengono <strong>in</strong>serite delle etichette descrittive.<br />
L<strong>in</strong>ea di vita<br />
Si rappresenta con una l<strong>in</strong>ea tratteggiata: nel suo estremo superiore si disegna l’oggetto e il<br />
suo estremo <strong>in</strong>feriore può rappresentare eventualmente la sua distruzione; <strong>in</strong> quest’ultimo<br />
caso, l’estremo <strong>in</strong>feriore verrà marcato con una “X”. Il tratto di tempo <strong>in</strong> cui l’oggetto<br />
riceve e/o trasmette messaggi, viene <strong>in</strong>dicato sostituendo al tratteggio un rettangolo il cui<br />
asse co<strong>in</strong>cide con la l<strong>in</strong>ea di vita.<br />
Appendice A<br />
Breve richiami all’<strong>UML</strong>
Activity Diagram 37<br />
Per fare un esempio si veda la figura qua accanto.<br />
Messaggi<br />
I messaggi vengono disegnati con una freccia<br />
la quale viene etichettata con il nome dell’operazione<br />
o del segnale a cui si riferisce.<br />
Possiamo <strong>in</strong>f<strong>in</strong>e avere le seguenti categorie di<br />
messaggi:<br />
<strong>in</strong>izia()<br />
Conto<br />
estrai()<br />
promozione()<br />
1) As<strong>in</strong>croni: disegnati con mezza freccia<br />
2) Chiamate: disegnate con una freccia normale<br />
3) Restituzione: disegnato con una freccia Chuiso()<br />
tratteggiata.<br />
Nella figura che seguirà ci sarà un esempio più significativo: si tratta del diagramma di<br />
più 4 oggetti che rappresentano la gestione di un magazz<strong>in</strong>o; se sul messaggio appare un<br />
qualcosa del tipo:<br />
[cond] message()<br />
−−−−−−−−−−−−−−−−→<br />
vuol dire che se è verificata la condizione cond allora sarà spedito il messaggio message().<br />
I term<strong>in</strong>i new e return sono delle parole chiave che significano rispettivamente la creazione<br />
di un nuovo oggetto e il ritorno di un messaggio.<br />
order entry order order l<strong>in</strong>e<br />
product<br />
prepara()<br />
prepara()<br />
ok:=check()<br />
[ok] cala()<br />
poco:=scarta()<br />
[poco] new<br />
ord<strong>in</strong>azione<br />
return<br />
[ok] new<br />
[NOT ok] new<br />
spedizione<br />
messaggio<br />
Breve richiami all’<strong>UML</strong><br />
Appendice A
38 Activity Diagram<br />
A.4 Activity Diagram<br />
È un diagramma che rappresenta una serie di stati di attività. Per attività si <strong>in</strong>tende<br />
sia un processo reale che avviene mondo (come ad esempio scrivere una lettera) e sia<br />
l’esecuzione di una rout<strong>in</strong>e di un software (come un metodo di una classe).<br />
Si parte (punto di start) dal flusso <strong>in</strong>iziale che può eventualmente diramarsi (fork), si<br />
compiono le azioni <strong>in</strong>dicate negli stati e <strong>in</strong>f<strong>in</strong>e si term<strong>in</strong>a (punto di stop). Inf<strong>in</strong>e ogni flusso<br />
può diramarsi, cioè seguire una strada al posto di un’altra a seconda che una determ<strong>in</strong>ata<br />
condizione sia vera o meno. Per disegnare questo grafico si fa uso dei seguenti simboli:<br />
azione<br />
Per chiarire il tutto si osservi il seguente esempio:<br />
Appendice A<br />
Breve richiami all’<strong>UML</strong>
Sate Diagram 39<br />
Ricavo orid<strong>in</strong>e<br />
soddisfo<br />
ord<strong>in</strong>e<br />
<strong>in</strong>vio<br />
fattura<br />
[urgente]<br />
Spedizione<br />
regolare<br />
Spedizione<br />
espressa<br />
Pagamento<br />
Chiudo ord<strong>in</strong>e<br />
Concludo dicendo che il diagramma delle attività è facoltativo.<br />
A.5 Sate Diagram<br />
Questo grafico si generalizza quello visto <strong>in</strong> precedenza, poiché si rappresentano i possibili<br />
stati per i quali un oggetto o una <strong>in</strong>terazione può passare.<br />
Ad esempio un oggetto appartenente alla classe Persona può passare per i seguenti stati<br />
fondamentali:<br />
Breve richiami all’<strong>UML</strong><br />
Appendice A
40 Uno strumento non previsto: DFD<br />
matrimonio<br />
celibe<br />
[età>=18] matrimonio<br />
sposato<br />
sentenza<br />
separato<br />
[tempo>=3m]<br />
divorziato<br />
do/pago_alimenti<br />
matrimonio<br />
morte coniuge<br />
vedovo<br />
Come si può notare uno stato può avere diversi livelli di dettaglio. Quello più alto è:<br />
Nome stato<br />
nome evento / azione 1<br />
nome evento / azione 2<br />
.<br />
nome evento / azione n<br />
Gli eventi canonici sono:<br />
• entry: esegui azione quando entry nello stato<br />
• do: esegui azione nel mentre che sei nello stato<br />
• exit: esegui azione prima di uscire dallo stato<br />
Inf<strong>in</strong>e è doveroso precisare che tutte le azioni sono atomiche.<br />
A.6 Uno strumento non previsto: DFD<br />
Il Data Flow Diagram lo prevede OMT ma non <strong>UML</strong>. Tuttavia lo vogliamo trattare<br />
perché è molto utile per scomporre funzionalmente un processo [6] che qu<strong>in</strong>di diventa,<br />
con questo strumento, raff<strong>in</strong>abile per stadi. Per esempio:<br />
[6] per processo si <strong>in</strong>tende una attività che assume dei dati <strong>in</strong> <strong>in</strong>gresso e produca outputs <strong>in</strong> uscita<br />
Appendice A<br />
Breve richiami all’<strong>UML</strong>
Uno strumento non previsto: DFD 41<br />
I1<br />
I2<br />
I3<br />
Processo<br />
O1<br />
O2<br />
I1<br />
I2<br />
P1<br />
d12<br />
P2<br />
d23<br />
d24<br />
P3<br />
O1<br />
O2<br />
I3<br />
P4<br />
Oltre al processo il DFD ha le seguenti primitive:<br />
• Agente esterno (es. l’utente o un programma):<br />
Nome<br />
• Deposito dati:<br />
Nome<br />
Si deve tenere presente che gli agenti esterni e i depositi dati non possono scambiarsi<br />
messaggi tra loro, ma solo con processi. Per esempio:<br />
Utente<br />
richiesta se<br />
Dati B<br />
P1<br />
d12<br />
P2<br />
Utente<br />
Dati A<br />
Dati A<br />
Il DFD è precedente all’approccio ad oggetti ma è utile perché i processi diventeranno i<br />
metodi nel diagramma delle classi.<br />
Breve richiami all’<strong>UML</strong><br />
Appendice A
42 Uno strumento non previsto: DFD<br />
Appendice A<br />
Breve richiami all’<strong>UML</strong>
Elenco delle figure<br />
II.1 Use Case Utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
II.2 Use Case Biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
II.3 diagramma degli attori del sistema . . . . . . . . . . . . . . . . . . . . . . 11<br />
III.1 Class Diagram Utenti del Sistema . . . . . . . . . . . . . . . . . . . . . . . 13<br />
III.2 Package Diagram del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
III.3 Class Diagram dei Testi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
III.4 Class Diagram di Acquisto . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
III.5 Class Diagram Ord<strong>in</strong>azione . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
III.6 Class Diagram Prestito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
III.7 Class Diagram Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
IV.1 Sequence Diagram sull’acquisto di un libro . . . . . . . . . . . . . . . . . . 20<br />
IV.2 Sequence Diagram del prestito di un libro . . . . . . . . . . . . . . . . . . 21<br />
V.1 Activity Diagram Acquisto di un libro . . . . . . . . . . . . . . . . . . . . 23<br />
V.2 Activity Diagram Acquisto di un libro . . . . . . . . . . . . . . . . . . . . 24<br />
VI.1 State Diagram sullo stato del dipendente . . . . . . . . . . . . . . . . . . . 25<br />
VII.1Data Flow Diagram di un prestito . . . . . . . . . . . . . . . . . . . . . . . 27<br />
VII.2Data Flow Diagram dettagliato . . . . . . . . . . . . . . . . . . . . . . . . 28
44 Elenco delle figure<br />
Elenco delle figure
Bibliografia<br />
§ M. Flower, K. Scott:<br />
“<strong>UML</strong> distilled”<br />
1997 – Addison Wesley<br />
§ Rational Software Corporation:<br />
“<strong>UML</strong> Notation Guide”<br />
1997 – http://www.rational.com/uml