Analisi e progettazione

Object Oriented
con UML
Esercizi

Esercizio 0
Modelliamo il sistema di gestione dei tirocini di una
universit
Siamo interessati a rappresentare i requisi utente,
quindi usiamo gli use case diagrams.

Gestione tirocini
Le aziende interessate producono delle offerte di
tirocinio.
Il responsabile dei tirocini approva o rifiuta le offerte.
I rifiuti sono notificati allazienda proponente.
Le offerte accettate diventano visibili agli studenti.

Gli studenti visualizzano le offerte. In conseguenza di ci

possono accordarsi con lazienda proponente.
Le aziende assegnano gli studenti graditi ai tirocini offerti.
Il responsabile dei tirocini approva o rifiuta gli
accoppiamenti studente-tirocinio.
In caso di accettazione si stampa laccordo che dovr essere
firmato da tutte le parti in causa.

Use case diagram

InserimentoOfferta
Azienda

ValutazioneOfferta

RifiutoOfferta

AccettazioneOferta
Responsabile

Accordo

Studente

EsaminaOfferta

Approvazione

StampaDoc

Esercizio 1: Impresa edile

Si definisca un semplice Use Case Diagram per
modellare il sistema informativo di una impresa
edile. Il sistema deve gestire gli operai, i cantieri, il
parco mezzi e i clienti.

Impresa Edile: Use Case Diagram

Assunzioni

UfficioPersonale

GestioneFerie

GestioneMalattie

Operaio

Responsabile

AcquisizioneMezzi

GestioneRiparazioni

AssegnamentoRisorse

GestioneCommesse

AssegnamentoMezzi

Cliente

AperturaCantiere

GestionePagamenti
Banca

Impresa Edile: Class Diagram

Impresa

Operaio

Mezzo
Operat ivo : bool
Nome : string
Descrizione : string

Nome
Qualifica
DataAssunzione

Cantiere
Dat aA pertura
Luogo
Responsabile

Cliente
Nome

Lavoro
Descrizione
Durata
Costo
Pagamento

Esercizio 2:
Compagnia di Assicurazioni
Descriviamo una compagnia di assicurazione
Siamo interessati a descrivere il dominio del
problema, con particolare riferimento agli aspetti di
modellazione statica.
Produciamo un diagramma delle classi

La compagnia di assicurazioni
La compagnia di assicurazioni stipula diversi tipi di
polizze (RC auto, vita, rischi diversi).
La compagnia ha diversi clienti, ciascuno dei quali
pu sottoscrivere pi contratti.

Compagnia di Assicurazioni:
Class diagram (1)
Cliente
Nome : string
DataNascita : date
Indirizzo : string
CodiceFiscale : string
1

1..n
Contratto
Numero : int
DataStipula : date
ImportoAssicurato

Compagnia
1

0..n
1
Polizza
Testo : string
1..n

Vita

RCAuto

Furto

Compagnia di Assicurazioni:
Class diagram (2)
Cliente
Nome : string
DataNascita : date
Indirizzo : string
CodiceFiscale : string

Assistenza
Inizio : date
Fine : date
Impiegato

1..n
1..n

1..n
Contratto
1..n Numero : int
DataStipula : date
ImportoAssicurato

1
Agenzia
Numero : int
Indirizzo : string
1..n

0..n
1
Polizza
1..n
Testo : string

1
Compagnia

Vita

RCAuto

Furto

Esercizio 3:
Struttura di un Ospedale
Descriviamo la struttura (statica) di un ospedale con
un diagramma delle classi
Lospedale organizzato in reparti, ciascuno dei
quali ha uno staff e dei pazienti.
I pazienti hanno una cartella clinica associata.
Ciascun paziente pu essere ricoverato pi volte.
Si vuole tenere traccia dei ricoveri e delle
dimissioni.
I reparti hanno uno staff medico fisso. Il pronto
soccorso no: tutto lo staff, secondo opportuni turni,
vi lavora.

Ospedale: class diagram

1

Paziente
Nome : string
CodiceFiscale : string
DataNascita : date

Ospedale
1

ProntoSoccorso

1..n
PersonaleAmministrativo
Nome : string
Anzianit : int

1
1..n
Turno
Data : date

1..n
1..n
Reparto

1..n

Ricovero
0..n Ingresso : date
Uscita : date

0..n

1
Periodo
Da : date
A : date

1..n
PersonaleMedico
Nome : string
Qualifica : string

1
CartellaClinica

RepartoConStaff
1

1..n 1

1
StoriaRicovero
1..n

Personale

Medicina

Chirurgia

Ostetricia

