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
 Identificare i Casi d'uso
 e produrre lo Use Case Diagram
Come identificare i casi d’uso
Per un sistema già esistente:

manuale di utilizzo (se disponibile e aggiornato,
ossia conforme a quanto il sistema effettivamente
fa)

intervistando gli utilizzatori

attraverso l'utilizzo diretto del sistema stesso.

Come identificare i casi d’uso

Per un sistema nuovo o per un progetto di
evoluzione di un sistema esistente

Rilevare i requisisti attraverso il dialogo con il

committente e/o attraverso l'esame della
documentazione iniziale disponibile per il progetto

Identificare tutte le tipologie di utilizzatori del

sistema (esseri umani o altri sistemi)
• Costituiscono attori primari candidati
Come identificare i casi d’uso
Per un sistema nuovo o per un progetto di
evoluzione di un sistema esistente
(continua)
Per ogni attore primario candidato, rilevare in quale
modo può o deve utilizzare il sistema, partendo
dagli obiettivi che deve raggiungere
• Ad ogni modalità di utilizzo può corrispondere un
caso d'uso.
Per ogni caso d'uso, descrivere lo scenario base e
le principali varianti a tale scenario.
• possono emergere necessità di interazione del
sistema con altri soggetti (esseri umani o altri
sistemi), che verranno rappresentati nel modello
come attori secondari.

Relazione tra requisiti e casi

d'uso (1)
I requisiti costituiscono il punto di partenza
per l'individuazione dei casi d'uso.
Un caso d’uso può essere associato a più
requisiti funzionali e non funzionali
Un requisito funzionale può dare origine a più
casi d’uso.
I casi d'uso costituiscono uno strumento
estremamente efficace ed efficiente per
portare alla luce nuovi requisiti non ancora
emersi, e per chiarire requisiti ambigui,
generici o in conflitto tra loro
Relazione tra requisiti e casi
d'uso (2)
L'efficacia dei casi d'uso per la scoperta dei
requisiti è legata al dialogo tra
analista/progettista e committente:
vengono analizzati per ogni caso d'uso gli scenari
concreti di operatività degli utilizzatori nei confronti
del sistema, le sequenze di passi, le varianti e le
eccezioni.
Il committente esprime feedback sugli
scenari concreti ipotizzati da chi
analizza/progetta
si chiariscono requisiti esistenti o ne specificano di
nuovi

Relazione tra requisiti e casi

d'uso (3)
A fine dialogo tra committente ed
analista/progettista:
chiarimento degli scenari
versione concordata del caso d'uso
elenco di requisiti più dettagliato e con minori
ambiguità
I casi d'uso concordati costituiscono, a tutti
gli effetti, dei requisiti concordati per il
sistema da sviluppare
Sono il riferimento principale le successive fasi del
ciclo di vita del sistema
Casi d'uso e transazioni
informatiche (1)
Un caso d’uso può corrispondere a più
transazioni informatiche che il sistema deve
eseguire per produrre il comportamento ed i
risultati attesi
Il caso d'uso viene definito a partire dalla
visione esterna del sistema di uno specifico
attore primario, per il quale costituisce una
particolare modalità di utilizzo.
La definizione del caso d'uso deve essere
completa, indipendentemente dal fatto che il
sistema per svolgerlo debba effettuare una o
più transazioni (magari in momenti diversi)

Casi d'uso e transazioni

informatiche (2)
Ad esempio, nel caso del sistema di commercio
elettronico, "Acquistare un prodotto" è un caso d'uso
per l'attore "Cliente", che si conclude, in caso di
successo, con l'arrivo a casa della merce ordinata,
l'addebito dell'importo corretto sulla carta di credito
ecc.
Per raggiungere tale risultato, al sistema sarà
necessario effettuare certamente più transazioni, in
tempi diversi, con il coinvolgimento probabile di
diverse funzioni organizzative interne
Sarebbe però sbagliato definire ciascuna di queste
transazioni come un caso d'uso a sé stante
Se si definisse un caso d'uso per ognuna delle
transazioni interne al sistema si perderebbe la
visione complessiva delle azioni da effettuare per
fornire le risposte necessarie alla richiesta dell'attore
Casi d'uso e Sistema di
riferimento (1)
Il sistema di riferimento è l'entità i cui utilizzi
vengono descritti dall'insieme dei casi d'uso
Un insieme completo di casi d'uso descrive in
modo completo gli utilizzi del sistema, ossia
dal punto di vista “esterno” degli attori che
interagiscono con esso, senza rivelare la
struttura interna del sistema
Si rappresenta con un rettangolo.

Progettazione di
Sistemi Informativi

Diagrammi UML delle attività

Diagrammi UML delle attività
 Servono a descrivere i processi aziendali
 Definiscono le azioni da svolgere per
realizzare una data funzionalità di un
sistema
 Ad ogni Use Case dovrebbe corrispondere
un Activity Diagram
 Sono simili ai diagrammi di flusso con la
differenza fondamentale che supportano
anche l’elaborazione parallela

Diagrammi UML delle attività

 Un Activity Diagram definisce una serie di
azioni e flussi, le relazioni tra loro, chi è
responsabile per la singola azione ed i
punti di decisione.
 Un diagramma delle attività è composto da
