La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Politecnico di Milano © 2005 - CEFRIEL UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza CEFRIEL

Presentazioni simili


Presentazione sul tema: "Politecnico di Milano © 2005 - CEFRIEL UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza CEFRIEL"— Transcript della presentazione:

1 Politecnico di Milano © CEFRIEL UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza CEFRIEL

2 2 © CEFRIEL Unified Modeling Language Sommario Introduzione ai linguaggi di modellazione Fondamenti del paradigma object-oriented UML: il linguaggio Esempi di modellazione con UML

3 3 © CEFRIEL Unified Modeling Language I modelli Ragionare sui sistemi complessi è difficile. Costruire sistemi complessi è difficile. Come fare a valutare aspetti notevoli dei sistemi, o a valutare l’efficacia di soluzioni costruttive senza affrontare l’intera complessità di un sistema reale? Usando dei modelli.

4 4 © CEFRIEL Unified Modeling Language Modellare: un’idea nuova? Non proprio si pensi al modello di cupola del Brunelleschi

5 5 © CEFRIEL Unified Modeling Language Caratteristiche del modello Astrazione Modularità Viste molteplici

6 6 © CEFRIEL Unified Modeling Language Astrazione Un sistema reale è caratterizzato da un numero impressionante di elementi. Spesso, solo una minima parte di tale elementi risultano “interessanti” –NB: cosa sia interessante dipende dal contesto Ne consegue che il modello può trascurare i dettagli irrilevanti. Astrazione = descrizione di un sistema (o di parte di esso) che ne riporta solo le caratteristiche rilevanti.

7 7 © CEFRIEL Unified Modeling Language Astrazione: esempio Caratteristiche di una persone: –Nome, –Indirizzo –Età –Numero di scarpe –Gruppo sanguigno –Codice fiscale –Fede calcistica –Reddito –… La stragrande maggioranza dei contesti che possiamo immaginare richiedono la conoscenza di un sottoinsieme di queste caratteristiche

8 8 © CEFRIEL Unified Modeling Language Modularità Divide et impera Un sistema è modulare se è diviso in parti che hanno una sostanziale autonomia individuale ed una ridotta interazione con le altre parti –i moduli sono scarsamente connessi e fortemente coesi

9 9 © CEFRIEL Unified Modeling Language Cinque criteri di modularità Scomponibilità modulare –scomporre un problema in sottoproblemi di minori dimensioni e quindi più facilmente affrontabili Componibilità modulare –ri-aggregare moduli esistenti per risolvere problemi nuovi –riusabilità –ES: Lego Comprensione modulare –capire un modulo osservando solo quello e i "confinanti“ Continuità modulare –un piccolo cambiamento nelle specifiche comporta cambiamenti in un solo (o pochi) moduli –estendibilità Protezione modulare –errori in un modulo influenzano solo il modulo stesso (o al massimo si propagano ai confinanti)

10 10 © CEFRIEL Unified Modeling Language Come ottenere la modularità Unità linguistiche modulari Poche interfacce –ciascun modulo deve comunicare con il minor numero possibile di altri moduli –in un sistema composto da n moduli il numero delle interfacce deve essere quanto più possibile vicino a (n-1) e lontano da n(n-1)/2 Interfacce piccole –ogni modulo deve scambiare il minor numero possibile di informazioni con gli altri moduli Interfacce esplicite –il fatto che due moduli A e B comunichino deve risultare evidente sia dal codice di A che dal codice di B Information hiding informazioni pubbliche informazioni private –il modulo deve distinguere tra informazioni pubbliche ed informazioni private

11 11 © CEFRIEL Unified Modeling Language Molteplici viste Un sistema complesso presenta molteplici “aspetti” che devono essere considerati ed adeguatamente descritti per rappresentare il sistema, ritraendone tutte le caratteristiche. Risulta quindi difficile comprimere in un unico modello informazioni di natura anche molto diversa: si consideri ad esempio il fatto che una rappresentazione adeguata del sistema deve descrivere – la struttura statica – il comportamento dinamico – l’organizzazione logica – la distribuzione fisica – ecc. Soluzione: non un modello, ma più modelli, ciscuno specializzato per fornire un certo tipo di informazioni

12 12 © CEFRIEL Unified Modeling Language Molteplici viste Un’idea nuova? Non proprio …

13 13 © CEFRIEL Unified Modeling Language Linguaggi di descrizione Le “descrizioni” vengono prodotte in svariate fasi del processo: –Descrizione = insieme di affermazioni riguardo una qualche realtà di interesse –Problem definition = fra l’altro, descrizione del problema da risolvere –Program design = fra l’altro, descrizione del comportamento del sistema da realizzare Linguaggi di descrizione = linguaggi adatti a scrivere “descrizioni”

14 14 © CEFRIEL Unified Modeling Language Caratteristiche dei linguaggi di descrizione Completezza –Il linguaggio deve mettere a disposizione strumenti per descrivere tutti gli aspetti di interesse. Accuratezza –Deve essere possibile costruire una descrizione precisa. Consistenza –Il linguaggio deve aiutare a non esprimere concetti contraddittori in diverse rappresentazione della stessa descrizione. Comprensibilità –La descrizione deve essere facilmente comprensibile da parte di chi la deve interpretare. Formalità –Rigore con cui sono definite la sintassi e la semantica del linguaggio. Stile –Quale aspetto del sistema è più facile descrivere utilizzando il linguaggio (comportamento o proprietà)

15 15 © CEFRIEL Unified Modeling Language Grado di formalità Informale: tipicamente linguaggio corrente (italiano, inglese) –Spesso usato perché è usabile con poco sforzo –Può dar luogo ad ambiguità Semi-formale (ha sintassi ma poca semantica) –Facilmente comprensibile, ma possibile fonte di ambiguità Formale (ha sia sintassi sia semantica rigorosa) –Ha fondamenti logico-matematici: elimina ambiguità –Consente di ragionare su e verificare proprietà, anche con strumenti (semi)automatici che supportano quel linguaggio –N.B. Non tutte le proprietà sono formalmente verificabili

16 16 © CEFRIEL Unified Modeling Language Stile Stile descrittivo: definisce le proprietà desiderate –Es. La curva soddisfa l’equazione ax 2 + by 2 + c = 0. Stile operazionale: definisce il comportamento desiderato (una “macchina”) –Es. La curva rappresenta il cammino di un punto che si muove in modo che la somma delle sue distanze da due punti fissati P1 e P2 rimanga costante.

17 Politecnico di Milano © CEFRIEL Il paradigma object-oriented

