DIAGRAMMI DELLE CLASSI 
INGEGNERIA DEL SOFTWARE 
Università degli Studi di Padova 
Dipartimento di Matematica 
Corso di Laurea in Informatica, A.A. 2014 – 2015 
rcardin@math.unipd.it
SOMMARIO 
 Introduzione 
 Proprietà e Operazioni 
 Concetti base e avanzati 
 Diagrammi degli oggetti 
Ingegneria del software mod. A 
Riccardo Cardin 2
SOMMARIO 
 Introduzione 
 Proprietà e Operazioni 
 Concetti base e avanzati 
 Diagrammi degli oggetti 
Ingegneria del software mod. A 
Riccardo Cardin 3
DIAGRAMMI DELLE CLASSI 
Ingegneria del software mod. A 
Riccardo Cardin 4
DIAGRAMMI DELLE CLASSI 
 Specifica Tecnica, Definizione di Prodotto 
Ingegneria del software mod. A 
Riccardo Cardin 5 
• Diagrammi Use case 
• Diagrammi di flusso 
Revisione dei 
Requisiti 
R. Progetto 
Architetturale 
Revisione di 
Qualifica 
R. di 
Accettazione 
• Diagrammi dei package 
• Diagrammi delle classi 
• Diagrammi degli oggetti 
• Diagrammi di attività 
• Diagrammi di sequenza 
• Diagrammi delle classi 
• Diagrammi di attività 
• Diagrammi di sequenza 
• Diagrammi di flusso
DIAGRAMMI DELLE CLASSI 
 Definizione 
 Descrizione del tipo degli oggetti che fa parte di un 
sistema 
 Relazioni statiche fra i tipi degli oggetti 
Unica parte 
obbligatoria 
Ingegneria del software mod. A 
Riccardo Cardin 6 
Nome della classe 
Attributo 1 
Attributo 2 
Attributo 3 
… 
Operazione 1 
Operazione 2 
… 
Questa è una 
classe!!! 
Features
DIAGRAMMI DELLE CLASSI 
 Definizione: esempio 
Ingegneria del software mod. A 
Riccardo Cardin 7
DIAGRAMMI DELLE CLASSI 
 Esempio principale 
Ingegneria del software mod. A 
Riccardo Cardin 8 
Esempio 
È richiesto lo sviluppo di un’applicazione che permetta la gestione di un semplice blog. 
In particolare devono essere disponibili almeno tutte le funzionalità base di un blog: 
deve essere possibile per un utente inserire un nuovo post e successivamente per gli 
altri utenti deve essere possibile commentarlo. Queste due operazioni devono essere 
disponibili unicamente agli utenti registrati all’interno del sistema. La registrazione 
avviene scegliendo una username e una password. La username deve essere univoca 
all’interno del sistema.
DIAGRAMMI DELLE CLASSI 
 Esempio principale 
Ingegneria del software mod. A 
Riccardo Cardin 9
SOMMARIO 
 Introduzione 
 Proprietà e Operazioni 
 Concetti base e avanzati 
 Diagrammi degli oggetti 
Ingegneria del software mod. A 
Riccardo Cardin 10
PROPRIETÀ 
 Caratteristiche strutturali 
 Attributo 
Definizione 
Visibilità nome : tipo [molteplicità] = default {proprietà aggiuntive} 
 Visibilità: + pubblica, - privata, # protetta 
 Associazione 
 Linea continua e orientata fra due classi 
 Molteplicità 
 Quanti oggetti possono far parte dell’associazione 
 1, 0..1, 0..*, *,… 
 Spesso interscambiabile con un attributo: quando usarla? 
Ingegneria del software mod. A 
Riccardo Cardin 11 
1
PROPRIETÀ 
 Visibilità 
Ingegneria del software mod. A 
Riccardo Cardin 12
PROPRIETÀ 
 Esempio 1 
