Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti

Transcript

1 Lezione 5: Progettazione di Software e Database Dr. Luca Abeti Ingegneria del Software L ingegneria del software è la disciplina che studia i metodi e gli strumenti per lo sviluppo del software e la misura della sua qualità È una disciplina metodologica Problemi principali dell ingegneria del software Studio dei modelli e processi di sviluppo software Sviluppo e studio strumenti di produzione del SW Aspetti economici ed impatto sui processi del SW Il Software L acquisizione di hardware da parte di una organizzazione è lineare ed assimilabile a qualsiasi altro fattore produttivo Lo stesso non si può dire del software: Scelte possibili nell acquisizione del software: Posso comprarlo Posso «affittarlo» Posso realizzarlo con risorse interne Posso farlo realizzare su commissione Posso usarlo condividendolo con altri 1

2 Il Prodotto Software Il software ha caratteristiche che lo differenziano da ogni altro prodotto esistente: È intangibile ed astratto L unica visibilità che ho del prodotto mi è data dai documenti che descrizione il prodotto E un prodotto complesso Basato su componenti differenti, numero di stati esponenziale, difficile da comprendere Può essere prodotto in molti modi differenti e per diversi ambienti Costantemente soggetto a modifiche (nuove versioni) Non sono chiari i criteri per definire oggettivamente se e perché un software è qualitativamente migliore di un altro Non è facile misurarlo e definirne il valore Sviluppo del Software Il processo di sviluppo del software è un processo di problem solving I problemi si risolvono: Comprendendo il problema Compilazione di un piano risolutivo Sviluppo del piano risolutivo Verifica del risultato (Polya 1975, «How to solve it?») Processi Produttivi Produzione: risultato di una serie di trasformazioni operate dall uomo Tre tipi di attività produttive: Industriale Ciclo di produzione è un processo descritto, controllato, ottimizzato ed applicato da molte persone Artigianale Regolate meno rigorosamente dell industriale ma con regole di fondo che coinvolgono meno persone Artistica Attività completamente sregolate basate sulla creatività, di norma ad opera di una o pochissime persone In molti casi questi tre approcci si mescolano es. costruzione della Tour Eiffel, produzione di un film 2

3 Produzione di Software (1/2) Il software per sua natura richiede un approccio misto e che tenga conto della sua complessità Basato sulla produzione industriale ma che consideri L intangibilità e l invisibilità del prodotto Difficoltà a valutarne il costo e pretendere un giusto prezzo La produzione è una attività creativa ed esplorativa Spesso ai clienti è richiesto un coinvolgimento nel processo di produzione E difficile definire un processo di produzione da poter ripetere alla lettera Produzione di Software (2/2) Un processo di sviluppo software Descrive le attività necessarie allo sviluppo di un prodotto software e come queste sono collegate tra loro In generale chi progetto software deve: Definire le proprietà del prodotto requisiti che il software deve avere Fornirne una descrizione progetto di come il software dovrebbe essere realizzato Far sviluppare il prodotto codifica e produzione del codice vero e proprio Fasi dello Sviluppo Software (1/2) Analisi e Specifica dei Requisiti: Definizione rigorosa delle caratteristiche richieste dal software ed analisi di vincoli, condizioni ecc. A sua volta suddivisa in: studio di fattibilità analisi dei requisiti specifica dei requisiti verifica dei requisiti I requisiti possono essere: Funzionali: specificano cosa il sistema deve fare (funzioni) Non Funzionali: specificano caratteristiche generali del sistema 3

4 Fasi dello Sviluppo Software (2/2) Progettazione Definisce la struttura del software che realizza le specifiche fornendone una descrizione formale A sua volta suddivisa in : Suddivisione dei requisiti Identificazione sottosistemi ed architettura software Progettazione delle interfacce, dei componenti, dei dati, algoritmi ecc. In questa fase ci sia avvale di modelli per rappresentare il software da codificare in maniera astratta Implementazione Codifica del programma in un linguaggio di programmazione per la sua esecuzione Verifica Verifica del corretto funzionamento del sistema e validazione della rispondenza tra software e specifiche Processi di Sviluppo Software Waterfall Model Le fasi possono essere combinate in maniera diversa e secondo diverse «filosofie» Il primo processo di sviluppo SW proposto fu il modello a cascata Modello Incrementale Modello a spirale 4