18 18 © CEFRIEL Unified Modeling Language I concetti base del paradigma Object-Oriented Classi Oggetti Generalizzazione/specializzazione Polimorfismo Dynamic binding

19 19 © CEFRIEL Unified Modeling Language Classe Una classe definisce un insieme di possibili oggetti È la descrizione –astratta– di una tipologia di oggetti Automobile, felino, fenomeno atmosferico, copricapo sono possibili classi. NB: la classe è una descrizione –Gli oggetti che descrive sono elementi del mondo reale –La classe esiste su un piano diverso

20 20 © CEFRIEL Unified Modeling Language Classe: dati e comportamento La classe descrive sia le caratteristiche statiche degli oggetti che il loro comportamento (le operazioni in cui possono essere coinvolti) Attributi: sono i “dati” che caratterizzano la classe Esempio: –La classe conto corrente avrà gli attributi: numero, titolare, saldo, ecc. Operazioni (o “metodi”): sono le operazioni che si può chiedere agli oggetti di eseguire Esempio: –La classe conto corrente sarà dotata delle operazioni di versamento, prelevamento, bonifico, ecc.

21 21 © CEFRIEL Unified Modeling Language Classi: proprietà pubbliche e private Contenuti privati –attributi e metodi accessibili solo dall’interno della classe Contenuti pubblici –attributi e metodi accessibili dall’esterno (cioè da altre classi) Servono a realizzare l’information hiding È desiderabile che tutti gli attributi siano privati. –Questo rende la classe accessibile solo attraverso le operazioni pubbliche. –Conseguenza: la altre classi sanno cosa possono fare con una classe, ma non sanno come la classe funziona internamente –Modularità! –Concetto nuovo? Non proprio: noi conosciamo solo l’interfaccia pubblica della banca, del videoregistratore, dell’automobile, …

22 22 © CEFRIEL Unified Modeling Language Oggetto Definizione –Istanza di una classe –Esemplare corrispondente alla descrizione fornita dalla classe Ogni oggetto ha associate le proprietà descritte nella classe di cui è istanza –Tutte le istanze della stessa classe si comportano nello stesso modo –Ma oggetti diversi che sono istanze della stessa classe avranno valori degli attributi diversi Esempio: –La classe Persona prevede l’attributo età –Rossi e Bianchi sono istanze di persona –Sia Rossi che Bianchi hanno dunque un’età –I valori delle età di Rossi e Bianchi possono chiaramente essere diversi

23 23 © CEFRIEL Unified Modeling Language Oggetto Un oggetto incapsula: –stato = valore di attributi –comportamento = metodi Il comportamento dipende spesso dallo stato Esempi –La classe Persona comprende lo stato civile: l’operazione “matrimonio” è disponibile solo se l’oggetto è nello stato “celibe” –La classe Motore comprende l’operazione di accensione, che è disponibile solo se gli attributi del motore indicano che non è guasto ed il carburante è presente.

24 24 © CEFRIEL Unified Modeling Language La metafora di interazione Un metodo si invoca mandando un messaggio all'oggetto In altre parole: per stimolare un certo comportamento da parte di un oggetto, gli mandiamo un messaggio contenente l’invocazione del metodo dell’oggetto corrispondente al comportamento che desideriamo ottenere. Chi manda i messaggi? Un altro oggetto. Nel modello object-oriented qualunque cosa è un oggetto. PersonaConto corrente Prelievo

25 25 © CEFRIEL Unified Modeling Language Classi: attenzione all’astrazione Lo scopo semantico della classe e l’astrattezza della descrizione possono portare a situazioni apparentemente bizzare, ma perfettamente logiche. Esempio: –Scopo semantico = bene materiale, caratterizzato dalla sua descrizione e valore –Classe Bene –La mia auto e il mio box sono istanze della stessa classe –Il cavallo e la stalla del Sig. Rossi sono istanze della stessa classe Esempio: –Scopo semantico = gli insegnanti –Classe Insegnante –Il sig. Mauro Rossi e il suo fratello genello sono istanze di classi diverse (uno è insegnante, l’altro no).

26 26 © CEFRIEL Unified Modeling Language Classi come insiemi Una classe può essere vista come un insieme Le istanze della classe appartengono all’insieme associato alla classe Esempio –Classe Libro –Le istanze “Pinocchio”, “Tom Sawyer”, “Il nome della rosa” appartengono all’insieme dei libri, così come tutte le altre istanza di Libro.

27 27 © CEFRIEL Unified Modeling Language Oggetti complessi Sono oggetti costruiti a partire da oggetti più semplici. Occorre fornire operatori per gestire gli oggetti complessi. Questo vuol dire che in generale un'operazione effettuata su un oggetto complesso generico (cioé avente qualunque struttura) deve propagare transitivamente i propri effetti ai componenti dell'oggetto operando. –Esempio: "deep" e "shallow" copy.

28 28 © CEFRIEL Unified Modeling Language Identità degli oggetti Un oggetto esiste indipendentemente dal suo valore. Esistono due relazioni di equivalenza sugli oggetti: –identità (due oggetti sono in realtà il medesimo oggetto) –uguaglianza (due oggetti hanno lo stesso valore) Se l'oggetto é complesso l'uguaglianza può essere "deep" o "shallow".

29 29 © CEFRIEL Unified Modeling Language Identità degli oggetti - condivisione Esempio: una persona ha un nome, un età e un insieme di figli. Carlo e Maria hanno entrambi un figlio di 15 anni di nome Luca. Sono possibili due situazioni: –Luca é il figlio di Carlo e Maria –Ci sono due persone di nome Luca di 15 anni, uno figlio di Carlo e uno di Maria Un sistema basato sull'identità rappresenta in modo naturale entrambe le situazioni: Carlo Maria Carlo Maria Luca

30 30 © CEFRIEL Unified Modeling Language Identità degli oggetti Aggiornamento di oggetti condivisi Quando un oggetto condiviso viene aggiornato tutti gli oggetti cui appartiene automaticamente ed immediatamente vedono il cambiamento. –Es: carlo->figlio->anni += 1 Questo meccanismo é al tempo stesso potente e pericoloso (side-effects). Carlo Maria Luca 15 Carlo Maria Luca 16

31 31 © CEFRIEL Unified Modeling Language Generalizzazione È una relazione tra classi (cioè tra descrizioni) Rappresenta il ben noto concetto di generalizzazione (o specializzazione se visto nel senso inverso) Una classe A è una generalizzazione di una sottoclasse B se la tipologia rapprersentata da A comprende come caso particolare (specializzazione) la tipologia B. Esempi –La classe Studente è una specializzazione della classe Persona –La classe Primate è una specializzazione della classe Mammifero, che a sua volta è una specializzazione della classe Animale La relazione di generalizzazione non è limitata alle classi, ma può essere usata anche tra altri tipi di descrizioni

