Sistemi Informativi –

Modulo B: Progettazione
di Sistemi Informativi
Università della Calabria
Corso di Laurea Magistrale in
Statistica ed Informatica per le Decisioni
e le Analisi di Mercato

a.a. 2020/2021

Progettazione di
Sistemi Informativi
 Introduzione a UML
 Casi d'uso ed Use Case Diagrams
UML (Unified Modelling
Language)
 È una famiglia di notazioni grafiche che servono
per supportare l’analisi e la progettazione di
sistemi
 UML è uno standard controllato dall’OMG (Object
Management Group)
 un consorzio formatosi per definire standard che
supportino l’interoperabilità (specialmente per i sistemi
orientati agli oggetti)
 I linguaggi di modellazione visuale, a differenza
dei linguaggi di programmazione, hanno un livello
di astrazione sufficientemente alto da permettere
la discussione diretta delle scelte di progetto
Nascita di UML
 UML è nato dall’evoluzione e combinazione
di una serie di linguaggi/diagrammi per
analisi e progettazione già presenti tra la
fine degli anni ’80 ed i primi anni ’90
 Esistono forti affinità e somiglianze con:
 Diagrammi Entity-Relationship (ER)
 Flow Chart
 Diagrammi di stato
 Notazioni Object Oriented (OO)

UML come standard

 Nel 1997 l’OMG (Object Management
Group) emette una versione standard di
UML che si basa sostanzialmente sulla
versione di Booch, Rumbaugh e
Jacobson ma anche sui contributi di
molti altri studiosi e di alcune delle più
importanti software house mondiali
 La sua evoluzione è a carico dell’OMG
ed è soggetta a procedure ben definite
per ogni cambiamento
 Documenti ufficiali: http://www.uml.org
 Storia di UML
Booch Rumbaugh Jacobson

94 (RATIONAL)

Ott. 95
UNIFIED METHOD
Lug. 96 Microsoft, HP, Oracle e altri
UNIFIED MODELING
LANGUAGE (v. 0.9)

Gen. 97 IBM, Platinum e altri

UML 1.0

Nov. 97
UML 1.1 (versione
adottata da OMG)

Storia versioni UML

 novembre 1997: 1.1
 dicembre 1998: 1.2
 giugno 1999: 1.3
 maggio 2001: 1.4
 marzo 2003: 1.5
 agosto 2005 : 2.0
 aprile 2006: 2.1
 Maggio 2008: 2.2
 ….....
Modi di usare UML
 UML come abbozzo
 Diagrammi informali (ed incompleti) per facilitare la
comunicazione e la discussione delle idee e considerare
diverse alternative di progetto
 UML come progetto
 Modello dettagliato e completo che possa essere usato
per la successiva analisi di implementazione
 UML come “linguaggio di programmazione”
 Strumenti CASE (Computer-Aided Software Engineering)
che includono forme di generazione del codice
 Prospettiva concettuale
 UML rappresenta la descrizione dei concetti presenti nel
dominio di studio
 Prospettiva software
 Gli elementi di UML corrispondono direttamente agli
elementi di un sistema software

Diagrammi UML (versioni

1.x)
 diagrammi “strutturali”:
 diagramma delle classi (class)
 diagramma dei componenti (component)
 diagramma di distribuzione (deployment)
 diagrammi “comportamentali” :
 diagramma dei casi d’uso (use case)
 diagramma di sequenza (sequence)
 diagramma di collaborazione (collaboration)
 diagramma di stato (statechart)
 diagramma delle attività (activity)
Diagrammi UML (versioni
2.x)
 diagrammi “strutturali”:
 diagramma delle classi (class)
 Descrivono classi di tipi di entità, loro caratteristiche e relazioni
 diagramma degli oggetti (object)
 Descrivono la configurazione esemplificativa delle istanze
 diagramma dei componenti (component)
 Descrivono la struttura dei compomenti e loro connessioni
 diagramma delle strutture composite (composite structure)
 Descrive la scomposizione di una classe a runtime
 diagramma di deployment (deployment)
 Descrive la distribuzione delle elaborazioni in diversi nodi
 diagramma dei package (package)
 Descrive la struttura gerarchica al momento della compilazione

Diagrammi UML (versioni

2.x)
 diagrammi “comportamentali”:
 diagramma dei casi d’uso (use case)
 Descrive come gli utenti interagiscono con il sistema
 diagramma di stato (statechart)
 Descrive come gli eventi cambiano un oggetto durante il suo ciclo
