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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 11 + Credits I lucidi di questa lezione sono stati preparati da: Professor Stefano Mizzaro Professor Paolo Coppola e sono stati modificati e completati dal Dr. Paolo

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

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

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

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

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

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

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

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

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

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

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

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/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

Sequence Diagram e Collaboration Diagram

Sequence Diagram e Collaboration Diagram Sequence Diagram e Collaboration Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Sommario Interaction

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

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

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 3. LEZIONE 7: Fondamenti di programmazione orientata agli oggetti (1)

Informatica 3. LEZIONE 7: Fondamenti di programmazione orientata agli oggetti (1) Informatica 3 LEZIONE 7: Fondamenti di programmazione orientata agli oggetti (1) Modulo 1: Introduzione: oggetti e classi Modulo 2: Link e associazioni Modulo 3: Aggregazione Informatica 3 Lezione 7 -

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

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 Applicazioni Web

Progettazione di Applicazioni Web 1 Argomenti della lezione Progettazione di Applicazioni Web Sviluppo delle applicazioni Processo di sviluppo Formalismi grafici di supporto diagrammi UML (cenni) Scelta dell architettura Sviluppo di applicazioni

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

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

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

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

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari 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

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

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

Programmazione in Java (I modulo) Lezione 3: Prime nozioni

Programmazione in Java (I modulo) Lezione 3: Prime nozioni Programmazione in Java (I modulo) Lezione 3: Prime nozioni La volta scorsa Abbiamo avuto un primo assaggio! Abbiamo visto come usare l editor per scrivere un programma Java. Abbiamo analizzato riga per

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

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

Progettazione concettuale usando il modello Entità-Relazione (ER) e Progettazione Logica

Progettazione concettuale usando il modello Entità-Relazione (ER) e Progettazione Logica Progettazione concettuale usando il modello Entità-Relazione (ER) e Progettazione Logica 1 Introduzione alla progettazione delle basi di dati v Progettazione concettuale (in questa fase si usa il modello

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

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

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

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

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

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 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

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

Un modello è ragionevole quando contiene queste tre caratteristiche.

Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Si consideri un agenzia che opera come biglietteria ferroviaria, aerea e navale, accettando diversi modi di pagamento. Si identifichino le principali entità coinvolte illustrando le gerarchie

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

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

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

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 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

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

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

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

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

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

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

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

Object Model: Diagrammi di classe

Object Model: Diagrammi di classe Object Model: Diagrammi di classe A seconda dell ambito, si incontrano diversi modi per designare un oggetto oppure per designare una classe. Oggetto Entità Istanza Occorrenza Concetto Tipo di entità Classe

Dettagli

LE BASI DI DATI. Seconda parte La progettazione di database Relazionali SCHEMA CONCETTUALE LE ASSOCIAZIONI

LE BASI DI DATI. Seconda parte La progettazione di database Relazionali SCHEMA CONCETTUALE LE ASSOCIAZIONI LE BASI DI DATI Seconda parte La progettazione di database Relazionali SCHEMA CONCETTUALE LE ASSOCIAZIONI L'associazione (in inglese Relationship) descrive eventuali legami concettuali tra una, due o più

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

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

L applicazione di MVC alla simulazione di ascensore I COMPONENTI DELLE INTERFACCE UTENTE GRAFICHE: PARTE II 1

L applicazione di MVC alla simulazione di ascensore I COMPONENTI DELLE INTERFACCE UTENTE GRAFICHE: PARTE II 1 I COMPONENTI DELLE INTERFACCE UTENTE GRAFICHE: PARTE II 1 3.13 (Caso di studio facoltativo) Pensare a oggetti: Modello-Vista-Controllore I design pattern descrivono strategie efficaci per costruire sistemi

Dettagli

Diagrammi dei package

Diagrammi dei package Diagrammi dei package Package Meccanismo di raggruppamento di più classi (riferito al momento della compilazione) in unità di livello più alto, al fine di dominare la complessità strutturale di un sistema

Dettagli

Rappresentazione grafica di entità e attributi

Rappresentazione grafica di entità e attributi PROGETTAZIONE CONCETTUALE La progettazione concettuale, ha il compito di costruire e definire una rappresentazione corretta e completa della realtà di interesse, e il prodotto di tale attività, è lo schema

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

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

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

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

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

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

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

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Un negozio di musica vende anche libri e riviste musicali. Si intende automatizzare l intero processo, dall approvvigionamento alla vendita. Si analizzino i requisiti e se ne rappresentino

Dettagli

Esercizi di Ingegneria del Software

Esercizi di Ingegneria del Software Esercizi di Ingegneria del Software Il caso della Grande Distribuzione V. Ambriola, C. Montangero e L. Semini Corso di Laurea in Informatica Corso di Laurea in Informatica Applicata Dipartimento di Informatica

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

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

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

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

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

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