32 32 © CEFRIEL Unified Modeling Language Generalizzazione Generalizzazione = relazione "is-a“ (“è un/una”) –Ogni istanza di una classe è anche istanza di tutte le superclassi –Fuffy è un felino. Dunque è anche un mammifero e un animale. La generalizzazione forma una gerarchia –Non è possibile (neanche indirettamente) che A sia una specializzazione di B e B una specializzazione di A Felino Primate Animale MammiferoRettileUccello

33 33 © CEFRIEL Unified Modeling Language Generalizzazione Perché usiamo la generalizzazione nei modelli? –Condivisione di proprietà Le sottoclassi hanno tutte le proprietà delle super-classi Possono essere descritte incrementalmente –Compatibilità Le sottoclassi sono compatibili con le superclassi Ad es. se la maestra chiede di disegnare un animale, va bene sia il disegno di un felino che di un rettile

34 34 © CEFRIEL Unified Modeling Language Condivisione di proprietà Poligono Ellisse Figura FiguraChiusaFiguraAperta Rettangolo Attributi: Colore Operazioni: Rotazione Disegno Eredita le proprietà di Figura Aggiunge le Operazioni: Perimetro Area Eredita le proprietà di FiguraChiusa (e quindi anche di Figura) Aggiunge l’attributo: NumeroLati Eredita le proprietà di FiguraChiusa Aggiunge gli attributi: Fuoco1 e Fuoco2

35 35 © CEFRIEL Unified Modeling Language Quando usare la generalizzazione? Quando esistono classi “simili” (cioè che condividono un insieme di proprietà) che –rispetto agli scopi del modello– presentano differenze rilevanti. NB: possono esistere tipologie di modelli molto diverse nel mondo reale, ma che rispetto allo scopo semantico richiesto dal modello possono essere rappresentate mediante un’unica classe (cioè mediante un’unica astrazione). Regola: non creare una specializzazione se non ce n’è bisogno.

36 36 © CEFRIEL Unified Modeling Language Polimorfismo Conseguenza dell’esistenza di generalizzazione e della compatibilità delle sottoclassi rispetto alle superclassi Poligono Ellisse Figura FiguraChiusaFiguraAperta Rettangolo Disegno Attributi: Colore Operazioni: Rotazione Disegno Composto_da Il disegno “sa” di essere composto da figure, cui può chiedere di ruotare o disegnarsi. Non sa nulla delle possibili specializzazioni, salvo che saranno compatibili

37 37 © CEFRIEL Unified Modeling Language Polimorfismo Un riferimento polimorfico: –ha un tipo statico Nell’esempio precedente, il disegno è composto di oggetti di tipo Figura –ha un tipo dinamico: può riferirsi, nel corso dell'esecuzione del programma, a istanze di più di una classe; Nell’esempio precedente, il disegno a un certo punto potrebbe comprendere solo un ellisse, più tardi solo due rettangoli

38 38 © CEFRIEL Unified Modeling Language Dynamic binding Binding: –Il collegamento tra il nome di una operazione e la sua implementazione Dynamic binding: –Un oggetto invia un messaggio a un altro oggetto, di cui ignora il tipo dinamico –L’operazione eseguita dipende dal tipo effettivo dell’oggetto ricevente

39 39 © CEFRIEL Unified Modeling Language Dynamic binding: esempio Poligono Ellisse Figura FiguraChiusaFiguraAperta Rettangolo Disegno Composto_da Rotazione Tipo statico Se il disegno è composto di ellissi la rotazione eseguita è quella delle ellissi, se il disegno contiene rettangoli la rotazione eseguita è quella definita nella classe Rettangolo, ecc.

40 Politecnico di Milano © CEFRIEL Unified Modeling Language

41 41 © CEFRIEL Unified Modeling Language È un insieme di linguaggi che, utilizzati congiuntamente, consentono di descrivere/modellare tutti (o quasi) gli aspetti rilevanti di un sistema, secondo con un approccio object- oriented Notazione grafica Linguaggio semi-formale Stile misto –parzialmente dichiarativo, parzialmente operazionale Standard OMG per la modellizzazione di sistemi Object- Oriented sin dal 1997

42 42 © CEFRIEL Unified Modeling Language Situazione Dove trovare informazioni costantemente aggiornate: –http://www.rational.com –http://www.omg.org –internet newsgroup comp.object 2004

43 43 © CEFRIEL Unified Modeling Language Indice Diagrammi UML –Class e Object Diagram –Use Case Diagram –Interaction Diagram Sequence Diagram Collaboration Diagram –Composite structure Diagram –Statechart Diagram –Activity Diagram –Component Diagram –Deployment Diagram

44 44 © CEFRIEL Unified Modeling Language 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

45 45 © CEFRIEL Unified Modeling Language Classi Una classe descrive un gruppo di oggetti con caratteristiche comuni –attributi –comportamento Gli oggetti (istanze) di una stessa classe differiscono tra loro per i valori degli attributi e per le relazioni che li legano ad altri oggetti.

46 46 © CEFRIEL Unified Modeling Language NomeClasse nome-attributo-1: tipo-dato-1 = valore-di-default-1 nome-attributo-2: tipo-dato-2 = valore-di-default nome-operazione-1 (lista-argomenti-1): tipo-reso-1 nome-operazione-2 (lista-argomenti-2): tipo-reso Notazione generale per le classi Nel caso più generale la notazione è la seguente. Esempi File Persona Nome: string Età: int CambiaLavoro CambiaIndirizzo Nome: string Dimensione: int Creazione: data Stampa Disegno Titolo: string Altezza: int Larghezza: int Stampa Ruota(gradi: int)

47 47 © CEFRIEL Unified Modeling Language Operazioni Un operazione è una funzione o una trasformazione applicabile ad un’istanza di una classe (ogni operazione ha come argomento implicito un oggetto obiettivo) –La stessa operazione può essere definita in classi diverse –Il comportamento dipende dalla classe a cui appartiene l'oggetto obiettivo Persona Classi con attributi e operazioni Nome: string Età: int CambiaLavoro CambiaIndirizzo File Nome: string Dimensione: int Creazione: data Stampa Disegno Titolo: string Altezza: int Larghezza: int Stampa Ruota(gradi: int)

