Università degli Studi di Roma “La Sapienza” Facoltà di...

Progettazione del Software, Laurea in Ingegneria Gestionale

Università degli Studi di Roma “La Sapienza”Facoltà di Ingegneria – Corso di Laurea in Ingegneria Gestionale

Corso di Progettazione del SoftwareProff. Toni Mancini e Monica ScannapiecoDipartimento di Informatica e Sistemistica

Università di Roma “La Sapienza”

S.P.1 – La fase di Progetto

versione del February 18, 2008

T. Mancini & M. Scannapieco S.P.1 – La fase di Progetto – February 18, 2008 – p. 1/65


Modifiche rispetto alle versioni precedenti

Rispetto alla versione del 1 Marzo 2007 Aggiunto “implements Cloneable ” alla prima rigadella slide n. 25 (DataOra con side-effect senza cond.)



La fase di progetto

L’input di questa fase è costituito da:

– lo schema concettuale , formato da:– diagramma delle classi e degli oggetti– diagramma degli use case

– diagrammi degli stati e delle transizioni

– la specifica– una specifica per ogni classe

– una specifica per ogni use case

– una specifica per ogni tipo di dato definito in fase di analisi

L’output della fase di analisi è una concettualizzazione delle informazioni e delle funzionalitàdi interesse per la nostra applicazione che però prescinde da considerazioni tecnologiche.

Per potere produrre un programma in modo efficace, dobbiamo prendere in esame alcuniaspetti su come la nostra applicazione utilizzerà tali informazioni e funzionalità. Questo èesattamente lo scopo della fase di Progetto.



La fase di Progetto (cont.)

In particolare la fase di Progetto si occupa di:

– definire l’architettura del programma

– scegliere le strutture di rappresentazione

– scegliere gli algoritmi che realizzano le funzionalità che il sistema deve offrire(operazioni di classe, tipi di dato, use-case).



Output della fase di Progetto

L’output della fase di Progetto è costituito da:

– La scelta o il progetto delle strutture dati (ove non esiste una corrispondenza evidentecon i tipi base Java) da utilizzare:

– per rappresentare i tipi di dato

– necessarie all’implementazione delle operazioni di classe e di use case (ad es.per mantenere informazioni di supporto)

– necessarie alla realizzazione dell’architettura del programma (ad es. perrealizzare attributi multivalore).

– La ristrutturazione delle generalizzazioni e delle gerarchie is-a di modo da poterleeffettivamente realizzare in Java

– La segnatura e gli algoritmi delle operazioni delle classi, use case, e strutture dati

– La scelta sulla gestione delle proprietà locali (attributi) e globali (associazioni) delleclassi

– Le scelte relative al progetto dei diagrammi degli stati e transizioni

– La scelta delle classi UML che hanno responsabilità sulle associazioni



Output della fase di Progetto (cont.)

Alcuni di questi aspetti andranno a confluire in un raffinamento del diagramma delle classiprodotto nella fase di analisi, chiamato diagramma delle classi realizzativo .

Tale diagramma contiene tutte le informazioni necessarie alla realizzazione del codice, leuniche scelte che rimangono da fare sono scelte programmative.

Nota: il diagramma delle classi realizzativo è peggiore del diagramma delle classiconcettuale, in quanto si sono effettuate delle scelte influenzate da tecnicalità realizzative.



Scelta dei tipi Java e delle strutture dati

Tipi base usati in fase di analisi: Di solito hanno un corrispondente esatto nel linguaggio diprogrammazione scelto (Java). In questi casi è opportuno decidere di realizzarlimediante questi ultimi;

Specializzazione dei tipi base: Di solito il tipo Java corrispondente è semanticamente piùesteso del tipo UML (ad es., intero > 0 vs. int ). Per questi, è di solito sufficienteutilizzare il corrispondente tipo Java, con opportuni accorgimenti (verifica delleprecondizioni, cf. in seguito)

Tipi enumerativi: Di solito è sufficiente realizzare un tipo enumerativo ad n valori mediante unintero nell’intervallo [1..n]. Allo stesso modo dei tipi base specializzati, vanno usatiopportuni accorgimenti (verifica delle precondizioni)

Tipi definiti: Di questi tipi è stata prodotta una specifica in fase di analisi. Sulla base diquesta, va deciso se è possibile realizzarli utilizzando opportune classi di libreriafornite dal linguaggio (Java), oppure è necessario progettare per essi delle strutturedati ad-hoc (cf. seguito).

Nota: Per ottenere una migliore modularizzazione, in alcuni casi è ragionevole scegliere direalizzare i tipi base specializzati e quelli enumerativi alla stessa stregua dei tipi definiti.



Verifica delle precondizioni

In alcuni casi, il tipo Java che si sceglie per rappresentare il tipo di un attributo ha dei valorinon ammessi per quest’ultimo (ad es. int vs. intero > 0. Si dice che il tipo Java èsemanticamente più esteso del tipo UML che realizza.

Ad esempio, nella classe UML Persona potrebbe essere presente un attributo età, di tipo0..120.

Persona

Eta : 0..120

In tali casi si pone il problema di assicurare che i valori usati nei parametri attuali delcostruttore di Persona e della funzione setEta() siano coerenti con l’intervallo. Unproblema simile si ha quando un’operazione di una classe o di uno use case haprecondizioni .

Esistono due possibili approcci alla soluzione di questo problema:

– Verifica lato client ;

– Verifica lato server .



Verifica precondiz. lato client

È sempre il cliente a doversi preoccupare che siano verificate le condizioni di ammissibilità.La classe (il server) non effettua alcun controllo.

Con tale approccio, il cliente ha bisogno di un certo grado di conoscenza dei meccanismi difunzionamento della classe, il che potrebbe causare un aumento dell’accoppiamento .

Inoltre, il controllo delle precondizioni verrà duplicato in ognuno dei clienti, conindebolimento dell’estendibilità e della modularità .

Esempio. Un modulo che modifica il valore del campo eta di un oggetto di classe personap mediante un valore letto da tastiera, potrebbe essere il seguente:....Persona p = ...;int nuovaEta = ...; // legge un intero da tastieraif(nuovaEta >= 0 && nuovaEta <= 120) {

p.setEta(nuovaEta);} else {

...// Il valore ‘nuovaEta’ non rispetta le precondizioni:// non viene assegnato a p.eta

}...