5 Rational Unified Process (RUP) Studi di Fattibilità Prima ancora di iniziare la realizzazione del software bisogna capire: se questo è tecnicamente realizzabile se è conveniente dal punto di vista economico come questo cambierà l organizzazione ed i suoi processi Questa fase che possiamo chiamare di «preprogettazione» dovrebbe essere realizzata prima di definire qualsiasi progetto Ciclo di Vita del Software 5

6 Specifica dei Requisiti Per gli obiettivi del nostro corso ci interessa approfondire solo l analisi dei requisiti Prima di analizzarli, i requisiti devono essere raccolti e scritti Questa attività richiede lunghi colloqui con i committenti per comprendere le funzioni del sistema, i suoi vincoli, le caratteristiche generali qualitativamente rilevanti Attività da effettuare sono: Comprendere il dominio (es. analisi delle acque) Collezionare i requisiti Strutturazione dei requisiti Risoluzione conflitti ed ambiguità dei requisiti Controllo e validazione dei requisiti Analisi dei Requisiti I requisiti sono spesso raccolti in linguaggio naturale es. appunti in italiano, descrizioni informali ecc. Il linguaggio naturale male si presta ad un analisi rigorosa Facili fraintendimenti, ambiguità, differenti terminologie usate Per questo si usano notazioni più precise Linguaggio naturale strutturato Definisce un formato standard o template/moduli per descrivere i requisiti Notazioni grafiche Basate su linguaggi grafici standardizzati (es. UML) Formulazioni matematiche Linguaggi formali che consentono una descrizione basata su un particolare formalismo matematico (es. macchine a stati finiti) Esempio: Use Case UML 6

7 Processo di Sviluppo nei Sistemi Informativi I software quasi sempre utilizzano basi di dati per realizzare le loro funzioni I database rispetto al software possono essere: Integrati nell applicazione software es. rubrica di MS Outlook, ArcGIS Esterni ed indipendenti, utilizzati da una o più applicazioni software es. bancomat, una Web application Progettazione di Database Come i software anche i database devono essere progettati prima di essere implementati Sia che siano relazionali (SQL) Che semi-strutturati (XML) o in altre forme Anche per la progettazione di Database esiste una metodologia di riferimento analoga a quella vista per il software Sviluppo di Database Nello sviluppo di DB la fase di design viene divisa in 3 sottofasi: Progettazione concettuale Progettazione logica Progettazione fisica 7

8 Sotto-Fasi di Progettazione di DB Concettuale descrive in maniera formale ed indipendente dal modello di rappresentazione, la realtà di interesse. Produce il lo schema per il modello concettuale dei dati Logica ha come scopo la traduzione dello schema concettuale nel modello di rappresentazione a disposizione nei DBMS produce lo schema per il modello logico dei dati Fisica ha come scopo la specifica dei parametri fisici di rappresentazione; produce lo schema per il modello fisico dei dati Analisi dei Requisiti Cosa rappresentare Progettazione concettuale Schema concettuale Progettazione Come rappresentarlo Progettazione logica Schema logico Progettazione fisica Schema fisico Implementazione rappresentarlo Progettazione concettuale Progettazione logica Progettazione fisica 8

9 Modello dei Dati Insieme di costrutti utilizzati per organizzare i dati di interesse e descriverne la dinamica La componente fondamentale dei modelli è il meccanismo di strutturazione dei dati ad esempio, il modello relazionale prevede il costruttore relazione, che permette di definire insiemi di tuple omogenee Tipi di Modello Modelliconcettuali: permettono di rappresentare i dati in modo indipendente dai DBMS: cercano di descrivere i concetti del mondo reale sono utilizzati nelle fasi preliminari di progettazione il più noto è il modello Entità-Relazione Modellilogici: utilizzati nei DBMS esistenti per l organizzazione dei dati: utilizzati dai programmi indipendenti dalle strutture fisiche esempi: relazionale, reticolare, gerarchico, a oggetti Modelli Concettuali Se proviamo a modellare una applicazione definendo direttamente lo schema logico della base di dati: Non sappiamo da dove cominciare Ci perdiamo subito nei dettagli Dobbiamo pensare subito a come correlare le varie tabelle (chiavi, vincoli,...) perdendo d occhio gli obiettivi principali I Modelli Concettuali servono proprio per ragionare sulla realtà di interesse, indipendentemente dagli aspetti realizzativi (sia logici che fisici) Permettono di rappresentare le classi di dati di interesse e le loro correlazioni Prevedono efficaci rappresentazioni grafiche (utili anche per discussione, documentazione e comunicazione) 9

