Upload
dokien
View
215
Download
2
Embed Size (px)
Citation preview
Ingegneria del Software
The Unified Modeling Language
Molte discipline ingegneristiche dispongono di validi mezzi di rappresentazione (schemi, diagrammi di prestazioni e consumi, ...)
Il software non dispone ancora di tecniche efficaci per descriverne la struttura, le funzionalità e le prestazioni
UML cerca di rimediare a questa situazione
• UML è diventato uno standard di fatto per object-oriented modelling
design
• Una “famiglia di notazioni”
Ingegneria del Software
Class Diagram
• Definiscono la visione statica del sistema
– classi
– relazioni tra classi
• associazione (uso)
• generalizzazione (ereditarietà)
• aggregazione (contenimento)
• È forse il modello più importante perché definisce gli
elementi base del sistema
Ingegneria del Software
Classi
• In UML una classe è composta da tre parti
– nome
– attributi (lo stato)
– metodi (il comportamento)
Professore
nome
cognome
create()
delete()
Professore
create()
delete()
Professore
nome
cognome
Professore
Ingegneria del Software
Professore
{abstract}
+ nome: String
# cognome: String
- età: integer = 32
+ visualizza()
- scegliCorso()
Professore
nome: String
cognome: String
età: integer
visualizza()
scegliCorso()
Professore
Visibilità
Ingegneria del Software
Classe
Attributo: visibilità nome: tipo [molteplicità] = default {stringa di proprietà}
Metodo: visibilità nome (lista parametri): tipo di ritorno {stringa di proprietà}
Visibilità: + public, - private, # protected, ~ friendly
Parametro: direzione nome: tipo = default
7
Dettagli classe
Ingegneria del Software
Traduzione
8
public class Persona { private String nome; private String cognome; private Date dataNascita; private static int numPersone; public boolean siSposa(Persona p) { … } public boolean compieAnni(Date d) { … } }
Classe UML e classe Java
Ingegneria del Software
Ereditarietà
• Le classi sono di solito organizzate in una gerarchia
• Le classi in cima alla gerarchia hanno caratteristiche
comuni a tutte le classi
• Le classi più in basso ereditano attributi e servizi dalle
classi superiori, ma possono essere specializzate se
necessario
• Ereditarietà è detta generalizzazione in UML
Ingegneria del Software
• Un package è una cartella che contiene altre entità
(oggetti, classi, altri package, …).
Pressure
controller
Temperature
controller
Alarm and
protection
Oxygen plant
(b) Package containing packages
Oxygen plant
(a) Package
symbol
UML package
Ingegneria del Software
Corso CartellaStudente appare
Associazioni
• Un’associazione indica una relazione tra classi
– ad esempio persona che lavora per azienda
• Un’associazione deve avere un nome
• Il nome è solitamente un verbo (un etichetta al centro
della linea che definisce l’associazione)
Ingegneria del Software
Corso Studente
3 .. 10 0..*
Molteplicità
segue
La molteplicità definisce il numero di oggetti che prendono parte alla
relazione
La molteplicità dice:
Se l’associazione è obbligatoria oppure no?
Il numero minimo e massimo di oggetti che possono essere
relazionati ad un altro oggetto
Ingegneria del Software
Molteplicità (cont.)
1 Esattamente 1
* zero o più
0..1 zero o uno
m..n entro gli estremi specificati
Ingegneria del Software
Esempio1
class Persona {
…
private Casa casa;
…
}
class Casa {
…
private Persona[] persone;
…
}
17
- casa - persone
Associazioni e molteplicità in Java
Associazioni
sono attributi
impliciti (con
visibilità)
Ingegneria del Software
Persona Azienda
lavora
Impiegato DatoreDiLavoro
1..* 0..1
Ruolo
• Definisce il ruolo svolto nell’associazione
Ingegneria del Software
Utente Directory
proprietario
utente autorizzato
contenente
contenuto
0..*
0..*
0..* 0..*
0..1
Ruolo (cont.)
• Il ruolo diventa “importante” quando una classe è
coinvolta più volte nella stessa associazione
Ingegneria del Software
Esempio2
20
class Persona { private String nome; private String cognome; private Date dataNascita; private static int numPersone; public Persona marito; public Persona moglie; public boolean siSposa(Persona p) { … } public boolean compieAnni(Date d) { … } }
Associazioni riflessive e ruoli
Ingegneria del Software
Esempio3
21
Associazioni con ruolo e verso
class Persona {
private String nome;
private String cognome;
private String codFiscale;
private int stipendio;
}
class Banca {
private Persona[] clienti;
}
class Prestito {
private int ammontare;
private int rata;
private Date dataInizio;
private Date dataFine;
private Persona intestatario;
private Banca banca;
}
Ingegneria del Software
Corso Curriculum 1..*
Aggregazioni
• Le aggregazioni sono una forma particolare di
associazione. Una parte è in relazione con un oggetto
(part-of)
• La traduzione in Java è simile al caso delle associazioni
Ingegneria del Software
Slider Panel Button
Window
1
2
1
1
1
1 scrollbar body close
2
1 1
1
1
1
Composizioni
• Una relazione di composizione è un’aggregazione forte
– Le parti componenti non esistono senza il contenitore
• Creazione e distruzione avvengono nel contenitore
• I componenti non sono parti di altri oggetti
Ingegneria del Software
Composizione (Notazioni Alternative)
body:Panel
scrollbar: Slider
close: Button
Window
1
1
2
body
scrollbar
close
Window
1
1
2 Slider
Panel
Button
Ingegneria del Software
Modello di un sistema
• Descrizione astratta del sistema di cui si stanno
analizzando i requisiti
• Modello è una specifica in cui è inclusa anche una
descrizione dell’ambiente in cui il sistema dovrà operare
Ingegneria del Software
System modelling
• Modellare il sistema (System modelling) aiuta gli analisti
a capire le funzionalità del sistema
• I modelli del sistema sono usati per comunicare con i
committenti
• Diversi modelli presentano il sistema da diverse
prospettive
– Esterna: Mostrare il contesto o l’ambiente
– Comportamentale (Behavioural): operazione svolte dal
sistema
– Strutturale: architettura del sistema
Ingegneria del Software
Object models
• Modelli a oggetti (Object models) descrivono il sistema in termini di classi di oggetti
• Una classe è un'astrazione di un insieme di oggetti come costituiti da attributi comuni e da servizi (operazioni) fornite da ogni oggetto.
• Modo naturale di descrivere le entità del mondo reale manipolate dal sistema
• Identificazione delle classi è un processo difficile che richiede una profonda conoscenza del domino dell'applicazione
• Le classi che rispecchiano il dominio dell'applicazione, sono riutilizzabili per definire sistemi diversi
Ingegneria del Software
Concetti base
• Oggetti
• Classi
• Relazioni tra classi
• Questi concetti si ritrovano nella (sono ispirati dalla)
Programmazione ad Oggetti, ma lo scopo è molto
diverso.
• Oggetti qui possono essere entità del mondo reale, non
solo elementi di un programmnon sono
Ingegneria del Software
Oggetti
• Un oggetto è un concetto, un’astrazione o una “cosa”
con un significato ben preciso per l’applicazione in
esame
• Un oggetto è un’entità:
– fisica
– concettuale
– software
Ingegneria del Software
Stato
• Lo stato rappresenta la condizione in cui si trova
l’oggetto
• Lo stato è definito dai valori delle proprietà (attributi)
• Gli oggetti possono essere suddivisi in:
– passivi (lista di nomi)
– attivi (orologio, persona)
Ingegneria del Software
Comportamento
• Determina come agisce e reagisce un oggetto
– cambiamenti di stato e “reazioni” verso altri oggetti
• È definito dall’insieme di operazioni che l’oggetto può compiere
Apriti !
Ingegneria del Software
Operazioni
• Un’operazione è un servizio fornito dagli oggetti della
classe.
• L’insieme delle operazioni definiscie il comportamento
• Tutte e sole le operazioni rilevanti per il dominio
applicativo
– Bancario
• ricevePrestito, riceveCredito, apreConto
– Medico
• faEsame, prendeMedicina, vaOspedale
Ingegneria del Software
Classi
• Una classe è un gruppo di entità identificato da un
insieme di caratteristiche comuni
• Una classe è un “modello” per descrivere oggetti con
proprietà simili
• La classe è un’astrazione della realtà
– enfatizza alcune caratteristiche
– tralascia altre proprietà
Ingegneria del Software
Relazioni (associazioni)
• Oggetti e classi partecipano a relazioni ("associazioni" in
UML) con altri oggetti e classi
• Associazioni possono essere annotate con informazioni
che descrivono l'associazione
– Nessun significato formale…
• Associazioni possono anche indicare un oggetto è
associato con uno (o più) metodi o attributi di altri oggetti
Ingegneria del Software
Classificare le entità
• Utile minimizzare numero delle classi per migliorare produttività e riusco.
• Eseguire classificazione degli oggetti, identificando fattori in comune:
– funzione e comportamenti
– Qualità (attributi).
• Esempio: prima classificazione suddivide in tre gruppi: sensor, controller and actuator.
• Gli attuatori sono fra loro identici, ma I sensori hanno dettagli diversi
• Cosa fare?
Airspeed
Height
Attitude
Roll actuator
Yaw actuator
Pitch actuatorSystem
controller
(a) System Objects
Sensors
Airspeed
Height
Attitude
Controllers
System
Actuators
Roll
Pitch
Yaw
(b) Grouping of system objects
Ingegneria del Software
User class hierarchy N a m e
A d d re ss
P h on e
R e gi st ra t io n #
L i br a ry us e r
R e gi st e r ( )
D e - r e gi st e r ( )
A ff il ia t io n
Re a de r
I te m s o n l oa n
M a x. lo a ns
B o rro w e r
D e p a r tm e n t
D e p a r tm e n t ph on e
S t a ff
M a jo r s ub je c t
H o m e a d d re ss
S t ud e nt
Ingegneria del Software
Vantaggi ereditarietà per OOA
• Meccanismo di astrazione utile per classificare entità e trovare relazioni fra
entità simili
– Es.: vari tipi di sensori sono diversi ma hanno caratteristiche comuni,
fattorizzabili in una classe sensore, da cui le altre ereditano.
• Meccanismo di riuso, sia per l'analisi del dominio, che a livello di design e di
programmazione
• Il grafo dell'ereditarietà è sorgente di informazione organizzativa sul dominio
dell'applicazione e sui sistemi realizzati, utile anche documentazione
• Svantaggio: Problema di leggibilità
– classi non sono entrocontenute: occorre leggere anche le superclassi
per capirle…
Ingegneria del Software
Multiple inheritance
• Possibilità di ereditare da più classi
• Può portare a conflitti fra attributi o servizi con lo stesso nome
ereditati da classi diverse
# Ta pe s
T a lk in g bo ok
A u th or
E d it io n
P u bl ic a t io n d a t e
I S B N
B o ok
S p e ake r
D u ra t io n
Re c ord in g d a t e
V o ic e r e c or d in g
Ingegneria del Software
Analisi vs. Design
OOA OOD Modello dei requisiti
Aggiunta di dettagli e decisioni progettuali
Punto di vista dell’utente Punto di vista del progettista
Transizione OOA -> OOD presenta spesso
discontinuita’: scelte architetturali.
Ingegneria del Software
Object-oriented Design
• La progettazione del software può essere descritta come
un insieme di oggetti software interagenti che gestiscono
il proprio stato e le proprie operazioni
• Vari modelli per descrivere OOD, e UML può essere
usato per rappresentarli
Ingegneria del Software
Vantaggi di OOD
• Manutenzione semplificata. Oggetti comprensibli come
entità stand-alone
• Oggetti sono componenti riusabili
• Per molti sistemi, c'è una chiara corrispondenza fra le
entità del "mondo reale" (persone, ruoli, dispositivi…) e
gli oggetti del sistema
Ingegneria del Software
Oggetti in OOD/OOP
• Oggetto: entità in memoria, con uno stato e un insieme
definito di operazioni che manipolano lo stato.
– lo stato è rappresentato dai valori in memoria degli attributi
dell'oggetto.
– Le operazioni forniscono servizi ad altri oggetti (clienti),
che li richiedono quando necessario.
• Oggetti sono creati secondo quanto definito nella classe
corrispondente.
– Una classe è quindi uno "stampo" per creare oggetti dello
stesso tipo.
– Include dichiarazioni di tutti gli attributi e servizi che
dovrebbero essere parte degli oggetti della classe.
Ingegneria del Software
Object-oriented development
• Object-oriented analysis, design and programming: correlate ma distinte
– OOA: sviluppare un modello a oggetti del dominio applicativo e individuare le responsabilità del sistema da sviluppare
– OOD: sviluppare un modello object-oriented di un sistema che implementa i requisiti
– OOP: realizzare un design object-oriented usando un linguaggio di programmazione OO (Java, C++,…)
• E' possibile utilizzare solo OOA, oppure solo OOA e OOD e poi implementare in linguaggio tradizionale come C (ma allora alcuni accorgimenti…)
Ingegneria del Software
Esempio
movimento
DisplayPulsantiera
Controllo SistemaAscensore
Piano
visualizzazioneposizione
visualizzazionerichieste
prenotazione
richieste
Ingegneria del Software
Diagramma di deployment
Cellulare2
JME JME
client.jarserver.jar
client.jar
Cellulare1
TCP/IP
Ingegneria del Software
Database server
prenotazioni.myd
Application server
gestPrenotazioni.ear
Web server
prenota.war
Cellulare
browser
http/Internet
Ingegneria del Software
Modellare il comportamento
• Comportamento: modalità di interazione fra oggetti
• Sequence diagrams sono utilizzati a tale scopo
Ingegneria del Software
Diagrammi di sequenza
I diagrammi di sequenza rappresentano interazioni tra oggetti
Materializzazione di scenari specifici
Sono utili per
Evidenziare le interazioni tra oggetti e quindi i metodi da associare alle diverse classi
Provare l’efficacia dei servizi identificati
56
Diagrammi di sequenza
Ingegneria del Software
Distribuzione di materiale in formato
elettronico
: L ib r a r y U s e r
E c a t :
C a ta l o g
L o o k u p
I ss u e
D i s p l ay
: L ib r a r y I te mL i b 1 :
N e t S e r v e r
I ss u e li c e n c e
A c c e p t li c e nc e
C o m p r e ss
D e l iv e r
Ingegneria del Software
State Diagrams models
• Modellano il comportamento del sistema come risposta a
eventi interni e esterni
• Particolarmente adatti a sistemi reattivi e in tempo reale
(descrivono risposte a stimoli esterni)
• Stati = nodi, eventi= archi fra i nodi. Quando accade un
evento il sistema si sposta da uno stato all'altro
Ingegneria del Software
StateCharts
Gli Statecharts sono un'estensione degli automi a stati finiti,
tipicamente utilizzati per descrivere sistemi di controllo.
Dovuti a David Harel, primi anni ‘80.
Specificano tramite diagrammi (charts) il comportamento di
un sistema o di singoli oggetti
La compatezza della loro rappresentazione permette di
controllare l’esplosione degli stati
Ingegneria del Software
Caratteristiche
Una specifica e’ scomposta in vari oggetti comunicanti.
Ogni oggetto e’ un automa a stati finiti descritto in termini di:
Eventi a cui gli oggetti sono “sensibili” (segnali, chiamate di metodi, passaggio del tempo, cambi di stato di altri oggetti)
Azioni prodotte in risposta agli eventi
Transizioni di stato
Possibilità di descrivere evoluzioni parallele e cooperanti degli oggetti.
Ricca notazione grafica per rendere piu’ semplice la descrizione
Ingegneria del Software
StateCharts: blocchi base della notazione
Stato
Decomposizione OR
Decomposizione AND
azione
Transizione
evento [condizione]
Ingegneria del Software
Identificare gli stati
Analizzare tutti gli stati in cui un oggetto può trovarsi
Usare gli use case e gli scenari
Definire un livello di dettaglio giusto e omogeneo
Identificare gli attributi significativi
Individuare le condizioni limite
Ingegneria del Software
Esempio (senza stato finale):
centrale telefonica
Messaggio Vocale
Inattivo
Tono Pronto
Compos. Numero
ProntoA Connettere
Tono Libero
Connesso
Tono Occupato
Tono TimeOut
Chiamante.Aggancia
FineMessaggio
T
T Compone(n)
NumValido
NumNonValido
Occupato
Chiamante.Aggancia
Chiamante.Sgancia
Ricevente.Sgancia
Instradato
Compone(n)
Ingegneria del Software
Inizio e Fine
Inizio Bianco Muovere
Nero Muovere
Matto o Abbandono
Stallo o Accordo
Mossa Bianca
Mossa Nera
Vince Nero
Vince Bianco
Patta
Matto o Abbandono
Stallo o Accordo
Ingegneria del Software
Pronto Verde [incrocio.stato=libero]
InCorsa
Condizione Evento
Condizioni
Funzioni booleane sui valori degli oggetti
Opzionali, ma utili Utili quando non basta l'evento, ma si
vuole aggiungere un predicato
Anche evento e’ opzionale: ci puo’ essere solo condizione
Ingegneria del Software
Operazioni
Azioni
Operazioni che hanno durata istantanea
Tipicamente produzione di eventi
Sono associate alle transizioni di stato oppure all'ingresso o
all'uscita da uno stato
Attività
Sono operazioni con durata significativa
Sono associate ad uno stato
Continue o sequenziali
Possono essere descritte con linguaggio di programmazione
Ingegneria del Software
event3 [condizione1] / azione5
event4 [condizione2] / azione6
do: attività1
entry / azione1
exit / azione2
event1 / azione3
event2 / azione4
Nome
attributo1: tipo1 = val.iniziale
attributo2: tipo2 = val.iniziale
Stato Completo
In ogni stato si possono dichiarare variabili, da
inizializzare opportunamente.
Ingegneria del Software
right-mouse-down(location) [location in window] /
object:=pick-object(location) ^object.highlight() 0 Oggetti
selezionati
1 Oggetto
selezionato
Eventi (Generati da Azioni)
Spesso le azioni consistono nell'inviare un evento ad un
altro oggetto : questi sono detti eventi INTERNI
Ingegneria del Software
Eventi (2)
Gli eventi ESTERNI sono invece quelli non generati dal
sistema.
Gli eventi (interni e esterni) sono messi in una coda
(buffer FIFO) ed estratti uno alla volta.
Se nessuna transizione associata all’evento e’ in grado di
scattare, l’evento e’ perduto.
Attenzione a catene infinite di eventi in composizione
parallela (A invia evento e1 a B che in risposta invia e2
ad A che invia e1 a B, …)
Ingegneria del Software
State Diagram Piatti
La complessità cresce esponenzialmente
Descresce l’espressività e la comprensibilità
Diagrammi Strutturati
Favoriscono la sintesi e aumentano la leggibilità
Generalizzazione (macro stati)
Aggregazione (stati concorrenti)
Ingegneria del Software
Folle RetroMarcia
MarciaAvanti
Prima Seconda Terza
levaR
levaN
levaF levaN
accelera accelera
decelera decelera
ferma
Cambio Automatico
Diagrammi a stati strutturati
Un macro stato equivale ad una scomposizione Or degli stati
I sottostati ereditano le transizioni dei loro superstati
Ingegneria del Software
History
History può essere associata a stati non foglia
Quando l’esecuzione lascia uno stato S con history
Si salva l’ultimo stato visitato S1 in S
Quando l’esecuzione ritorna in S
Si riparte da S1
H
A A1
A2
B
Ingegneria del Software
Registrazione Corsi
Creazione Selezione corsi
Selezione corsi extra
Sospeso
Salva
Sottometti
corsiE < 2
corsi < 4
sospendi
ricomincia
quit
corsiE = 2
giorni > 3
corsi = 4
H
Ingegneria del Software
Concorrenza di due attività
Guida Normale
do: guida
do: guida
do: sms
Guida distratta
sms clacson
Guida Attenta
do: guida piano invia
Ingegneria del Software
Sottostati Concorrenti. Decomposizione AND
lab1 lab2
progetto
scritto passato
Incompleto
non passato
Ingegneria del Software
Oggetti Compositi
Accendino
Serbatoio
Fornello
Vuoto
Serbatoio
Chiuso
Acceso Aperto
Fornello
carica
Pieno
[gas = 0]
[gas > 0]
apri
scintilla
chiudi
Ingegneria del Software
Interazione fra Componenti
Vuoto
Serbatoio
Chiuso
Acceso Aperto
Fornello
carica
Pieno
[gas = 0]
[gas > 0]
apri
[Serbatoio.stato == Pieno]
chiudi
scintilla
Ingegneria del Software
Microwave oven model
F u ll pow e r
E n a b l e d
d o : op e r a te
o ve n
F u ll
p ow e r
H a l f
p ow e r
H a l f
p ow e r
F u ll
p ow e r
N u m b er
T i m e r
D o or
o pe n
D o or
c lo se d
D o or
c lo se d
D o or
o pe n
S t a rt
d o : se t po w e r
= 6 00
H a l f p ow e r
d o : se t po w e r
= 3 00
S e t ti m e
d o : ge t nu m be r
e x i t: s e t t im e
D i s ab l ed
O p e r a ti on
T i m e r
C a nc e l
W a it in g
d o : d i sp la y
ti m e
W a it in g
d o : d i sp la y
ti m e
d o: d i sp la y
' R e a dy '
d o : d i sp la y
' W a it in g '
Ingegneria del Software
Microwave oven operation
C o ok
d o: run
ge ne ra t or
D o ne
d o: bu z z e r on
f or 5 s e c s.
Wa it in g
A l a rm
d o: d i sp la y
ev e nt
d o: c he c k
s ta tu s
C h ec k in g
T u rn ta b le
fa ul t
E m i tt e r
f a ul t
D i s ab le d
O K
T i m eo ut
T i m e
O p e r at i on
D o or
o pe nC a nc e l