di vita
 diagramma delle attività (activity)
 Descrive il comportamento procedurale e parallelo
 diagrammi “comportamentali di interazione”:
 diagramma di sequenza (sequence)
 Descrive l’interazione tra oggetti con enfasi sulla sequenzialità
 diagramma di comunicazione (communication)
 Descrive l’interazione tra oggetti con enfasi sulla comunicazione
 diagramma dei tempi (timing)
 Descrive l’interazione tra oggetti con enfasi sulla temporizzazione
 diagramma di sintesi dell’interazione (interaction overview)
 Fusione di un diagramma di sequenza con un diagramma delle
attività
Aspetti della modellazione
UML
 UML consente di descrivere un sistema secondo tre aspetti
principali, per ciascuno dei quali si utilizzano un insieme di tipi di
diagrammi specifici (che possono poi essere messi in relazione fra
loro):
 Il modello funzionale rappresenta il sistema dal punto di vista
dell'utente, ovvero ne descrive il suo comportamento così come
esso è percepito all'esterno, prescindendo dal suo funzionamento
interno.
 Questo tipo di modellazione corrisponde all'analisi dei requisiti
 La modellazione funzionale utilizza i diagrammi dei casi d’uso
 Il modello dinamico rappresenta il comportamento degli oggetti
del sistema, ovvero la loro evoluzione nel tempo e le dinamiche
delle loro interazioni.
 Utilizza i diagrammi di sequenza e i diagrammi delle attività
 Il modello a oggetti rappresenta la struttura e sottostruttura del
sistema utilizzando i concetti object-oriented di classe, oggetto, le
relazioni fra classi e fra oggetti.
 questo tipo di modellazione può essere utilizzata sia nella fase di
analisi del dominio che nelle varie fasi di progetto a diversi livelli di
astrazione
 Utilizza i diagrammi delle classi

Progettazione di
Sistemi Informativi
 Casi d'uso ed Use Case Diagrams
Casi d’uso
 Sono una tecnica utilizzata per identificare
e descrivere i requisiti funzionali di un
sistema
 Serve nella fase di analisi dei requisiti
 Si basano su una descrizione narrativa e
dei diagrammi (diagrammi dei casi d’uso –
Use Case Diagrams ) delle interazioni tra
utenti e sistema
 Un caso d’uso descrive un insieme di
scenari che sono accomunati dallo scopo
finale dell’utente nei confronti del sistema

Scenario
 Uno scenario è una sequenza di passi che
caratterizzano una particolare interazione tra un
utente ed il sistema
 Esempio:
 Caso di un negozio online
 Scenario di Acquisto Prodotto:

Il cliente naviga nel catalogo on-line, sceglie gli articoli

desiderati e li mette in un carrello della spesa.
Quando il cliente desidera pagare, specifica le modalità di
spedizione e fornisce gli estremi della carta di credito.
Il sistema controlla la validità della carta e conferma
l’acquisto immediatamente a video e successivamente
con un messaggio di posta elettronica.
 Questa è uno scenario possibile, ma non l’unico
Scenario Principale
 Ingenerale un caso d’uso ha uno scenario
principale di successo (main success
scenario) che accade nella grande
maggioranza dei casi, detto anche flusso di
eventi principale (basic flow) o corso
d’azione base o “happy path”
 Lo scenario dell’esempio precedente è
quello principale

Scenari Secondari
 Inoltreil caso d’uso può prevedere una o
più estensioni (alternative flows) che
gestiscono eventuali situazioni non comuni
(o di errore) e che possono risolversi con un
successo o un fallimento
 Nel caso dell’esempio precedente
 Se la carta di credito non è valida, il cliente può
provare ad inserire nuovamente gli estremi della carta
e ritentare l’acquisto, oppure potrebbe rinunciare
all’acquisto
 Se il cliente è un cliente abituale, potrebbe avere già

salvato un profilo con le preferenze relative alla

spedizione ed il numero di carta di credito
Basic and alternative flows

Nel caso dell’esempio del negozio online:

basic
 Acquisto del prodotto concluso con successo flow
 Carta di credito non accettata

 Cliente abituale alternat

ive
 Disponibilità di un prodotto terminata flows
 Collegamento con i servizi interbancari interrotto

Attori e ruoli (1)

 Un attore è un ruolo interpretato da un utente in
relazione all’interazione che ha con il sistema
 Esempi:
 Clienti, impiegati, manager, analisti di prodotto, etc.
 Gli attori ‘svolgono’’ i casi d’uso
 Un attore può prendere parte a più casi d’uso
 Il cliente del negozio online può acquistare un prodotto e/
o inserire una recensione su un prodotto
 Un singolo caso d’uso può coinvolgere più attori
 L’acquisto di un prodotto potrebbe coinvolgere sia il
