Analisi Modelli per la specifica dei requisiti

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Analisi Modelli per la specifica dei requisiti"

Transcript

1 Modelli per la specifica dei requisiti Modelli semantici dei dati Entità-Relazioni (E-R) Modelli orientati all elaborazione dati Diagrammi di Flusso dei Dati (Data-Flow Diagrams, DFD) Modelli orientati alla classificazione Modelli orientati agli oggetti Modelli operazionali Automi a stati finiti Reti di Petri Modelli descrittivi Logica del primo ordine Logica temporale Ingegneria del Software L-A 2.63 Modelli per la specifica dei requisiti Obiettivo Specificare (cioè definire) le proprietà che il sistema dovrà avere senza descrivere una loro possibile realizzazione Approccio funzionale Astrae sino al massimo livello il modo di funzionare di un calcolatore Approccio orientato agli oggetti Si basa sulla stessa forma di astrazione applicata dagli uomini per affrontare la complessità del mondo Principio fondamentale: Astrazione Permette di gestire la complessità intrinseca del mondo reale Ignorare gli aspetti che non sono importanti per lo scopo attuale Concentrarsi maggiormente su quelli che lo sono Ingegneria del Software L-A 2.64 Ingegneria del Software L-A 2.1

2 Approccio Funzionale Tecnica della Scomposizione Funzionale Strategia: scegliere i passi ed i sotto-passi di elaborazione previsti per il sistema tipica analisi top-down L analista concentra la sua attenzione sulla modularizzazione delle procedure i moduli devono essere il più possibile indipendenti specifica le elaborazioni e le interfacce delle procedure La scomposizione in funzioni è molto volatile (a causa del continuo cambiamento dei requisiti funzionali) Ingegneria del Software L-A 2.65 Approccio Funzionale Astrazione procedurale Considerare ogni operazione come una singola entità Nonostante tale operazione sia effettivamente realizzata da un insieme di operazioni di più basso livello Ingegneria del Software L-A 2.66 Ingegneria del Software L-A 2.2

3 Approccio Orientato agli Oggetti Si basa sugli oggetti che sono molto più stabili delle funzioni Produce una specifica più resistente ai cambiamenti Fornisce una base efficace per L analisi del dominio Il riuso Fornisce una rappresentazione omogenea analisi progettazione programmazione in quanto si utilizzano Gli stessi principi La stessa notazione Gli stessi oggetti Ingegneria del Software L-A 2.67 Approccio Orientato agli Oggetti Astrazione dei dati Definire un tipo di dato in termini delle operazioni applicabili agli oggetti di quel tipo, con il vincolo che i valori di tali oggetti si possano modificare e osservare solo usando tali operazioni Si definiscono un insieme di attributi un insieme di operazioni (procedure) che manipolano in esclusiva tali attributi l unico modo per accedere agli attributi è tramite un operazione Gli attributi e le loro operazioni possono essere trattati come un tutto unico Ingegneria del Software L-A 2.68 Ingegneria del Software L-A 2.3

4 Approccio Orientato agli Oggetti Principio fondamentale: Incapsulamento Ogni tipo di dato deve rivelare il meno possibile della sua struttura interna e del suo funzionamento interno Obiettivo Minimizzare le modifiche da fare durante le fasi di sviluppo e di manutenzione Applicabile a tutti i livelli: Singoli attributi di una classe Singoli componenti del sistema Ingegneria del Software L-A 2.69 Approccio Orientato agli Oggetti Principio fondamentale: Ereditarietà Attributi e operazioni comuni devono essere specificati una volta sola Attributi e operazioni specifici vengono aggiunti e/o ridefiniti Obiettivo Semplificare la definizione e la realizzazione di tipi di dato simili Permette di esprimere esplicitamente le caratteristiche comuni, sino dalle prime attività dell analisi Ingegneria del Software L-A 2.70 Ingegneria del Software L-A 2.4

5 Modello dei dati del dominio del problema al fine di individuare Oggetti e classi rilevanti per il sistema da sviluppare Limitarsi esclusivamente a quelle classi che fanno parte del vocabolario del dominio del problema Relazioni tra le classi Per ogni classe Responsabilità Attributi Operazioni fondamentali cioè servizi forniti all esterno (interfaccia) Attività non strettamente sequenziali, ma reiterate sino alla produzione di un modello coerente Ingegneria del Software L-A 2.71 Modello dei dati Raggruppamento delle classi in sottosistemi Documentazione Diagrammi delle classi e dei sottosistemi Diagrammi di collaborazione tra le classi (opzionali) Per ogni classe, descrizione che ne specifica scopo, responsabilità, attributi, operazioni Per ogni attributo e ogni operazione, descrizione testuale accurata Ingegneria del Software L-A 2.72 Ingegneria del Software L-A 2.5

6 Notazione UML Una classe si rappresenta come un rettangolo diviso in 1 o 3 sezioni Stereotipo Nome della classe matricola cognome nome «attore» Esaminando getmatricola() getcognomenome() effettuaesame() Attributi Operazioni Ingegneria del Software L-A 2.73 Notazione UML matricola cognome nome «attore» Esaminando getmatricola() getcognomenome() effettuaesame() La prima sezione contiene Il nome della classe (in grassetto) può contenere Lo stereotipo della classe (ad esempio, controllore, attore, evento, interfaccia utente, database, ecc.) Il nome del pacchetto (package, namespace) Quizzer::Esaminando Altre proprietà della classe tra parentesi graffe ad esempio {abstract} Ingegneria del Software L-A 2.74 Ingegneria del Software L-A 2.6

7 Notazione UML matricola cognome nome «attore» Esaminando La seconda sezione contiene Gli attributi La terza sezione contiene Le operazioni getmatricola() getcognomenome() effettuaesame() Ingegneria del Software L-A 2.75 Notazione UML «attore» Esaminando Interfaccia IStudente IEsaminando matricola cognome nome getmatricola() getcognomenome() effettuaesame() Ingegneria del Software L-A 2.76 Ingegneria del Software L-A 2.7