Ingegneria del software mod. A 
Riccardo Cardin 13
PROPRIETÀ 
 …nel linguaggio di programmazione 
 Attributi 
 Membri di classe (privati, se possibile) 
 Proprietà aggiuntive 
 Se ordered: Array o vettori 
 Se unordered: insiemi 
 Convenzioni dei gruppi di programmazione 
 Esempio: Getter e setter per ogni attributo 
 Associazioni 
 Anche se etichettata con verbo, meglio renderla con un nome 
 Evitare le associazioni bidirezionali 
 Di chi è la responsabilità di aggiornare la relazione? 
Ingegneria del software mod. A 
Riccardo Cardin 14
PROPRIETÀ 
 Esempio 2 
Ingegneria del software mod. A 
public class Commento { 
private String corpo = null; 
private List<Commento commenti = 
new ArrayList<Commento>(); 
public void addCommento(Commento c) { 
Riccardo Cardin 15 
commenti.add(c); 
} 
} 
public class Post { 
private List<Commento> commenti = 
new ArrayList<Commento>(); 
// ... 
public List<Commento> getCommenti() 
{...} 
} 
Java
OPERAZIONI 
 Le azioni che la classe “sa eseguire” 
 Aspetto comportamentale 
 Servizio che può essere richiesto ad ogni istanza della 
classe 
Visibilità nome (lista-parametri) : tipo-ritorno {proprietà aggiuntive} 
 Direzione: in, out, inout (default in) 
 Visibilità: + pubblica, - privata, # protetta 
 Query 
 Modificatori 
 Operazione ≠ metodo 
 Concetti differenti in presenza di polimorfismo 
Ingegneria del software mod. A 
Riccardo Cardin 16 
Lista-parametri := direzione nome : tipo = default 
Definizione
OPERAZIONI 
 Esempio 3 
Modificatori 
Ingegneria del software mod. A 
Riccardo Cardin 17 
Operazioni query 
• addCommento modifica lo stato interno 
di un post 
• getCommenti non modifica lo stato
SOMMARIO 
 Introduzione 
 Proprietà e Operazioni 
 Concetti base e avanzati 
 Diagrammi degli oggetti 
Ingegneria del software mod. A 
Riccardo Cardin 18
COMMENTI E NOTE 
 Informazioni aggiuntive 
 Singole e solitarie 
 Legate a qualsiasi elemento grafico 
 Linea tratteggiata 
 Esempio 5 
Ingegneria del software mod. A 
Riccardo Cardin 19
RELAZIONE DI DIPENDENZA 
 Definizione 
Si ha dipendenza tra due elementi di un diagramma se la modifica alla 
definizione del primo (fornitore) può cambiare la definizione del secondo 
(client) 
 UML permettere di modellare ogni sorta di 
dipendenza 
 Non è una proprietà transitiva! 
 Le dipendenze vanno minimizzate! 
 Loose coupling 
 Da inserire solo quando danno valore aggiunto 
 Troppe dipendenze creano confusione nel diagramma 
Ingegneria del software mod. A 
Riccardo Cardin 20
RELAZIONE DI DIPENDENZA 
 Definizione 
Ingegneria del software mod. A 
Riccardo Cardin 21
RELAZIONE DI DIPENDENZA 
 Dipendenze UML 
Ingegneria del software mod. A 
Riccardo Cardin 22 
Parola chiave Significato 
«call» La sorgente invoca un’operazione della classe destinazione. 
«create» La sorgente crea istanze della classe destinazione. 
«derive» La sorgente è derivata dalla classe destinazione 
«instantiate» La sorgente è una istanza della classe destinazione (meta-classe) 
«permit» La classe destinazione permette alla sorgente di accedere ai suoi campi 
privati. 
«realize» La sorgente è un’implementazione di una specifica o di una interfaccia 
definita dalla sorgente 
«refine» Raffinamento tra differenti livelli semantici. 
«substitute» La sorgente è sostituibile alla destinazione. 
«trace» Tiene traccia dei requisiti o di come i cambiamenti di una parte di modello 
si colleghino ad altre 
«use» La sorgente richiede la destinazione per la sua implementazione.
RELAZIONE DI DIPENDENZA 
 Esempio 6 
