Diagrammi_classi2.0

Transcript

Diagrammi_classi2.0
Diagrammi delle classi
 Tecnica centrale di modellazione OO
 Descrizione strutturale statica degli oggetti che compongono il sistema
(comprensiva di attributi e operazioni) e delle loro relazioni (restrizioni
incluse)
 Descrizione dei vincoli
 Sono simili ai modelli per i dati  è facile basare erroneamente il loro
sviluppo sui dati piuttosto che sulle responsabilità
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
1
Concetti essenziali
Elementi
Sintassi
Classe
Scatola suddivisa in tre parti orizzontali, contenenti
rispettivamente nome, attributi (lo stato) e operazioni (il
comportamento);
nome è una stringa in grassetto che identifica univocamente
la classe e può essere preceduta dal nome del package che
contiene la classe (es. java::awt::Rectangle); la sezione del
nome è l’unica obbligatoria
nome
attributi
operazioni
Semantica
Insieme di
oggetti che
condividono
gli stessi
attributi,
operazioni,
relazioni e
semantica
Shape
origin
height : Float
Is Empty : Boolean = false
move ( )
resize ( )
display ( )
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
2
Concetti essenziali (cont.)
Elementi
Sintassi
Attributo
visibilità nome: tipo
[molteplicità] = valore-didefault {stringa-elencoproprietà-aggiuntive}
dove solo nome, che è una
stringa, è obbligatorio
Semantica
default = valore in un oggetto appena
creato, se non specificato diversamente
durante la creazione
Se la stringa delle proprietà aggiuntive
non è presente, generalmente
l’attributo è modificabile
Es. – titolo: String
[1] = “UML distilled”
{readOnly}
Visibilità
(di attributi
e
operazioni)
+ (pubblica)
- (privata)
# (protected)
~ (package)
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
 Gli elementi pubblici possono essere
usati da un’altra classe, quelli privati
invece sono riservati all’uso interno
 Per la semantica precisa degli
identificatori bisogna fare riferimento
alle regole del linguaggio di
programmazione adottato
3
Associazione
associazione
molteplicità
1..*
Persona
dipendente
*
datore di
lavoro
Azienda
nome del
ruolo
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
4
Concetti essenziali (cont.)
Elementi
Sintassi
Associazione Linea continua che unisce
(o ruolo)
due classi; opzionalmente
ciascun capo della linea può
terminare con una punta
biforcuta, che indica la
navigabilità, e può essere
etichettato con:
 molteplicità (es. 1, *, 0..1)
 nome del ruolo (stringa da
specificare solo quando fa
aumentare la
comprensibilità, altrimenti
il nome implicito del ruolo
è quello della classe
attaccata al capo)
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
 Relazione statica fra le istanze di
due classi;
 la molteplicità è il numero di
oggetti che prendono parte a tale
relazione;
 la navigabilità è il verso di
percorribilità del collegamento (e non
è rilevante nel modello concettuale);
 l’assenza dell’indicazione di
navigabilità si interpreta o come
mancanza di info circa la stessa o
come associazione bidirezionale, che
è difficile da implementare perché
richiede che le due proprietà siano
sempre “sincronizzate”
5
Proprietà di una classe
Proprietà espressa come attributo
Ordine
+ data : Data [0 .. 1]
prepagato : Boolean [1]
cliente
Proprietà espressa come associazione
navigabilità
Ordine
+ data : Data [0 .. 1]
prepagato : Boolean [1]
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Cliente
*
1
6
Molteplicità delle proprietà
 Si indicano gli estremi inferiore e superiore di un intervallo, come 2..4, dove *
rappresenta un valore illimitato
 1 equivale a 1..1
 * è un’abbreviazione per 0..*
 Se una proprietà ha più valori, è preferibile indicare il suo nome in forma
plurale
 Gli elementi di una molteplicità a più valori formano un insieme; se ciò non è
