I class diagram. Class - names

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "I class diagram. Class - names"

Transcript

1 I class diagram Forniscono una vista strutturale (statica) del sistema in termini di classi attributi operazioni relazioni tra classi (associazioni, generalizzazioni,...) Un class diagram rappresenta uno schema concettuale se una classe A è in relazione con una classe B, allora ogni istanza di A sarà in relazione con un istanza di B 1 Class - names name Libro cod_libro titolo data edizione ISDN data acquisizione richiesta( ) restituzione( ) create( ) attributes Una class può essere rappresentata anche usano solo la sezione del nome Libro Un nome può essere un: simple name, il solo nome della class path name, il nome della class preceduto dal nome del package in cui la classe è posta operations Cliente Libro simple names Magazzino::Cliente Graphics::Rettangolo path names 2 1

2 Class - Attributes Attributes Una classe può avere un qualsiasi numero di attributi, o nessuno Per ciascun attributo si può specificare il tipo ed un eventuale valore iniziale tipicamente il nome di un attributo è composto da una parola o più parole insieme, usare il maiuscolo per la prima lettera di ciascuna parola lasciando minuscola la lettera iniziale del nome Scaffale altezza: Float larghezza: Float profondità: Float numeroscansie: Int èpieno: Boolean=false 3 Class - Operations Operations Una classe può avere un qualsiasi numero di operations, o nessuna Per ciascun operation si può specificare il solo nome o la sua signature, indicando il nome, il tipo, parametri e, in caso di funzione, il tipo ritornato stesse convenzioni dette per attributes per l uso di minuscolo e maiuscolo per i nomi delle operations SensoreTemperatura reset() setalarm(t:temperatura) leggival():temperatura 4 2

3 Class - Attributes e Operations Attributes e Operations di una class non devono obbligatoriamente essere descritti tutti subito Attributi ed operations possono essere mostrati solo parzialmente, elidendo la class Una sezione vuota non indica necessariamente che non esistono attributes/operations Per indicare che esistono più attributes/operations di quelli mostrati usare i punti sospensivi. Per meglio organizzare lunghe liste di attributes/operations raggrupparli insieme in categorie usando stereotypes Agente Finanziario. <<costruttore>> new() new(p: Polizza). <<query>> èsolvibile(o:ordine) èemesso(o:ordine) 5 Visibility E possibile specificare la visibiltà di attributes e operations La visibilità di un elemento specifica se esso può essere usato da altri. In UML è possibile specificare tre livelli di visibilità - public: qualsiasi altro classifier con visibilità al dato classifier può usare l elemento; è utilizzato il simbolo + (è il default se nessun simbolo è indicato) - protected: qualsiasi discendente del classifier può usare l elemento; è usato il simbolo # - private: solamente il classifier stesso può usare l elemento ; è usato il simbolo - Libro Visibility per attributes ed operations di una class + cod_libro + titolo # data edizione ISDN #richiesta( ) restituzione( ) + create( ) 6 3

4 Multiplicity La multiplicity è usata per indicare il numero di istanze di una classe; una multiplicity pari a zero indicherà una classe astratta, una multiplicity pari ad uno una singleton class; per default è assunta una multiplicity maggiore di uno. La multiplicity di una class è indicata con un numero intero posto nell angolo in alto a destra del simbolo della class La multiplicity si applica anche agli attributi, indicandola tra [ ] NetworkController 1 consoleport [2..*]: Port ControlRod 4 7 Class - Attributes e Operations La sintassi completa per specificare un attribute in UML è: [visibility] name [ [multiplicity] ] [: type] [= inital-value] [{property-string}] dove property-string può assumere uno dei seguenti 3 valori: changeable nessuna limitazione per la modifica del valore dello attribute addonly per attributi con molteplicità maggiore di 1 possono essere aggiunti ulteriori valori, ma una volta creato un valore non può essere né rimosso né modificato frozen il valore non può essere modificato dopo la sua inizializzazione 8 4

5 Class - Attributes e Operations La sintassi completa per specificare un operation in UML è: [visibility] name [(parameter-list)] [:return-type] [{propertystring}] con la lista dei parametri avente questa sintassi [direction] name: type [=default-value] dove direction può assumere uno dei seguenti 3 valori: in parametro di input out parametro di output inout parametro di input/output 9 Class - Attributes e Operations property-string può assumere uno dei seguenti valori isquery l esecuzione dell operazione lascia lo stato del sistema immutato sequential i chiamanti devono coordinare l oggetto dall esterno in modo che vi sia un sol flusso per volta verso l oggetto; in presenza di più flussi di controllo, non è garantita la semantica e l integrità dell oggetto guarded la semantica e l integrità dell oggetto è garantita in presenza di flussi di controllo multipli dalla sequenzializzazione di tutte le chiamate a tutte le operation guarded dell oggetto; concurrent la semantica e l integrità dell oggetto è garantita in presenza di flussi di controllo multipli trattando la operation come atomica. Chiamate multiple da flussi di controllo concorrente possono presentarsi contemporaneamente ad un oggetto o ad una sua operation concurrent ed essere eseguite correttamente con corretta semantica Le ultime tre proprità riguardano la concorrenza di una operation Sono rilevanti solo in presenza di oggetti attivi, processi o threads 10 5

