Web Application Engineering

Analisi del dominio

Cristian Lucchesi

Istituto di Informatica e Telematica - CNR

Analisi del dominio

L'altalena dei Requisiti

L'altalena dei requisiti
altre altalene

Analisi del dominio: approcci

Gli approcci sono suddivisi in tre categorie principali:
approccio informale
nessun modello del sistema viene costruito (uso di un linguaggio informale)
raccolta di informazioni attraverso:
  • riunioni tra gli utenti/committenti ed analisti
  • l'uso di questionari
  • studio di documentazione esistente

si procede attraverso la formulazione e il successivo raffinamento di vari documenti sottoposti a convalida

Analisi del dominio: approcci (cont)

approccio basato sulla prototipazione
il problema viene analizzato ed i requisiti sono compresi grazie all'uso di un prototipo del sistema da parte di cliente ed utenti
approccio basato su modelli concettuali
produce rappresentazioni del dominio applicativo e del sistema

Approcci basati su modelli concettuali

Analisi Strutturata
basata sull'uso di Data Flow Diagrams e Dizionario dei Dati
l'analisi del problema viene eseguita usando lìapproccio della decomposizione delle funzioni - i dati e le relative relazioni sono modellati con linguaggi diversi (es. modello Entità-Relazioni)
Analisi Object-Oriented
l'analisi del problema viene eseguita usando l'approccio della decomposizione in oggetti (entità/ concetti del dominio del problema)
si usano linguaggi di modellazione, es. UML

Modelli concettuali

Analisi tramite modello concettuale

L'analisi del dominio si distingue in tre fasi metodologiche:

Analisi tramite modello concettuale (cont)

Relazione tra fasi metodologiche:

Analisi: concettualizzazione

Studio del dominio del problema per delimitarne i contorni ed evidenziare le realtà di interesse (Requisiti di Contesto)

Problem statement

Regole empiriche per la stesura di un Problem Statement corretto:

Scenari

Nelle agile development si preferisce l'utilizzo della comunicazione verbale con la definizione dei casi d'uso

Caso d'uso

Caso d'uso (cont)

Usare i casi d'uso significa:
  1. individuare chi dovrà utilizzare il sistema
  2. chiedersi quali sono gli obiettivi che si intendono conseguire utilizzando il sistema
  3. approfondire, in termini di descrizione di scenari concreti, ciascuna modalità di utilizzo, chiarendo:
    • il modo in cui inizia
    • le risposte che l'utilizzatore si attende dal sistema
    • la sequenza di passi con cui l'interazione si svolge
    • eventuali altri soggetti (esterni al sistema) coinvolti

Struttura dei casi d'uso

Non esiste un modo univoco per descrivere i casi d'uso, tipicamente si tratta di una descrizione testuale dei passi compiuti dall'utente
Molto spesso per i casi d'uso di utilizza una struttura del tipo:

Esempio di caso d'uso

Titolo: validazione PIN del bancomat
Sommario: il sistema controlla e convalida il PIN del client
Attori: cliente ATM
Precondizioni: il sistema è in attesa e mostra sul display un messaggio di benvenuto
Descrizione:
  1. l'utente inserisce il bancomat
  2. il sistema riconosce il bancomat e ne legge il numero
  3. il sistema chiede il PIN
  4. il client inserisce il PIN
  5. il sistema controlla la data di scadenza e se la Card risulta in stato di PrelievoContanti, di smarrita o rubata

Esempio di caso d'uso cont

Descrizione (cont.):
  1. se la Card è valida, il sistema controlla se il PIN è corretto
  2. se il PIN è corretto, il sistema controlla quali conti correnti sono accessibili
  3. il sistema mostra al cliente le possibili transazioni (menu): prelievo, saldo, lista movimenti o trasferimento
Alternative:
  1. il sistema non riconosce la Card, la Card viene espulsa
  2. il sistema determina che la Card è scaduta: la Card viene confiscata
  3. il sistema determina che la Card risulta smarrita o rubata: la Card viene confiscata;
  4. il cliente digita un PIN non corretto...
  5. ...
Postcondizioni il PIN è stato validato

Casi d'uso, analisi e design

Utilizzare i casi d'uso permette di:

Prototipi e casi d'uso

On Software "Engineering"

An oldie but a goodie, courtesy of Jeroen van den Bos:
A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?"
The man below says: "Yes you're in a hot air balloon, hovering 30 feet above this field."
"You must be a software developer," says the balloonist.
"I am," replies the man. "How did you know?"
"Well," says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone."
The man below says, "You must work in business as a manager." "I do," replies the balloonist, "but how did you know?"
"Well," says the man, "you don't know where you are or where you are going, but you expect me to be able to help. You're in the same position you were before we met but now it's my fault."

Riferimenti

The end

Grazie
per
l'attenzione