Verifica precondiz. lato server

È la classe a doversi preoccupare della verifica delle condizioni di ammissibilità.

In tale approccio, le funzioni della classe lanceranno un’eccezione nel caso in cui lecondizioni non siano rispettate. Il cliente intercetterà tali eccezioni , e intraprenderà leopportune azioni.

A tale scopo, si possono prevedere, in fase di Realizzazione, opportune classi Java, derivateda Exception o RuntimeException, per rappresentare le diverse tipologie di eccezioni(rispettivamente “checked” o “unchecked”).

Nei casi più semplici (approccio usato in questo corso), si prevede un’unica classe,EccezionePrecondizioni , per tutte le possibili eccezioni nelle precondizioni.



Verifica precondiz. lato server (cont.)

Di seguito viene riportato un esempio della classe Java Persona che implementa la verificalato server e una semplice implementazione della classe EccezionePrecondizioni (in realtàtale implementazione è di competenza della successiva fase di Realizzazione):public class Persona {

...private int eta; // tipo UML 0..120 realizzato come int!...public setEta(int e) throws EccezionePrecondizioni {

if (e < 0 || e > 120) {throw new EccezionePrecondizioni("Eta’ non valida");// Quando viene generata un’eccezione, il metodo// interrompe la sua esecuzione: l’eta’ non viene cambiata!

}eta = e;

}} //:˜

// File EccezionePrecondizioni.javapublic class EccezionePrecondizioni extends Exception {

public EccezionePrecondizioni() { super(); }public EccezionePrecondizioni(String messaggio) { super (messaggio); }

} //:˜



Progetto di strutture dati

Può essere necessario progettare strutture dati ad-hoc per rappresentare i tipi di dato definitinel diagramma delle classi concettuale (ad es. il tipo UML Indirizzo visto più volte in fase diAnalisi), oppure a supporto dell’implementazione delle operazioni di classe o use-case. Talistrutture dati saranno implementate, in fase di Realizzazione, mediante opportune classiJava.In questi casi, durante la fase di progetto si deve decidere:

– Quali sono gli attributi della classe (si ricordi che gli attributi definiti nella specifica deltipo prodotta in fase di Analisi sono quelli concettuali, ed è possibile che si decida direalizzare la classe utilizzando un diverso meccanismo di rappresentazione dei valoridel tipo)

– Lo schema realizzativo da adottare, definito da due coordinate:1. La possibilità per le operazioni del tipo di fare o meno side-effect (modificare)

sull’oggetto di invocazione o su sue componenti, oppure di consentire o meno ailoro clienti tale possibilità (ad esempio ritornando riferimenti di componentimodificabili dell’oggetto di invocazione)

2. La possibilità per gli oggetti di condividere o meno memoria

Sono quindi possibili 4 diversi approcci (con o senza side-effect, con o senzacondivisione di memoria).



Progetto di strutture dati (cont.)

– Come va controllata l’uguaglianza profonda tra oggetti della classe, al fine di essereconsistenti con la semantica dell’uguaglianza tra i valori del tipo che si sta realizzando.

Tali decisioni vanno esplicitate nella cosiddetta specifica realizzativa della struttura datiche si sta progettando (cf. seguito).



Esempio: la classe DataOra

Supponiamo di dover progettare una classe che realizzi il tipo di dato DataOra, conl’operazione domani() (che assumiamo presente nella specifica prodotta in fase di Analisi),che calcola l’istanza rappresentante la stessa ora del giorno successivo quellorappresentato dall’oggetto di invocazione.Scegliamo di realizzare la classe Java DataOra come aggregato di un attributo data di tipoData ed uno ora di tipo Ora.

Realizzazione senza side-effect.

– L’operazione domani() ritorna un nuovo oggetto di classe DataOra che rappresenta lastessa ora del giorno seguente this.

– L’oggetto di invocazione this non viene mai modificato.

– La classe inoltre non consentirà ai suoi clienti di modificare il valore degli attributidell’oggetto di invocazione.