6 Class Abstract, root, leaf e polymorphic elements Le classi astratte sono indicate ponendo il nome in corsivo Per specificare che una class non può avere : - discendenti indicare la proprietà leaf sotto il suo name - avi indicare la proprietà root sotto il suo name Per indicare una operation astratta scrivere il suo nome in corsivo Una operazione con la stessa signature in più classi di una gerarchia di generalizzazione/specializzazione è polimorphic ClassA {root} ClassB ClassC {leaf} 11 Relationships Una relationship è una connessione tra things. Dependency relazione semantica tra due things in cui un cambiamento su una (quella indipendente) può influenzare la semantica dell altra (quella dipendente), ma non necessariamente anche l inverso. 12 6

7 Relationships La freccia punta verso la thing indipendente Una dependency indica un uso di una thing da parte di un altra (ciò spesso è mostrato dall indicazione in una signature di una operation di un argomento dell altra class) Una relationship può avere un nome UML defisce 17 stereotypes (organizzati in 6 gruppi) per che possono essre applicati a dependency VideoRegistratore name playon(c:channel) start() stop() reset() Channel 13 Dipendenza tra classi Esempi di dipendenza tra classi C1 e C2: Un metodo di C1 ha come parametro un oggetto di classe C2 Un metodo di C1 restituisce come risultato un oggetto di classe C2 Un metodo di C1 istanzia un oggetto di classe C2 Un metodo di C1 invia un messaggio ad un oggetto di classe C2 di cui possiede il riferimento 14 7

8 Dipendenza tra classi <<instantiates>> Un metodo di una classe crea istanze di un altra classe <<calls>> Un metodo di una classe chiama un metodo di un altra classe <<friend>> Indica la possibilità di accesso al contenuto di un altra classe indipendentemente dalla visibilità prevista dalla classe target <<usage>> Indica che un elemento richiede la presenza di un altro per il suo corretto funzionamento (comprende <<calls>>, <<instantiates>>) 15 Relationships Generalization relazione di generalizzazione/specializzazione, in cui oggetti dell elemento specializzato (figlio) sono sostituibili all oggetto generalizzato (genitore). I figli condividono la struttura ed il comportamento del genitore. la freccia punta al genitore Una class può avere zero, uno o più genitori; se non ha genitori è detta root class, se ha un solo genitore è detta a singola ereditarietà, se ha più genitori è detta ad ereditarietà multipla 16 8

9 Relationships Generalization UML definisce 4 constraints per la Generalization: complete : tutte le sottoclassi sono state specificate, nessun altra sottoclasse è permessa incomplete : non tutte le sottoclassi sono state specificate, altre sottoclassi sono permesse disjoint : oggetti del genitore possono avere non più di un figlio come tipo overlapping : oggetti del genitore possono avere più di un figlio come tipo 17 Forma {root} display() Rettangolo {leaf} Ellisse Poligono display() Circonferenza {leaf} 18 9

10 Relationships Association relazione strutturale che descrive un insieme di link, cioè connessioni tra oggetti. Un particolare tipo di associazione è l aggregazione tra un tutto e le sue parti. Multiplicity Ditta 1 1..* datorelavoro impiegato Persona Role name Una association può avere un name ed una name direction name direction Ditta Lavora per name Persona 19 Cardinalità Indica il numero di istanze di una classe che possono essere associate ad una singola istanza dell altra classe Può non essere specificata ad uno degli estremi ( association-end ) o a entrambi E in questo caso non significa cardinalità pari a 1! 20 10

11 Cardinalità 21 Associazioni n-arie Alcune associazioni con cardinalità maggiore di due non sono riducibili a semplici associazioni binarie

12 Ruoli nelle associazioni Una classe può partecipare ad un associazione con un ruolo specifico, che può essere indicato 23 Relationships Aggregation Un particolare tipo di association è la aggregation che indica una relazione tutto-parti Tutto Ditta 1 Parte * Dipartimento aggregation 24 12

