Sei sulla pagina 1di 111

Diagrammi strutturali in UML

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 1

Riferimenti
Ian Sommerville, Ingegneria del Software, capitolo 8, 14 Martin Fowler, UML Distilled, capitoli 3, 5 Carlo Savy, Da C++ a UML, capitolo 34

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 2

Tipi di Modello in UML 2


UML 2 possiede 13 differenti tipi di diagrammi, appartenenti a tre categorie: Diagrammi Comportamentali, quali use-case diagrams, activity diagrams, state machine diagrams Diagrammi di Interazione, per modellare interazioni fra entit del sistema, quali sequence diagrams e communication diagrams. Diagrammi Strutturali, che modellano lorganizzazione del sistema, quali class diagrams, package diagrams, e deployment diagrams. Tali diagrammi rappresentano i deliverables di diverse fasi del ciclo di vita del software, tra cui attivit di analisi dei requisiti e attivit di progettazione, sia di alto che di basso livello
3

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 3

Class diagram
Il pi diffuso diagramma compreso in UML il diagramma delle classi Si tratta di un diagramma statico che pu essere utilizzato:
Per la modellazione concettuale del dominio di un problema Per la modellazione delle specifiche richieste ad un sistema Per modellare il progetto del sistema Per modellare limplementazione (object-oriented) di un sistema software
4

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 4

Class Diagram
I concetti fondamentali di un class diagram sono estensioni dei concetti fondamentali del paradigma object-oriented
Nel seguito verr presentato il class diagram nelle sue varie accezioni, fino alla modellazione dellimplementazione di sistemi object-oriented

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 5

Aspetti principali
I principali elementi dei class diagram sono:
Classi
Rappresentanti i tipi di dati presenti in un sistema

Associazioni
Rappresentano i collegamenti fra istanze di classi

Attributi
Sono i dati semplici presenti nelle classi e nelle loro istanze

Operazioni
Rappresentano le funzioni svolte dalle classi e dalle loro istanze

Generalizzazioni
Raggruppano le classi in gerarchie di ereditariet

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 6

Classi
Una classe semplicemente rappresentata da un rettangolo con il nome della classe allinterno.
Rectangle Rectangle
getArea resize

Rectangle
height width

Rectangle
height width getArea resize

Rectangle
height: int width: int getArea(): int resize(int,int)

Informazioni soppresse

La signature completa di unoperazione :


operationName(parameterName: parameterType ): returnType
Ingegneria del Software Modellazione 7

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 7

Attributi
visibilit nome molteplicit: tipo = default {propriet}
Sono consentiti tre livelli di visibilit:
+ Livello pubblico: L'utilizzo viene esteso a tutte le classi # Livello protetto: L'utilizzo consentito soltanto alle classi che derivano dalla classe originale - Livello privato: Soltanto la classe originale pu utilizzare gli attributi e le operazioni definite come tali.

Il nome dellattributo lunico parametro necessario Il tipo dellattributo pu essere un tipo standard (int, double, char, etc) oppure il nome di una classe definita nello stesso diagramma (in tal caso forse lattributo andrebbe indicato con unassociazione ) Default rappresenta il valore di default dellattributo
Ingegneria del Software Modellazione 8

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 8

Attributi
visibilit nome molteplicit: tipo = default {propriet}
La molteplicit indica il quantitativo degli attributi (ad esempio la dimensioni per un array). Tramite la molteplicit possibile indicare come attributi degli array o matrici. Il valore di default 1. Alcuni valori possibili sono:
1 (uno e uno solo). E il valore di default 0..1 (al pi uno) * (un numero imprecisato, eventualmente anche nessuno; equivalente a 0..*) 1..* (almeno uno)

Gli elementi di una molteplicit sono considerati come un insieme. Se essi sono dotati anche di ordine si aggiunge lindicazione {ordered}. Se sono possibili valori duplicati si aggiunge lindicazione {nonunique}

{propriet} rappresenta caratteristiche aggiuntive dellattribute (ad esempio la sola lettura) Esempio: name: String [1] = "Untitled" {readOnly}
Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 9

Metodi
visibilit nome (lista parametri) : tipo-ritornato {propriet}
La visibilit e il nome seguono regole analoghe a quelle degli attributi. Lista parametri contiene nome e tipo dei parametri della funzione, secondo la forma:

direzione nome parametro: tipo = valore-di-default


direzione: input (in), output (out) o entrambi (inout). Il valore di default in nome, tipo e valore di default sono analoghi a quelli degli attributi Tipo-ritornato il tipo del valore di ritorno: dovrebbe essere un tipo appartenente ad una classe standard

Esempio:
+ balanceOn (date: Date) : Money

Ingegneria del Software Modellazione

10

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 10

Associazioni
Unassociazione rappresenta una relazione (fisica o concettuale) tra classi
Esempio: Persona possiede Automobile
Possiede > Persona Automobile

Il verso dellassociazione indicato in figura indica in che direzione deve essere letta lassociazione
In questo caso indica che la Persona a posseder lAutomobile e non lAutomobile a possedere la Persona!

In alternativa, si pu indicare il ruolo di uno dei due estremi dellassociazione +Proprietario


Persona Automobile

Ingegneria del Software Modellazione

11

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 11

Verso di navigazione
Verso di navigazione di unassociazione
Il verso di navigazione uninformazione utile soprattutto in fase di progetto di dettaglio Indica in quale direzione possibile reperire le informazioni
Possiede > Persona Automobile

Nellesempio, nota una persona possibile sapere quali sono le automobili che possiede (se ne possiede) Viceversa, non possibile conoscere il possessore di una data automobile Non ci sono, per, indicazioni sul quantitativo di automobili possedute, n sul numero di proprietari di un automobile (da questo diagramma non possiamo sapere se si tratti di informazioni non note o di informazioni soppresse) Di solito, il verso di navigazione rappresenta una scelta di progetto, per cui non presente nei diagrammi concettuali
12

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 12

Molteplicit delle associazioni


La molteplicit delle associazioni indica quante istanze di una classe possono essere associate con una singola istanza di unaltra classe
Possiede > Persona Automobile 1..*

Uno ed uno solo

Nellesempio,

una Persona possiede almeno una Automobile


evidentemente le persone che non possiedono Automobile non fanno parte del problema in oggetto

UnAutomobile pu essere posseduta da una e una sola Persona


Evidentemente, non nel problema in oggetto il mantenimento di informazioni riguardo i proprietari di automobili di seconda, terza mano, etc.

Questesempio si configura come associazione uno a molti (una Persona, molte Automobili)
13

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 13

Associazioni molti a molti


Associazioni molti-a-molti
Uno studente pu conseguire un numero potenzialmente non limitato di esami Un esame pu essere conseguito da un numero potenzialmente non limitato di studenti Possono esserci studenti che non hanno conseguito esami Possono esserci esami non conseguiti (ancora) da nessuno studente
Consegue > Studente * * Esame

Se avessimo voluto modellare il caso in cui uno studente era considerato solo dal momento del conseguimento del primo esame, allora sarebbe stato
Consegue > Studente * 1..* Esame

Ingegneria del Software Modellazione

14

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 14

Associazioni uno a uno


Uno-a-uno
Ogni studente ha uno e un sol badge

Non possibile modellare, in caso di smarrimento e rilascio di un nuovo badge, lelenco di tutti I badge avuti da uno studente nel tempo
Un badge identifica uno e un solo studente
Studente 1 1 Badge

Se avessimo voluto considerare anche studenti privi di badge, allora la soluzione sarebbe stata:
Studente 1 0..1 Badge

Ingegneria del Software Modellazione

15

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 15

Codifica delle associazioni


Molti a uno (es.: una Persona, molte Automobili)
La classe Automobile ha un attributo Persona oppure la classe Persona ha un attributo array di Automobile o entrambe le cose
La differenza tra le tre soluzioni identificata dai versi della frecce di navigazione Si parlato genericamente di array ma in realt potrebbe trattarsi di una qualsiasi struttura vettoriale
Persona
1

Possiede > Automobile 1..*

Possiede > Persona


1

Automobile 1..*
Possiede > 1 1..* Automobile