cliente che il responsabile dell’evasione ordini
Attori e ruoli (2)
 Una singola persona può ricoprire la parte di più
ruoli (quindi rappresentare più attori)
 Un attore non deve necessariamente essere un
umano
 Se un sistema svolge un servizio richiesto da un altro
sistema, quest’ultimo è anch’esso un attore
 Ogni caso d’uso ha un attore principale
 È quello che richiede il servizio al sistema
 È quello che persegue lo scopo che il caso d’uso cerca di
soddisfare
 Generalmente, è quello che da inizio al caso d’uso
 Possono esserci attori secondari
 Attori che comunicano con il sistema al fine di portare con
successo a conclusione il caso d’uso

Specifica dei casi d’uso (1)

 Ciascun caso d’uso è descritto da:
 un nome (che può essere una breve frase)
 una breve descrizione in forma testuale del
risultato che l’attore principale si attende da
questa particolare modalità di utilizzo del
sistema
Specifica dei casi d’uso (2)
 Ciascun caso d’uso è descritto da:
 il flusso principale degli eventi (basic flow),
ossia un elenco numerato rappresentante la
sequenza di passi costituenti lo scenario
principale
 considera dall’evento scatenante alla

conclusione per successo del caso d’uso,

senza prendere in considerazione
complicazioni, eccezioni, errori
 Per ogni passo va indicato il soggetto che

effettua l’azione (uno degli attori che

partecipano al caso d’uso, o il sistema) e
l’azione effettuata

Specifica dei casi d’uso (3)

 Ciascun caso d’uso è descritto da:
 eventuali alternative flows, ossia un elenco di
tutte le possibili alternative ai passi dello
scenario principale di successo. Per ogni
scenario secondario deve essere indicata:
 la condizione che lo provoca,

 la sequenza di passi da compiere per il

trattamento del caso particolare (che potrà

concludersi con un ricongiungimento allo
scenario principale, oppure con la
conclusione del caso d’uso)
Specifica dei casi d’uso (4)
 Ciascun caso d’uso è descritto da:
 Eventuali pre-condizioni: condizioni che
devono essere rispettate affinché il caso
d’uso possa iniziare
esempio: per poter fare un acquisto

on-line l’utente deve aver inserito i

propri dati anagrafici nell’apposito
form di iscrizione ai servizi del sito

Specifica dei casi d’uso (5)

 Ciascun caso d’uso è descritto da:
 Eventuali Post-condizioni: condizioni che devono
essere verificate quando il caso d’uso termina
 Possono essere diverse a seconda dello scenario
effettivamente seguito,
 Distinguiamo:

 Post-Condizioni per Successo: Ciò che deve essere

vero dopo che il caso d’uso si sia concluso con il
raggiungimento del risultato atteso
 Post-Condizioni per Fallimento: Ciò che deve essere
vero dopo che il caso d’uso si sia concluso senza il
raggiungimento del risultato atteso
 esempio: se il cliente conferma l’ordine esso viene
passato al magazzino (Post-Condizioni per Successo),
se invece l’utente lo annulla il sistema rimane
inalterato(Post-Condizioni per Fallimento)
Specifica dei casi d’uso (6)
 Ciascun caso d’uso è descritto da:
 eventuali Special Requirements: sono requisiti
non funzionali (non relativi alle funzionalità del
sistema nell’assolvere al caso d’uso)
 Esempio: il sistema deve garantire che l’inoltro
dell’ordine al magazzino avvenga entro le 24
ore successive alla sua conferma

Specifica dei casi d’uso:

esempio 1
 Nome: Acquisto di un prodotto dal catalogo
on-line
 Descrizione: consente ad un cliente di
scegliere un prodotto dal catalogo online,
inserirlo nel carrello e perfezionare l’ordine.
Specifica dei casi d’uso:
esempio 1
 Scenario principale di successo:
1. Il cliente naviga nel catalogo ed inserisce nel carrello
uno o più articoli
2. Il cliente va “alla cassa”
3. Il sistema presenta il conto degli articoli selezionati
4. Il cliente inserisce le informazioni per la spedizione
(indirizzo, tempo di consegna)
5. Il sistema fornisce il conto totale, comprese le spese di
spedizione
6. Il cliente inserisce le informazioni riguardo la sua carta
di credito
7. Il sistema autorizza l’acquisto
8. Il sistema conferma il perfezionamento con successo
dell’ordine
9. Il sistema invia una e-mail di conferma dell’acquisto
all’indirizzo indicato dal cliente

Specifica dei casi d’uso:

esempio 1
 Scenario secondari:
 Carta di credito non valida:
 Il sistema al passo 7 del Basic Flow non autorizza l’acquisto.
 Il sistema avverte l’utente e gli consente di reinserire i dati