8 Notazione UML «interface» IStudente «interface» IEsaminando getmatricola() getcognomenome() effettuaesame() matricola cognome nome «attore» Esaminando getmatricola() getcognomenome() effettuaesame() Ingegneria del Software L-A 2.77 Individuazione delle classi Due analisti non produrranno mai due modelli delle classi identici per lo stesso dominio applicativo La letteratura è ricca di approcci raccomandati per l individuazione delle classi Approccio basato sulle frasi nominali Approccio basato sulle strutture comuni Approccio guidato dai casi d uso Approccio CRC La cosa migliore è usare un approccio misto Ingegneria del Software L-A 2.78 Ingegneria del Software L-A 2.8

9 Individuazione delle classi Fonti principali Documento dei requisiti Altri documenti di tutti i tipi che descrivono il sistema Altre fonti Altri sistemi che funzionano nello stesso dominio o in domini analoghi Enciclopedie, nomenclature e documenti tecnici che descrivono il dominio Riutilizzare classi, gerarchie e strutture ottenute da precedenti analisi nello stesso dominio Ingegneria del Software L-A 2.79 Individuazione delle classi Il nome della classe deve Indicare al singolare un oggetto della classe Iniziare con una lettera maiuscola Essere un nome familiare All utente o All esperto del dominio del problema Non allo sviluppatore! Esempi Docente CorsoDiStudio AttivitaFormativa Ingegneria del Software L-A 2.80 Ingegneria del Software L-A 2.9

10 Individuazione delle classi Elencare i nomi (semplici o composti) che compaiono nei documenti raccolti, convertendoli al singolare Eliminare i nomi che sicuramente non si riferiscono a classi indicano attributi (dati di tipo primitivo) indicano operazioni Scegliere un solo termine significativo se più parole indicano lo stesso concetto (sinonimi) Ingegneria del Software L-A 2.81 Individuazione delle classi Attenzione agli aggettivi e agli attributi, possono Indicare oggetti diversi Indicare usi diversi dello stesso oggetto Essere irrilevanti Ad esempio: Studente bravo potrebbe essere irrilevante Studente fuori corso potrebbe essere una nuova classe Attenzione alle frasi passive, impersonali o con soggetti fuori dal sistema devono essere rese attive ed esplicite, perché potrebbero mascherare entità rilevanti per il sistema in esame Ingegneria del Software L-A 2.82 Ingegneria del Software L-A 2.10

11 Individuazione delle classi Individuare Attori con cui il sistema in esame deve interagire Persone Docente, Studente, Esaminatore, Esaminando, Sistemi esterni ReteLocale, Internet, DBMS, Dispositivi attuatori, sensori, Individuare Modelli e loro elementi specifici, cioè oggetti descrittivi e istanze specifiche Insegnamento Ingegneria del Software L-A CorsoDiStudio Ingegneria Informatica Facoltà Ingegneria Ingegneria del Software L-A 2.83 Individuazione delle classi Individuare Cose tangibili, cioè oggetti reali appartenenti al dominio del problema Banco, LavagnaLuminosa, Schermo, Computer, Individuare Contenitori (fisici o logici) di altri oggetti Facoltà, Dipartimento, Aula, SalaTerminali, ListaEsame, CommissioneDiLaurea, OrdineDegliStudi, Window, Form, Individuare Eventi o Transazioni che il sistema deve gestire e memorizzare - possono avvenire in un certo istante (ad es., una vendita) o - possono durare un intervallo di tempo (ad es., un affitto) Appello, EsameScritto, Registrazione, AppelloDiLaurea, Ingegneria del Software L-A 2.84 Ingegneria del Software L-A 2.11

12 Individuazione delle classi Per determinare se includere una classe nel modello, porsi le seguenti domande: Il sistema deve ricordare qualcosa sugli oggetti della classe? In caso negativo, la validità e l importanza della classe è dubbia; può anche succedere che un oggetto abbia delle operazioni, ma non abbia dati da memorizzare: per esempio, una classe che descrive un sistema esterno potrebbe avere solo operazioni per colloquiare col sistema in esame Il sistema deve interagire con gli oggetti di questa classe? Quali sono le responsabilità della classe? Ingegneria del Software L-A 2.85 Individuazione delle classi Attenzione a Oggetti con un solo attributo si può essere giunti a un livello di dettaglio troppo basso: probabilmente conviene includere l'oggetto come attributo di un altra classe Classi con un solo oggetto (singleton) Oggetti di tipo diverso con le stesse responsabilità Ingegneria del Software L-A 2.86 Ingegneria del Software L-A 2.12

13 Individuazione delle classi Attributi e operazioni devono essere applicabili a tutti gli oggetti della classe Se esistono Attributi con un valore ben definito solo per alcuni oggetti della classe e/o Operazioni applicabili solo ad alcuni oggetti della classe siamo in presenza di ereditarietà Esempio: dopo una prima analisi, la classe Studente potrebbe contenere un attributo booleano incorso, ma un analisi più attenta potrebbe portare alla luce la gerarchia: Studente StudenteInCorso StudenteFuoriCorso Ingegneria del Software L-A 2.87 Individuazione delle responsabilità Responsabilità di una classe Descrizione ad alto livello dello scopo per cui è stata definita la classe Vengono descritti solo i servizi disponibili pubblicamente, non quelli privati interni alla classe, la cui definizione sarebbe prematura Obiettivo aiutare nell identificazione di Classi Attributi Operazioni Relazioni tra le classi Ingegneria del Software L-A 2.88 Ingegneria del Software L-A 2.13

14 Individuazione delle responsabilità Principali sorgenti di informazione Documento dei requisiti Classi già identificate Cercare verbi che rappresentano azioni fatte da un oggetto del sistema Utilizzare le classi già identificate per il semplice fatto di esistere, devono avere almeno una responsabilità Annotare tutte le informazioni che gli oggetti devono mantenere e gestire Ingegneria del Software L-A 2.89 Individuazione delle responsabilità Una volta identificate, le responsabilità vanno assegnate alle classi in base ai seguenti criteri: Distribuire le responsabilità in modo bilanciato (molti oggetti che si scambiano messaggi) Assegnare le responsabilità al livello più generale possibile salendo la gerarchia delle classi Mantenere il comportamento collegato alle informazioni ad esso necessarie Ingegneria del Software L-A 2.90 Ingegneria del Software L-A 2.14