Ingegneria del software mod. A 
Riccardo Cardin 23
AGGREGAZIONE E COMPOSIZIONE 
 Aggregazione 
 Relazione di tipo “parte di” (part of) 
 Gli aggregati possono essere 
condivisi 
 Composizione 
 Come aggregazione, ma: 
 Gli aggregati appartengono ad un solo aggregato 
 Solo l’oggetto intero può creare e distruggere le sue parti 
Ingegneria del software mod. A 
Riccardo Cardin 24 
0..1, 1
AGGREGAZIONE E COMPOSIZIONE 
 Esempio 7 
Ingegneria del software mod. A 
Riccardo Cardin 25 
Un’istanza di un 
commento può 
essere presente in 
al più un post!
CLASSI DI ASSOCIAZIONE 
 Aggiungono attributi e operazioni alle 
associazioni 
 Esiste solo una istanza della classe associazione fra i 
due oggeti 
Ingegneria del software mod. A 
Riccardo Cardin 26 
1 
1 
* 
1..* 
Una persona ha 
SOLO UN lavoro in 
un’azienda 
Può essere 
“promossa” 
Una persona può 
avere PIU’ lavori 
in un’azienda
CLASSI DI ASSOCIAZIONE 
 Traduzione in linguaggio di programmazione 
Ingegneria del software mod. A 
Riccardo Cardin 27 
Java 
public class BlogAccount { 
private String name = null; 
private Category[] categories; 
private BlogEntry entries; 
} 
public class Category { 
private String name; 
} 
public class BlogEntry { 
private String name; 
private Category[] categories 
} 
Ovviamente, è 
necessario imporre 
che esista solo 
un’istanza
GENERALIZZAZIONE 
 A generalizza B, se ogni oggetto di B è anche un 
oggetto di A 
 Equivale all’ereditarietà dei linguaggi di programmazione 
 Ereditarietà multipla supportata, ma da NON USARE! 
 Le proprietà della superclasse non si riportano nel 
diagramma della sottoclasse 
 A meno di override 
 Sostituibilità 
 Sottotipo ≠ sottoclasse 
 Interfacce / implementazinoe 
Ingegneria del software mod. A 
Riccardo Cardin 28
GENERALIZZAZIONE 
 Esempio 4 
Ingegneria del software mod. A 
Riccardo Cardin 29 
Gli attributi protected 
sono visibili anche dalle 
classi derivate 
Il metodo della 
classe base è 
ereditato e può 
esserne fatto 
l’override
CLASSI ASTRATTE 
 Classe Astratta {abstract} 
 Classe che non può essere istanziata 
 Operazione astratta non ha implementazione 
 Altre operazioni possono avere implementazione 
Ingegneria del software mod. A 
Riccardo Cardin 30 
getUsername non ha 
implementazione 
Nome in corsivo
INTERFACCE 
 Interfaccia «interface» 
 Classe priva di implementazione 
 Una classe realizza un’interfaccia se ne implementa le 
operazioni 
Ingegneria del software mod. A 
Riccardo Cardin 31 
«Ball» 
notation UML 
2.x 
«Stereotype» 
notation UML 
1.x
INTERFACCE 
 Interfacce 
Ingegneria del software mod. A 
Riccardo Cardin 32 
IPagamento
CLASSIFICAZIONE E GENERALIZZAZIONE 
 Sottotipo ≠ “è un” (IS A) 
 Generalizzazione 
 Proprietà transitiva 
 La classificazione non lo è! 
 Classificazione 
 Dipendenza «instantiate» 
Ingegneria del software mod. A 
Classificazione 
• Shep è un Border Collie 
• Border Collie è una razza 
Riccardo Cardin 33 
Generalizzazione 
• Un Border Collie è un cane 
• I cani sono animali 
• I cani sono una specie
CARATTERISTICHE VARIE 
 Operazioni e attributi statici 
 Applicabili alla classe, non all’oggetto 
 Sottolineati sul diagramma 
 Parole chiave 
 Estensione della semantica UML 
 Costrutto simile + parola chiave! 
 «interface» 
 {abstract} 
 Responsabilità 
 Funzionalità offerte 
 Aggiunta alla classe con commento 