48 48 © CEFRIEL Unified Modeling Language Relazioni in UML In un Class Diagram vengono rappresentate relazioni oltre alle classi: –Associazioni (semplici, aggregazioni, composizioni) –Relazioni di generalizzazione –Relazioni di dipendenza –Relazioni di raffinamento

49 49 © CEFRIEL Unified Modeling Language Città Nome: string CapoluogoDi Nota: una associazione è naturalmente bidirezionale. Nome (opzionale) dell'associazione Regione Nome: string Associazioni Una Associazione individua una “connessione” logica tra classi –Il significato della relazione è specificato solo attraverso l’etichetta dell’associazione –si traduce in una connessione fra oggetti istanze delle classi coinvolte nell’associazione

50 50 © CEFRIEL Unified Modeling Language Cardinalità nelle associazioni 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!

51 51 © CEFRIEL Unified Modeling Language Cardinalità delle associazioni P2 P1 Mondo reale Indicazione (opzionale) di molteplicità 0..* PoligonoPunto Derfinito_da 3..* P4 P5 P3 P6 Px

52 52 © CEFRIEL Unified Modeling Language Notazione per la cardinalità Nota: Il class diagram indica che una persona può possedere un numero qualsiasi di auto Quanti sono i proprietari di una singola auto? –Il diagramma non fornisce questa informazione, dato che la cardinalità della partecipazione di Persona all’associazione risulta non specificata! –Inoltre, dato che l’associazione è navigabile in una sola direzione, data un’auto non è mai possibile risalire ai suoi (o al suo) proprietario Possiede 0..* Auto Modello: string Persona Nome: string

53 53 © CEFRIEL Unified Modeling Language PersonaAzienda Lavora per Impiegato DatoreDiLavoro Il ruolo (opzionale) 1..*0..1 Ruoli nelle associazioni Una classe può partecipare ad un’associazione con un ruolo specifico, che può essere indicato

54 54 © CEFRIEL Unified Modeling Language StudenteCorso Frequenza anno_accademico profitto Questa è la notazione per indicare che una associazione possiede alcuni attributi Non si tratta di attributi dello studente perché cambiano da corso a corso. Nè sono attributi del corso (ad es. ogni corso è frequentato da studenti diversi in anni diversi) 1..* Attributi delle associazioni (Association Class) In molti casi alcune proprietà sono proprie dell'associazione piuttosto che delle classi coinvolte.

55 55 © CEFRIEL Unified Modeling Language Associazioni esclusive Talvolta un’associazione può esistere verso una classe o verso un’altra (non verso entrambe) Partita IVA Persona {xor} Azienda

56 56 © CEFRIEL Unified Modeling Language Diagrammi delle Istanze (Object Diagram) Descrivono singole istanze di classi (oggetti) e associazioni (links) rappresentate in un particolare class diagram Adatti a descrivere esempi o situazioni specifiche (punti di vista o “fotografie” delle istanze esistenti in un certo istante di tempo)

57 57 © CEFRIEL Unified Modeling Language Order Classe Istanze MyOrder: Order : Order Oggetti: Notazione grafica Scopo delle istanze è solitamente di fornire degli esempi di oggetti, oppure evidenziare oggetti di particolare rilevanza. MyOrder: Order number=0 amount=10000

58 58 © CEFRIEL Unified Modeling Language presidente cittadino Italia: Repubblica C.A.Ciampi: Persona Dario Fo: Persona cittadino Link e Object Diagram Un legame (link) è una connessione fisica o concettuale fra due istanze. Mentre un'associazione connette due classi, un link connette due oggetti. I link sono istanze delle associazioni.

59 59 © CEFRIEL Unified Modeling Language Object diagram: Esempio Diagramma degli oggetti Pol: Poligono P3: Punto P1: Punto P2: Punto P4: Punto P2 P1 Mondo reale P4 P5 P3 P6 P5: Punto P6: Punto

60 60 © CEFRIEL Unified Modeling Language PoligonoPunto InsiemeDi Modello equivalente che usa una associazione convenzionale: PoligonoPunto Il rombo “vuoto” si legge "è un insieme di" 3..* Aggregazione È un caso particolare di associazione molto comune che significa: “è un insieme di". Essendo un tipo particolare di associazione è sempre possibile specificare la cardinalità

61 61 © CEFRIEL Unified Modeling Language Composizione È un caso particolare di aggregazione che significa: “è composto da". –i componenti non possono esistere senza il contenitore –la proprietà da parte del contenente è esclusiva Quindi la molteplicità dal lato dell’aggregato non può essere >1 Può essere qualsiasi per gli elementi componenti PC MonitorUnitàBaseMouseTastiera HardDiskCDModuloRAMCPUCoprocessore *

62 62 © CEFRIEL Unified Modeling Language Relazioni di aggregazione: Semantica Varianti esclusiva, dipendente, ma assenza di propagazione delle operazioni ? * Dipendenza delle parti dall’oggetto composito Proprietà ? 1..* + semantica di propagazione delle operazioni definita dall’utente (necessaria) 1 Avanzato

63 63 © CEFRIEL Unified Modeling Language 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 Corso 0..* precedenza 0..*

64 64 © CEFRIEL Unified Modeling Language generalizzazione Documento è una generalizzazione di Libro e di File File e libro sono sottoclassi di documento Attributi, operazioni e associazioni vengono ereditati dalle sottoclassi File Libro Numero_pagine Documento Titolo 0..* StessoAutore 0..* {simmetrica} HuckleberryFinn: Libro TomSawyer : Libro StessoAutore HF.doc: File Stampa_di Generalizzazione Esempio di Object Diagram Dimensione_in_KB Copia() Stampa_di StessoAutore

65 65 © CEFRIEL Unified Modeling Language Generalizzazione ed ereditarietà: Esempi (2) La classe Studente eredita dal padre: –attributi –metodi Un oggetto Studente può essere trattato esattamente come un oggetto Persona In cosa solitamente può differenziarsi la classe erede –aggiunta di attributi e metodi –i metodi possono essere ridefiniti Studente - int matricola - String esami[ ] - int voti[ ] + Studente(String nome, String ind, int mat) + aggiungiEsame(String nome, int voto) + int mediaVoti() Persona - String nome - String indirizzo + Persona(String nome, String ind) + stampa() + String nome() + String indirizzo()

66 66 © CEFRIEL Unified Modeling Language Generalizzazione: Esempi (3) Triangolo Rettangolo + float diagonale() Poligono + Colore colore + sposta(float dx, float dy) + ruota(Punto centro, float angolo) + disegna(Schermo s) Autoveicolo + String targa + String modello + stampaLibretto() VeicoloCommerciale + int pesoCarico + int pesoVuoto + boolean articolato VeicoloPrivato + int numeroPorte + int numeroPosti