accettabile, è necessario dare un’indicazione diversa come {ordered},
{nonunique} o {bag}
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
7
Molteplicità delle proprietà
Elementi
Sintassi
{ordered}
Vincoli circa
una molteplicità {nonunique}
{bag}
a più valori
{hierarchy}
{dag}
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
Possono coesistere anche più vincoli
(purché matematicamente consistenti)
 {ordered}: esiste un ordinamento
fra gli elementi
 {nonunique}: gli elementi
possono comparire più volte
 {bag}: gli elementi formano un
multinsieme
 {hierarchy}: gli elementi
formano una gerarchia
 {dag}: gli elementi formano un
DAG (grafo orientato aciclico)
8
Verbo come nome di associazione
Possiede
0..1
Imprenditore
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
*
Azienda
9
Diagrammi delle classi: concetti essenziali (cont.)
Elementi
Sintassi
Operazione visibilità nome (lista-parametri):
tipo-ritornato {stringaproprietà}
dove
 nome è una stringa,
 lista-parametri è una serie di
parametri, ciascuno specificato
mediante un elemento direzione
nome: tipo = valore-di-default e
separato dal successivo mediante
una virgola (la direzione può
assumere i valori in, out, inout,
se manca si presume sia in),
 stringa-proprietà indica i
valori delle proprietà
dell’operazione, cioè query,
modificatore, get e set
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
Azione che una classe sa come eseguire;
 se un’operazione i) non modifica lo
stato del sistema e ii) ritorna dei valori è
una query,
 se un’operazione i) modifica lo stato
osservabile del sistema e ii) non ritorna
valori è un modificatore;
 un metodo get è una particolare query
che restituisce il valore di un attributo e
non fa nient’altro;
 un metodo set è un particolare
modificatore che assegna il valore a esso
passato a un attributo e non fa nient’altro
Una convenzione comune è cercare di
scrivere modificatori che non restituiscano
mai valori
10
Operazioni
 Quelle che manipolano le proprietà della classe di solito si possono dedurre,
per cui non sono incluse nel diagramma
 Nei modelli concettuali, dovrebbero indicare le principali responsabilità della
classe, magari facendo riferimento a una carta CRC
 Corrispondono alla dichiarazione di una procedura e, quindi, si distinguono
(sottilmente) dai metodi, che invece corrispondono al corpo della procedura 
le due cose sono diverse in presenza di polimorfismo
Responsabilità di una classe = obbligo che la classe si assume nello svolgere un
servizio. Fa parte del contratto che essa stipula con le altre classi
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
11
Concetti essenziali (cont.)
Toolbar
# currentSelection: Tool
# toolCount: Integer
+ pickItem(i: Integer)
+ addTool(t: Tool)
+ removeTool(i: Integer)
+ getTool(): Tool
# checkOrphans()
- compact()
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
12
Concetti essenziali (cont.)
Elementi
Sintassi
Generalizzazione Freccia con testa vuota e uno
o più capi: la testa termina
nella superclasse, i capi si
dipartono ciascuno da una
sottoclasse
Nota
Testo
 che segue due trattini –all'interno di un elemento
del diagramma, oppure
 contenuto in una scatola
