Università degli Studi di Trieste

Corso di Laurea Magistrale in

INGEGNERIA CLINICA

UNIFIED MODELING LANGAUGE

BASICS

Corso di Informatica Medica

Docente Sara Renata Francesca MARCEGLIA

Dipartimento di Ingegneria e Architettura

 2
WHAT IS UML

The Unified Modeling Language (UML) is a

language for specifying, visualizing, constructing, and
documenting the artifacts of software systems, as
well as for business modeling and other non-software
systems .
 OBIETTIVI DI UML

• UML è un linguaggio e non un metodo

• UML è costituito da un insieme di linguaggi che consentono di dare
descrivere e modellare diversi aspetti di un sistema:
– Aspetti statici
– Aspetti dinamici
– Interazioni tra le diverse componenti

• UML facilita la comunicazioneà

– tra analisti e esperti di dominio
– Tra analisti e progettisti
– Tra progettisti e sviluppatori

• Linguaggio grafico ma formale, preciso e non ambiguo

• Dà una visione concisa del sistema da diversi punti di vista
• Non necessita
3 di conoscenza del codice
• UML è basato sulla logica della programmazione a oggetti
 PERCHÈ SI USA UML

• Si deve operare con esperti di dominio

• Si devono catturare gli aspetti più importanti senza
perdersi nei dettagli
• La notazione di UML è flessibile à molti diagrammi
rappresentano aspetti diversi dei concetti
• La riunione di tutti i diagrammi prodotti può essere
facilmente utilizzata come rappresentazione del sistema
intero à scheletro del sistema

4
 5
STORIA DI UML

3 DIFFERENT
METHODOLOGIES FOR
SOFTWARE
DEVELOPMENT WITH A
PROPER SET OF SYMBOLS
AND PRINCIPLES

1995 àUNIFICATION OF
THE 3 METHODOLOGIES

FIRST VERSION RELEASED

IN 1997 BECOMES A
STANDARD

NOW
UML 2.5
UML IN SOFTWARE ENGINEERING

Studio di fattibilità

Analisi dei requisiti

modello UML
Definizione
Progettazione

Codifica e test di modulo

modello UML
Utilizzo
Integrazione e test di sistema

Consegna, installazione e manutenzione

 7
DIAGRAMMI UML: viste statiche e
dinamiche

VISTE VISTE
STATICHE DINAMICHE
• Use case • Sequence
diagrams diagrams
• Class diagram • Collaboration
• Component diagrams
diagram • State chart
• Deployment diagrams
diagram • Activity
• Object diagram diagrams
 DIAGRAMMI UML: tipologia di
rappresentazione
DIAGRAMMI STRUTTURALI
• Class diagrams
• Object diagrams
• Component diagrams
• Composite structures
• Deployment diagrams
• Package diagrams
DIAGRAMMI COMPORTAMENTALI
• Use case diagrams
• State chart diagrams
• Activity diagrams
DIAGRAMMI DI INTERAZIONE
• Sequence diagrams
• Communication diagrams
• Timing diagrams
• Interaction diagrams
• Overviews
 9

USE CASE DIAGRAMS (1/2)

• Schematizza il comportamento del sistema dal punto di vista degli utenti, o,
più in generale, di altri sistemi che interagiscono col sistema specificato.

• Use case = servizio o attività messa a disposizione dal sistema

• Scenario = insieme di casi d’uso che descrivono un’interazione
utente/sistema
• Attore = entità esterna al sistema

• Attori e casi d’uso sono legati da associazioni che rappresentano

comunicazioni.

• I casi d’uso non rappresentano sottosistemi, per cui non possono interagire o
scambiarsi messaggi fra di loro, ma possono essere legati da relazioni.

• Non definiscono il comportamento richiesto al sistema per fornire il servizio

rappresentato
 RELAZIONI TRA CASI D’USO

INCLUSIONE
• Use case inserito in un altro use case
• Viene eseguito sempre quando lo use case di riferimento è
eseguito

ESTENSIONE
• Uso opzionale di uno use case in concomitanza di un altro
• L’esecuzione dello use case può anche non avvenire

GENERALIZZAZIONE
• Relazione tra elementi del modello del tipo
classe/sottoclasse
• Definizione di una relazione “is type of”

10
 USE CASE DIAGRAM:
NOTAZIONE GRAFICA

Use case << include >>

Extension points