67 67 © CEFRIEL Unified Modeling Language Significati della generalizzazione Una sottoclasse può ridefinire alcune proprietà della superclasse Una sottoclasse può anche ridefinire il protocollo delle operazioni –Cioè in una sottoclasse si può ridefinire un’operazione ereditata dalla superclasse, cambiandone anche parametri e tipo restituito

68 68 © CEFRIEL Unified Modeling Language Uso della delega (delegation) Devo definire la classe pila (col solito significato) Dispongo di una classe Sequenza, che vorrei riutilizzare Sequenza insert(pos:int, x:item) delete(pos:int) Pila push(x:item) pop(): item Pila push(x:item) pop(): item Sequenza insert(pos:int, x:item) delete(pos:int) così la pila erediterebbe la possibilità di inserire e togliere elementi da qualunque posizione così la pila contiene (tipicamente nella parte privata) una sequenza di elementi - content

69 69 © CEFRIEL Unified Modeling Language Classi concrete Classi astratte Poligono {abstract} Cerchio Figura {abstract} Triangolo Quadrato Classi astratte Una classe astratta è una classe che non può essere direttamente istanziata Può (anzi deve) avere delle sottoclassi concrete – e queste possono essere istanziate (se non sono astratte a loro volta) Notazione alternativa: nome della classe in corsivo

70 70 © CEFRIEL Unified Modeling Language Classi astratte (2) Il termine “astratto” viene anche utilizzato per per descrivere una operazione per la quale non è stata definita una implementazione –Le operazioni astratte di una classe si rappresentano scrivendo il nome in corsivo Una classe astratta può avere operazioni concrete –Almeno una operazione deve essere astratta Tipicamente vengono usate –per mettere a fattor comune un'astrazione di un certo tipo –per favorire il riuso

71 71 © CEFRIEL Unified Modeling Language Classi astratte: Esempio Il disegno è composto di figure. Non importa come sono fatte. Il disegno sa solo che per disegnare (draw) se stesso può chiamare il metodo draw delle figure. –Aggiungendo una sottoclasse a figura il codice di gestione dei disegni non cambia! Figura Gruppo_FigurePoligonoLinea +figuraPart 1 1..* +draw() #Position : Pos +lineaPart 1 3..* 1..* Disegno +draw()

72 72 © CEFRIEL Unified Modeling Language Eredità multipla VeicoloTerrestre e VeicoloaSpintaUmana sono sottoclassi non disgiunte di Veicolo Bicicletta eredita sia da VeicoloTerrestre, sia da VeicoloaSpintaUmana Veicolo Terrestre Veicolo Veicoloa SpintaUmana AutoBiciclettaBarcaaRemi {propulsione} {superficie}

73 73 © CEFRIEL Unified Modeling Language La delega La delega consiste nel "delegare" una entità apposita (es. RapportoDiLavoro) a svolgere particolari operazioni. Persona Rapporto DiLavoro Senza delega (eredità multipla) Con delega (eredità semplice) Lavoratore Autonomo Lavoratore Dipendete ConPartitaIva Lavoro Autonomo Lavoro Dipendete

74 74 © CEFRIEL Unified Modeling Language PersonaAzienda impiegato 0..1 dipendente * datore di lavoro * capo Vincoli relativi sulle associazioni Persona.datore_di_lavoro = Persona.capo.datore_di_lavoro Nota: in generale, i diagrammi consentono più gradi di libertà di quanti se ne vogliano effettivamente lasciare. Per introdurre vincoli e restrizioni bisogna ricorrere a una notazione testuale. OCL (Object constraint Language) fa questo in modo formale (è un linguaggio logico).

75 75 © CEFRIEL Unified Modeling Language Dipendenza Relazione che indica una dipendenza di varia natura tra elementi di un modello UML –Si può avere dipendenza tra classi, packages, use cases, etc. Individua una connessione “semantica” tra due elementi, uno dei quali è dipendente dall’altro –Una modifica nell’elemento indipendente ha effetti su quello dipendente

76 76 © CEFRIEL Unified Modeling Language Classe A Classe B Classe C Classe D operationZ() > Dipendenza: Esempio

77 77 © CEFRIEL Unified Modeling Language Costrutti di raggruppamento Modulo: raggruppa classi, associazioni e generalizzazioni –fornisce una vista del problema –diminuisce la complessità del problema La suddivisione in moduli può essere fatta in diversi modi. –Criterio: forte coesione, scarse connessioni

78 78 © CEFRIEL Unified Modeling Language Forniscono un costrutto di raggruppamento per gli elementi definiti in un modello UML A volte si utilizza il termine subsystem per indicare un package È possibile definire delle relazioni (tipicamente di dipendenza, raffinamento, generalizzazione) tra packages diversi A B B1 A B A1A2 Packages

79 79 © CEFRIEL Unified Modeling Language Dipendenze tra Packages Descrivono, ad un livello di astrazione più alto, dipendenze esistenti tra elementi contenuti nei singoli packages –dipendenze multiple dello stesso tipo tra singoli elementi (ad es. Classi) appartenenti a packages diversi vengono “riassunte” in una singola dipendenza tra i packages contenenti i diversi elementi Tipologie di relazioni tra packages –Generalizzazione Esiste almeno una relazione di generalizzazione tra elementi appartenenti a package diversi –Dipendenza Esiste almeno una relazione di dipendenza tra elementi appartenenti a package diversi

80 80 © CEFRIEL Unified Modeling Language Dipendenze tra Packages (2) In generale, se non si esplicita una relazione di dipendenza, un package non può accedere agli elementi contenuti in un altro package –Le relazioni di dipendenza definiscono delle “permission” per l’accesso al contenuto di altri packages (limitatamente agli elementi con visibilità public o protected presenti nel package target) Le relazioni di dipendenza tra packages non sono transitive –Se il package A può vedere B e B può vedere C, non è detto che A possa vedere C

81 81 © CEFRIEL Unified Modeling Language > e > > e > Dipendenza con stereotipo > –Gli elementi contenuti nel package target possono essere referenziati dagli elementi contenuti nel package client (o dai sub-package in esso contenuti) –Una dipendenza di tipo > non modifica il namespace del client e non crea riferimenti di alcun tipo Garantisce solo la possibilità di creare refrences Dipendenza con stereotipo > –I nomi degli elementi presenti nel namespace del package target vengono aggiunti al namespace del package client (con le stesse regole di visibilità valide per >) –Se ci sono conflitti fra i nomi importati e nomi già presenti nel namespace del client, il modello è mal formato (ill formed)