con “orecchietta”,
eventualmente collegata
all’elemento a cui si
riferisce mediante una linea
tratteggiata
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
Se due o più classi sono
diverse ma mostrano anche
molte somiglianze, queste si
possono raccogliere in una
superclasse (relazione IS-A)
Commento aggiuntivo
Una o più note possono
apparire in qualsiasi tipo di
diagramma UML
Una convenzione comune
prevede di mettere un
cerchietto vuoto all’estremità
della linea tratteggiata, per
meglio collegarla all’elemento
a cui si riferisce
13
Concetti essenziali (cont.)
1
*
Window
associazione
Shape
Ogni forma geometrica
visualizzabile in una finestra
move ( )
resize ( )
display ( )
generalizzazione
Rectangle
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Circle
14
Prospettive e diagrammi delle classi
Prospettiva
Concettuale
(da adottarsi
per realizzare il
modello di
dominio nella
fase di
elaborazione
del RUP)
Interpretazione
classe = concetto nella mente del cliente ( il diagramma
diventa il linguaggio dell’interlocutore)
associazione = relazione fra concetti (la navigabilità non è utile)
attributo = proprietà degli oggetti della classe, notazione
alternativa rispetto all’associazione
operazione = una delle responsabilità principali della classe
generalizzazione: qualsiasi cosa si possa dire del supertipo (in
termini di associazioni, attributi e operazioni), si può dire anche
dei sottotipi
N.B. Le responsabilità di una classe possono essere descritte ciascuna mediante
una nota inserita entro il riquadro della classe
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
15
Prospettive e diagrammi delle classi (cont.)
Prospettiva
Interpretazione
classe = tipo (un tipo è l’interfaccia – o parte di essa - di una o
Specifica
più classi “fisiche”, una classe “fisica” può implementare più
tipi)
associazione = responsabilità (indipendenti dalla struttura dati)
ovvero, per ogni relazione R fra due classi C1 e C2 con
navigabilità C1C2, esistenza di un’interfaccia (implicita, che,
a livello implementativo può essere realizzata in vario modo) che
 dato un elemento di C1, determina tutti gli elementi di C2 che
partecipano a R
 effettua l’aggiornamento della relazione
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
16
Prospettive e diagrammi delle classi (cont.)
Prospettiva
Interpretazione
attributo = responsabilità: esiste un’interfaccia (implicita) che
Specifica
(cont.)
 consente di impostare il valore dell’attributo di un oggetto
 restituisce il valore dell’attributo
operazione = metodo pubblico
generalizzazione = creazione di sottotipi (o ereditarietà di
interfacce): l’interfaccia del sottotipo deve includere tutti gli
elementi dell’interfaccia del supertipo (si dice che deve essere
conforme all’interfaccia del supertipo);
deve essere possibile sostituire un’istanza della sottoclasse
all’interno di qualsiasi pezzo di codice che preveda l’esistenza di
un’istanza della superclasse e tutto deve continuare a funzionare
N.B. la creazione di sottoclassi “fisiche” è solo uno dei modi per
implementare la creazione di sottotipi, un altro è la delega
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
17
Prospettive e diagrammi delle classi (cont.)
Prospettiva
Interpretazione
Implementazione classe = classe “fisica”
associazione R (C1C2)= dato un qualsiasi oggetto di C1
esistono specifici meccanismi di collegamento verso gli
oggetti corrispondenti di C2
la navigabilità può essere diversa da quella di specifica
attributo = campo
generalizzazione: la sottoclasse eredita tutti i metodi e i campi
della superclasse e può ridefinirne le funzioni (eredità di
implementazione)
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
18
Dipendenza
Un elemento (detto client) di un diagramma (di qualsiasi tipo) dipende da un
altro (detto supplier, cioè fornitore) se la modifica della definizione del secondo
può causare un cambiamento del primo
Una classe C1 dipende da un classe C2 se




invoca operazioni di C2 (anche solo un costruttore), e/o
un suo campo è di tipo C2, e/o
un parametro di una sua operazione è di tipo C2, e/o
accede ai campi di C2
Man mano che il sistema cresce, il problema del controllo delle dipendenze
aumenta
Specificare le dipendenze rende espliciti gli effetti a catena del cambiamento di
un elemento  il sistema è più facilmente modificabile
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
19
Concetti essenziali (cont.)
Elementi
Sintassi
Dipendenza Freccia con linea
tratteggiata e punta
biforcuta
Vincolo
Semantica
La modifica della classe destinazione
(fornitore) può causare un cambiamento
della classe sorgente (client)
Può legare pure una classe e un
interface (o una classe astratta), dove se
l’interface (o la classe astratta) dovesse
cambiare, anche la classe potrebbe
cambiare
Descrizione in linguaggio OCL (Object Constraint Language) fa
naturale racchiusa fra
parte di UML ed è basato sul calcolo
parentesi graffe, oppure dei predicati
descrizione in OCL
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
20
Dipendenza (cont.)
In generale non è una relazione transitiva (ad es. se C1 dipende da C2 che
dipende da C3, la relazione non è transitiva se il cambiamento di C2 –
conseguente a un qualsiasi cambiamento di C3 – riguarda solo il corpo delle
operazioni di C2)
Molte relazioni UML implicano una dipendenza, ad es.
 in un’associazione navigabile C1C2, C1 dipende da C2
 una sottoclasse dipende dalla superclasse (ma non viceversa)
