UML 2.0
Panoramica su UML
Leggi il programma completo del corso
www.javaportal.it | www.k-tech.it corsi@k-tech.it

Agenda
Mod 00 – Presentazione
►Mod 01 – Panoramica su UML◄
Mod 02 – Introduzione all'UML
Mod 03 – Modellazione Strutturale
Mod 04 – Relazioni
........
Mod 14 – Statechart Diagram
Mod 15 – Timing Diagram
Mod 16 – Sequence Diagram
Mod 17 – Communication Diagram
Mod 18 – Interaction Overview Diagram
www.javaportal.it | www.k-tech.it corsi@k-tech.it 2

“ The programmer, like the poet, works only slightly
removed from pure thought-stuff. He builds his
castles in the air, from air, creating by exertion
of the imagination. Few media of creation are
so flexible,so readily capable of
”
realizing grand conceptual structures.
Frederick P. Brooks, Jr.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 3

Un po' di storia
Durante gli anni '90 furono introdotte nel mercato dell'Information Technology
parecchie metodologie per il disegno e la progettazione di sistemi software.
Vi era un problema, però: ognuna di queste tecnologie aveva il suo insieme
proprio di notazioni e simboli, che differiva, a volte in modo rilevante, dalle
altre.
In particolare, eccellevano tre di queste metodologie:
● OMT (Rumbaugh)
● Booch 1991
● OOSE (Obiectory) (Jacobson)
Nell'ottobre del 1995, nacque la prima bozza dell' UML (Unified Modelling
Language), ovvero l'unificazione delle notazioni e delle idee prodotte da
Booch, Rumbaugh e Jacobson per modellare un sistema software.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 4

Evoluzione
<< document >> 1997 - Unificazione dei principali linguaggi di modellazione:
Booch, OMT e Objectory.
UML 1.1 OMG acquisisce UML.
<< refine >>
<< document >> 1998 – Modifiche editoriali senza cambiamenti tecnici
significativi.
UML 1.2
<< refine >>
<< document >> 1999 – Aggiunti gli stati di sync per la sincronizzazione di
attività concorrenti.
UML 1.3 Ridefinite le relazioni dei casi d'uso: generalizzazione,
include, estende.
<< refine >>
<< document >> 2001 – Aggiunti vincoli nei diagrammi di collaborazione.
Cambiamento della notazione grafica dei componenti.
UML 1.4 Definiti gli artefatti per specificare i componenti fisici (file
sorgenti, file eseguibili, script).
<< refine >> Aggiunta vivibilità di package.
<< document >> 2002 – 2005 – La OMG definisce quattro request For
Proposals:
UML 2.0 UML 2.0 Infrastructure, UML 2.0 Superstructure, UML Object
Constraint Language, UML 2.0 Diagram Interchange.
<< refine >>
<< document >> 2006 – variazioni minori.
UML 2.1
www.javaportal.it | www.k-tech.it corsi@k-tech.it 5

UML 2.0
www.javaportal.it | www.k-tech.it corsi@k-tech.it 6

Modello
Cos’è un modello ?
Un modello è la semplificazione della realtà
“A model is an abstraction of something for the purpose of
understanding it before building it.
Because a model omits nonessential details, it is easier to
”
manipulate than the original entity.
Rumbaugh - 1991
Un modello è una astrazione di qualche cosa, [creato] con
lo scopo di capirla prima di costruirla. Poiché un modello
omette i dettagli non essenziali, è più semplice da
manipolare rispetto all'entità originale.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 7

Modellare il problema
Perché abbiamo bisogno di un modello?
Modelliamo per capire meglio il sistema
che dobbiamo sviluppare
Perché dobbiamo semplificare la realtà?
Qualunque realtà è troppo complessa
(nell’insieme e nel dettaglio)
per essere compresa
www.javaportal.it | www.k-tech.it corsi@k-tech.it 8

Obiettivi della Modellazione
Modellare per il riutilizzo
– Un buon progetto consente di riutilizzare parti del
software in contesti diversi da quello per cui è stato
pensato
Modellare per il cambiamento
– Un buon progetto deve essere in grado di resistere ai
cambiamenti, generati da un mutamento delle
specifiche oppure da un cambio di contesto
tecnologico
www.javaportal.it | www.k-tech.it corsi@k-tech.it 9

Qualità di un Modello
Le proprietà che deve possedere un modello dovrebbero
essere tenute a mente e guidare la fase di progettazione del
sistema, al fine di produrre versioni di migliore qualità.
Un modello dovrebbe essere :
• Accurato: deve descrivere il sistema correttamente,
completamente e senza ambiguità
• Consistente: le diverse viste devono completarsi
vicendevolmente per formare un insieme coerente
• Semplice: deve poter essere compreso, senza troppi
problemi, da persone estranee al processo di modellazione
• Manutenibile: la variazione dello stesso deve essere la più
semplice possibile
www.javaportal.it | www.k-tech.it corsi@k-tech.it 10

La mappa e il territorio
Ognuno ha una immagine precisa (mappa) del Dominio del
Problema.
Questa mappa però viene spesso creata attraverso tre
processi pericolosi:
• Rimozione
• Distorsione
• Generalizzazione
www.javaportal.it | www.k-tech.it corsi@k-tech.it 11

Rimozione
L’informazione viene scartata
E' un processo di selezione dell'esperienza
La rimozione ci consente di orientarci nel mondo
concentrandoci in particolare su ciò che è funzionale per noi
www.javaportal.it | www.k-tech.it corsi@k-tech.it 12

Distorsione
L’informazione viene modificata tramite meccanismi di creazione e
allucinazione.
Interpretiamo il mondo esterno secondo le nostre mappe, adeguando la
realtà alle nostre attese.
La distorsione ci consente di "trasformare" la realtà adattandola ai nostri
scopi, nonché di scegliere e decidere quali comportamenti adottare,
immaginando nel futuro le loro conseguenze.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 13

Generalizzazione
L’informazione viene incorporata in una regola, assioma o principio
che riguarda principi di verità o falsità.
La generalizzazione è il processo attraverso cui le persone
partendo da una esperienza specifica, la decontestualizzano
traendone un significato universale.
E' in pratica una semplificazione della realtà con la quale creiamo
categorie di riferimento.
La generalizzazione ci consente di gestire al meglio situazioni simili
ad altre passate, recuperando le opportune risorse.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 14

Principi di modellazione...
La scelta di quale modello creare influisce profondamente su come
verrà affrontato il problema e di conseguenza su quale soluzione
verrà trovata.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 15

...Principi di modellazione...
Ogni modello può essere espresso a diversi livelli di precisione
(profondità).
Diversi livelli di zoom
offrono viste con
contenuti informativi
diversi, utili ad audience
diverse.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 16

...Principi di modellazione...
I modelli migliori sono connessi alla realtà.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 17

...Principi di modellazione
Un singolo modello non è sufficiente. Molto meglio molti modelli
(viste) indipendenti.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 18

Module Review
In questo modulo abbiamo visto:
● Un po’ di storia
● Evoluzione
● UML 2.0
● Modello
● Modellare il problema
● Obiettivi della modellazione
● Qualità di un modello
● La mappa e il territorio
● Rimozione
● Distorsione
● Generalizzazione
● Principi di modellazione
www.javaportal.it | www.k-tech.it corsi@k-tech.it 19

Domande...
www.javaportal.it | www.k-tech.it corsi@k-tech.it 20

BREAK
Dopo la pausa:
Introduzione all'UML
Leggi il programma completo del corso
www.javaportal.it | www.k-tech.it corsi@k-tech.it 21