82 82 © CEFRIEL Unified Modeling Language Dipendenze tra packages: Esempio

83 83 © CEFRIEL Unified Modeling Language Use Case Diagram È una tipica interazione tra l’utente e il sistema informatico. –Esempi per un word processor: sottolinea una parte di testo crea un indice Quindi, uno use case –rappresenta una funzione visibile dall’utente –rappresenta un obiettivo specifico (atomico) per l’utente –può essere di “dimensioni” diverse –Descrive Il sistema L’ambiente Le relazioni fra sistema e ambiente Ogni caso di utilizzo identificato –È etichettato con un nome –Viene descritto graficamente –Viene descritto con del testo (la notazione grafica non basta)

84 84 © CEFRIEL Unified Modeling Language Use Case: Elementi caratteristici Uno Use case consente di individuare il comportamento (in termini di funzionalità offerte) di un sistema o di una qualsiasi altra entità definita nel sistema senza entrare nel dettaglio della struttura interna dell’entità Uno Use Case individua una tipologia di possibili utilizzi del sistema (descritti testualmente)

85 85 © CEFRIEL Unified Modeling Language Use case diagram Actor Use case >

86 86 © CEFRIEL Unified Modeling Language Use case diagram Esempio: Sistema per la gestione delle vendite dei prodotti di una azienda –Si vuole descrivere la possibilità da parte del venditore di effettuare l’evasione di un ordine Acquisizione Ordine Venditore Attore Use-Case Confine del sistema (non sempre indicato esplicitamente)

87 87 © CEFRIEL Unified Modeling Language Actor (attori) Attore = Entità esterna al sistema che interagisce con il sistema assumendo un particolare ruolo –non c’è necessariamente corrispondenza tra attori e individui precisi –possono esserci diversi utenti con lo stesso ruolo, e diversi ruoli possono essere ricoperti dallo stesso utente –possono esserci diversi attori che esercitano lo stesso use case, e diversi use case possono essere esercitati dallo stesso attore –non è detto che un attore corrisponda a uno o più persone: può essere un sistema esterno nonostante l’icona standard utilizzata per la rappresentazione

88 88 © CEFRIEL Unified Modeling Language Relazioni tra attori e use case Venditore Supervisore Immissione Ordine Attribuzione credito Associazione: Identifica la partecipazione di un attore ad uno Use Case Generalizzazione: Il supervisore può partecipare a tutti gli use case cui partecipa il Venditore (compatibilità!)

89 89 © CEFRIEL Unified Modeling Language Use case diagram: esempio Venditore Verifica stato ordine Acquisizione Ordine Addetto al magazzino Evasione ordine Cliente Supervisore Attribuzione credito

90 90 © CEFRIEL Unified Modeling Language Use Case, Use Case Instances e Scenari Uno Use Case individua una tipologia di “storie” d’uso del sistema Una istanza dello Use Case individua una specifica storia d’uso –Specifica una delle possibili sequenze di azioni che possono avvenire durante lo svolgimento dello use case Scenario: È una istanza di use case corredata da una descrizione esplicita –Il termine “scenario” non è usato in modo sempre consistente.

91 91 © CEFRIEL Unified Modeling Language Scenari Uno “scenario” individua e descrive esplicitamente una particolare istanza di uno use case, ovvero una delle possibili varianti –Ad es. un ordine può essere elaborato regolarmente, o può mancare la merce ordinata o può mancare il credito nei confronti dell’ordinante, … Ciascuno di questi casi è uno scenario specifico dello use case “gestione ordini”. Ogni Use Case è caratterizzato da uno scenario base (sequenza tipica di eventi) e da un numero, imprecisato a priori, di varianti Le varianti possono essere aggiunte nei successivi raffinamenti dello use case

92 92 © CEFRIEL Unified Modeling Language Relazioni tra Use Cases Esistono tre tipi di relazioni possibili tra use cases: –Generalizzazione Simile alla generalizzazione tra classi –Inclusione Il comportamento individuato dallo use case target viene incluso nella sequenza di azioni svolta dalle istanze dello use case base –Estensione Le funzionalità individuate da uno use case base vengono estese, al verificarsi di opportune condizioni, con funzionalità definite in un altro use case >

93 93 © CEFRIEL Unified Modeling Language Esempio Supply Customer Data Order Product Arrange Payment Pay by Money Transfer > Request Catalog with Order > [Order created, P1 ] Place Order Extension Points: P1: After order creation Customer SalesPerson base use case extension use case Pay Cash

94 94 © CEFRIEL Unified Modeling Language I requisiti non funzionali Gli use case non sono adatti a specificare i requisiti non funzionali. Poiché tali requisiti sono di importanza fondamentale occorre inventarsi un modo per descriverli comunque. UML non fornisce alcuna soluzione. Quindi solitamente si ricorre ad una specifica testuale che viene allegata agli use case diagrams.

95 95 © CEFRIEL Unified Modeling Language Interaction diagram e comportamento dinamico del sistema Sono diagrammi che descrivono come gruppi di oggetti collaborano nel mostrare un certo comportamento. Tipicamente rappresentano il comportamento di uno specifico use case –in termini di specifici oggetti e messaggi scambiati Ci sono due tipi di interaction diagram: –Sequence diagram –Collaboration diagram

96 96 © CEFRIEL Unified Modeling Language Sequence diagram Mostra una interazione tra oggetti come sequenza temporale di azioni. –oggetti partecipanti –sequenze (temporali) di messaggi scambiati –non si vedono le associazioni tra oggetti

97 97 © CEFRIEL Unified Modeling Language Oggetti Obj1 Obj2Obj3 a:do_this() b:do_that() c {b-a < 1 sec.} This call is routed through the network Tempo Messaggi Istanti di tempo c’ Vincolo temporale Commento Messaggio che impiega un certo tempo per essere ricevuto Sequence diagram: notazione

98 98 © CEFRIEL Unified Modeling Language physician waveform controller heart rate parameter alarm manager alarm display patient physician sets up for patient monitoring use 4 waveforms Rate=50 Rate=47 setsweep speed(25) Rate=0 set bradycardia alarm set tachycardia alarm asystole event raise bradycardia alarm alarm text Rate=45 physician’s intervention lower bradycardia alarm clear alarm Esempio: sequence diagram