Esempio : se l’attributo data : Data di this fosse mutabile, nessuna operazione della classe(ad es. getData() ritornerebbe il riferimento a this.data, perché questo consententirebbe adun cliente di effettuare indirettamente side-effect su this modificando il valore dell’attributothis.data.L’operazione getData() ritornerà invece una copia dell’oggetto a cui this.data si riferisce.



Esempio: la classe DataOra (cont.)

Realizzazione con side-effect.

– L’operazione domani() modifica l’oggetto di invocazione this, facendolo avanzare di 24ore.

– La classe inoltre potrà consentire ai suoi clienti di modificare il valore degli attributidell’oggetto di invocazione.

– Ovviamente, resta compito del progettista della classe impedire side-effect nondesiderati, fornendo un accesso controllato ai campi dati.




Realizzazione con condivisione di memoria. Questo schema consente a due oggettidistinti della classe Java DataOra che realizza il tipo, di condividere in memoria oggetti diclasse Data oppure Ora:

g 5

m 4

do1 data a 2006 h 16

ora m 0

s 0

h 14

do2 data m 28

ora s 56

Oggetto di

classe Data

Oggetti di

classe Ora

Nella figura, gli oggetti puntati da do1 e do2, che rappresentano gli istanti “5/4/2006,16:00:00” e “5/4/2006, 14:28:56” rispettivamente, condividono l’oggetto di classe Data.




Realizzazione senza condivisione di memoria.. La classe si comporterà in modo di taleda non permettere mai che esistano porzioni di memoria comuni ad oggetti distinti.

g 5

m 4

do1 data a 2006 h 16

ora m 0

s 0

g 5

do2 data m 4

ora a 2006

h 14

m 28

s 56

Oggetti di

classe Data

Oggetti di

classe Ora



Tipi di dato: schemi realizzativi

Senza side-effect.

Vantaggi: Vicinanza alle specifiche (cioè alla formulazione matematica del tipo comealgebra, le cui operazioni sono funzioni matematiche, ovvero calcolano valori a partireda valori)

Svantaggi: Potenziale perdita di efficienza: alcune operazioni che calcolano valori del tipopossono essere costrette a copiare intere strutture in memoria, per evitare il side-effect(cf. l’operazione domani() della classe Data)

Con side-effect.

Vantaggi: Maggiore efficienza delle operazioni che calcolano valori del tipo

Svantaggi: Maggiore lontananza dalle specifiche (gli oggetti della classe vengono modificati,mentre per i valori di un tipo, algebra eterogenea, questo non sarebbe possibile)



Tipi di dato: schemi realizzativi (cont.)

Con condivisione di memoria.

Vantaggi: Risparmio nell’occupazione di memoria

Svantaggi: Necessità di copie di strutture (quelle mutabili) per evitare side-effect nondesiderati

Senza condivisione di memoria.

Vantaggi: Riduzione della necessità di effettuare copie di strutture per evitare side-effect nondesiderati

Svantaggi: Aumento dell’occupazione di memoria, che può diventare oneroso in presenza distrutture grandi



Schemi realizzativi (cont)

Le combinazioni più usate sono le due che massimizzano i vantaggi:

Senza side-effect, con condivisione di memoria:

– Le operazioni della classe che realizza il tipo non modificano mai il valore delleproprietà dell’oggetto di invocazione.

– Gli oggetti possono avere componenti condivise in memoria.

Con side-effect, senza condivisione di memoria:

– Le operazioni della classe che realizza il tipo possono modificare il valore delleproprietà dell’oggetto di invocazione.

– Gli oggetti non possono avere componenti condivise in memoria.



La classe Data con side-effect (senza cond.)

Per chiarire le differenze tra i diversi schemi realizzativi, diamo l’esempio di una possibilerealizzazione della classe Data con side-effect (la condivisione di memoria in questo casonon è possibile perché gli attributi della classe sono tutti di tipi base).

Si osservi che l’implementazione della classe Java che realizza un tipo è relativa allasuccessiva fase di Realizzazione, dove verrà descritta in modo più approfondito.public class DataSideEffect implements Cloneable {

private int g, m, a;// Gli attributi sono tutti di tipi// base, non puo’ esserci condivisione

public DataSideEffect(int gg, int mm, int aa) {g = gg; m = mm; a = aa;

}public int getGiorno() { return g; }...public void setGiorno(int gg) { g = gg; } // side-effect!...public boolean equals(Object o) { ... }public int hashCode() { ... }

// Necessario, per evitare side-effect// non desiderati!public Object clone() { ... }

} //:˜



La classe Data senza side-effect (con cond.)

public class DataNoSideEffect {private int g, m, a;// Gli attributi sono tutti di tipi// base, non puo’ esserci condivisione

public DataNoSideEffect(int gg, int mm, int aa) {g = gg; m = mm; a = aa;

}public int getGiorno() { return g; }...// Ritorno un nuovo oggetto!public DataNoSideEffect setGiorno(int gg) {

return new DataNoSideEffect(gg, this.m, this.a);}...public boolean equals(Object o) { ... }public int hashCode() { ... }

// Dato che gli oggetti sono immutabili,// posso evitare di ridefinire clone()

} //:˜



Esercizi

Realizzare la classe Ora secondo gli schemi alternativi seguenti:Campi dati.

1. tre attributi di tipo intero, ore, min, sec

2. un attributo intero, sec (secondi dalla mezzanotte)

Schema realizzativo.

1. Senza side-effect, con condivisione

2. Con side-effect, senza condivisione



DataOra senza side-effect con cond.

public class DataOraNoSideEffectCondiv {private DataNoSideEffect data;private OraNoSideEffect ora;public DataOraNoSideEffectCondiv(DataNoSideEffect d, O raNoSideEffect o) {

data = d; ora = o;}public DataOraNoSideEffectCondiv(int g, int m, int a, int h , int min, int sec) {

this( new DataNoSideEffect(g,m,a), new OraNoSideEffect( h,m,s) );}// data e’ di classe DataNoSideEffect, il cliente non puo’ mo dificarla!public DataNoSideEffect getData() { return data; }...public DataOraNoSideEffect setData(DataNoSideEffect d) {

// No side-effect: ritorno un nuovo oggetto// Con condivisione: this e result condividono l’oggetto// puntato dall’attributo ’ora’// d e’ di classe DataNoSideEffect, il cliente non puo’ modif icarla!DataOraNoSideEffectCondiv result = new DataOraNoSideEff ectCondiv( d, ora );return result;

}...public boolean equals(Object o) { ... }public int hashCode() { ... }

} //:˜



DataOra con side-effect senza cond.

public class DataOraSideEffectNoCondiv implements Clone able {private DataSideEffect data;private OraSideEffect ora;public DataOraSideEffectNoCondiv(DataSideEffect d, Ora SideEffect o) {

// Devo clonare gli oggetti passati come argomento// per evitare possibili condivisioni che possono// causare side-effect non desiderati!data = (DataSideEffect)d.clone();ora = (OraSideEffect)o.clone();

}public DataOraSideEffectNoCondiv(int g, int m, int a, int h , int min, int sec) {

this( new DataSideEffect(g,m,a), new OraSideEffect(h,m, s) );}

// data e’ di classe DataSideEffect:// Devo ritornare un clone, per evitare che// il cliente possa fare side-effect su this!public DataSideEffect getData() {

return (DataSideEffect)data.clone();}...public void setData(DataSideEffect d) {

data = (DataSideEffect)d.clone();}...public boolean equals(Object o) { ... }public int hashCode() { ... }

// Necessario, per evitare side-effect// non desiderati!public Object clone() { ... }

} //:˜T. Mancini & M. Scannapieco S.P.1 – La fase di Progetto – February 18, 2008 – p. 25/65


Esercizio

Realizzare la classe DataOra secondo gli schemi “senza side-effect e senza condivisione” e“con side-effect e con condivisione”, e analizzarne criticamente gli svantaggi rispetto agliapprocci appena visti.



La specifica realizz. delle strutture dati

Le specifiche realizzative delle strutture dati progettate avranno lo schema seguente:

SpecificaStrutturaDati <NomeStrutturaDati>attributi

// attributi della struttura datischema realizzativo

// lo schema realizzativo adottatooperazioni

...

uguaglianzao1 e o2 sono dichiarati uguali se e solo se...

FineSpecifica



La specifica realizz. delle strutture dati

Nel caso la struttura dati progettata realizza un tipo di dato:

– Deve essere data la specifica delle operazioni già isolate in fase di Analisi, e quindipresenti nella specifica concettuale del tipo di dato;

– Nel caso durante il progetto si è scelto di rappresentare i valori del tipo medianteattributi diversi da quelli concettuali (definiti nella specifica concettuale del tipo), vannopreviste operazioni aggiuntive, che permettano di calcolare il valore degli attributiconcettuali a partire dal valore di quelli realizzativi.

Ad esempio, nella specifica realizzativa della struttura dati Ora (che realizza il tipo didato Ora), dato che si è scelto di rappresentare i valori del tipo mediante un singoloattributo sec : int, vanno previste le operazioni ore() : int, minuti() : int, secondi() : int(con la relativa specifica) che permettano di calcolare i valori degli attributi concettualiisolati durante l’Analisi a partire dall’attributo sec.

– Vanno previsti eventuali costruttori, come fatto nella specifica concettuale del tipo, il cuicomportamento viene adattato agli attributi realizzativi;

– È possibile specificare ulteriori operazioni che si rendono necessarie in questa fase(ad es. quelle di supporto alle altre).

Il contenuto della specifica di ogni singola operazione è comune a quello delle specifichedelle operazioni di classe e use-case, e verrà descritto in seguito.



Esempio: Spec. della strutt. dati DataOra

SpecificaStrutturaDati DataOraattributi

data : Data, ora : Oraschema realizzativo

Con side-effect, senza condivisione

operazioni// quelle della specifica del tipo di dato prodotta in analis i,// con ovvie modifiche alle segnature,// piu’ eventuali operazioni di supporto...

uguaglianzao1 e o2 sono dichiarati uguali se e solo se o1.data = o2.data eo1.ora = o2.ora

FineSpecifica



Il tipo di attributi multivalore e opzionali

– Un attributo multivalore di tipo T con molteplicità massima maggiore di 1, ad es. attr :T {n,m} (con m > 1), sarà trattato come se il suo tipo UML fosse Insieme(T). Nel casole molteplicità siano diverse da {0,*}, vanno ovviamente verificate le condizioni diammissibilità (perché il corrispondente Java del tipo Insieme(T) è semanticamente piùesteso, ad es., del tipo UML T {1,10});

– Un attributo opzionale attr : T {0,1} può essere trattato allo stesso modo di un attributodi molteplicità {1,1}. Tuttavia dobbiamo decidere come rappresentare l’eventualità cheil valore sia indefinito. A tale scopo possono essere usati diversi approcci:

– Aggiungere un attributo attrEsistente : boolean che vale true se e solo se il valoredi attr è significativo;

– Se T è una classe Java, possiamo usare la costante null per rappresentare il fattoche il valore di attr non è significativo;

– Se T è un tipo base Java, possiamo usare la corrispondente classe wrapper(ovvero Integer per int, Double per double, . . . ) e ricondurci al caso precedente(un campo di un tipo base Java non può essere null!).



Decisioni su tipi e strutture dati

Le decisioni su:

– corrispondenza tra tipi UML e tipi Java,

– progetto di strutture dati ad-hoc (con relativa specifica realizzativa)

confluiscono in una tabella riassuntiva ed in un insieme di specifiche delle strutture datiprogettate, secondo lo schema seguente:

Tipo UML Corrispondenza in Java Note

. . . . . . . . .

Nel campo Note sarà dichiarato:

– nel caso il tipo Java sia semanticamente più esteso del tipo UML, come siverificheranno le precondizioni

– nel caso il tipo sia enumerativo, qual è l’intervallo di interi che si utilizza perrappresentare i valori del tipo, e come si verificheranno le precondizioni.



Decisioni su tipi e strutture dati (cont.)

Esempio.

Tipo UML Corrispondenza in Java Note

intero int –reale double –

intero > 0 int con verifica delle precondizioni lato server[1..8] int con verifica delle precondizioni lato server

{Lun, . . . , Dom } int da 1 a 7, con verifica delle prec. lato serverDataOra DataOra da realizzare, v. spec. realizz.

Insieme(int) InsiemeArrayOmogeneo di Integerintero {1..*} InsiemeArrayOmogeneo di Integer, con verif. prec. lato serverreale {0,1} Double l’attributo può essere null

reale > 0 {0,1} Double l’attr. può essere null, ver. prec. lato serverLista(. . . ) ListaArrayOmogenea disponibile

. . . . . . . . .



Spec. realizz. di classi e use-case

Per ogni classe con operazioni (quelle già specificate in fase di Analisi più tutte quelle chesaranno aggiunte in fase di progetto, cf. seguito) e per ogni use-case va definita unaspecifica realizzativa. Lo schema è il seguente:

SpecificaClasse <NomeClasse> (oppure SpecificaUseCase < NomeUseCase>)specifica operazione 1...specifica operazione n

Fine Specifica

La specifica delle singole operazioni segue le stesse regole per ogni tipo di specificarealizzativa (di struttura dati, di classe, di use case).



La spec. realizz. delle operazioni

La fase di Progetto deve occuparsi di come il sistema fornirà le funzionalità isolate nella fasedi Analisi. Per questo motivo, di ogni operazione di classe, di struttura dati, o diuse-case, va fornita la specifica realizzativa , che oltre a fissarne la segnatura, forniscel’algoritmo da implementare (nella fase di Realizzazione) per realizzarla.

Si osservi che, a differenza di quanto avviene nella fase di Analisi, la specifica di unaoperazione non dichiara quali sono le post-condizioni, ma l’algoritmo da usare perrispettarle. L’algoritmo sarà descritto in modo astratto e sintetico, mediante pseudo-codice,di modo che sia traducibile in un programma in modo semplice e senza ambiguità (esempi didescrizione di algoritmi saranno dati in seguito).

