Luigi Lavazza CEFRIEL lavazza@cefriel.it UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza CEFRIEL lavazza@cefriel.it.

Presentazione sul tema: "Luigi Lavazza CEFRIEL lavazza@cefriel.it UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza CEFRIEL lavazza@cefriel.it."— Transcript della presentazione:

1 Luigi Lavazza CEFRIEL lavazza@cefriel.it
UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza CEFRIEL © CEFRIEL

2 Sommario Introduzione ai linguaggi di modellazione
Fondamenti del paradigma object-oriented UML: il linguaggio Esempi di modellazione con UML 1. Introduzione ai linguaggi di modellazione Astrazione Modelli Domini dei modelli 2. Fondamenti del paradigma object-oriented Classificazione Oggetti Messaggi Composizione Generalizzazione/specializzazione 3. UML: il linguaggio I diagrammi rilevanti 4. Esempi di modellazione con UML Libro verde Biblioteca Ricondizionamento di PC Unified Modeling Language © CEFRIEL

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

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

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

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

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

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

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

10 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 il modulo deve distinguere tra informazioni pubbliche ed informazioni private Unified Modeling Language © CEFRIEL

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

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

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

14 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à) Unified Modeling Language © CEFRIEL

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

16 Stile Stile descrittivo: definisce le proprietà desiderate
Es. La curva soddisfa l’equazione ax2 + by2 + 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. Unified Modeling Language © CEFRIEL

17 Il paradigma object-oriented
© CEFRIEL

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

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

20 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 La classe conto corrente sarà dotata delle operazioni di versamento, prelevamento, bonifico, ecc. Unified Modeling Language © CEFRIEL

21 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, … Unified Modeling Language © CEFRIEL

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

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

24 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. Prelievo Persona Conto corrente Unified Modeling Language © CEFRIEL

25 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 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). Unified Modeling Language © CEFRIEL

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

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

28 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". Unified Modeling Language © CEFRIEL

29 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 Carlo Maria Maria Luca Luca Luca Unified Modeling Language © CEFRIEL

30 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 Carlo Maria Maria 16 15 Luca Luca Unified Modeling Language © CEFRIEL

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

32 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 Animale Rettile Mammifero Uccello Felino Primate Unified Modeling Language © CEFRIEL

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

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

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

36 Polimorfismo Conseguenza dell’esistenza di generalizzazione e della compatibilità delle sottoclassi rispetto alle superclassi Attributi: Colore Operazioni: Rotazione Disegno Disegno Composto_da Figura 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 FiguraChiusa FiguraAperta Poligono Ellisse Rettangolo Unified Modeling Language © CEFRIEL

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

38 Dynamic binding Binding: Dynamic 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 Unified Modeling Language © CEFRIEL

39 Dynamic binding: esempio
Tipo statico Rotazione Disegno Figura Composto_da FiguraChiusa FiguraAperta 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. Poligono Ellisse Rettangolo Unified Modeling Language © CEFRIEL

40 Unified Modeling Language
© CEFRIEL

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

42 Situazione Dove trovare informazioni costantemente aggiornate:
internet newsgroup comp.object 2004 Unified Modeling Language © CEFRIEL 3

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

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

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

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

47 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 Classi con attributi e operazioni Persona File Disegno Nome: string Età: int Nome: string Dimensione: int Creazione: data Titolo: string Altezza: int Larghezza: int CambiaLavoro CambiaIndirizzo Stampa Stampa Ruota(gradi: int) Unified Modeling Language © CEFRIEL

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

49 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 Nome (opzionale) dell'associazione Città Regione CapoluogoDi Nome: string Nome: string Nota: una associazione è naturalmente bidirezionale. Unified Modeling Language © CEFRIEL 21

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

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

52 Notazione per la cardinalità
Persona Auto Possiede Nome: string Modello: string 0..* 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 Unified Modeling Language © CEFRIEL

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

54 Attributi delle associazioni (Association Class)
In molti casi alcune proprietà sono proprie dell'associazione piuttosto che delle classi coinvolte. 1..* 1..* Studente Corso 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) Unified Modeling Language © CEFRIEL 28

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

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

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

58 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. presidente C.A.Ciampi: Persona cittadino Italia: Repubblica cittadino Dario Fo: Persona Unified Modeling Language © CEFRIEL 20

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

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

61 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 1..* 0..1 Monitor UnitàBase Mouse Tastiera 1..4 1..2 1..3 1..2 0..1 HardDisk CD ModuloRAM CPU Coprocessore Unified Modeling Language © CEFRIEL 36

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

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

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

65 Generalizzazione ed ereditarietà: Esempi (2)
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() 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 Unified Modeling Language © CEFRIEL

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

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