Persona

Ingegneria del Software Modellazione

16

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 16

Codifica delle associazioni


Molti a molti (es: molti Studente, molti Esame)
La classe Studente implementata avendo anche un attributo array di Esame, Oppure la classe Esame implementata avendo anche un attributo array di Studente O entrambe le cose La classe Badge implementata avendo un attributo Studente Oppure la classe Studente implementata avendo un attributo Badge O entrambe le cose

Uno a Uno (es: uno Studente, un Badge)


Ingegneria del Software Modellazione

17

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 17

Esempi Java
class A { A(B b) {this.link(b)} public link(B linkato) {this.ruolo_di_B =linkato} private B ruolo_di_B; }; class B { B(A a) {this.link(a)} public link(A linkato) {this.ruolo_di_A=linkato} private A ruolo_di_A; }; public static void main() { A a; B b; +ruolo_di_A a=new A(b); A 1 b.link(a); }; class A { public aggiungi(B newobj); public rimuovi(B oldobj); private ArrayList<B> lista; };

Associazione uno a molti

class B { B(A a) {this.link(a)} public link(A linkato) {this.ruolo_di_A=linkato} private A ruolo_di_A; }; public static void main(){ A a=new A(); a.aggiungi (new B(a)); }
A +ruolo_di_A 1 +ruolo_di_B * B

+ruolo_di_B 1

Associazione uno a uno


Modelli di sistema- Introduzione a UML

Ingegneria del Software Modellazione

18

P Tramontana

Slide 18

Esempi C++
class A { Public: link(B* linkato):ruolo_di_B(linkato) {} Private: B* ruolo_di_B; }; Class B { Public: link(A* linkato):ruolo_di_A(linkato) {} Private: A* ruolo_di_A; }; Void main() { A a; B b; a.link(&b); b.link(&a); }; class A { Public: aggiungi(B* newobj); rimuovi(B* oldobj); Private: lista_puntatori_a_B; }; Class B { Public: link(A* linkato):ruolo_di_A(linkato) {} Private: A* ruolo_di_A; };

Associazione uno a molti

Associazione uno a uno


19

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 19

Contro-esempi
A volte le associazioni uno a uno sono inutili Evitare
Person
name

migliore soluzione!
PersonInfo
address email birthdate

Person
name address email birthdate

Ingegneria del Software Modellazione

20

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 20

Un esempio pi complesso
Una prenotazione si riferisce sempre ad un solo passeggero
Non esistono prenotazioni con zero passeggeri

Ci implica che prima di creare una prenotazione deve esistere un passeggero


Una prenotazione non pu mai riferirsi a pi di un passeggero.

Un Passeggero pu avere pi prenotazioni


Un passeggero potrebbe avere zero prenotazioni Un passeggero potrebbe avere pi di una prenotazione

Una prenotazione si riferisce ad un volo Un volo pu avere pi passeggeri prenotati


Passeggero 1
Ingegneria del Software Modellazione

Prenotazione * * 1

Volo

21

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 21

Classi associative
In alcuni casi, un attributo che si riferisce a due classi collegate non pu essere riferito a nessuna delle due Pu esistere nel caso di molteplicit molti-a-molti
Studente *
*

Esame

Classe Associativa
Studente
1

Voto
valore * *
1

Soluzioni equivalenti
Esame

Voto
valore

Prima di creare unistanza della classe Voto, devono esistere le istanze delle classi collegate

La classe associativa pu avere attributi, metodi, altre associazioni


Ingegneria del Software Modellazione 22

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 22

Associazioni riflessive
Associazioni che collegano una classe con se stessa
Propedeutico > * *

Corso
* *

In alternativa a

Precede > * +Meglio classificato Atleta +Nome *

Distacco +Valore

+Peggio Classificato

Associazione asimmetrica

Permette, per ogni atleta, di risalire al distacco da tutti gli altri atleti

Associazione simmetrica

Ingegneria del Software Modellazione

23

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 23

Aggregazione
Le Aggregazioni sono speciali associazioni che rappresentano una relazione tutto-parti.
Il lato del tutto spesso chiamato laggregato La molteplicit dal lato del tutto, quando sottintesa, vale 0..1

Veicolo

Ruota

Nazione

Regione

Ingegneria del Software Modellazione

24

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 24

Quando usare una aggregazione


Una associazione diventa una aggregazione se:
possibile affermare che:
Le parti sono parte di un insieme Laggregato composto da parti

Quando qualcosa possiede o controlla laggregato, allora esso possiede o controlla anche le sue parti
Per quanto le aggregazioni siano importanti dal punto di vista della espressivit del modello, spesso sono implementate in maniera identica rispetto ad associazioni di pari cardinalit
Ingegneria del Software Modellazione 25

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 25

Una gerarchia di aggregazione


documento

0..1 titolo

1 sezione

sottosezione 0..*

Esercizio proposto: modellare i concetti di file e directory nellambito di un file system


Ingegneria del Software Modellazione

0..* paragrafo 1..*


26

frase

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 26

Composizione
Una composizione una forma forte di aggregazione
Se laggregato viene distrutto, anche le sue parti saranno distrutte (le parti non esistono senza il tutto)

Evidentemente, in questo dominio, non ha senso parlare di stanze fintantoch esse non siano state legate alla casa in cui si trovano La cardinalit dellaggregazione, se sottintesa, vale 1
Palazzo
*

Stanza

4 Classifica -lega

Squadra -nome: String -punteggio: int

Ingegneria del Software Modellazione

27

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 27

Esempio di aggregazione
Consideriamo il seguente esempio:

Esso esprime il concetto che l'Automobile (ogni istanza di Automobile) ha una Carrozzeria ed un Motore. La specifica prodotta indica un contenimento in senso lasco. Per quanto detto scegliamo la traduzione di tale relazione tramite l'uso dei puntatori per cui avremo:

Ingegneria del Software Modellazione

28

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 28

Esempio di aggregazione Java (uno a uno)