della sua carta
 Collegamento con i servizi interbancari interrotto
 Il sistema salva il carrello dell’utente e lo invita a riprovare a
perfezionare l’ordine in seguito
 < eventuali altri flussi alternativi qui….>
 Pre-condizione:
 L’utente deve aver fatto login sul sistema inserendo
username e pwd
 Post-condizione:
 Di successo: se l’ordine è stato perfezionato con
successo, c’è un nuovo ordine da evadere
 Di Fallimento: il sistema rimane inalterato
 Specifica dei casi d’uso:
esempio 2
 Nome: Registrare un nuovo conto corrente
 Descrizione: Permette ad un addetto conti
correnti di registrare un conto corrente
presso la propria filiale.

Specifica dei casi d’uso:

esempio 2
 Scenario principale di successo:
1. L’addetto richiama la transazione di inserimento nuovo conto
2. Il sistema richiede i codici cliente degli intestatari del conto
3. L’addetto fornisce i codici degli intestatari
4. Il sistema visualizza le anagrafiche corrispondenti, e richiede
le condizioni da applicare al conto
5. L’addetto specifica le condizioni del conto (standard, legate a
convenzione, derogate)
6. Il sistema visualizza le condizioni richieste, e richiede la
selezione delle carte
7. L’addetto seleziona le carte di debito (Bancomat) da
associare al conto
8. Per ogni carta selezionata, il sistema richiede la definizione
dei massimali
9. L’addetto specifica i massimali
Specifica dei casi d’uso:
esempio 2
 Scenario principale di successo:
10. L’addetto seleziona le carte di credito da associare
al conto
11. Per ogni carta selezionata, il sistema richiede la
definizione dei massimali e delle eventuali
modalità di rateazione
12. L’addetto specifica i massimali e le modalità di
rateazione
13. L’addetto richiede la registrazione del conto
14. Il sistema visualizza le informazioni acquisite, e
chiede conferma
15. L’addetto conferma
16. Il sistema visualizza il numero di conto corrente
assegnato

Specifica dei casi d’uso:

esempio 2
 Scenario secondari:
 Se l’addetto non conosce i codici, richiama la
transazione di ricerca anagrafica (che
corrisponde al caso d’uso Ricercare anagrafica)
 Se il sistema non riconosce un codice cliente, o
se fornisce in risposta una anagrafica
imprevista, l’addetto può correggere il codice
cliente, o terminare il caso d’uso annullando
l’inserimento
Specifica dei casi d’uso:
esempio 2
 Scenario secondari:
 Se l’addetto non conosce la convenzione da
associare al conto per definire le condizioni,
richiama la transazione di ricerca convenzione
(caso d’uso Ricercare convenzione)
 Se l’addetto richiede l’annullamento, il sistema
elimina le informazioni acquisite, ma
memorizza il tentativo di registrazione con il
codice dell’addetto
 L’addetto richiama la transazione di
inserimento nuovo conto, specificando che si
tratta di un conto relativo ad un dipendente
della banca

Specifica dei casi d’uso:

esempio 2
 Pre-condizione:
 Il conto corrente non deve ancora esistere; gli
intestatari del conto devono essere già censiti
 Post-condizione:
 Di successo: Il conto corrente deve essere
aperto, con riferimento ad intestatari censiti in
anagrafica.
 Di Fallimento: Il conto corrente non deve
esistere. Il tentativo di registrazione deve
essere stato memorizzato
Diagrammi UML dei casi
d’uso
 È un diagramma per la rappresentazione
dei casi d’uso
 Raffigura il sistema, gli attori partecipanti
ai casi d’uso, i casi d’uso e le relazioni
(associazioni) tra attori e casi d’uso

Diagrammi UML dei casi

d’uso
 Il sistema è rappresentato con un rettangolo
 Gli attori sono rappresentati graficamente nel
diagramma da un'icona che rappresenta un uomo
stilizzato (stickman).
 Un caso d'uso è rappresentato graficamente come
un'ellisse contenente il nome del caso d'uso

attore caso
d’usoSistema
Relazione tra attori e caso
d’uso
 È l'associazione fondamentale negli Use Case
Diagram
 È rappresentata da una linea tra l’attore ed il caso
d’uso a cui partecipa
 Un attore può essere associato a un qualsiasi
numero di casi d'uso, e viceversa.
 implica uno scambio di messaggi attori e use case
associati

attore caso
d’uso

Riferimenti (oltre i testi

consigliati)
 http://www.analisi-disegno.com/usecases/LineeGu
idaUML-CasiUsoV2.pdf

 http://it.wikipedia.org/wiki/Use_Case_Diagram