Dato che gli algoritmi utilizzati possono avere impatto su altre scelte progettuali (ad es. sulleresponsabilità delle classi nelle associazioni, v. seguito), le decisioni su quali adottare nonpuò essere ritardata alla fase di Realizzazione.

La specifica realizzativa di un’operazione segue lo schema seguente:nomeOperazione(arg1:Tipo1, ..., arg:TipoN) : TipoRitorn o

pre: Le condizioni che devono essere verificate affinche’l’operazione si comporti correttamente

algoritmo:L’algoritmo da implementare in fase di Realizzazione



Specifica della struttura dati DataOra

SpecificaStrutturaDati DataOraattributi

data : Data, ora : Oraschema realizzativo


operazioni// quelle della specifica prodotta in analisi,// con ovvie modifiche alle segnature,// piu’ eventuali operazioni di supportodomani() // nessun tipo di ritorno!

pre: nessunaalgoritmo: viene invocato this.data.domani()

primaDi(do : DataOra) : boolean {pre : nessunapost : se this.data.primaDi(do.data), allora result = true ;

altr. se do.data.primaDi(do.data), allora result = false;altr. se this.ora.primaDi(do.ora), allora result = true;altr. result = false.

FineSpecifica



Specifica della struttura dati Data

SpecificaStrutturaDati Dataattributi

g : int, m : int, a : intschema realizzativo


operazioni// quelle della specifica prodotta in analisi,// con ovvie modifiche alle segnature,// piu’ eventuali operazioni di supportoData(gg: int, mm: int, aa: int) : Data

pre: 1<=gg<=31, 1<=mm<=12, aa>0, ... (cf. spec. tipo dato Da ta prodotta in Analisi)algoritmo: viene creato result con result.g = gg, result.m = mm, result.a = aa

domani() // nessun tipo di ritorno!pre: nessunaalgoritmo: se m in {1,3,...}

se g < 31, allora this.g = this.g+1altrimenti,

se m < 12,allora this.g = 1 e this.m = this.m+1

altrimenti this.g = 1, this.m = 1, this.a = this.a+1...

primaDi(d : Data) : booleanpre: nessunaalgoritmo: se this.anno < d.anno, allora result = true;

altrimenti ...FineSpecifica



Specifica della struttura dati Ora

SpecificaStrutturaDati Oraattributi

sec : intschema realizzativo


operazioni// quelle della specifica prodotta in analisi,// con ovvie modifiche alle segnature,// piu’ eventuali operazioni di supporto:// esempio:avantiUnOra() // Nessun tipo di ritorno!

pre: nessunaalgoritmo: this.sec = (this.sec + 3600) % (3600 * 24)

primaDi(o : Ora) : booleanpre: nessunaalgoritmo: result = (this.sec < o.sec)

// Dato che gli attributi realizzativi sono diversi// da quelli concettuali (ore, minuti, secondi), devo preve dere operazioni// che permettano di calcolare il valore per questi ultimiore() : int

pre: nessunaalgoritmo: result = parteInteraInferiore( sec/3600 )

minuti(): intpre: nessunaalgoritmo: result = parteInteraInferiore((sec % 3600)/60 )

secondi(): intpre: nessunaalgoritmo: result = (sec % 60)

FineSpecifica



La spec. real. delle operaz.: osservazioni

In generale, va prevista una specifica realizzativa per ogni struttura dati (che realizza untipo), per ogni classe con operazioni, e per ogni use-case.Tuttavia, in alcuni casi pratici, l’algoritmo che si decide di usare per una operazione èparticolarmente semplice ed è suggerito univocamente dalla specifica data in fase di Analisi.In questi casi, la specifica realizzativa dell’operazione può essere omessa , dato che nonaggiungerebbe alcuna informazione interessante.

Ad esempio, la specifica del costruttore della struttura dati Data e le operazioni primaDi()delle strutture dati DataOra e Data sono molto simili a quelle delle operazioni primaDi() deitipi di dato DataOra e Data prodotte in fase di analisi, e possono quindi essere omesse.Ciò non avviene invece per la specifica della struttura dati Ora, che si è scelto di realizzare inmodo diverso (un campo sec, invece di tre campi, ore, min, sec).La specifica può essere omessa anche per le operazioni aggiunte in fase di Progetto il cuicomportamento è standard (cf. seguito).



Ristrutturazione delle gerarchie IS-AÈ possibile che le gerarchie IS-A presenti nel diagramma delle classi concettuale debbanoessere ristrutturate. Questo per diversi motivi:

– Una gerarchia UML può essere complete , e in tal caso la classe base va resaabstract per evitare che si possano creare sue istanze dirette.

– Una gerarchia UML può essere non-disjoint : in tal caso si è già prevista unasottoclasse comune alle classi derivate. Tuttavia, Java non supporta l’ereditarietàmultipla, e quindi tale classe non può essere realizzata. La gerarchia is-a va alloraristrutturata in modo tale che le sottoclassi siano tutte disjoint.

– Una classe UML può essere base di diverse gerarchie . Tale situazione comportaintrinsecamente vincoli di non-disjointness che devono essere gestiti come al puntoprecedente.

– Alcune delle sottoclassi di una classe UML rappresentano in realtà degli stati deglioggetti della classe base, che in fase di Analisi abbiamo creduto opportunodistinguere, ad es. perchè alcune proprietà (attributi e/o associazioni) hanno sensosolo per oggetti in questi stati. Dato che un oggetto Java non può cambiare classedurante il suo ciclo di vita, tali sottoclassi andranno fuse con la superclasse, e leproprietà aggiuntive definite in esse (attributi o associazioni) vanno gestite in modooculato. In particolare, tale migrazione verso l’alto delle proprietà, comporta che le loromolteplicità minime diventino tutte 0. Inoltre in alcuni casi è necessario definire unagestione particolare per esse (cf. la gestione delle proprietà di classe descritta inseguito).

Queste decisioni andranno a confluire nel diagramma delle classi realizzativo.T. Mancini & M. Scannapieco S.P.1 – La fase di Progetto – February 18, 2008 – p. 39/65


Esempio: Ristrutt. gerarchie IS-A

Sia dato il seguente diagramma delle classi concettuale:

{disj,compl}

nome: Stringa

Maschio

Femmina

Persona

Studente Lavoratore



Esempio: Ristrutt. gerarchie IS-A (cont.)

Durante la fase di progetto viene ristrutturato in:

nome: Stringa

StudMaschio LavMaschio StudFemm LavFemm

StLavMasch StLavFemm

Maschio Femmina

Persona (abstract)

Si osservi come le gerarchie sono state tutte trasformate in semplici generalizzazioni , eche la classe base è dichiarata abstract .



Sottoclassi che rappresentano stati

Si consideri il seguente frammento di diagramma delle classi concettuale (relativoall’esercizio “Catena di officine”):

È evidente come la sottoclasse RiparazTerm rappresenta uno tra i possibili stati in cuipossono trovarsi gli oggetti di classe Riparazione e che i singoli ogggetti attraverseranno varistati, secondo l’ordine definito dal seguente diagramma degli stati e transizioni (prodotto infase di Analisi):



Sottoclassi che rappresentano stati (cont.)

Dato che gli oggetti Java non possono cambiare classe durante il loro ciclo di vita (passandodalla classe Riparazione a RiparazTerm), in fase di Progetto fondiamo insieme le due classi(in un’unica classe Riparazione), portando le molteplicità dell’attributo dataOraRic a 0..1, eimponendo opportune politiche circa la gestione di tale attributo (cf. progetto del diagrammadegli stati e transizioni e gestione delle proprietà delle classi): in particolare, tra le altre cose,dobbiamo imporre che:

– Al momento della nascita di un oggetto r di classe Riparazione, il valore perr.dataOraRic è indefinito;

– Per ogni oggetto r di classe Riparazione, il valore per l’attributo r.dataOraRic puòpassare da indefinito a definito, ma non viceversa. Infine, una volta che tale valorediventa definito, non può essere più modificato.

Tali vincoli prendono il nome di vincoli sull’evoluzione delle proprietà mutabili delle classi (odelle strutture dati) e verranno illustrati in dettaglio in seguito.



Gestione delle proprietà di classi UML

– In generale le proprietà (attributi e associazioni) di un oggetto UML evolvono inmaniera arbitraria durante il suo ciclo di vita.

– Esistono però alcuni casi particolari che vanno presi in considerazione nella fase diprogetto.Definiamo una proprietà

– non nota alla nascita , se non è completamente specificata nel momento in cuinasce l’oggetto;

– immutabile , se, una volta che è stata specificata, il suo valore resta invariato pertutto il ciclo di vita dell’oggetto.

Tali caratteristiche degli attributi e delle associazioni sono da evincersi dal documentodei requisiti, oppure sono conseguenti di altre scelte effettuate in fase di Analisi o diProgetto.



Gestione d. proprietà di classi UML (cont.)

Esempio. Per la classe UML Persona, si ha:

Persona Citta

nome: Stringa nataA nome: Stringa

cognome: Stringa 1..1

coniugato: bool

nome: proprietà immutabile, nota alla nascita

cognome: proprietà immutabile, nota alla nascita

nataA: proprietà immutabile, nota alla nascita

coniugato: proprietà mutabile, non nota alla nascita



Assunzioni di default

– Distinguiamo innanzitutto fra:

– proprietà singole , ovvero attributi (di classe o di associazione) e associazioni (omeglio, ruoli) con molteplicità 1..1;

– proprietà opzionali , ovvero attributi di classe o di associazione) e associazioni (omeglio, ruoli) con molteplicità 0..1;