Actor
Generalization
<< extend >>
(extension points)

11
 CLASS DIAGRAMS
• Le classi rappresentano OGGETTI e CATEGORIE con
significato diverso
CONCETTUALEà
Rappresentazione dei concetti in
un dominio

DI SPECIFICAà
Specifica di interfacce (non di
implementazione) in un dominio
DI IMPLEMENTAZIONEà
Classi del linguaggio di
programmazione
12
 13
CLASS DIAGRAM: NOTAZIONE
GRAFICA
• Ogni classe ha un’intestazione, degli attributi e delle
operazioni
• Una classe viene rappresentata graficamente da un
rettangolo contenente il nome della classe e,
opzionalmente, l’elenco degli attributi e delle operazioni.

Class Name

Class Name

attribute:Type = initialValue
operation(arg list) : return type
 14

ATTRIBUTI
<visibilita‘> <nome> <molteplicita‘> : <tipo> = <val-iniziale>

• Nome à obbligatorio
• Tipo:
– tipi fondamentali predefiniti dall’UML (corrispondenti a quelli usati comunemente nei linguaggi di
programmazione)
– tipo definito in un linguaggio di programmazione
– classe definita (in UML) dallo sviluppatore;
• Visibilità: privata, protetta, pubblica, package; quest’ultimo livello di visibilità significa che l’attributo è
visibile da tutte le classi appartenenti allo stesso package
– + pubblica
– # protetta
– ~ package
– - privata
• Molteplicità: ´ındica se l’attributo può essere replicato, cioè avere più valori (array). Si ındica con un
numero o un intervallo numerico fra parentesi quadre
– [3] tre valori
– [1..4] da uno a quattro valori
– [1..*] uno o pi´u valori
– [0..1] zero o un valore (attributo opzionale)
• Valore iniziale: valore assegnato all’attributo quando si crea l’oggetto.
 OPERAZIONI
<visibilita‘> <nome> (<lista-parametri>) : <tipo>

Per ogni parametro:

<direzione> <nome> : <tipo> = <val-default>

• PARAMETRI
– Direzione: ingresso (in), uscita (out), ingresso e uscita (inout);
– Tipo;
– Valore default: valore passato al metodo che implementa la funzione.
– Solo il nome del parametro è obbligatorio
– Parametri separati da virgole
• OPERAZIONI
– Visibilità (come attributi)
– Tipo del valore restituito

15
 16

CLASS DIAGRAM: NOTAZIONE GRAFICA

role B
Association Class A
role A
Class B

Supertype

Generalization discriminator

Subtype 1 Subtype 2
CLASS DIAGRAM: NOTAZIONE GRAFICA

1
Multiplicities Class exactly one

* Class many (zero or more)

0 …1 optional (zero or one)

Class

m .. n numerically specified
Class

Aggregation Class

Composition Class

17
 18

ASSOCIAZIONI
• ASSOCIAZIONE = relazione tra due classi

• Si rappresenta con una linea tra le due classi associate

• PROPRIETÀ DELLE ASSOCIAZIONI

– Raggruppate nel rispettivo estremo di associazione (association end).
– Ruolo: specifica la relazione fra le istanze della classe (molto utile nelle
autoassociazioni)
– Molteplicità: numero di istanze di tale classe che possono essere in relazione con
una istanza della classe associata. essere indicata con intervalli numerici alle
estremità della linea che rappresenta l’associazione: per esempio, 1, 0..1 (zero o
uno), 1..* (uno o più), 0..* (zero o più), * (equivalente a 0..*).
– Ordinamento: per molteplicità >1, se le istanze sono ordinate
– Unicità: per molteplicità >1, se le istanze possono essere duplicate
– Qualificatore: attributo dell’associazione , che distingue i diversi oggetti di una
classe che possono essere in relazione con oggetti dell’altra, per meglio definire
una certa istanza, fra molte, di una classe associata. rappresentato da un
rettangolo avente un lato combaciante con un lato della classe opposta a quella di
cui si vogliono qualificare le istanze
– Tipo di aggregazione (aggregation kind)
– Navigabilità
 ASSOCIAZIONI

Uid è il qualificatore dell’account che rende la relazione 1..1 à uno

user può avere più account ma se considero un certo account con un
certo uid, avrà uno ed un solo utente associato
 CLASSE ASSOCIAZIONE
