La Metodologia adottata nel Corso

Transcript

1 La Metodologia adottata nel Corso 1 Mission Statement + Glossario + Lista Funzionalià 3 Descrizione 6 Funzionalità 2 Schema 4 Schema 5 concettuale Logico EA Relazionale Codice Transazioni In PL/SQL Schema Fisico 7 Architettura: basedati centralizzata Verifica & Validazione 1 2,3 4 5,6 Determinazione requisiti Specifica dei requisiti Progetto Implementazione Nei rettangoli, sono indicati i prodotti delle attività metodologiche. Metodologia DB 1

2 Acquisiti On Line: Mission Statement 1. Il software degli acquisti on line deve poter permettere di acquisire gli ordini effettuati dai clienti, permettendo agli stessi di controllarne lo stato 2. Il software degli acquisti on line deve poter permettere di acquisire gli ordini effettuati dai clienti, dando una visibilità ai clienti stessi sul tempo stimato di consegna, e sullo stato. 3. Il software degli acquisti on line deve poter permettere di acquisire gli ordini effettuati dai clienti, dando una visibilità ai clienti stessi sul tempo esatto di consegna. 4. Il software degli acquisti on line deve poter permettere di acquisire gli ordini effettuati dai clienti, e nei casi possibili, effettuare un inoltro automatico al magazzino. 5. Il software degli acquisti on line deve permettere ai clienti di scegliere o di definire delle configurazioni di computer (secondo un catalogo predefinito), e quindi di acquisire gli ordini eventualmente conseguenti 6. Il software degli acquisiti on line deve permettere permettere ai clienti di scegliere o di definire delle configurazioni di computer, fornendo anche un supporto effettivo affinché le scelte o le definizioni delle configurazioni siano corrispondenti alle necessità dei clienti etc. Metodologia DB 2

3 Acquisti On Line: Lista Funzionalità Compilare un Ordine Aggiungere una configurazione ad un ordine Selezionare tutte le configurazioni disponibili, secondo certi criteri Aggiungere una componente ad una configurazione Selezionare tutte le componenti disponibili, secondo certi criteri Modificare lo stato di un ordine di un qualunque cliente Visualizzare lo stato di un ordine di un cliente specifico Calcolare il costo di una configurazione Richiedere un contatto con un venditore Visualizzare la presenza di un componente a magazzino Visualizzare la presenza di un computer standard a magazzino Metodologia DB 3

4 Lista Funzionalità & Mission Statement Le seguenti funzionalità sono valide solo nel caso del mission statement 3: Visualizzare la presenza di un componente a magazzino Visualizzare la presenza di un computer standard a magazzino Il mission statement è quindi necessario per decidere in modo univoco quali funzionalità devono essere sviluppate come applicativi software. Metodologia DB 4

5 Acquisti On Line: Glossario Requisito Informativo Espresso in una Fonte Requisiti ORDINE CLIENTI COSTO CONFIGURA ZIONE CONFIGURA ZIONE COMPUTER DESKTOP Definizione Un ordine è il modo con cui un cliente chiede all azienda di acquistare una o più configurazioni di computer tra quelle disponibili o quelle definite dal cliente stesso Indica i dettagli del computer E il tipo di computer costruito dal cliente ovvero dall azienda Rilevante (serve per valutare la coerenza con il Mission Statement) Metodologia DB 5

6 Acquisti On Line: Glossario Requisito Informativo Espresso in una Fonte Requisiti Cliente effettua Ordine Un Ordine riguarda varie Configurazioni Codice cliente Carrello Definizione Indica il fatto che un cliente ha effettuato, cioè confermato, un ordine. Indica composizione singolo ordine la del Indica una proprietà del cliente, usata dall azienda per identificare in modo univoco i clienti stessi Indica un insieme di prodotti che, potenzialmente, daranno luogo ad un ordine ma non sono stati ancora ordinati Rilevante (serve per valutare la coerenza con il Mission Statement) Metodologia DB 6

7 Glossario & Mission Statement Requisito Informativo Espresso in una Fonte Requisiti ORDINE Definizione Rilevante (serve per valutare la coerenza con il Mission Statement) CLIENTI COSTO CONFIGURA ZIONE CONFIGURA ZIONE COMPUTER DESKTOP Indica uno qualunque dei computer che si trovano a magazzino (con il mission statement 3) NO (con i restanti mission statement) Metodologia DB 7