15 Individuazione delle responsabilità Metodo di analisi CRC (Class-Responsibility- Collaboration) di Cunningham e Beck Nome della classe Lista di responsabilità Lista di collaboratori I collaboratori sono le altre classi con le quali la classe in esame deve interagire Si utilizzano schede di cartoncino di 10x15 cm Ingegneria del Software L-A 2.91 Individuazione delle relazioni La maggior parte delle classi (degli oggetti) interagisce con altre classi (altri oggetti) in vari modi Quando si modella un sistema è necessario individuare: Non solo le entità coinvolte nel sistema Ma anche le relazione tra tali entità Una relazione (relationship) è una connessione tra entità Ingegneria del Software L-A 2.92 Ingegneria del Software L-A 2.15

16 Individuazione delle relazioni Nella modellazione object-oriented le relazioni più importanti sono: Ereditarietà Associazione Associazione generica Aggregazione Composizione Dipendenza Collaborazione (relazione usa) Relazione Istanza Classe Istanza di classe generica Classe generica (istanza di template template) Relazione Classe Metaclasse Ingegneria del Software L-A 2.93 Individuazione delle relazioni In ogni tipo di relazione, esiste un cliente C che dipende da un fornitore di servizi F C ha bisogno di F per lo svolgimento di alcune funzionalità che C non è in grado di effettuare autonomamente Conseguenza per il corretto funzionamento di C è indispensabile il corretto funzionamento di F Ingegneria del Software L-A 2.94 Ingegneria del Software L-A 2.16

17 Individuazione delle relazioni Tipo di relazione Ereditarietà Associazione Dipendenza sottoclasse classe dipendente (che usa) istanza classe Cliente contenitore superclasse contenuto classe da cui si dipende (che viene usata) classe Fornitore metaclasse Ingegneria del Software L-A 2.95 Individuazione dell ereditarietà Una classe B è in relazione EREDITA_DA con una classe A (B EREDITA_DA A), se B deriva da una modifica incrementale di A La classe B (specializzazione o sottoclasse) è simile alla classe A (generalizzazione o superclasse) e ne eredita Relazioni Attributi Operazioni AB AB Ingegneria del Software L-A 2.96 Ingegneria del Software L-A 2.17

18 Individuazione dell ereditarietà La ricerca delle relazioni di ereditarietà contribuisce a chiarire il significato delle varie classi e può portare alla scoperta di nuove classi Studente StudenteInCorso StudenteFuoriCorso Ingegneria del Software L-A 2.97 Individuazione dell ereditarietà L ereditarietà deve rispecchiare una tassonomia effettivamente presente nel dominio del problema Eccezione ereditarietà dell implementazione (ma siamo ancora in fase di analisi!) Non usare l ereditarietà solo per riunire caratteristiche comuni ad es., Studente e Dipartimento hanno entrambi un indirizzo, ma non per questo c è ereditarietà! Ingegneria del Software L-A 2.98 Ingegneria del Software L-A 2.18

19 Individuazione dell ereditarietà Ereditarietà semplice ogni classe della gerarchia ha al più una superclasse La struttura che si ottiene è sempre un albero Ereditarietà multipla almeno una classe della gerarchia ha più di una superclasse Se esistono antenati comuni ripetuti la struttura che si ottiene è un reticolo si hanno conflitti di nome la gestione può diventare molto complessa Ingegneria del Software L-A 2.99 Individuazione dell ereditarietà Tra due o più classi di una gerarchia possono esistere dei vincoli {overlapping} o {disjoin} Veicolo {overlapping} {disjoint} VeicoloTerrestre VeicoloAcquatico VeicoloMilitare VeicoloCivile CarroArmato Taxi Corazzata BarcaAVela Un reticolo di veicoli Ingegneria del Software L-A Ingegneria del Software L-A 2.19

20 Individuazione dell ereditarietà Veicolo OggettoMilitare OggettoCivile VeicoloTerrestre VeicoloAcquatico CarroArmato Taxi Corazzata BarcaAVela Una gerarchia multipla di veicoli, senza antenati ripetuti Ingegneria del Software L-A Individuazione delle associazioni Un associazione rappresenta una relazione strutturale tra due istanze di classi diverse o della stessa classe Un associazione può Rappresentare un contenimento logico (aggregazione) Una lista d esame contiene degli studenti Rappresentare un contenimento fisico (composizione) Un triangolo contiene tre vertici Non rappresentare un reale contenimento Una fattura si riferisce a un cliente Un evento è legato a un dispositivo Ingegneria del Software L-A Ingegneria del Software L-A 2.20

21 Individuazione delle associazioni Aggregazione Un oggetto x di classe X è associato a (contiene) un oggetto y di classe Y in modo non esclusivo x può condividere y con altri oggetti anche di tipo diverso (che a loro volta possono contenere y) Una lista d esame contiene degli studenti Uno studente può essere contemporaneamente in più liste d esame La cancellazione della lista d esame non comporta l eliminazione fisica degli studenti in lista Ingegneria del Software L-A Individuazione delle associazioni Composizione Un oggetto x di classe X è associato a (contiene) un oggetto y di classe Y in modo esclusivo y esiste solo in quanto contenuto in x Un triangolo contiene tre punti (i suoi vertici) L eliminazione del triangolo comporta l eliminazione dei tre punti Se la distruzione del contenitore comporta la distruzione degli oggetti contenuti, si tratta di composizione, altrimenti si tratta di aggregazione Ingegneria del Software L-A Ingegneria del Software L-A 2.21

22 Individuazione delle associazioni In UML La composizione è indicata con un rombo nero dalla parte del contenitore L aggregazione è indicata con un rombo bianco dalla parte del contenitore Ad ogni associazione è possibile aggiungere: Un nome (e una direzione di lettura del nome) I ruoli delle classi coinvolte La cardinalità, cioè il numero di oggetti che possono partecipare all'associazione Il contenimento (aggregazione o composizione) Ingegneria del Software L-A matrimonio Società nome indirizzo 1 lavora-per * datore-lavoro impiegato marito Persona nome indirizzo codicefiscale datanascita sottoposto moglie * dirigente 0..1 dirige Poligono 1 contiene {ordered} 3..* Punto Questo è un commento associato alla classe Poligono. Finestra * 1 BarraTitolo Pannello Bordo 1 1 Etichetta 1 Pulsante Chiusura Vari tipi di associazione. Ingegneria del Software L-A Ingegneria del Software L-A 2.22

