Ing. Andrea Bulgarelli UML 1.3
|
|
- Roberta Volpe
- 7 anni fa
- Visualizzazioni
Transcript
1 1. UNA BREVE INTRODUZIONE A UML UML Rappresentazione (perspective) USE CASES Costruzione di Use Cases Diagram Quando si utilizzano gli Use Case Diagram Esempio CLASS DIAGRAM Esempio CLASS DIAGRAM (CONCETTI AVANZATI) Generalizzazione ed ereditarietà INTERACTION DIAGRAM Sequence diagram Collaboration Diagram Quando utilizzare gli Interaction Diagram PACKAGE DIAGRAM STATE DIAGRAM ACTIVITY DIAGRAM Dead End e End Point Swimlanes Esempi IMPLEMENTATION DIAGRAM UTILIZZO DEI DIAGRAMMI
2 1. UNA BREVE INTRODUZIONE A UML UML UML è un linguaggio di modellazione, non un metodo. Infatti un metodo è in genere costituito da un linguaggio di modellazione e da un processo, dove il processo indica i passi necessari per eseguire il progetto, e il linguaggio di modellazione è una notazione che il metodo usa per rappresentare il progetto stesso. UML è quindi indipendente dal processo utilizzato nello sviluppo del software. Il processo è infatti scelto dal progettista, in base alle sue esperienze e al tipo di applicazione da sviluppare Rappresentazione (perspective) E importante avere chiaro fin dall inizio il punto di vista utilizzato nello sviluppo di un particolare modello del sistema in esame. Tre sono i differenti punti di vista: concettuale : consente di costruire un modello del sistema in esame rappresentando i concetti del dominio dell utente. Questo è il punto di vista utilizzato nel presente documento; di specificazione : è il primo passo verso il software, ma ci si occupa del software solo a livello di interfacce. Ci si muove non più nel dominio utente, ma nel dominio applicativo; implementativo: tale punto di vista consente di descrivere l implementazione del software. UML non distingue tra i tre punti di vista, permettendo di descrivere l applicazione in ognuno di essi. Uno dei punti di forza (comune comunque anche ad OMT) sta proprio in questa flessibilità. Lo svantaggio è comunque ovvio: se non si ha chiara la distinzione tra i tre punti di vista, è possibile costruire un modello derivante dall analisi non buono, cioè un modello di analisi che, anziché concentrarsi sull analisi del problema in esame, contiene già elementi di soluzione. 2
3 1.2 Use Cases Uno use case descrive una tipica interazione tra l utente 1 e il sistema in analisi. Tali iterazioni sono formalmente descritte mediante uno o più Use Case Diagram. Le primitive utilizzate nella costruzione di uno Use Case Diagram sono: actor: ruolo che l utente ha rispetto al sistema. use case: entità grafica che rappresenta tutto ciò che riguarda le funzionalità esterne richieste dal sistema. Specifica il comportamento di un sistema o di una parte di un sistema ed e una descrizione di un set di sequenze di azioni. Si usano per catturare il comportamento del sistema in esame, senza dover specificare come il comportamento è realizzato. Un actor esegue (nel senso che utilizza) uno o più use case. A sua volta uno use case può essere eseguito da più actor. Questa relazione tra actor e use case è stabilita mediante messaggi, come nella seguente figura: ChiedePreventivo Utente Acquista Figura 1: esempio di Use Case Diagram Possono essere presenti diversi tipi di relazioni tra use case: include : si verifica quando un determinato comportamento si ripete in più casi d uso e non si vuole ripetere la sua descrizione; generalizzazione : si utilizza quando un caso d uso è simile ad un altro ma fa qualcosa di più (generalizzazione nel senso dell estensione). Questo permette di rappresentare scenari alternativi. extend: è simile alla generalizzazione, ma ci sono più regole. Quando si utilizza questo costrutto il caso d uso che estende un caso base può aggiungervi comportamento, ma stavolta il caso d uso base deve 1 Non è detto che un utente debba essere inteso come umano. Può anche essere un sistema esterno che necessità di informazioni dal sistema in esame. 3
4 dichiarare dei punti di estensione e il caso che lo estende può aggiungere comportamento solamente in corrispondenza dei punti specificati Costruzione di Use Cases Diagram Nella costruzione di uno Use Case Diagram bisogna avere ben chiara la differenza tra: system interaction (interazione col sistema); user goals (obbiettivi dell utente). Spesso è presente una dicotomia tra questi due aspetti, che viene rilevata in fase di analisi dei requisiti 2. Per risolverla è possibile concentrarsi sugli obbiettivi dell utente e ottenere una serie di Use Case Diagram che descrivono le iterazioni col sistema necessarie per soddisfare gli obbiettivi dell utente. Per la costruzione del diagramma, è possibile partire da una lista di actor e poi passare agli use cases, selezionando il dettaglio che si ritiene più opportuno Quando si utilizzano gli Use Case Diagram Uno Use Case Diagram può essere utilizzato in modo molto efficace nei primi stadi del ciclo di vita del software, in particolare in fase di analisi. Tali diagrammi consentono di individuare con chiarezza gli obbiettivi dell utente e le interazioni del sistema con gli elementi esterni ad esso. Può anche essere utilizzato, vista la sua semplicità sintattica, come supporto nella fase di specificazione dei requisiti. Ogni use case può potenzialmente descrivere una caratteristica che il sistema deve soddisfare (ad esempio, svolgimento di particolari compiti, ecc.) Esempio L esempio riguarda la definizione dei flussi informativa in una Università. Livello di Facoltà ATTORI: Preside di Facoltà: è l utente definito per ciascuna Facoltà che ha i permessi relativi alla gestione e responsabilità completa sulle informazioni del Manifesto degli Studi e del Regolamento Didattico riguardanti la Facoltà di appartenenza. Dal punto di vista organizzativo si pensa che questa competenza sia delegata alle singole Segreterie di Facoltà. Referente/Presidente di Corso di Studio: è l utente definito per ciascun Corso di Studio che ha i permessi relativi alla gestione e responsabilità completa sulle informazioni del Manifesto degli Studi e del Regolamento Didattico relative al proprio Corso di Studio. 2 Ad esempio, costruire gli use case diagram focalizzando l attenzione solo sull iterazione col sistema può portare a non comprendere appieno quali sono le reali necessità dell utente. 4
5 Docente : è l utente che rappresenta il singolo docente incaricato di uno o più insegnamenti; ha il compito di inserire il programma, l eventuale materiale didattico ed i testi consigliati dell insegnamento, ed eventualmente alcune informazioni anagrafiche che lo riguardano. Tali informazioni sono pubblicate nei singoli siti web delle Facoltà. La competenza di queste informazioni è del singolo Docente. Delegato per l Orientamento di Facoltà: ha il compito di definire i tempi e le modalità di aggiornamento delle informazioni, di monitorarne il corretto svolgimento, di validare le informazioni inserite abilitandone la pubblicazione sul Portale di Ateneo in accordo con il Delegato per l Orientamento di Ateneo. Amministratore di Facoltà: ha il compito, a livello di Facoltà, di definire i singoli utenti, di definire/controllare i permessi di accesso alle informazioni, monitorare il corretto flusso delle informazioni nel rispetto della tempistica prevista. 5
6 <<include>> Gestione programma Docente Gestione Insegnamento <<include>> Gestione materiale didattico Referente/Presidente Corso di Studio Definizione Regolamento Didattico Preside di Facolta' Definizione Manifesto degli Studi Pubblicazione Regolamento Didattico Pubblicazione Manifesto degli Studi Figura 2: Use Case Diagram dell Offerta Didattica a livello di Facoltà 1.3 Class Diagram Una classe UML è indicata da un rettangolo suddiviso in tre parti distinte: nella prima parte è indicato il nome della classe; 6
7 nella seconda parte sono elencati gli attributi della classe: agli attributi viene associata una visibilità: + indica public, # indica protected e indica private. I simboli testuali possono essere sostituiti da rappresentazioni grafiche degli stessi concetti; nella terza parte sono indicate le operazioni della classe: vale anche in questo caso il discorso della visibilità del punto precedente. Le classi sono relazionate tra loro mediante associazioni. Le associazioni, oltre ad avere una cardinalità, possono anche avare un nome (role name) e possono essere navigabili (se sull associazione è specificata una freccia). La navigabilità indica come verrà realizzata l associazione da un punto di vista realizzativo Nella figura seguente si mostra il caso dell associazione fra l ordine e il cliente, in cui si è deciso che solo la classe Ordine deve mantenere la navigabilità, mentre la classe Cliente non implementa in alcun modo il collegamento verso Ordine. Cliente nome : String indirizzo : String Cliente() -c Ordine n_ordine : int priorita : int numero_linea : int data_emissione : java.util.date Ordine() evadi() aggiungi_linea() getlineaordine() evadilinea() Figura 3 Per la due classi sono anche stati elencati gli attributi e le operazioni associate. UML distingue due ulteriori tipi di associazione: l aggregazione, indicata con il rombo vuoto, che rappresenta una relazione di part-of in cui l oggetto può essere condiviso in aggregazione da altre classi; 7
8 la composizione, indicata con il rombo pieno, in cui si richiede la partecipazione esclusiva del composto nel componente, inoltre il componente è destinato a seguire le sorti del composto quando questo viene distrutto; Il seguente esempio illustra un esempio di uso delle due varianti di questo concetto: Poligono vertice 3..* Punto 1 centro Cerchio 0..* 0..* 1 Stile 1 Figura 4 Il punto in se viene visto come valore, e non viene condiviso dalle classi, mentre lo stile può essere condiviso da più classi (il che significa che lo stile è visto come un oggetto dotato di identità). Le gerarchia di generalizzazione (primitiva IS_A) è rappresentata da un collegamento terminante con una freccia vuota, come riportato nella seguente figura. Cliente Azienda Privato Figura Esempio Il class diagram di seguito riportato è relativo all organizzazione di una università. 8
9 Ateneo 1..* Dipartimento Orientamento 0..* 0..* 1..* Facolta 1 1..* Corso di Studio durata tipo 1 1..* 1..* 0..* Insegnamento Preside di Facolta' (from Facolta) 1..n Regolamento Didattico anno_corso periodo 1..* Referente/Presidente Corso di Studio (from Facolta) 1 Manifesto degli Studi Docente (from Facolta) Figura 6: Diagramma delle classi che rappresenta la struttura del livello di Ateneo 1.4 Class Diagram (concetti avanzati) Il diagramma delle classi di UML è molto simile a quello presente in OMT. E possibile affermare che tutte le primitive e la semantica di OMT sono racchiuse nel class diagram di UML, con qualche variazione relativamente all aspetto grafico. Ovviamente il class diagram di UML ha primitive in più. Le principali differenze rispetto ad OMT sono le seguenti: un diverso modo per indicare la molteplicità delle associazioni: simbolo significato * [0, + [ 9
10 a..b a..* [a, b] a > b [a, + [ E stata introdotta una sintassi specifica per le operazioni: visibility name (parameter list): return-type-expression {property string} dove: - visibility può essere: + (public), # (protected), - (private) 3 - name è una stringa - parameter list è una lista di argomenti (opzionale) è possibile indicare regole di restrizione, includendole in {}. Per la scrittura di tali regole, è possibile utilizzare linguaggio comune oppure l OCL. Tali regole possono essere applicate a associazioni, generalizzazione, attributi, ecc. si distingue tra aggregazione e composizione : con la composizione, la classe componente può appartenere solo ad una classe composta. Per tale motivo gli oggetti di tale classe componente hanno lo stessa durata degli oggetti della classe composta. E introdotto il concetto di interfaccia di una classe, che viene comunque implementata mediante classi astratte Si distingue tra reference object e value object. I value object sono gli oggetti che descrivono i tipi di dato, e sono immutabili. All interno di UML, gli attributi sono generalmente indicati per specificare i value object Generalizzazione ed ereditarietà Oltre ad avere la possibilità di indicare dei discriminatori (caratteristica presente comunque anche in OMT), è ora possibile indicare: classificazione singola e multipla: nel caso della classificazione multipla, una superclasse può essere specializzata in più sottoclassi è possibile marcare un discriminatore come {mandatory}, per specificare l obbligatorietà di una gerarchia classificazione statica o dinamica: la classificazione dinamica permette ad un oggetto di cambiare tipo all interno della struttura dei sottotipi. 3 E ovvio che questi concetti sono più utili per un punto di vista implementativo che non concettuale. 10
11 L esempio seguente riassume le tre caratteristiche descritte in precedenza: Male Female Sex Person {mandatory} Job <<dynamic>> Salesman Engineer Manager Figura 7 Esiste invece una differenza semantica sostanziale tra la generalizzazione implementata in OMT e quelle implementata in UML. In generale, la generalizzazione può essere utilizzata per estendere una superclasse (nel senso che una sottoclasse può aggiungere nuove caratteristic he) oppure per restringere una superclasse. La restrizione riguarda: una sottoclasse può vincolare gli attributi delle superclasse; una sottoclasse può inibire l uso di alcune operazioni di una superclasse; è possibile cambiare la signature e nome di alcune operazioni o attributi. OMT implementa sia la restrizione che l estensione (si veda [Rumbaugh-91]). UML si limita invece all implementazione della generalizzazione per estensione. Infatti per descrivere tale concetto si fa uso del Principio di Sostituibilità. La maggior parte dei linguaggi ad oggetti è basata sull idea che una sottoclasse equivalga ad un sottotipo. Questa affermazione viene spesso presentata con il principio di Sostituibilità di Liskov, che si propone di chiarire cosa significhi derivare un sottotipo (o sottoclasse): B è un sottotipo 4 di A sse per ogni programma che usi oggetti di classe A è possibile utilizzare al loro posto oggetti di classe B lasciando immutato il comportamento logico del programma 4 Ricordo che per sottotipo (o sottoclasse) si intende la classe derivata. Vedi una nota precedente. 11
12 Questo principio è molto restrittivo e fonte di paradossi come quello del Quadrato-Rettangolo 5. Per ulteriori approfondimenti si faccia riferimento a [Pescio97-62]. 1.5 Interaction diagram Sono diagrammi che descrivono come gruppi di oggetti interagiscono in alcuni comportamenti. Si definiscono quindi degli scenari. In genere, si cattura il comportamento di Use Case, mostrando alcuni oggetti e i messaggi scambiati. Ci sono due tipi di Interaction Diagram: Sequence Diagram Collaboration Diagram Sequence diagram Con riferimento alla Figura 8, ogni oggetto è rappresentato da un box (contenete il nome dell oggetto nella forma objectname: classname), al di sotto del quale è presente una lifeline, la quale rappresenta la vita dell oggetto durante l interazione con gli altri oggetti. Ogni messagge è rappresentato da una freccia, al di sopra della quale è presente il nome del messaggio stesso. E possibile la self-delegation (un messaggio spedito da un oggetto a se stesso). E anche possibile indicare delle condition, che indicano le condizioni rispetto alle quali il messaggio può essere spedito. Con l iteration maker (indicato con *) è possibile indicare la spedizione di messaggi multipli. A fianco di tale marcatore è presente una condizione che indica il criterio rispetto al quale avviene la spedizione multipla. E possibile indicare anche un return, mediante linea tratteggiata 6, che indica il ritorno da un messaggio, non un nuovo messaggio. 5 Per i linguaggi ad oggetti che rispettano questo principio, un quadrato non è un rettangolo. Infatti da una classe rettangolo che accetti come parametri le due lunghezze dei lati, non è possibile derivare la classe quadrato che necessita invece di una sola misura del lato. 6 Questo è quello che prevede lo standard, ma lo strumento CASE utilizzato non consentiva di tracciare una linea tratteggiata, così ho indicato i return con una scritta tra parentesi vicino alla linea. 12
13 condition Ordine : Ordine _Cliente Riga : Riga_ Preventivo ArticoloVenduto : Articolo * [for all Riga] Prepara() object InMagazzino = CheckQuantità( ) iteration maker [InMagazzino] ModificaQuantità( ) messagge Riordinare := DaRiordinare() lifeline self-delegation Figura Collaboration Diagram Rappresenta la stessa informazione e le stesse interazioni del Sequence Diagram, ma in un'altra forma. Infatti, la sequenza dei messaggi è indicata mediante numerazione progressiva (in vari formati). 4: Riordinare := DaRiordinare() ArticoloVenduto : Articolo 2: InMagazzino = CheckQuantità( ) 3: [InMagazzino] ModificaQuantità( ) Ordine : Ordine _Cliente 1: * [for all Riga] Prepara() Riga : Riga_ Preventivo Figura 9 : Collaboration Diagram del Sequence Diagram della figura precedente 13
14 1.5.3 Quando utilizzare gli Interaction Diagram Sono diagrammi utili quando è necessario mostrare il comportamento di parecchi oggetti all interno di un singolo Use Case. L utilizzo del sequence o collaboration diagram dipende da quello che si vuole mostrare 7 : sequence diagram: enfatizza la sequenza dei messaggi; collaboration diagram: utile per vedere come gli oggetti sono connessi staticamente. Sono diagrammi utili anche per gestire processi concorrenti. 1.6 Package Diagram Diagramma che mostra raggruppamenti di classi (package ) e le dipendenze fra loro. Un package diagram può essere visto come un altra forma di class diagram. Una dipendenza esiste tra due package se esiste tra le classi costituenti il package. E possibile anche definire package che contengono altri package oppure definire la generalizzazione tra package (con lo stesso significato presente tra le classi). Esistono anche package marcati come {abstract}, che definiscono l interfaccia, implementata poi da altri package collegati al package astratto mediante generalizzazione. Acquisti Prodotti In Vendita Il Package Diagram è molto importante per grandi progetti, oppure se il class diagram diviene poco leggibile. SystemUser Gestione Magazzino Figura 10 : Esempio di Package Diagram 1.7 State Diagram UML utilizza la stessa sintassi e semantica presente negli State diagram di OMT. Si faccia quindi riferimento a [Rumbaugh91] per maggiori dettagli. Gli State Diagram sono utili per descrivere il comportamento di un singolo oggetto attraverso diversi Use Case. 7 Lo strumento CASE utilizzato consente comunque di passare in modo automatico da una forma all altra. 14
15 1.8 Activity Diagram L Activity Diagram descrive la sequenza delle attività e supporta un comportamento condizionale e parallelo. Si tratta di una variante del diagramma di stato in cui tutti gli stati hanno associata una attività Gli elementi di un Activity Diagram sono i seguenti: Activity: dal punto di vista concettuale, indicano un lavoro che deve essere svolto. Dal punto di vista più strettamente implementativo, un activity può essere un metodo di una classe. Da ogni activity possono uscire uno o più transazioni, che indicano il percorso da una activity ad un altra. Start e End Point: punti di inizio e fine del diagramma. Gli End Point possono anche non essere presenti, oppure essere più di uno. Branch e merge : il comportamento condizionale è determinato da questi due costrutti. Il branch ha una singola transazione entrante e più transazioni uscenti in cui solo una di queste sarà prescelta. Il merge ha più transazioni entranti e una sola uscente e serve a terminare il blocco condizionale cominciato con un branch. Fork e join: il comportamento parallelo è determinato da questi due costrutti. Quando scatta la transazione entrante, si eseguono in parallelo tutte le transazioni che escono dal fork. Con il parallelismo non è specificata la sequenza. Per la sincronizzazione delle attività parallele è presente il costrutto di join che ha più transazioni entranti ed una sola transazione uscente. Un Activity Diagram è particolarmente utile per descrivere: workflow process, e quindi business process; parallel process. Da un punto di vista più vicino ad UML, tali diagrammi sono utili per: descrivere metodi di classe; descrivere use case Dead End e End Point Non è necessario che in un Activity Diagram sia presente in modo esplicito un End Point. Un End Point in un Activity Diagram può essere un punto nel quale i thread si possono fermare perché la condition di uscita è falsa oppure perché non sono presenti uscite dall Activity stessa Swimlanes E possibile combinare più Activity Diagram per evidenziare come le attività presenti in uno schema possono influenzare le attività presenti in un altro schema. Questo è utile soprattutto quando si rappresenta il comportamento di use case. Gli Activity Diagram ci dicono che cosa succede, ma non ci dicono chi fa che cosa. Non vengono quindi indicate le responsabilità, cioè non viene indicato quale classe compie l azione. 15
16 Un modo per indicare queste responsabilità è introdurre un etichetta che indichi il responsabile, e separare il diagramma mediante linee verticali in zone. L etichetta presente in ogni zona indica la classe responsabile dell azione. Swimlanes è un buon metodo, in quanto combina la rappresentazione logica degli Activity Diagram con la rappresentazione della responsabilità presente nell Interaction Diagram Esempi L esempio che segue è sempre relativo alla definizione dei flussi informativi in un Ateneo. 16
17 Definizione tempi di pubblicazione [ Non valido ] [ Non valido ] Verifica Regolamento di Facoltà Verifica Manifesto degli Studi [ Valido ] [ Valido ] Autorizza pubblicazione Regolamento Autorizza pubblicazione Manifesto Pubblicazione Regolamento Pubblicazione Manifesto Figura 11: Activity Diagram del Delegato per l Orientamento di Facoltà L esempio successivo riguarda l evasione di un ordine. 17
18 Riceve ordine Soddisfa ordine Invia conto [ordine rapido] [else] Spedizione 24h Spedizione standard Ricevi pagamento Chiudi ordine Figura 12: esempio Activity Diagram 18
19 1.9 Implementation Diagram 8 Mostrano gli aspetti dell implementazione, inclusa la struttura del codice e le strutture per l implementazione run-time del progetto. Si dividono in Component Diagram, che mostra le dipendenze fra componenti software. Il Deployment Diagram mostra le relazione fisiche fra componenti software e hardware Component diagram I component diagram forniscono una vista fisica del modello corrente, mostrando l organizzazione e le dipendenze fra componenti software, inclusi moduli di codice sorgente, di codice binario e componenti eseguibili. Questi diagrammi mostrano anche il comportamento visibile esternamente dei componenti, mostrandone le interfacce. Le dipendenze sono mostrate mediante opportune relazioni tra componenti ed interfacce. I component diagram sono composti da: component packages; components; interfaces; dependency relationships I component packages rappresentano un insieme di componenti logicamente correlati. In tal modo è possibile partizionare il modello fisico del sistema. Nella figura sono rappresentati due packages e una relazione di dipendenza. NomePackage_1 NomePackage_1 Figura: component packages Un componente (component) rappresenta un modulo software con una ben definita interfaccia. L interfaccia è rappresentata da uno o più elementi d interfaccia che il componente fornisce. I componenti sono usati per rappresentare dipendenze tra i moduli (a tempo di compilazione, run-rime, di chiamata). E anche possibile visualizzare le classi implementate nel modulo. Un sistema potrebbe essere composto da parecchi moduli software di diversa specie. Per distinguere le differenti specie di moduli, è utilizzato il concetto di stereotipo 9. 8 Si veda [UML Notation Guide ] 9 Rappresenta una sotto-classificazione (una specializzazione) di un elemento del modello UML. 19
20 L icona di un componente è rappresentata nella seguente figura: NomeComponente OLE Data Figura: component Un cerchio attaccato all icona del componente significa che questo supporta una particolare interfaccia. Le interfacce sono delle classi appartenenti al componente, e definite nel diagramma delle classi. E possibile disegnare una relazione di dipendenza tra i componenti. Questo tipo di relazione sta ad indicare che le classi contenute nel componente client 10 usano le classi contenute nel componente supplier. Si consideri il seguente esempio: NewComponent Data NewComponent2 App Figura Errore. L'origine riferimento non è stata trovata..1 In questo esempio, il componente client è NewComponent2, ed utilizza la classe Data contenuta nel componente NewComponent Deployment diagram Un deployment diagram mostra l integrazione del programma con la struttura hardware e software. Gli elementi costituenti il diagramma sono: processors: componente hardware in grado di eseguire programmi. Opzionalmente è anche possibile visualizzare i processi attivi sul processore e il tipo di scheduling; device: componente hardware che non è in grado di eseguire programmi; connection: rappresenta un accoppiamento hardware tra due entità. 10 Cioè il componente che fornisce utilizza i servizi forniti da un componente supplier. 20
21 NewProcessor connection NewDevice preemptive NewMain SubProgram Figura Errore. L'origine riferimento non è stata trovata Utilizzo dei diagrammi Conviene usare l Interaction Diagram per osservare il comportamento di parecchi oggetti all interno di un singolo Use Case. Se si vuole descrivere il comportamento di un oggetto attraverso molti Use case, si utilizzo lo State Diagram se invece si vuole osservare il comportamento di uno o più oggetti attraverso molti Use case e/o molti threads, si utilizzi l Activity Diagram. 21
Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A Introduzione ad UML E.
Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Introduzione ad UML E. TINELLI UML È un linguaggio (e notazione) universale per rappresentare qualunque
DettagliProgramma operativo Regione Lombardia/Ministero del Lavoro/Fondo Sociale Europeo, Obiettivo 3 Misura C3
Programma operativo Regione Lombardia/Ministero del Lavoro/Fondo Sociale Europeo, Obiettivo 3 Misura C3 Progetto ID 24063 Moduli e contenuti professionalizzanti inseriti nei corsi di laurea e diplomi universitari
DettagliMicrosoft Visio 2002 UML Sergio Colosio
Microsoft Visio 2002 UML Sergio Colosio Casi d uso Prima di definire un caso d uso è necessario definire cosa s intende per scenario. Uno scenario è una sequenza di passi che descrivono l interazione tra
DettagliLaboratorio di Progettazione di Sistemi Software UML per Design Patterns e Refactoring
TITLE Laboratorio di Progettazione di Sistemi Software UML per Design Patterns e Refactoring Valentina Presutti (A-L) Riccardo Solmi (M-Z) 1 Indice degli argomenti Introduzione alla notazione UML I diagrammi
DettagliProgramma operativo Regione Lombardia/Ministero del Lavoro/Fondo Sociale Europeo, Obiettivo 3 Misura C3
Programma operativo Regione Lombardia/Ministero del Lavoro/Fondo Sociale Europeo, Obiettivo 3 Misura C3 Progetto ID 24063 Moduli e contenuti professionalizzanti inseriti nei corsi di laurea e diplomi universitari
DettagliLaboratorio di Sistemi Software UML per Design Patterns e Refactoring
TITLE Laboratorio di Sistemi Software UML per Design Patterns e Refactoring Luca Padovani (A-L) Riccardo Solmi (M-Z) 1 Indice degli argomenti Introduzione alla notazione UML I diagrammi Class Diagram Object
DettagliIntroduzione alla programmazione
Introduzione alla programmazione Risolvere un problema Per risolvere un problema si procede innanzitutto all individuazione Delle informazioni, dei dati noti Dei risultati desiderati Il secondo passo consiste
DettagliDescrivono la collaborazione di un gruppo di oggetti per implementare collettivamente un comportamento
Diagrammi di interazione Diagrammi di sequenza Diagrammi di comunicazione (ex collaborazione) Diagrammi di interazione generale Diagrammi di temporizzazione Descrivono la collaborazione di un gruppo di
DettagliCorso di Ingegneria del Software. Activity Diagram
Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it Diagrammi di attività Diagrammi di attività 1. La notazione 2. Uso dei diagrammi di attività 3. TOOL di supporto 4.
DettagliIngegneria del Software 4. Introduzione a UML. Dipartimento di Informatica Università di Pisa A.A. 2014/15
Ingegneria del Software 4. Introduzione a UML Dipartimento di Informatica Università di Pisa A.A. 2014/15 e per i modelli iterativi analisi peliminare analisi e progettazione realizzazione Necessità di
DettagliSOMMARIO DIAGRAMMI DELLE CLASSI E DEGLI OGGETTI INGEGNERIA DEL SOFTWARE. Introduzione. Proprietà e Operazioni. Proprietà e Operazioni
SOMMARIO Introduzione Proprietà e Operazioni DIAGRAMMI DELLE CLASSI E DEGLI OGGETTI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica,
DettagliIntroduzione ai casi d uso
Introduzione ai casi d uso versione 16 marzo 2009 http://www.analisi-disegno.com Introduzione ai casi d uso Pag. 1 Obiettivo di questa introduzione fornire elementi di base sui casi d uso fornire indicazioni
DettagliUniversità di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi A4_3 V2.1. Progettazione. Metodi e Linguaggi
Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A4_3 V2.1 Progettazione Metodi e Linguaggi Il contenuto del documento è liberamente utilizzabile dagli studenti, per
DettagliUML come abbozzo. Introduzione all UML. UML come linguaggio x programmi. UML come progetto dettagliato
Introduzione all UML UML come abbozzo UML - Unified Modeling Language E una famiglia di notazioni grafiche per la modellazione visuale del software Modellazione: rappresentazione di elementi che corrispondono
DettagliTecniche di sviluppo di progetti. Lezione 4: Diagrammi UML
Tecniche di sviluppo di progetti Lezione 4: Diagrammi UML Struttura di un progetto UML Un progetto software è composto da parti, dette diagrammi UML. Ogni diagramma UML contiene un tipo ben definito di
DettagliUML I diagrammi implementativi
Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - UML I diagrammi implementativi E. TINELLI I diagrammi implementativi In UML 2.x esistono 3 tipi di
DettagliI Diagrammi di Flusso OO
Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - I Diagrammi di Flusso OO Generalità I diagrammi di attività vengono usati per modellare processi a
DettagliAlcuni diagrammi. OCL (Object Constraint Language)
UML e Java UML Alcune discipline ingegneristiche dispongono di validi mezzi di rappresentazione (schemi, diagrammi di prestazioni e consumi,...) Il software non dispone ancora di tecniche efficaci per
Dettagli2. Modellazione dei casi d uso
2. Modellazione dei casi d uso Andrea Polini Laboratorio di Ingegneria del Software Corso di Laurea in Informatica (Laboratorio di Ingegneria del Software) 2. Modellazione dei casi d uso 1 / 20 Sommario
DettagliProgrammazione Orientata agli Oggetti. Emilio Di Giacomo e Walter Didimo
Programmazione Orientata agli Oggetti Emilio Di Giacomo e Walter Didimo Una metafora dal mondo reale la fabbrica di giocattoli progettisti Un semplice giocattolo Impara i suoni Dall idea al progetto Toy
DettagliElementi di UML (6): Diagrammi dinamici di flusso
Elementi di UML (6): Diagrammi dinamici di flusso Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio di Sistemi
DettagliSQL e linguaggi di programmazione. Cursori. Cursori. L interazione con l ambiente SQL può avvenire in 3 modi:
SQL e linguaggi di programmazione L interazione con l ambiente SQL può avvenire in 3 modi: in modo interattivo col server attraverso interfacce o linguaggi ad hoc legati a particolari DBMS attraverso i
DettagliIngegneria del Software
Ingegneria del Software Analisi Object Oriented ed Elementi di Programmazione OO Origini Le metodologie ad oggi nascono negli anni 70 ma si affermano solo nelgi anni 80 grazie alla nascita dei linguaggi
DettagliSOMMARIO DIAGRAMMI DI SEQUENZA
SOMMARIO DIAGRAMMI DI SEQUENZA INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica, A.A. 2011 2012 2 rcardin@math.unipd.it SOMMARIO DIAGRAMMI
DettagliProgettazione del Sofware
Corso Serale Progettazione del Sofware Perché Modellare un Sistema Necessità di realizzare un artefatto, indipendentemente dalla sua dimensione e settore di interesse (una casa, un particolare macchinario,
DettagliLEZIONE 3 USE CASE DIAGRAM && ACTIVITY DIAGRAM
Istituto di Scienza e Tecnologie dell'informazione A. Faedo Software Engineering and Dependable Computing Laboratory LEZIONE 3 USE CASE DIAGRAM && ACTIVITY DIAGRAM Laboratorio di Ingegneria del Software
DettagliSOMMARIO. DIAGRAMMI DELLE CLASSI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova. Introduzione. Proprietà e Operazioni
SOMMARIO Introduzione Proprietà e Operazioni Concetti base e avanzati DIAGRAMMI DELLE CLASSI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica,
DettagliUML. Il linguaggio UML e ArgoUML. Ingegneria dei sistemi software 2009/ /09/2009
UML Il linguaggio UML e ArgoUML 30/09/2009 Ingegneria dei sistemi software 2009/2010 manuel.comparetti@iet.unipi.it UML Unified Modeling Language una famiglia di notazioni grafiche standardizzate* orientata
DettagliSOMMARIO DIAGRAMMI DI ATTIVITÀ INGEGNERIA DEL SOFTWARE. Introduzione. Concetti base. Introduzione. Concetti base
SOMMARIO Introduzione Concetti base INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2013 2014 2 rcardin@math.unipd.it SOMMARIO Introduzione
DettagliCorso di Algoritmi e Strutture dati Programmazione Object- Oriented in Java (Parte I)
Corso di Algoritmi e Strutture dati Programmazione Object- Oriented in Java (Parte I) Ing. Gianluca Caminiti Sommario ( OOP ) Programmazione Object-Oriented Incapsulamento, Ereditarietà, Polimorfismo Richiami
DettagliProgrammazione ad oggetti
Programmazione ad oggetti OOP La programmazione orientata agli oggetti (Object Oriented Programming) ha l obiettivo di formalizzare gli oggetti del mondo reale e di costruire con questi un mondo virtuale.
DettagliSOMMARIO. DIAGRAMMI DI ATTIVITÀ INGEGNERIA DEL SOFTWARE Università degli Studi di Padova. Introduzione. Concetti base.
SOMMARIO Introduzione Concetti base INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2014 2015 rcardin@math.unipd.it 2 SOMMARIO Introduzione
DettagliA. Lorenzi, A. Rizzi Java. Programmazione ad oggetti e applicazioni Android Istituto Italiano Edizioni Atlas
Classi e oggetti A. Lorenzi, A. Rizzi Java. Programmazione ad oggetti e applicazioni Android Istituto Italiano Edizioni Atlas Oggetti La programmazione orientata agli oggetti, OOP (Object-Oriented Programming),
DettagliLinguaggi, Traduttori e le Basi della Programmazione
Corso di Laurea in Ingegneria Civile Politecnico di Bari Sede di Foggia Fondamenti di Informatica Anno Accademico 2011/2012 docente: Prof. Ing. Michele Salvemini Sommario Il Linguaggio I Linguaggi di Linguaggi
DettagliDISPENSA ACCESS (OFFICE 2010 BETA)
DISPENSA ACCESS (OFFICE 2010 BETA) 2. LE RELAZIONI. Una relazione può essere definita come un legame tra due tabelle basato sul valore di uno o più campi di ciascuna delle due tabelle. Di solito i campi
DettagliSistemi Informativi I Strumenti - UML
8 UNIFIED MODELING LANGUAGE (UML)...2 8.1 UN APPROCCIO VISUALE ALLA PROGETTAZIONE....2 8.1.1 I vantaggi dell utilizzo di diagrammi nella fase di progettazione....2 8.2 COS È UML...3 8.2.1 Origini e breve
DettagliTesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola Sicurezza e Permission in Android
Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola 633688 Sicurezza e Permission in Android La sicurezza al giorno d oggi è uno degli aspetti più importanti dell informatica!
DettagliINTRODUZIONE ALLA PROGETTAZIONE. Patrizio Dazzi a.a
INTRODUZIONE ALLA PROGETTAZIONE Patrizio Dazzi a.a. 2017-2018 COMUNICAZIONI Lezione odierna e successive Metodologia di progetto Progettazione concettuale Progettazione logica Fondamentali per il secondo
DettagliIngegneria del Software
Ingegneria del Software Progettazione OO Agenda Astrazione e classificazione Generalizzazione e Refactoring Riuso Interfacce e classi di utilità Patterns di progettazione GRASP Obiettivi Ottenere dei modelli
DettagliSOMMARIO DIAGRAMMI DI ATTIVITÀ INGEGNERIA DEL SOFTWARE. Introduzione. Concetti base. Introduzione. Concetti base
SOMMARIO INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2012 2013 2 rcardin@math.unipd.it SOMMARIO 3 4 Analisi dei Requisiti, Specifica
DettagliLez. 8 La Programmazione. Prof. Pasquale De Michele (Gruppo 2) e Raffaele Farina (Gruppo 1) 1
Lez. 8 La Programmazione Prof. Pasquale De Michele (Gruppo 2) e Raffaele Farina (Gruppo 1) 1 Dott. Pasquale De Michele Dott. Raffaele Farina Dipartimento di Matematica e Applicazioni Università di Napoli
DettagliPrincipi di Progettazione del Software a.a
Principi di Progettazione del Software a.a. 2016-2017 UML: approfondimenti sui diagrammi delle classi e di sequenza. Diagrammi di package e di deployment Prof. Università del Salento Obiettivi della lezione
DettagliDiagrammi di attività
Diagrammi di attività Combinano idee tratte da molte tecniche diverse (diagrammi degli eventi, modellazione di stato SDL, modellazione di workflow, reti di Petri) Costituiscono un argomento complesso (e
DettagliEsempio 2: Subtyping
Esempio 2: Subtyping 22 Subclassing e subtyping Fino ad ora abbiamo trattato l ereditarietà come strumento che consente il riuso flessibile di classi già esistenti mediante l aggiunta o la ridefinizione
DettagliI database. Introduzione alla teoria delle basi di dati
I database Introduzione alla teoria delle basi di dati 1 Cosa sono e a cosa servono i Database Un database (o base di dati) e' una raccolta organizzata di dati correlati. Il principale scopo di un database
DettagliAnalisi e specifica dei requisiti
Analisi e specifica dei requisiti Processo che stabilisce i servizi che il committente richiede al sistema da sviluppare ed i vincoli con cui lo si utilizzera` e sviluppera` Requisiti funzionali o non
DettagliI Tipi di Dato Astratto
I Tipi di Dato Astratto Sommario Cosa sono le Strutture Dati Astratte? Le strutture dati Le operazioni Come scegliere fra varie implementazioni? Quale è la questione? Come organizzare (strutturare) i dati
DettagliAltrimenti, il M.C.D. di a e b è anche divisore di r (e.g. a=15,b=6,r=3 che è il M.C.D.)
Elaboratore Un elaboratore o computer è una macchina digitale, elettronica, automatica capace di effettuare trasformazioni o elaborazioni sui dati digitale l informazione è rappresentata in forma numerica
DettagliDiagrammi di classe e sistemi orientati agli oggetti
Appendice D Diagrammi di classe e sistemi orientati agli oggetti ANDREA GINI Un effetto della strategia di incapsulamento è quello di spingere il programmatore a esprimere il comportamento di un sistema
DettagliUnità A2. Progettazione concettuale. Obiettivi. Astrazione. Astrazione per aggregazione
Obiettivi Unità A2 Progettazione concettuale Imparare ad astrarre i dati per definire entità. Saper distinguere tra astrazione per classificazione, per aggregazione e per generalizzazione. Saper distinguere
DettagliIntroduzione a UML. Obiettivi. Unified Modeling Language. Gli autori di UML. Cos è UML. Cos è UML (cont.) Unified Modeling Language
Obiettivi Introduzione a UML Unified Modeling Language Fornire elementi di base su UML Introdurre i principali diagrammi Fornire indicazioni sulle modalità di utilizzo di UML nello sviluppo delle applicazioni
DettagliProgrammi e Oggetti Software
Corso di Laurea Ingegneria Civile Fondamenti di Informatica Dispensa 06 Programmi e Oggetti Software Marzo 2010 Programmi e Oggetti Software 1 Contenuti Cosa è un programma Cosa significa programmare Il
DettagliModello Entità - Relazione. Basi di dati. Elena Baralis 2007 Politecnico di Torino D B M G D B M G2 D B M G4 D B M G6. Progettazione di basi di dati
di basi di dati Modello Entità-Relazione concettuale logica Normalizzazione Sistemi informativi D B M G D B M G2 Modello Entità-Relazione di basi di dati di basi di dati Entità e relazioni Attributi Identificatori
DettagliSISTEMI INFORMATIVI E DATABASE
SISTEMI INFORMATIVI E DATABASE SISTEMA INFORMATIVO AZIENDALE (S.I.) In una realtà aziendale si distingue: DATO elemento di conoscenza privo di qualsiasi elaborazione; insieme di simboli e caratteri. (274,
DettagliD B M G D B M G 2. Sistemi informativi. Progettazione di basi di dati
Sistemi informativi D B M G Progettazione di basi di dati Modello Entità-Relazione Progettazione concettuale Progettazione logica Normalizzazione D B M G 2 1 Progettazione di basi di dati D B M G Modello
DettagliStrategie top-down. Primitive di trasformazione top-down. Primitive di trasformazione top-down
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 che aggiungono via via più
DettagliUniversità degli studi di Roma Tor Vergata Ingegneria Medica Informatica I Programma del Corso
Obiettivi Di seguito vengono riportate una serie di domande che possono essere poste durante la prova formale del corso. Le seguenti domande non sono da ritenersi esaustive ma esemplificative. 1. Architettura
DettagliLe Basi di dati: progettazione concettuale
Le Basi di dati: progettazione concettuale Progettazione di una base di dati requisitidel Sistema Informativo progettazione concettuale SCHEMA CONCETTUALE SCHEMA FISICO progettazione fisica progettazione
DettagliSOMMARIO DIAGRAMMI DI ATTIVITÀ
SOMMARIO INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica, A.A. 2010 2011 2 ingegneria.software.math.unipd@gmail.com SOMMARIO 3 4 Analisi
DettagliIngegneria del Software 8. Diagrammi di attività. Dipartimento di Informatica Università di Pisa A.A. 2014/15
Ingegneria del Software 8. Diagrammi di attività Dipartimento di Informatica Università di Pisa A.A. 2014/15 so far Modello del dominio Modello statico: diagrammi delle classi Modello dinamico : diagrammi
DettagliIntroduzione a UML Linguaggio di Modellazione Unificato. Corso di Ingegneria del Software Anno Accademico 2006/2007
Introduzione a UML Linguaggio di Modellazione Unificato Corso di Ingegneria del Software Anno Accademico 2006/2007 1 Che cos è UML? UML (Unified Modeling Language) è un linguaggio grafico per: specificare
DettagliProgramma del corso. Elementi di Programmazione. Introduzione agli algoritmi. Rappresentazione delle Informazioni. Architettura del calcolatore
Programma del corso Introduzione agli algoritmi Rappresentazione delle Informazioni Architettura del calcolatore Reti di Calcolatori Elementi di Programmazione Algoritmi e programmi Algoritmo Sequenza
DettagliIndice. Prefazione. 3 Oggetti e Java 53
Prefazione xv 1 Architettura dei calcolatori 1 1.1 Calcolatori e applicazioni 1 1.1.1 Alcuni esempi di applicazioni 3 1.1.2 Applicazioni e interfacce 4 1.2 Architettura dei calcolatori 7 1.2.1 Hardware
DettagliIntroduzione alle classi e agli oggetti. Walter Didimo
Introduzione alle classi e agli oggetti Walter Didimo Classi e oggetti La classe rappresenta l unità di base della programmazione ad oggetti: una classe definisce una tipologia di elementi (cioè una categoria
DettagliCONCETTI FONDAMENTALI
CONCETTI FONDAMENTALI Algoritmo Procedura di trasformazione di un insieme di dati iniziali in un insieme di risultati finali mediante una sequenza di istruzioni. Linguaggio di programmazione Programma
DettagliCatia Trubiani. Laboratorio di Ingegneria del Software a.a
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
DettagliProgrammazione ad Oggetti
Programmazione ad Oggetti Analisi e Progettazione OO Origini Le metodologie ad oggetti nascono negli anni 70 ma si affermano solo negli anni 80 grazie alla nascita dei linguaggi di programmazione ad oggetti
DettagliGerarchia di Generalizzazione. Esempio. Rappresentazione grafica. Cap. 4 - Modello E/R avanzato: Gerarchie di Generalizzazione/ specializzazione
Gerarchia di Generalizzazione 22 Cap. 4 - Modello E/R avanzato: Gerarchie di Generalizzazione/ specializzazione Concetti Definizioni Esempi Mette in relazione (legami logici) una o più entità, E 2,...,
DettagliAnalisi Orientata agli Oggetti
Generalità Concetti di base: Oggetto, Classe, Attributo, Operazione, Associazione, Aggregazione, Generalizzazione, Ereditarietà Il Diagramma delle Classi: notazione UML 1 Generalità Approccio all analisi
DettagliLa classe java.lang.object
La classe java.lang.object In Java: Gerarchia di ereditarietà semplice Ogni classe ha una sola super-classe Se non viene definita esplicitamente una super-classe, il compilatore usa la classe predefinita
DettagliLa progettazione logica Traduzione dal modello Entità-Associazione al modello relazionale Anno accademico 2008/2009
La progettazione logica Traduzione dal modello Entità-Associazione al modello Anno accademico 2008/2009 Obiettivo: Costruire uno schema logico in grado di descrivere le informazioni contenute nello schema
DettagliCorso di Informatica. Problemi ed algoritmi. Ing Pasquale Rota
Corso di Problemi ed algoritmi Ing Pasquale Rota Argomenti Problemi ed algoritmi Proprietà degli algoritmi Pseucodice Diagrammi di flusso Problemi ed algoritmi - Ing. Pasquale Rota 2 Proprietà degli algoritmi
DettagliUML: DIAGRAMMA DI SEQUENZA
UML: DIAGRAMMA DI SEQUENZA UC n. 4: Basi di dati andrea.reale@unibo.it 2 UML e diagrammi di interazione Abbiamo visto il diagramma delle classi in UML Utilizzato per rappresentare strutturalmente il dominio
DettagliIl linguaggio di programmazione Python
Università Roma Tre Dipartimento di Matematica e Fisica Percorso Abilitante Speciale Classe A048 Matematica Applicata Corso di Informatica Il linguaggio di programmazione Python Marco Liverani (liverani@mat.uniroma3.it)
DettagliProgrammazione Java Avanzata Programmazione Object- Oriented in Java
Programmazione Java Avanzata Programmazione Object- Oriented in Java Ing. Gianluca Caminiti Testi di Riferimento (Java) Cay Horstmann Concetti di informatica e fondamenti di Java Apogeo, 2007 (Versione
DettagliDescrizione delle operazioni di calcolo. Espressioni costanti semplici
Descrizione delle operazioni di calcolo Come abbiamo detto l interprete è in grado di generare nuovi valori a partire da valori precedentemente acquisiti o generati. Il linguaggio di programmazione permette
DettagliAUTOMA A STATI FINITI
Gli Automi Un Automa è un dispositivo, o un suo modello in forma di macchina sequenziale, creato per eseguire un particolare compito, che può trovarsi in diverse configurazioni più o meno complesse caratterizzate
DettagliUnified Modeling Language - UML
Unified Modeling Language - UML Linguaggio Unificato per Modellare un sistema (software) Linguaggio non una semplice notazione per disegnare diagrammi ma un Linguaggio completo per catturare la conoscenza
DettagliStrutture dati. Il che cosa e il come. F. Damiani - Alg. & Lab. 04/05
Strutture dati Il che cosa e il come Il che cosa ed il come Struttura dati: descrive come sono organizzati i dati e come sono realizzate le operazioni su di essi (cioe come si accede ai dati) Specifica
DettagliRDF. Resource Description Framework
RDF Resource Description Framework 1 Sommario 1) Cos è l RDF RDF Model and Syntax RDF Schema 2) Il data model RDF definizione di risorsa, proprietà e statement esempio 1 esempio 2 2 3) Combinazione RDF
DettagliProgrammi e Oggetti Software
Corso di Laurea Ingegneria Informatica Fondamenti di Informatica 1 Dispensa 2 Programmi e Oggetti Software Alfonso Miola Settembre 2007 http://www.dia.uniroma3.it/~java/fondinf1/ Programmi e Oggetti Software
DettagliProgettare 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
DettagliLez. 5 La Programmazione. Prof. Salvatore CUOMO
Lez. 5 La Programmazione Prof. Salvatore CUOMO 1 2 Programma di utilità: Bootstrap All accensione dell elaboratore (Bootsrap), parte l esecuzione del BIOS (Basic Input Output System), un programma residente
DettagliUNIVERSITÀ DEGLI STUDI DI PAVIA FACOLTÀ DI INGEGNERIA. Introduzione alla programmazione
UNIVERSITÀ DEGLI STUDI DI PAVIA FACOLTÀ DI INGEGNERIA Introduzione alla programmazione Riferimenti Emanuele Goldoni Laboratorio Reti (MN) Tel. 0376-286234 E-mail: emanuele.goldoni@unipv.it Slide sul sito
DettagliModellazione di Workflow mediante le Reti di Petri. Prof. Giancarlo Fortino
Modellazione di Workflow mediante le Reti di Petri Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Il successo di un sistema di workflow si basa sulla qualità dei flussi di lavoro che lo compongono.
DettagliIl modello Entità/Relazioni (ER)
Il modello Entità/Relazioni (ER) Basi di dati 1 Il modello Entità/Relazioni (ER) Angelo Montanari Dipartimento di Matematica e Informatica Università di Udine Il modello Entità/Relazioni (ER) Basi di dati
DettagliProgrammazione con Java
Programmazione con Java Astrazioni e UML Astrazioni Nella vita reale siamo abituati a osservare e descrivere oggetti a vari livelli di dettaglio Dai da mangiare a Fido Porta a passeggio il cane Di quale
DettagliINTRODUZIONE ALLA PROGRAMMAZIONE AD ALTO LIVELLO IL LINGUAGGIO JAVA. Fondamenti di Informatica - D. Talia - UNICAL 1. Fondamenti di Informatica
Fondamenti di Informatica INTRODUZIONE ALLA PROGRAMMAZIONE AD ALTO LIVELLO IL LINGUAGGIO JAVA Fondamenti di Informatica - D. Talia - UNICAL 1 Fondamenti di Informatica - Programma Un programma è una formulazione
DettagliModularizzazione del software
Modularizzazione del software Ing. Luca De Santis DIS - Dipartimento di informatica e sistemistica Anno accademico 2006/2007 Fortran 90: Subroutine e function DIS - Dipartimento di informatica e sistemistica
DettagliProgrammazione Orientata agli Oggetti
Programmazione Orientata agli Oggetti Lezione 13 La programmazione ad oggetti si basa su due principi fondamentali ereditarietà polimorfismo Queste due proprietà consentono di definire nuovi tipi di dato
DettagliProgrammazione = decomposizione basata su astrazioni
Programmazione = decomposizione basata su astrazioni 1 Decomposizione in moduli necessaria quando si devono sviluppare programmi abbastanza grandi decomporre il problema in sotto-problemi i moduli che
DettagliCorso sul linguaggio Java
Corso sul linguaggio Java Modulo JAVA2 2.1- Funzioni 1 Prerequisiti Programmazione elementare in Java Tecnica top-down Concetto matematico di funzione Compilazione e link di programmi Esecuzione di funzioni
DettagliModelli e Metodi per la Simulazione (MMS)
Modelli e Metodi per la Simulazione (MMS) adacher@dia.uniroma3.it Programma La simulazione ad eventi discreti, è una metodologia fondamentale per la valutazione delle prestazioni di sistemi complessi (di
DettagliFondamenti di Informatica T-1. Ereditarietà & Polimorfismo
Ereditarietà & Polimorfismo Ereditarietà Meccanismo per definire una nuova classe (classe derivata) come specializzazione di un altra (classe base) La classe base modella un concetto generico La classe
DettagliMetodologie di Programmazione. ovvero, Principi e Tecniche per la costruzione di programmi
Metodologie di Programmazione ovvero, Principi e Tecniche per la costruzione di programmi 1 In questo corso Sviluppo in piccolo: Tempi: mesi/uomo v.s. anni/uomo Strumenti: personal v.s. professional Programmazione
DettagliCorso di Linguaggi di Programmazione + Laboratorio
Corso di inguaggi di Programmazione + aboratorio Capitolo 1 - Introduzione Si ringrazia il Dott. Marco de Gemmis per la collaborazione nella predisposizione del materiale didattico Apprendimento di un
DettagliUML GML- Classi di Oggetti
UML GML- Classi di Oggetti Claudio Rocchini Istituto Geografico Militare Introduzione Per lavorare nel GIS serve sapere anche queste cose? Si, perché: I dati geografici verranno scambiato nel formato GML
Dettagli19 - Eccezioni. Programmazione e analisi di dati Modulo A: Programmazione in Java. Paolo Milazzo
19 - Eccezioni Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo di.unipi.it Corso
DettagliFUNZIONI COME COMPONENTI SW FUNZIONI COME COMPONENTI SW FUNZIONI MODELLO CLIENTE/SERVITORE
FUNZIONI Spesso può essere utile avere la possibilità di costruire nuove istruzioni che risolvano parti specifiche di un problema Una funzione permette di dare un nome a una espressione rendere tale espressione
DettagliProgrammazione a oggetti
Programmazione a oggetti Quanti oggetti, tra di loro parlando, fanno programmi. Pilu Crescenzi piluc@dsi.unifi.it Università di Firenze Programmazione a oggetti p.1/32 Cosa è un oggetto Una scatola software
Dettagli