Metodologia Classica di Progettazione delle Basi di Dati

Transcript

1 Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1

2 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore fonte di fallimento Software La Realtà di interesse è nota, in questo contesto, come Universo del Discorso Realtà Uno Schema, basato su un Modello, è prodotto durante lo svolgimento di alcune Attività Metodologiche Descritta da un insieme di Schemi basati su uno o più modelli Schemi Software Metodologia DB 2

3 Il Software Base Dati Altri Linguaggi Applicativi (Programmi) VISTE Cosa mettere? SQL SCHEMA LOGICO Cosa mettere? SCHEMA FISICO/INTERNO Architettura generale di una base dati Cosa mettere? Chi dice cosa mettere? Metodologia DB 3

4 Problemi E necessario chiedersi quali sono gli applicativi (chiamati anche funzioni, programmi, transazioni) da sviluppare: quindi, è necessario chiedersi quali sono le informazioni che tali applicativi trattano E necessario mettere insieme tutte le informazioni di cui necessitano tutti gli applicativi E necessario considerare le prestazioni in termini di carico di lavoro (ad esempio, quante volte un applicativo viene eseguito per giorno/minuto) E necessario considerare la quantità delle informazioni trattate Metodologia DB 4

5 Approccio SCHEMA ESTERNO integrare SCHEMA CONCETTUALE trasformare SCHEMI LOGICO/INTERNO Requisiti del singolo applicativo riguardanti cosa devono fare e non fare gli applicativi Requisiti di un qualsiasi applicativo riguardanti cosa devono fare e non fare gli applicativi Requisiti legati a prestazioni, occupazione di disco etc. A chi serve il database A cosa serve il database Metodologia DB 5

6 Problemi da affrontare Da dove si ottengono i requisiti? Fonti dei requisiti Mission statement Cosa sono esattamente i requisiti? Proprietà dei requisiti Come si rappresentano i requisiti? Modelli dei requisiti Come si ottengono i requisiti? Come si trasformano i requisiti nella corrispondente base dati? (Ovvero come è possibile mantenere la rispondenza della base di dati ai requisiti espressi.) Metodologie Modelli del software Metodologia DB 6

7 Fonti dei Requisiti Il software non esiste ancora cioè si tratta di un nuovo software Mission statement (Contesto) Il software (un software simile) già esiste e si tratta di modificarlo Mission statement (Contesto) Documentazione sul software attuale In un contesto aziendale: osservazione diretta, interviste e questionari, moduli Il software non esiste ma, ciò che dovrebbe fare tale software, già viene fatto (più o meno) in altro modo Mission statement (Contesto) Documentazione sull attuale modo di fare In un contesto aziendale: osservazione diretta, interviste e questionari, moduli Metodologia DB 7

8 Gli Acquisti OnLine: qualche Mission Statement 1. Il software degli Acquisti OnLine deve permettere la definizione e l acquisizione degli ordini da parte dei clienti dell azienda. 2. Il software degli Acquisti OnLine deve permettere la definizione e l acquisizione degli ordini da parte dei clienti dell azienda, permettendo al cliente di visualizzare, in ogni momento, lo stato dei propri ordini. 3. Il software degli Acquisti OnLine deve permettere la definizione e l acquisizione degli ordini da parte dei clienti dell azienda, permettendo al cliente di visualizzare la reale disponibilità di merce a magazzino. Metodologia DB 8

