Principi di Progettazione del Software a.a. 2017-2018 - UML: approfondimenti sui diagrammi delle classi e di sequenza. Diagrammi di package e di ...
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Principi di Progettazione del Software
a.a. 2017-2018
UML: approfondimenti sui diagrammi delle classi e di
sequenza. Diagrammi di package e di deployment
Prof. Luca Mainetti
Università del SalentoObiettivi della lezione
■ Approfondire alcuni concetti relativi ai diagrammi delle
classi e ai diagrammi di sequenza
■ Introdurre i diagrammi dei package e di deployment
■ Comprendere come utilizzare i diagrammi sopra elencati
per progettare/documentare l’architettura software delle
applicazioni di interesse per il corso di Principi di
Progettazione del Software
Approfondimenti diagrammi UML 2 Luca MainettiDiagramma delle classi
■ E’ la tipologia di diagramma più ricorrente (e forse più utile)
di UML
■ Un diagramma delle classi può essere utilizzato per
modellare concetti oppure per modellare software
■ Nel secondo caso, descrive il tipo degli oggetti (classi) che
fanno parte di un sistema software e le relazioni che li
legano
■ Per ogni classe, il diagramma descrive le corrispondenti
caratteristiche (feature), cioè le proprietà e le operazioni
che la compongono
Approfondimenti diagrammi UML 3 Luca MainettiUn esempio di diagramma delle classi
Ordine
-data: Data [0..1] Cliente
-prepagato: Boolean [1]
-nome [1]
-numero: String [1]
-indirizzo [0..1]
-prezzo: Denaro * 1 +getiLivelloCredito() : String
+spedisci()
+chiudi()
1
{if Ordine.cliente.getLivelloCredito() == "basso"
then Ordine.prepagato = true} AziendaCliente ClientePrivato
-nomeContatto -numeroCartaCredito
{ordered} * -elementiLinea -livelloCredito
-limiteCredito
LineaOrdine +contoMensile(in c : Integer)
+sollecito()
-quantita: integer
-prezzo: Denaro
*
{getLivelloCredito() == "basso"}
*
1 0..1 -rappresentante
Prodotto Impiegato
Approfondimenti diagrammi UML 4 Luca MainettiProprietà
■ Le proprietà di una classe ne definiscono la struttura
■ In prima approssimazione corrispondono ai campi della
classe
■ Le proprietà possono essere rappresentate con due
notazioni differenti
– Attributi
• Tipicamente utilizzati per rappresentare dati semplici
– Associazioni
• Tipicamente utilizzati per rappresentare dati complessi (altre classi)
Approfondimenti diagrammi UML 5 Luca MainettiAttributi
■ Sintassi completa
– visibilità nome: tipo molteplicità = default
{stringa-di-proprietà}
■ Esempio
– - titolo: String [1] = “UML distilled” {readOnly}
■ Elementi
– visibilità: (-) private, (#) protected, (+) public
– nome: nome dell’attributo
– tipo: tipo di dato di un campo di programmazione
– molteplicità: numero di valori ammessi per le istanze
– default: valore di default in un oggetto appena creato
– {stringa-di-proprietà}: alcune caratteristiche aggiuntive
Approfondimenti diagrammi UML 6 Luca MainettiAssociazioni
■ Un’associazione è una linea
continua che collega due classi Ordine
■ E’ orientata dalla classe -data: Data [0..1]
sorgente a quella destinazione -prepagato: Boolean [1]
■ La classe destinazione -elementiLinea: LineaOrdine [*] {ordered}
corrisponde al tipo della
proprietà
■ La rappresentazione con
associazioni descrive in modo
più intuitivo l’architettura Data
-data
Ordine
-prepagato
Boolean
0..1 * 1
■ Dal punto di vista implementativo 1
la rappresentazione con * -elementiLinea {ordered}
associazioni è equivalente alla
LineaOrdine
rappresentazione con attributi
Approfondimenti diagrammi UML 7 Luca MainettiMolteplicità
■ La molteplicità indica quanti oggetti possono entrare a far parte di una
proprietà (attributo o associazione)
■ Sintassi
– [min..max]
■ Esempi
– Opzionale: [0]
– Obbligatorio: [1..1], [1]
– Singolo: [0..1]
– Multiplo: [0..*], [1..*], [*]
■ Se una proprietà ha più valori si possono specificare proprietà
aggiuntive come {ordered}, {unordered}
■ La molteplicità di default di un attributo è [1]
Approfondimenti diagrammi UML 8 Luca MainettiProprietà e codice Java
■ Non vi è una diretta public class LineaOrdine …
corrispondenza tra UML e private int quantita;
codice, ma una analogia private Prodotto prodotto;
public int getQuantita(){
■ Ad esempio, le proprietà
return quantita;
possono essere implementate
}
come campi privati (a) o come
public int setQuantita(int q){
operazioni (b)
this.quantita = q;
}
public class LineaOrdine …
public Money getPrezzo(){
private int quantita; return prodotto.
private Denaro prezzo; getPrezzo().
multiply(quantita);
private Ordine ordine; }
private Prodotto prodotto;
(a) (b)
Approfondimenti diagrammi UML 9 Luca MainettiOperazioni
■ Sintassi completa
– visibilità nome (lista-parametri): tipo-di-ritorno
{stringa-di-proprietà}
■ Esempio
– + saldo (data: Data): Denaro
■ Elementi
– visibilità: (-) private, (#) protected, (+) public
– nome: nome dell’operazione
– lista-parametri: direzione nome: tipo = default
• nome, tipo, valore di default sono analoghi a quelli degli attributi
• direzione: in, out, inout
– tipo-di-ritorno: è il tipo del valore restituito
– {stringa-di-proprietà}: alcune caratteristiche aggiuntive
Approfondimenti diagrammi UML 10 Luca MainettiGeneralizzazione
■ La generalizzazione modella il concetto di supertipo/sottotipo
– Ad esempio: Cliente/AziendaCliente
– AziendaCliente è un sottotipo di Cliente se tutte le istanze della prima classe
sono anche istanze della seconda
■ Dal punto di vista software
– La generalizzazione modella l’ereditarietà per molti linguaggi a oggetti
– Un concetto di base per l’ereditarietà è il principio di sostituibilità di
Liskov: dovrebbe essere sempre possibile sostituire AziendaCliente in tutti i
punti in cui il codice richiede Cliente e tutto dovrebbe continuare a
funzionare
– Per ottenere sottoclassi sostituibili è bene fare riferimento al concetto di
ereditarietà di interfaccia oppure a design patterns piuttosto che
all’ereditarietà di classe (Gamma, Helm, Johnson, Vlissides — Design
patterns — Addison-Wesley 2002)
Approfondimenti diagrammi UML 11 Luca MainettiDipendenza
■ La classe A (client) dipende dalla
classe B (supplier) se ogni modifica UI Prodotto
a B può implicare una modifica ad A
– A chiama metodi di B
– A usa B come tipo di un suo attributo
– A usa B come tipo in una sua
operazione
■ E’ importante minimizzare le
dipendenze
Prodotto
■ E’ fondamentale evitare dipendenze
cicliche
■ Molte relazioni UML implicano una
dipendenza
– Un’associazione navigabile (es:
Ordine dipende da Cliente)
– Una generalizzazione (es:
AziendaCliente dipende da Cliente) Gateway dei dati Gateway dei dati
Offerte Prodotto
Approfondimenti diagrammi UML 12 Luca MainettiTipologie di dipendenze UML
La sorgente invoca un’operazione della destinazione
La sorgente crea un’istanza della destinazione
La sorgente è derivata dalla destinazione
La sorgente è un’istanza della destinazione. Poiché la sorgente è una
classe, la destinazione deve essere una meta-classe
La destinazione permette alla sorgente di accedere ai suoi campi privati
La sorgente è un’implementazione di un’interfaccia della destinazione
Raffinamento tra livelli semantici, ad esempio tra analisi e progettazione
La sorgente è sostituibile alla destinazione
Usata per tenere traccia di cose come i requisiti
La sorgente richiede la destinazione per la sua implementazione
Approfondimenti diagrammi UML 13 Luca MainettiVincoli
■ Quando si definiscono diagrammi delle classi, di fatto si
definiscono dei vincoli
■ Ad esempio, un Ordine può essere creato solamente da un
singolo Cliente
■ I costrutti UML come attributi, associazioni, generalizzazioni
permettono di catturare i vincoli più importanti
■ Altri vincoli possono essere espressi in vari modi (tra
parentesi graffe e all’interno di note)
– In linguaggio naturale
– In qualche pseudo linguaggio
– In OCL (Object Constraint Language), che è basato sul calcolo dei
predicati
Approfondimenti diagrammi UML 14 Luca MainettiCome usare i diagrammi delle classi
■ Stabilire il livello di modellazione
– Concettuale (modellazione di concetti)
– Logica (modellazione dei software)
■ Stabilire l’interpretazione da dare alle classi UML
– Classi di analisi (modello nello spazio dei requisiti)
– Classi del software (modello nello spazio della soluzione)
■ Procedimento
– Non utilizzare subito tutti i costrutti disponibili, ma concentrarsi in prima
istanza su classi, associazioni, attributi, generalizzazioni, dipendenze,
vincoli
– Fare diagrammi delle classi solamente per le cose rilevanti
– Non concentrarsi solamente sulla struttura, ma sviluppare in parallelo
diagrammi delle classi e diagrammi comportamentali (diagrammi di
sequenza)
Approfondimenti diagrammi UML 15 Luca MainettiProfili
■ Un profilo è una personalizzazione del meta-modello UML
■ E’ conveniente definire dei profili quando è rilevante
introdurre concetti specifici di alcuni domini
■ Tecnicamente un profilo UML è
– Un insieme di stereotipi
– Un insieme di vincoli
– Un insieme di tagged value (coppia attributo valore)
■ Tipicamente i profili vengono utilizzati per creare nuovi
linguaggi a partire da UML
– La WAE (Web Application Extension) è una personalizzazione di
UML per la progettazione di applicazioni web
Approfondimenti diagrammi UML 16 Luca MainettiVisualizzare le responsabilità delle classi
Vista Modello
-- visualizza i dati -- gestisce la logica
del modello del dominio e lo stato
Controllore
-- gestisce l'interazione
col sistema
Approfondimenti diagrammi UML 17 Luca MainettiAggregazione e composizione
■ E’ importante comprendere la
differenza tra aggregazione e
composizione
-membri
■ Nella composizione vale la regola Club Persona
della non condivisione * *
■ Benché una classe possa essere
componente di molte altre classi,
ogni sua istanza può essere
componente di un solo oggetto
■ Inoltre nella composizione, se il tutto
viene eliminato, anche i componenti
{ordered} 1 1
devono essere eliminati Poligono Punto Cerchio
1 3..* -centro
– Ad esempio, se si cancella un
poligono, anche tutti i suoi punti
devono essere eliminati
Approfondimenti diagrammi UML 18 Luca MainettiProprietà derivate
■ Sono calcolate a partire da altri
valori
■ La sintassi prevede di anteporre
al nome delle proprietà derivate
il simbolo “/”
PeriodoDiTempo
■ Con un vincolo possiamo
-inizio: Data
descrivere la semantica di -fine: Data {durata = fine – inizio}
derivazione -/durata: Integer
Approfondimenti diagrammi UML 19 Luca MainettiInterfacce e classi astratte
■ Una classe astratta è una classe «interfaccia»
Collection
che non può essere istanziata. Solo +equals()
le sue sottoclassi concrete lo +add()
possono essere
■ Una classe astratta ha operazioni
pubbliche astratte, cioè operazioni
con la sola dichiarazione e senza
implementazione AstractList
Ordine «interfaccia»
■ Una classe astratta è indicata con il -items [*] List
+equals()
nome in corsivo o con l’etichetta +get() +get()
{abstract} +add()
■ Un’interfaccia è una classe priva di
implementazione, cioè tutte le sue
caratteristiche sono astratte
ArrayList
■ Le dipendenze dovrebbero sempre Dipendenza Implementazione
sussistere tra classe e interfacce e (richiede (fornisce
+get()
l’interfaccia) l’interfaccia)
non direttamente tra classi +add()
Approfondimenti diagrammi UML 20 Luca MainettiInterfacce e classi astratte (cont)
■ Le classi possono richiedere
oppure fornire interfacce Ordine List
■ Una classe richiede -items [*] ArrayList
un’interfaccia se ha bisogno di
una sua istanza per funzionare Collection
■ Una classe implementa
un’interfaccia se è sostituibile ad
essa
■ In UML2 ci sono due notazioni Ordine List
alternative come mostra -items [*] ArrayList
l’esempio a fianco
Collection
Approfondimenti diagrammi UML 21 Luca MainettiPrincipi di Progettazione del Software
a.a. 2016-2017
Diagrammi di sequenza, package, deployment
Prof. Luca Mainetti
Università del SalentoDiagramma di sequenza
■ Un diagramma di sequenza rappresenta il comportamento
di un insieme di oggetti coinvolti in un singolo caso d’uso
■ Sono da utilizzare principalmente per rappresentare
decisioni già prese sull’implementazione di singoli casi
d’uso
■ Non spiegano i dettagli degli algoritmi (meglio per questo
utilizzare i diagrammi di attività)
■ Se invece si è in fase di scelta e si vogliono vagliare
differenti possibilità d’interazione, è meglio utilizzare le
schede CRC
■ Prendiamo ad esempio lo scenario di calcolo del prezzo
totale di un ordine commerciale
Approfondimenti diagrammi UML 23 Luca MainettiImplementazione scenario calcolo prezzo ordine:
controllo centralizzato
unOrdine unaLineaOrdine unProdotto unCliente
Utente
calcolaPrezzo
getQuantita
getProdotto
unProdotto
getDettagliPrezzo
calcolaPrezzoBase
calcolaSconti
getInfoSconto
Approfondimenti diagrammi UML 24 Luca MainettiImplementazione scenario calcolo prezzo ordine:
controllo distribuito
unOrdine unaLineaOrdine unProdotto unCliente
Utente
calcolaPrezzo
calcolaPrezzo
getPrezzo(quantita)
getValoreSconto(unOrdine)
getValoreBase
valoreScontato
Approfondimenti diagrammi UML 25 Luca MainettiCreare e distruggere partecipanti
unHandler
interrogaDatabase
new
unaQuery
new
unComandoDB
esegui
risultati
chiudi
risultati
Approfondimenti diagrammi UML 26 Luca MainettiCicli e condizioni
unOrdine unaLineaOrdine unProdotto
Utente
calcolaPrezzo
loop getQuantita
loop
getProdotto
alt unProdotto
opt getDettagliPrezzo
Frame d’interazione
calcolaPrezzoBase
Approfondimenti diagrammi UML 27 Luca MainettiMessaggi sincroni e asincroni
unOggetto unAltroOggetto
Messaggio sincrono
Messaggio asincrono
Approfondimenti diagrammi UML 28 Luca MainettiDiagramma di comunicazione
■ E’ un particolare tipo di diagramma
d’interazione che mette in enfasi lo
scambio di dati tra gli oggetti
partecipanti
1: calcolaPrezzo
1.4: calcolaPrezzoBase
■ In UML 1 era chiamato diagramma di 1.5: calcolaSconti
1.5.1: getInfoSconti
collaborazione unOrdine unCliente
■ E’ equivalente a un diagramma di
sequenza
■ L’ordine temporale viene specificato
1.3: getDettagliPrezzo
dalla numerazione dei messaggi 1.1: getQuantita
1.2: getProdotto
■ E’ più comodo del diagramma di
sequenza durante le riunioni informali
(da disegnare alla lavagna)
■ Il diagramma di comunicazione a lato è
unaLineaOrdine unProdotto
equivalente al diagramma di sequenza
presentato precedentemente per la
specifica dello scenario di calcolo del
prezzo di un ordine, con controllo
centralizzato
Approfondimenti diagrammi UML 29 Luca MainettiDiagramma di package
■ Un package è un contenitore di
elementi UML
util
■ Tipicamente usiamo i package per
illustrare sottosistemi
■ In tal senso un package contiene util
sotto-package e classi
Data
■ Un package definisce un
namespace e rappresenta i
package Java o i namespace C++ e java
C# util
■ Una classe ha un solo package di Data
appartenenza e deve avere un
nome univoco in tale package
■ Un package è denotato con un box java::util::Data
con linguetta
Approfondimenti diagrammi UML 30 Luca MainettiDiagramma di package (cont.)
■ Le classi di un package possono essere pubbliche o private
■ Una classe pubblica fa parte dell’interfaccia del package
■ Può essere usata dalle classi al di fuori del package
■ Come si fa a stabilire quali classi devono appartenere al
medesimo package?
– Classi coese
– Classi che condividono le medesime cause di cambiamento
– Classi che dovrebbero essere riusate insieme
Approfondimenti diagrammi UML 31 Luca MainettiPackage e dipendenze
■ Soprattutto se il sistema è
complesso, è molto utile un Presentazione
conti correnti
Presentazione
fondi
diagramma dei package che
documenta i package del
sistema e le dipendenze tra di Interfaccia
essi utente
■ Tali dipendenze sono desunte
dalle dipendenze tra le Dominio conti
correnti
Dominio fondi
corrispettive classi
■ Un package con tante
dipendenze entranti deve
necessariamente avere Mapper dati
conti correnti
Mapper dati
fondi
un’interfaccia stabile
■ Le dipendenze non sono
transitive (fortunatamente) Database
Approfondimenti diagrammi UML 32 Luca MainettiImplementare package
■ Può essere utile definire
interfaccia e implementazione di
una classe in package separati
Applicazione
■ Nell’esempio accanto la
realizzazione indica che
Gateway del database definisce
un’interfaccia implementata dagli Gateway del
database
altri gateway
Gateway
Gateway Oracle Gateway MySQL
SQLServer
Approfondimenti diagrammi UML 33 Luca MainettiDiagramma di deployment
■ I diagrammi di deployment
specificano il rilascio del sistema
a livello fisico Client con Client dedicato
browser {OS = Windows}
■ Il sistema è fatto di nodi, cioè di
elementi che possono eseguire
http DCOM
software
■ Un dispositivo hardware (ad Web server
{OS = Linux}
esempio un PC) è un nodo {web server = Apache}
Application.war
■ Un ambiente software (ad
esempio un sistema operativo) è Java RMI
un nodo
■ I nodi contengono artefatti e Application server
{OS = Linux}
{EJB container= JBoss}
componenti (file eseguibili, file di {DBMS = Oracle}
dati, configurazioni, documenti
HTML, XML, ecc.)
Approfondimenti diagrammi UML 34 Luca MainettiPuoi anche leggere