23 Individuazione delle associazioni Per individuare potenziali aggregazioni o composizioni, considerare Insieme-PartiComponenti Contenitore-Contenuto Collezione-Membri Se contenitore e contenuto hanno un legame forte e uno stesso ciclo di vita, si tratta di composizione altrimenti, si tratta di aggregazione Ingegneria del Software L-A Individuazione delle associazioni Per individuare potenziali associazioni generiche, per ogni oggetto, porsi le domande A quali altri oggetti è collegato nel dominio del problema? Da chi deve ottenere informazioni per soddisfare alle sue responsabilità? Ingegneria del Software L-A Ingegneria del Software L-A 2.23

24 Individuazione delle associazioni Una volta determinata la presenza di un associazione Tracciare la linea di connessione, eventualmente col simbolo di aggregazione o composizione dalla parte del contenitore Se possibile, dare un nome all associazione e ai due ruoli, scegliendolo tra i termini del dominio del problema Definire il valore, l intervallo o l insieme di valori e/o intervalli del limite inferiore la connessione è opzionale? il limite inferiore è 0 la connessione è obbligatoria? il limite inferiore è1 limite superiore la connessione è singola? il limite superiore è 1 la connessione è multipla? il limite superiore è > 1 Ingegneria del Software L-A Individuazione delle associazioni Cardinalità Simbolo Significato Esempi n valore singolo 1 * da 0 a * n..m n,m intervallo insieme di valori e/o intervalli * 1,3..5,7 Ingegneria del Software L-A Ingegneria del Software L-A 2.24

25 Individuazione delle associazioni Attenzione alle associazioni molti a molti possono nascondere una classe (classe di associazione) del tipo evento da ricordare Esempio: la connessione proprietà tra Proprietario e Veicolo nasconde una classe CompraVendita, che lega Proprietari e Veicoli Esempio: la connessione matrimonio tra Persona e Persona nasconde una classe Matrimonio, che lega due Persone Ingegneria del Software L-A Individuazione delle associazioni 1 esempio Un proprietario può possedere molti veicoli Proprietario possiede 1..* * 1..* * Veicolo Un veicolo può essere di molti proprietari in tempi successivi Proprietario 1..* * 1..* * Veicolo in comproprietà CompraVendita -dataacquisto Legame 1 a 1 Ingegneria del Software L-A Ingegneria del Software L-A 2.25

26 Individuazione delle associazioni 1 esempio Un proprietario può partecipare a più compravendite Proprietario 1..* * 1..* * CompraVendita -dataacquisto Veicolo Un veicolo può essere contemporaneamente di più proprietari Una compravendita è relativa a un solo veicolo Proprietario 1..* partecipa a 1..* CompraVendita -dataacquisto 1..* Veicolo 1 acquisto di Ingegneria del Software L-A Individuazione delle associazioni Persona * * matrimonio Relazione n-m (matrimonio) tra due oggetti della stessa classe. Persona 1 1 marito moglie * * Matrimonio data Un Matrimonio è in effetti una classe, con due associazioni con oggetti di tipo Persona (marito e moglie). Ingegneria del Software L-A Ingegneria del Software L-A 2.26

27 Individuazione delle collaborazioni Una classe A è in relazione USA con una classe B (A USA B) quando A ha bisogno della collaborazione di B per lo svolgimento di alcune funzionalità che A non è in grado di effettuare autonomamente Un operazione della classe A ha bisogno come argomento di un istanza della classe B void fun1(b b) { usa b } Un operazione della classe A restituisce un valore di tipo B B fun2() { B b; return b; } Un operazione della classe A utilizza un istanza della classe B (ma non esiste un associazione tra le due classi) void fun3() { B b = new B(); usa b } Ingegneria del Software L-A Individuazione delle collaborazioni La relazione non è simmetrica A dipende da B, ma B non dipende da A Evitare situazioni in cui una classe, tramite una catena di relazioni USA, alla fine dipende da se stessa Cliente Fornitore Cliente Nome Interfaccia Fornitore Ingegneria del Software L-A Ingegneria del Software L-A 2.27

28 Eredità e composizione Una classe potrebbe aver bisogno di utilizzare le risorse di un altra classe Ad esempio, la classe Finestra ha bisogno della classe Rettangolo per memorizzare posizione e dimensione fare calcoli di sovrapposizione con altre finestre... Esistono due possibili soluzioni Ingegneria del Software L-A Eredità e composizione 1. Rendere Finestra sottoclasse di Rettangolo Una Finestra eredita e quindi ha accesso diretto a dati e operazioni di un Rettangolo 2. Inserire un Rettangolo entro la struttura dati di una Finestra: una Finestra contiene un Rettangolo Una Finestra ha accesso indiretto alle operazioni pubbliche di un Rettangolo Rettangolo Finestra Ereditarietà Finestra Rettangolo Composizione Ingegneria del Software L-A Ingegneria del Software L-A 2.28

29 Eredità e composizione Nel primo caso (ereditarietà) La definizione avviene staticamente (compile-time) L implementazione della sottoclasse è facile da modificare, può definire i propri metodi e continuare a usare quelli della superclasse La superclasse definisce parte della rappresentazione fisica della sottoclasse, legando a sé la sottoclasse, rompendo l incapsulamento e rendendo più difficile il riuso della sottoclasse Ingegneria del Software L-A Eredità e composizione Nel secondo caso (composizione) La definizione può avvenire dinamicamente (run-time) Le interfacce delle due classi restano indipendenti Quindi Usare l ereditarietà solo se rispecchia il dominio del problema Altrimenti, preferire la composizione Ingegneria del Software L-A Ingegneria del Software L-A 2.29

Analisi Modello dei dati

Analisi Modello dei dati Modello dei dati Individuare Oggetti e classi rilevanti per il sistema da sviluppare Limitarsi esclusivamente a quelle classi che fanno parte del vocabolario del dominio del problema Relazioni tra le classi

Dettagli

Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni

Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni LA PROGETTAZIONE DI BASI DI DATI Progettare una basi di dati vuole dire progettare la struttura dei dati e le applicazioni La progettazione dei dati è l attività più importante Per progettare i dati al

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