9 Gli Acquisti OnLine: una fonte dei requisiti La nostra azienda produce computer e vuole offrire la possibilità di acquistare i computer via Internet. Il cliente può selezionare un computer sulla pagina web del produttore. I computer sono classificati in server, desktop e portatili. Il cliente può selezionare una configurazione standard o può costruire interattivamente la configurazione desiderata. I componenti configurabili (come memorie) sono presentati in una lista di opzioni disponibili. Per ogni configurazione, il cliente può valutarne il costo. Il cliente può scegliere di ordinare il computer direttamente online oppure può richiedere un incontro via attraverso un indirizzo mostrato sulla appropriata pagina web con un venditore prima di confermare l'ordine, per ottenere maggiori spiegazioni sui dettagli dell'ordine, una negoziazione del costo, etc. Per ordinare, il cliente deve fornire le informazioni per la consegna e per il pagamento. I modi di pagamento accettati sono: carta di credito e assegno. Una volta che l'ordine è stato inviato, il sistema manda un di conferma al cliente con i dettagli dell'ordine. Il cliente, mentre attende l'arrivo del computer, può controllare on-line lo stato dell'ordine in ogni momento. Il trattamento di back-end consiste nei passi di: verifica della solvibilità del cliente, richiesta al magazzino della configurazione ordinata, stampa di una fattura, e richiesta al magazzino di consegnare il computer al cliente. Metodologia DB 9

10 Esempi di Requisiti 1 Il software (database) deve poter memorizzare tutte le informazioni su ordini effettuati dai clienti 2 Il software (database) deve poter memorizzare tutte le informazioni su configurazioni costruite dai clienti 3 Il software deve poter permettere la selezione da parte dei clienti dei computer a magazzino 4 Il software deve poter permettere la selezione dei computer venduti dal produttore 5 Il software deve effettuare il riordino automatico delle componenti una volta si scenda sotto certi valori di soglia 6 Il software deve poter permettere ad un cliente di contattare un venditore prima di dare seguito all ordine stesso 7 Il software deve trattare mediamente 1000 clienti/giorno contemporaneamente connessi senza apprezzabile diminuzione dei tempi di risposta 8 Il cliente richiede via attraverso un indirizzo mostrato sulla appropriata pagina web un contatto con il venditore 9 Il numero medio di ordini è Il numero di clienti è mediamente La data d acquisto deve essere lunga 5 Metodologia DB 10

11 Si può sviluppare un software/database? Ambiguo (1) Cosa s intende per ordine? Un ordine può considerare un solo computer? Può considerare più computer dello stesso tipo o di tipo distinto? (2) Cosa s intende per cliente? Incompleto (2) Come dovrebbero essere trattati gli ordini di configurazioni costruite dai clienti? Se queste non sono computer (ad esempio, si ordina un insieme di componenti)? Metodologia DB 11

12 Si può sviluppare un software/database? Non necessariamente consistente (3,4) Computer non è sempre la stessa cosa nel testo quindi il suo uso deve essere differenziato per non creare delle inconsistenze (6,1) Un ordine trattato come (6) per cui il cliente chiede spiegazioni ad un venditore è un ordine nel senso del requisito (1)? Non necessariamente condiviso (5) Il problema posto riguarda esclusivamente la gestione dell acquisizione degli ordini dei clienti oppure riguarda anche un controllo a tempo d acquisizione degli ordini della disponibilità a magazzino? Metodologia DB 12

13 Si può sviluppare un software/database? Indica già una soluzione software ed è quindi poco stabile Al posto di (8) sarebbe meglio usare un form piuttosto che un indirizzo mostrato su una pagina? Al posto di (11) sarebbe meglio indicare una forma della data Tutto o parte Se fosse necessario scartare gli ordini che riguardano configurazioni che non sono computer, quanto potrebbe costare? Quale sarebbe il beneficio? Quale sarebbe il rischio nel sviluppare una tale funzionalità, se non è mai stata sviluppata per altre aziende? Metodologia DB 13

14 Caratteristiche di un Requisito Condiviso Non ambiguo Completo Non in conflitto Possedere un grado di priorità Possedere un grado di stabilità Possedere un grado di rischio Verificabile Manutenibile Tracciabile Traceability (IEEE) : the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessorsuccessor or master-subordinate relationship to one another Traceability (ISO 8402) : is the ability to trace the history, application or location of an entity by means of recorded identifications Metodologia DB 14