Ingegneria del software mod. A 
Riccardo Cardin 34
CARATTERISTICHE VARIE 
 Proprietà derivate 
 Possono essere calcolate a partire da altri valori 
 Definiscono un vincolo fra valori 
 Si indicano con “/” che precede il nome della proprietà 
 Proprietà read only e frozen 
 {readOnly} 
 Non vengono forniti i servizi di scrittura 
 {frozen} 
 Immutabile, non può variare nel suo ciclo di vita 
 Enumerazioni 
 Insiemi di valori che non hanno altre proprietà oltre il valore 
simbolico 
 «enumeration» 
Ingegneria del software mod. A 
Riccardo Cardin 35
CARATTERISTICHE VARIE 
 Classi Parametriche 
 T è detto “segnaposto” 
 Come template C++ o 
generics Java 
Ingegneria del software mod. A 
Riccardo Cardin 36 
Raffinamento
CARATTERISTICHE VARIE 
 Classi Attive 
 Eseguono e controllano il proprio thread 
Ingegneria del software mod. A 
Riccardo Cardin 37
CONSIGLI UTILI 
 Diagrammi molto ricchi di concetti 
 Non cercare di utilizzare tutte le notazioni disponibili 
 Cominciare dapprima con i concetti semplici 
 Una prospettiva concettuale permette di esplorare il 
linguaggio di un particolare business 
 Mantenere la notazione semplice e non introdurre concetti 
legati al software 
 Concentrarsi nel disegno dei diagrammi delle parti 
più importanti 
 Disegnare ogni cosa è sinonimo di diagrammi non 
fondamentali che diventano obsoleti molto presto! 
Ingegneria del software mod. A 
Riccardo Cardin 38
SOMMARIO 
 Introduzione 
 Proprietà e Operazioni 
 Concetti base e avanzati 
 Diagrammi degli oggetti 
Ingegneria del software mod. A 
Riccardo Cardin 39
DIAGRAMMI DEGLI OGGETTI 
 Grafo delle istanze, comprensivo di associazioni 
e valori delle proprietà 
 Fotografia degli oggetti che compongono un sistema 
 Non ci sono parti obbligatorie 
 Specifica di istanza 
 Anche di classi astratte, omissione dei metodi, ecc… 
Ingegneria del software mod. A 
Riccardo Cardin 40 
nome dell’istanza : nome della classe
RIFERIMENTI 
OMG Homepage – www.omg.org 
 UML Homepage – www.uml.org 
 UML Distilled, Martin Fowler, 2004, Pearson 
(Addison Wesley) 
 Learning UML 2.0, Kim Hamilton, Russell Miles, 
O’Reilly, 2006 
Ingegneria del software mod. A 
Riccardo Cardin 41