• Associazione con attributi e operazioni
• Rappresentata collegando alla linea dell’associazione il
simbolo della classe mediante una linea tratteggiata.

Class Class

Association
Class

20
 AGGREGAZIONE
• AGGREGAZIONE = associazione che lega un’entità
complessa (aggregato) alle proprie parti componenti.

• Indicata da una piccola losanga all’estremità

dell’associazione dalla parte della classe (o dell’oggetto)
che rappresenta l’entità complessa.

• L’aggregazione esprime il concetto di “appartenenza”,

“contenimento”, “ripartizione”, o in generale di una forma
di subordinazione strutturale non rigida.

• Un’istanza di una classe può appartenere a più di una

aggregazione.

21
 AGGREGAZIONI

I clienti non fanno parte

della loro banca, mentre
i giocatori fanno parte
della squadra

Uno studente può far

parte sia del coro (che
è formato da studenti)
che della squadra (che
è formata da studenti)

22
 23

COMPOSIZIONE

• COMPOSIZIONE = subordinazione strutturale rigida in cui

l’aggregato ha il completo e unico controllo delle parti
componenti.
• Aggregazioni: parti indipendenti dall’aggregato
• Composizione: dipendenza stretta fra composto e componenti
(l’esistenza dei componenti coincide con quella del composto à la
creazione e la distruzione del composto implicano la creazione e la
distruzione dei componenti)
• Un componente può appartenere ad un solo composto
• Il composto è il “padrone” del componente.
• Si rappresenta con una losanga nera dalla parte dell’entità complessa,
oppure si possono disegnare i componenti all’interno dell’entità stessa.
 COMPOSIZIONE (2)

• Una classe può appartenere come componente a più di

una composizione,
• Un’istanza di una classe componente può appartenere ad
una sola istanza di una classe composta.

24
 AGGREGAZIONE E COMPOSIZIONE

25
 26

STEREOTIPI
• Stereotipi = nuovi elementi di modello ottenuti da elementi
già esistenti (per esempio, dall’elemento classe o
dall’elemento associazione) aggiungendo informazioni di
vario tipo alla loro semantica, per mezzo di vincoli e valori
etichettati.
Distinguo le classi destinate
all’interfacciamento con l’utente (boundary)
dalle classi che rappresentano i server (server)
e da quelle che definiscono la logica
dell’applicazione (control)

Si possono associare informazioni

rilevanti per tutti i tipi di server, per
esempio il massimo numero di
richieste che possono essere messe in
attesa, espresso da un valore
etichettato (max reqs).
 27

GENERALIZZAZIONE
• Una classe (classe base o superclasse) generalizza un’altra classe (classe derivata o
sottoclasse) quando definisce un insieme di elementi che include l’insieme di
elementi definiti dalla classe derivata

• La classe derivata è un sottoinsieme della classe base à La classe base ha meno

caratteristiche (attributi, operazioni, associazioni, vincoli. . . ) della classe derivata.

• Una classe base può avere più classi derivate, e in questo caso ne riassume alcune
caratteristiche comuni (attributi, operazioni, associazioni, vincoli. . . ).

• La relazione di generalizzazione si può anche chiamare specializzazione (cambia il

punto di vista). La specializzazione può avvenire per estensione (aggiungo
attributi) o per restrizione (aggiungo vincoli)

• Un oggetto appartenente ad una classe derivata appartiene anche alla classe base.
• Principio di sostituzione (di Barbara Liskov): un’istanza della classe derivata può
sostituire un’istanza della classe base à importante per verificare se la relazione
di generalizzazione è corretta (soprattutto nel caso di restrizione)
 EREDITARIETÀ

• Una sottoclasse ha tutte le caratteristiche della

superclasse à eredita le caratteristiche
• Operazioni à nell’eredità si può effettuare overriding
(stessa signature ma diversa implementazione) purchè
valga il principio di sostituzione.
• Eredità multiplaà
– una classe derivata è un sottoinsieme di due o più classi che non
sono in relazione di generalizzazione/specializzazione fra di loro.
– Le istanze della classe derivata ereditano le caratteristiche di
tutte le classi base

28
 29

