tesina di ingegneria del software - progetto atena del software/tesina... · 2003. 2. 7. ·...

Universita degli studi di Modena e Reggio EmiliaFacolta di Ingegneria Informatica

Tesina di Ingegneria del Software(Anno accademico 2000 – 2001)

Gestione Automatizzata di una BibliotecaNotazione: 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

IIIClass 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

VIIData 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 automatiz-zata che tratta testi che possono essere libri o riviste on–line.

1.2 Validita: il sistema si occupa principalmente di gestire un archivio sugli utenti, suitesti 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 possibilita di ordinare dei testiattualmente non disponibili.

Direttore che controlla l’operato dei dipendenti della biblioteca e gestisce un fondomonetario per la manutenzione della biblioteca.

Responsabili degli ordini: si occupano di contattare i fornitori per acquistare i libriordinati e di registrare le fatture una volta acquistato un testo.

Responsabili del prestito: dipendenti che si occupano di registrare il prestito, noti-ficare l’avvenuta restituzione di un libro e infine di tesserare un nuovo utente dellabiblioteca.

1.4 Referenze: Statuto della Biblioteca

2 DESCRIZIONE GENERALE

2.1 Prospettive: il sistema potra essere ampliato nelle sue funzionalita aggiungendo del-le statistiche sugli argomenti maggiormente richiesti al fine di orientare la direzionenella cura di derminati settori culturali.

2.2 Funzioni

Tesserati: il sistema permette di conoscere quali libri ha in prestito istante peristante e permette la tesserazione di nuovi utenti.

6

Dipendenti: il sistema permette la registrazione dei dipendenti e di conoscere il lorostato attuale di carriera.

Testi: il sistema permette la ricerca di libri e di riviste on–line e di sapere se sonopresenti in biblioteca; in caso contrario da la possibilita di ordinarli e in seguito diarchiviare la fattura d’acquisto.

Fondo: il sistema permette di conoscere la disponibilita economica della bibliotecaper 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 distudio in caso si registri un ricercatore.

3.1.1.3 Processing: il sistema memorizza i dati del tesserato ed elaboraun 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 disponi-bilita.

3.1.3.4 Output: visualizza la collocazione se e 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 dispo-nibilita e copia l’articolo della rivista su un su un supporto magneticoesterno.

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’in-terazione con un software (chiamato “Review”) gia fornito da una dittaspecializzata 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 alprestito; infatti ogni tesserato puo avere in prestito al massimo 3 librinello stesso periodo e ogni prestito puo ha durata massima 30 giorni nonrinnovabili (cioe se si vuole tenere ancora il libro, lo si deve consegnare epoi richiedere un nuovo prestito).

3.1.6.4 Output: in caso di fattibilita del prestito si stampa la ricevutadel 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 respon-sabile 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 promozionedel dipendente.

3.1.8.4 Output: visualizza nuovo stipendio

[1] il dipendente viene assunto come responsabile dei prestiti, poi puo essere promosso a responsabiledegli 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 accingero a descrivere i vari casi in cui il software viene utilizzato.Questa fase e molto utile per mettere a fuoco gli obiettivi del progetto. Visti che questiultimi sono l’interesse primario del committente, e opportuna la sua presenza in questafase. A tale scopo l’UML mette a disposizione un tipo di grafico molto intuitivo e chequindi puo essere facilmente compreso dal cliente stesso.

II.1 Utenti

Ho innanzitutto analizzato il sistema dal punto di vista degli utenti della biblioteca e hoottenuto il grafico in figura II.1.

Ho messo in evidenza come un ricercatore abbia tutte le possibilita d’uso previsto per untesserato normale con in piu la possibilita di ordinare un testo ma solo se esso non risultadisponibile. Proprio per rispettare tale vincolo lo use case Ordina testo disponibile dovraavere al suo interno il controllo della disponibilta (come espresso nel grafico tramite larelazione di “include”). Un discorso analogo e stato fatto nel considerare i casi “copiarivista on–line” e “richiede prestito libro”; in quest’ultimo caso, inoltre, e stato previstauna relazione di extends su “limita prestito” per indicare che, oltre a richiedere il libro,limitare il prestito stesso.