Diagrammi delle Classi

  • 1.
    DIAGRAMMI DELLE CLASSI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2014 – 2015 rcardin@math.unipd.it
  • 2.
    SOMMARIO  Introduzione  Proprietà e Operazioni  Concetti base e avanzati  Diagrammi degli oggetti Ingegneria del software mod. A Riccardo Cardin 2
  • 3.
    SOMMARIO  Introduzione  Proprietà e Operazioni  Concetti base e avanzati  Diagrammi degli oggetti Ingegneria del software mod. A Riccardo Cardin 3
  • 4.
    DIAGRAMMI DELLE CLASSI Ingegneria del software mod. A Riccardo Cardin 4
  • 5.
    DIAGRAMMI DELLE CLASSI  Specifica Tecnica, Definizione di Prodotto Ingegneria del software mod. A Riccardo Cardin 5 • Diagrammi Use case • Diagrammi di flusso Revisione dei Requisiti R. Progetto Architetturale Revisione di Qualifica R. di Accettazione • Diagrammi dei package • Diagrammi delle classi • Diagrammi degli oggetti • Diagrammi di attività • Diagrammi di sequenza • Diagrammi delle classi • Diagrammi di attività • Diagrammi di sequenza • Diagrammi di flusso
  • 6.
    DIAGRAMMI DELLE CLASSI  Definizione  Descrizione del tipo degli oggetti che fa parte di un sistema  Relazioni statiche fra i tipi degli oggetti Unica parte obbligatoria Ingegneria del software mod. A Riccardo Cardin 6 Nome della classe Attributo 1 Attributo 2 Attributo 3 … Operazione 1 Operazione 2 … Questa è una classe!!! Features
  • 7.
    DIAGRAMMI DELLE CLASSI  Definizione: esempio Ingegneria del software mod. A Riccardo Cardin 7
  • 8.
    DIAGRAMMI DELLE CLASSI  Esempio principale Ingegneria del software mod. A Riccardo Cardin 8 Esempio È richiesto lo sviluppo di un’applicazione che permetta la gestione di un semplice blog. In particolare devono essere disponibili almeno tutte le funzionalità base di un blog: deve essere possibile per un utente inserire un nuovo post e successivamente per gli altri utenti deve essere possibile commentarlo. Queste due operazioni devono essere disponibili unicamente agli utenti registrati all’interno del sistema. La registrazione avviene scegliendo una username e una password. La username deve essere univoca all’interno del sistema.
  • 9.
    DIAGRAMMI DELLE CLASSI  Esempio principale Ingegneria del software mod. A Riccardo Cardin 9
  • 10.
    SOMMARIO  Introduzione  Proprietà e Operazioni  Concetti base e avanzati  Diagrammi degli oggetti Ingegneria del software mod. A Riccardo Cardin 10
  • 11.
    PROPRIETÀ  Caratteristichestrutturali  Attributo Definizione Visibilità nome : tipo [molteplicità] = default {proprietà aggiuntive}  Visibilità: + pubblica, - privata, # protetta  Associazione  Linea continua e orientata fra due classi  Molteplicità  Quanti oggetti possono far parte dell’associazione  1, 0..1, 0..*, *,…  Spesso interscambiabile con un attributo: quando usarla? Ingegneria del software mod. A Riccardo Cardin 11 1
  • 12.
    PROPRIETÀ  Visibilità Ingegneria del software mod. A Riccardo Cardin 12
  • 13.
    PROPRIETÀ  Esempio1 Ingegneria del software mod. A Riccardo Cardin 13
  • 14.
    PROPRIETÀ  …nellinguaggio di programmazione  Attributi  Membri di classe (privati, se possibile)  Proprietà aggiuntive  Se ordered: Array o vettori  Se unordered: insiemi  Convenzioni dei gruppi di programmazione  Esempio: Getter e setter per ogni attributo  Associazioni  Anche se etichettata con verbo, meglio renderla con un nome  Evitare le associazioni bidirezionali  Di chi è la responsabilità di aggiornare la relazione? Ingegneria del software mod. A Riccardo Cardin 14
  • 15.
    PROPRIETÀ  Esempio2 Ingegneria del software mod. A public class Commento { private String corpo = null; private List<Commento commenti = new ArrayList<Commento>(); public void addCommento(Commento c) { Riccardo Cardin 15 commenti.add(c); } } public class Post { private List<Commento> commenti = new ArrayList<Commento>(); // ... public List<Commento> getCommenti() {...} } Java
  • 16.
    OPERAZIONI  Leazioni che la classe “sa eseguire”  Aspetto comportamentale  Servizio che può essere richiesto ad ogni istanza della classe Visibilità nome (lista-parametri) : tipo-ritorno {proprietà aggiuntive}  Direzione: in, out, inout (default in)  Visibilità: + pubblica, - privata, # protetta  Query  Modificatori  Operazione ≠ metodo  Concetti differenti in presenza di polimorfismo Ingegneria del software mod. A Riccardo Cardin 16 Lista-parametri := direzione nome : tipo = default Definizione
  • 17.
    OPERAZIONI  Esempio3 Modificatori Ingegneria del software mod. A Riccardo Cardin 17 Operazioni query • addCommento modifica lo stato interno di un post • getCommenti non modifica lo stato
  • 18.
    SOMMARIO  Introduzione  Proprietà e Operazioni  Concetti base e avanzati  Diagrammi degli oggetti Ingegneria del software mod. A Riccardo Cardin 18
  • 19.
    COMMENTI E NOTE  Informazioni aggiuntive  Singole e solitarie  Legate a qualsiasi elemento grafico  Linea tratteggiata  Esempio 5 Ingegneria del software mod. A Riccardo Cardin 19
  • 20.
    RELAZIONE DI DIPENDENZA  Definizione Si ha dipendenza tra due elementi di un diagramma se la modifica alla definizione del primo (fornitore) può cambiare la definizione del secondo (client)  UML permettere di modellare ogni sorta di dipendenza  Non è una proprietà transitiva!  Le dipendenze vanno minimizzate!  Loose coupling  Da inserire solo quando danno valore aggiunto  Troppe dipendenze creano confusione nel diagramma Ingegneria del software mod. A Riccardo Cardin 20
  • 21.
    RELAZIONE DI DIPENDENZA  Definizione Ingegneria del software mod. A Riccardo Cardin 21
  • 22.
    RELAZIONE DI DIPENDENZA  Dipendenze UML Ingegneria del software mod. A Riccardo Cardin 22 Parola chiave Significato «call» La sorgente invoca un’operazione della classe destinazione. «create» La sorgente crea istanze della classe destinazione. «derive» La sorgente è derivata dalla classe destinazione «instantiate» La sorgente è una istanza della classe destinazione (meta-classe) «permit» La classe destinazione permette alla sorgente di accedere ai suoi campi privati. «realize» La sorgente è un’implementazione di una specifica o di una interfaccia definita dalla sorgente «refine» Raffinamento tra differenti livelli semantici. «substitute» La sorgente è sostituibile alla destinazione. «trace» Tiene traccia dei requisiti o di come i cambiamenti di una parte di modello si colleghino ad altre «use» La sorgente richiede la destinazione per la sua implementazione.
  • 23.
    RELAZIONE DI DIPENDENZA  Esempio 6 Ingegneria del software mod. A Riccardo Cardin 23
  • 24.
    AGGREGAZIONE E COMPOSIZIONE  Aggregazione  Relazione di tipo “parte di” (part of)  Gli aggregati possono essere condivisi  Composizione  Come aggregazione, ma:  Gli aggregati appartengono ad un solo aggregato  Solo l’oggetto intero può creare e distruggere le sue parti Ingegneria del software mod. A Riccardo Cardin 24 0..1, 1
  • 25.
    AGGREGAZIONE E COMPOSIZIONE  Esempio 7 Ingegneria del software mod. A Riccardo Cardin 25 Un’istanza di un commento può essere presente in al più un post!
  • 26.
    CLASSI DI ASSOCIAZIONE  Aggiungono attributi e operazioni alle associazioni  Esiste solo una istanza della classe associazione fra i due oggeti Ingegneria del software mod. A Riccardo Cardin 26 1 1 * 1..* Una persona ha SOLO UN lavoro in un’azienda Può essere “promossa” Una persona può avere PIU’ lavori in un’azienda
  • 27.
    CLASSI DI ASSOCIAZIONE  Traduzione in linguaggio di programmazione Ingegneria del software mod. A Riccardo Cardin 27 Java public class BlogAccount { private String name = null; private Category[] categories; private BlogEntry entries; } public class Category { private String name; } public class BlogEntry { private String name; private Category[] categories } Ovviamente, è necessario imporre che esista solo un’istanza
  • 28.
    GENERALIZZAZIONE  Ageneralizza B, se ogni oggetto di B è anche un oggetto di A  Equivale all’ereditarietà dei linguaggi di programmazione  Ereditarietà multipla supportata, ma da NON USARE!  Le proprietà della superclasse non si riportano nel diagramma della sottoclasse  A meno di override  Sostituibilità  Sottotipo ≠ sottoclasse  Interfacce / implementazinoe Ingegneria del software mod. A Riccardo Cardin 28
  • 29.
    GENERALIZZAZIONE  Esempio4 Ingegneria del software mod. A Riccardo Cardin 29 Gli attributi protected sono visibili anche dalle classi derivate Il metodo della classe base è ereditato e può esserne fatto l’override
  • 30.
    CLASSI ASTRATTE Classe Astratta {abstract}  Classe che non può essere istanziata  Operazione astratta non ha implementazione  Altre operazioni possono avere implementazione Ingegneria del software mod. A Riccardo Cardin 30 getUsername non ha implementazione Nome in corsivo
  • 31.
    INTERFACCE  Interfaccia«interface»  Classe priva di implementazione  Una classe realizza un’interfaccia se ne implementa le operazioni Ingegneria del software mod. A Riccardo Cardin 31 «Ball» notation UML 2.x «Stereotype» notation UML 1.x
  • 32.
    INTERFACCE  Interfacce Ingegneria del software mod. A Riccardo Cardin 32 IPagamento
  • 33.
    CLASSIFICAZIONE E GENERALIZZAZIONE  Sottotipo ≠ “è un” (IS A)  Generalizzazione  Proprietà transitiva  La classificazione non lo è!  Classificazione  Dipendenza «instantiate» Ingegneria del software mod. A Classificazione • Shep è un Border Collie • Border Collie è una razza Riccardo Cardin 33 Generalizzazione • Un Border Collie è un cane • I cani sono animali • I cani sono una specie
  • 34.
    CARATTERISTICHE VARIE Operazioni e attributi statici  Applicabili alla classe, non all’oggetto  Sottolineati sul diagramma  Parole chiave  Estensione della semantica UML  Costrutto simile + parola chiave!  «interface»  {abstract}  Responsabilità  Funzionalità offerte  Aggiunta alla classe con commento Ingegneria del software mod. A Riccardo Cardin 34
  • 35.
    CARATTERISTICHE VARIE Proprietà derivate  Possono essere calcolate a partire da altri valori  Definiscono un vincolo fra valori  Si indicano con “/” che precede il nome della proprietà  Proprietà read only e frozen  {readOnly}  Non vengono forniti i servizi di scrittura  {frozen}  Immutabile, non può variare nel suo ciclo di vita  Enumerazioni  Insiemi di valori che non hanno altre proprietà oltre il valore simbolico  «enumeration» Ingegneria del software mod. A Riccardo Cardin 35
  • 36.
    CARATTERISTICHE VARIE Classi Parametriche  T è detto “segnaposto”  Come template C++ o generics Java Ingegneria del software mod. A Riccardo Cardin 36 Raffinamento
  • 37.
    CARATTERISTICHE VARIE Classi Attive  Eseguono e controllano il proprio thread Ingegneria del software mod. A Riccardo Cardin 37
  • 38.
    CONSIGLI UTILI Diagrammi molto ricchi di concetti  Non cercare di utilizzare tutte le notazioni disponibili  Cominciare dapprima con i concetti semplici  Una prospettiva concettuale permette di esplorare il linguaggio di un particolare business  Mantenere la notazione semplice e non introdurre concetti legati al software  Concentrarsi nel disegno dei diagrammi delle parti più importanti  Disegnare ogni cosa è sinonimo di diagrammi non fondamentali che diventano obsoleti molto presto! Ingegneria del software mod. A Riccardo Cardin 38
  • 39.
    SOMMARIO  Introduzione  Proprietà e Operazioni  Concetti base e avanzati  Diagrammi degli oggetti Ingegneria del software mod. A Riccardo Cardin 39
  • 40.
    DIAGRAMMI DEGLI OGGETTI  Grafo delle istanze, comprensivo di associazioni e valori delle proprietà  Fotografia degli oggetti che compongono un sistema  Non ci sono parti obbligatorie  Specifica di istanza  Anche di classi astratte, omissione dei metodi, ecc… Ingegneria del software mod. A Riccardo Cardin 40 nome dell’istanza : nome della classe
  • 41.
    RIFERIMENTI OMG Homepage– www.omg.org  UML Homepage – www.uml.org  UML Distilled, Martin Fowler, 2004, Pearson (Addison Wesley)  Learning UML 2.0, Kim Hamilton, Russell Miles, O’Reilly, 2006 Ingegneria del software mod. A Riccardo Cardin 41