99 99 © CEFRIEL Unified Modeling Language Obj1:C1 op() Obj3:C3 Obj2:C2 [x>=0] foo(x) [x<0] bar(x) doit(w) Agente Oggetto creato da op() Oggetto creato da foo(x) Oggetto preesistente condizione, equivale a if (x>=0) { Obj2=new(C2); Obj2.foo(x); } else Obj3.bar(x); “lifeline” dell’oggetto Notazione estesa: terminologia

100 100 © CEFRIEL Unified Modeling Language Obj1:C1 op() doit(z) more() Obj3:C3 Obj2:C2 Obj4:C4 [x>=0] foo(x) [x<0] bar(x) doit(w) Processi concorrenti e attivazioni

101 101 © CEFRIEL Unified Modeling Language doit(z) more() Obj2:C2 Obj4:C4 doit(w) Distruzione dell’oggetto Oggetto che prosegue la sua esistenza dopo queste interazioni Messaggi “return” Confluenza delle due possibili evoluzioni Attivazioni Attivazione ricorsiva Notazione estesa: terminologia

102 102 © CEFRIEL Unified Modeling Language Collaboration diagram Collaboration: interazione tra parti di un sistema per un certo scopo –si isolano parti di sistema e si trascurano le interazioni non essenziali allo scopo L’interazione è descritta in rapporto agli oggetti e alle relazioni che li legano. Non c’è una dimensione precisa per il tempo –le sequenze temporali sono descrivibili numerando i messaggi in modo progressivo

103 103 © CEFRIEL Unified Modeling Language : OrderEntryWindow : Order LineaTrenini : OrderLineMagazzinoTrenini : Stock : DeliveryItem : ReorderItem 5: NeedToReorder() 1: prepare() 2*: prepare() 7: [check() == true] new 3: check() 4: [check() == true] remove() 6: new oggetto messaggio ordine nella sequenza di messaggi auto-delega Esempio di interazione

104 104 © CEFRIEL Unified Modeling Language State diagram Rappresentano il comportamento di una classe di oggetti, descrivendone i possibili stati e la reazione ad eventi esterni, in termini di cambiamenti di stato e/o azioni svolte. I diagrammi di stato danno un'astrazione di stati, eventi e transizioni Gli stati dei diversi oggetti evolvono concettualmente in parallelo (sincronizzati dagli eventi comuni).

105 105 © CEFRIEL Unified Modeling Language Concetti fondamentali: stati È l'insieme dei valori degli attributi e dei link posseduti da un oggetto in un certo istante Ci interessa lo stato astratto –esempio: motore acceso/spento (non ci interessa il numero di giri/min.) –può corrispondere a diverse - anche infinite - combinazioni di valori degli attributi Lo stato influenza il comportamento –L'oggetto reagisce in modo qualitativamente diverso agli eventi esterni, in funzione dello stato in cui si trova. –Esempio: prelievo da un conto corrente con saldo negativo

106 106 © CEFRIEL Unified Modeling Language Concetti fondamentali: stati Il comportamento quantitativo è influenzato dal valore degli attributi, dei link e dei parametri delle operazioni Uno stato perdura nel tempo –finché un evento non fa cambiare stato all’oggetto (es. un versamento fa passare un conto corrente da saldo negativo a saldo positivo)

107 107 © CEFRIEL Unified Modeling Language Concetti fondamentali: eventi Evento = stimolo esterno –E' istantaneo il tempo è un attributo implicito –Se due eventi sono legati da relazione causa/effetto sono ordinati nel tempo. –Può causare nell'oggetto destinatario un cambio di valore, di stato o la produzione di ulteriori eventi. –Si intende che un evento ha una individualità ben definita raggruppabili in classi di eventi (con attributi caratterizzanti) –La risposta ad uno stimolo dipende dallo stato, e può implicare una transizione di stato esempio del versamento su CC

108 108 © CEFRIEL Unified Modeling Language Messaggio Vocale Inattivo Tono Pronto Compos. Numero ProntoA Connettere Tono Libero Connesso Tono Occupato Tono TimeOut Chiamante.Aggancia T TCompone(n) NumValido NumNonValido Occupato Chiamante.Aggancia Chiamante.Sgancia Ricevente.Sgancia Instradato Compone(n) Diagramma degli stati: Esempio

109 109 © CEFRIEL Unified Modeling Language Inizio AlBianco Muovere AlNero Muovere Matto or Abbandono Stallo or Accordo Mossa Bianca Mossa Nera VinceIlNero VinceIlBianco Patta Matto or Abbandono Stallo or Accordo Stati iniziali e finali Alcuni oggetti hanno diagrammi degli stati ciclici, altri possono avere stati iniziali e/o finali.

