1
UMLUnified Modeling Language (UML)
Lo standard emergente nella progettazione del software (e non solo)
Ken Jacobs, Oracle Vice-president:
“… Le definizioni dei dati per i database ad oggetti sono
di difficile comprensione se si esamina la loro
espressione testuale. Con una rappresentazione
grafica si possono, invece, facilmente capire le
relazioni tra essi ed il resto del DB.”
Perchè usare la progettazione visuale?
Mary Loomis, HP - Software Technology Laboratory:
“… la progettazione visuale e le tecniche di
rappresentazione visuale (…) permettono di
rappresentare le specifiche in un modo comprensibile sia
per le persone che per i tool di sviluppo”
Perchè usare la progettazione visuale?
n John Roskill, Microsoft - Director of Product
Marketing for Microsoft Visual Studio:
“… Noi riteniamo la progettazione visuale molto
importante nello sviluppo delle applicazioni di livello
‘enterprise’ basate su componenti (…) perché permette
di gestire la complessità dell’applicazione.”
Perchè usare la progettazione visuale?
Breve storia dell’UML
2
La storia dell’UMLNov ‘97 UML viene approvato dall’OMG
Cosa è l’UML
Cosa è l’UMLStruttura dell’UMLObiettivi dell’UML
Che cos’è l’UML?
UML è l’acronimo di Unified Modeling Language
È un linguaggio visuale per la specifica, la costruzione e la documentazione di sistemi software complessi
UML: Unified ModelingLanguage
n Un linguaggio "standard" (accettato dall'OMG) per la modellazione di sistemi software
n UML deriva dalla "integrazione" di modelli preesistenti (proposti nel contesto di metodologie):n Booch et al.n OMT (Rambaugh et al.)n OOSE (Jacobson et al.)
n Gli autori di UML sono Booch, Rumbaugh e Jacobson
UML: principi ispiratorin Modellazione (allo scopo di produrre software
migliore)
n La modellazione è essenziale in ogni attività ingegneristica complessa, in quanto permette di astrarre e semplificaren “costruiamo modelli per comprendere meglio i sistemi
che stiamo sviluppando” [Booch et al: The UML UserGuide]
n “costruiamo modelli di sistemi complessi altrimenti nonpotremmo comprendere tali sistemi nella loro interezza”
Finalità della modellazionen Visualizzazione del sistema (così com'è o come lo si
vorrebbe) in quanto “una figuravale più di mille parole”n Specifica della struttura e del comportamento di un
sistema in maniera precisa, completa e senza ambiguitàn Definizione delle linee guida per la costruzione di un
sisteman forward engineeringn reverse engineering
n Documentazione delle decisioni prese
n UML è stato pensato per supportare tutto questo
3
UML, questioni generalin Diagrammi e viste
n i diagrammi sono una “rappresentazione” dei vari aspettidell’applicazione
n ogni diagramma descrive una vista della applicazione secondo unacerta prospettiva
n Abbellimenti (adornments): n per ogni costrutto esiste una notazione grafica base, cui possono
essere aggiunti dettagli e noten Distinzioni di base:
n classe-oggetto (schema-istanza); notazione:n classen oggetto :classe :classe oggetto
n interfaccia-implementazione
I diagrammi di UML
Use CaseDiagramsUse Case
DiagramsUse CaseDiagrams
ScenarioDiagramsScenario
DiagramsCollaborationDiagrams
StateDiagramsState
DiagramsComponentDiagrams
ComponentDiagramsComponent
DiagramsDeploymentDiagrams
StateDiagramsState
DiagramsObjectDiagrams
ScenarioDiagramsScenario
DiagramsStatechartDiagrams
Use CaseDiagramsUse Case
DiagramsSequenceDiagrams
StateDiagramsState
DiagramsClassDiagrams
ActivityDiagrams
Models
I diagrammi di UML (9 tipi diversi)
n Diagramma delle classi (Class)n Diagramma degli oggetti (Object)n Diagramma dei casi di uso (Use case)n Diagrammi di interazione (Interaction)
n Diagramma di sequenza (Sequence)n Diagramma di collaborazione (Collaboration)
n Diagramma delle attività (Activity)n Diagramma degli stati (Statechart)n Diagramma dei componenti (Component)n Diagramma della distribuzione dei componenti
(Deployment)
Obiettivi dell’UMLn 1) Fornire all’utente un
linguaggio di specifica espressivo, visuale e pronto all’uso
n 2) Offrire meccanismi di estensibilità e specializzazione del linguaggio
n 3) Essere indipendente dagli specifici linguaggi di programmazione e dai processi di sviluppo
n 4) Incoraggiare la crescita dei toolOO commerciali
n 5) Supportare concetti di sviluppo ad alto livello come frameworks, pattern ed i componenti
n 6) Integrare i migliori approcci.
Cosa non è l’UML
n Non è un linguaggio di programmazione visuale (è un linguaggio di specifica visuale)
n UML non è un modello per la definizione di interfacce
n UML non è dipendente dal paradigma di sviluppo nel quale può essere utilizzato
Parti di UML
4
UML
UML può essere suddiviso in due grandi parti:
nDiagrammi strutturalinDiagrammi comportamentali
Diagrammi strutturali
Diagrammi di classe: Descrivono le classi di oggetti che compongono il sistema, ossia gli aspetti che accomunano diversi oggetti nella loro struttura e nel loro comportamento
Diagrammi di implementazione: Illustrano le interazioni nel sistema organizzandole attorno agli oggetti e ai legami tra gli oggetti
Diagrammi comportamentali
Diagrammi di attività:Forniscono la sequenza di operazioni “elementari” che definiscono un’attività più complessa
Use case diagrams Specificano il comportamento del sistema, ossia come il sistema agisce e reagisce dal punto di vista degli attori (possibili figure di utenti del sistema)
Sequence diagrams Forniscono una rappresentazione dei vari “scenari” che possono verificarsi nel ciclo di vita del sistema orientata a visualizzare in sequenza le interazioni tra gli oggetti del sistema. Quando due oggetti interagiscono? E cosa trasmettono l’uno all’altro?
Diagrammi comportamentali
Collaboration diagramsIllustrano le interazioni nel sistema organizzandole attorno agli oggetti e ai legami tra gli oggetti (come i Sequence Diagrams descrivono i possibili scenari, ma da un diverso punto di vista)
Statechart diagrams (diagrammi di stato)
Descrivono il "ciclo di vita" degli oggetti del sistema, visualizzando in che modo essi vengono modificati da eventi che possono occorrere nella processo di funzionamento del sistema
Diagrammi comportamentaliComponent diagramsRappresentano come i moduli software del sistema (le componenti) sono organizzati e quali sono le loro dipendenze
Deployment diagrams (diagrammi di allocazione)
Illustrano la dislocazione al run-time dei nodi elaborativi, delle componenti, dei processi e degli oggetti che risiedono presso di essi.
Diagrammi comportamentali
5
Use Cases Diagram
Diagramma dei casi d’usoCi sono modi diversi di guardare a un SISTEMA. Ø"aprirlo" e guardarci dentro, per vedere come è strutturato all'interno ( punto di vista del progettista)Ø guardare a come può essere utilizzato. In questo caso il sistema viene visto come una "black box", sigillata, ed è possibile osservarne solo i comportamenti dall'esterno ( punto di vista dell'utilizzatore, e di tutto ciò che interagisce con il sistema nell'ambito del suo funzionamento).Questo secondo punto di vista corrisponde al modello dei casi d'uso.
Casi d’uso§ Il termine "use case" è stato coniato dal
metodologo svedese Ivar Jacobson.
§ I casi d'uso sono semplicemente i modi in cui il sistema può essere utilizzato.
I casi d'uso svolgono un duplice ruolo nello sviluppo di un sistema.
§ nelle fasi iniziali della progettazione, servono per chiarire cosa dovrà fare il sistema.
§ guidano l'intero progetto di sviluppo.
Casi d’uso
Caso d’usoUn caso d’uso rappresenta un’interazione tra un utente ed il sistema: cattura le funzionalità del sistema da realizzare così come esse sono percepite dall’utente.
I casi d’uso sono le azioni che un utente intraprende in un sistema
Registra voti
Un sistema è qualcosa che svolge una funzione
Secondo UML, modellare la realtà d’interesse significa:
• individuare tutti i possibili casi d’uso del sistema
• individuare tutti gli utenti dei singoli casi d’uso (attori)
• rappresentare le interazioni tra casi d’uso e utenti
Modellare la realtà
6
Attore – cosa è?
Qualcuno o qualcosa, esternoal sistema, che interagisce con
i casi d’uso.
Ogni attore corrisponde ad un insieme coerente di ruoli che i soggetti esterni possono assumere interagendo con il sistema.
Attore – cosa è?
Gli attori comunicano con il sistema inviando o ricevendo messaggi: forniscono lo stimolo “trigger” agli use case; ciò equivale a dire che ogni caso d’uso deve essere avviato da una esplicita richiesta di un attore
Primari (o attivi): avviano le funzionalità proprie del sistema, forniscono uno stimolo al sistema
Secondari: fruiscono di informazioni o notifiche generate da use case eseguiti da altri attori, ricevono messaggi e non forniscono un vero e proprio stimolo
Individuazione Attore
Primari (o attivi): avviano le funzionalità proprie del sistema, forniscono uno stimolo al sistema
Secondari: fruiscono di informazioni o notifiche generate da use case eseguiti da altri attori, ricevono messaggi e non forniscono un vero e proprio stimolo
Individuazione Attore
Sistema
E' l'entità i cui utilizzi vengono descritti dall'insieme dei casi d'uso.
Un insieme completo di casi d'uso descrive in modo completo gli utilizzi del sistema dall'esterno, ossia dal punto di vista degli attori che interagiscono con esso,
senza rivelare la struttura interna del sistema
SistemaUn confine ideale separa ciò che è interno al sistema da ciò che ne è al di fuori.
i casi d'uso rientrano all'interno del contesto del sistema, mentre tutti gli attori sono esterni al sistema.
7
Confini del Sistema
nIl primo passo nella realizzazione dei modelli dei casi d’uso consiste nello stabilire con precisione il confine del sistema.
nLa definizione del contesto del sistema è una delle attività più delicate di un progetto,
APPROCCIO ITERATIVO INCREMENTALE
Una buona idea consiste nell’individuare il “core” del nuovo sistema (le funzionalità indispensabili).
Attori e casi d’usoOgni caso d'uso è collegato agli attori, uno o più, che partecipano al caso d'uso stesso mediante una associazione, che ha il significato di "comunicazione" (rappresentata da una linea continua che collega attore e caso d'uso).
comunicazione bi-direzionale
La comunicazione tra attori e casi d'uso, nei due sensi, avvienetramite segnali, ed è pertanto da considerarsi asincrona.
Attori e casi d’uso
L'associazione può essere orientata (ed essere quindi rappresentata con una freccia), per evidenziare la direzione delle comunicazioni nell'interazione (si tratta di una estensione definita nel profilo UML relativo al Software Development Process).
comunicazione unidirezionale
Associazioni tra attoriL'unica associazione ammessa tra attori è la specializzazione o generalizzazione.
ØL'attore specializzato eredita il comportamento del genitore e loestende in qualche maniera
ØL'attore specializzato eredita la partecipazione a tutti i casi d'uso con i quali comunica l'attore generico, ma può partecipare ad ulteriori casi d'uso ai quali l'attore generico non è collegato.
La relazione di specializzazione, in UML, è espressa graficamente con una linea continua, e con una punta di freccia triangolare ebianca.
GeneralizzazioneUn attore che ne specializza un altro può sempre essere utilizzato al posto di quello esteso (genitore o padre)
Cattiva organizzazione gerarchica attori
8
Diagramma ristrutturato
Esempio organizzazione gerarchica attori in un sistema
Associazioni tra casi d’usoOgni caso d'uso descrive un utilizzo completo del sistema, e non è quindi ammessa in UML la possibilità che casi d'uso distinti abbiano tra loro un'associazione di comunicazione.
Associazioni tra casi d’usoLe associazioni ammesse sono tre:
• Generalizzazione/Specializzazione• extend• include
L'effetto globale dell'utilizzo delle associazioni tra casi d'uso è comunque quello di una frammentazione del singolo caso d'uso, anche se basata sull'"emersione" di particolarità (specializzazione edextend) o di comportamenti comuni (include).
Generalizzazione/SpecializzazioneAssocia un caso d'uso di tipo generale ad uno o più casi d'uso specializzati.
Generalizzazione/Specializzazione
n Ogni caso d'uso generale può avere più figli (casi d'uso specializzati).
n Ogni caso d'uso può avere più padri, cioè specializzare diversi casi d'uso generali.
n L’esecuzione di use case “fratelli” può avvenire solo in alternativa
9
Esempio Generalizzazione/Specializzazione
n Il diagramma indica la proiezione statica delle funzionalità: specifica che il caricamento di un ordine richiede la validazione dell’utente e la verifica dell’ordine stesso.
n Il diagramma non specifica nulla circa la dinamica dell’operazione
Diagramma degli eventi
n Codice cap 3 pag 41.
Generalizzazione/Specializzazione
n Il comportamento specifico di un caso d’uso figlio può essere indicato inserendo opportune sezioni osovrascrivendone altre nella sequenza di azioni ereditate dallo use case genitore (in modo del tutto analogo a quanto succede con i metodi nelle classi)
n Quando il caso d’uso geneitore è astratto lo usecase ereditante deve provvedere,
Include
n Casi d'uso diversi possono avere in comune una sequenza di passi da svolgere. In questo caso è possibile enucleare la sequenza comune, e definirla come un caso d'uso a sé stante, da "includere" nei casi d'uso originari.
n Così facendo si evidenziano le parti comuni, e si evitano le ripetizioni nelle descrizioni dei casi d’uso.
10
Include
n In termini di sequenza di azioni, che ciascun caso d’uso esegue per erogare il servizio, la relazione di Include comporta l’esecuzione della sequenza di azioni dello use case incluso sotto il controllo e nella locazione specificata nello use case base.
Use case che include
Use case incluso<<include>>
Include
•Ogni caso d'uso può includere un numero illimitato di altri casi d'uso. Viceversa, ogni caso d'uso può essere incluso in un numero illimitato di altri casi d'uso.•L'associazione di inclusione è rappresentata da una dipendenza (linea tratteggiata, punta della freccia aperta) con lo stereotipo <<include>> , la cui direzione va dal caso d'uso "includente" al caso d'uso "incluso".
Esempio Include
n Il concetto di inclusione è per molti versi analogo a quello di invocazione di una funzione: viene eseguita la sequenza di azioni dello use case base quando viene raggiunto un punto di inclusione il controllo viene passato al caso d’uso ivi indicato (incluso) e ne viene eseguita completamente la sequenza di azioni, quindi il controllo ritorna allouse case base.
Esempio Extend
n L'associazione "extend" permette di definire che un caso d'uso "base" può venire "esteso" con il comportamento definito in un altro caso d'uso, detto di estensione.
n L'estensione riguarda un comportamento opzionale del caso d'uso base, ed è soggetta ad una condizione di attivazione.
n Il caso d'uso base "ignora le proprie estensioni". La sequenza dei passi che lo descrive è in sé completa, e non contiene alcun riferimento alle condizioni ed ai comportamenti definiti nel caso d'uso di estensione.
11
Extend
Use case che estende
Use case esteso
nL'associazione di estensione è rappresentata da una dipendenza (linea tratteggiata, punta della freccia aperta) con lo stereotipo <<extend>> , la cui direzione va dal caso d'uso "di estensione" al caso d'uso "base".
<<extend>>
Extendn L'unica particolarità che contraddistingue un caso
d'uso soggetto ad estensioni è che nell'ambito della sua sequenza vengono definiti uno o più punti di estensione ("extension point"), che sono dei punti di ancoraggio ai quali si agganceranno i casi d'uso di estensione.
n I punti di estensione possono essere rappresentati in un comparto specifico dell'ellisse che rappresenta il caso d'uso base.
Extend: funzionamenton Il funzionamento prevede che quando una
istanza dello use case base raggiunge una locazione referenziata da un punto di estensione la condizione viene valuatata :n Se l’esito è positivo (valore TRUE) allora le azioni
specificate nel caso d’uso estendente vengono eseguite
n Altrimenti si procede con le successive istruzione dello use case base
Esempio Extend: funzionamenton L’assenza di una condizione corrisponde ad un
valore sempre true.n Se una relazione ha più punti di estensione la
condizione viene verificata solo la prima volta ossia prima dell’esecuzione del primo frammento
12
Esempio Inclusione o Estensione?
Opzionalità: se l’esecuzione del flusso di azioni di uno use case invocato deve avvenire solo al verificarsi di particolari condizioni (ossia rappresentaunavariante al flusso di azione) bisogna usare la relazione di estensione.
Inclusione o Estensione?
nSe uno use case viene invocato solo da un altro probabilmente è opportuno usare l’estensione.nSe può essere usato nel flusso di azione di svariati casi d’uso allora è da preferire la relazione di inclusione
Inclusione o Estensione?
nLa relazione di inclusione ricorda molto l’invocazione di una procedura (o metodo) e pertanto lo use case incluso deve ricevere (dallo use case base) gli eventuali attributi di cui necessita per eseguire il flusso di azioni
Inclusione o Estensione?
nLo use case esteso contiene il flusso primario degli eventi e non ha conoscenza diretta di eventuali altri casi d’uso estendenti
Esempi
13
FINE