INSIEME DI GENERALIZZAZIONI
• Generalizzazione à spesso usata per classificare le entità del dominio
analizzato
• Insieme di generalizzazioni:
– modo di raggruppare le sottoclassi di una classe base (insieme di
sottoinsiemi), a cui si può dare un nome che descriva il criterio con
cui si raggruppano le sottoclassi.
– Insieme completo: ogni istanza della classe base appartiene ad
almeno una delle sottoclassi
– Insieme disgiunto: le sottoclassi sono disgiunte (intersezione vuota)
– Per default, un insieme di generalizzazioni è incompleto e disgiunto.
 30

OGGETTI
• Oggetto à rettangolo contenente
– i nomi dell’oggetto e della classe d’appartenenza,
sottolineati e separati dal carattere ‘:’,
– (opzionalmente) gli attributi con i rispettivi valori.
– Il nome della classe o quello dell’oggetto possono
mancare. In questo caso, il nome della classe viene
preceduto dal carattere ‘:’
 31

ACTIVITY DIAGRAMS

ATTIVITÀ = qualcosa che viene fatto e che si

può potenzialmente suddividere in sotto attività
• Activity diagram:
• Rappresentano la sequenza di attività e supportano il comportamento
condizionale e parallelo
• Servono a descrivere il flusso di attività, di controllo e di informazioni
• Simili ai diagrammi di flusso (flowchart)

• Comportamento condizionale:
• Branch à un input con diversi output sotto condizione
• Merge à più input danno luogo ad un singolo output
– Comportamento parallelo:
• Fork à da una transizione ne escono molte parallele
• Join à da più percorsi paralleli, si torna ad un solo percorso comune, quando tutte
le attività parallele sono completate

• Swimlane à attività svolte da entità differenti, raggruppante graficamente in

partizioni (corsie)
 32
ACTIVITY DIAGRAM: NOTAZIONE
GRAFICA
start

Activity

fork

[condition] [else] Dynamic

branch Concurrent
Activity

Activity Activity

merge

join

end
 SWIMLANE

33
 USE CASE DIAGRAM ESEMPIO

34
 CLASS DIAGRAM ESEMPIO

35
 ACTIVITY DIAGRAM ESEMPIO

36
 SEQUENCE DIAGRAMS

• Diagrammi di interazione
• Rappresentano i messaggi che gli oggetti si
scambiano in determinate situazioni
• Oggetti à rettangoli posti all’inizio di linee verticali
tratteggiate
• Linea della vita dell’oggetto à
– Linea verticale tratteggiata
– Rettangolo verticale sulla linea della vita:
momento in cui l’oggetto è attivo e scambia
messaggi
• Messaggi à
– Frecce tra le linee della vita di due oggetti
– L’ordine va dall’alto verso il basso
– Selfcall: messaggio che l’oggetto scambia con se
stesso

37
 SEQUENCE DIAGRAM: NOTAZIONE
GRAFICA

an Object

create
new Object

message self delegation

return

delete

38
 39

DEPLOYMENT E COMPONENT DIAGRAMS

• DEPLOYMENT DIAGRAM:
– Rappresentano la parte HW del sistema
– Ogni nodo rappresenta una unità computazionale (un
dispositivo, un sensore, una periferica, etc)
– Le connessioni tra i nodi sono percorsi di comunicazione tra i
componenti

• COMPONENT DIAGRAM:
– Rappresentano le componenti del sistema e le loro dipendenze
– Componente: package software
– Dipendenza: relazione tra due componenti (come un
componente influisce sul cambiamento dell’altro)

• COMBINAZIONE dei due diagrammi à

– rappresenta il sistema mettendo in evidenza quali componenti
sono installati e funzionano su ciascun nodo
– Relazione tra le componenti HW e SW
 DEPLOYMENT E COMPONENT DIAGRAM:
NOTAZIONE GRAFICA

• node

Component 2

Component 1

40
 SEQUENCE DIAGRAM: ESEMPIO
Reference Clinical Data Verification XML XML Concept
Prescription Mobile App
terminology Repository Privacy interface Creator Translator
Criteria
Healthcare
professional

Patient's visit Create

Request
coded concept
Concept Code

Signature Request

Signature
Access
New Prescription
Request
Transmit
Credentials
Credentials

Verify credentials
CHV
Access
granted

Request prescription

Request XML
creation
Request
Query
translation
Retrieve
UMLS code
Prescription
CHV
translation
Translation

Structured XML

Structured
XML

Encryption

41 Prescription
(structured/translated)
DEPLOYMENT E COMPONENT DIAGRAM:
ESEMPIO