8 Glossario & Lista Funzionalità: un esempio di Verifica Per ogni voce nel Glossario, Esiste una funzionalità in Lista Funzionalità che ne ha necessità? Per ogni funzionalità in Lista Funzionalità, Il Glossario indica tutte le informazioni necessarie? Metodologia DB 8

9 Attività Generiche e Attività di Progettazione della Basedati Se viste nel contesto generale, le attività di progettazione di una basedati sono parte di quelle metodologiche generiche, secondo la seguente relazione: Determinazione dei requisiti Specifica dei requisiti Progetto Determinazione (o Raccolta ed Analisi) dei requisiti (orientata ai dati) Progettazione concettuale Progetto logico Implementazione Progetto fisico Metodologia DB 9

10 Attività Metodologiche Progettazione di Basidati Requisiti (Informativi) / Fonti dei Requisiti / Mission Statement Progettazione Concettuale Validazione dello Schema Verifica dello Schema Schema Concettuale, Modello EA Progettazione Logica Dipendente dal (tipo di) DBMS (e dall architettura) Schema Logico, Modello Relazionale Indipendente dal DBMS Progettazione Fisica Dipendente dal DBMS (e dall architettura) Schema Fisico, Indici, Cluster, etc. Metodologia DB 10

11 Usare un DBMS? memorizzazione persistente di dati gestione centralizzata dei dati controllo della ridondanza controllo della consistenza supporto multiutente condivisione dei dati documentazione dei dati indipendenza dalle organizzazioni dati controllo accessi e sicurezza backup e recovery Non usare un DBMS? investimento iniziale in HW/SW e training troppo importante la generalità fornita da un DBMS non è necessaria il prezzo per sicurezza, concorrenza, controllo e recovery è troppo alto rispetto agli obiettivi da raggiungere i dati e le applicazioni sono semplici e stabili requisiti di real-time non possono essere soddisfatti l accesso multiutente non è necessario Metodologia DB 11

12 Metodologie di Progettazione di Basidati Le metodologie per basi dati servono allo sviluppo di applicazioni di medie e grandi dimensioni caratterizzate da un uso consistente di dati Uso consistente di dati significa dati in grande quantità poco algoritmiche (semplici funzioni) operazioni di inserimento, cancellazione, modifica Interrogazioni (su insiemi) Applicazioni di ridotte dimensioni se progetto ben definito brevi tempi di sviluppo nessuna manutenzione a lungo termine poche persone, stabili senza risorse critiche basso rischio di fallimento basso costo del fallimento Perché applicazioni medie o grandi: la metodologia è una politica di assicurazione il costo di usare un metodologia è alto Metodologia DB 12

13 Conclusioni Riassuntive I Dalle fonti che descrivono la richiesta formulata dal committente è necessario passare attraverso una fase di determinazione e rappresentazione (specifica) dei requisiti stessi. I motivi sono molti tra cui: le fonti possono essere (ma lo sono quasi sempre) incomplete, le fonti possono essere scorrette ovvero includere elementi da non considerare (il committente non ha ben presente il suo problema), le fonti possono essere (ma lo sono quasi sempre) ambigue (ovvero il loro significato non è esplicito), per quanto si possa fare, i requisiti possono sempre soffrire di ambiguità, incompletezza etc. è necessario avere una certa garanzia per proseguire onde incorrere in costi e ritardi (e problemi legali), non tutto è realizzabile ed esistono sono visioni distinte. Una semplice rappresentazione dei requisiti riconosce la distinzione tra strutture dati (EA) ed algoritmi (descrizione funzionalità), tipica nei linguaggi di programmazione: EA+Testo per Funzionalità=Modello dei Requisiti Metodologia DB 13

14 Conclusioni Riassuntive II Il Modello EA definisce alcune caratteristiche essenziali per la specifica dei requisiti informativi. Nel software centrato sull uso di dati, il ruolo della del Mission Statement e della Lista delle Funzionalità sono essenziali per: definire meglio i limiti del software da sviluppare, costituire una base da cui derivare/completare i Requisiti Informativi per costruire Schemi EA, garantire la consistenza dei Requisiti Informativi con le Funzionalità che il software deve fornire, fornire una descrizione delle operazioni (transazioni) sulla basedati. Metodologia DB 14