Dato il codice di un sistema, le dipendenze in esso contenute sono rilevabili
automaticamente da uno strumento CASE
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
21
Dipendenza e progettazione
client
fornitore
Classe A
Finestra
-- classe di
-- presentazione
Impiegato
-- classe di dominio
Classe B
dipendenza
Regole di progettazione
Separare presentazione (cioè le classi relative all’interfaccia) dalla logica del
dominio (cioè le classi che incarnano il comportamento fondamentale del
sistema), con la prima dipendente dalla seconda ma non viceversa
Minimizzare le dipendenze
Evitare i cicli di dipendenze, possibilmente fra classi dello stesso package e
assolutamente fra classi di package diversi
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
22
Concetti avanzati
Elementi
Sintassi
Parola
Parola racchiusa fra
chiave
virgolette uncinate
Es. «interface»
Semantica
Rappresenta un costrutto creato dall’utente
perché non compreso in UML ma è simile a
un altro che vi è compreso
Parola chiave  stereotipo
Stereotipo = meccanismo di estensione di UML che agisce sul metamodello
Profilo = estensione di una parte di UML ottenuta per mezzo di un gruppo
coerente di stereotipi, adattando così il linguaggio a un particolare dominio (ad
es. la modellazione di business)
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
23
Concetti avanzati (cont.)
Elementi
Operazione e
attributo statici
Sintassi
Semantica
Come operazione e
Metodi e attributi con campo
attributo d’istanza ma d’azione di classe (anziché d’istanza)
sottolineati
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
24
Concetti avanzati (cont.)
Elementi
Sintassi
Aggregazione Freccia che termina sulla classe
“parte” con una punta biforcuta;
all’altra estremità si diparte dalla
classe “tutto” con un rombo
vuoto; su entrambe le estremità
è obbligatoria la molteplicità
Composizione Come nell’aggregazione ma il
rombo è pieno
La molteplicità sul lato della
classe composta è
necessariamente 0..1 oppure 1
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
Generica relazione “parte-di”
(o HAS-A), difficilmente
distinguibile dall’associazione
Inclusa in UML senza
definirne la semantica 
persone diverse la usano con
significati diversi
 Varietà più forte
dell’aggregazione: l’oggetto
componente può appartenere a
un solo oggetto composto
(regola di non condivisione)
 la cancellazione dell’oggetto
composto si propaga a tutti gli
oggetti componenti
25
Aggregazione e composizione
Poligono
1..*
Aggregazione
Vincolo
Composizione
1
1
Riempimento
{ordered} 3..*
Punto
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
colore
tessitura
26
Concetti avanzati (cont.)
Elementi
Sintassi
Proprietà Il nome
derivata
dell’associazione
o dell’attributo è
preceduto da una
barra (/)
Semantica
 È un attributo/associazione rappresentato
esplicitamente anche se può essere derivato a
partire da altri attributi/associazioni
 dal punto di vista concettuale, indica un
vincolo tra valori e può essere usato per ricordarsi
di chiedere conferma agli esperti circa una
presunta derivabilità
 dal punto di vista della specifica, indica un
vincolo tra valori (non cosa viene direttamente
memorizzato e cosa viene derivato)
 dal punto di vista implementativo indica i