10 Diagramma degli attori

Ordina testoindisponibile

Richiedeprestito

libro

Ricercatesto

Restituiscelibro

Copia rivistaon-line

disponibile

Ricercatore

Controlladisponibilità

"include"

"include"

Limitaprestito

"extends"

"include"

Tesseratonormale

Figura II.1: Use Case Utenti

II.2 Biblioteca

Successivamente ho analizzato il sistema secondo il punto di vista dei dipendenti dellabiblioteca analizzando le possibilta d’uso per ogni tipo di attore. Ho cosı ottenuto ilseguente diagramma.

Responsabileprestito

Registraprestito

Notificarestituzione

Registranuovo tesserato

Cataloganuovitesti

Aggiornafondo

Acquistaordinerivista

Responsabileoridini

Acquistaoridine

Direttore"include"

Fornitore

sw: "Review"

Figura II.2: Use Case Biblioteca

Capitolo II Use Case Diagram

Diagramma degli attori 11

II.3 Diagramma degli attori

Una volta distinti tutti i possibili utenti del sistema, e utile prima di passare al classdiagram classificarli attraverso il seguente diagramma (che non esiste nell’UML).

Ricercatore

Tesserato

Direttore R. ordine R. prestito

Impiegato

Persona Fornitore

il fornitoreè una azienda

Figura II.3: diagramma degli attori del sistema

Use Case Diagram Capitolo II

12 Diagramma degli attori

Capitolo II Use Case Diagram

Capitolo III

Class Diagram

III.1 Utenti del sistema

Una prima modellazione delle classi e quella discende direttamente dal diagramma degliattori (a pagina 11).

Persona+nome: string+cognome: string+inidirizzo: string+telefono: string+stato: string+addPersona()+delPersona()

Tesserato-codice_tessera: string+libri_prestati(): integer+set_tessera()+get_tessera(): string

Impiegato-CoficeFiscale: string+stipendio: integer+set_cf()+get_cf(): string

Direttore R_ordine

Fornitore+azienda: string+PIVA: long+telefono: string+indirizzo: string+addFornitore()+delFornitore()+editFornitore()

ruolo{sovrapposto,incompleto}

impiego{disgiunto,completo,

dimaico}

R_prestitoRicercatore-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 daldiagramma degli attori ma saranno aggiunte le informazioni sul tipo di generalizzazione.

In particolare voglio mettere in evidenza che la gerarchia “ruolo” e incompleta poicheuna persona puo essere istanziata anche se non e un tesserato o un impiegato (per esempiopuo essere una persona disoccupata che prima di essere assunta sta facendo un periododi prova). Questa gerarchia risulta inoltre sovrapposta per dare maggiore flessibilita alsistema che potra quindi prevedere un impiegato a sua volta tesserato.

14 Testo

Un altra cosa che voglio mettere in evidenza e che la gerarchia “impiego” e dinamica, perprevedere la possibilta di carriera.

III.2 Package Diagram del sistema

A questo punto e possibile individuare alcuni gruppi di classi (o pacchetti) che interagi-scono all’interno del sistema.

utentiSistema ordinazione

prestito testo

acquisto

Figura III.2: Package Diagram del sistema

Questo diagramma e stato ottenuto generalizzando un abbozzo [1] di class diagram (ap-proccio bottom–up) con lo scopo di trattare i singoli pacchetti (approccio top–down) ren-dendoli il piu possibile elastici, introducendo eventualmente anche delle classi che nonservono per la risoluzione del problema ma che saranno utili per la riusabilita del lavorosvolto.

III.3 Testo

