Modellazione - Dipartimento di Ingegneria dell`Informazione

Transcript

5
UML
Analisi, Modellazione e
altro
UML (2) - 2010/11
G. Bucci
1
Contenuto
Analisi e Modellazione
z Il pattern Singleton (en passant)
z Stereotipi per l’analisi
z Il pattern MVC
z
z
z
Il pattern Observer
Una metodologia di Analisi-ProgettoSviluppo
z
(Anticipo ulteriori concetti UML)
UML (2) - 2010/11
G. Bucci
2
Modellazione/Diagr Classi
z
Diagramma delle classi: è il principale
strumento di modellazione
z
z
E’ la rappresentazione strutturale (statica) del
sistema
Tre prospettive di uso:
z
Livello concettuale: relazioni tra le classi del
modello
z
Livello di specifica: responsabilità delle classi
(interfacce)
z
Livello di implementazione: classi di supporto,
trasformazione, dettagli realizzativi (puntatori,
liste, etc..)
UML (2) - 2010/11
G. Bucci
3
Prospettive
z
Analisi, mod concettuale
Mod. dominio
button
Client
Applicazione
z
Responsabilità
button
Client
+push()
BWindows
z
Blinux
+push()
Progetto, mod implementativo
Client
+push()
BLinux
+push()
<<interface>>
Window
<<interface>>
AbFactory
WLinux
+createWindow()
+createButton()
WWindows
<<interface>>
Button
UML (2) - 2010/11
WinFactory
LinuxFactory
+createWindow()
+createButton()
+createWindow()
+createButton()
G. Bucci
Blinux
BWindows
4
Modellazione OO
1.
Costruzione del modello di dominio
z
z
z
Si identificano le entità del dominio
applicativo e si modellano con
oggetti/classi
Si identificano le relazioni di associazione
Possibilmente di identificano gerarchie di
classi, specializzando, ridefinendo il
comportamento nelle classi subordinate
UML (2) - 2010/11
G. Bucci
5
Modello di dominio
z
In esso entrano solo le entità che fanno parte
del dominio applicativo (dette classi di analisi,
ovvero classi entity)
z Esempio:
z
CC, Fido, Cliente, Mutuo
Non entrano gli oggetti che rappresentano
soluzioni progettuali/implementative (liste,
puntatori, ecc) o altro (interfacce utente,
oggetti con funzione di controllo)
z Esempio:
UML (2) - 2010/11
StampaListaFidi
G. Bucci
6
Identific. classi/associazioni
z
Classi/Oggetti sono tipicamente espressi da
sostantivi (cliente, mutuo, fido …)
z
Associazioni sono tipicamente espresse da
verbi che esprimono:
z
z
z
Collocazione fisica (contenuto in); azioni (gestisce,
corre, ..); proprietà (possiede, ha);
soddisfacimento di condizioni (sposato a)
Ogni riferimento da una classe a un’altra è
un’associazione
Una associazione deve esprimere una proprietà
strutturale del dominio, non un evento transitorio
UML (2) - 2010/11
G. Bucci
7
Esempi
Evitare di rappresentare soluzioni progettuali (implementative)
Banchetto
Banchetto
UML (2) - 2010/11
Lista
1..*
1..*
Invitato
G. Bucci
Invitato
NO!
SI!
8
Esempi
Una associazione deve esprimere una proprietà
strutturale del dominio, non un evento transitorio
Biblioteca
presta
Biblioteca
Libro
SI!
NO!
UML (2) - 2010/11
contiene
G. Bucci
Libro
prestato
9
Esempi
I nomi delle classi devono riflettere la loro natura
intrinseca, non il ruolo giocato nelle associazioni
Marito
sposa
Moglie
NO!
Uomo
0,1 sposa
marito
0,1
moglie
Donna
SI!
UML (2) - 2010/11
G. Bucci
10
Esempio: Modellazione di un museo
z
z
z
z
z
Un museo si compone di diverse sezioni, ciascuna
comprende un certo numero di sale.
Ogni sezione ha un orario di apertura giornaliero ed è
custodita durante l’orario da un solo custode secondo un
turno settimanale; il turno definisce quale sezione un custode
deve sorvegliare ogni giorno della settimana.
Ciascuna sala comprende diverse opere d’arte: dipinti,
sculture (divise in bassorilievi, altorilievi, statue), arazzi e
ceramiche.
Ogni opera ha un autore, ma ci sono opere di autore
sconosciuto.
Ogni opera appartiene a un periodo storico (Rinascimento,
Medio Evo, Novecento, ..); alcuni autori appartengono a un
movimento artistico (impressionismo, cubismo, futurismo,…)
UML (2) - 2010/11
G. Bucci
11
Esempio (continuazione)
z
Si analizza attentamente il testo alla ricerca
dei sostantivi che identificano le classi e/o i
loro eventuali attributi
z
I verbi come “ha”, “contiene”, “possiede”,..
danno le relazioni strutturali tra le classi
z
I verbi come “gestisce”, “legge” possono
identificare relazioni strutturali oppure
funzionalità
UML (2) - 2010/11
G. Bucci
12
z
z
z
z
z
Un museo si compone di diverse sezioni, ciascuna comprende
un certo numero di sale.
Ogni sezione ha un orario di apertura giornaliero ed è custodita
durante l’orario da un solo custode secondo un turno
settimanale; il turno definisce quale sezione un custode deve
sorvegliare ogni giorno della settimana.
Ciascuna sala comprende diverse opere d’arte: dipinti,
sculture (divise in bassorilievi, altorilievi, statue), arazzi e
ceramiche.
sconosciuto.
Ogni opera appartiene a un periodo storico (Rinascimento,
Medio Evo, Novecento, ..); alcuni autori appartengono a un
movimento artistico (impressionismo, cubismo, futurismo,…)
In grassetto possibili classi e attributi
UML (2) - 2010/11
G. Bucci
13
z
Un museo si compone di diverse sezioni, ciascuna
comprende un certo numero di sale. Ogni sezione
ha un orario di apertura giornaliero…..
z
Sono aggregazioni
Museo
Sezione
-orario
Sala
UML (2) - 2010/11
G. Bucci
14
z
z
Ogni sezione ha un orario di apertura giornaliero ed
è custodita durante l’orario da un solo custode
secondo un turno settimanale; il turno definisce quale
sezione un custode deve sorvegliare ogni giorno
della settimana.
Qui c’è una associazione ternaria: un custode è
associato a una sala ma in base al turno.
L’associazione stessa è una classe che lega sezioni
a custodi in base al giorno della settimana
Sezione
-orario
Custode
*
*
CustoditaDa
-giorno
UML (2) - 2010/11
G. Bucci
15
z
Ciascuna sala comprende diverse opere d’arte:
dipinti, sculture (divise in bassorilievi, altorilievi,
statue), arazzi e ceramiche.
Sala
1
contiene
1..*
Perché non
aggregazione?
Opera
-periodoS torico
Dipinto
Statua
UML (2) - 2010/11
Scultura
A razzo
Bassorilievo
Ceramica
A ltoril.
G. Bucci
16
z
z
sconosciuto.
Ogni opera appartiene a un periodo storico
(Rinascimento, Medio Evo, Novecento, ..); alcuni
autori appartengono a un movimento artistico
(impressionismo, cubismo, futurismo,…)
Sala
Perché
attributi e
non classi?
1
contiene
1..*
Opera
-periodoStorico
UML (2) - 2010/11
Autore
eseguita
1..*
0..*
G. Bucci
+movimentoArtistico
17
Museo
Sezione
Custode
-orario
CustoditaDa
-giorno
Sala
1
contiene
1..*
Opera
-periodoStorico
Dipinto
Statua
UML (2) - 2010/11
Scultura
Bassorilievo
eseguita
1..*
Arazzo
Autore
0..* +movimentoArtistico
Ceramica
Altoril.
G. Bucci
18
Commento
z
Il diagramma precedente rappresenta il
modello del dominio applicativo
z
z
z
z
In pratica è il modello dei dati
Nel campo dell’elaborazione dei dati il modello dei
dati è di norma l’aspetto rilevante
Il nostro esempio somiglia molto a un problema di
basi di dati: è difficile immaginare un caso d’uso
diverso da una interrogazione o un aggiornamento
z Di per sé c’è poca (o nessuna) “logica di
business”
La logica dell’applicazione si costruisce a
parte
UML (2) - 2010/11
G. Bucci
19
..Commento
z
z
Ci vuole un po’ di fantasia a immaginare che
oggetti della classe Opera abbiano un
comportamento (interagiscano con altri
oggetti scambiando messaggi)
In questo caso il modello dei dati serve
essenzialmente a navigare:
z
z
z
Recuperare uno o più dati
Aggiornare uno o più dati
Lo scambio dei messaggi tra oggetti è da
riguardarsi come funzionale alla navigazione
UML (2) - 2010/11
G. Bucci
20
Divagazione
Classi di applicazioni
Prevalente controllo
Automazione
ind.
Monitor/Controllo
Controllo e
manipolaz. dati
Prevalente
manipolaz. Dati
Word
Banche
process.
Modellazione
UML (2) - 2010/11
G. Bucci
Contabilità
21
Applicazioni di controllo
Automazione
ind.
Monitor/Controllo
Controllo e
manipolaz. dati
Prevalente
manipolaz. Dati
Word
Banche
process.
Modellazione
Pochi
Contabilità
dati da manipolare, eventi da tenere sotto controllo
Tempo
reale (anche stretto)
Operatività
(24H ?)
UML (2) - 2010/11
G. Bucci
22
Applicazioni “Enterpise”
Automazione
ind.
Monitor/Controllo
Controllo e
manipolaz. dati
Prevalente
manipolaz. Dati
Word
Banche
process.
Modellazione
Contabilità
Molti
dati da manipolare
Persistenza
Operatività
Real
UML (2) - 2010/11
G. Bucci
(24H)
time (?)
23
Schema Appl. Enterprise
UML (2) - 2010/11
G. Bucci
24
N-tier (AE)
Presentation
Network
Business logic
Dati
Middleware
Middleware
Client
UML (2) - 2010/11
Web server
Appl. servers
G. Bucci
DB server
25
..Commento
z
Pratica consolidata per le applicazioni
enterprise: ORM (object-relational mapping)
Un mondo “morto”
Un mondo “vivo”
UML (2) - 2010/11
G. Bucci
26
.. ..ma perché ?
z
Perché si vuole utilizzare tecnologie OO
L’Applicazione è programmata a oggetti
z La base di dati contiene un numero di dati
potenzialmente molto grande
z Nell’applicazione, in un dato momento,
sono presenti solo gli oggetti che servono
(quelli che corrispondono ai dati che in
quel momento vengono manipolati)
to
n
z Il Mapper ha la funzione di mappare
e
m
go
r
oggetti su tabelle e viceversa.
l l ’a
z
UML (2) - 2010/11
G. Bucci
r
o
T
u
s
o
m
re
e
n
27
Esempio: una bolla di consegna
z
Si immaginano questi attributi
Numero progressivo
z Data di emissione
z Termine di pagamento
z Intestatario
z Un certo numero di righe ciascuna delle
quali descrive un prodotto, la quantità, il
prezzo unitario e il prezzo totale
z Ecc.
z
UML (2) - 2010/11
G. Bucci
28
..bolla (AE)
z
Cosa possiamo chiedere a una bolla?
z
Lettura/modifica di attributi
z Forse qualche specifica operazione:
aggiunta di una Riga
UML (2) - 2010/11
G. Bucci
29
Metodi get e set
z
z
Classi come le precedenti presentano due categorie
di metodi: metodi Getter e metodi Setter, per la
lettura e la modifica degli attributi.
Seguiremo il criterio di avere attributi privati e
leggerli/modificarli attraverso l’interfaccia della classe
z Cfr. Information Hidig – Incapsulamento
z
z
Type getAttributo_i();
Si usa anche il
void setAttributo_i(param); termine
UML (2) - 2010/11
Proprietà in
luogo di attributo
G. Bucci
30
Dove sta la logica applicativa?
z
Nelle applicazione enterprise:
z
Di norma conviene che la logica applicativa
sia realizzata attraverso classi aggiuntive
z Tipicamente classi di controllo che
“comandano” le classi del modello
z Le classi del modello devono presentare
metodi adeguati in modo da collaborare
con le classi di controllo (permettendo la
navigazione nel modello)
UML (2) - 2010/11
G. Bucci
31
…Dove sta la logica applicativa?
z
Nelle applicazioni di controllo
z
Sta nel modello!
z
Gli oggetti del modello rappresentano entità del mondo reale
che effettivamente hanno un comportamento
Timer
Controllore
1
Sensore
SensTemperature
UML (2) - 2010/11
1..*
1..*
SensPressione
Classe attiva
1
Attuatore
Elettrovalvola
G. Bucci
Motore
32
Come procederemo?
z
Studieremo prima il caso delle
applicazioni tipo Enterprise
z
Focalizzando solo l’aspetto della
programmazione OO dell’applicazione
(rimandando la questione della persistenza dei dati)
z
z
Successivamente parleremo di ORM
In un secondo tempo esamineremo
anche il caso di sistemi a prevalente
aspetto di controllo
UML (2) - 2010/11
G. Bucci
33
Torniamo al Museo
z
Aggiungiamo qualche attributo per rendere
l’esempio più realistico
Museo
Sezione
-nome: String
-indirizzo
Sala
-numero: int
-orario
-num: int
1
contiene
1..*
Opera
Autore
eseguita
-id: int
-nome: String
1..*
0..* -nome: String
-descrizione: String
-movimentoArtistico
-periodoStorico
~//altri attributi
Gli altri attributi potrebbero essere
oggetti legati all'opera;
p.es. gli eventuali restauri subiti,
gli expertise, ecc.
UML (2) - 2010/11
G. Bucci
34
L’applicazione
z
Potrebbe richiedere che il sistema mostri tutti
i dati relativi a una data Opera
z
z
z
Occorre prevedere la funzionalità corrispondente.
Stabiliamo che ci sia un oggetto della classe
AnalisiOpera, avente la responsabilità di
mostrare i dati relativi all’opera selezionata tramite
menu
Stabiliamo che AnalisiOpera presenti il metodo
mostraOpera(String), responsabile di
mostrare i dettagli relativi all’opera specificata,
invocato a seguito della scelta da menù
il metodo mostraOpera(String) della classe
AnalisiOpera chiama il metodo
getOpera(String) di Museo
UML (2) - 2010/11
G. Bucci
35
..Esempio
Museo
AnalisiOpera
-nome: String
-indirizzo
+mostraOpera(nome)
+getOpera(nome): Opera
z
Occorre prevedere i metodi adeguati nelle
altre classi per permettere la navigazione
z Arrivare fino a Opera
z Restituire all’applicazione (all’oggetto della classe
AnalisiOpera) il riferimento all’opera cercata
UML (2) - 2010/11
G. Bucci
36
Aggiungiamo le
interfacce (i metodi)
Museo
-nome: String
-indirizzo
-sezioni
Sezione
-numero: int
-orario
-sale
Sala
-num: int
1
contiene
1..* -opere
Opera
-id: int
-nome: String
-periodoStorico
~//altri attributi
eseguita
1..*
Autore
-nome: String
0..* -movimentoArtistico
+getName(): String
UML (2) - 2010/11
G. Bucci
37
Procediamo alla realizzazione
Museo
Realizzate come Collection
( size(), get(index), …)
-nome: String
-indirizzo
-sezioni
Restituisce null se
non si trova l’opera
Sezione
-numero: int
-orario
-sale
Sala
-num: int
1
contiene
UML (2) - 2010/11
G. Bucci
38
Java
Museo
-nome: String
-indirizzo
Opera getOpera(String nome){
Opera o = null;
if (sezioni.isEmpy()){
ahi! ahi! ::::
}
int i=0;
while (o==null && i<sezioni.size()){
o= sezioni.get(i).getOpera(nome);
i++;
}
return o;
}
-sezioni
Sezione
-numero: int
-orario
-sale
Sala
-num: int
1
contiene
UML (2) - 2010/11
G. Bucci
39
..Java
Museo
-nome: String
-indirizzo
-sezioni
Sezione
-numero: int
-orario
Opera o = null;
if (sale.isEmpy()){
che fare??
::
}
int i =0;
while (o==null && i<sale.size()){
o= sale.get(i).getOpera(nome);
i++;
}
return o;
}
-sale
Sala
-num: int
1
contiene
UML (2) - 2010/11
G. Bucci
40
if (opere.isEmpy()){
è possibile ?? ::::
}
int i=0;
while (i<opere.size()){
if (opere.get(i).getName() == nome )
return opere.get(i);
i++;
-sezioni
} Sezione
Sala
return null;
-sale
int
} -numero:
-num: int
-orario
1
contiene
1..* -opere
Opera
-id: int
-nome: String
-periodoStorico
~//altri attributi
eseguita
1..*
Autore
-nome: String
+getName(): String
UML (2) - 2010/11
G. Bucci
41
La navigazione
Museo
AnalisiOpera
+mostraOpera(nome)
-nome: String
-indirizzo
-sezioni
Sezione
-sale
-numero: int
-orario
Sala
-num: int
1
contiene
1..* -opere
Torna il riferimento
all’opera cercata (o null)
Opera
-id: int
-nome: String
-periodoStorico
~//altri attributi
eseguita
1..*
Autore
-nome: String
+getName(): String
UML (2) - 2010/11
G. Bucci
42
..E ora l’applicazione
void mostraOpera(String nome) {
opera = museo.getOpera(nome);
if (opera != null){
descr = opera.getDescrizione();
autore = opera.getAutore();
nomeAutore = autore.getNome();
//ecc.
}
else {
1
// l’opera con quel nome non esiste
contiene
1..* -opere
}
I primi due
metodi devono
essere aggiunti
alla classe
Opera, il terzo
alla classe
Autore.
Opera
-id: int
-nome: String
-periodoStorico
~//altri attributi
UML (2) - 2010/11
G. Bucci
+getName(): String
+getDescrizione()
+getAutore()
eseguita
1..*
Autore
-nome: String
+getNome()
43
Domanda
z
Perché tutto questo traffico?
z
Non si poteva rendere le opere visibili ad
AnalisiOpera, in modo da evitare la lunga
navigazione?
In AnalisiOpera
Opera o = null;
int i= 0;
while (i<opere.size() && o==null){
if (opere.get(i).getNome == nome) o= opere.get(i);
}
UML (2) - 2010/11
G. Bucci
44
Risposta
Certamente sì!
Però….
z
L’applicazione risulterebbe strettamente intrecciata con il modello
di dominio: l’eliminazione/aggiunta di un’opera comporterebbe
l’aggiornamento di tutti gli oggetti che fanno riferimento ad essa:
z Anche dell’oggetto applicazione!
z E di tutte le applicazioni che intendono accedere alle opere !!!
z
Vogliamo che il modello possa espandersi/contrarsi senza alcun
impatto sulle applicazioni
UML (2) - 2010/11
G. Bucci
45
Eventualmente...
z
Motivi di efficienza possono suggerire l’aggiunta di
associazioni non strettamente necessarie
Attenzione:
Non sono la
stessa cosa
z
Mettiamo in Museo il metodo getOpere() che restituisce
all’applicazione la collection opere
UML (2) - 2010/11
G. Bucci
46
Confronto con le Basi dati
z
z
Le tabelle sono visibili dall’applicazione ma solo
come nomi
La gestione è affidata al DBMS; l’accesso è via SQL
Applicazione
D
B
M
S
Vogliamo riportarci a una situazione analoga
Î Museo deve fare da “contenitore” degli oggetti del
modello e provvedere l’interfaccia per accedervi
UML (2) - 2010/11
G. Bucci
47
..Cosa vogliamo
Museo
Applicazione
z
z
La classe Museo provvede l’interfaccia tra il modello
di dominio e l’esterno. Essa costituisce una sorta di
contenitore
La logica dell’applicazione sta all’esterno e si riferisce
al museo per raggiungere gli oggetti del modello
z
Forse parte della logica applicativa poteva anche essere
parzialmente embedded nel Museo (e nelle altre classi del
modello)
UML (2) - 2010/11
G. Bucci
48
..Commenti
z
E’ meglio avere la logica applicativa
esterna o dentro il modello?
z
z
Dipende dal contesto ma la logica esterna
consente un minor accoppiamento e
maggior coesione
Se la logica è esterna, quante classi
applicative conviene avere?
Una sola omnicomprensiva ?
z Una per funzionalità?
z
z
Approfondiremo più avanti questo aspetto
UML (2) - 2010/11
G. Bucci
49
Contenuto
z Il pattern MVC
z
z
z
Il pattern Observer
z
UML (2) - 2010/11
G. Bucci
50
Motivo
z
E’ bene che Museo venga istanziato
una sola volta
z
z
Probabilmente anche AnalisiOpera deve
essere presente in un solo esemplare
Come si fa a garantire che venga
istanziato un solo oggetto di una data
classe?
col Pattern Singleton !!!
UML (2) - 2010/11
G. Bucci
51
Singleton
Garantisce che di una classe non possa
essere istanziato più di un oggetto
Come:
z
¾
¾
Rendere impossible l'uso del costrutto new da
parte del programma utente (nascondere il costruttore)
Fornire un metodo indiretto per ottenere una
istanza (l'unica) della classe.
Ovvero:
z
z
Dichiarare privato il costruttore
Prevedere un metodo pubblico statico (di classe) che:
z
z
UML (2) - 2010/11
istanzia un esemplare se l’esemplare non è già istanziato
restituisce l'oggetto già istanziato nel caso contrario
G. Bucci
52
..Singleton
public class Singleton {
private static Singleton instance = null
private static String nome= "XX"; // prevediamo
un nome
public static Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}
private Singleton() { //costruttore privato !!}
public String getNome(){ //restituisce il nome
return nome;
}
}
UML (2) - 2010/11
G. Bucci
53
.. Singleton
Nel chiamante:
Singleton soloLui;
::::
soloLui = Singleton.getInstance();
Definizione
Il pattern Singleton garantisce che ci sia una sola
istanza di una data classe e fornisce un punto di
accesso globale a tale istanza.
UML (2) - 2010/11
G. Bucci
54
Contenuto
z Il pattern MVC
z
z
z
Il pattern Observer
z
UML (2) - 2010/11
G. Bucci
55
Tre stereotipi per l’analisi
z
Entity: classi di oggetti che rappresentano la
semantica del dominio applicativo
z
Boundary: classi di oggetti che rappresentano
l’interfaccia tra gli attori e il sistema (il modello
applicativo e il resto)
z
Controller: classi di oggetti che determinano il
modo in cui l’applicazione risponde agli input degli
attori:
Robustness diagram di Unified Process
UML (2) - 2010/11
G. Bucci
56
Boundary Control Entity
UML (2) - 2010/11
G. Bucci
57
Estrema sintesi
z
Qualunque sistema è schematizzabile
in questomodo
INTERFACCIA U.
UML (2) - 2010/11
FUNZIONALITA’
G. Bucci
MODELLO DEL DOMINIO
58
..segue
z
Qualunque sistema è composto da
questi ingredienti
Analisi Opera
Calcola Saldo di XX
Cerca Fattura del gg/mm/aa
Calcola Totale Crediti
…..
UML (2) - 2010/11
G. Bucci
Museo
Opera
Conto Corrente
Cliente
Libro
Fattura ……..
59
..ma anche
z
Qualunque sistema è composto da
questi ingredienti
Driver
Dispositivo
UML (2) - 2010/11
Controllore Temperatura Pressione
Temperatura
Controllore Velocità
Altezza
Controllore Frenata
Questo può
essere un vero
modello
matematico
G. Bucci
60
..Un vero modello!
z
Un modello fatto di equazioni!
Sensore di
livello a
Firenze
Interruz.
UML (2) - 2010/11
Driver
Controllore livello
Livello
Modello piena
Calcola livello a 3 ore a
Empoli
G. Bucci
61
Dinamica (semplificata)
UML (2) - 2010/11
G. Bucci
62
Contenuto
z Il pattern MVC
z
z
z
Il pattern Observer
z
UML (2) - 2010/11
G. Bucci
63
MVC Model-View-Controller
Model: Oggetto applicativo (classi entity)
z View:
Presentazione (viste)/lettura
z
ingressi (classi boundary)
z Controller: Determina il comportamento del
modello e della presentazione
(classi control)
Controller
View
Model
UML (2) - 2010/11
G. Bucci
64
Viste differenti
UML (2) - 2010/11
G. Bucci
65
Controller
Comandi cambiam. stato
Definisce il comportamento del modello
zMappa le azioni dell’utente in richieste
di aggiornamento dello stato del modello
zSeleziona la vista per le risposte
z(Un controllore per funzionalità)
z
Selezione vista
Model
Incapsula lo stato dell’applicazione
zSegnala i cambiamenti (di stato) a View
z
Input utente
Rich. stato
Segnalazione
cambiamenti
Invocazione metodi
UML (2) - 2010/11
Eventi
View
Mostra il modello (i dati nel modello)
zRichiede lo stato al modello (aggiornamento)
zTrasmette al controllore gli input dell’utente
zConsente al controllore di selezionare differenti
viste
z
G. Bucci
66
MVC
E’ esso pure un Pattern di
progettazione (di livello molto alto)
z Disaccoppia le tre categorie di oggetti
z
z
z
Evita i grovigli
Tra View e Model c’è un protocollo
publish/subscribe: il modello che subisce un
cambiamento (di stato) informa le viste ad esso
relative; queste hanno la possibilità di aggiornarsi
z
Più viste per uno stesso modello
UML (2) - 2010/11
G. Bucci
67
Dinamica (forma classica)
(Boundary)
UML (2) - 2010/11
(Control)
G. Bucci
(Model)
68
Pattern Observer
Il Modello e la Vista implementano il
pattern publish & subscribe detto anche
observer
z Il pattern assume che l’oggetto (Subject
o Observable) che contiene i dati sia
separato rispetto agli oggetti (Observer)
che presentano i dati
z Gli observer osservano i cambiamenti
nel subject
z
UML (2) - 2010/11
G. Bucci
69
Pattern Observer
UML (2) - 2010/11
G. Bucci
70
Il Pattern Observer
z
Definisce una relazione uno a molti tra
oggetti, in modo che se un oggetto
cambia il suo stato gli oggetti da esso
dipendenti vengono avvisati
automaticamente
UML (2) - 2010/11
G. Bucci
71
Modello UML
UML (2) - 2010/11
G. Bucci
72
Messa in moto
1.
2.
3.
4.
5.
Istanziazione soggetto (concreto)
Istanziazione osservatore (concreto)
Registrazione dell’osservatore sul
soggetto
Passaggio del soggetto all’osservatore
Eventuale ripetizione dei passi 2-4
UML (2) - 2010/11
G. Bucci
73
Dettaglio
UML (2) - 2010/11
G. Bucci
74
Dinamica
UML (2) - 2010/11
G. Bucci
75
Interfaccia osservatore
UML (2) - 2010/11
G. Bucci
76
Sogetto
public abstract class Soggetto {
protected int stato;
protected ArrayList<Osservatore> osservatori;
public void registraOsservatore(Osservatore o) {
osservatori.add(o);
}
public void rimuoviOsservatore(Osservatore o) {
int i = osservatori.indexOf(o);
if (i>=0) osservatori.remove(i);
}
protected void informaOsservatori() {
for (int i=0; i<osservatori.size(); i++){
Osservatore o = osservatori.get(i);
o.aggiorna();
}}
public abstract void setStato(int s);
public abstract int getStato();
}
UML (2) - 2010/11
G. Bucci
77
Sogetto
public abstract class Soggetto {
protected int stato;
protected ArrayList<Osservatore> osservatori;
public void registraOsservatore(Osservatore o) {
osservatori.add(o);
}
public void rimuoviOsservatore(Osservatore o) {
int i = osservatori.indexOf(o);
if (i>=0) osservatori.remove(i);
}
protected void informaOsservatori() {
for (int i=0; i<osservatori.size(); i++){
Osservatore o = osservatori.get(i);
o.aggiorna();
}}
public abstract void setStato(int s);
public abstract int getStato();
}
UML (2) - 2010/11
G. Bucci
78
Soggetto concreto
public class SoggettoConcreto extends Soggetto{
public SoggettoConcreto(){
osservatori = new ArrayList<Osservatore>();
stato = 0;
}
public void setStato(int s) {
stato= s;
System.out.println("Sono il soggetto (concreto). "
+"Ho subito una variazione di stato.);
this.informaOsservatori();
}
public int getStato() {
return stato;
}
UML (2) - 2010/11
G. Bucci
79
Osservatore Concreto
UML (2) - 2010/11
G. Bucci
80
Stimolatore
UML (2) - 2010/11
G. Bucci
81
Supporto java.util
Osservatore:
z
Deve implementare l’interfaccia Observer
z
L’interfaccia ha il solo metodo
update(Observable obj, Object arg)
z
chiamato quando l’oggetto osservato cambia
z I due parametri individuano l’oggetto che è
cambiato e gli argomenti passati
all’observer
UML (2) - 2010/11
G. Bucci
82
Lo schema semplificato
Invece di un update della
vista iniziale potrebbe essere
l’apertura di una nuova vista
UML (2) - 2010/11
G. Bucci
83
Contenuto
z Il pattern MVC
z
z
z
Il pattern Observer
z
UML (2) - 2010/11
G. Bucci
84
Una metodologia per l’analisi, la
progettazione e lo sviluppo di
sistemi software
(ICONIX)
UML (2) - 2010/11
G. Bucci
85
Passi del metodo
1.
Analisi dei requisiti
z
z
z
z
2.
z
Analisi di robustezza
Rifinitura casi d’uso e modello di dominio
Progetto dettagliato
z
z
4.
il “Cosa”
Analisi/Progetto preliminare
z
3.
Specifica dei requisiti funzionali
Modello di dominio (preliminare)
Analisi dei casi d’uso
Validazione requisiti Ù casi d’uso
Diagrammi di sequenza
il “Come”
Assegnazione responsabilità alle classi
Realizzazione
UML (2) - 2010/11
G. Bucci
86
Specifica Requisiti
z
z
[R2] Il sistema deve permettere in qualunque momento
la modifica o l'eventuale eliminazione di ogni singola
escursione. Si assume di trascurare le implicazioni e gli
effetti indotti da una modifica o da una cancellazione,
nel senso che non si producono avvisi per le persone
registrate, non si calcolano gli eventuali rimborsi da
effettuare, ecc..
[R3] Il sistema deve permettere di registrare un
partecipante ad una data escursione, consentendo, nel
caso siano previsti, la scelta di eventuali optional; deve
calcolare il costo dell'escursione comprensivo degli
optional.
UML (2) - 2010/11
G. Bucci
87
Modello di dominio
UML (2) - 2010/11
G. Bucci
88
Un Caso d’uso
UML (2) - 2010/11
G. Bucci
89
RequisitiÙCasi d’uso
R1
R2
R3
CU1
CU2
CU3
CU4
R4
R5
X
X
X
X
X
X
Verificare che tutti i requisiti funzionali siano “coperti”
almeno da un caso d’uso
UML (2) - 2010/11
G. Bucci
90
Riempire il fossato
(tra cosa e come)
COME
COSA
Robustness
Analysis
UML (2) - 2010/11
G. Bucci
91
Analisi/Progetto preliminare
z
L’analisi di robustezza può determinare
Una revisione dei casi d’uso
z Il perfezionamento del modello di dominio
z
z
Lo scopo è identificare le funzioni
(stereotipi controllori)
UML (2) - 2010/11
G. Bucci
92
Progetto dettagliato: Diagramma di
sequenza
UML (2) - 2010/11
G. Bucci
93
….Progetto dettagliato
Identificare tutte le classi e attribuire loro le responsabilità
=> classi completamente definite

Introdurre eventuali pattern progettuali
Ricorrere
a Frameworks e/o Librerie di componenti
(Possono avere un impatto non trascurabile )
I precedenti due punti possono portare a rivedere
quanto elaborato (nuove classi, ulteriori interazioni)
UML (2) - 2010/11
G. Bucci
94
Esempio: Progetto dettagliato/sviluppo
Questo sia un risultato dell’analisi dei casi d’uso
Stabiliamo di usare le Swing di Java per realizzare
l’interfaccia
=> Occorre adattarsi alle convenzioni delle Swing
UML (2) - 2010/11
G. Bucci
95
Esempio: Progetto dettagliato/sviluppo
Costruisce il bottone
Nella parte che costruisce la finestra “Menu”:
JButton rBtn = new JButton("Registrazione");
rBtn.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e) {
RDlg rDialog = new RDlg(“Registrazione partecipanti”);
}
Aggiunge un ascoltatore
Al verificarsi dell’evento
});
UML (2) - 2010/11
(un osservatore, ovvero un
viene istanziata la finestra
controllore) dell’evento
“Registrazione partecipanti”
ActionEvent (sul bottone)
G. Bucci
96
Negli esercizi di esame
Come è stato fatto fino ad ora
z
Si simulano Attori e Viste con un programma (una
o più classi), chiamando direttamente i metodi
delle classi di controllo e presentando i risultati
sulla console del sistema (di Eclipse)
z Ovviamente non c’è da fare il controllo degli
eventi (a meno che non sia espressamente
richiesto) perché si assume che il simulatore
generi solo eventi ammessi
UML (2) - 2010/11
G. Bucci
97
..negli esercizi di esame
z
Fare il diagramma che corrisponde alla
precedente
UML (2) - 2010/11
G. Bucci
98
..negli esercizi di esame
UML (2) - 2010/11
G. Bucci
99
FINE
z
Non è detto che nel futuro non venga
richiesto di fare qualche boundary
usando le swing.
UML (2) - 2010/11
G. Bucci
100