13 Relationships Compositon Un particolare tipo di aggregation è la compositon che indica una relazione una stretta relazione tutto-parti, nel senso che ciascuna parte ha la stessa durata di vita del tutto (cioè una parte una volta creata vive per tutto e solo il tempo del Tutto cui appartiene). Ciò significa anche che una parte può appartenere ad un solo tutto per volta. Tutto Finestra 1 Parte * Anta composition 25 Relationships Association qualifier Una association può avere un qualifier, cioè un attributo (o insieme di attributi) il cui valore partiziona un insieme di oggetti (detti targets) associati ad un altro oggetto (detto source). Il qualifier è attaccato alla source class di una association e determina come gli oggetti della class target sono partizionati e identificati Definisce la regola con cui associare gli oggetti nella relazione qualifier Dipartimento nomedip Professore 26 13

14 Relationships Association interface specifier Una association può avere un interface specifier, per specificare quale parte dell interfaccia di una classe è mostrata da questa, in una association, nei confronti di un altra classe della stessa association. intefafce spcifier worker : IEmployee Persona * 1 supervisor: IManager Persona nel ruolo di supervisor presenta solo la faccia IManager al worker; Persona nel ruolo di worker presenta solo la faccia IEmployee al supervisor. E utilizzata una notazione esplicita del tipo di ruolo usando la sintassi: rolename : iname 27 Relationships Association class Una association può essere caratterizzata da una association class, ovvero un gruppo di cartteristiche appartenenti alla relazione e che non sono proprie di nessuna classe coinvolta in questa. Ditta 1 1..* datorelavoro impiegato Persona Lavoro descrizione dataassunzione salario association class Possono essere viste come association con proprietà di class o class con proprietà di association 28 14

15 Associazioni riflessive Una associazione o aggregazione si dice riflessiva ( o ricorsiva) se coinvolge oggetti della stessa classe una associazione ricorsiva indica che più oggetti della stessa classe interagiscono e collaborano in qualche modo 29 Relationships Realization Una association può essere una realization, ovvero una relationship tra elementi in cui uno specifica un contratto che l altro garantisce di compiere. E un incrocio tra dependency e generalization; usata principalmente in due circostanze: contesto delle interface e delle collaboration. la freccia punta al classifier che definisce il contratto <<interface>> IruleAgent addrule() changerule() explainaction() realization RegolamentazioneConto 30 15

16 Interfaccia (Definizione) Specifica il comportamento di una classe senza darne l implementazione 31 Interfaccia (Uso) 32 16

17 Class diagrams Un class diagram rappresenta un insieme di class, interface, collaboration e le loro relationship specifica, mediante le association, i vincoli che legano tra loro le classi e le dipendenze tra queste modellano la vista di statica di un sistema, che supporta principalmente i requisiti funzionali del sistema se includono active class descrivono la vista statica di un processo di un sistema 33 Class diagrams Un class diagram è tipicamente usato per modellare: il dominio del sistema il glossario di un sistema sono prese decisioni relativamente alle astrazioni da considerare lo schema concettuale di un database Un class diagram possiede un nome significativo che comunica il suo scopo, può contenere note e costraints, package o subsystem

18 Class diagrams generalization (genitore- figlio) Libro cod_libro titolo data edizione ISDN data acquisizione richiesta( ) restituzione( ) create( ) Libro antico valore valorizza( ) 0..* 1..* 0..* pubblicato da relationship scritto da 0..* 1 0..* Editore ragione sociale nome breve indirizzo sede telefono variazione dati editore( ) Autore nome : type = initval cognome : type = initval anno nascita anno morte Utente variazione anagrafica( ) variazioneanagrafica( ) 35 Ditta * 1..* Dipartimento nome: Nome Location * * 1..* Ufficio indirizzo: String telefono: Number member * manager Persona nome: Nome matricola: Integer posizionelav: String getcontactinfo() getschedapersonale() getfoto() * 1..* 1 ContactInfo address: String SedeCentrale ISecureInfo 36 18

19 Class diagrams Un class diagram ben strutturato è incentrato sul comunicare un solo aspetto della vista dello static design contiene solamente gli elementi che sono essenziali a comprendere quell aspetto fornisce dettagli consistenti con il suo livello di astrazione, con solo quegli adornments che sono essenziali alla comprensione non è così minimalista da disinformare il lettore circa la reale semantica non possiede troppi tipi di relationships (se si hanno relationship complicate è meglio mettere tali elementi in un ulteriore diagramma di dettaglio) ha un lay out che ne facilita la lettura ed evidenzia i vari componenti ha un nome significativo possiede, eventualmente, note e colori per evidenziare aspetti particolari 37 Linee Guida per costruire un class diagram Obiettivo: identificare e caratterizzare gli elementi del modello a oggetti e come sono in relazione tra loro Non cercare di mettere tutto su un solo diagramma, specie per sistemi di grosse dimensioni Eventualmente disegnare un diagramma per ogni vista del sistema Ogni diagramma deve avere uno scopo: mostrare le classi e gli oggetti che partecipano in ogni singola collaborazione mostrare una tassonomia di generalizzazione mostrare la suddivisione delle partizioni logiche (packages) E possibile non mostrare attributi ed operazioni delle classi per migliorare la leggibilità del diagramma 38 19