azioni (e non attività)
 Un azione ha un solo flusso in entrata ed
un solo flusso in uscita
 Le azioni possono essere divise in sotto-
attività (specificate da un opportuno “sotto-
diagramma” delle attività)
Azione
 Un’azione rappresenta una “cosa da fare”
che deve essere svolta all'interno della
attività/funzione/processo (intero Activity
Diagram)
 È rappresentata da un rettangolo smussato
con una descrizione dell‘azione.

Flusso
 Il flusso è rappresentato tramite delle frecce
orientate, che indicano la sequenza temporale con
cui devono essere effettuate le diverse azioni.
 È previsto un simbolo per indicare l'inizio del
flusso ed un altro per indicarne il termine
Comportamento condizionale
(1)
 Nel caso le azioni siano alternative, svolte o
meno rispetto ad una scelta, si ha un
punto di decisione
 È rappresentato da dei rombi da cui
partono i flussi alternativi
 Un Branch, o punto di decisione, ha un
flusso entrante e più di uno uscente, con
condizioni mutuamente esclusive
 I flussi uscenti sono contraddistinti da
guardie, ossi condizioni booleane racchiuse
da parentesi quadre

Comportamento condizionale
(2)

 Se le condizioni sono più di due, devono

comunque essere mutamente esclusive:non è
possibile che più di una è valida (comportamento
ambiguo) o nessuna (comportamento bloccato)
 Comportamento condizionale
(3)
 Un Branch, o punto di decisione, è seguito
da un Merge che ha più flussi entranti ed
uno uscente
 Il Merge termina il blocco condizionale
aperto dal Branch

Comportamento parallelo
(1)
 Le azioni possono essere anche effettuate
in parallelo
 Il punto di divisione (fork) è rappresentato
da frecce divergenti rispetto ad un
segmento
 Comportamento parallelo
(2)
 Ad ogni punto di divisione corrisponde un punto di
ricongiungimento del flusso (join)
 Il punto di ricongiungimento è rappresentato da un
segmento su cui le frecce si ricongiungono
 Una join implica una sincronizzazione dei flussi
entranti

Esempio
Ricevi
Ordine
Fork
Branch

Azione
Soddisfa Invia
Ordine conto

[ordine rapido] [else]

Spedizione
24 h
Spedizione
standard
Ricevi
Pagamento
Flusso

Chiudi Ordine
Join
Merge
Diagrammi UML delle attività
 Un Activity Diagram definisce una serie di azioni e
flussi, le relazioni tra loro, chi è responsabile per la
singola azione ed i punti di decisione.
 Un diagramma delle attività è composto da azioni
(e non attività)
 Un azione ha un solo flusso in entrata ed un solo
flusso in uscita
 Le azioni possono essere divise in sotto-attività
(specificate da un opportuno “sotto-diagramma”
delle attività)

Scomposizione di un’azione
(1)
 Le azioni possono essere divise in sotto-attività
Scomposizione di un’azione
(1)
Ricevi
Ordine

Soddisfa Ordine Invia

conto

Spedizione ordine
[else]
[ordine rapido]

Spedizione Spedizione Ricevi

24 h standard Pagamento

Chiudi Ordine

Sottoattività

Scomposizione di un’azione
(3)
 L’inserimento di uno stato iniziale ed uno stato
finale consentono di disaccoppiare
completamente l’attività Spedizione rispetto al
diagramma complessivo
 In un diagramma ad alto livello potrebbe essere
indicata soltanto l’attività Spedizione senza
esplicitare il sottodiagramma
 E’ possibile specificare input ed output al
sottodiagramma
Partizioni (1)
 I diagrammi delle attività documentano cosa
accade, ma non dicono chi fa cosa
 Non è chiaro quale parte dell’organizzazione
esegue (è responsabile) di una azione
 Per indicare chi svolge parte dell’attività si usano
le partizioni (o swimlanes )
 Si struttura il diagramma in corsie verticali,
separate da linee continue, in cui è indicato il
responsabile delle azioni della corsia

Partizioni (2)
Magazzino Servizio Contabilit
Clienti à

Ogni azione deve

Titolare della Ricevi essere contenuta in
responsabilità Ordine
una singola swimlane

Soddisfa Invia Le linee di flusso

Ordine conto
possono
attraversare le
linee verticali di
Spedizione Ricevi demarcazione
24 h Pagamento delle corsie

swimlane Chiudi Ordine

Esercizio
Descrivere il processo di richiesta di una carta tecnica
mediante un diagramma di attività:
Le amministrazioni provinciali hanno in gestione la cartografia
tecnica regionale nelle scale 1:5.000, 1:10.000 ed 1:25.000
nei formati cartaceo o elettronico.
Gli utenti possono richiedere copia di queste cartografie,
mediante una fotocopia per il formato cartaceo o una
“plottata” per il formato elettronico.
L’addetto dell’amministrazione provinciale riceve la richiesta,
verifica l’effettiva disponibilità della carta richiesta, fornisce
all’utente gli estremi per il pagamento della quota
corrispondente all’operazione, ed una volta avuta conferma
dell’effettuazione del pagamento, predispone la copia della
cartografia.
La quota da pagare è diversa a seconda che la richiesta
provenga da un privato cittadino, da un tecnico professionista
o da una pubblica amministrazione.