Tesina di Ingegneria del Software

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