Basi di Dati. Programmazione e gestione di sistemi telematici

Transcript

1 Basi di Dati. Programmazione e gestione di sistemi telematici Coordinatore: Prof. Paolo Nesi Docenti: Prof. Paolo Nesi Dr.sa Michela Paolucci Dr. Emanuele Bellini

2 UML La prima versione ufficiale risale al 1997: UML Unified Modeling Language È un liguaggio universale per la descrizione dei modelli e dei sitemi progettati, valido ed accessibile sia agli sviluppatori di software che agli utenti finali L'UML è, dunque, un metodo per descrivere l'architettura di un sistema in dettaglio

3 UML: tipi di diagrammi Requisiti di Sistema e Diagrammi di casi d'uso Diagrammi di classe, degli oggetti e di package Diagrammi di interazione: sequenza e collaborazione Diagrammi fisici: componenti e deployment Diagrammi di stato Diagrammi di attività

4 Requisiti di sistema (1) Funzionali: elenco delle funzionalità che il sistema deve avere Cosa deve fare il sistema? Requisiti sui dati che il sistema deve usare Il sistema deve usare fonti dati o destinazioni dati particolari? C'è un modello dati che specifica entità e relazioni per questo sistema? Per quanto tempo questo tipo di dati deve essere mantenuto negli archivi? Per quanto tempo deve essere visibile agli utenti? Interoperabilità: studio delle relazioni e sulle interfacce di questo sistema con sistemi esterni (se presenti) Quali altri sistemi devono interagire con il sistema? Quali sono le caratteristiche di interoperabilità di questi sistemi? Dobbiamo sapere cosa abbiamo mandato e ricevuto attraverso un'interfaccia?

5 Requisiti di sistema (2) Responsabilità: servono per stabilire chi ha la responsabilità di eseguire specifiche funzioni del sistema Chi ha la responsabilità di fare [una azione]? Funzionali: elenco delle funzionalità che il sistema deve avere Cosa deve fare il sistema? Requisiti sui dati che il sistema deve usare Il sistema deve usare fonti dati o destinazioni dati particolari? C'è un modello dati che specifica entità e relazioni per questo sistema? Per quanto tempo questo tipo di dati deve essere mantenuto negli archivi? Per quanto tempo deve essere visibile agli utenti? Interoperabilità: studio delle relazioni e sulle interfacce di questo sistema con sistemi esterni (se presenti) Quali altri sistemi devono interagire con il sistema? Quali sono le caratteristiche di interoperabilità di questi sistemi? Dobbiamo sapere cosa abbiamo mandato e ricevuto attraverso un'interfaccia?

6 Requisiti di sistema (3) Responsabilità: servono per stabilire chi ha la responsabilità di eseguire specifiche funzioni del sistema Chi ha la responsabilità di fare [una azione]? Disponibilità: riguardano la disponibilità del sistema per l'utilizzo operativo Quando deve essere disponibile il sistema? In quali giorni? In quali orari? Prestazioni del sistema: Quali sono le funzioni importanti dal punto di vista delle prestazioni e che tempo di risposta è ammissibile per questo tipo di funzioni del sistema? Carichi (capacità): riguardano i volumi di dati da gestire e i picchi che il sistema deve trattare Quanti oggetti (significativi per il sistema in esame) devono essere gestiti entro un certo periodo (specificare l unità di misura temporale)? Il sistema deve gestire dei picchi? Quanto durano? Scalabilità: riguardano le previsioni di crescita del volume di dati che il sistema deve gestire Affidabilità: servono per stabilire la probabilità che il sistema funzioni senza interruzioni per un determinato periodo di tempo. Cosa può accadere in caso di malfunzionamento?

7 Requisiti di sistema (4) Installazione: elenco delle funzionalità necessarie per l'installazione del sistema e per la migrazione dei dati. Che livello di competenze deve avere l'installatore del sistema? È necessaria una conversione di dati? Devono essere scritte procedure per la conversione? È necessario un backup manuale prima dell'installazione? Come devono essere gestiti gli aggiornamenti al sistema? Portabilità del sistema in altri ambienti hardware e software Ci si aspetta che il sistema venga utilizzato per molti anni? Il sistema deve essere portabile in altre piattaforme? Quali? L'utente dovrà poter accedere al sistema tramite altri dispositivi? Quali? Quali versioni dei browser web più comuni deve gestire il sistema? Leggi e normative: riguardano le leggi, nazionali ed internazionali, da rispettare Esistono leggi nazionali o internazionali rilevanti per questo tipo di sistema? Quali sono i requisiti imposti dalla legge? Esistono dei copyright da rispettare?

8 Requisiti di sistema (5) Tecnologie da usare Dobbiamo vincolare le scelte tecnologiche per essere compatibili con i sistemi esistenti? Dobbiamo usare (o evitare di usare) tecnologie specifiche? Aspetto e stile Come deve apparire il sistema ai suoi utenti? Come deve essere percepito? Il sistema deve essere conforme alle linee stilistiche aziendali, ai logo, ecc? Facilità d'uso: caratteristiche relative alla facilità con cui il sistema può essere usato dagli utenti previsti Quali sono le funzioni più complesse da usare? Tra queste, quali sono le più frequenti? Quanto è previsto che l'utente si ricordi da una volta all'altra in cui utilizza il sistema? Di quanto feedback ha bisogno l'utente? Personalizzazione: si basano sull'adattabilità del sistema alle preferenze personali di ogni utente o organizzazione Il sistema deve essere configurabile da ogni utente secondo le sue preferenze personali? Il sistema deve essere configurabile da parte di ogni organizzazione che lo adotta?

