Please enable JavaScript.
Coggle requires JavaScript to display documents.
USE CASES diagrammi e template (Use case diagrams (documenta le…
USE CASES
diagrammi e template
Use cases → definizione di requisiti funzionali
requisiti funzionali
catturano il comportamento atteso
di un sistema in termini di
servizi
compiti
funzioni
bene inquadrati nel modello
SRS-232
casi d'uso
pratica
dominante
nel rappresentare r.f.
principalmente nello sviluppo
OO
, ma non solo
danno
struttura e metodo
all'idea di catturare r.f. partendo da
esempi
scenari di interazione e uso
Attori e casi d'uso, il concetto
attore
entità esterna
al sistema che interagisce con esso
può essere
classe di utenti
ruolo che utenti possono svolgere
s/sistema
parte del sistema non ancora sviluppata
trigger temporale
attore
primario
ha goal che richiede supporto del sistema
attore
secondario
sistema ne richiede l'assistenza
caso d'uso
insieme di
interazioni
, finalizzate ad un goal, tra
sistema
almeno un attore esterno al sistema
funzione offerta
dal sistema alla sua interfaccia
caso d'uso
è
avviato
da un attore, con un goal, e si
conclude
quando lo raggiunge
cattura
chi fa cosa
con quale goal
attraverso quali passi
descrive
sequenza di interazioni
tra sistema e attori necessarie a realizzare il servizio richiesto dall'obiettivo
anche sequenze alternative
che raggiungono goal
che falliscono
scenari
sistema trattato in prospettiva
black-box
/funzionale
interazioni includono stimoli e risposte, descritte come percepite dall'esterno
non come il sistema è realizzato
lista completa
di casi d'uso specifica tutti i differenti modi di usare il sistema
definisce tutto il comportamento richiesto dal sistema
delimita lo scope del sistema
Rappresentazione composta
use case diagrams
visione d'insieme
relazioni tra attori e casi d'uso
strutturazione dei casi d'uso
use case templates
specifica testuale dei singoli casi d'uso
mock-ups
info e interazione sull'interfaccia grafica destinata agli utenti
Use case diagrams
documenta le funzionalità offerte dal sistema ad una sua interfaccia
caso d'uso
attore
relazione d'uso
documenta interazione tra attore e sistema
direzionalità
attore interagisce con il caso d'uso
fornendo stimoli
ricevendo risposte
più attori coinvolti in diversi casi d'uso
più attori possono partecipare ad uno stesso caso d'uso
breakdown funzionale vs. dataflow
uno use case diagram
non
documenta flusso dell'informazione
non
descrive relazioni di precedenza tra casi d'uso
relazione di inclusione
svolgimento di un caso include quello di almeno un sottocaso
più per partizionare la complessità che riusare le parti
metafora nella prospettiva dello sviluppatore
dimostrare caso
costo del caso
avanzamento
non documenta la procedura
relazione di estensione
identifica s/casi eseguiti in circostanze speciali
metafora dello sviluppatore
necessarie per completezza, non per dimostrare caso
si hanno:
«includes»
«extends»
«invokes»
«precedes»
relazione di generalizzazione
documenta la relazione di specializzazione e sostituibilità
si applica ad attori e casi d'uso
da usare con giudizio
context & scope
system boundaries
delimita contorni e interfacce di un sottosistema
scope di un caso
sistema
sottosistema
parte funzionale
release
livelli di astrazione
high summary
definisce ambito da analizzare, non è specifica "sufficiente"
summary
visione d'insieme sui casi di livello user-goal
user goal
specifica una interazione
è il livello che conviene dettagliare con template testuali e mock-up
function
specifica un dettaglio dell'interazione che ha qualche particolarità
usualmente non documentato in modo individuale
Use case templates
i singoli casi d'uso sono
documentati in forma testuale
narrativa
non ambigua ma semplice
riferita al linguaggio del
dominio
specifico
meglio se riferita a un
modello
concettuale
esplicito
formalizzato
condiviso
enfasi sul dialogo
di interazione tra sistema e attori
devono abilitare il
coinvolgimento
sia di utenti che di esperti di dominio per
seguire e validare casi d'uso
definire i requisiti
elementi di uno use case template
use case
history
source
level
description
scope
actors
pre-conditions
post-conditions
normal flow
variazioni
alternative flows
riferimenti
requisiti non funzionali
issues
priorità
data di consegna
Mockups
prototipo
delle interfacce grafiche esposte all'utente
struttura di navigazione delle pagine
layout delle singole pagine
enfasi su
informazione e funzionalità
nella interazione tra utente e sistema
astrazione
rispetto ai dettagli del design grafico
perchè usarli?
forniscono coinvolgimento di utenti ed esperti del sistema
diverse finalizzazioni nelle fasi del ciclo di vita
progetto
analisi
test di accettazione
supportato da strumenti
Use cases
non servono a
descrivere
procedure nel flusso
di elaborazione dell'informazione
partizionare
il processo di elaborazione all'interno del sistema
progettare
servono a
discutere/definire
requisiti funzionali
definire le
interfacce
di un sottosistema
partizionare/strutturare
le funzionalità (breakdown)
e anche a
pianificare/monitorare lo sviluppo
pianificare test in prospettiva funzionale
sostenere un piano di usability engineering
specificare condizioni di workload
inoltre
sono facili da mantenere
relazione con le classi del modello concettuale
nel testo degli use case templates