10 Analisi dei Requisiti Cosa rappresentare Progettazione concettuale Schema concettuale Progettazione Come rappresentarlo Progettazione logica Schema logico Progettazione fisica Schema fisico Implementazione rappresentarlo Come Progetteremo i Nostri Database Lo sviluppo del DB seguirà un metodo di progetto iterativo Noi useremo un metodo per ovvie ragioni semplificato e consisterà solo nelle seguenti fasi: Analisi dei Requisiti Progettazione Concettuale Progettazione Logica Implementazione in postgres Dettagli nella dispensa Analisi dei Requisiti nei DB Lettura requisiti espressi in linguaggio naturale ed eliminazione delle ambiguità Realizzazione di un glossario dei termini Strutturazione dei requisiti in base ai soggetti coinvolti (stakeholders) Specifica operazioni 10

11 Progettazione Concettuale del DB Descrizione del database in un modello concettuale Il modello scelto si chiama E-R Identificazione Entità e Relazioni Sviluppo modello E-R Dizionario dei Dati Regole Aziendali Progettazione Logica Eliminazione Gerarchie dal modello Accorpamenti/Partizionamenti attributi Elenco identificatori principali chiavi primarie Traduzione dal modello concettuale scelto (E-R) verso il modello logico (relazionale) Il Modello Entità-Relazione (E-R) Il più diffuso modello concettuale: ne esistono molte versioni, (più o meno) diverse una dall altra Fornisce una serie di costrutti per descrivere formalmente la realtà di interesse, in maniera (relativamente) semplice da comprendere ed indipendente dal modello di rappresentazione a disposizione nei DBMS Uno schema E-R è rappresentato tramite un diagramma, pienamente interpretato mediante una documentazione 11

12 Costrutti principali - entità - relazione - attributo Altri costrutti - cardinalità - identificatore - generalizzazione Costrutti del Modello Entità-Relazione Entità Rappresentano classi di oggetti (fatti, persone, cose, ) dell applicazione di interesse con proprietà comuni e con esistenza autonoma Esempi: impiegato, città, conto corrente, ordine, fattura Entità: rappresentazione grafica Impiegato Dipartimento Città Vendita 12

13 Relazioni (o associazioni) Rappresentano legami logici, rilevanti nell applicazione di interesse, tra due o più entità Esempi: residenza (fra persona e città) esame (fra studente e corso) Relazioni: rappresentazione grafica Studente Esame Corso Impiegato Residenza Città Due relazioni sulle stesse entità Sede di lavoro Impiegato Residenza Città 13

14 Attributi Rappresentano proprietà elementari, di interesse ai fini dell applicazione, di entità o relazioni Associano ad ogni occorrenza (di entità o relazione) un valore appartenente ad un insieme, detto dominio (il quale contiene i valori ammissibili per l attributo stesso) I domini non sono riportati nello schema (ma solo nella documentazione) Attributi: rappresentazione grafica Cognome Nome Data Voto Titolo Studente Esame Corso Matricola Codice Attributi Composti Raggruppano attributi di una medesima entità o relazione che presentano affinità nel loro significato o uso Esempio: via, numero civico e codice di avviamento postale formano un indirizzo 14

15 Attributi Composti: rappresentazione Cognome Impiegato Età Indirizzo Via Numero CAP Cognome Impiegato Codice Partecipazione Direzione Afferenza Data Telefono Dipartimento Nome Ubicazione Budget Progetto Nome Via CAP Indirizzo Sede Città Cardinalità delle Relazioni Coppia di valori associati a ogni partecipazione di entità ad una relazione Specifica il numero minimo e massimo di occorrenze della relazione a cui ciascuna occorrenza di una entità può partecipare 15