Dettagli

Database. Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014

Database. Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014 Database Appunti di Amaranto Oronzo e Giancane Diego Lezione dell Ing. Lucia Vaira 24/04/2014 Cos'è un database? È una struttura di dati composta da tabelle a loro volta composte da campi. Caratteristiche

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Analisi Giulio Destri Ing. del software: Analisi - 1 Scopo del modulo Definire

Dettagli

Progettazione base dati relazionale

Progettazione base dati relazionale Progettazione base dati relazionale Prof. Luca Bolognini E-Mail:luca.bolognini@aliceposta.it Progettare una base di dati Lo scopo della progettazione è quello di definire lo schema della base di dati e

Dettagli

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti Alessio Bechini - Corso di - Il paradigma OO e le relative metodologie di progettazione Metodologie OO Programmazione orientata agli oggetti La programmazione ad oggetti (OOP) è un paradigma di programmazione

Dettagli

Class Diagram. Catia Trubiani. Laboratorio di Ingegneria del Software a.a. 2013-2014

Class Diagram. Catia Trubiani. Laboratorio di Ingegneria del Software a.a. 2013-2014 Università degli Studi dell Aquila Laboratorio di Ingegneria del Software a.a. 2013-2014 Catia Trubiani Dipartimento di Ingegneria e Scienze dell'informazione e Matematica (DISIM)- Università degli Studi

Dettagli

Definizione Un modello astratto è la rappresentazione formale di idee e conoscenze relative a un fenomeno.

Definizione Un modello astratto è la rappresentazione formale di idee e conoscenze relative a un fenomeno. MODELLI INFORMATICI 1 Definizione Un modello astratto è la rappresentazione formale di idee e conoscenze relative a un fenomeno. Aspetti di un modello: il modello è la rappresentazione di certi fatti;

Dettagli

Alessandra Raffaetà. Basi di Dati

Alessandra Raffaetà. Basi di Dati Lezione 2 S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali Alessandra Raffaetà Dipartimento di Informatica Università Ca Foscari Venezia Basi di Dati

Dettagli

PROGETTAZIONE CONCETTUALE

PROGETTAZIONE CONCETTUALE Fasi della progettazione di basi di dati PROGETTAZIONE CONCETTUALE Parte V Progettazione concettuale Input: specifiche utente Output: schema concettuale (astrazione della realtà) PROGETTAZIONE LOGICA Input:

Dettagli

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS Basi di Basi di (Sistemi Informativi) Sono una delle applicazioni informatiche che hanno avuto il maggiore utilizzo in uffici, aziende, servizi (e oggi anche sul web) Avete già interagito (magari inconsapevolmente)

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

PROGETTAZIONE DI UN DATABASE

PROGETTAZIONE DI UN DATABASE Indice PROGETTAZIONE DI UN DATABASE 1.Il modello ER (entity relationship)...1 Generalità...1 I costrutti principali del modello...2 Entità...2 Associazioni...2 Attributi...2 Altri costrutti del modello...2

Dettagli

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi Metodologie e modelli per la progettazione di basi di dati Introduzione alla progettazione Il problema: progettare una base di base di dati a partire dai suoi requisiti Progettare: definire la struttura,

Dettagli

UML Diagrammi delle classi. UML Diagramma classi 1

UML Diagrammi delle classi. UML Diagramma classi 1 UML Diagrammi delle classi UML Diagramma classi 1 Diagramma delle classi Non è nei nostri obiettivi affrontare UML nel suo complesso Ci concentreremo sui diagrammi delle classi che ci forniscono un linguaggio

Dettagli

Ingegneria del Software: UML Class Diagram

Ingegneria del Software: UML Class Diagram Ingegneria del Software: UML Class Diagram Due on Mercoledì, Aprile 1, 2015 Claudio Menghi, Alessandro Rizzi 1 Contents Ingegneria del Software (Claudio Menghi, Alessandro Rizzi ): UML Class Diagram 1

Dettagli

Relazioni tra oggetti e classi : Composizione. Relazioni tra oggetti e classi : esempio di Aggregazione. classe contenitore

Relazioni tra oggetti e classi : Composizione. Relazioni tra oggetti e classi : esempio di Aggregazione. classe contenitore Relazioni tra oggetti e classi : Generalizzazione Fondamenti di Informatica II 20. Laboratorio 6 Collegamenti e associazioni Le relazioni di tipo generalizzazione (specializzazione), servono per poter

Dettagli

Basi di dati. Le funzionalità del sistema non vanno però ignorate

Basi di dati. Le funzionalità del sistema non vanno però ignorate Basi di dati La progettazione di una base di dati richiede di focalizzare lo sforzo su analisi, progettazione e implementazione della struttura con cui sono organizzati i dati (modelli di dati) Le funzionalità

Dettagli

Sistemi Informativi. Basi di Dati. Progettazione concettuale. Architettura Progettazione Analisi funzionale

Sistemi Informativi. Basi di Dati. Progettazione concettuale. Architettura Progettazione Analisi funzionale 6LVWHPL,QIRUPDWLYL H DVLGL'DWL Oreste Signore (Oreste.Signore@cnuce.cnr.it) &RQWHQXWR Sistemi Informativi Basi di Dati Architettura Progettazione Analisi funzionale Progettazione concettuale Information

Dettagli

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E.

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Class Discovery E. TINELLI Contenuti Classi di analisi: definizione ed esempi Tecniche per la definizione

Dettagli

Basi di Dati. Progettazione del Modello ER. K. Donno - Progettazione del Modello ER

Basi di Dati. Progettazione del Modello ER. K. Donno - Progettazione del Modello ER Basi di Dati Progettazione del Modello ER Dai requisiti allo schema ER Entità, relazioni e attributi non sono fatti assoluti dipendono dal contesto applicativo Nella pratica si fa spesso uso di una strategia

Dettagli

Sistemi ICT per il Business Networking

Sistemi ICT per il Business Networking Corso di Laurea Specialistica Ingegneria Gestionale Sistemi ICT per il Business Networking Unified Modelling Language (UML) Class Diagram Docente: Massimo Cossentino Slide adattate dagli originali di:

Dettagli

Programmazione a Oggetti e JAVA. Prof. B.Buttarazzi A.A. 2012/2013

