Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
P Tramontana
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
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
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
Ingegneria del Software Modellazione 8
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}
Ingegneria del Software Modellazione
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:
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!
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
Nellesempio,
Questesempio si configura come associazione uno a molti (una Persona, molte Automobili)
13
P Tramontana
Slide 13
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
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
Automobile 1..*
Possiede > 1 1..* Automobile
Persona
16
P Tramontana
Slide 16
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; };
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
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; };
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
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
P Tramontana
Slide 22
Associazioni riflessive
Associazioni che collegano una classe con se stessa
Propedeutico > * *
Corso
* *
In alternativa a
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 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
Slide 25
0..1 titolo
1 sezione
sottosezione 0..*
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
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
29
P Tramontana
Slide 29
30
P Tramontana
Slide 30
31
P Tramontana
Slide 31
32
P Tramontana
Slide 32
P Tramontana
Slide 33
//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
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
Ingegneria del Software Modellazione 36
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
In alternativa, possibile usare una relazione di implementazione (o realizzazione) tra una classe concreta ed una interfaccia
38
P Tramontana
Slide 38
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
P Tramontana
Slide 41
Esempio
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
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
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
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
Slide 49
50
P Tramontana
Slide 50
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
LinearShape
1..*
LineSegment
startPoint: Point endPoint: Point length : int
Path
length
Line
{edge->size=1}
Polygon
{edge->first.startPoint = edge->last.endPoint}
{length = edge.length->sum}
RegularPolygon
{edge->forAll(e1,e2 | e1.length = e2.length)}
53
P Tramontana
Slide 53
54
P Tramontana
Slide 54
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
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
Slide 55
Person
name placeOfBirth dateOfBirth placeOfDeath child dateOfDeath *
Woman
0..1
Man
Union
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
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
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 }
P Tramontana
Slide 61
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
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!
Ingegneria del Software Modellazione 65
P Tramontana
Slide 65
66
P Tramontana
Slide 66
67
P Tramontana
Slide 67
68
P Tramontana
Slide 68
qualche altra classe del modello Specificare le molteplicit da entrambi i lati. Assegnare un nome chiaro allassociazione.
Ingegneria del Software Modellazione 69
P Tramontana
Slide 69
Restituisce
Prestito
SocioLibreria
ArticoloLibreria
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
71
P Tramontana
Slide 71
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
P Tramontana
Slide 73
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.
Ingegneria del Software Modellazione 78
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
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
P Tramontana
Slide 80
P Tramontana
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
P Tramontana
Slide 82
P Tramontana
Slide 83
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
Slide 84
P Tramontana
Slide 85
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
88
P Tramontana
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.
89
P Tramontana
Slide 89
90
P Tramontana
Slide 90
1..*
Responsabilit
3 +Responsabile Catalogo -Visualizza info prodotti() Manager --Controllo Accessi() --Leggi Info dipendenti()
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
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
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
Da UML Distilled
Ingegneria del Software Modellazione 97
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
1..*
Responsabilit
3 +Responsabile InfoDipendente Catalogo -Visualizza info prodotti() Manager --Controllo Accessi() --Leggi Info dipendenti()
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
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
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
Gli archi di un deployment diagram corrispondono alle connessioni fisiche tra i suoi nodi
106
P Tramontana
Slide 106
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
Ingegneria del Software Modellazione 108
P Tramontana
Slide 108
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
Ingegneria del Software Modellazione
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