68 Uso della delega (delegation)
Devo definire la classe pila (col solito significato) Dispongo di una classe Sequenza, che vorrei riutilizzare Sequenza Pila - content insert(pos:int, x:item) delete(pos:int) 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 Pila così la pila contiene (tipicamente nella parte privata) una sequenza di elementi push(x:item) pop(): item Unified Modeling Language © CEFRIEL

69 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) Figura {abstract} Notazione alternativa: nome della classe in corsivo Classi astratte Poligono {abstract} Cerchio Classi concrete Quadrato Triangolo Unified Modeling Language © CEFRIEL 48

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

71 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_Figure Poligono Linea +figuraPart 1 1..* +draw() #Position : Pos +lineaPart 3..* Disegno Unified Modeling Language © CEFRIEL

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

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

74 Vincoli relativi sulle associazioni
dipendente datore di lavoro 0..1 impiegato 0..* Persona Azienda 1..* 0..1 capo 0..1 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). Unified Modeling Language © CEFRIEL 61

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

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

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

78 Packages 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 A B A1 A2 B1 B Unified Modeling Language © CEFRIEL

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

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

81 <<import>> e <<access>>
Dipendenza con stereotipo <<access>> 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 <<access>> non modifica il namespace del client e non crea riferimenti di alcun tipo Garantisce solo la possibilità di creare refrences Dipendenza con stereotipo <<import>> 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 <<access>>) Se ci sono conflitti fra i nomi importati e nomi già presenti nel namespace del client, il modello è mal formato (ill formed) Unified Modeling Language © CEFRIEL

82 Dipendenze tra packages: Esempio
Unified Modeling Language © CEFRIEL

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

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

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

86 (non sempre indicato esplicitamente)
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 Use-Case Attore Acquisizione Ordine Venditore Confine del sistema (non sempre indicato esplicitamente) Unified Modeling Language © CEFRIEL

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

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

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

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

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

92 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 <<include>> <<extend>> Unified Modeling Language © CEFRIEL

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

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

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

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

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

98 Esempio: sequence diagram
waveform controller heart rate parameter alarm manager alarm display physician patient physician sets up for patient monitoring use 4 waveforms Rate=50 setsweep speed(25) Rate=47 set bradycardia alarm set tachycardia alarm asystole event Rate=0 raise bradycardia alarm The physician powers up the ECG machine. The physician sets up for four waveforms at 25 mm/sec sweep speed. The physician sets the bradycardia alarm at 40 bpm and the tachycardia alarm at 110 bpm. The patient undergoes an asystole event. The system detects the asystole and raises the alarm. The physician provides therapy to correct the problem (external to the system boundary). The system detects the restarted heart rate to be 45 bpm and lowers the alarm. ... physician’s intervention alarm text Rate=45 lower bradycardia alarm clear alarm Unified Modeling Language © CEFRIEL 8

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

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

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

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

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

104 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). Unified Modeling Language © CEFRIEL 2

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

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

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

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

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

110 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). Evento Condizione Pronto Verde [incrocio.stato=libero] InCorsa Unified Modeling Language © CEFRIEL 16

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

112 Operazioni Azioni Attività Transizioni automatiche
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à. Unified Modeling Language © CEFRIEL 18

113 Notazione generale Transizione causata dall'evento evento3 sotto condizione condizione1. Vengono eseguite azione2 e azione5 StatoA 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 event3 [condizione1] / azione5 event4 [condizione2] / azione6 Transizione automatica (evento scatenante fine della attività1) Pseudo transizione causata dall'evento evento4 nell'ordine vengono eseguiti: azione2, azione6, azione1 Unified Modeling Language © CEFRIEL 19

114 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 right-mouse-down(location) [location in window] / object:=pick-object(location); object.highlight() No object selected One object selected invio di messaggio a object Unified Modeling Language © CEFRIEL 20

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

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

117 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) Unified Modeling Language © CEFRIEL 23

118 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) levaR Folle RetroMarcia Cambio Automatico levaN Questa transizione, risposta all'evento ferma, viene ereditata da tutti i sotto-stati di MarciaAvanti levaF levaN MarciaAvanti accelera accelera ferma Prima Seconda Terza decelera decelera Unified Modeling Language © CEFRIEL 24

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

120 Sottostati concorrenti
Unified Modeling Language © CEFRIEL 29

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

122 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). Unified Modeling Language © CEFRIEL

123 Un Activity Graph Unified Modeling Language © CEFRIEL 35

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

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

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

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

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

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

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

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

132 <<database>>
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 <<database>> Meetings reservations :scheduler myPC: PC :planner Unified Modeling Language © CEFRIEL

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

134 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). Unified Modeling Language © CEFRIEL 8

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

136 Bibliografia: URL Rational/IBM Object Management Group
Object Management Group Unified Modeling Language © CEFRIEL 3