Programmazione a Oggetti e JAVA. Prof. B.Buttarazzi A.A. 2012/2013 Programmazione a Oggetti e JAVA Prof. B.Buttarazzi A.A. 2012/2013 Relazioni tra classi Ereditarietà Generalizzazione Specializzazione Aggregazione Composizione Dipendenza Associazione Sommario Relazioni

Dettagli

La progettazione concettuale: il modello ER. 17/12/2007 Unità di Apprendimento A2 1

La progettazione concettuale: il modello ER. 17/12/2007 Unità di Apprendimento A2 1 La progettazione concettuale: il modello ER 17/12/2007 Unità di Apprendimento A2 1 1 La progettazione concettuale Prima di procedere con la progettazione concettuale è necessario effettuare un analisi

Dettagli

MODELLO E/R. Modellazione dei dati

MODELLO E/R. Modellazione dei dati MODELLO E/R Maria Mirto Modellazione dei dati Modellare i dati significa: costruire una rappresentazione semplificata della realtà osservata, individuandone gli elementi caratterizzanti e i legami intercorrenti

Dettagli

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Il modello Entity-Relationship: elementi di base

Il modello Entity-Relationship: elementi di base Il modello Entity-Relationship: elementi di base Sistemi Informativi T Versione elettronica: 06.1.ER.base.pdf I modelli concettuali dei dati Vogliamo pervenire a uno schema che rappresenti la realtà di

Dettagli

Progettazione del Software

Progettazione del Software L4.4 Progettazione del Software Emiliano Casalicchio Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti http://www.ce.uniroma2.it/courses/psw Seconda Parte La fase di

Dettagli

I Sistemi Informativi

I Sistemi Informativi I Sistemi Informativi Definizione Un Sistema Informativo è un mezzo per acquisire, organizzare, correlare, elaborare e distribuire le informazioni che riguardano una realtà che si desidera descrivere e

Dettagli

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1 a cura di Giancarlo Cherchi 1 Introduzione Il meccanismo dell eredità consente di sfruttare delle relazioni tipo/sottotipo, ereditando attributi

Dettagli

Metodologie di progetto Estensione di classi Implementazione di interfacce Composizione

Metodologie di progetto Estensione di classi Implementazione di interfacce Composizione Gerarchie di Tipi Metodologie di progetto Estensione di classi Implementazione di interfacce Composizione Notazione UML Relazione Simbolo Significato Ereditarietà Implementazione Aggregazione Dipendenza

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006. Esercizi entità relazione risolti. a cura di Angela Campagnaro 802749

Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006. Esercizi entità relazione risolti. a cura di Angela Campagnaro 802749 Corso di Sistemi di Elaborazione delle Informazioni I Anno 2005/2006 Esercizi entità relazione risolti a cura di Angela Campagnaro 802749 Indice: Esercizio 1: Un insieme di officine 1.1 Testo esercizio.3

Dettagli

UML Unified Modeling Language

UML Unified Modeling Language UML Unified Modeling Language Lezione 4-1 - UML Il diagramma delle classi Parte Seconda - 2 - Relazioni tra Classi&Oggetti I diagrammi delle classi mettono in evidenza i blocchi costitutivi del sistema

Dettagli

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA 1 Sistema Informativo Un sistema informativo (SI) è un componente di una organizzazione il cui obiettivo è gestire le informazioni utili per gli scopi dell

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

Dettagli

Modello dei Dati ENTITÀ-RELAZIONE (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale

Modello dei Dati ENTITÀ-RELAZIONE (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale Modello dei Dati E-R ENTITÀ-RELAZIONE O (ENTITY-RELATIONSHIP) é l insieme di concetti, simboli, regole che useremo per rappresentare il modello concettuale R.Gori - G.Leoni Modello dei Dati Entità-Relazione

Dettagli

LABORATORIO di INFORMATICA

LABORATORIO di INFORMATICA Università degli Studi di Cagliari Corso di Laurea Magistrale in Ingegneria per l Ambiente ed il Territorio LABORATORIO di INFORMATICA A.A. 2010/2011 Prof. Giorgio Giacinto IL MODELLO ER PER LA PROGETTAZIONE

Dettagli

Esercitazione di Basi di Dati

Esercitazione di Basi di Dati Esercitazione di Basi di Dati Corso di Fondamenti di Informatica 6 Maggio 2004 Come costruire una ontologia Marco Pennacchiotti pennacchiotti@info.uniroma2.it Tel. 0672597334 Ing.dell Informazione, stanza

Dettagli

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1]

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1] Progettazione di basi di dati Progettazione di basi di dati Requisiti progetto Base di dati Struttura Caratteristiche Contenuto Metodologia in 3 fasi Progettazione concettuale Progettazione logica Progettazione

Dettagli

I livelli di progettazione possono essere così schematizzati: Esistono tre tipi diversi di modelli logici: Modello gerarchico: Esempio SPECIFICHE

I livelli di progettazione possono essere così schematizzati: Esistono tre tipi diversi di modelli logici: Modello gerarchico: Esempio SPECIFICHE I DATABASE o basi di dati possono essere definiti come una collezione di dati gestita dai DBMS. Tali basi di dati devono possedere determinati requisiti, definiti come specifiche, necessarie per il processo

Dettagli

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Luciano Baresi Luciano Baresi 1 OMT Booch UML Sono simili in molti aspetti: Prescrivono un approccio passo-passo Consentono il passaggio dall analisi al progetto in modo omogeneo

Dettagli

Informatica (Basi di Dati)

Informatica (Basi di Dati) Corso di Laurea in Biotecnologie Informatica (Basi di Dati) Modello Entità-Relazione Anno Accademico 2009/2010 Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati Lucidi del Corso di Basi di Dati 1, Prof.

Dettagli

Il modello Entity-Relationship per il progetto delle basi di dati

Il modello Entity-Relationship per il progetto delle basi di dati 1 Il modello Entity-Relationship per il progetto delle basi di dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Le metodologie di progettazione delle Basi di Dati 2 Una metodologia

Dettagli

Progettazione di un DB....in breve

Progettazione di un DB....in breve Progettazione di un DB...in breve Cosa significa progettare un DB Definirne struttura,caratteristiche e contenuto. Per farlo è opportuno seguire delle metodologie che permettono di ottenere prodotti di