20 Linee Guida per costruire un class diagram Identificare le classi di oggetti Preparare un dizionario dei dati Identificare le associazioni (incluse specializzazioni ed aggregazioni) tra classi Identificare gli attributi delle classi Identificare le operazioni L ordine non è rigido e sono possibili più iterazioni 39 Identificare le classi di oggetti Cosa cercare oggetti fisici, altri sistemi, dispositivi esterni, eventi da ricordare, ruoli, locazioni, unità organizzative Dove cercare conoscenza generale del problema, descrizioni testuali, figure Cosa considerare candidati aventi confini ben definiti e identità distinte candidati con proprietà da ricordare candidati che forniscono o richiedono servizi Scartare: candidati ridondanti, irrilevanti, o vaghi candidati che rappresentano singoli oggetti, o operazioni su oggetti, o ruoli in associazioni candidati legati alla realizzazione 40 20

21 Esempio: Problema del Bancomat Il sistema software da progettare per gestire una rete bancaria automatizzata prevede che i cassieri e gli sportelli automatici (Bancomat) siano condivisi da un consorzio di banche. Ogni banca fornisce il proprio computer per gestire i propri conti ed elaborare le transazioni su questi conti. I terminali dei cassieri sono posseduti dalle singole banche e comunicano direttamente con il computer della propria banca. I cassieri inseriscono dati su conti e transazioni. I Bancomat comunicano con un computer centrale che passa le transazioni alle banche appropriate. Un Bancomat accetta una scheda magnetica, interagisce con l utente, comunica con il sistema centrale per portare a termine la transazione, distribuisce il denaro, e stampa la ricevuta. Il sistema richiede appropriati provvedimenti per la registrazione e la sicurezza. Il sistema deve gestire correttamente accessi concorrenti allo stesso conto. Ogni banca fornirà il proprio software per il proprio computer; bisogna progettare il software per i Bancomat e per la rete. Il costo del sistema condiviso sarà distribuito proporzionalmente tra le banche secondo il numero di clienti con carta Bancomat. 41 Esempio: Identificare le classi di oggetti Classi selezionate Conto Bancomat Banca Scheda Cassiere Terminale del cassiere Cliente Transazione Classi scartate Vaghe» Sistema, Provvedimento di sicurezza» Provvedimento per la registrazione» Rete bancaria Singoli oggetti»consorzio Attributi» Dati del conto, Ricevuta, Contante» Dati della transazione Irrilevanti»Costo Realizzazione» Software 42 21

22 Preparare un dizionario dei dati Definire cosa la classe rappresenta nel contesto del problema Specificare quali sono le responsabilità della classe nel sistema Esempio Bancomat Conto Rappresenta un singolo conto di un cliente in una banca. Tutti gli accessi e le modifiche al conto della banca devono avvenire attraverso questa classe Transazione Remota Una richiesta integrale di operazioni sul conto effettuata dal cliente attraverso un Bancomat 43 Identificare le associazioni Cercare le dipendenze tra classi considerare le espressioni verbali nella descrizione del problema La relazione di aggregazione/composizione è un tipo speciale di associazione ( è parte di o si compone di ) Aggiungere i nomi alle associazioni o ai ruoli delle classi associate Specificare la molteplicità Scartare le associazioni: non rilevanti per il problema specifico troppo legate alla realizzazione derivabili da altre associazioni 44 22

23 Esempio: Identificare le associazioni 45 Identificare l ereditarietà Considerare solo classificazioni utili per il problema specifico Specializzazione E possibile raffinare una classe in sottoclassi con attributi e operazioni specifici? Generalizzazione E possibile identificare una superclasse che astrae attributi e operazioni comuni? Posizionare nella superclasse gli attributi e le operazioni comuni a tutte le sottoclassi 46 23

24 Esempio: Identificare l ereditarietà 47 Identificare gli attributi degli oggetti e dei legami Gli attributi necessari dipendono dal problema specifico In fase di analisi Si può non essere immediatamente esaustivi Si possono omettere attributi derivati attributi che descrivono stati interni alla classe 48 24

