Progettazione concettuale di SI basati su Web

B. Pernici

Sommario

• Requisiti del sistema

• Modelli (progettazione concettuale)– Use case

• Attori, interazione con il sistema

– User experience (UX model)• Navigazione, pagine principali

Specifica dei requisti

• Descrizione del sistema– “Non ambigua”, necessariamente incompleta– Documenti, modelli, record in DB

• Insieme di vincoli (“Il sistema dovrà …”)– Comportamenti– Proprieta’– Testabili (criteri, casi di test)

Tipi di requisti• Funzionali

– Es: “Il sistema produrre un sommario delle vendite settimanali”– “Req. 1 - Il cliente usa la pagina web d’acquisti on line del

produttore per selezionare una configurazione standarad del server, desktop o computer portatile che potrebbe interessargli. Il prezzo viene mostrato”

• Non funzionali– Usabilità– Performance– Robustezza/affidabilità– Sicurezza– Hardware– Deployment

Requisti non funzionali

– Usabilità (es: massimo 4 click per raggiungere una funzionalità, non usare frame, browser qualunque che supporti le tabelle)

– Performance• Es: Tempo massimo per caricare una pagina,

almeno 150 sessioni simultanee

– Robustezza/affidabilità (rispetto a 24/7/52)• 0,9999, oppure down 1 ora alla settimana per

manutenzione

Non funzionali (cont.)

– Sicurezza• A chi e’ accessibile (ruoli, matrice funzioni/ruoli)• Meccanismi: controllo accessi, autenticazionem

crittografia, audit, intrusion detection

– Hardware• Requisiti minimi hw per la realizzazione (rispetto a

architettura)

– Deployment• Come l’applicazione viene consegnata al cliente:

installazione, manutenzione, scalabilità

Collegare modelli e requisti

• Requisiti numerati (es. 1.3.1)

• Ogni elemento nei modelli corrisponde almeno a un requisito– Servono davvero le funzionalità fornite?

• Analizzare impatto dei cambiamenti

• Assegnare priorità ai requisiti

• Risolvere conflitti (le priorità aiutano)

Modellazione concettuale

• Casi d’uso– Passo 1: identificare attori– Passo 2: identificare casi d’uso– Passo 3: disegnare un diagramma dei casi d’uso– Passo 4: documentare i casi d’uso– Passo 5: Scenari– Passo 6: Progettazione concettuale dei dati

(diagramma delle classi)

Identificare attori (passo 1)

• Cliente

• Sistema verifica conti (verifica pagamento)

• Spedizioniere (servizio spedizione)

Passo 2: identificazione casi d’uso

• Servizi

• “verbi” principali nelle descrizioni

• Tabella riassuntiva

Use case (esempi)Requisito Attore Caso d’uso

1 - Il cliente usa la pagina web d’acquisti on line del produttore per selezionare una configurazione standarad del server, desktop o computer portatile che potrebbe interessargli. Il prezzo viene mostrato

Cliente Mostrare Configurazione Computer Standard

…. 5 - Nel back-end viene controllata la solvibilita’ del cliente

Sistema verifica conti

Richiedi pagamento cliente

Passo 3: diagramma dei casi d’uso

• Composizione dei casi d’uso in un unico diagramma

• Relazioni tra casi d’uso:– Include (come cut and paste, riuso)– Extend (funzionalità aggiuntive che possono

essere utilizzate)

• Non indicano sequenza• Non e’ scomposizione funzionale

Passo 3: diagramma dei casi d’uso

Passo 4: Documentazione casi d’uso

• nome• breve descrizione• attori• casi d'uso collegati• precondizioni• postcondizioni• descrizione dettagliata• altri diagrammi

Approx 10 pagine per caso d’uso

Documentazione casi d’uso: modellazione delle attività

principali

• Passo 5: Diagrammi di interazione

– Solo i principali

possono essere anche utilizzati diagrammi di attività

Diagramma di interazione

Activity diagram

Passo 6: modellazione concettuale dei dati• Identificazione delle entita’ principali

• Diagramma delle classi

• Associazioni– Cardinalità– Aggregazione– Composizione (part of)

Modellazione concettuale: UX model

• Primo passo di analisi• UX: user experience• Modellare la navigazione

– Class diagram– A alto livello– Dettagliato

• Storyboard– Esempi di interazione con il sistema

UX – class diagram

• Dati dal punto di vista dell’utente

• Pagine

• Stereotipi (WAE):– Schermo (<<screen>>)– Input form (<<input form>>)– Parti di schermo (<<screen compartment>>)

UX - Diagramma di navigazione• Nomi classi

– Maiuscolo– $ riferimento da qualunque pagina– + serie di pagine

• Attributi– Contenuto pagine

• Metodi– Solo se cambiano stato

• Associazioni– Nomi ruoli (scelte, azioni)– Direzione navigazione

Modellare input utente• Come classe associata a associazione

Modellare input utenteCome classe contenuta

Storyboard

• Mostrare l’interazione su istanze

• Alternative (non esclusive)– Sequenza di schermate (con valori significativi)– Sequence diagrams (tra oggetti)– Collaboration diagrams (tra oggetti)

– Per ogni caso d’uso

Diagrammi di interazione