Dettagli

Il diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T1 B2 Significato e proprietà della OOP 1 Prerequisiti Concetto ed elementi della comunicazione Allocazione e deallocazione della memoria Compilazione di un programma Spazio

Dettagli

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio.

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio. Testo Esercizio Si consideri un sistema per la gestione di un magazzino di un negozio scelto a piacere dal candidato Il sistema è in grado di gestire le seguenti operazioni: Arrivo di nuovi prodotti; Controllo

Dettagli

Lezione 4. Modello EER

Lezione 4. Modello EER Lezione 4 Modello EER 1 Concetti del modello EER Include tutti i concetti di modellazione del modello ER Concetti addizionali: sottoclassi/superclassi, specializzazione, categorie, propagazione (inheritance)

Dettagli

Indice. Prefazione alla seconda edizione italiana XVII. Introduzione. Parte 1 Introduzione all UML e all UP 1

Indice. Prefazione alla seconda edizione italiana XVII. Introduzione. Parte 1 Introduzione all UML e all UP 1 00PrPag 19-07-2006 15:22 Pagina V Prefazione alla seconda edizione italiana Introduzione XV XVII Parte 1 Introduzione all UML e all UP 1 Capitolo 1 UML 3 1.1 Contenuto del capitolo 3 1.2 Cos è l UML? 3

Dettagli

Progettazione del Software A.A.2008/09

Progettazione del Software A.A.2008/09 Laurea in Ing. Informatica ed Ing. dell Informazione Sede di latina Progettazione del Software A.A.2008/09 Domenico Lembo* Dipartimento di Informatica e Sistemistica A. Ruberti SAPIENZA Università di Roma

Dettagli

Object Oriented Software Design

Object Oriented Software Design Dipartimento di Informatica e Sistemistica Antonio Ruberti Sapienza Università di Roma Object Oriented Software Design Corso di Tecniche di Programmazione Laurea in Ingegneria Informatica (Canale di Ingegneria

Dettagli

Cardinalità e identificatori. Informatica. Generalizzazioni. Generalizzazioni. Generalizzazioni. Generalizzazioni

Cardinalità e identificatori. Informatica. Generalizzazioni. Generalizzazioni. Generalizzazioni. Generalizzazioni e identificatori Codice (0,1) (1,1) Dirige Informatica Lezione 8 Laurea magistrale in Scienze della mente Laurea magistrale in Psicologia dello sviluppo e dell'educazione Anno accademico: 2012 2013 1 Cognome

Dettagli

Progettazione orientata agli oggetti Introduzione a UML

Progettazione orientata agli oggetti Introduzione a UML Progettazione orientata agli oggetti Introduzione a UML Claudia Raibulet raibulet@disco.unimib.it Il processo di sviluppo software Rappresenta un insieme di attività per la specifica, progettazione, implementazione,

Dettagli

Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica.

Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica. Progettazione logica Lo schema concettuale risultante dalla progettazione concettuale è l input alla fase di progettazione logica. La progettazione logica è basata su un particolare modello logico dei

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Il meccanismo dell ereditarietà a.a. 2008/2009 Claudio De Stefano 1 L ereditarietà consente di definire nuove classi per specializzazione o estensione di classi preesistenti,

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Principi di programmazione OO

Principi di programmazione OO Principi di programmazione OO Ing. Paolo Vaccari Giovedì 9 e 16 Marzo 2006 Corsi Speciali L.143/04 - SSIS TOSCANA 2005/2006 Principi di programmazione OO Prima lezione: Programmazione

Dettagli

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9

!#$%&&'()#*%+%+!#$',,'()#*%+ -)%*&'&'+'$.)+-$$%&&) !#$%&&'(%)'*+%,#-%#.'%&'#/0)-+#12+3,)4+56#7+#.')8'9 !"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&)!"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9 Slide 1 Paradigmi di Programmazione! Un linguaggio supporta uno stile di programmazione se

Dettagli

Statechart Diagrams. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

Statechart Diagrams. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Statechart Diagrams Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Agenda Cosa è uno Statechart Diagram Quando

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13 Raccolta dei Requisiti con i Casi D'uso Corso di Ingegneria del Software Anno Accademico 2012/13 I casi d uso I casi d'uso (use case) sono una tecnica utilizzata per identificare i requisiti funzionali

Dettagli

Progettazione ad oggetti

Progettazione ad oggetti Progettazione ad oggetti Gli elementi reali vengono modellati tramite degli oggetti Le reazioni esistenti nel modello reale vengono trasformate in relazioni tra gli oggetti Cos'è un oggetto? Entità dotata

Dettagli

Dalla progettazione concettuale alla modellazione di dominio

Dalla progettazione concettuale alla modellazione di dominio Luca Cabibbo A P S Analisi e Progettazione del Software Dalla progettazione concettuale alla modellazione di dominio Capitolo 91 marzo 2015 Se qualcuno vi avvicinasse in un vicolo buio dicendo psst, vuoi

Dettagli

Progettazione Logica. Progettazione Logica

Progettazione Logica. Progettazione Logica Consorzio per la formazione e la ricerca in Ingegneria dell'informazione Tabelle per ogni concetto Docente: Cesare Colombo CEFRIEL colombo@cefriel.it http://www.cefriel.it Passaggio al modello logico (1)

Dettagli

Progetto Finale: Progettazione di un database e di una applicazione

Progetto Finale: Progettazione di un database e di una applicazione Progetto Finale: Progettazione di un database e di una applicazione Roberto Basili Corso di Basi Di Dati a.a. 2002-2003 Norme Generali Il progetto fa parte della valutazione gobale del corso e la data

Dettagli

PROGETTAZIONE CONCETTUALE

PROGETTAZIONE CONCETTUALE PROGETTAZIONE CONCETTUALE 1 Il Modello Concettuale Nella progettazione concettuale la descrizione dei dati da rappresentare avviene a livello astratto indipendentemente dal computer e dal software utilizzato.

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere.

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere. UML e i Casi d USO I casi d uso specificano una sequenza di azioni che producono un risultato visibile agli attori del sistema. Essi nascono per fornire descrizioni delle capacità del sistema. I casi d

Dettagli

Diagrammi di Flusso dei Dati

Diagrammi di Flusso dei Dati Ingegneria del Software Diagrammi di Flusso dei Dati Corso di Ingegneria del Software Anno Accademico 2012/2013 Lucidi liberamente tratti dalle dispense online del prof. Lucio Sansone, Univ. di Napoli

Dettagli

Fondamenti di Informatica 1. Prof. B.Buttarazzi A.A. 2010/2011

Fondamenti di Informatica 1. Prof. B.Buttarazzi A.A. 2010/2011 Fondamenti di Informatica 1 Prof. B.Buttarazzi A.A. 2010/2011 Sommario Paradigma OO Incapsulamento Polimorfismo e Overloading Ereditarietà e Overriding Esercizi svolti Esercizi proposti Paradigma OO Le

Dettagli

Data Base. Prof. Filippo TROTTA

Data Base. Prof. Filippo TROTTA Data Base Definizione di DataBase Un Database può essere definito come un insieme di informazioni strettamente correlate, memorizzate su un supporto di memoria di massa, costituenti un tutt uno, che possono

Dettagli

UML. Una introduzione incompleta. UML: Unified Modeling Language

UML. Una introduzione incompleta. UML: Unified Modeling Language UML Una introduzione incompleta 1/23 UML: Unified Modeling Language Lo Unified Modeling Language (UML) è una collezione di notazioni grafiche che aiuta a progettare sistemi software, specialmente quelli

Dettagli

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche.

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Si consideri la realizzazione di un semplice programma grafico per il disegno di figure geometriche in due dimensioni. Si analizzino i requisiti e se ne rappresentino i risultati in UML

Dettagli

Lezione 1. Introduzione e Modellazione Concettuale

Lezione 1. Introduzione e Modellazione Concettuale Lezione 1 Introduzione e Modellazione Concettuale 1 Tipi di Database ed Applicazioni Database Numerici e Testuali Database Multimediali Geographic Information Systems (GIS) Data Warehouses Real-time and

Dettagli

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA DISPENSA DEL CORSO DI SISTEMI INFORMATIVI Prof. Carlo Combi DFD Appunti a cura di E. Peri M. Devincenzi Indice 1

Dettagli

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it Programmazione II Lezione 4 Daniele Sgandurra daniele.sgandurra@iit.cnr.it 30/09/2011 1/46 Programmazione II Lezione 4 30/09/2011 Sommario 1 Esercitazione 2 Panoramica della Programmazione Ad Oggetti 3

Dettagli

Casi d uso (use cases)

Casi d uso (use cases) Casi d uso (use cases) proposti da Ivar Jacobson nel 1992 termine nuovo, ma tecnica consolidata (studio degli scenari di operatività degli utilizzatori di un sistema) sono i modi in cui il sistema può

Dettagli

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP)

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) 12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica,