25 Esempio: Identificare gli attributi degli oggetti e dei legami 49 Identificare le operazioni Operazioni base (costruttore, selettore, distruttore) non è necessario esplicitarle nel diagramma; indicarle solo se utili nella comprensione del problema o se menzionate esplicitamente nella descrizione Altre operazioni Consultare gli scenari che descrivono i casi d uso Attribuire le funzionalità richieste alle classi identificate Considerare le operazioni che modificano lo stato degli oggetti Si può non essere immediatamente esaustivi 50 25

26 Esempio: Identificare le operazioni 51 Oggetti: Notazione grafica Un oggetto è un istanza di una classe Per rappresentare un oggetto si utilizza lo stesso simbolo usato per rappresentare le classi Il nome viene sottolineato per evidenziare che si tratta di un oggetto Analogamente a quanto accade per le classi è possibile decidere il livello di visibilita per attributi e valori 52 26

27 Object diagrams Un object diagram rappresenta un insieme di oggetti e le relazioni tra essi rappresentano una istanziazione di things di class diagrams rappresentano la vista statica di un sistema (o vista statica di un processo) ma dalla prospettiva di un caso reale, o prototipale 53 Object diagrams L:Libro cod_libro=xx111 Titolo= YYYYY data edizione=1/1/87 ISDN= data acquisizione=2/2/90 0..* pubblicato da 1 Ed:Editore ragione sociale=... nome breve=... indirizzo sede=... Telefono= * LA:Libro antico 0..* scritto da 0..* Aut: Autore nome =... cognome =... anno nascita=... anno morte=... Valore= * Utente 54 27

28 Classi: Implementazione Esiste una corrispondenza tra la rappresentazione UML di una classe e l implementazione con un linguaggio O-O (Es. Java) 55 Associazioni: Implementazione In generale non esiste un mapping diretto su un costrutto di un linguaggio di programmazione Possono essere implementate introducendo degli attributi ad hoc che contengono dei riferimenti (o puntatori) alle istanze delle classi associate Il riferimento a più istanze di una classe può essere modellato con liste, array, etc. Direzionalità In fase di implementazione si può decidere di codificarla solo in una delle due direzioni (con un puntatore), perdendo però così la possibilità di percorrere il link nella direzione opposta! 56 28

29 57 29

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

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

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

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

Linguaggi di Programmazione I Lezione 6

Linguaggi di Programmazione I Lezione 6 Linguaggi di Programmazione I Lezione 6 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 8 aprile 2008 Analisi di oggetti e classi 3 Introduzione............................................................

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

Analisi Modelli per la specifica dei requisiti

Analisi Modelli per la specifica dei requisiti 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

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

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

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist www.roccatello.it

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist <eduard.roccatello@3dgis.it> www.roccatello.it Modellazione e progettazione con UML Eduard Roccatello 3D GIS Specialist www.roccatello.it Object Oriented Analysis and Design Consente di modellare un sistema attraverso l

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

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

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

14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER

14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER 14. LA PROGETTAZIONE CONCETTUALE: IL DIAGRAMMA ER La progettazione concettuale consiste nel riorganizzare tutti gli elementi che si hanno a disposizione dopo la fase di raccolta delle richieste (utente),

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

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi Linguaggio Java Robusto Non permette costrutti pericolosi Eredità Multipla Gestione della Memoria Orientato agli oggetti Ogni cosa ha un tipo Ogni tipo è un oggetto (quasi) Protegge e gestisce dagli errori

Dettagli

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

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

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

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

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML)

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) a cura di Giacomo PISCITELLI Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Questi appunti sono ricavati da una

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

Unified Modeling Language -Class Diagram: concetti di base -

Unified Modeling Language -Class Diagram: concetti di base - Unified Modeling Language -Class Diagram: concetti di base - Henry Muccini Università degli Studi dell'aquila muccini@di.univaq.it http://www.henrymuccini.com Engineering IgTechnology Imola Informatica

Dettagli

progettare buone gerarchie

progettare buone gerarchie progettare buone gerarchie 1 generalizzazione permette di definire dettagli del modello a vari livelli di astrazione 2 generalizzazione le istanze delle classi più specifiche sono istanze anche delle classi

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

Progetto di Ingegneria del Software matricola 640926 MODELLAZIONE UML DI UN TERMINALE ATM. di Cavenaghi Mattia 03/04/2008 1/24

Progetto di Ingegneria del Software matricola 640926 MODELLAZIONE UML DI UN TERMINALE ATM. di Cavenaghi Mattia 03/04/2008 1/24 MODELLAZIONE UML DI UN TERMINALE ATM di Cavenaghi Mattia 03/04/2008 1/24 INDICE: Descrizione del problema pag. 3 Analisi dei requisiti pag. 3 Requisiti funzionali Requisiti non funzionali Requisiti tecnologici

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

