Analisi, Modellazione e altro - STLAB · UML (2) - 2010/11 G. Bucci 2 Contenuto zAnalisi e...

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


LinuxFactory


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


Banche

Contabilità


Automazione ind.

Monitor/Controllo


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”


Banche

Contabilità


Automazione ind.

Monitor/Controllo


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


+getOpera(nome): Opera

AnalisiOpera

+mostraOpera(nome)

UML (2) - 2010/11 G. Bucci 37

Aggiungiamo le interfacce (i metodi)

Opera


+getName(): String

Autore


Museo



Sezione

-numero: int-orario


Sala

-num: int


contiene

-opere1..*

1

eseguita

0..*1..*

-sale

-sezioni

UML (2) - 2010/11 G. Bucci 38

Procediamo alla realizzazione

Museo



Sezione

-numero: int-orario


Sala

-num: int


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



Sezione

-numero: int-orario


Sala

-num: int


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



Sezione

-numero: int-orario


Sala

-num: int


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


+getName(): String

Autore


Sezione

-numero: int-orario


Sala

-num: int


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


+getName(): String

Autore


Museo



Sezione

-numero: int-orario


Sala

-num: int


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


+getName(): String+getDescrizione()+getAutore()

Autore


+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




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




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




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




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.

Analisi, Modellazione e altro - STLAB · UML (2) - 2010/11 G. Bucci 2 Contenuto zAnalisi e...

Documents

Transcript of Analisi, Modellazione e altro - STLAB · UML (2) - 2010/11 G. Bucci 2 Contenuto zAnalisi e...