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