110 110 © CEFRIEL Unified Modeling Language Pronto Verde [incrocio.stato=libero] InCorsa Condizione Evento Condizioni Sono funzioni booleane sui valori degli oggetti. Sono valide in un intervallo di tempo Sono utili come guardie delle transizioni di stato (non basta l'evento, deve essere verificata la condizione).

111 111 © CEFRIEL Unified Modeling Language Operazioni Durante la loro vita gli oggetti eseguono operazioni. –associate allo stato (attività) –associate alle alle transizioni (azioni) Le attività hanno una durata –continue –sequenziali Le azioni sono istantanee

112 112 © CEFRIEL Unified Modeling Language Operazioni Azioni –Sono operazioni che hanno durata istantanea (rispetto alla granularità del tempo). Tipicamente produzione di eventi. –Sono associate alle transizioni di stato oppure all'ingresso o all'uscita da uno stato. Attività –Sono operazioni con durata significativa. –Sono associate ad uno stato Continue o sequenziali Transizioni automatiche –Se uno stato ha una attività associata e una freccia senza eventi esce da questo, la freccia indica la transizione svolta automaticamente al completamento della attività.

113 113 © CEFRIEL Unified Modeling Language event3 [condizione1] / azione5 Transizione automatica (evento scatenante fine della attività1) event4 [condizione2] / azione6 Transizione causata dall'evento evento3 sotto condizione condizione1. Vengono eseguite azione2 e azione5 Pseudo transizione causata dall'evento evento4 nell'ordine vengono eseguiti: azione2, azione6, azione1 In caso di ricezione dell'evento1 nello stato A viene eseguito azione3 senza cambio di stato (e quindi senza azioni di entry ed exit) do: attività1 entry / azione1 exit / azione2 event1 / azione3 event2 / azione4 StatoA Notazione generale

114 114 © CEFRIEL Unified Modeling Language right-mouse-down(location) [location in window] / object:=pick-object(location); object.highlight() No object selected One object selected invio di messaggio a object Azioni consistenti nell'invio di eventi Molto spesso le azioni consistono nell'inviare un evento ad un altro oggetto. –esempio: transazione tra stati di un oggetto Window

115 115 © CEFRIEL Unified Modeling Language Invio di eventi Gli eventi possono avere attributi Il destinatario può essere unico o un intero set di oggetti. Tutti gli oggetti riceventi che riconoscono l'evento possono accettarlo e reagire in parallelo. Attenzione alle corse critiche

116 116 © CEFRIEL Unified Modeling Language Invio di eventi: notazione grafica Il segnale accende o spegne Il VCR a seconda dello stato corrente “power” button /VCR.togglePower “power” button /television.togglePower

117 117 © CEFRIEL Unified Modeling Language Problemi dei diagrammi a stati piatti Diventano poco espressivi e troppo ingarbugliati al crescere delle dimensioni del problema. –Ad esempio, il numero di collegamenti possibili tra stati è quadratico nel numero di stati. Soluzione: diagrammi strutturati –la strutturazione favorisce la descrizione sintetica di sistemi complessi L'attività corrispondente ad uno stato può essere espansa in un diagramma a stati di più basso livello, dove ogni stato rappresenta una fase dell'attività. Generalizzazione (specializzazione delle attività, gerarchie di ereditarietà,...) –Aggregazione (stati concorrenti)

118 118 © CEFRIEL Unified Modeling Language FolleRetroMarcia MarciaAvanti PrimaSecondaTerza levaR levaN levaF levaN accelera decelera ferma Cambio Automatico Questa transizione, risposta all'evento ferma, viene ereditata da tutti i sotto- stati di MarciaAvanti Diagrammi a stati strutturati Uno stato strutturato equivale ad una scomposizione OR degli stati: l'oggetto si trova, all'interno di uno stato più generale, in un qualunque sotto-stato. I sottostati ereditano le transizioni dei loro superstati (a meno di overriding)

119 119 © CEFRIEL Unified Modeling Language Diagramma di stato: esempio (1)

120 120 © CEFRIEL Unified Modeling Language Sottostati concorrenti

121 121 © CEFRIEL Unified Modeling Language Naturalmente Attento do: appunti do: sbadiglia do: gratta Distratto noia richiamo Forzatamente Attento do: ghirigori Transazione complessa Sincronizzazione richiamo Concorrenza di due attività

122 122 © CEFRIEL Unified Modeling Language Activity Graph e Activity Diagram Sono dei casi speciali di macchine a stati, in cui –tutti gli stati (o quasi) contengono un’azione o una attività –tutte le transizioni (o quasi) sono causate dal completamento delle azioni/attività negli stati Un activity graph è associato ad una classe, o all'implementazione di un’operazione, o ad uno use case. Un Activity Diagram è un diagramma contenente un activity graph Lo scopo deglio activity graph è di evidenziare l’evoluzione guidata dall’elaborazione interna, in contrapposizione agli eventi esterni (meglio trattati negli state diagram).

123 123 © CEFRIEL Unified Modeling Language Un Activity Graph

124 124 © CEFRIEL Unified Modeling Language oggetti responsabili di azioni oggetto in ingresso o in uscita da un’azione azioni stati degli oggetti Swimlanes (corsie) CustomerWarehouseSales Order [in progress] Order [delivered] Order [forwarded] Order [completed] Request product Ship product Pay bill Receive order Process order Find product Bill [unpaid] Bill [paid]

125 125 © CEFRIEL Unified Modeling Language Implementation diagram Component diagram –mostrano la struttura del codice Deployment diagram –mostrano la struttura del sistema run-time

126 126 © CEFRIEL Unified Modeling Language Component diagram Mostra le dipendenze tra componenti software –sorgenti, binari, eseguibili –esistenti a compile-time, a link-time, a run-time I moduli sono rappresentati come tipi di componenti –le istanze si vedono nei deployment diagram I diversi componenti offrono e usano interfacce specifiche –Primo passo verso Component Programming

127 127 © CEFRIEL Unified Modeling Language Componenti dictionary spell-check synonyms mailer Realizes +Mailbox +RoutingList -MailQueue mailer +Mailbox +RoutingList -MailQueue mailer +RoutingList -MailQueue +Mailbox

128 128 © CEFRIEL Unified Modeling Language Component diagram Un’architettura a “layer”: dipendenze

129 129 © CEFRIEL Unified Modeling Language Component diagram con icone ad-hoc hello.class hello.jpg hello.java hello.html

130 130 © CEFRIEL Unified Modeling Language Deployment diagram Mostrano la configurazione a run-time degli elementi attivi a run-time (e dei componenti, processi e oggetti che vi “vivono”). –processi e/o processori Istanze di componenti software rappresentano le manifestazioni run-time delle unità di codice. Componenti che non esistono a run-time non appaiono in questi diagrammi. I legami fra processi possono essere –Connettori passivi Generici Specializzati con opportuni commenti –Connettori attivi Modellati con opportuni processi

131 131 © CEFRIEL Unified Modeling Language Associazioni Rappresentano le connessioni fisiche tra i nodi Server Client1 Client2 >

132 132 © CEFRIEL Unified Modeling Language Nodi e componenti Un grafo –nodi = risorsa computazionale possono contenere istanze di componenti e/o oggetti –archi = comunicazione tipicamente indicano una relazione di utilizzo Server: Host :scheduler reservations myPC: PC :planner Meetings >

133 133 © CEFRIEL Unified Modeling Language Nodi e componenti Server: Host :scheduler reservations myPC: PC :planner > Mirror: Host :scheduler >

134 134 © CEFRIEL Unified Modeling Language Dove trovare altre informazioni Esistono diverse collezioni di link a siti web contenenti informazioni su strumenti e prodotti vari. –una collezione estesa di riferimenti a siti sull’analisi e progettazione OO (non necessariamente UML).

135 135 © CEFRIEL Unified Modeling Language Bibliografia: Libri Terry Quatrani, Visual Modeling with Rational Rose and UML, Addison-Wesley Unified Modeling Language User Guide Unified Modeling Language Reference Manual H. Eriksson, M. Penker, UML Toolkit, J. Wiley M. Fowler, UML distilled, Addison-Wesley

136 136 © CEFRIEL Unified Modeling Language Bibliografia: URL Rational/IBM –http://www-306.ibm.com/software/rational/ Object Management Group –http://www.omg.org


Scaricare ppt "Politecnico di Milano © 2005 - CEFRIEL UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza CEFRIEL"

Presentazioni simili


Annunci Google