Esercizio 4:
Sistema di gestione corsi (1)
Si vuole realizzare un sistema per la gestione
amministrativa dei corsi di Master
Ciascun corso pu essere svolto in pi edizioni
Ogni edizione si articola in un certo numero di lezioni e ogni
lezione pu essere tenuta da pi docenti. Possono esistere
docenti assegnati al corso che, per vari motivi, non tengono
alcuna lezione (ad esempio vengono preallocati per possibili
sostituzioni). Ogni lezione ha una data, unorario di inizio, una
durata e unaula assegnata
Ogni lezione pu richiedere lutilizzo di risorse aggiuntive (es.
VideoBeam, PC, etc.)
I docenti si distinguono fra docenti interni ed esterni. Ciascun
corso ha come responsabile un docente interno
Ogni edizione di un corso ha un certo numero di partecipanti,
iscritti a quella specifica edizione, distinti fra studenti di Master
e uditori esterni

Sistema di gestione corsi:

class diagram
+responsabile DocenteInterno
1
Docente

0..n
Corso
Nome : string
Edizione
: int
1..n
1

Preallocazione
0..n

Nome : string

1..n

DocenteEsterno
1..2

Allocazione
0..n
Lezione
Numero : int
1..n Argomento : string
Data : date
OraInizio : time
OraFine : time

Iscritto

1..n
Partecipante

0..n

0..n

1..n
1

Studente

0..n

Uditore

Aula
Nome : string
Capienza : int
VideoBeam : bool

0..n
Risorsa
Nome : string

Esercizio 5: Palestra
Si progetti un sistema informativo per la gestione di
una palestra.
Ad ogni cliente, la palestra chiede nome, cognome,
et, indirizzo e professione, nonch la tipologia di
abbonamento e i servizi richiesti.
La palestra offre abbonamenti mensili e annuali (13
mesi).
I clienti possono usufruire della sala pesi, della
piscina, della parete da arrampicata, della sauna e
del bagno turco. Sala pesi, sauna e bagno turco sono
compresi nellabbonamento base; gli altri servizi
sono venduti in aggiunta alla quota base.

Palestra (2)
Ad ogni cliente associata una scheda per la sala
pesi che definisce gli esercizi da compiere, il
numero di ripetizioni e la frequenza. La scheda pu
essere organizzata su una visita alla palestra a
settimana oppure su due.Nel caso i clienti siano
abbonati a servizi aggiuntivi (ad esempio, la
piscina), la scheda pu considerare anche questi
servizi e, di conseguenza, il numero di visite
aumenta.

Palestra (3)
La palestra offre, a chi fosse interessato, uno staff
medico per assistere i clienti, stabilirne il grado di
forma e definire diete opportune. Chi richiede
questo servizio, deve sottoporsi a controlli mensili e
i risultati vengono opportunamente archiviati: peso,
massa grassa, elettrocardiogramma, battiti del
cuore a riposo e sotto sforzo.
Il sistema deve essere in grado di elaborare il
bilancio complessivo (entrate dagli abbonati) della
palestra sia mese per mese, che alla fine di ogni
anno, e deve sollecitare eventuali clienti morosi o
che devono sottoporsi al controllo mensile.

Palestra: Diagramma delle classi

Numero : Integer
Frequenza : String

Scheda
NumVisiteSettimanali : Integer

0..n

1..n

Esercizio
Descrizione : String

Palestra

1
ServiziAggiuntivi
1
Cliente
Nome : String
DataNascita : Date
Indirizzo : String
Professione : String
Moroso(d : Date) : Boolean
DeveFareControllo() : Boolean
1
0..n
RisultatoControlloMedico
DataControllo : Date
Peso : Double
MassaGrassa : Double
FreqCardiacaRiposo : Integer
FreqCardiacaStress : Integer

0..n

1..n

1
0..n

Abbonamento
DataInizio : Date
CostoBase : Integer
1

1..n

EntrateMese(d : Date) : Integer

1 EntrateAnno(d : Date) : Integer
StampaMorosi()
StampaControlliDovuti()

Servizio
Nome : String
1..n CostoAggiuntivo : Integer

ServiziBase

Entrata(d : Date) : Integer

CostoMensile() : Integer

1..n

AbbonamentoMensile

AbbonamentoAnnuale

CostoMensile() : Integer
CostoAnnuale() : Integer
DataConclusione() : Date

CostoMensile() : Integer
CostoAnnuale() : Integer
DataConclusione() : Date

Pagamento
MesePagato : Date
0..1 ImportoPagato : Integer

0..13

1..n

