7 ModellazioneStatica

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
P Tramontana
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
P Tramontana
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
P Tramontana
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
P Tramontana
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
P Tramontana
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
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
P Tramontana
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}
P Tramontana
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
10
P Tramontana
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
11
P Tramontana
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
P Tramontana
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
P Tramontana
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
14
P Tramontana
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
15
P Tramontana
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
16
P Tramontana
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)

17
P Tramontana
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

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
P Tramontana
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
20
P Tramontana
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
Prenotazione * * 1
Volo
21
P Tramontana
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

P Tramontana
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
23
P Tramontana
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
24
P Tramontana
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
P Tramontana
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

0..* paragrafo 1..*

26
frase
P Tramontana
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
27
P Tramontana
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:
28
P Tramontana
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 };
29
P Tramontana
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); }
30
P Tramontana
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);
31
P Tramontana
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
32
P Tramontana
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; };

P Tramontana
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;}
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
Slide 34
Gerarchia di Aggregazione
Veicolo
Chassis
Carrozzeria
Porta
Telaio
Motore
Trasmissione
Ruota
35
P Tramontana
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
P Tramontana
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.
37
P Tramontana
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
P Tramontana
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
P Tramontana
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
P Tramontana
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
P Tramontana
Slide 41
Esempio
Esempio tratto da UML Distilled

P Tramontana
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:

43
P Tramontana
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()
44
P Tramontana
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
P Tramontana
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()
47
P Tramontana
Slide 47
Altro esempio
Person
interface
Cashier
withdraw deposit
Machine
Person
Cashier
Machine
Cashier
Employee
ATM
Employee
ATM
Relazioni di <<realizzazione>>
48
P Tramontana
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
-- Gestisce l'inserimento, l'aggiornamento e la modifica degli esami() -- Gestisce le prenotazioni degli studenti all'esame()
Prenotazione
Studente
49
P Tramontana
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
50
P Tramontana
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
P Tramontana
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
P Tramontana
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)}
53
P Tramontana
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?
54
P Tramontana
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?)
P Tramontana
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
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.
57
P Tramontana
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.
58
P Tramontana
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
59
P Tramontana
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!
60
P Tramontana
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
P Tramontana
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
63
P Tramontana
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
64
P Tramontana
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!
P Tramontana
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
66
P Tramontana
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?)
67
P Tramontana
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
68
P Tramontana
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.
P Tramontana
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
70
P Tramontana
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
71
P Tramontana
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
P Tramontana
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
P Tramontana
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
75
P Tramontana
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
76
P Tramontana
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
77
P Tramontana
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.
P Tramontana
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
P Tramontana
Slide 79
Ricerca classi
80
P Tramontana
Slide 80
Ricerca associazioni ed attributi

81
P Tramontana
Slide 81
Ricerca generalizzazioni
82
P Tramontana
Slide 82
Ricerca e assegnazione di responsabilit

83
P Tramontana
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
P Tramontana
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
P Tramontana
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
P Tramontana
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.
87
P Tramontana
Slide 87
Ricerca associazioni ed attributi

88
P Tramontana
Slide 88
Ricerca generalizzazioni
89
P Tramontana
Slide 89
Ricerca e assegnazione di responsabilit

90
P Tramontana
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()
91
P Tramontana
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).
92
P Tramontana
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
P Tramontana
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
94
P Tramontana
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
95
P Tramontana
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
96
P Tramontana
Slide 96
Possibili rappresentazioni di un package
Da UML Distilled
P Tramontana
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
98
P Tramontana
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
99
P Tramontana
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
100
P Tramontana
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()
101
P Tramontana
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
102
P Tramontana
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
P Tramontana
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
P Tramontana
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
105
P Tramontana
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
106
P Tramontana
Slide 106
Esempio di Deployment Diagram
107
P Tramontana
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
P Tramontana
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
P Tramontana
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
Composite diagram della classe TVViewer

110
P Tramontana
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
111
P Tramontana
Slide 111

7 ModellazioneStatica

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

7 ModellazioneStatica

Încărcat de

Drepturi de autor:

Formate disponibile

Diagrammi strutturali in UML

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Tipi di Modello in UML 2

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

La signature completa di unoperazione :

Modelli di sistema- Introduzione a UML

Modelli di sistema- Introduzione a UML

Modelli di sistema- Introduzione a UML

direzione nome parametro: tipo = valore-di-default

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

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

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Molteplicit delle associazioni

Uno ed uno solo

una Persona possiede almeno una Automobile

UnAutomobile pu essere posseduta da una e una sola Persona

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Associazioni molti a molti

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Associazioni uno a uno

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Codifica delle associazioni

Possiede > Automobile 1..*

Possiede > Persona

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Codifica delle associazioni

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

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Associazione uno a molti

Associazione uno a uno

Ingegneria del Software Modellazione

Associazione uno a molti

Associazione uno a uno

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

Ingegneria del Software Modellazione

Modelli di sistema- Introduzione a UML

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

Un Passeggero pu avere pi prenotazioni

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

Modelli di sistema- Introduzione a UML

La classe associativa pu avere attributi, metodi, altre associazioni

Modelli di sistema- Introduzione a UML

Precede > * +Meglio classificato Atleta +Nome *