Trattando in maniera generica la classe Testo mi sono accorto che essa poteva esserespecializzata in “disponibile” o in “indisponibile”.

Un’altra distinzione su Testo all’interno di questo sistema e tra libri e riviste.

Avevo dunque la scelta di classificare in libri e riviste e poi distinguere ognuno di questeclassi in disponibili o indisponibili, oppure distinguere subito secondo la disponibilita epoi in libri e riviste.

Ho preferito optare per questa seconda possibilita poiche mi sembrava piu agevole per leinterazioni con le classi degli altri pacchetti e ho cosı ottenuto il diagramma seguente.

[1] questo grafico non viene riportato come inizialmente pensato ma presentero una sua versione piuraffinata in figura III.7 a pagina 17

Capitolo III Class Diagram

Ordinazione 15

Testo+Titolo: string+addTesto()+delTesto()+editTesto()

T_disponibile+collocazione: string+get_collocazione(): string

T_indisponibile

disponibilità{completo,disgiunto}

tipologia{completo,disgiunto}tipologia

{completo,disgiunto}

Rivista_Indisponibile Libro_IndisponibileLibro+autori: string+editore: string+anno: integer+Num_copie(): integer

Rivista+tipo: string+articolo: 1..maxint+autore: string

Figura III.3: Class Diagram dei Testi

III.4 Acquisto

In questo diagramma viene trattato il problema dell’acquisto di un libro e della registra-zione di una fattura da parte di un Responsabile degli ordini.

Fornitore(from utentiSistema)

1..1

0..*

PIVAFattura

+data: date+numero: integer+importo: integer+addFattura()+modFattura()+delFattura()

Ordinazione(from ordinazione)

1..*

0..1

R_ordine(from utentiSistema)

0..*

1..1

registra

Figura III.4: Class Diagram di AcquistoLa relazione tra Fattura e Ordinazione e stata messa come composizione per evidenziare chequesto legame e sı opzionale (poiche ci puo essere una ordinazione ancora non soddisfatta)ma una volta instaurato l’oggetto di Ordinazione “muore” con questo legame: cioe nonha senso tenere traccia dell’ordinazione se si cancella la fattura a cui si riferisce. Questonon avviene per Fornitore oltretutto perche una ordinazione puo appartenere ad una solafattura, mentre un fornitore puo comparire anche su piu fatture.

III.5 Ordinazione

Il diagramma diventa semplicemente il seguente.

Class Diagram Capitolo III

16 Class Diagram riassuntivo

T_indisponibili(from testo)

Ricercatore(from utentiSistema)

0..*

0..*

Ordinazione+data_ordinazione: date

Figura III.5: Class Diagram Ordinazione

III.6 Prestito di un Testo

Libro(from testo)

Tesserato(from utentiSistema)

Rivista(from testo)

0..*

0..*

copia

0..* 0..*

Prestito+data_prestito: date+get_scadenza(): date