Esercizio 6:
Bookmaker
Un Bookmaker vuole ralizzare una applicazione per
la gestione di una lista di scommettitori sulle corse
dei cavalli.
Una corsa caratterizzata da un certo numero di
corridori e da un vincitore, che deve essere un
corridore partecipante alla corsa
Un corridore un cavallo guidato da un fantino
Ciascuno scommettitore pu effettuare un numero
qualsiasi di scommesse
Ciascuna scommessa riferita ad una singola corsa,
ad un particolare corridore presente nella corsa ed
caratterizzata da un importo e da una quotazione

Bookmaker (2)
Il sistema deve consentire
la gestione di un elenco di scommettitori
l'accettazione di scommesse da parte del bookmaker
per conto di scommettitori (gi conosciuti o nuovi)
la determinazione dell'importo totale delle vincite e
delle perdite per il bookmaker al termine delle corse
(quando cio sono noti i vincitori di tutte le corso
sulle quali sono state accettate scommesse)

Persona
Persona(nome : String, cognome : String)
toString() : String
equals(p : Object) : boolean
main(args : String[]) : v oid

Bookmaker

Fantino
peso : f loat
altezza : f loat
n_v ittorie : int

Bookmaker(nome : String, cognome : String)

aggiungiScommettitore(s : Scommettitore) : v oid
accettaScommessa(sc : Scommettitore, s : Scommess...
totaleVincite() : int
totalePerdite() : int
main(args : String[]) : v oid

Fantino(nome : String, cognome : String, p : f loat, a : f loat, n : int)

equals(f : Object) : boolean

f antino
Scommettitore
Scommettitore(nome : String, cognome : String)
aggiungiScommessa(s : Scommessa) : v oid
totaleScommesse() : int
totaleVincite() : int
equals(s : Object) : boolean

Corridore

co rr id or e

Corridore(f : Fantino, c : Cav allo)

equals(c : Object) : boolean
v incitore

Scommessa
importo : int
quotazione : f loat
cav allo
Scommessa(c : Corsa, corr : Corridore, imp : int, quot : int)
v inta() : boolean

Ca va llo
pe so : flo at
Ca va llo(n : Str ing, p : flo at )
eq uals (c : Obje ct) : bo olea n

corsa
Co rsa
aggiungiCorridore(c : Corridore) : v oid
setVincitore(v : Corridore) : v oid
equals(c : Object) : boolean

Esercizio 7:
Spedizione posta ordinaria
Descrivere con un sequence diagram le operazioni
che caratterizzano linvio di una lettera per posta
ordinaria dal momento della spedizione fino a
quello della ricezione da parte del destinatario.
Introdurre gli attori, le classi e gli oggetti ritenuti
utili per una descrizione sufficientemente completa
del problema.
Eventualmente descrivere diversi scenari alternativi.

Spedizione posta

mi tte nte : Person a

: Buca per
lettere

portalettere :
Persona

: Uff ici o p osta le

Ufficio destinazione :
Ufficio postale

porta let tere2 :

Persona

casell a postale destinata rio :

Buca per lettere

: Persona

Imbuca lettera

Ritiro posta
Consegna posta

Smistamento posta

Ritiro posta in consegna

consegna posta
Ritiro posta in arrivo

Esercizio 8: Prelievo Bancomat

Si definisca un semplice Sequence Diagram per
modellare il prelievo di denaro da uno sportello
Bancomat

: Cliente

s : Sportello

t : Tessera

: Banca

MioCC :
ContoCorrente

InserisciTessera(Tessera)
LeggiDati
Dati Tessera: Banca, Codice Tessera
tesseraLeggibile()
VerificaAbilitazione(Codice Tessera)

ok
Lista Operazioni
Pre li ev o(I mpo rto )
Richiesta PIN
PIN
EseguiOperazione(Prelievo, Importo, CodiceTessera, PIN)

VerificaDisponibilit(Importo)
ok
ok
Importo
Impo rto Prel ev at o
ImportoPrelevato
AggiornaSaldoCC
RiduciDisponibilitResidua(Importo)
ok

Collaboration diagram
equivalente
4: tesseraLeggibile()
1: InserisciTessera(Tessera)
8: Prelievo(Importo)
10: PIN
16: ImportoPrelevato

: Cliente

7: Lista Operazioni
9: Richiesta PIN
15: Importo

5: [tesseraLeggibile() = True] VerificaAbilitazione(Codice Tessera)

11: EseguiOperazione(Prelievo, Importo, CodiceTessera, PIN)
17: ImportoPrelevato
: Banca
s : Sportello

3: Dati Tessera:
Banca, CodiceTessera

2: LeggiDati

t : Tessera

6: ok
14: ok

13: ok
20: ok

12: VerificaDisponibilit(Importo)
18: AggiornaSaldoCC
19: RiduciDisponibilitResidua
(Importo)

MioCC :
ContoCorrente

Esercizio 9:
Orologio digitale
Descrivere con un diagramma a stati il comportamento di
un orologio digitale dotato di display per la
visualizzazione e di due bottoni per limpostazione
dellorario.
Il primo bottone definisce la modalit di visualizzazione (normale,
impostazione ora, impostazione minuti), mentre il secondo viene
utilizzato in modalit impostazione per incrementare lora o i
minuti correnti.

Dalla modalit di visualizzazione normale (nella quale

viene visualizzato lorario corrente)
premendo una prima volta il bottone che seleziona la modalit di
visualizzazione si passa alla modalit di impostazione dellora
premendo una seconda volta si passa all impostazione dei minuti
premendolo una terza volta si torna alla modalit di
visualizzazione normale.

Orologio digitale:
class diagram
Display
1

Visualizza(Ore : int, Min : int)

1
Orologio

Ore : int
Minuti : int
Ticks : int
+ Click(ButtonId : int)
+ Tick()
- IncrementaOre()
- IncrementaMinuti()
- Aggiorna()
1
1
Timer

+ModeButton
Button
ButtonId : int

1
+InputButton

Orologio digitale
classe orologio: state diagram
InFunzione
Normale

Click(1)
Tick / Aggiorna

Click(1)

ImpostaOre

Click(2) / IncrementaOre

Click(1)

ImpostaMinuti

Click(2) / IncrementaMinuti

Nota: in genere preferibile specificare il significato delle

operazioni mediante OCL.
Comunque entro certi limiti si pu fare anche negli state diagram.

Orologio digitale
classe orologio: state diagram

InFunzione
Normale
Click(1)
Click(2) / [Minuti=59] Minuti = 0

Click(1)
Click(2)
[Ore=23]
Ore = 0

ImpostaOre

Click(2) [Ore<23] Ore = Ore+1

Click(1)

ImpostaMinuti

Click(2) / [Minuti<59] Minuti = Minuti+1

Tick / Aggiorna

Caso di Studio:
Sistema di controllo per un ascensore

Contesto
Sistema di controllo degli ascensori in un palazzo di
m piani
Il sistema di controllo deve gestire il movimento
degli ascensori tra i diversi piani in accordo con i
seguenti vincoli:
Ogni ascensore ha un insieme di bottoni
corrispondenti ai diversi piani. Questi bottoni si
illuminano quando vengono premuti indicando la
richiesta di arresto dellascensore al raggiungimento
del piano corrispondente

Contesto
Vincoli (segue):
In ogni piano, ad eccezione del primo e dellultimo,
esistono due bottoni per chiamare lascensore
specificando se si vuole salire o scendere. I bottoni si
illuminano quando vengono premuti. Lilluminazione
si spegne quando lascensore arriva al piano
muovendosi nella direzione corrispondente al bottone
illuminato

Identificazione dei requisiti: use

case

Apertura/ chiusura porta

Illuminazione bottone

<<inc lude>> <<include>>

<<include>>

Movimento/Fermata ascensore

<<include>> <<include>>
<<include>>

Selezione diretta piano

Chiamata Ascensore

Passeggero

Diagramma delle classi iniziale

Ascensore

controlla

Controllore Ascensore

controlla

1
comunica
n
Bottone

Bott one_A scensore

Bottone_Piano

Porta

Diagramma delle classi con

attributi
Ascensore
direzione : Boolean
piano_corrente : Integer
idle : Boolean

Porta
controlla

Controllore Ascensore

closed : Boolean
controlla
open()
close()

move()
stop()
status()

comunica

n
Bot tone

Bottone_Ascensore

Bot tone_Piano
num_piano : Integer
direzione : Boolean

Sequence diagram:
Selezione diretta piano
: Passeggero

: Bottone_Ascensore

: Controllore
Ascensore

: Ascensore

premi bottone
selezione piano
status( )

illumina
[porta aperta] chiudi
move(direzione)

piano ragg iunto(piano_c orrente)

[raggiunto piano finale] stop()

[raggiunto piano finale] disattiva illuminazione

[raggiunto piano finale] apri porta

: Porta

Collaboration diagram:
Selezione diretta piano
: Passeggero

1. premi bot tone

2. selezione piano
: Bottone_Ascensore

5. [porta aperta] chiudi

10. [raggiunto piano finale] apri porta
: Controllore
: Porta
Ascensore

4. illumina
9. [raggiunto piano finale] disattiva illuminazione
3. status( )
6. move(direzione)
7. piano raggiunto(piano_corrente)
8. [raggiunto piano finale] stop()

:
Ascensore

Sequence diagram:
chiamata ascensore
: Passeggero

:
Bottone_Piano

: Controllore
Ascensore

: Ascensore

premi bottone
richiesta fermata(piano, direzione)

illumina
[ascensore libero] move(piano)
piano raggiunto
status( )

[di rez io ne OK] sto p

elimina illuminazione
apri porta

: P orta

Collaboration diagram:
chiamata ascensore

: Passeggero
1. premi bottone

2. richiesta fermata(piano, direzione)

9. apri porta

: Controllore
Ascensore

:
Bottone_Piano

: Porta

3. illumina
8. elimina illuminazione
5. piano raggiunto

4. [ascensore libero] move(piano)

6. status( )
7. [direzione OK] stop

:
Ascensore

Porta: diagramma degli stati

close()
Aperta

Chiusa

open()

Ascensore:
esempio di diagramma degli stati
piano raggiunto[ ! ultimo_piano ] /
piano_corrente = piano_corrente + 1
^cont ro llore.pi ano_ rag giun to

Salita

move( nuovo_piano )[
nuovo_piano>piano_corrente a...

al piano
Discesa

stop() / idle = true

[ ! idle and direzione = salita ]

move( nuovo_piano )[
nuovo_piano<piano corrente a...

piano raggiunto ^Controllore.piano raggiunto(piano)

Caso di Studio:
Sistema di gestione posta elettronica

Contesto
In un sistema di posta elettronica ogni utente caratterizzato
dal suo username.
Per ogni utente esistono tre mailbox (inbox, outbox, draft)
che, per semplicit, consideriamo insiemi non ordinati di
messaggi.
Si specifichino le operazioni di creazione di una mail e di sua
spedizione:

La prima operazione crea una nuova mail nella outbox

dell'utente.
La seconda operazione preleva i messaggi in outbox e
li deposita nelle inbox dei destinatari.
Precisazione:

Solo indicazioni di massima, si trascurano molti

dettagli

Use cases

Creazione nuovo messaggio

Creazione nuovo account

User

Administrator

Invio posta

Rimozione Account

Creazione nuovo messaggio:

Scenario base

: MailSystem

Requesting user :

Requesting user's
outbox : MailBox

User

1: newMessage(MailMessage)
2: Aggiungi messaggio a outbox del mittente
3:
4:

Invio posta:
Scenario base
: MailSystem

Requesting User :
User

RequestingUser_

ReceivingUser_

OutBox : MailBox

Inbox : MailBox

1: sendMail(Account)

2: Preleva messaggio
3:

4: Spedisci messaggio al destinatario

5:
6:

a-b : Ripetuto per tutti i messaggi

contenuti nella outbox del
richiedente

Creazione nuovo account:

scenario base
: MailSystem

: Administrator

: Account

: MailBox

: MailBox

: MailBox

1: newAccount(userName)
2: crea account

new

3: crea inbox
new
4: crea outbox
new
5: crea draft
new
6: result

Rimozione account:
Scenario base
: MailSystem

: Administrator

UserAccount :

AccountInbox :

Account

MailBox

AccountOutbox
: MailBox

AccountDraft :
MailBox

1: removeAccount(userName)
2: destroy inbox

3: destroy outbox

X
X

4: destroy draft

5: rimuovi account

6:

Diagramma delle classi

Struttura statica del sistema
Classi
Propriet delle classi
Relazioni fra classi

Costruzione
Identificazione delle entit rilevanti (classi)
Identificazione delle relazioni fra classi
Identificazione degli attributi
Identificazione delle relazioni di
generalizzazione/specializzazione
Eventuale suddivisione in package

Diagramma delle classi

MailSystem
newMessage(msg : MailMessage) : Boolean
sendMail(account : Account)
outbox(account : Account) : MailBox
inbox(account : Account) : MailBox
newAccount(userName : String) : boolean
removeAccount(userName : String) : boolean

0..*

0..*
MailBox

MailMessage
mitt : Account
dest : Account
text : Testo

#outbox

#inbox
0..*

1
#draft
1

Account
1

userName : String

1
1
+theAccount

Diagramma delle classi

(Alternativo)

MailSystem

Account
userName

newMessage(message : MailMessage) : boolean

0..*

sendMail(message : MailMessage) : void

MailMessage
mitt : Account
dest : Account
text : Testo

0..*

MailBox

0..*
Inbox

Draft

1
OutBox