– proprietà multiple , tutte le altre.

– Le nostre assunzioni di default, ovvero che valgono in assenza di ulteriori elementi,sono le seguenti:

– tutte le proprietà sono mutabili ;

– le proprietà singole sono note alla nascita ;

– le proprietà opzionali e multiple non sono note alla nascita .



Evoluzione delle proprietà mutabili

Per quanto riguarda le proprietà mutabili , potrebbero esistere alcune restrizioni sulla loroevoluzione.Esempio.

nome: Stringa haVisitato nome: Stringa

cognome: Stringa 0..*

coniugato: bool

eta:intero>0

Persona Citta

– Il valore dell’attributo eta della classe Persona può solo crescere;

– I link dell’associazione haVisitato possono essere creati ma non eliminati.

Un altro frequente esempio riguarda la possibilità di creare link solo se altre condizioni sonorispettate (ad esempio, non è possibile prenotare un volo aereo per un giorno trascorso).



Gestione delle proprietà di classi UML

Ovviamente, in presenza di motivi validi (v. esempio precedente), possiamo operare sceltediverse da quelle di default.

Riassumeremo tutte le nostre scelte differenti da quelle di default nel diagramma delleclassi realizzativo (descritto in seguito).



Progetto dei diag. degli stati e trans.

Per quanto riguarda il diagramma degli stati e delle transizioni corrispondente ad una certaclasse UML, dobbiamo effettuare alcune scelte importanti:

– Come rappresentare lo stato corrente dei singoli oggetti

– Come fare in modo che gli oggetti ricevano gli eventi

– Come fare in modo che gli oggetti possano cambiare stato a fronte di un evento, ecome possano essere controllate le condizioni ed essere eseguite le azionicorrispondenti alle transizioni.



La rappresentazione degli stati