16 Rappresentazione Grafica (1,5) (0,50) Impiegato Assegnamento Incarico Convenzione sulle Cardinalità Usiamo solo tre simboli: 0 e 1 per la cardinalità minima: 0 = partecipazione opzionale 1 = partecipazione obbligatoria 1 e N per la cardinalità massima: N non pone alcun limite (1,1) (0,N) Studente Residenza Città 16

17 Tipi di Relazioni Binarie Con riferimento alle cardinalità massime, abbiamo relazioni: uno-a-uno (entrambe pari a 1) uno-a-molti (una pari a 1, l altra a N) molti-a-molti (entrambe pari a N) Esempi di relazioni molti-a-molti (0,N) (0,N) Studente Esame Corso Montagna (0,N) Scalata (1,N) Alpinista Macchinista (1,N) (1,N) Abilitazione Locomotore Esempi di relazione uno-a-molti Persona (0,1) (0,N) Impiego Azienda Cinema (1,1) (0,N) Ubicazione Località Comune (1,1) (1,N) Ubicazione Provincia 17

18 Esempi di relazione uno-a-uno Professore (0,1) (0,1) Titolarità Cattedra Professore di ruolo (1,1) (0,1) Titolarità Cattedra Professore di ruolo (1,1) (1,1) Titolarità Cattedra coperta Identificatori delle entità Permettono l identificazione univoca delle occorrenze di un entità Sono costituiti da: attributi dell entità identificatore interno, o chiave oppure attributi dell entità (l entità è detta debole) + entità esterne (attraverso relazioni) identificatore esterno Identificatore interno: rappresentazione Targa Automobile Modello Data Nascita Persona Cognome Indirizzo Nome 18

19 Identificatore esterno: rappresentazione Cognome Matricola Nome Studente (1,1) (0,N) Iscrizione Università Anno di corso Indirizzo Osservazioni Ogni entità deve possedere almeno un identificatore (interno o esterno), ma può averne in generale più di uno Una identificazione esterna è possibile solo attraverso una relazione a cui l entità da identificare partecipa con cardinalità (1,1) Non sono ammessi cicli di identificazioni esterne Cognome Impiegato Codice (0,N) Partecipazione (1,N) (0,1) (1,1) Telefono Direzione (1,N) (0,1) Dipartimento (0,N) Afferenza (0,1) (1,1) Ubicazione Nome Data (1,N) Budget Progetto Nome Via CAP Indirizzo Sede Città 19