class Automobile { public: //il costruttore inizializza Automobile anche in assenza di Motore e Carrozzeria Automobile(Stringa marca, Stringa mod,, Motore mot, Carrozzeria car) {this.marca=marca; this.modello= mod; this.motore=mot; this.carrozzeria=car;} private: Carrozzeria carrozzeria; //traduzione aggregazione Motore motore; //traduzione aggregazione };

Ingegneria del Software Modellazione

29

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 29

Esempio di aggregazione Java (uno a uno)


Il programma principale dovr dapprima creare un oggetto di tipo Carrozzeria e Motore ed infine l'oggetto di tipo Automobile. Ad esempio: public static void main (String args[]) { //definisce e inizializza oggetto di tipo Motore Motore m=new Motore("AZ123","Ferrari", 6,12,1000); //definisce e inizializza oggetto di tipo Carrozzeria Carrozzeria c=new Carrozzeria("12345ASA", "RossoFerrari",1500); //definisce e inizializza oggetto Automobile, fornendo puntatori Automobile auto1=new Automobile("Ferrari", 2012, c,m); }

Ingegneria del Software Modellazione

30

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 30

Esempio di aggregazione C++ (uno a uno)


//file Automobile.h #include "Motore.h" #include "Carrozzeria.h" class Automobile { public: //il costruttore inizializza Automobile anche in assenza di Motore e Carrozzeria Automobile(Stringa marca= "", Stringa mod="",, Motore* mot=0, Carrozzeria* car=0); private: Carrozzeria* carrozzeria; //traduzione aggregazione Motore* motore; //traduzione aggregazione };

//file Automobile.cpp //Costruttore di Automobile


Automobile:: Automobile(Stringa marca, Stringa mod,,Motore* mot, Carrozzeria* car) :

marca(marca), modello(mod),motore(mot), carrozzeria(car);

Ingegneria del Software Modellazione

31

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 31

Esempio di aggregazione C++ (uno a uno)


Il programma principale dovr dapprima creare un oggetto di tipo Carrozzeria e Motore ed infine l'oggetto di tipo Automobile. Ad esempio: #include "Automobile.h" main () { //usa classe Automobile //definisce e inizializza oggetto di tipo Motore Motore m("AZ123","Ferrari", 6,12,1000); //definisce e inizializza oggetto di tipo Carrozzeria Carrozzeria c("12345ASA", "RossoFerrari",1500); //definisce e inizializza puntatore a motore Motore* puntatoreMotore=&m; //definisce e inizializza puntatore a carrozzeria Carrozzeria* puntatoreCarrozzeria=&c; //definisce e inizializza oggetto Automobile, fornendo puntatori Automobile auto1("Ferrari", , puntatoreCarrozzeria, puntatoreMotore); } //al termine vengono separatamente distrutti m,c e auto1

Ingegneria del Software Modellazione

32

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 32

Esempio di composizione Java (uno a uno)


class Contenitore { public: Contenitore(String a, String x) {nomeContenitore=a; contenuto=new Contenuto(x);} // composizione Contenuto contenuto; String nomeContenitore; }; Affinch si possa parlare di contenimento stretto (composizione) deve essere garantito che la classe Contenitore sia effettivamente lunica ad accedere al metodo costruttore della classe Contenuto

class Contenuto { public: Contenuto(String x) {nomeContenuto=x}; String nomeContenuto; };


Ingegneria del Software Modellazione 33

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 33

Esempio di composizione C++ (uno a uno)


//file Contenitore.h #include "Contenuto.h" class Contenitore { public: Contenitore(String, String); ~Contenitore(); // composizione Contenuto c; //Nota bene: un oggetto, non un puntatore! String nomeContenitore; }; //file Contenuto.h class Contenuto { public: //il costruttore inizializza gli attributi propri e richiama il costruttore dellelemento contenuto Contenuto(String x); String nomeContenuto; };

//file Contenuto.cpp #include "Contenuto.h" Contenuto::Contenuto(String x):nomeContenuto(x){}

//file Contenitore.cpp #include "Contenitore.h" //Costruttore: chiama anche il costruttore del contenuto Contenitore:: Contenitore (String a, String x):nomeContenitore(a),c(x){} //Distruttore: chiama anche il distruttore del contenuto Contenitore::~Contenitore() { delete &c;}
Ingegneria del Software Modellazione

Affinch si possa parlare di contenimento stretto (composizione) deve essere garantito che la classe Contenitore sia effettivamente lunica ad accedere al metodo costruttore della classe Contenuto 34

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 34

Gerarchia di Aggregazione
Veicolo

Chassis

Carrozzeria

Porta

Telaio

Motore

Trasmissione

Ruota

Ingegneria del Software Modellazione

35

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 35

Generalizzazioni
l concetti di generalizzazione e specializzazione UML sono del tutto analoghi a quelli object oriented
La linea tratteggiata indica che la generalizzazione incompleta

Animal
habitat

Animal
typeOfFood

AquaticAnimal

LandAnimal

Carnivore

Herbivore

Un discriminatore potr essere implementato come un attributo con valori diversi nelle due sottoclassi
Ingegneria del Software Modellazione 36

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 36

Generalizzazioni
A livello concettuale, una gerarchia di generalizzazione esprime una relazione Is-a tra un concetto generale e le sue specializzazioni
Cliente

Azienda

Privato

Regola della Sostituibilit: Ogni elemento della classe Azienda (o Privato) anche un elemento della classe Cliente. Ne consegue che il software potr riferirsi al tipo Cliente, senza dover distinguere se esso unAzienda o un Privato.

Ingegneria del Software Modellazione

37

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 37

Implementazione della generalizzazione


A livello di progetto di dettaglio, la generalizzazione pu essere implementata :
Con una relazione di ereditariet tra due classi concrete
Le classi derivate (figlie) ereditano attributi e metodi public e protected dalla classe padre Si pu ereditare anche da una classe astratta: la classe figlia implementa i metodi sfruttando loverriding Problemi quando la classe padre include troppe propriet non desiderate nelle classi figlie!

In alternativa, possibile usare una relazione di implementazione (o realizzazione) tra una classe concreta ed una interfaccia
38

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 38

Classe astratta ed Interfacce


La classe astratta una classe che ha una o pi operazioni astratte e non pu essere direttamente istanziata.
Occorre prima creare una sottoclasse concreta In UML si indica col nome in corsivo o etichetta {abstract}

Una interfaccia una classe priva di implementazione (tutte le sue propriet sono astratte)
descrive una porzione del comportamento visibile di un insieme di oggetti In UML si indica con la parola chiave <<interface>>
39

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 39

Interfaccia
Linterfaccia molto utilizzata, specie in linguaggi come Java, per separare limplementazione di una o pi classi (raggruppate in un package) da quella che la loro interfaccia vera e propria Linterfaccia rappresenta anche un modo per alterare le regole di visibilit dei metodi
Una stessa classe o un package di classi possono mostrare diverse interfacce con diversi sottoinsiemi di classi e metodi resi accessibili in maniera pubblica

Il concetto di interfaccia UML coincide con quelli realizzati in Java e CORBA, mentre rappresenta solo un modo possibile di utilizzare le classi abstract in C++
40

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 40

Rapporti fra classi ed interfacce


Una classe pu fornire una interfaccia se sostituibile ad essa (in pratica la implementa)
Java e .NET ha costrutti per implementare interfacce In C++ non possibile, si pu solo ereditare dalla classe interfaccia

Una classe pu richiedere una interfaccia


ha bisogno di una sua istanza per funzionare ( una forma di dipendenza)
41

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 41

Esempio

Esempio tratto da UML Distilled


Ingegneria del Software Modellazione 42

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 42

Notazione Lollipop
Una notazione molto utilizzata per le interfacce quella a Lollipop:
La pallina (lollipop) rappresenta linterfaccia esposta da una classe (quindi una realization) Il semicerchio (socket) rappresenta il servizio richiesto (quindi una dependency) un motore di ricerca fornisce la possibilit di accedere al proprio servizio Cerca tramite uninterfaccia La classe visualizzatore richiama la ricerca
Motore di ricerca Cerca Visualizzatore

Esempio:

Ingegneria del Software Modellazione

43

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 43

Esempio
Un libro (implementa linterfaccia) acquistabile (dobbiamo sapere/modificare il suo prezzo) Un DVD acquistabile ma anche Noleggiabile (dobbiamo sapere/modificare il suo prezzo di noleggio) Libri e DVD sono entrambi media, con un titolo e un prezzo
Acquistabile
+getPrezzo() +setPrezzo()

Noleggiabile
+getPrezzoNoleggio +setPrezzoNoleggio

DVD Libro -numeroPagine +getPrezzo() +setPrezzo() +getPrezzo() +setPrezzo() +getPrezzoNoleggio() +setPrezzoNoleggio() -durata -prezzoNoleggio

Media #titolo #prezzo +getTitolo() +setTitolo()

Ingegneria del Software Modellazione

44

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 44

Esempio
public class Libro extends Media implements Acquistabile { public interface Acquistabile { private int numeroPagine; public void setPrezzo(double public void setPrezzo(double prezzo) { prezzo); this.prezzo = prezzo; public double getPrezzo(); } } public double getPrezzo() { return prezzo; public interface Noleggiabile { } public void setPrezzoNoleggio(double } prezzo); public class DVD extends Media implements Acquistabile, public double getPrezzoNoleggio(); } Noleggiabile { private double durata; Public class Media { private double prezzoNoleggio; protected String titolo; public void setPrezzo(double prezzo) { this.prezzo = prezzo; protected double prezzo; } public void setTitolo(String titolo) { this.titolo = titolo; public double getPrezzo() { } return prezzo; public double getTitolo() { } return titolo; public void setPrezzoNoleggio(double prezzo) { } this.prezzoNoleggio = prezzo; } } public double getPrezzoNoleggio() { return prezzoNoleggio; 45 } Ingegneria del Software Modellazione } a UML P Tramontana Modelli di sistema- Introduzione Slide 45

Esempio (main)
public class EsempioInterfaceMain { public static void main(String[] args) {
Libro l=new Libro(); l.setPrezzo(10); l.setTitolo("Titolo Libro"); DVD d=new DVD(); d.setPrezzo(5); d.setPrezzoNoleggio(2); d.setTitolo("Titolo DVD"); Media m=new Media(); m.setTitolo("Titolo Media"); System.out.println(l.getPrezzo()); System.out.println(l.getTitolo()); System.out.println(d.getPrezzoNoleggio()); System.out.println(d.getPrezzo()); System.out.println(d.getTitolo()); System.out.println(m.getTitolo());

} }
46

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 46

Altra notazione
Media #titolo #prezzo +getTitolo() +setTitolo()

DVD Libro -numeroPagine +getPrezzo() +setPrezzo() +getPrezzo() +setPrezzo() +getPrezzoNoleggio() +setPrezzoNoleggio() -durata -prezzoNoleggio

Acquistabile +getPrezzo() +setPrezzo()

Noleggiabile +getPrezzoNoleggio() +setPrezzoNoleggio()

Ingegneria del Software Modellazione

47

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 47

Altro esempio

Person

interface

Cashier
withdraw deposit

Machine

Person
Cashier

Machine
Cashier

Employee

ATM

Employee

ATM

Relazioni di <<realizzazione>>

Ingegneria del Software Modellazione

48

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 48

Responsabilit
Nei diagrammi che descrivono il dominio del problema non si inseriscono di solito metodi perch essi rappresenterebbero un elemento del dominio della soluzione In alternativa si possono utilizzare le Responsabilit Una responsabilit un
Esame

insieme di servizi e compiti che la classe dovrebbe garantire Sono utili per controllare la completezza del modello di dominio
Ingegneria del Software Modellazione

-- Gestisce l'inserimento, l'aggiornamento e la modifica degli esami() -- Gestisce le prenotazioni degli studenti all'esame()

Prenotazione

Studente

49

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 49

Note e testo descrittivo


Si possono aggiungere ulteriori informazioni direttamente in linguaggio naturale ad un qualsiasi diagramma UML utilizzando le annotazioni Note:
Una nota un pezzo di testo incluso in un diagramma UML come un commento in un linguaggio di programmazione
Possiede > Persona 1 1..* Automobile

Persona deve aver conseguito la patente di guida

Ingegneria del Software Modellazione

50

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 50

Object Constraint Language (OCL)


OCL un linguaggio di specifica progettato per specificare vincoli nei moduli software
Una espressione OCL specifica un vincolo (predicato logico) sul sistema che deve assumere valore vero La valutazione di unespressione OCL non pu avere effetti collaterali Gli statements OCL nei class diagrams possono specificare quali devono essere i valori di attributi e associazioni: il programmatore dovr poi rispettare tali vincoli
Ingegneria del Software Modellazione 51

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 51

OCL statements
Gli statements OCL possono essere costruiti usando:
Riferimenti a nomi di ruolo, nomi di associazioni, attributi ed I risultati di operazioni I valori logici true e false Operatori logici come and, or, =, >, < o <> (not equals) Stringhe di caratteri quali: a string Interi e numeri reali Operatori aritmetici: *, /, +, 52

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 52

Esempio: vincoli sui poligoni


{edge->forAll(e1,e2 | e1 <> e2 implies e1.startPoint <> e2.startpoint a LinearShape is any shape and e1.endPoint <> e2.endpoint)} {ordered} that can be constructed of line edge

segments (in contrast with shapes that contain curves).

LinearShape

1..*

LineSegment
startPoint: Point endPoint: Point length : int

Path
length

Line
{edge->size=1}

Polygon
{edge->first.startPoint = edge->last.endPoint}

{startPoint <> endPoint}

{length = edge.length->sum}

RegularPolygon
{edge->forAll(e1,e2 | e1.length = e2.length)}

Ingegneria del Software Modellazione

53

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 53

Un esempio dettagliato: un Class Diagram per una Genealogia


Versione riduttiva delle specifiche Un matrimonio un legame tra un uomo e una donna Ogni persona pu essere genitore di alcuni figli Un figlio ha sempre due genitori Come modellare queste specifiche?

Ingegneria del Software Modellazione

54

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 54

Un esempio dettagliato: un Class Diagram per una Genealogia


Person
name sex placeOfBirth dateOfBirth placeOfDeath {husband.sex dateOfDeath = #male} placeOfMarriage child husband dateOfMarraige 0..1 dateOfDivorce * parent 2 0..1 wife
{wife.sex = #female}

Ogni uomo pu essere legato ad una donna tramite un matrimonio e viceversa Ogni persona pu essere genitore di alcuni figli Un figlio ha sempre due genitori

Problemi

{parent->forAll(p1,p2: p1 <> p2 implies p1.sex <> p2.sex)}

Una persona deve avere sempre due genitori I Matrimoni non sono gestiti adeguatamente (persone con pi matrimoni e figli per ciascun matrimonio?)
Ingegneria del Software Modellazione 55

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 55

Genealogia : Possibili soluzioni


Person
name sex placeOfBirth dateOfBirth placeOfDeath child dateOfDeath *
partner * 0..2 {partner->forAll(p1,p2 | p1 <> p2 implies p1.sex <> p2.sex)} *

Person
name placeOfBirth dateOfBirth placeOfDeath child dateOfDeath *

Woman
0..1

Man

Union

femalePartner malePartner 0..1 * 0..1 child child

placeOfMarriage parents dateOfMarriage dateOfDivorce

Union
0..1 placeOfMarriage parents dateOfMarriage dateOfDivorce

I figli sono attribuiti allunione da cui nascono una persona pu avere zero o al pi due genitori
P Tramontana Modelli di sistema- Introduzione a UML

Rimosso il vincolo OCL


56

Ingegneria del Software Modellazione

Slide 56

Dependency
Una Dependency rappresenta una relazione di necessit tra le istanze di due classi, che viene a realizzarsi a tempo di esecuzione. Esempi: c dependency dalla classe A verso la classe B se:
Metodi della classe A vanno a leggere/scrivere/modificare il valore di attributi di oggetti della classe B; Metodi della classe A invocano metodi della classe B;
caso particolare: la classe A istanzia oggetti della classe B (ovvero ne invoca il costruttore)

La Dependency si rappresenta con una linea tratteggiata che termina con una freccia dalloggetto dipendente verso quello da cui dipende.

Ingegneria del Software Modellazione

57

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 57

Dependency
Le relazioni di dependency sono individuate principalmente durante la fase di progetto di dettaglio: esse raramente contribuiscono al modello concettuale Esprimono una dipendenza (accoppiamento) tra le classi, nel senso che la classe origine della dipendenza non potr essere riusata senza la classe destinazione della dependency. Una modifica nella classe da cui c dipendenza implicher modifiche anche nella classe dipendente. Analogamente, la correttezza della classe da cui parte una relazione di dipendenza condizionata alla verifica della correttezza della classe da cui si dipendenti.

Ingegneria del Software Modellazione

58

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 58

Tipi di Dipendenze in UML 2.0


Per distinguere diverse tipologie di dipendenze, UML mette a disposizione gli stereotipi, che possono essere indicati con keywords scritti tra parentesi angolari doppie Alcuni esempi di stereotipi: <<call>> Chiamata di metodo <<create>> Creazione di unistanza di oggetto <<use>> Utilizza un attributo

Ingegneria del Software Modellazione

59

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 59

Ulteriori notazioni
Classi parametriche (template)
Utili pi che altro nella modellazione di diagrammi di progetto di dettaglio di applicazioni da sviluppare in C++ o simili

Tipi enumerativi
Utilizzano la stessa notazione delle classi ma esprimono un elenco di valori

Classi attive
Classi che eseguono e controllano I propri thread

Per qualsiasi altro elemento bisogna consultare la guida di riferimento oppure inventare stereotipi comprensibili!

Ingegneria del Software Modellazione

60

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 60

Esempi
Classi parametriche
ArrayList<String>

Tipi enumerativi
public enum Day { SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY }

(per lesempio sulle classi attive si rimanda al corso di Sistemi Operativi)


61

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 61

Livelli di dettaglio dei Class Diagram


I diagrammi UML possono essere creati in diverse fasi del ciclo di vita, con diversi scopi e livelli di dettaglio
System domain model (Modello Concettuale dei dati):
Modello del dominio dei dati del problema Descrive aspetti del dominio del problema che saranno presenti nel sistema (i dati di interesse) A volte si aggiungono a questo modello anche le responsabilit delle classi

System model:
Include anche classi che saranno usate per costruire

le interfacce utente Le interazioni con altri sistemi, database, etc. Classi di utilit Ingegneria del Software Modellazione
P Tramontana Modelli di sistema- Introduzione a UML Slide 62

62

"Object-oriented programming is an exceptionally bad idea that could only have been invented in California." - Edsger Dijkstra

Ingegneria del Software Modellazione

63

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 63

Un processo di astrazione di un modello di dominio


1. Identifica un primo insieme di classi candidate 2. Aggiungi associazioni ed attributi a queste classi 3. Trova le generalizzazioni 4. Trova le principali responsabilit di ogni classe 5. In base alle responsabilit decidi sulle operazioni 6. Itera il processo finch il modello ottenuto soddisfacente

Ingegneria del Software Modellazione

64

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 64

1. Identificare le classi
Ad una classe dovrebbe corrispondere unentit del dominio del problema
In pratica, bisogna applicare i concetti generali di modellazione Object Oriented

Quando si sviluppa un domain model si tende a scoprire classi che fanno parte del dominio Nel lavorare allinterfaccia utente o allarchitettura, si tende ad inventare classi
Necessarie a risolvere un problema di design Si possono inventare classi anche per il domain model!
Ingegneria del Software Modellazione 65

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 65

Come fatta una buona classe di analisi?


Il suo nome ne rispecchia lintento. una astrazione ben definita che modella un elemento del dominio del problema ha un insieme ridotto e ben definito di responsabilit ha una massima coesione interna
Una classe tanto pi coesa quanto pi riesce ad assolvere da sola alle proprie responsabilit

Ingegneria del Software Modellazione

66

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 66

Analisi dei nomi


Semplice tecnica per scoprire le classi del dominio
Analizzare la documentazione di partenza, come la descrizione dei requisiti Estrarre nomi e predicati nominali (aggettivi di nomi) Eliminare nomi che: Sono ridondanti (rappresentano la stessa classe) Rappresentano istanze e non classi Sono vaghi, troppo generici Corrispondono a classi che non sono necessarie al livello considerato Fare attenzioni a classi nel domain model che rappresentano tipi di utente o altri attori (servono davvero?)

Ingegneria del Software Modellazione

67

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 67

2. Identificare associazioni ed attributi


Parti con le classi ritenute centrali ed importanti Stabilisci i dati ovvi e chiari che esse contengono e le loro relazioni con altre classi. Procedi con le classi meno importanti. Evita di aggiungere troppi attributi ed associazioni ad una classe.
Un sistema pi semplice se manipola meno informazioni Le classi devono avere poche dipendenze da altre classi

Ingegneria del Software Modellazione

68

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 68

Suggerimenti per trovare e specificare associazioni valide


Una associazione dovrebbe esistere se una classe:
possiede controlla collegata a si riferisce a parte di ha come parti membro di oppure ha come membri

qualche altra classe del modello Specificare le molteplicit da entrambi i lati. Assegnare un nome chiaro allassociazione.
Ingegneria del Software Modellazione 69

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 69

Azioni piuttosto che associazioni.


Un errore comune consiste nel considerare azioni come se fossero associazioni.
SocioLibreria
*
Prende In prestito

Restituisce

Prestito

SocioLibreria

ArticoloLibreria

DataPrestito DataRitorno * DataRestituzione

ArticoloLibreria

Errore!

Nellimplementazione della classe Meglio: loperazione presta crea un Prestito Prestito compariranno due attributi e Loperazione restituisci setta la data di restituzione riferimento a un oggetto SocioLibreria e un oggetto ArticoloLibreria

Ingegneria del Software Modellazione

70

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 70

2.a. Identificare gli attributi


Cercare le informazioni che devono essere conservate per ciascuna classe possibile che nomi che sono stati scartati come classi, possano ora essere considerati attributi Un attributo dovrebbe in genere contenere un solo valore
Es. stringa, numerico

Ingegneria del Software Modellazione

71

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 71

Suggerimenti per identificare e specificare attributi validi


bene non avere molti attributi duplicati Se un sottoinsieme degli attributi di una classe forma un gruppo coerente, crea una classe distinta per questi attributi
Person
name addresses

Person
name street1 municipality1 provOrState1 country1 postalCode1 street2 municipality2 provOrState2 country2 postalCode2

Person
name

* addresses *

Address
street municipality provOrState country postalcode type

Bad due to too many Errore: troppi attributi attributes, and inability duplicati, e incapacit to add more addresses di Ingegneria del Software Modellazione gestire pi indirizzi
P Tramontana Modelli di sistema- Introduzione a UML Slide 72

Bad due to Errore: uso di a plural attributi attributeal plurale: sostituire con address [1..*], ad esempio

Good lattributo solution. The Bene: type indicates whether tipo tipo di it is indica a home il address, business address etc. indirizzo

72

3. Identificare generalizzazioni e interfacce


Due modi per trovare le generalizzazioni:
bottom-up Raggruppo classi simili creando una nuova superclasse top-down Cerco prima le classi pi generali, e poi specializzo

Crea un interfaccia, invece di una superclasse se:


Le classi sono molto diverse fra loro, tranne che hanno poche operazioni in comune Una o pi classi hanno gi le loro superclassi Potrebbero essere disponibili diverse implementazioni della stessa classe
Ingegneria del Software Modellazione 73

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 73

4. Assegnare le Responsabilit alle classi


Una responsabilit un qualcosa che richiesto al sistema.
La responsabilit di ogni requisito funzionale deve essere attribuita ad una delle classi, anche se tale requisito potr essere svolto mediante una collaborazione fra pi classi.
Tutte le responsabilit di una classe dovrebbero essere chiaramente correlate. Se una classe ha troppe responsabilit, valutare lipotesi di dividerla in pi classi Se una classe non ha responsabilit, probabilmente inutile Quando una responsabilit non pu essere attribuita a nessuna delle classi esistenti, dovrebbe essere creata una nuova classe

Per stabilire le responsabilit:


Svolgere lanalisi dei casi duso Cercare verbi e nomi che descrivono azioni nella descrizione del sistema
Ingegneria del Software Modellazione 74

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 74

Categorie di responsabilit
Set e get dei valori degli attributi Creare ed inizializzare nuove istanze Prelevare da o memorizzare dati in una memoria persistente Distruggere istanze Aggiungere e cancellare istanze di associazioni Copiare, convertire, trasformare, trasmettere o fornire in output dati. Calcolare risultati numerici Navigare e cercare dati di particolari istanze Altro lavoro specifico

Ingegneria del Software Modellazione

75

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 75

Qualche suggerimento
La responsabilit di creare istanze di una classe non pu essere attribuita alla classe stessa, ma ad una classe collegata ad essa La responsabilit di cercare istanze di una classe che fanno parte di una collection (es. lista, catalogo, etc.) non pu essere attribuita alla classe stessa, ma alla classe collection Cercare di attribuire ad una classe responsabilit che le richiedono di interagire soprattutto con le sue classi vicine

Ingegneria del Software Modellazione

76

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 76

CRC cards
CRC sta per Class Responsibility Collaboration
Per ogni classe identificata, porre il nome della classe su una scheda (Card) Man mano che vengono individuati attributi e responsabilit, elencarli sulle Card Sistemare le card su una lavagna per creare il Class diagram Disegnare le linee corrispondenti ad associazioni e generalizzazioni.
Lutilizzo delle card serve per imporre, quanto meno psicologicamente, allanalista di non realizzare classi con un numero troppo elevato di attributi e metodi Se la card piena allora probabilmente bisogna dividere la classe in due o pi classi pi semplici

Ingegneria del Software Modellazione

77

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 77

5. Identificare le operazioni
Le operazioni saranno necessarie a realizzare le responsabilit di ciascuna classe
Ci saranno in genere diverse operazioni per realizzare ogni responsabilit, ma una in particolare avr limpegno della responsabilit. Le principali operazioni che implementano una responsabilit sono normalmente dichiarate public Altri metodi che collaborano a realizzare una responsabilit devono essere dichiarate private se possibile.
Ingegneria del Software Modellazione 78

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 78

Esempio: videogioco
Si vuole progettare un videogioco nel quale il giocatore impersona un agente di borsa, rivivendone le interazioni e basandosi sulle azioni delle societ effettivamente quotate alla borsa di New York. Ogni giocatore ha una dotazione monetaria iniziale, pari a 100 milioni di dollari, che pu essere investita acquistando delle azioni. Possono essere acquistate azioni di ognuna delle societ quotate nel listino della borsa di New York. Le azioni di una societ vengono acquistate al prezzo cui sono quotate nellistante dellacquisto. In fase di acquisto, il giocatore acquirente deve specificare anche il quantitativo di azioni che vuole acquistare. Il sistema provveder a valutare leffettiva disponibilit di liquidi da parte dellacquirente e, in caso di acquisto possibile, scaler dalla sua liquidit il denaro necessario allacquisto delle azioni. Il giocatore potr anche vendere le azioni che possiede, al prezzo cui sono quotate in quel momento (il sistema provveder ad aggiornare la liquidit). Acquisti e vendite di azioni potranno essere effettuati soltanto nel periodo di tempo tra lorario di apertura e lorario di chiusura della borsa di New York. I giocatori possono anche scegliere di monitorare le azioni di alcune societ. In tal caso il sistema manterr un valore del prezzo delle azioni di ognuna delle societ monitorate per ogni giorno nel quale il giocatore vorr monitorarla. I giocatori sono organizzati in squadre di al pi 4 elementi. Ogni squadra ha un nome e il sistema assegner un premio mensile alla squadra che ha il bilancio migliore. Una bacheca manterr tutti i premi mensili ricevuti.
79

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 79

Ricerca classi
Si vuole progettare un videogioco nel quale il giocatore impersona un agente di borsa, rivivendone le interazioni e basandosi sulle azioni delle societ effettivamente quotate alla borsa di New York. Ogni giocatore ha una dotazione monetaria iniziale, pari a 100 milioni di dollari, che pu essere investita acquistando delle azioni. Possono essere acquistate azioni di ognuna delle societ quotate nel listino della borsa di New York. Le azioni di una societ vengono acquistate al prezzo cui sono quotate nellistante dellacquisto. In fase di acquisto, il giocatore acquirente deve specificare anche il quantitativo di azioni che vuole acquistare. Il sistema provveder a valutare leffettiva disponibilit di liquidi da parte dellacquirente e, in caso di acquisto possibile, scaler dalla sua liquidit il denaro necessario allacquisto delle azioni. Il giocatore potr anche vendere le azioni che possiede, al prezzo cui sono quotate in quel momento (il sistema provveder ad aggiornare la liquidit). Acquisti e vendite di azioni potranno essere effettuati soltanto nel periodo di tempo tra lorario di apertura e lorario di chiusura della borsa di New York. I giocatori possono anche scegliere di monitorare le azioni di alcune societ. In tal caso il sistema manterr un valore del prezzo delle azioni di ognuna delle societ monitorate per ogni giorno nel quale il giocatore vorr monitorarla. I giocatori sono organizzati in squadre di al pi 4 elementi. Ogni squadra ha un nome e il sistema assegner un premio mensile alla squadra che ha il bilancio migliore. Una bacheca manterr tutti i premi mensili ricevuti.
80

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 80

Ricerca associazioni ed attributi


Si vuole progettare un videogioco nel quale il giocatore impersona un agente di borsa, rivivendone le interazioni e basandosi sulle azioni delle societ effettivamente quotate alla borsa di New York. Ogni giocatore ha una dotazione monetaria iniziale, pari a 100 milioni di dollari, che pu essere investita acquistando delle azioni. Possono essere acquistate azioni di ognuna delle societ quotate nel listino della borsa di New York. Le azioni di una societ vengono acquistate al prezzo cui sono quotate nellistante dellacquisto. In fase di acquisto, il giocatore acquirente deve specificare anche il quantitativo di azioni che vuole acquistare. Il sistema provveder a valutare leffettiva disponibilit di liquidi da parte dellacquirente e, in caso di acquisto possibile, scaler dalla sua liquidit il denaro necessario allacquisto delle azioni. Il giocatore potr anche vendere le azioni che possiede, al prezzo cui sono quotate in quel momento (il sistema provveder ad aggiornare la liquidit). Acquisti e vendite di azioni potranno essere effettuati soltanto nel periodo di tempo tra lorario di apertura e lorario di chiusura della borsa di New York. I giocatori possono anche scegliere di monitorare le azioni di alcune societ. In tal caso il sistema manterr un valore del prezzo delle azioni di ognuna delle societ monitorate per ogni giorno nel quale il giocatore vorr monitorarla. I giocatori sono organizzati in squadre di al pi 4 elementi. Ogni squadra ha un nome e il sistema assegner un premio mensile alla squadra che ha il bilancio migliore. Una bacheca manterr tutti i premi mensili ricevuti.
81

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 81

Ricerca generalizzazioni
Si vuole progettare un videogioco nel quale il giocatore impersona un agente di borsa, rivivendone le interazioni e basandosi sulle azioni delle societ effettivamente quotate alla borsa di New York. Ogni giocatore ha una dotazione monetaria iniziale, pari a 100 milioni di dollari, che pu essere investita acquistando delle azioni. Possono essere acquistate azioni di ognuna delle societ quotate nel listino della borsa di New York. Le azioni di una societ vengono acquistate al prezzo cui sono quotate nellistante dellacquisto. In fase di acquisto, il giocatore acquirente deve specificare anche il quantitativo di azioni che vuole acquistare. Il sistema provveder a valutare leffettiva disponibilit di liquidi da parte dellacquirente e, in caso di acquisto possibile, scaler dalla sua liquidit il denaro necessario allacquisto delle azioni. Il giocatore potr anche vendere le azioni che possiede, al prezzo cui sono quotate in quel momento (il sistema provveder ad aggiornare la liquidit). Acquisti e vendite di azioni potranno essere effettuati soltanto nel periodo di tempo tra lorario di apertura e lorario di chiusura della borsa di New York. I giocatori possono anche scegliere di monitorare le azioni di alcune societ. In tal caso il sistema manterr un valore del prezzo delle azioni di ognuna delle societ monitorate per ogni giorno nel quale il giocatore vorr monitorarla. I giocatori sono organizzati in squadre di al pi 4 elementi. Ogni squadra ha un nome e il sistema assegner un premio mensile alla squadra che ha il bilancio migliore. Una bacheca manterr tutti i premi mensili ricevuti.
82

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 82

Ricerca e assegnazione di responsabilit


Si vuole progettare un videogioco nel quale il giocatore impersona un agente di borsa, rivivendone le interazioni e basandosi sulle azioni delle societ effettivamente quotate alla borsa di New York. Ogni giocatore ha una dotazione monetaria iniziale, pari a 100 milioni di dollari, che pu essere investita acquistando delle azioni. Possono essere acquistate azioni di ognuna delle societ quotate nel listino della borsa di New York. Le azioni di una societ vengono acquistate al prezzo cui sono quotate nellistante dellacquisto. In fase di acquisto, il giocatore acquirente deve specificare anche il quantitativo di azioni che vuole acquistare. Il sistema provveder a valutare leffettiva disponibilit di liquidi da parte dellacquirente e, in caso di acquisto possibile, scaler dalla sua liquidit il denaro necessario allacquisto delle azioni. Il giocatore potr anche vendere le azioni che possiede, al prezzo cui sono quotate in quel momento (il sistema provveder ad aggiornare la liquidit). Acquisti e vendite di azioni potranno essere effettuati soltanto nel periodo di tempo tra lorario di apertura e lorario di chiusura della borsa di New York. I giocatori possono anche scegliere di monitorare le azioni di alcune societ. In tal caso il sistema manterr un valore del prezzo delle azioni di ognuna delle societ monitorate per ogni giorno nel quale il giocatore vorr monitorarla. I giocatori sono organizzati in squadre di al pi 4 elementi. Ogni squadra ha un nome e il sistema assegner un premio mensile alla squadra che ha il bilancio migliore. Una bacheca manterr tutti i premi mensili ricevuti.
83

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 83

Modello di Dominio del Problema


AcquistoAzione +DataAcquisto +PrezzoAcquisto +Quantita +Vendi() Squadra +Bilancio +AggiungiGiocatore() +EliminaGiocatore() 1 0..* Premio +Mese +Assegna() 1..* 1..4 Giocatore +DenaroLiquido +AcquistaAzione() +MonitoraAzione() +AggiornaLiquidit() 0..* GiornoMonitorato Bacheca MonitoraggioAzione +Monitora() 1 1..* +Data +Prezzo 0..* Possiede > 0..* SocietaQuotata +Nome +PrezzoAzione 1..* Borsa +OrarioApertura +OrarioChiusura

Monitora >

0..*

Vincolo: le azioni possono essere vendute solo negli stessi stock (gruppi a quantit fissata) che erano stati acquistati, quindi la classe AcquistoAzione andrebbe rinominata in AcquistoStockAzione
Ingegneria del Software Modellazione 84

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 84

Soluzioni alternative (provarle per esercizio)


Per poter vendere anche azioni separatamente dagli stock (ad esempio rivendere una per una le azioni comprate in stock) necessario mettere una nuova classe associativa Vendita, tra Giocatore e SocietQuotata, con attributo QuantitVenduta Una soluzione equivalente a quella proposta la si poteva ottenere considerando una classe SocietMonitorata come specializzazione di SocietQuotata, associata quindi soltanto a Giocatore e a GiornoMonitorato MonitoraggioAzione poteva fondersi con GiornoMonitorato, dato che non ci sono specifici attributi/associazioni/responsabilit che rendano necessaria MonitoraggioAzione (in questo caso la responsabilit Monitora viene risolta completamente da Giocatore Il Bilancio per giocatore e per squadra non riportato come attributo perch calcolabile (e deve sicuramente essere calcolato nellambito di Premio.Assegna. In fase di raffinamento, si pu inserire unoperazione CalcolaBilancio in Squadra e in Giocatore.
85

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 85

Esempio: azienda alimentare


Una azienda produttrice di prodotti alimentari, vuole organizzare un sistema informativo aziendale. Tutti gli utenti dellapplicazione devono essere in grado di visualizzare informazioni relative al catalogo dei prodotti. Inoltre i dipendenti devono essere in grado di accedere ad informazioni relative alle loro mansioni. I prodotti sono organizzati in linee di prodotto che accomunano prodotti dello stesso tipo: ad esempio, due linee possono essere pasta e sughi. I prodotti possono essere confezionati in diversi stabilimenti. I dipendenti si suddividono in diverse categorie: i manager, che sono responsabili di una o pi linee di produzione (ogni linea per gestita esattamente da tre manager, per assicurare una gestione equa), i supervisori della produzione che sono responsabili di tutti i prodotti di una specifica linea in uno specifico stabilimento, e gli operai che lavorano su uno specifico prodotto in un determinato stabilimento. Lapplicazione deve prevedere un sistema di controllo accessi che consenta ai manager ed ai supervisori della produzione di accedere alle informazioni relative ai dipendenti di cui sono responsabili, e che consenta a tutti di accedere alle informazioni sui prodotti.
86

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 86

Ricerca classi
Una azienda produttrice di prodotti alimentari, vuole organizzare un sistema informativo aziendale. Tutti gli utenti dellapplicazione devono essere in grado di visualizzare informazioni relative al catalogo dei prodotti. Inoltre i dipendenti devono essere in grado di accedere ad informazioni relative alle loro mansioni. I prodotti sono organizzati in linee di prodotto che accomunano prodotti dello stesso tipo: ad esempio, due linee possono essere pasta e sughi. I prodotti possono essere confezionati in diversi stabilimenti. I dipendenti si suddividono in diverse categorie: i manager, che sono responsabili di una o pi linee di produzione (ogni linea per gestita esattamente da tre manager, per assicurare una gestione equa), i supervisori della produzione che sono responsabili di tutti i prodotti di una specifica linea in uno specifico stabilimento, e gli operai che lavorano su uno specifico prodotto in un determinato stabilimento. Lapplicazione deve consentire ai manager di accedere alle informazioni relative ai dipendenti di cui sono responsabili, e a tutti di accedere alle informazioni sui prodotti.

Ingegneria del Software Modellazione

87

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 87

Ricerca associazioni ed attributi


Una azienda produttrice di prodotti alimentari, vuole organizzare un sistema informativo aziendale. Tutti gli utenti dellapplicazione devono essere in grado di visualizzare informazioni relative al catalogo dei prodotti. Inoltre i dipendenti devono essere in grado di accedere ad informazioni relative alle loro mansioni. I prodotti sono organizzati in linee di prodotto che accomunano prodotti dello stesso tipo: ad esempio, due linee possono essere pasta e sughi. I prodotti possono essere confezionati in diversi stabilimenti. I dipendenti si suddividono in diverse categorie: i manager, che sono responsabili di una o pi linee di produzione (ogni linea per gestita esattamente da tre manager, per assicurare una gestione equa), i supervisori della produzione che sono responsabili di tutti i prodotti di una specifica linea in uno specifico stabilimento, e gli operai che lavorano su uno specifico prodotto in un determinato stabilimento. Lapplicazione deve consentire ai manager di accedere alle informazioni relative ai dipendenti di cui sono responsabili, e a tutti di accedere alle informazioni sui prodotti.

Ingegneria del Software Modellazione

88

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 88

Ricerca generalizzazioni
Una azienda produttrice di prodotti alimentari, vuole organizzare un sistema informativo aziendale. Tutti gli utenti dellapplicazione devono essere in grado di visualizzare informazioni relative al catalogo dei prodotti. Inoltre i dipendenti devono essere in grado di accedere ad informazioni relative alle loro mansioni. I prodotti sono organizzati in linee di prodotto che accomunano prodotti dello stesso tipo: ad esempio, due linee possono essere pasta e sughi. I prodotti possono essere confezionati in diversi stabilimenti. I dipendenti si suddividono in diverse categorie: i manager, che sono responsabili di una o pi linee di produzione (ogni linea per gestita esattamente da tre manager, per assicurare una gestione equa), i supervisori della produzione che sono responsabili di tutti i prodotti di una specifica linea in uno specifico stabilimento, e gli operai che lavorano su uno specifico prodotto in un determinato stabilimento. Lapplicazione deve consentire ai manager di accedere alle informazioni relative ai dipendenti di cui sono responsabili, e a tutti di accedere alle informazioni sui prodotti.

Ingegneria del Software Modellazione

89

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 89

Ricerca e assegnazione di responsabilit


Una azienda produttrice di prodotti alimentari, vuole organizzare un sistema informativo aziendale. Tutti gli utenti dellapplicazione devono essere in grado di visualizzare informazioni relative al catalogo dei prodotti. Inoltre i dipendenti devono essere in grado di accedere ad informazioni relative alle loro mansioni. I prodotti sono organizzati in linee di prodotto che accomunano prodotti dello stesso tipo: ad esempio, due linee possono essere pasta e sughi. I prodotti possono essere confezionati in diversi stabilimenti. I dipendenti si suddividono in diverse categorie: i manager, che sono responsabili di una o pi linee di produzione (ogni linea per gestita esattamente da tre manager, per assicurare una gestione equa), i supervisori della produzione che sono responsabili di tutti i prodotti di una specifica linea in uno specifico stabilimento, e gli operai che lavorano su uno specifico prodotto in un determinato stabilimento. Lapplicazione deve consentire ai manager di accedere alle informazioni relative ai dipendenti di cui sono responsabili, e a tutti di accedere alle informazioni sui prodotti.

Ingegneria del Software Modellazione

90

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 90

System Domain Model


Stabilimento 1..* 1..* Operaio 1..* Prodotto 1..* Linea di Prodotto * Assegnazione Supervisore

1..*

Responsabilit

3 +Responsabile Catalogo -Visualizza info prodotti() Manager --Controllo Accessi() --Leggi Info dipendenti()

Dipendente --Visualizza Mansione()

Ingegneria del Software Modellazione

91

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 91

Esercizio assegnato
Sviluppare il Modello di Dominio mediante un Class Diagram per il Sistema di Gestione Biblioteca. Le specifiche informali sono su web docenti (Cartella Esercizio Biblioteca).

Ingegneria del Software Modellazione

92

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 92

Altri diagrammi strutturali


Oltre ai Class Diagram, UML 2 propone altri diagrammi che possiamo definire strutturali, in quanto modellano aspetti statici della struttura del sistema:
Object Diagram (o diagrammi degli oggetti, o delle istanze) Package Diagram Component Diagram Deployment Diagram
93

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 93

Object Diagram
Un object diagram rappresenta una fotografia di un class diagram (o di una sua parte) in un determinato istante
In luogo di ogni classe compaiono uno o pi istanze di oggetti di quella classe, identificati con la notazione nomeoggetto:nomeclasse Si potrebbe disegnare un diagramma degli oggetti per ogni scenario di ogni caso duso Lo scopo degli object diagram (peraltro non utilizzati molto spesso) quello di chiarire le relazioni tra classi che possono istanziarsi in un particolare scenario desecuzione, mostrando, ad esempio, una specifica risoluzione di una situazione di polimorfismo

Ingegneria del Software Modellazione

94

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 94

Object Diagram
Gli archi rappresentano istanze di associazioni, quindi corrispondono ad archi gi presenti tra le classi corrispondenti nel class diagram (ovviamente negli object diagram sono omesse le cardinalit) Pat:Employee
Wayne:Employee OOCorp:Company Ali:Employee OOCorp's Board:

Carla:Employee

UML inc:Company

UML inc's Board

Terry:Employee

Ingegneria del Software Modellazione

95

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 95

Package diagram
Un package un contenitore di classi
In Java il package identificato dalla omonima keyword; in altri linguaggi esistono costrutti analoghi In UML (e anche in Java) possibile definire una visibilit (di classi, metodi o attributi), in termini di package, ovvero definire un elemento come visibile solo allinterno del package nel quale dichiarato Un package rappresenta uno spazio dei nomi (namespace): il nome completo che identifica una classe , quindi:
Nomepackage::nomeclasse

Ingegneria del Software Modellazione

96

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 96

Possibili rappresentazioni di un package

Da UML Distilled
Ingegneria del Software Modellazione 97

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 97

Suddivisione in packages
Dato un sistema software composto di molte classi, esiste un enorme quantitativo di possibili raggruppamenti delle classi in package. Quale scegliere?
Bisogna stabilire un principio secondo il quale operare il raggruppamento: in generale si dice che vengono raggruppate tra loro classi che presentano una buona coesione
Se ne discuter a margine della proposizione dei principi di progettazione, nelle prossime lezioni

Ingegneria del Software Modellazione

98

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 98

Dependency e generalization
Tra due packages pu insistere una relazione di dependency se esiste una coppia di classi appartenenti rispettivamente ai due packages e legate da una relazione di dependency

Ingegneria del Software Modellazione

99

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 99

Generalization e implementation
Allo stesso modo potrebbero essere considerate le generalizzazioni tra package oppure le relazioni tra classi concrete e classi astratte da esse implementate

Ingegneria del Software Modellazione

100

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 100

Faade
Si consideri un package; si voglia fornire al resto del sistema la possibilit di accedere solo ad un sottoinsieme delle operazioni implementate nelle varie classi del package Si implementa una classe Faade che:
Abbia visibilit public Richiami e fornisca attributi e metodi delle classi interne al package (invisibili allesterno del package stesso)
Stabilimento Azienda 1..* 1..* Operaio InfoStabilimento 1..* Prodotto InfoProdotto 1..* Linea di Prodotto * Assegnazione Supervisore

Classi Faade (public)

1..*

Responsabilit

3 +Responsabile InfoDipendente Catalogo -Visualizza info prodotti() Manager --Controllo Accessi() --Leggi Info dipendenti()

Dipendente --Visualizza Mansione()

Ingegneria del Software Modellazione

101

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 101

Considerazioni
I diagrammi dei package sono utili, nella progettazione di grandi sistemi, per poter suddividere il problema della progettazione in sottoproblemi pi piccoli e semplici da governare I package diagram sono, in generale, dei diagrammi di architettura, per cui essi possono essere utili nelle fasi di design e di implementazione, non in quella di analisi del problema

Ingegneria del Software Modellazione

102

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 102

Component diagrams
Il concetto di componente molto dibattuto, in UML Un componente un contenitore di altri elementi statici UML, come classi e package Spesso, il component si identifica come un componente fisico, come ad esempio un file contenente codice sorgente, oppure un file eseguibile, o un database, Altre volte il concetto di component coincide con quello di package (ad esempio nelle librerie java impacchettate in un unico file con estensione .jar) Nellaccezione UML 2, invece, un component pu anche contenere altri component al suo interno
103

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 103

Component diagrams
Il component diagram mostra insiemi di componenti e di relazioni tra loro
Per ogni component si suole mostrare esplicitamente linterfaccia che esso espone allesterno (utilizzando la notazione con lollipop)

Il diagramma dei componenti , quindi, un diagramma architetturale che mostra oggetti effettivamente realizzati, ma che non comprende informazioni sulla effettiva dislocazione fisica di tali componenti
104

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 104

Esempio di component diagram


In UML 1 (e anche in Star UML), si utilizzava un altro simbolo di componente:
Component

Simbolo di component

Per I componenti che non siano persistenti, ma siano istanziati a run-time (ad esempio una pagina web ottenuta in risposta ad una richiesta al web server), si utilizza il seguente simbolo:
ComponentInstance1

Interfaccia fornita e interfaccia richiesta

Ingegneria del Software Modellazione

105

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 105

Deployment Diagram
I diagrammi di deployment (in italiano dispiegamento) mostrano larchitettura fisica del sistema Lelemento fondamentale il nodo, corrispondente ad un elemento fisico del sistema (ad esempio una macchina o un dispositivo)
Allinterno dei nodi possono essere disegnati i component, in modo da poter collegare il deployment diagram ai component diagram corrispondenti Con il concetto di artifact si interpreta un qualsiasi oggetto fisico prodotto dal sistema

I prodotti dellelaborazione sono rappresentati dagli artifact

Gli archi di un deployment diagram corrispondono alle connessioni fisiche tra i suoi nodi

Ingegneria del Software Modellazione

106

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 106

Esempio di Deployment Diagram

Ingegneria del Software Modellazione

107

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 107

Altro esempio
GPS Satellite Wireless communication Machine1: Client1: Client2: TCP/IP Machine2: Server:

I deployment diagram sono dei diagrammi architetturali che possono essere utilizzati in fase di progetto architetturale e in fase di implementazione Talvolta necessario introdurli gi in fase di analisi del problema qualora si voglia rappresentare vincoli architetturali posti alla base del problema
Ingegneria del Software Modellazione 108

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 108

Composite structure diagram


Il composite structure diagram stato introdotto solo a partire da UML 2 Esso utilizzato per mostrare in maniera pi dettagliata la struttura interna ad una classe
Risulta utile nel progetto di dettaglio di classi particolarmente complesse

Nel composite structure diagram viene introdotto il concetto di porta (Port), intesa come punto di comunicazione tra linterno e lesterno della classe
109

Ingegneria del Software Modellazione

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 109

Esempio

Classe TVViewer e sue interfacce Nel composite diagram diventa evidente come Tuning e Picture stream influiranno sul Generatore (di immagini), mentre come il telecomando (TV control GUI) possa influire sui controlli Viceversa la API TV control pu agire direttamente su Generator
Ingegneria del Software Modellazione

Composite diagram della classe TVViewer


110

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 110

Subsystem diagrams
Operazioni
requestToRegister(aStudent) : boolean dropCourse(aStudent) getSchedule( ) : Iterator Specification Elements Register in a course Drop a course Display schedule Realization Elements * CourseSection * Registration * Student

Student Actor

Ingegneria del Software Modellazione

111

P Tramontana

Modelli di sistema- Introduzione a UML

Slide 111