Modulo 4: Ereditarietà, interfacce e clonazione

Modulo 4: Ereditarietà, interfacce e clonazione Modulo 4: Ereditarietà, interfacce e clonazione Argomenti Trattati: Classi, Superclassi e Sottoclassi Ereditarietà Ereditarietà ed Attributi Privati Override super Ereditarietà e Costruttori Polimorfismo

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

object oriented analysis

object oriented analysis object oriented analysis 1 attività di analisi l obiettivo dell analisi è raggiungere la piena comprensione del dominio di interesse lo strumento è la descrizione di un modello di dominio mediante un opportuno

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

1. Rappresentazione della conoscenza 2. Ontologie 3. Usi delle ontologie 4. Progettazione di un ontologia 5. Esempio di progettazione di una

1. Rappresentazione della conoscenza 2. Ontologie 3. Usi delle ontologie 4. Progettazione di un ontologia 5. Esempio di progettazione di una 1. Rappresentazione della conoscenza 2. Ontologie 3. Usi delle ontologie 4. Progettazione di un ontologia 5. Esempio di progettazione di una ontologia 1 Rappresentazione della conoscenza Il problema di

Dettagli

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

Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti 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

Dettagli

Database. Organizzazione di archivi mediante basi di dati. ing. Alfredo Cozzi 1

Database. Organizzazione di archivi mediante basi di dati. ing. Alfredo Cozzi 1 Database Organizzazione di archivi mediante basi di dati ing. Alfredo Cozzi 1 Il database è una collezione di dati logicamente correlati e condivisi, che ha lo scopo di soddisfare i fabbisogni informativi

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Progettazione del Software

Progettazione del Software Progettazione del Software Analisi: Introduzione ad UML & UML Class Diagrams Domenico Lembo Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Corso di Laurea in Ingegneria

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

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

DIAGRAMMI DI SEQUENZA

DIAGRAMMI DI SEQUENZA DIAGRAMMI DI SEQUENZA Francesco Poggi fpoggi@cs.unibo.it A.A. 2015-2016 Premessa As always, there is never a correct solution to any modelling problem. It s more that some models are more precise, and

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

Programmazione AA 2012 2013

Programmazione AA 2012 2013 Programmazione ad Oggetti AA 2012 2013 Contenuti del corso Modulo A Tecniche di programmazione Docente: Prof. Michele Bugliesi Modulo B Tecniche di progetto Docente: Prof. Alessandro Roncato Contenuti

Dettagli

Progettare un Database Geografico con UML

Progettare un Database Geografico con UML Progettare un Database Geografico con UML Claudio Rocchini (rockini@tele2.it) Istituto Geografico Militare Introduzione In questa breve nota si vuole introdurre i principi di progettazione tramite il linguaggio

Dettagli

Appunti sulla documentazione di un progetto software object oriented in linguaggio Java

Appunti sulla documentazione di un progetto software object oriented in linguaggio Java Appunti sulla documentazione di un progetto software object oriented in linguaggio Java Marco Liverani Luglio 2006 1 Introduzione Ogni progetto informatico è sicuramente incompleto fino a quando non viene

Dettagli

Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Automazione della gestione degli ordini d acquisto di una società di autonoleggio Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO

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

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

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

La Progettazione Concettuale

La Progettazione Concettuale La Progettazione Concettuale Università degli Studi del Sannio Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica CorsodiBasidiDati Anno Accademico 2006/2007 docente: ing. Corrado Aaron Visaggio

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

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

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36 10. Design Patterns Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 10. Design Patterns 1 / 36 Problemi Ci focalizziamo nelle problematiche riguardanti la

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

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale DIIGA - Università Politecnica delle Marche A.A. 2006/2007 Informatica Industriale Modello funzionale: Informazione Progettazione concettuale Luca Spalazzi spalazzi@diiga.univpm.it www.diiga.univpm.it/~spalazzi/

Dettagli

Paradigma object-oriented

Paradigma object-oriented Paradigma object-oriented Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced

Dettagli

Tipi di Dato Ricorsivi

Tipi di Dato Ricorsivi Tipi di Dato Ricorsivi Luca Abeni September 2, 2015 1 Tipi di Dato Vari linguaggi di programmazione permettono all utente di definire nuovi tipi di dato definendo per ogni nuovo tipo l insieme dei suoi

Dettagli

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

Outline. Programmazione ad oggetti in Java. La programmazione ad oggetti Classi e istanze Associazioni fra classi Incapsulamento Costruttori

