analisi, modellazione e altro - stlab · uml (2) - 2010/11 g. bucci 2 contenuto zanalisi e...
TRANSCRIPT
UML (2) - 2010/11 G. Bucci 1
5
UML Analisi, Modellazione e
altro
UML (2) - 2010/11 G. Bucci 2
ContenutoAnalisi e ModellazioneIl pattern Singleton (en passant)Stereotipi per l’analisiIl pattern MVC
Il pattern ObserverUna metodologia di Analisi-Progetto-Sviluppo
(Anticipo ulteriori concetti UML)
UML (2) - 2010/11 G. Bucci 3
Modellazione/Diagr ClassiDiagramma delle classi: è il principale strumento di modellazione
E’ la rappresentazione strutturale (statica) del sistema
Tre prospettive di uso:Livello concettuale: relazioni tra le classi del modelloLivello di specifica: responsabilità delle classi (interfacce)Livello di implementazione: classi di supporto, trasformazione, dettagli realizzativi (puntatori, liste, etc..)
UML (2) - 2010/11 G. Bucci 4
Analisi, mod concettuale
Responsabilità
Progetto, mod implementativo
Client button
+push()
BWindows
+push()
Blinux
+push()
BLinux
+push()
buttonClient
Prospettive
ClientWindow
<<interface>>
WLinux WWindows
BWindowsBlinux
AbFactory<<interface>>
+createWindow()+createButton()
Button<<interface>>
WinFactory
+createWindow()+createButton()
LinuxFactory
+createWindow()+createButton()
Mod. dominio
Applicazione
UML (2) - 2010/11 G. Bucci 5
Modellazione OO1. Costruzione del modello di dominio
Si identificano le entità del dominio applicativo e si modellano con oggetti/classiSi identificano le relazioni di associazione Possibilmente di identificano gerarchie di classi, specializzando, ridefinendo il comportamento nelle classi subordinate
UML (2) - 2010/11 G. Bucci 6
Modello di dominioIn esso entrano solo le entità che fanno parte del dominio applicativo (dette classi di analisi, ovvero classi entity)
Esempio: CC, Fido, Cliente, MutuoNon entrano gli oggetti che rappresentano soluzioni progettuali/implementative (liste, puntatori, ecc) o altro (interfacce utente, oggetti con funzione di controllo)
Esempio: StampaListaFidi
UML (2) - 2010/11 G. Bucci 7
Identific. classi/associazioniClassi/Oggetti sono tipicamente espressi da sostantivi (cliente, mutuo, fido …)
Associazioni sono tipicamente espresse da verbi che esprimono:
Collocazione fisica (contenuto in); azioni (gestisce, corre, ..); proprietà (possiede, ha); soddisfacimento di condizioni (sposato a)Ogni riferimento da una classe a un’altra èun’associazioneUna associazione deve esprimere una proprietàstrutturale del dominio, non un evento transitorio
UML (2) - 2010/11 G. Bucci 8
Esempi
Lista InvitatoBanchetto1..*
NO!
InvitatoBanchetto SI!1..*
Evitare di rappresentare soluzioni progettuali (implementative)
UML (2) - 2010/11 G. Bucci 9
Esempi
NO!Biblioteca
prestaLibro
SI!
Bibliotecacontiene
Libro
prestato
Una associazione deve esprimere una proprietàstrutturale del dominio, non un evento transitorio
UML (2) - 2010/11 G. Bucci 10
Esempi
NO!
Maritosposa
Moglie
SI!
0,1DonnaUomo
sposa
mogliemarito
0,1
I nomi delle classi devono riflettere la loro natura intrinseca, non il ruolo giocato nelle associazioni
UML (2) - 2010/11 G. Bucci 11
Esempio: Modellazione di un museo
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 eceramiche.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 12
Esempio (continuazione)Si analizza attentamente il testo alla ricerca dei sostantivi che identificano le classi e/o i loro eventuali attributi
I verbi come “ha”, “contiene”, “possiede”,.. danno le relazioni strutturali tra le classi
I verbi come “gestisce”, “legge” possono identificare relazioni strutturali oppure funzionalità
UML (2) - 2010/11 G. Bucci 13
Esempio (continuazione)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,…)
In grassetto possibili classi e attributi
UML (2) - 2010/11 G. Bucci 14
Esempio (continuazione)Un museo si compone di diverse sezioni, ciascuna comprende un certo numero di sale. Ogni sezioneha un orario di apertura giornaliero…..Sono aggregazioni
Museo Sezione
-orario
Sala
UML (2) - 2010/11 G. Bucci 15
Esempio (continuazione)Ogni sezione ha un orario di apertura giornaliero ed è custodita durante l’orario da un solo custodesecondo 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
-orarioCustode
CustoditaDa
-giorno
**
UML (2) - 2010/11 G. Bucci 16
Esempio (continuazione)Ciascuna sala comprende diverse opere d’arte: dipinti, sculture (divise in bassorilievi, altorilievi, statue), arazzi e ceramiche.
Opera
-periodoStorico
Dipinto
Bassorilievo
ArazzoScultura Ceramica
Statua Altoril.
Sala
contiene
1..*
1
Perché non aggregazione?
UML (2) - 2010/11 G. Bucci 17
Esempio (continuazione)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,…)
Opera
-periodoStoricoAutore
+movimentoArtistico
Sala
contiene
1..*
1
eseguita
0..*1..*
Perchéattributi e non classi?
UML (2) - 2010/11 G. Bucci 18
Opera
-periodoStorico
Dipinto
Bassorilievo
ArazzoScultura Ceramica
Statua Altoril.
Autore
+movimentoArtistico
Museo Sezione
-orario
Sala
Custode
CustoditaDa
-giorno
contiene1..*
1
eseguita
0..*1..*
UML (2) - 2010/11 G. Bucci 19
CommentoIl diagramma precedente rappresenta il modello del dominio applicativo
In pratica è il modello dei datiNel campo dell’elaborazione dei dati il modello dei dati è di norma l’aspetto rilevanteIl nostro esempio somiglia molto a un problema di basi di dati: è difficile immaginare un caso d’uso diverso da una interrogazione o un aggiornamento
Di per sé c’è poca (o nessuna) “logica di business”
La logica dell’applicazione si costruisce a parte
UML (2) - 2010/11 G. Bucci 20
..CommentoCi 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:
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 21
Divagazione
Prevalente manipolaz. Dati
Banche
Contabilità
Prevalente controllo
Automazione ind.
Monitor/Controllo
Controllo e manipolaz. dati
Word process.
Modellazione
Classi di applicazioni
UML (2) - 2010/11 G. Bucci 22
Applicazioni di controllo
Prevalente manipolaz. Dati
Banche
Contabilità
Prevalente controllo
Automazione ind.
Monitor/Controllo
Controllo e manipolaz. dati
Word process.
Modellazione
Pochi dati da manipolare, eventi da tenere sotto controllo
Tempo reale (anche stretto)
Operatività (24H ?)
UML (2) - 2010/11 G. Bucci 23
Applicazioni “Enterpise”
Prevalente manipolaz. Dati
Banche
Contabilità
Prevalente controllo
Automazione ind.
Monitor/Controllo
Controllo e manipolaz. dati
Word process.
Modellazione
Molti dati da manipolare
Persistenza
Operatività (24H)
Real time (?)
UML (2) - 2010/11 G. Bucci 24
Schema Appl. Enterprise
UML (2) - 2010/11 25G. Bucci
NN--tiertier (AE)(AE)
Appl. serversClientDB serverWeb server
NetworkMiddleware
Middleware
Presentation Business logic Dati
UML (2) - 2010/11 G. Bucci 26
..CommentoPratica consolidata per le applicazioni enterprise: ORM (object-relational mapping)
Un mondo “morto”Un mondo “vivo”
UML (2) - 2010/11 G. Bucci 27
.. ..ma perché ?Perché si vuole utilizzare tecnologie OO
L’Applicazione è programmata a oggettiLa base di dati contiene un numero di dati potenzialmente molto grandeNell’applicazione, in un dato momento, sono presenti solo gli oggetti che servono (quelli che corrispondono ai dati che in quel momento vengono manipolati)Il Mapper ha la funzione di mappare oggetti su tabelle e viceversa.
Torneremo sull’a
rgomento
UML (2) - 2010/11 G. Bucci 28
Esempio: una bolla di consegna
Si immaginano questi attributiNumero progressivoData di emissioneTermine di pagamentoIntestatarioUn certo numero di righe ciascuna delle quali descrive un prodotto, la quantità, il prezzo unitario e il prezzo totaleEcc.
UML (2) - 2010/11 G. Bucci 29
..bolla (AE)
Cosa possiamo chiedere a una bolla?Lettura/modifica di attributi
Forse qualche specifica operazione: aggiunta di una Riga
UML (2) - 2010/11 G. Bucci 30
Metodi get e setClassi 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
Cfr. Information Hidig – Incapsulamento
Type getAttributo_i(); void setAttributo_i(param);
Si usa anche il termine Proprietà in luogo di attributo
UML (2) - 2010/11 G. Bucci 31
Dove sta la logica applicativa?
Nelle applicazione enterprise:Di norma conviene che la logica applicativa sia realizzata attraverso classi aggiuntive
Tipicamente classi di controllo che “comandano” le classi del modelloLe 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 32
…Dove sta la logica applicativa? Nelle applicazioni di controllo
Sta nel modello!Gli oggetti del modello rappresentano entità del mondo reale che effettivamente hanno un comportamento
Sensore
SensTemperature SensPressione
Attuatore
Elettrovalvola Motore
Controllore
1
1..*
1
1..*
Timer
Classe attiva
UML (2) - 2010/11 G. Bucci 33
Come procederemo?Studieremo prima il caso delle applicazioni tipo Enterprise
Focalizzando solo l’aspetto della programmazione OO dell’applicazione (rimandando la questione della persistenza dei dati)
Successivamente parleremo di ORMIn un secondo tempo esamineremo anche il caso di sistemi a prevalente aspetto di controllo
UML (2) - 2010/11 G. Bucci 34
Torniamo al MuseoAggiungiamo qualche attributo per rendere l’esempio più realistico
Opera
-id: int-nome: String-descrizione: String-periodoStorico~//altri attributi
Autore
-nome: String-movimentoArtistico
Museo
-nome: String-indirizzo
Sezione
-numero: int-orario
Sala
-num: int
contiene1..*
1
eseguita
0..*1..*Gli altri attributi potrebbero essereoggetti legati all'opera; p.es. gli eventuali restauri subiti, gli expertise, ecc.
UML (2) - 2010/11 G. Bucci 35
L’applicazione Potrebbe richiedere che il sistema mostri tutti i dati relativi a una data Opera
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 menuStabiliamo 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 36
..Esempio
Occorre prevedere i metodi adeguati nelle altre classi per permettere la navigazione
Arrivare fino a OperaRestituire all’applicazione (all’oggetto della classe AnalisiOpera) il riferimento all’opera cercata
Museo
-nome: String-indirizzo
+getOpera(nome): Opera
AnalisiOpera
+mostraOpera(nome)
UML (2) - 2010/11 G. Bucci 37
Aggiungiamo le interfacce (i metodi)
Opera
-id: int-nome: String-descrizione: String-periodoStorico~//altri attributi
+getName(): String
Autore
-nome: String-movimentoArtistico
Museo
-nome: String-indirizzo
+getOpera(nome): Opera
Sezione
-numero: int-orario
+getOpera(nome): Opera
Sala
-num: int
+getOpera(nome): Opera
contiene
-opere1..*
1
eseguita
0..*1..*
-sale
-sezioni
UML (2) - 2010/11 G. Bucci 38
Procediamo alla realizzazione
Museo
-nome: String-indirizzo
+getOpera(nome): Opera
Sezione
-numero: int-orario
+getOpera(nome): Opera
Sala
-num: int
+getOpera(nome): Opera
contiene
1
-sale
-sezioni
Restituisce null se non si trova l’opera
Realizzate come Collection
( size(), get(index), …)
UML (2) - 2010/11 G. Bucci 39
Java
Museo
-nome: String-indirizzo
+getOpera(nome): Opera
Sezione
-numero: int-orario
+getOpera(nome): Opera
Sala
-num: int
+getOpera(nome): Opera
contiene
1
-sale
-sezioni
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;
}
UML (2) - 2010/11 G. Bucci 40
..Java
Museo
-nome: String-indirizzo
+getOpera(nome): Opera
Sezione
-numero: int-orario
+getOpera(nome): Opera
Sala
-num: int
+getOpera(nome): Opera
contiene
1
-sale
-sezioni
Opera getOpera(String nome){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;
}
UML (2) - 2010/11 G. Bucci 41
Opera
-id: int-nome: String-descrizione: String-periodoStorico~//altri attributi
+getName(): String
Autore
-nome: String-movimentoArtistico
Sezione
-numero: int-orario
+getOpera(nome): Opera
Sala
-num: int
+getOpera(nome): Opera
contiene
-opere1..*
1
eseguita
0..*1..*
-sale
-sezioni
Opera getOpera(String nome){if (opere.isEmpy()){
è possibile ?? ::::}
int i=0;while (i<opere.size()){
if (opere.get(i).getName() == nome )return opere.get(i);
i++;}return null;
}
UML (2) - 2010/11 G. Bucci 42
La navigazione
Opera
-id: int-nome: String-descrizione: String-periodoStorico~//altri attributi
+getName(): String
Autore
-nome: String-movimentoArtistico
Museo
-nome: String-indirizzo
+getOpera(nome): Opera
Sezione
-numero: int-orario
+getOpera(nome): Opera
Sala
-num: int
+getOpera(nome): Opera
contiene
-opere1..*
1
AnalisiOpera
+mostraOpera(nome)
eseguita
0..*1..*
-sale
-sezioni
Torna il riferimento all’opera cercata (o null)
UML (2) - 2010/11 G. Bucci 43
..E ora l’applicazionevoid mostraOpera(String nome) {
opera = museo.getOpera(nome);if (opera != null){
descr = opera.getDescrizione();autore = opera.getAutore();nomeAutore = autore.getNome();//ecc.}
else {// l’opera con quel nome non esiste
}
I primi due metodi devono essere aggiunti alla classe Opera, il terzo alla classe Autore.
Opera
-id: int-nome: String-descrizione: String-periodoStorico~//altri attributi
+getName(): String+getDescrizione()+getAutore()
Autore
-nome: String-movimentoArtistico
+getNome()
contiene
-opere1..*
1
eseguita
0..*1..*
UML (2) - 2010/11 G. Bucci 44
DomandaPerché tutto questo traffico?
Non si poteva rendere le opere visibili ad AnalisiOpera, in modo da evitare la lunga navigazione?
Opera o = null;int i= 0;while (i<opere.size() && o==null){
if (opere.get(i).getNome == nome) o= opere.get(i);}
In AnalisiOpera
UML (2) - 2010/11 G. Bucci 45
Risposta
Certamente sì! Però….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:
Anche dell’oggetto applicazione! E di tutte le applicazioni che intendono accedere alle opere !!!
Vogliamo che il modello possa espandersi/contrarsi senza alcun impatto sulle applicazioni
UML (2) - 2010/11 G. Bucci 46
Eventualmente...
Mettiamo in Museo il metodo getOpere() che restituisce all’applicazione la collection opere
Motivi di efficienza possono suggerire l’aggiunta di associazioni non strettamente necessarie
Attenzione: Non sono la stessa cosa
UML (2) - 2010/11 G. Bucci 47
Confronto con le Basi dati
Vogliamo riportarci a una situazione analoga Museo deve fare da “contenitore” degli oggetti del modello e provvedere l’interfaccia per accedervi
Applicazione
DBMS
Le tabelle sono visibili dall’applicazione ma solo come nomiLa gestione è affidata al DBMS; l’accesso è via SQL
UML (2) - 2010/11 G. Bucci 48
La classe Museo provvede l’interfaccia tra il modello di dominio e l’esterno. Essa costituisce una sorta di contenitoreLa logica dell’applicazione sta all’esterno e si riferisce al museo per raggiungere gli oggetti del modello
Forse parte della logica applicativa poteva anche essere parzialmente embedded nel Museo (e nelle altre classi del modello)
..Cosa vogliamo
Applicazione
Museo
UML (2) - 2010/11 G. Bucci 49
..CommentiE’ meglio avere la logica applicativa esterna o dentro il modello?
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 ?Una per funzionalità?Approfondiremo più avanti questo aspetto
UML (2) - 2010/11 G. Bucci 50
ContenutoAnalisi e ModellazioneIl pattern Singleton (en passant)Stereotipi per l’analisiIl pattern MVC
Il pattern ObserverUna metodologia di Analisi-Progetto-Sviluppo
(Anticipo ulteriori concetti UML)
UML (2) - 2010/11 G. Bucci 51
MotivoE’ bene che Museo venga istanziato una sola volta
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 52
SingletonGarantisce che di una classe non possa essere istanziato più di un oggetto
Come: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:Dichiarare privato il costruttorePrevedere un metodo pubblico statico (di classe) che:
istanzia un esemplare se l’esemplare non è già istanziatorestituisce l'oggetto già istanziato nel caso contrario
UML (2) - 2010/11 G. Bucci 53
..Singletonpublic class Singleton {
private static Singleton instance = nullprivate 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 nomereturn nome;
}}
UML (2) - 2010/11 G. Bucci 54
.. SingletonNel chiamante:
Singleton soloLui;::::
soloLui = Singleton.getInstance();
Il pattern Singleton garantisce che ci sia una sola istanza di una data classe e fornisce un punto di accesso globale a tale istanza.
Definizione
UML (2) - 2010/11 G. Bucci 55
ContenutoAnalisi e ModellazioneIl pattern Singleton (en passant)Stereotipi per l’analisiIl pattern MVC
Il pattern ObserverUna metodologia di Analisi-Progetto-Sviluppo
(Anticipo ulteriori concetti UML)
UML (2) - 2010/11 G. Bucci 56
Tre stereotipi per l’analisi
Entity: classi di oggetti che rappresentano la semantica del dominio applicativo
Boundary: classi di oggetti che rappresentano l’interfaccia tra gli attori e il sistema (il modello applicativo e il resto)
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 57
Boundary Control Entity
UML (2) - 2010/11 G. Bucci 58
Estrema sintesiQualunque sistema è schematizzabile in questomodo
MODELLO DEL DOMINIOINTERFACCIA U. FUNZIONALITA’
UML (2) - 2010/11 G. Bucci 59
..segueQualunque sistema è composto da questi ingredienti
MuseoOperaConto CorrenteClienteLibroFattura ……..
Analisi OperaCalcola Saldo di XXCerca Fattura del gg/mm/aaCalcola Totale Crediti…..
UML (2) - 2010/11 G. Bucci 60
..ma ancheQualunque sistema è composto da questi ingredienti
PressioneTemperaturaAltezzaQuesto può essere un vero modello matematico
Controllore TemperaturaControllore VelocitàControllore Frenata
Driver
Dispositivo
UML (2) - 2010/11 G. Bucci 61
..Un vero modello!Un modello fatto di equazioni!
Sensore di livello a Firenze Driver Controllore livello Modello piena
LivelloInterruz. Calcola livello a 3 ore a Empoli
UML (2) - 2010/11 G. Bucci 62
Dinamica (semplificata)
UML (2) - 2010/11 G. Bucci 63
ContenutoAnalisi e ModellazioneIl pattern Singleton (en passant)Stereotipi per l’analisiIl pattern MVC
Il pattern ObserverUna metodologia di Analisi-Progetto-Sviluppo
(Anticipo ulteriori concetti UML)
UML (2) - 2010/11 G. Bucci 64
MVC Model-View-Controller
Model: Oggetto applicativo (classi entity)View: Presentazione (viste)/lettura
ingressi (classi boundary)Controller: Determina il comportamento del
modello e della presentazione (classi control)
View
Model
Controller
UML (2) - 2010/11 G. Bucci 65
Viste differenti
UML (2) - 2010/11 G. Bucci 66
ModelIncapsula lo stato dell’applicazioneSegnala i cambiamenti (di stato) a View
ControllerDefinisce il comportamento del modelloMappa le azioni dell’utente in richiestedi aggiornamento dello stato del modelloSeleziona la vista per le risposte(Un controllore per funzionalità)
ViewMostra il modello (i dati nel modello)Richiede lo stato al modello (aggiornamento) Trasmette al controllore gli input dell’utenteConsente al controllore di selezionare differenti viste
Comandi cambiam. stato
Input utente
Segnalazione cambiamenti
Selezione vista
Rich. stato
Invocazione metodiEventi
UML (2) - 2010/11 G. Bucci 67
MVC
E’ esso pure un Pattern di progettazione (di livello molto alto)Disaccoppia le tre categorie di oggetti
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
Più viste per uno stesso modello
UML (2) - 2010/11 G. Bucci 68
Dinamica (forma classica)(Control) (Model)(Boundary)
UML (2) - 2010/11 G. Bucci 69
Pattern ObserverIl Modello e la Vista implementano il pattern publish & subscribe detto anche observerIl pattern assume che l’oggetto (Subjecto Observable) che contiene i dati sia separato rispetto agli oggetti (Observer) che presentano i datiGli observer osservano i cambiamenti nel subject
UML (2) - 2010/11 G. Bucci 70
Pattern Observer
UML (2) - 2010/11 G. Bucci 71
Il Pattern ObserverDefinisce 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 72
Modello UML
UML (2) - 2010/11 G. Bucci 73
Messa in moto1. Istanziazione soggetto (concreto)2. Istanziazione osservatore (concreto)3. Registrazione dell’osservatore sul
soggetto4. Passaggio del soggetto all’osservatore5. Eventuale ripetizione dei passi 2-4
UML (2) - 2010/11 G. Bucci 74
Dettaglio
UML (2) - 2010/11 G. Bucci 75
Dinamica
UML (2) - 2010/11 G. Bucci 76
Interfaccia osservatore
UML (2) - 2010/11 G. Bucci 77
Sogettopublic 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
Sogettopublic 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 79
Soggetto concretopublic 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 80
Osservatore Concreto
UML (2) - 2010/11 G. Bucci 81
Stimolatore
UML (2) - 2010/11 G. Bucci 82
Supporto java.utilOsservatore:
Deve implementare l’interfaccia ObserverL’interfaccia ha il solo metodoupdate(Observable obj, Object arg)
chiamato quando l’oggetto osservato cambiaI due parametri individuano l’oggetto che ècambiato e gli argomenti passati all’observer
UML (2) - 2010/11 G. Bucci 83
Lo schema semplificato
Invece di un update della vista iniziale potrebbe essere l’apertura di una nuova vista
UML (2) - 2010/11 G. Bucci 84
ContenutoAnalisi e ModellazioneIl pattern Singleton (en passant)Stereotipi per l’analisiIl pattern MVC
Il pattern ObserverUna metodologia di Analisi-Progetto-Sviluppo
(Anticipo ulteriori concetti UML)
UML (2) - 2010/11 G. Bucci 85
Una metodologia per l’analisi, la progettazione e lo sviluppo di
sistemi software
(ICONIX)
UML (2) - 2010/11 G. Bucci 86
Passi del metodo1. Analisi dei requisiti
Specifica dei requisiti funzionaliModello di dominio (preliminare) Analisi dei casi d’uso Validazione requisiti casi d’uso
2. Analisi/Progetto preliminareAnalisi di robustezzaRifinitura casi d’uso e modello di dominio
3. Progetto dettagliatoDiagrammi di sequenzaAssegnazione responsabilità alle classi
4. Realizzazione
il “Come”
il “Cosa”
UML (2) - 2010/11 G. Bucci 87
Specifica Requisiti[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 88
Modello di dominio
UML (2) - 2010/11 G. Bucci 89
Un Caso d’uso
UML (2) - 2010/11 G. Bucci 90
Requisiti Casi d’uso
CU3
CU4
CU1
CU2
R2R1 R5R4R3
X X
X
X
XX
Verificare che tutti i requisiti funzionali siano “coperti”almeno da un caso d’uso
UML (2) - 2010/11 G. Bucci 91
Riempire il fossato(tra cosa e come)
COMECOSA
RobustnessAnalysis
UML (2) - 2010/11 G. Bucci 92
Analisi/Progetto preliminareL’analisi di robustezza può determinare
Una revisione dei casi d’usoIl perfezionamento del modello di dominio
Lo scopo è identificare le funzioni (stereotipi controllori)
UML (2) - 2010/11 G. Bucci 93
Progetto dettagliato: Diagramma di sequenza
UML (2) - 2010/11 G. Bucci 94
….Progetto dettagliato
Introdurre eventuali pattern progettuali
Ricorrere a Frameworks e/o Librerie di componenti(Possono avere un impatto non trascurabile )
Identificare tutte le classi e attribuire loro le responsabilità=> classi completamente definite
I precedenti due punti possono portare a rivedere quanto elaborato (nuove classi, ulteriori interazioni)
UML (2) - 2010/11 G. Bucci 95
Esempio: Progetto dettagliato/sviluppo
Stabiliamo di usare le Swing di Java per realizzare l’interfaccia
=> Occorre adattarsi alle convenzioni delle Swing
Questo sia un risultato dell’analisi dei casi d’uso
UML (2) - 2010/11 G. Bucci 96
Esempio: Progetto dettagliato/sviluppo
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”);}
});
Costruisce il bottone
Aggiunge un ascoltatore (un osservatore, ovvero un
controllore) dell’evento ActionEvent (sul bottone)
Al verificarsi dell’evento viene istanziata la finestra
“Registrazione partecipanti”
UML (2) - 2010/11 G. Bucci 97
Negli esercizi di esameCome è stato fatto fino ad ora
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)
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 98
..negli esercizi di esame
Fare il diagramma che corrisponde alla precedente
UML (2) - 2010/11 G. Bucci 99
..negli esercizi di esame
UML (2) - 2010/11 G. Bucci 100
FINENon è detto che nel futuro non venga richiesto di fare qualche boundaryusando le swing.