{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 scadenzadel prestito di un libro. Osservo che per quanto riguarda di riviste on–line si parla di copiapiu che di prestito e quindi non ha senso porsi il problema della scadenza e di conseguenzanon 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 mostrera le interazioni tra le varieclassi dei diversi pacchetti


Class Diagram riassuntivo 17

Lib

ro(from testo)

Tes

sera

to(from utentiSistema)

Riv

ista

(from testo)

0..*

0..*

copia

0..*

0..* Pre

stit

o+data_prestito: date

+get_scadenza(): date

T_i

nd

isp

on

ibili

(from testo)

Ric

erca

tore

(from utentiSistema)

0..*

0..*

Ord

inaz

ion

e+data_ordinazione: date

Fo

rnit

ore

(from utentiSistema)

1..1

0..*

1..*

0..1

0..*

1..1

registra

PIVA

Fat

tura

+data: date

+numero: integer

+importo: integer

+addFattura()

+modFattura()

+delFattura()

R_o

rdin

e(from utentiSistema)

Tes

to+Titolo: string

+addTesto()

+delTesto()

+editTesto()

T_d

isp

on

ibile

+collocazione: string

+get_collocazione()

R_p

rest

ito

0..*

0..*

modifica

Figura III.7: Class Diagram Sistema

Class Diagram Capitolo III

18 Class Diagram riassuntivo


Capitolo IV

Sequence Diagram

In questo capitolo, come nei successivi non descrivero tutti i possibili casi d’uso tramite isequence diagram ma cerchero di analizzare quei casi che ho ritenuto piu significativi perevidenziare le potenzialita dell’UML.

IV.1 Acquisto di un libro

In questa azione intervengono le figure di Responsabile degli ordini e dei Fornitori secondole seguenti modalita

• Il responsabile degli ordini considera una ordinazione ancora insoluta.

• Attraverso un opportuno metodo della classe Ordinazione si chiedera al fornitore ilpreventivo 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 necessita di aggiungere i seguentimetodi:

1. +preventivo() per la classe Ordinazione

2. +calcola preventivo() per la classe Fornitore

20 Prestito di un libro

R_ordini

una ordinazione

fondo

Fornitore

prezzo:=preventivo()calcola_preventivo()

add_spesa(prezzo)

fatturanew

kill

Figura IV.1: Sequence Diagram sull’acquisto di un libro

Infine osservo che e 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 fara indirettamente eseguire un particolare metodo dellaclasse Testo che controllera se esso e ancora disponibile (ossia se e in biblioteca). In casoaffermativo verra istanziata un nuovo oggetto della classe T disponibile che il tesseratoprovvedera a inviare al responsabile dei prestiti (tramite un opportuno metodo). Saracompito di quest’ultimo controllare che il tesserato sia effettivamente abilitato ad ottenereil prestito (cioe 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

Prestito di un libro 21

[ok2

] new

Tes

sera

to

new

Tes

to :

test

o ch

iest

o

ok:=

chk_

disp

onib

ile()

T_d

ispo

nibi

le :

richi

esto

[dis

poni

bile

] new

retu

rn

R_p

rest

ito

[ok]

chi

edi_

test

o(ric

hies

to)

ok2:

=co

ntro

lla_l

imite

()

nuov

o pr

estit

o

stam

pa_r

icev

uta(

)

Figura IV.2: Sequence Diagram del prestito di un libro

Sequence Diagram Capitolo IV


Dall’analisi di questo nuovo diagramma si evince la necessita di aggiungere i seguentimetodi:

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 andro ad analizzare una serie di stati d’azione tramite lo strumentoUML dell’activity diagram. Infatti per attivita si intende un processo reale che avvienenel mondo reale (come chiedere un preventivo) o l’esecuzione di una routine del software(come un metodo di una classe).

In particolare si e esaminato il caso l’acquisto di un libro e il prestito di un libro a favoredi un tesserato.

V.1 Acquisto di un libro

Analizzando il caso dell’acquisto di un libro ho ottenuto il seguente diagramma:

Acquistalibro

Aggiornafondo

Registra fattura

Chiedi preventivo

Considerauna ordinazione

[prezzo<fondo][else]

Figura V.1: Activity Diagram Acquisto di unlibro


V.2 Prestito di un libro

Nel caso di un prestito di un libro (analizzato per certi aspetti nel capitolo del SequenceDiagram) il diagramma seguente:

Controlla limite prestito

Controlla disponibilità

[disponibile]

[else]

Aggiornalimite

Registraprestito

Aggiornadisponibilità

Stamparicevuta

[fuori_limite]

[else]

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 sivuole avere la possibilita di registrare anche i possibili candidati o persone che sono in unperiodo di prova e che non sono attualmente assunti. Queste categorie di persone vengonoconsiderate dal sistema come disoccupati .

Quando si viene assunti definitivamente si diventa Responsabile prestito poi, in seguito aduna promozione, Responsabile ordini e infine Direttore.

Dalla mia analisi risulta il seguente diagramma:

DisoccupatoR_prestito

do/timbra cartellino

R_ordine

entry/aumenta stipendiodo/timbra cartellino

Direttore

entry/aumenta stipendio

assunzione

promozione

promozione

licenziamento

licenziamento

licenziamento

Pensionato

entry/ricevi liquidazione

[età>65]

[età>65]

[età>65]

Figura VI.1: State Diagram sullo stato del dipendente

26 Stato del dipendente

Capitolo VI State Diagram

Capitolo VII

Data Flow Diagram

Anche se questo strumento non esiste nel UML, risulta comunque utile a evidenziare ilflusso 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 puo avere vari livelli di dettaglio, quindi in questocaso analizzero il prestito di un libro riservandomi di dettagliare in seguito il processo“Gestore Prestito”.

Tesserato Getsore prestito

chiede_testo

visualizza_esito

cerca_testo

ricercacollocazione

Db_Testi

R_prestito

Figura VII.1: Data Flow Diagram di un prestito

Dettagliando il processo “Gestore Prestito” ho ottenuto il diagramma nella figura seguen-te.


Te

ssera

to

chie

de

_te

sto

visua

lizza_

esito

ricerca

collo

cazio

ne

Db

_T

esti

R_

pre

stito

chk_disponibile

Db

_T

esti_

in_

bib

leo

teca

chiedi_testo

chie

de

_te

stod

ispo

nib

ile

controllalim

ite

visua

lizza_

esito

visua

lizzarich

iesta

Gestore

tesserato

ag

gio

rna

limite

Gestore

disponibilitàD

b_

Sta

to_

tesse

rato

cerca_testo

Db

_T

esti_

in_

bib

leo

teca

ag

gio

rna

disp

on

ibilità

Figura VII.2: Data Flow Diagram dettagliato

Capitolo VII Data Flow Diagram

Appendice A

Breve richiami all’UML

L’UML e un modello semi informale, orientato ad oggetti ed utile specialmente per sistemireal time.

A.1 Use Cases

La use case e il modello rudimentale utile nella fase iniziale della progettazione. Piuprecisamente e un complesso di funzioni elementari che risponde in maniera completa alleesigenze 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 puo registrare l’operazione

3o scenario: l’operatore puo respingere l’operazione

In questo caso la use case e “cambio assegno” e rappresenta le operazioni appunto neces-sarie per cambiare un assegno. Il grafico sul quale viene rappresentato e detto UCD (UseCase Diagram) dove viene disegnato l’attore a forma di omino e la use case racchiusa inun ovale. In questo esempio diventa l’UCD semplicemente:

Banchiere

cambio assegno

[1] si dice scenario una sessione di lavoro di un software che ha un inizio e una fine

30 Use Cases

Questo e un esempio molto banale; tuttavia potremmo avere un UCD piu complessodove ci sono piu relazioni tra una use case ed un’altra come vincoli (disegnati freccetratteggiate) o specializzazioni (indicate con una freccia continua). Per esempio potremmoavere qualcosa di simile:

Cassere

cambio assegno stato del c/c

Gestione prestito

Gestione prestito agricoloValorizzazionePresto

Direttore

"include"

"include"

"include"

Respons.prestito

oltre alle relazioni di include possiamo avere anche relazioni di extends come nell’esempioseguente:

cliente regolare

Rapporti banca

"extends"

(pagamento, spedizione)

"extends"

(garanzie)

Acq. Prodotto

extension points: pagamentospedizione, garanzie

tuttavia questo tipo di relazione si usa solo qualche volta, giusto per evidenziare aspettirispetto al concetto generale; nell’esempio i metodi che meritano di essere ridefiniti sonoi 3 dell’extension points.

Anche se UML non lo prevede, risulta utile fare un grafico dove si distinguono le categoriedi attori, come ad esempio:

Appendice A Breve richiami all’UML

Class Diagram 31

Attore

supporto tecnico

utente

Esterno

Interno

Tecnico

Politig(fa richieste di query standard)

Infine bisogna osservare che nell’UCD non sono solo gli attori che possono interagire con leuse cases, ma anche altri software (racchiusi in un rettangolo) come si evince dal seguenteesempio:

Attore

Use Case 1

Use Case 3

Use Case 2

"actor" sw XK41

A.2 Class Diagram

E un grafico di tipo statico per la modellazione delle classi [2] . Ogni classe e rappresentatainternamente in una scatola con i suoi attributi (dati) e i suoi metodi, come da esempio:

[2] una classe e 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

Piu 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 proprieta della classe separate da virgole e racchiuse tra parentesi graffe(es. {abstract}).

Possiamo avere delle associazioni tra classi indicate con una linea se e bidirezionale, conuna freccia se e unidirezionale. Sopra questa linea bisogna specificare la molteplicita dellarelazione secondo la seguente notazione:

• lower–bound..upper–bound

• il carattere asterisco (*) come upper–bound sta ad indicare +∞

ad esempio la seguente molteplicita:

Conto corrente+identificatore: 0..100+filiale: (A,B,C)+fido: 0..1000+apri()+stampa saldo()+prelievo()+deposito()

Cliente+Nome: +Cognome: -CF: +set CF()+get CF()

0..* 1..1

sta ad indicare che un contocorrente appartenere ad uno e un solo cliente mentre un clientepuo avere a 0 a +∞ conto correnti.

Davanti ai metodi o agli attributi puo esserci uno dei tag seguenti:

+ metodo/attributo pubblico


Class Diagram 33

# metodo/attributo protetto [3]

– metodo/attributo privato [4]

se non c’e nessun tag allora si tratta di una implementazione

Osservazione: non abbiamo bisogno, come nell’E/R, di cercare la chiave primaria perchein realta ad ogni oggetto e associato un object id (interno al sistema e invisibile) e lo statodei suoi attributi. Paritamente non abbiamo problemi di normalizzazione.

A.2.1 Vincoli

Possiamo avere la necessita di esprimere dei vicoli sugli attributi di una classe, alloraconvenzionalmente racchiudiamo questi vincoli tra parentesi graffe fuori dalla classe ecolleghiamo il vincolo al suo attributo tramite una linea tratteggiata. Ad esempio:

Persona+Nome: string+Cognome: string+Nascita: date+Età: 0..200+Nazionalità: string+Sesso: (M,F)+Età Media()

{Età=Differenza(Nascita-Oggi)}

A.2.2 Specializzazione

Le classi possono essere specializzate in sottoclassi attraverso una freccia (con punta atriangolo vuoto) e una etichetta vicino a essa che comprende il nome della partizione dellasuperclasse che si sta specializzando e uno o piu vincoli separati da una virgola, racchiusiin parentesi graffe. I vincoli piu noti sono:

• sovrapposto: se lo stato della partizione puo discendere da piu 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 dicadere al di fuori di essi

• incompleto: se le sottoclassi rappresentate non coprono tutti i casi

[3] si ricorda che un metodo e protetto quando e visibile solo dalla classe stessa e dalle classi appartenentiallo stesso package

[4] un metodo e privato se e visibile solo all’interno della sua classe


34 Class Diagram

Possono essere aggiunti anche altri vincoli come il dinamico dell’esempio seguente che staad indicare che lo stato di appartenenza della partizione ad una sottoclasse puo variaredinamicamente nel tempo:

Persona+Nome: string+Cognome: string+Sesso: +Professione:

Maschio Femmina

Sesso{disgiunto,completo}

Disoccupato

Studente

Pensionato

Professione{dinamico,incompleto}

A.2.3 Aggregazione

E una relazione del tipo parte di. L’Esempio classico e quella del motore e dell’auto:un motore e parte dell’auto. L’aggregazione e rappresentata attraverso un rombo vuotoattaccato 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 cardinalita. Un caso particolaredell’aggregazione e la composizione: cioe quando il componente puo fare parte di unsolo oggetto composto e una volta creato il vincolo, il componente muore con il legame.Un esempio e quella della finestra grafica che ha come componenti 2 scroll bar, un titolo eun corpo. E chiaro che si tratta di una composizione perche le scroll bars (come anche iltitolo e il corpo) non possono fare parte di piu di una finestra grafica e, quando muore lafinestra si deallocano anche gli oggetti che la compongono. Al dire il vero anche l’esempiodell’auto e del motore sembrerebbe una composizione. Invece un esempio piu chiaro diaggregazione semplice e il giocatore nella squadra se ammettiamo che un giocatore puogiocare in piu squadre.

La composizione si annerendo il rombo.


Class Diagram 35

A.2.4 Qualificatori

Il Qualificatore e un attributo (o una tupla di attributi) il cui valore mi identifica unaparte degli oggetti della classe che sono proprio quelli associati all’oggetto [5] dall’altraparte della associazione.

Consideriamo ad esempio:

Banca

Numero_conto

Persona

*

0..1

ho che un numero di conto mi identifica un insieme di oggetti della classe Banca chepossono essere associati (0..1) ad un oggetto della classe Persona.

Come visto in questo esempio il qualificatore e racchiuso in un quadrato sotto (o a sinistraoppure a destra) la scatola che contiene la classe.

A.2.5 Associazione di classe

E una associazione che ha le proprieta di una classe (come quella di essere associataad un’altra classe). Graficamente si disegna con una linea continua tra due classi e dalcentro di questa linea si fa partire una linea ortogonale tratteggiata che si collega allaclasse descrittrice dell’associazione. Nel seguente esempio Proprieta e una associazione diclasse:

Persona+Nome: String+Cognome: String+Nascita: Date+init()

Casa+Via: String+Mq: Integer+Costruita: Date+valore()

NotaioProprietà

+Data_inizio: Date+Data_fine: Date

1..n 0..n

[5] se parliamo di oggetto al singolare vuol dire che la cardinalita da questa parte dell’associazione e 0..1o 1


36 Sequence Diagram

A.2.6 Object Diagram

E un caso particolare del diagramma delle classi e viene usato per esprimere qualcheesempio. Si disegna come una classe solo che il nome viene sottolineato e non vengonomostrati 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 interazionitra gli oggetti. Tale diagramma ha due forme che evidenziano aspetti diversi: sequencediagram (o diagramma delle sequenze) e collaboration diagram.

Nel sequence diagram si mostrano le interazioni tra oggetti ordinate rispetto al tempo.Piu precisamente gli oggetti che partecipano all’interazione sono disegnati su delle “lineedi vita” e i messaggi che si scambiano sono indicati da delle frecce.

La differenza tra sequence diagram e collaboration diagram e che il primo mostra inesplicito la sequenza di messaggi ed e dunque meglio per le specifiche real–time o perscenari complessi. Invece il secondo mostra la parentela tra gli oggetti ed e quindi piuindicato per studiare tutti gli effetti di un dato oggetto in un progetto procedurale.

Qui si parlera del solo diagramma delle sequenze.

Questo diagramma ha due dimensioni: una verticale dove si rappresenta il tempo (at-traverso la linea di vita) ed una orizzontale dove vengono rappresentati gli oggetti. Nor-malmente il tempo procede dall’alto verso il basso. Vicino alle transazioni possono essereinserite delle etichette per vari scopi come ad esempio quello di marcare il tempo o quello dispiegare 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 ilsuo estremo inferiore puo rappresentare eventualmente la sua distruzione; in quest’ultimocaso, l’estremo inferiore verra marcato con una “X”. Il tratto di tempo in cui l’oggettoriceve e/o trasmette messaggi, viene indicato sostituendo al tratteggio un rettangolo il cuiasse coincide con la linea di vita.


Activity Diagram 37

Per fare un esempio si veda la figura qua ac-canto.

MessaggiI messaggi vengono disegnati con una frecciala quale viene etichettata con il nome dell’o-perazione o del segnale a cui si riferisce.Possiamo infine avere le seguenti categorie dimessaggi:

1) Asincroni: disegnati con mezza freccia2) Chiamate: disegnate con una freccia nor-male3) Restituzione: disegnato con una frecciatratteggiata.