campi usati come cache per motivi di efficienza
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
27
Concetti avanzati (cont.)
Periodo di tempo
inizio: Data
fine: Data
/durata: Quantità
daInizioAnno()
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Attributo derivato
Operazione di classe
28
Concetti avanzati (cont.)
Elementi
Classe e
operazione
astratti
Sintassi
Nome in corsivo +
eventuale vincolo
Semantica
Operazione astratta = operazione
priva di implementazione
{abstract}
Classe astratta = classe non
istanziabile direttamente
Interface
Uso della parola chiave Classe priva di implementazione
«interface» entro la
scatola della classe
Realizzazione
Freccia con linea
 Relazione fra una classe (concreta
(o
tratteggiata e punta
o astratta) che implementa
implementazione) vuota diretta dalla
un’interface e l’interface stessa
classe all’interface
 a livello di specifica, realizzazione
e subtyping sono indistinguibili
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
29
Classi astratte e interface
Dipendenza
(richiede la
conoscenza
dell’interface)
{abstract}
InputStream
Editor
testuale
Finestra
{abstract}
inPrimoPiano()
sulloSfondo()
Finestra Windows
inPrimoPiano()
sulloSfondo()
«interface»
DataInput
Generalizzazione
DataInputStream
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Realizzazione
(fornisce
un’implementazione
all’interface)
30
Interface: rappresentazione compatta
implementazione
List
Ordine
ElementiDellaLinea [*]
ListaConcreta
dipendenza
Collection
interface
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
31
Concetti avanzati (cont.)
Elementi
Sintassi
Associazione Dal riquadro della
qualificata
classe sorgente
fuoriesce un riquadro
più piccolo,
contenente il nome
del qualificatore, da
cui si diparte la linea
continua che
rappresenta
l’associazione;
tale linea termina con
una punta che indica
la navigabilità
Semantica
A ogni istanza della classe sorgente
corrispondono gli elementi di un array
associativo/tabella hash/mappa/dizionario
indicizzati dal valore di una chiave (il
qualificatore)
La molteplicità dell’associazione
qualificata va considerata nel contesto del
qualificatore (ovvero indica quante istanze
della classe destinazione corrispondono a
un singolo valore/istanza del qualificatore)
Nella modellazione concettuale rappresenta
un vincolo
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
32
Associazione qualificata
0..1
Ordine
Prodotto
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
LineaDOrdine
Quantita: Numero
33
Classificazione
Classificazione = relazione tra un oggetto e il suo tipo; può essere
 singola: un oggetto appartiene a un solo tipo
 multipla: un oggetto può essere descritto da più tipi
Classificazione multipla  ereditarietà multipla
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
34
Concetti avanzati (cont.)
Elementi
Sintassi
Classificazione  Come la generalizzazione, ma etichettata
multipla
con il nome di un insieme di generalizzazione
(subtyping)
(discriminante), che indica la base della
classificazione;
 il discriminante è accompagnato dal vincolo
{complete} se ogni istanza della superclasse
deve essere anche un’istanza di uno dei
sottotipi del gruppo così contraddistinto;
 ogni combinazione fra sottotipi aventi
discriminante distinto deve essere legale;
 tutti i sottotipi aventi lo stesso discriminante
(gruppo di sottotipi) devono essere disgiunti
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
 Associa a una
classe (la
superclasse) più
sottotipi
ortogonali (le
sottoclassi)
 utile a livello
di modellazione
concettuale
35
Concetti avanzati (cont.)
Elementi
Sintassi
Classificazione Come la classificazione multipla
dinamica
ma l’insieme di generalizzazione
è accompagnato dalla parola
chiave «dynamic»
Semantica
 Consente agli oggetti di
cambiare tipo all’interno di
una struttura di sottotipi
 utile a livello di