20 Generalizzazioni Mettono in relazione una o più entità E1, E2,..., En (figlie) con una entità E (genitore), rappresentando un legame logico tra esse: E è generalizzazione di E1, E2,..., En E1, E2,..., En sono specializzazioni di E comprende come caso particolare) (che le Rappresentazione generalizzazione Dipendente Impiegato Funzionario Dirigente Proprietà delle generalizzazioni Se E è generalizzazione di E1, E2,..., En: ogni proprietà di E (attributi, identificatori, relazioni, altre generalizzazioni) è anche proprietà di E1, E2,..., En (ereditarietà) e non viene rappresentata esplicitamente ogni occorrenza di E1, E2,..., En è anche occorrenza di E 20

21 Documentazione di schemi E-R Uno schema E-R, da solo, non è quasi mai sufficiente a rappresentare tutti gli aspetti di una applicazione, perché: dizionario dei nomi insufficiente per capirne il significato proprietà dei dati non rappresentabili mediante i costrutti del modello vincoli sull uso dei costrutti non esprimibili negli schemi Si devono documentare gli schemi E-R La progettazione concettuale mediante il modello E-R Consiste nella costruzione di uno schema E-R in grado di descrivere formalmente le specifiche sui dati dell applicazione di interesse: è preceduta da (ed interconnessa con) una attività di raccolta e analisi dei requisiti è un processo graduale (procede per raffinamenti, arricchimenti, correzioni) esistono strategie ben precise per lo sviluppo (sistematico) di uno schema concettuale (es. top-down, bottom-up, misto) Regole concettuali del modello E-R Dato un concetto: se ha proprietà significative e/o descrive oggetti con esistenza autonoma entità se ha struttura semplice e proprietà non rilevanti attributo se correla due o più entità relazione se è caso particolare di un altro generalizzazione 21

22 Proprietà degli schemi di buona qualità Correttezza: lo schema rappresenta correttamente (sintatticamente e semanticamente) i requisiti iniziali Completezza: lo schema rappresenta tutti i requisiti Minimalità: lo schema rappresenta solo i requisiti e ogni loro aspetto appare solo una volta Leggibilità: lo schema è facile da interpretare ed esprime i requisiti in modo naturale Modificabilità: lo schema può essere facilmente modificato se i requisiti cambiano Auto-documentabilità: lo schema non ha bisogno di materiale aggiuntivo esterno La progettazione logica a partire dallo schema E-R Consiste nella costruzione di uno schema logico in grado di descrivere, in maniera corretta ed efficiente, tutte le informazioni contenute nello schema E-R prodotto dalla progettazione concettuale: non è una semplice traduzione da un modello all altro (lo schema E-R va prima ristrutturato per semplificare la traduzione e ottimizzare il progetto si articola in due fasi: ristrutturazione dello schema E-R traduzione verso il modello logico Eliminazione delle generalizzazioni Il modello relazionale non permette di rappresentare direttamente le generalizzazioni Entità e relazioni sono invece direttamente rappresentabili Si eliminano perciò le generalizzazioni, sostituendole con entità e relazioni 22

23 Tre Possibilità 1. Accorpamento delle figlie della generalizzazione nel genitore 2. Accorpamento del genitore nelle figlie 3. Sostituzione della generalizzazione con relazioni A01 A02 E0 R1 E3 E1 E2 R2 A11 A21 E4 A01 (0,1) A11 E0 A21 (0,1) TIPO A02 R1 E3 (0,..) R2 E4 23

24 A01 A02 E0 R1 E3 E1 E2 R2 A11 A21 E4 R11 R12 E3 E1 E2 R2 A01 A11 A02 A01 A21 A02 E4 A01 A02 E0 R1 E3 E1 E2 R2 A11 A21 E4 24

25 A01 A02 E0 R1 E3 RG1 (0,1) (1,1) (0,1) (1,1) RG2 E1 E2 R2 A11 A21 E4 A01 A02 E0 R1 E3 E1 E2 R2 A11 A21 E4 Scelta degli Identificatori Principali Operazione indispensabile per la traduzione nel modello logico relazionale: - chiavi (legami tra relazioni diverse) - chiavi primarie (reperimento efficiente di dati) Criteri: assenza di opzionalità (cioè di valori nulli) semplicità (meno attributi possibili, identificatore interno preferito a identificatore esterno) utilizzo nelle operazioni più frequenti o importanti se nessuno degli identificatori soddisfa i requisiti, si introducono nuovi attributi (detti codici) contenenti valori speciali generati appositamente per questo scopo 25

26 Traduzione nel Modello Relazionale A partire da uno schema E-R ristrutturato, si costruisce uno schema relazionale equivalente (cui segue un eventuale passo di ottimizzazione, detto normalizzazione) Si assume di avere a disposizione una versione semplificata del modello E-R: - assenza di generalizzazioni e attributi multivalore - presenza di soli identificatori principali (primari) Idea di base: le entità diventano relazioni sui propri attributi le associazioni diventano relazioni sui propri attributi + sugli identificatori principali delle entità coinvolte Relazioni molti-a-molti Cognome Matricola Data inizio Codice Nome Impiegato (0,N) Partecipazione (1,N) Progetto Stipendio Budget Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) Ridenominazione Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) Partecipazione(Impiegato, Progetto, DataInizio) 26

27 Relazioni uno-a-molti Cognome Data Ingaggio nascita Città Nome (1,1) (0,N) Giocatore Contratto Squadra Ruolo Colori sociali Giocatore(Cognome, DataNascita, Ruolo) Contratto(CognGiocatore, DataNascG, Squadra, Ing) Squadra(Nome, Città, ColoriSociali) Relazioni uno-a-uno Data inizio Cognome Codice Sede Nome Direttore (1,1) (1,1) Direzione Dipartimento Stipendio Telefono Due possibilità simmetriche: fondere Direttore e Direzione Oppure fondere Dipartimento e Direzione 27