9 Requisiti di sistema (6) Internazionalizzazione: lingue previste per il sistema Accessibilità del sistema per persone con disabilità fisiche o cognitive (In alcuni paesi, possono essere regolamentati da leggi) Esistono standard sull'accessibilità da rispettare, per questo tipo di sistemi? Requisiti di protezione accessi: studio dei possibili effetti in termini di sicurezza (perdita, danno economico o fisico) di un utilizzo improprio del sistema Chi è autorizzato ad accedere al sistema? Tutte le funzioni sono accessibili a tutti? Bisogna gestire diversi profili utente? Requisiti di riservatezza di dati personali e dell'organizzazione Esistono dati sensibili? Dobbiamo informare gli utenti su come gestiamo i loro dati? Dobbiamo inserire cookie nei computer dei nostri utenti?

10 Requisiti di sistema (7) Tempi di progetto: elenco di date e durate significative per il progetto Budget di progetto: riguardano le risorse economiche disponibili per il progetto Documentazione: Che tipo di documentazione minima e in che lingua deve essere fornita per gli utenti previsti? Chi deve manutenere il sistema e che tipo di documentazione sarà necessaria per la manutenzione?

11 Introduzione ai casi d uso Rappresentano i modi in cui un sistema può essere usato. In pratica si tratta di descrivere in forma testuale l'interazione fra il sistema ed uno o più attori che richiedono un servizio Con il termine attore si indica una qualsiasi entità (una persona reale, un altro sistema o una sua componente) che ha il diritto o la possibilità di entrare in contatto con il sistema software Ad ogni caso d uso partecipa almeno un attore Attore Caso d uso

12 ESEMPIO: cellulare Punto di vista del cliente finale (attore=client): Telefonare Rispondere ad una chiamata Inviare messaggi Memorizzare numeri Punto di viste del progettista (attore=progettista): Trasmissione/ricezione del segnale Batteria Tipo di I/O

13 Casi d uso I casi d uso devono essere descritti sotto forma di interazione (dialogo) tra gli attori ed il sistema L utente richiede l elenco dei servizi forniti Il sistema propone I servizi Il cliente sceglie il servizio voluto Il sistema lo esplica NOTA: l attenzione va rivolta allínterazione tra sistema ed attori non alle parti interne del sistema che vegono coinvolte

14 Requisiti e casi d uso Ogni requisito può dare origine a più casi d uso Ogni caso d uso può soddisfare più di un requisito Per ogni caso d uso esiste un interazione tra azioen e sistema che avviene (per gli attori umani) attraverso l interfaccia utente

15 Caso d uso Inizia con una azione inviata dall attore al sistema Il sistema risponde effettuando a sua volta una serie di azioni Gli attori possono effettuare altre scelte ed inviare altri messaggi al sistema Il caso d uso termina quando sono state fornite tutte le informazioni necessarie al sistema per soddisfare l obiettivo dell attore

16 Identificazione dei casi d uso: Identificare gli attori (utilizzatori) del sistema Per ogni attore individuare le modalità (casi d uso) con cui deve utilizzare il sistema partendo dalgi obiettivi che deve raggiungere Chiarire, per ogni caso d uso, qual è il modo con cui inizia l attività, le risposte che l attore si aspetta dal sistema, la sequenza di passi con cui l interazione si svolge, elenco di altri attori eventualmente coinvolti, etc.

17 Casi d uso: utilità Serve come: Base di partenza per la progettazione del sistema Bozza per il futuro manuale dell utente Input per I test da effettuare per la validazione del sistema

18 Esmpio: apertura conto corrente Scenario di base: Il cliente si presente in banca per aprire un nuovo c/c L addetto riceve il cliente e fornisce spiegazioni Il cliente accetta e fornisce I propri dati L addetto verifica se il cliente è censito in anagrafica L addetto crea il nuovo c/c L addetto segnala il numero di conto al cliente Varianti: (a) Se il cliente non accetta le condizioni, il caso dúso termina (b) Se il conto va intestato a più persone, vanno forniti tutti i dati (c) Se il cliente non è censito, l addetto provvede a registrarlo, richiede la firma

19 Caso d uso schema di base Id Obiettivo Descrizione del risultato che l attore si attende da questa particolare modalità di utilizzo del sistema Pre-Condizioni Ciò che deve essere vero prima che inizi il caso d uso Scenario di base: Lista delle interazioni tra l attore ed il sistema Post-Condizioni per Successo Ciò che deve essere vero dopo che il caso d uso si è concluso con il raggiungimento del risultato atteso Post-Condizioni per Fallimento Ciò che deve essere vero dopo che il caso d uso si è concluso senza il raggiungimento del risultato atteso

20 Caso d uso (estensione) Estensione del caso d uso Fornire Id del caso d uso base che può essere esteso dal presente caso d uso, e punto di estensione (definito nel caso d uso base ) a cui il presente caso d uso si andrà ad agganciare Specializzazione del caso d uso Fornire Id del caso d uso generico del quale il presente caso d uso costituisce una specializzazione

21 Basi di Dati. Programmazione e gestione di sistemi telematici Prof. Paolo Nesi lab. DSI-DISIT nesi@dsi.unifi.it Dr.sa. Michela Paolucci paolucci@dsi.unifi.it Dr. Emanuele Bellini bellini@rinascimento-digitale.it