– Ci dobbiamo innanzitutto chiedere se sia possibile inferire lo stato di un oggetto Javadai valori degli attributi di classe (o combinazioni di questi.Esempio. Lo stato di un oggetto di classe Riparazione (cf. esempio “Catena diofficine” richiamato in precedenza) può essere inferito dall’esistenza o meno di unvalore per l’attributo dataOraRic: se tale attributo è definito, l’oggetto si troverà nellostato Terminata, altrimenti si troverà nello stato InCorso.

– In caso ciò non sia possibile, abbiamo bisogno di uno o più attributi, aggiuntivi rispettoa quelli già definiti, che denotano lo stato corrente degli oggetti della classe.

– Per tali attributi sono possibili varie scelte. Scelte tipiche, per la rappresentazione di undiagramma con n stati, sono:

– un attributo di tipo int , i cui valori ammissibili sono compresi fra 1 e n,

– n attributi di tipo boolean , di cui, ad ogni istante, esattamente uno avrà valoretrue .

Nota: I macrostati possono di solito non essere rappresentati esplicitamente.



Esempio: rappr. degli stati in Java

Consideriamo il diagramma degli stati associato alla classe Bambino visto nelle slides diAnalisi:

Tabella di codifica degli stati mediante un nuovo attributo stato : int.

Rappresentazione in Javatipo var. int

Stato nome var. stato

Iniziale valore 1

HaCodice valore 2

InizialeIscritto valore 3

Problematico valore 4

NonProblematico valore 5



Progetto del diag. d. stati in Java (cont.)

Per quanto riguarda le altre decisioni da prendere:

– Si definisce un’operazione di classe azione() per ogni azione azione (se questa nonera stata già definita in fase di Analisi);

– Si definisce un’operazione di classe cond() : boolean per ogni condizione cond (sequesta non era stata già definita in fase di Analisi);

– Si definisce, per ogni evento evento, una nuova operazione di classe evento(), senzaargomenti di input né tipo di ritorno: tale operazione, la cui specifica realizzativa èbanale e può essere omessa, nel caso lo stato corrente dell’oggetto di invocazioneabbia in uscita una transizione verso lo stato s contrassegnata da evento[cond]/azione,controlla che la condizione cond sia verificata (per mezzo dell’operazione cond(), ed inquesto caso invoca l’operazione azione() e porta lo stato corrente dell’oggetto diinvocazione ad s.



Progetto del diag. d. stati in Java (cont.)

Il comportamento delle operazioni evento() segue quindi sempre lo stesso schema, che è ilseguente:

evento()pre: nessunaalgoritmo:

Se lo stato corrente di this non ha una transizione in uscitaetichettata dall’evento ’evento’, allora ritorna senza fa re nulla;

Individua la transizione ’evento[cond]/azione’ da effett uaree il conseguente stato di destinazione (cf. diag. degli stat i);

se cond() = true {azione();stato = lo stato destinazione della transizione

}

Alcune volte, cf. fase di Analisi, è possibile avere eventi che dipendono da parametri (ad es.l’evento dial(n) nel diagramma degli stati relativo ad un telefono a scheda). I metodi relativi atali eventi dovranno, ovviamente, avere degli opportuni argomenti di input.

Di queste (nuove) operazioni va data la specifica (se non banale, e ad eccezione di quelleche denotano gli eventi). Esse inoltre andranno a confluire nel diagramma delle classirealizzativo.



Visibilità di attrib. e operaz. di classe

Al fine di aumentare l’information hiding, vanno decise quali proprietà (attributi e operazioni)delle classi possono essere accessibili dall’esterno della classe nella quale sono definite equali no.I livelli di visibilità possibili sono tre:

pubblico La proprietà è accessibile nella classe dove è definita e da ogni altra classe o usecase

protetto La proprietà è accessibile solo nella classe dove è definita e nelle sue sottoclassi

privato La proprietà è accessibile solo nella classe dove è definita



Visib. di attrib. e operaz. di classe (cont.)

I criteri che vanno usati per decidere il livello di visibilità delle proprietà sono i seguenti:

Attributi.

– Gli attributi definiti in fase di Analisi sono pubblici (attenzione: ciò non vuol dire chesaranno dichiarati public nella corrispondente classe Java!, cf. fase diRealizzazione).

– Gli attributi aggiunti in fase di Progetto (ad es. l’attributo che denota lo stato correntedegli oggetti di una classe con diagramma degli stati, oppure gli attributi booleaniutilizzati per distinguere quando un attributo (originariamente opzionale) è significativo,ecc.) sono privati (o protetti se è necessario accedervi da almeno una sottoclasse).



Visib. di attrib. e operaz. di classe (cont.)

Operazioni.

– Le operazioni definite in fase di Analisi sono pubbliche .

– Per le operazioni aggiuntive definite in fase di Progetto:

– Le operazioni di supporto (ausiliarie), aggiunte durante la specifica realizzativadelle operazioni di classe, sono private (o protette );

– Le operazioni che rappresentano eventi saranno pubbliche se gli eventi sonoesogeni (ovvero provengono dal di fuori della classe), mentre saranno private (oprotette ) se gli eventi sono endogeni, ovvero vengono generati dall’interno (ades. mediante l’invocazione di altre operazioni, come l’aggiornamento del valore diun attributo);

– Le operazioni che rappresentano azioni del diagramma degli stati sono di solitoprivate (o al limite protette ), perché si vuole fare in modo che vengano invocatesolo in occasione di transizioni. Nel caso invece tali operazioni servono anche adaltri scopi, e quindi devono essere accessibili dall’esterno ed invocabili anche inaltre occasioni, saranno dichiarate pubbliche .

– Discorso analogo vale per le operazioni che verificano condizioni.

– In generale, per stabilire se una proprietà debba essere dichiarata protetta invece cheprivata, vanno considerate le specifiche realizzative prodotte, da dove si possonoevincere le necessità, da parte delle sottoclassi, di accedere tale proprietà.

I livelli di visibilità scelti confluiscono nel diagramma delle classi realizzativo.



Progetto di associazioni: responsabilità

Prima di realizzare una classe UML che è coinvolta in un’associazione, ci dobbiamochiedere se la classe ha responsabilità sull’associazione.

Diciamo che una classe C ha responsabilità sull’associazione A, quando, per ognioggetto x che è istanza di C vogliamo poter eseguire opportune operazioni sulle istanze di Aa cui x partecipa, che hanno lo scopo di:

– conoscere l’istanza (o le istanze) di A alle quali x partecipa,

– aggiungere una nuova istanza di A alla quale x partecipa,

– cancellare una istanza di A alla quale x partecipa,

– aggiornare il valore di un attributo di una istanza di A alla quale x partecipa.



Prog. di assoc.: responsabilità (cont.)

Per ogni associazione A, deve esserci almeno una delle classi coinvolte che haresponsabilità su A.

I criteri per comprendere se una classe C ha responsabilità sull’associazione A sono iseguenti:

1. esiste una parte (ad es., una frase) nel documento dei requisiti , da cui si evince cheper ogni oggetto x che è istanza di C vogliamo poter eseguire almeno una delleoperazioni di “conoscere, aggiungere, cancellare, aggiornare”;

2. esiste un’operazione in una classe o in uno use case per la quale non è possibilerealizzare il corrispondente algoritmo senza che la classe C abbia tale responsabilità;

3. la responsabilità è logicamente implicata dai vincoli di molteplicità dell’associazione A(ovvero la classe partecipa all’associazione con un vincolo diverso da 0..*).



Molteplicità e responsabilità

– L’esistenza di alcuni vincoli di molteplicità di associazione ha come conseguenzal’esistenza di responsabilità su tali associazioni.

– In particolare, quando una classe C partecipa ad un’associazione Ass con un vincolodi molteplicità diversa da 0..*, la classe C ha necessariamente responsabilità suAss.

– Il motivo risiede nella necessità di poter controllare che il numero di link di tipo Ass acui partecipano gli oggetti della classe C sia consistente con i vincoli di molteplicità(verifica del rispetto dei vincoli di molteplicità lato server).



La tabella delle responsabilità

Le decisioni relative alle classi responsabili di ogni associazione vengono riassunte nellatabella delle responsabilità, che ha lo schema seguente:

Associazione 1

Classe 1 Sì/No motivi. . .Classe 2 Sì/No motivi. . .

Associazione 2

Classe 1 Sì/No motivi. . .Classe 2 Sì/No motivi. . .

. . .

e confluiranno nel diagramma delle classi realizzativo (cf. seguito).

Nota. per ogni associazione deve esserci almeno un “Sì” nella corrispondente tabelladelle responsabilità.



Responsabilità dei ruoli

Quanto detto vale anche per il caso in cui l’associazione coinvolga più volte la stessa classe.In questo caso il concetto di responsabilità si attribuisce ai ruoli , piuttosto che alle classi.

Azienda

0..1

Holding

+controllante

+controllata0..1

Ad esempio, la classe Azienda potrebbe avere la responsabilità sull’associazione holding,solo nel ruolo controllata. Questo significa che, dato un oggetto x della classe Azienda,vogliamo poter eseguire operazioni su x per conoscere l’eventuale azienda controllante, peraggiornare l’azienda controllante, ecc.



Il diagramma delle classi realizzativo

Molte delle decisioni prese in fase di progetto confluiscono in un nuovo diagramma delleclassi, raffinamento di quello prodotto in fase di Analisi.

Tale diagramma contiene tutte le informazioni necessarie alla realizzazione del codice, leuniche scelte che rimangono da fare sono scelte programmative.

Nota. Il diagramma delle classi realizzativo è peggiore del diagramma delle classiconcettuale, in quanto si sono effettuate delle scelte influenzate da tecnicalità realizzative.



Il diag. delle classi realizzativo (cont.)

In particolare, il diagramma delle classi realizzativo sarà derivato da quello concettuale eterrà conto dei seguenti aspetti:

Decisioni relative alla realizzazione dei tipi Gli attributi delle classi e delle associazioni avrannoper tipo il tipo base o la classe Java (di libreria o che realizza una struttura dati ad-hoc)scelti in fase di progetto;

Ristrutturazione delle gerarchie IS-A Le gerarchie IS-A saranno sostituite dalle lororistrutturazioni, e le eventuali ulteriori classi definite da questa attività sarannoaggiunte;

Attributi e operazioni aggiuntive delle classi Tutti gli attributi e le operazioni di classe definite inquesta fase (attributo dello stato corrente per classi che hanno un diagramma deglistati, operazioni di supporto, relative al progetto dei diagrammi degli stati, ecc.)saranno aggiunte al diagramma.

Visibilit a degli attributi e delle operazioni delle classi Ogni proprietà di classe (attributo ooperazione) viene contrassegnata con il livello di visibilità scelto (pubblico, protetto, oprivato), anteponendo, rispettivamente, un ‘+’, ‘#’, oppure ‘−’ al nome.



Il diag. delle classi realizzativo (cont.)

Gestione delle propriet a Gli attributi delle classi e associazioni immutabili sarannocontrassegnati da “〈〈immutable〉〉” (abbreviabile in “〈〈imm〉〉”), quelli mutabili da“〈〈mutable〉〉” (abbreviabile in “〈〈mut〉〉”). Le decisioni circa le proprietà note o menoalla nascita diverse da quelle di default, oppure circa restrizioni sulla loro evoluzioneverranno segnalate mediante opportuni commenti UML.

Responsabilit a delle classi sulle associazioni Nel caso di associazioni a responsabilità singolasenza attributi, l’arco di associazione presenta una freccia che ne indica l’unico versodi percorribilità (“----> ”).Inoltre, le associazioni binarie senza attributi a responsabilità singola possono essereconvertite in aggregazioni, In questo modo modelliamo l’associazione come unarelazione “has-a”: gli oggetti della classe che ha responsabilità hanno o possono avere(come parte, cioè come se fosse un attributo) riferimenti diretti ad uno o più oggettidell’altra classe (in base al vincolo di molteplicità). Un’aggregazione si denotaaggiungendo un rombo (non riempito) nel punto di congiunzione dell’arco diassociazione con la classe responsabile (“<>---> ”).



L’output della fase di Progetto

Riassumendo, l’output della fase di Progetto sarà costituito da:

– La tabella di corrispondenza dei tipi UML in tipi base o strutture dati Java, con relativedecisioni circa la verifica delle precondizioni (preferibilmente lato server) ed altreannotazioni

– Le specifiche realizzative delle strutture dati

– Le specifiche realizzative degli use-case

– Le specifiche realizzative delle classi con eventuali decisioni circa il progetto deidiagrammi degli stati e transizioni

– La tabella delle responsabilità delle classi sulle associazioni, dove vengono illustrati imotivi che hanno portato alle diverse decisioni

– Il diagramma delle classi realizzativo


Date post:	15-Feb-2019
Category:	Documents
Upload:	nguyentu
View:	216 times
Download:	0 times

Università degli Studi di Roma “La Sapienza” Facoltà di...

Documents