modellazione concettuale
Suggerimento: usare sempre una classificazione singola e statica (che
corrisponde all’uso di un singolo anonimo insieme di generalizzazione)
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
36
Classificazione
Insieme di
generalizzazione
(discriminante)
Vincolo
Femmina
sesso
{complete}
Programmatore
impiego
«dynamic»
Responsabile
di progetto
Persona
Maschio
contratto
«dynamic»
Dipendente
Collaboratore
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Commerciale
Classificazione
dinamica
37
Concetti avanzati (cont.)
Elementi
Sintassi
Classe di
Classe collegata a una
associazione linea di associazione
mediante una linea
tratteggiata
Classe
Classe con un riquadro
parametrica tratteggiato sull’angolo
(o template) superiore destro,
contenente i parametri
(tipi di dati) della classe,
che possono essere più
d’uno
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
Aggiunge un vincolo extra: ci può
essere solo un’istanza della classe di
associazione tra ogni coppia di oggetti
associati
 Usata per lo più per definire
collezioni
 Raramente utile in fase di
modellazione concettuale; da usare in
fase di specifica e implementazione solo
se effettivamente supportata dal
linguaggio di programmazione (è
inclusa con il nome di classe generica
in Java e C#)
38
Classe di associazione
Associazione
derivata
Azienda
0..1
1
appartiene
/impiegato
1..*
Datore di
lavoro
1..*
Dipartimento
0..1
1..*
Persona
Impiego
Una persona può avere un
singolo impiego nell’ambito
del dipartimento in cui lavora
descrizione
dataAssunzione
salario
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Classe di
associazione
39
Promozione di una classe di associazione
Dipartimento
0..*
1..*
Persona
Impiego
Una persona può avere un
singolo impiego nell’ambito
di ciascun dipartimento
descrizione
dataAssunzione
salario
Ma il significato è diverso rispetto a quello del diagramma sottostante, usato
soprattutto per rappresentare relazioni temporali (storiche)
Impiego
Dipartimento
1
1..*
descrizione
dataAssunzione
salario
0..*
Persona
1
Una persona può avere più
impieghi nell’ambito dello
stesso dipartimento
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
40
Concetti avanzati (cont.)
Elementi
Sintassi
Derivazione  Dalla classe derivata si diparte una
freccia di generalizzazione diretta
alla classe template; la freccia è
affiancata dalla parola chiave
«bind» seguita dall’elenco dei nomi
dei tipi usati come parametri fra
parentesi angolari (<>), ciascuno
preceduto da nome_parametro ::
Es. <T::Dipendente>, oppure
 La classe derivata contiene il nome
della classe template, la parola
chiave «bind» seguita dall’elenco
dei nomi dei tipi usati, nello stesso
formato di cui al punto precedente
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
Una classe derivata
rappresenta un uso
particolare della classe
parametrica,
corrispondente a una
specifica configurazione
dei valori dei parametri
La classe derivata non è
una sottoclasse: infatti non
è lecito aggiungerle
caratteristiche rispetto a
quelle del template
41
Classi parametriche (template)
List
Parametro
Item
Classe
parametrica
+ insert(in i: Item)
+ first(): Item
+ next(): Item
«bind» <Item::Integer>
ListOfInt
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Elemento
legato
42
Diagramma degli oggetti (o delle istanze)
 È la fotografia degli oggetti che compongono un sistema sw in un dato
momento
 È utile quando le connessioni fra oggetti sono complicate
Elementi
Oggetto
Sintassi
Scatola suddivisa in due parti, entrambe dal
contenuto opzionale, la prima contenente
nome-istanza : nome-classe (può comparire o
solo nome-istanza o solo : nome-classe), la
seconda zero, uno o più nome-attributo =
“valore” (l’elenco degli attributi non deve
essere necessariamente esaustivo)
Collegamento Linea continua fra due oggetti, eventualmente
etichettata con nome-associazione
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
Semantica
Istanza di una
classe
Istanza di
relazione fra due
classi
43
Diagramma degli oggetti (cont.)
Gruppo
*
luogo
0..1 padre
Persona
:Organizzazione
luogo = “Milano”
Organizzazione
padre
:Organizzazione
:Organizzazione
luogo = “Roma”
luogo = “Genova”
:Persona
:Persona
luogo = “Roma”
luogo = “Bologna”
Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi
44