Outline. Programmazione ad oggetti in Java. La programmazione ad oggetti Classi e istanze Associazioni fra classi Incapsulamento Costruttori Programmazione ad oggetti in Java Daniela Micucci Outline La programmazione ad oggetti Classi e istanze Associazioni fra classi Incapsulamento Costruttori 2 Programmazione ad oggetti in Java 1 OOP Java

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

Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008. Esercitazione. Programmazione Object Oriented in Java

Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008. Esercitazione. Programmazione Object Oriented in Java Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008 Alessandro Longheu http://www.diit.unict.it/users/alongheu alessandro.longheu@diit.unict.it Programmazione Object Oriented in Java

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia

Dettagli

Basi di dati. Maurizio Lenzerini. Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza. Anno Accademico 2011/2012

Basi di dati. Maurizio Lenzerini. Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza. Anno Accademico 2011/2012 Basi di dati Dipartimento di Informatica e Sistemistica Antonio Ruberti Università di Roma La Sapienza Anno Accademico 2011/2012 http://www.dis.uniroma1.it/~lenzerin/home/?q=node/44 4. La progettazione

Dettagli

Telematica II 17. Esercitazione/Laboratorio 6

Telematica II 17. Esercitazione/Laboratorio 6 Multitasking e Multithreading Telematica II 17. Esercitazione/Laboratorio 6 Multitasking si riferisce all abilità di un computer di eseguire processi (jobs) multipli in maniera concorrente si ricorda che

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

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

Il modello Entity-Relationship (ER)

Il modello Entity-Relationship (ER) Il modello Entity-Relationship (ER) Prof. Genny Tortora tortora@unisa.it Università di Salerno, a.a. 2010/2011 E.R.: Introduzione Il modello Entità-Relazione (ER) è un diffusissimo data model di alto livello,

Dettagli

Livelli di astrazione

Livelli di astrazione Realizzare Classi Astrazione Perdita di dettaglio Utile nella descrizione, progettazione, implementazione e utilizzo di sistemi complessi Dettagli trascurabili vengono incapsulati in sottosistemi più semplici

Dettagli

Metodologie per la Progettazione Concettuale

Metodologie per la Progettazione Concettuale Metodologie per la Progettazione Concettuale Raccolta e analisi dei requisiti Scegliere il corretto livello di astrazione Standardizzare la struttura delle frasi Evitare frasi contorte Individuare sinonimi

Dettagli

Corso Base. Liceo Norberto Rosa Bussoleno Prof. Angelo GIORGIO

Corso Base. Liceo Norberto Rosa Bussoleno Prof. Angelo GIORGIO Corso Base Liceo Norberto Rosa Bussoleno Prof. Angelo GIORGIO Java Java è un Linguaggio di Programmazione orientato agli oggetti. Un Linguaggio di Programmazione è un linguaggio ad alto livello, dotato

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

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

Proff. Fabio Ciao e Raffaele Bortone

Proff. Fabio Ciao e Raffaele Bortone ISTITUTO D ISTRUZIONE SUPERIORE FERRARIS BRUNELLESCHI - EMPOLI Materia: INFORMATICA PROGRAMMAZIONE ANNUALE A.S. 2014/2015 Classe IV C Informatica Proff. Fabio Ciao e Raffaele Bortone Libro di testo: Cloud

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

Programmazione a Oggetti Lezione 10. Ereditarieta

Programmazione a Oggetti Lezione 10. Ereditarieta Programmazione a Oggetti Lezione 10 Ereditarieta Sommario Come definire sottoclassi Costruttori Abstract Classes Final Ereditarietà: promemoria Strumento tipico dell OOP per riusare il codice e creare

Dettagli

ISTITUTO STATALE D ISTRUZIONE SUPERIORE FERRARIS - BRUNELLESCHI EMPOLI Anno scolastico 2014/2015

ISTITUTO STATALE D ISTRUZIONE SUPERIORE FERRARIS - BRUNELLESCHI EMPOLI Anno scolastico 2014/2015 ISTITUTO STATALE D ISTRUZIONE SUPERIORE FERRARIS - BRUNELLESCHI EMPOLI Anno scolastico 2014/2015 Classe: 4^A inf Prof.ssa Lami Carla Prof. Simone Calugi Programma di INFORMATICA GENERALE, APPLICAZIONI

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

Idee guida. Finite State Machine (1) Un automa a stati finiti è definito da una 5- pla: FSM = , dove: Finite State Machine (2)