Contoinizia()

estrai()

promozione()

Chuiso()

Nella figura che seguira ci sara un esempio piu significativo: si tratta del diagramma dipiu 4 oggetti che rappresentano la gestione di un magazzino; se sul messaggio appare unqualcosa del tipo:

[cond ] message()−−−−−−−−−−−−−−−−→vuol dire che se e verificata la condizione cond allora sara spedito il messaggio message().

I termini new e return sono delle parole chiave che significano rispettivamente la creazionedi un nuovo oggetto e il ritorno di un messaggio.

order entry order order line

prepara()

prepara()

return

product

ok:=check()

[ok] cala()

poco:=scarta()

ordinazione[poco] new

spedizione[ok] new

messaggio[NOT ok] new


38 Activity Diagram

A.4 Activity Diagram

E un diagramma che rappresenta una serie di stati di attivita. Per attivita si intendesia un processo reale che avviene mondo (come ad esempio scrivere una lettera) e sial’esecuzione di una routine di un software (come un metodo di una classe).

Si parte (punto di start) dal flusso iniziale che puo eventualmente diramarsi (fork), sicompiono le azioni indicate negli stati e infine si termina (punto di stop). Infine ogni flussopuo diramarsi, cioe seguire una strada al posto di un’altra a seconda che una determinatacondizione sia vera o meno. Per disegnare questo grafico si fa uso dei seguenti simboli:

azione

Per chiarire il tutto si osservi il seguente esempio:


Sate Diagram 39

Ricavo oridine

soddisfoordine

inviofattura

Spedizioneregolare

Spedizioneespressa

[urgente]

Pagamento

Chiudo ordine

Concludo dicendo che il diagramma delle attivita e facoltativo.

A.5 Sate Diagram

Questo grafico si generalizza quello visto in precedenza, poiche si rappresentano i possibilistati per i quali un oggetto o una interazione puo passare.

Ad esempio un oggetto appartenente alla classe Persona puo passare per i seguenti statifondamentali:


40 Uno strumento non previsto: DFD

[età>=18] matrimoniocelibe sposato

vedovo

morte coniugematrimonio

separatosentenza divorziato

do/pago_alimenti

[tempo>=3m]

matrimonio

Come si puo notare uno stato puo avere diversi livelli di dettaglio. Quello piu alto e:

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 e 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 trattareperche e 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 attivita che assume dei dati in ingresso e produca outputs in uscita


Uno strumento non previsto: DFD 41

Processo

I1

I2

I3

O1

O2

P1

P2

P3

P4

d12 d23

d24

I1

I2

I3

O1

O2

Oltre al processo il DFD ha le seguenti primitive:

• Agente esterno (es. l’utente o un programma): Nome

• Deposito dati: Nome

Si deve tenere presente che gli agenti esterni e i depositi dati non possono scambiarsimessaggi tra loro, ma solo con processi. Per esempio:

Utente

P1 P2

Dati B

Dati ADati A

d12

richiesta se

Utente

Il DFD e precedente all’approccio ad oggetti ma e utile perche i processi diventeranno imetodi nel diagramma delle classi.


42 Uno strumento non previsto: DFD


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

tesina di ingegneria del software - progetto atena del software/tesina... · 2003. 2. 7. ·...

Documents