15 Conclusione Chi descrive i requisiti non li domina completamente ovvero tende a non evidenziare oppure a sottovalutare aspetti riguardanti la realtà cui si riferisce; talvolta non ha neppure una chiara visione del mission statement oppure non è in accordo con tale mission statement Per sviluppare adeguatamente un software, è necessario: Sapere esattamente cosa dovrebbe fare il software Definire tutti gli aspetti impliciti Eliminare ogni ambiguità anche solo potenziale Considerare il cambiamento della realtà esistente o descritta Una risposta possibile a tali problemi è Usare modelli e linguaggi per la rappresentazione dei requisiti e del software Disporre di un modo formalizzato per passare dalla rappresentazione dei requisiti ad una rappresentazione del software Metodologia DB 15

16 Perché usare Modelli? I modelli sono utili per dominare la complessità della realtà mettendo in evidenza le parti di interesse: dominare significa poter analizzare e comprendere la realtà d interesse Il costo (compresa la manutenzione) generato passando attraverso l uso di modelli è spesso ampiamente inferiore al costo di sperimentare direttamente possibili soluzioni Esempi: simulatori di volo basati su modelli del volo simulatori di centrali nucleari basati su modelli delle reazioni nucleari modelli econometrici modelli del software, prototipi Metodologia DB 16

17 Caratteristiche di un Modello Un modello è un insieme di concetti necessari per analizzare la realtà d interesse In questo contesto, un modello è necessario per costruire uno schema Un modello è descritto in un qualche linguaggio (ad esempio le varie proposte sintattiche per EA) Un modello può essere più o meno formale: nei modelli del software, formale significa essere verificabile formalmente (logica) o eseguibile Metodologia DB 17

18 Caratteristiche di uno Schema Uno schema descrive la realtà d interesse (anche nota come Universo del Discorso) usando gli elementi propri di un modello Uno schema può essere più o meno preciso (astratto) Uno schema può essere errato concettualmente o errato sintatticamente Uno schema può essere incompleto Uno schema è uno strumento di comunicazione: i suoi utenti devono condividerne il significato ovvero i significati Metodologia DB 18

19 Quali e Quanti Modelli? Due principali categorie: Modelli per i Requisiti un requisito è un asserzione che deve essere garantita (fornita, soddisfatta) dal software sviluppato un modello dei requisiti permette di specificare (schematizzare) un insieme di requisiti i modelli dei requisiti si ripartiscono normalmente sulla base della tipologia dei requisiti Modelli per il Software tali modelli sono tipicamente distinti per tipologia di software o per aspetto del software modelli dei dati, per applicazioni real-time etc. modelli della dinamica, della struttura, dell architettura etc. Metodologia DB 19

20 Tipologie di Requisito I requisiti non sono tutti uguali ma devono essere classificati onde poter essere usati efficacemente per la progettazione del software: funzionali (indicano cosa deve fare (o non fare) il software e con quali elementi) funzionalità (talvolta anche funzionali), comportamento informazioni (o anche informativi) struttura vincoli architetturali logici non funzionali vincoli sulle prestazioni vincoli politici e legali vincoli sulle piattaforme HW/SW Etc. Metodologia DB 20

21 Metodologia Una metodologia consiste nella definizione di una serie di attività e della loro sequenza al fine di: determinare a partire da un insieme di fonti e rappresentare in modo sufficientemente preciso i requisiti del software garantire, il più possibile, la rispondenza del software sviluppato ai requisiti gestire le attività e le risorse necessarie al loro corretto svolgimento (persone, tempi, costi) In aggiunta, una metodologia dovrebbe prevedere il cambiamento ed agevolarne la gestione. Metodologia DB 21

22 Attività Metodologiche Generiche per lo Sviluppo del Software (Ri) Progettazione dei processi di business Determinazione dei requisiti Specifica del requisiti Progetto Implementazione Testing (Verifica e Validazione) Manutenzione Project Management Metodologia DB 22

23 Sintesi Metodologie Modelli requisiti Specifica dei requisiti Modelli software Specifica del software Schema concettuale Schema logico Metodologia DB 23