Idee guida. Finite State Machine (1) Un automa a stati finiti è definito da una 5- pla: FSM = <Q,,, q0, F>, dove: Finite State Machine (2) Idee guida ASM = FSM con stati generalizzati Le ASM rappresentano la forma matematica di Macchine Astratte che estendono la nozione di Finite State Machine Ground Model (descrizioni formali) Raffinamenti

Dettagli

Se un oggetto A aggrega oggetti B allora avrà informazioni su di loro

Se un oggetto A aggrega oggetti B allora avrà informazioni su di loro Concetto di responsabilità nella progettazione guidata dalle responsabilità (RRD) si pensa in termini di responsabilità del software. Le responsabilità vengono assegnate agli oggetti durante la progettazione.

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

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

Allegato 2. Il modello GeoUML Regole di interpretazione delle specifiche di contenuto per i DataBase Geotopografici

Allegato 2. Il modello GeoUML Regole di interpretazione delle specifiche di contenuto per i DataBase Geotopografici DECRETO 10 novembre 2011 Regole tecniche per la definizione delle specifiche di contenuto dei database geotopografici. (Gazzetta Ufficiale n. 48 del 27/02/2012 - Supplemento ordinario n. 37). Allegato

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Descrizione Formale Esplicita Dominio

Descrizione Formale Esplicita Dominio Ontologia Abbiamo visto che tassonomie e tesauri fissano una semantica. Per arricchire la semantica si deve passare a modelli concettuali e teorie logiche. Un modello concettuale è il modello di una particolare

Dettagli

1. Analisi dei requisiti

1. Analisi dei requisiti 1. Analisi dei requisiti 1a. Requisiti espressi in linguaggio naturale 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Si vuole realizzare una base di dati

Dettagli

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Object Oriented Analysis - OOA La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME

Dettagli

PERSONA UOMO MILITARE

PERSONA UOMO MILITARE Capitolo 6 Esercizio 6.1 Considerare lo schema ER in figura 6.36: lo schema rappresenta varie proprietà di uomini e donne. Correggere lo schema tenendo conto delle proprietà fondamentali delle generalizzazioni.

Dettagli

Informatica Introduzione alle basi di dati

Informatica Introduzione alle basi di dati Informatica Introduzione alle basi di dati Prof. Giovanni Giuffrida e-mail: giovanni.giuffrida@dmi.unict.it 27 November 2014 Basi di Dati - Introd. - Prof. G. Giuffrida 1 Materiale didattico Atzeni,Ceri,Paraboschi,Torlone,

Dettagli

Protégé. Cos è un ontologia

Protégé. Cos è un ontologia Protégé Cos è un ontologia Un ontologia è una descrizione formale di concetti in un dominio (classi) le proprietà di ciascun concetto (slot) le restrizioni sugli slot (facets) ONTOLOGIA + UN INSIEME DI

Dettagli

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto)

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto) Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Sede di Latina Laurea in Ingegneria dell Informazione Fasi del ciclo di vita del software (riassunto) Corso di PROGETTAZIONE DEL SOFTWARE

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

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

Introduzione a UML 2.0 1 parte Iolanda Salinari

Introduzione a UML 2.0 1 parte Iolanda Salinari Introduzione a UML 2.0 1 parte Iolanda Salinari Per un introduzione generale ai diagrammi UML si rimanda al tutorial Introduzione UML presente su questo sito UML E un linguaggio che serve per visualizzare

Dettagli

Esercitazione n 4. Obiettivi

Esercitazione n 4. Obiettivi Esercitazione n 4 Obiettivi Progettare e implementare per intero un componente software in Java Linguaggio Java: Classi astratte Utilizzo di costruttori e metodi di superclasse Polimorfismo Esempio guida:

Dettagli

Comitato per le regole tecniche sui dati territoriali delle Pubbliche Amministrazioni Il Modello GeoUML

Comitato per le regole tecniche sui dati territoriali delle Pubbliche Amministrazioni Il Modello GeoUML Comitato per le regole tecniche sui dati territoriali delle Pubbliche Amministrazioni Il Modello GeoUML Regole di Interpretazione delle Specifiche di Contenuto per i Database Geotopografici Versione 1.1

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

Lezione 2. Il modello entità relazione

Lezione 2. Il modello entità relazione Lezione 2 Il modello entità relazione Pag.1 Introduzione alla progettazione delle basi di dati 1. Analisi dei requisiti Quali sono le entità e le relazioni dell organizzazione? Quali informazioni su queste

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

Dispensa 3. 1.1 YACC: generalità

Dispensa 3. 1.1 YACC: generalità Dispensa 3 1.1 YACC: generalità Il tool Yacc (acronimo per Yet Another Compiler Compiler) è uno strumento software che a partire da una specifica grammaticale context free di un linguaggio scritta in un

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

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