Dettagli

Organizzazione delle informazioni: Database

Organizzazione delle informazioni: Database Organizzazione delle informazioni: Database Laboratorio Informatico di base A.A. 2013/2014 Dipartimento di Scienze Aziendali e Giuridiche Università della Calabria Dott. Pierluigi Muoio (pierluigi.muoio@unical.it)

Dettagli

Corso di Basi di Dati A.A. 2013/2014

Corso di Basi di Dati A.A. 2013/2014 Corso di Laurea in Ingegneria Gestionale Sapienza - Università di Roma Corso di Basi di Dati A.A. 2013/2014 8 - Progettazione Concettuale Tiziana Catarci, Andrea Marrella Ultimo aggiornamento : 27/04/2014

Dettagli

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

Sistemi Informativi e Basi di Dati

Sistemi Informativi e Basi di Dati Sistemi Informativi e Basi di Dati Laurea Specialistica in Tecnologie di Analisi degli Impatti Ecotossicologici Docente: Francesco Geri Dipartimento di Scienze Ambientali G. Sarfatti Via P.A. Mattioli

Dettagli

Associazioni. Informatica. Associazioni. Associazioni. Associazioni. Attributi. Possono esistere associazioni diverse che coinvolgono le stesse entità

Associazioni. Informatica. Associazioni. Associazioni. Associazioni. Attributi. Possono esistere associazioni diverse che coinvolgono le stesse entità Informatica Possono esistere associazioni diverse che coinvolgono le stesse entità Lezione 7 Lavora a Laurea magistrale in Scienze della mente Laurea magistrale in Psicologia dello sviluppo e dell'educazione

Dettagli

1.1 I componenti di un DBMS... 5

1.1 I componenti di un DBMS... 5 Indice 1 Introduzione ai DBMS.......................................................... 1 1.1 Scopi di un DBMS............................................................ 1 1.2 Modelli dei dati..............................................................

Dettagli

Progettazione di Basi di Dati

Progettazione di Basi di Dati Progettazione di Basi di Dati Prof. Nicoletta D Alpaos & Prof. Andrea Borghesan Entità-Relazione Progettazione Logica 2 E il modo attraverso il quale i dati sono rappresentati : fa riferimento al modello

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

I database. Cosa sono e a cosa servono i Database

I database. Cosa sono e a cosa servono i Database I database Estratto dal Modulo 1 - I database Prof. Piero GALLO 1 Cosa sono e a cosa servono i Database Un database(o base di dati) e' una raccolta organizzata di dati correlati. Il principale scopo di

Dettagli

Informatica. Prof. A. Longheu. Introduzione ai Linguaggi Object-Oriented

Informatica. Prof. A. Longheu. Introduzione ai Linguaggi Object-Oriented Informatica Prof. A. Longheu Introduzione ai Linguaggi Object-Oriented 1 Generalità programmazione OO La programmazione ad oggetti è un particolare modo di scrivere il programma. Si prevede che: 1) si

Dettagli

Introduzione a Classi e Oggetti

Introduzione a Classi e Oggetti Introduzione a Classi e Oggetti Oggetto: concetto astratto Entità di un programma dotata di tre proprietà caratteristiche stato informazioni conservate nell oggetto condizionano il comportamento dell oggetto

Dettagli

Introduzione al data base

Introduzione al data base Introduzione al data base L Informatica è quella disciplina che si occupa del trattamento automatico dei dati con l ausilio del computer. Trattare i dati significa: raccoglierli, elaborarli e conservarli

Dettagli