Introduzione ad UML

Introduzione ad UML

Prof. Orazio Tomarchio

Sommario

Cos’è la modellazione del software e perché è utile un linguaggio di modellazione

Come nasce l’Unified Modeling Language (UML)

Quali sono le sue caratteristiche principali

Overview dei principali diagrammi UML

O. Tomarchio Ingegneria Del Software 2

La modellazione del software

Che cos’è la modellazione? Tipica attività ingegneristica: costruire un modello del

manufatto che si vuole realizzare La progettazione di sistemi complessi si accompagna

sempre alla realizzazione di modelli. In alcune discipline i modelli sono fisici, in altre sono

intangibili. In ogni caso, i modelli rappresentano un’astrazione

della realtà: una rappresentazione semplificata del sistema che deve essere realizzato che ne cattura gli aspetti di interesse.



Perché modellare? In alcuni casi si può pensare che non sia

indispensabile realizzare un modello del sistema prima di realizzarlo:

Il dominio del problema è ben conosciuto La soluzione è relativamente facile da costruire La soluzione può essere realizzata da un numero molto

ristretto di persone (una sola…) La soluzione non deve essere mantenuta nel tempo Si prevede che il sistema non debba evolvere

significativamente Ma cosa succede se una di queste caratteristiche non

è vera?O. Tomarchio Ingegneria Del Software 4


Perche modellare il software? Per sua natura, il software può essere creato e

modificato con facilità: non richiede investimenti in impianti, stampi, manodopera…

Questo ha portato a pensare che non fosse necessario realizzare modelli di sistemi software.

Tuttavia…



Tuttavia: la complessità dei sistemi software è molto elevata spesso i sistemi software sono “embedded” in altri sistemi il software richiede grande manutenzione il software evolve significativamente rispetto alla sua prima

emissione

la progettazione software è un’attività ad alto rischio! Tutte le persone coinvolte nel processo di sviluppo

necessitano di comprendere a fondo il sistema che deve essere realizzato, ognuno dal proprio punto di vista.

La realizzazione di modelli riduce significativamente i rischi di progetto.



Resistenze alla modellazione software

Le resistenze alla realizzazione di modelli sono essenzialmente di due tipi: Culturali – gli sviluppatori tendono a focalizzarsi sugli

strumenti di sviluppo, debug, test… Temporali – si è portati a pensare che il tempo speso a

realizzare modelli sia tempo perso nell’ambito del progetto…



Cosa rende “buono” il modello di un software? Un buon modello coglie i concetti essenziali del sistema

(aiuta ad andare al «cuore» del progetto) Un buon modello permette ai vari attori di cogliere

dettagli diversi in momenti diversi Un buon modello, per quanto astratto, è collegato alla

realtà e ne segue la sua evoluzione Un buon modello si presta ad agire ed interoperare con

altri modelli al fine di illustrare sistemi complessi nella loro interezza.


Unified Modeling Language (UML)

Cosa è UML: Linguaggio (visuale) per la modellazione di sistemi

software È uno standard OMG Sintesi di notazioni usate in passato Universale: può essere usato per rappresentare sistemi

molto diversi, da quelli web ai legacy, dalle applicazioni tradizionali a quelle object oriented e a componenti


Cosa non è UML

NON è un linguaggio di programmazione NON è un metodo, né una metodologia per la

progettazione del software NON prescrive un processo software: cioè non

dice “prima bisogna fare questa attività, poi quest’altra”

È il tecnigrafo dell’ingegnere del software… … ma se non si sa progettare serve a poco!


Caratteristiche principali

UML è stato progettato per agevolare il processo di elaborazione di modelli: visualizzare il sistema specificare la struttura ed il comportamento del sistema implementare il sistema documentare tutte le decisioni prese durante le varie

fasi di lavoro


Caratteristiche principali: visualizzazione

UML è stato progettato per agevolare la comunicazione fra gli attori che partecipano allo sviluppo di un progetto software.

La maggior parte delle caratteristiche di un sistema si presta meglio per essere rappresentata in modo grafico piuttosto che con un testo.

UML definisce un insieme di diagrammi standard attraverso i quali ogni membro del processo di sviluppo ha la possibilità di comprendere lo stato di sviluppo del sistema, in maniera chiara ed univoca, riducendo il rischio di interpretazioni non corrette.


Caratteristiche principali: specifica

Fornire la specifica di un modello = definirlo in modo preciso, completo e privo di ambiguità.

I modelli costruiti nelle prime fasi del progetto servono a definire i requisiti dei committenti.

Addentrandosi nell’analisi è necessario arricchire i modelli iniziali per definire il sistema con maggior grado di dettaglio. Questi modelli intermedi definiscono i concetti chiave del sistema ed i meccanismi con i quali tali concetti verranno poi espressi.

I modelli più dettagliati descrivono completamente le caratteristiche del progetto.


Caratteristiche principali: implementazione

Molti elementi di UML sono in relazione diretta con i costrutti propri dei linguaggi di programmazione ad oggetti (C++, Java).

Altri elementi di UML agevolano la progettazione di database o la progettazione di sistemi distribuiti.


Modello CodiceForward engineering

Reverse engineering

Caratteristiche principali: documentazione

UML facilita il processo di stesura di documentazione di progetto. Alcuni diagrammi costituiscono una buona base per la

stesura di manuali utente. Altri diagrammi agevolano la definizione dei test del

sistema. Chi non è stato coinvolto nel processo di modellazione

ha la possibilità di comprendere i concetti fondamentali del sistema.

I modelli ben documentati possono essere riutilizzati, in tutto o in parte, in progetti successivi.



UML è uno standard aperto dell’OMG (Object Management Group) riunisce molte proposte esistenti è sponsorizzato dalle maggiori industrie produttrici di

software è un linguaggio non proprietario (i suoi autori non

hanno il copyright su UML)



UML riunisce aspetti dell’ingegneria del software, delle basi di dati e della progettazione di sistemi

UML è utilizzabile in domini applicativi diversi e per progetti di diverse dimensioni

UML è estendibile per modellare meglio le diverse realtà UML permette la specializzazione di concetti, notazione e

vincoli per domini particolari UML consente l’approccio alla complessità architetturale

dei problemi usando component technology, visual programming e patterns


UML: un po’ di storia

UML è nato da una serie di metodologie e diagrammi per analisi e progettazione pre-esistenti, orientate agli oggetti ed apparse tra la fine degli anni ’80 ed i primi anni ’90

Esistono forti affinità e somiglianze con: Diagrammi Entity-Relationship (ER) Flow Chart Diagrammi di stato Notazioni Object Oriented (OO)



Agli inizi degli anni ’90 c’erano svariate decine di metodologie di sviluppo ed analisi del software: la modellazione software con metodologie O-O si impone all’attenzione della comunità scientifica

Attorno alle più importanti di esse si erano costituiti dei gruppi di ricerca che le apprezzavano e che si ponevano in forte competizione fra loro.



1991: Jim Rumbaugh, “Object Oriented Modeling and Design” (Prentice Hall). Definisce la Object Modeling Tecnique (OMT), primo esempio di analisi nello spazio dei problemi. Molti degli attuali diagrammi UML derivano da concetti ivi espressi.

1992: Ivar Jacobson, “Object Oriented Software Engineering” (Addison-Wesley) detto “libro bianco” o OOSE. Definisce il processo Objectory e per la prima volta parla di Use Cases, uno dei fondamenti di UML.

1994: Grady Booch, “Object Oriented Analysis and Design with Applications” (Addison-Wesley). Presso Rational Software, Booch definisce in maniera molto rigorosa i dettagli della costruzione di un sistema software con metodologia O-O (“metodo di Booch”). I diagrammi UML più dettagliati e più vicini alle fasi di sviluppo sono stati definiti in questo testo.



Nel 1994 Grady Booch e James Rumbaugh decisero di fondere le loro diverse metodologie (Booch-93 e OMT).

Nel 1995 ad essi si aggiunse anche Ivar Jacobson (OOSE) ed i tre dettero vita nel 1996 ad una metodologia che unificava i loro precedenti approcci, dal nome Unified Modeling Language (UML). Gli autori vengono spesso indicati con il nickname “I tre amigos”.

Nel 1997 l’OMG (Object Management Group) emette una versione standard di UML (UML 1.1) che si basa sostanzialmente sulla versione di Booch, Rumbaugh e Jacobson ma anche sui contributi di molti altri studiosi e di alcune delle più importanti software house mondiali

La sua evoluzione è a carico dell’OMG ed è soggetta a procedure ben definite per ogni cambiamento

2001 Versione UML 1.4 (UML 1.4.2 is available as ISO/IEC 19501) 2004 Versione UML 2 (UML 2.1.2 is available as ISO/IEC 19505 ) Current specifications (2012): UML 2.4.1


Modello concettuale di UML

UML definisce una notazione standard, basata su un metamodello integrato degli elementi che compongono un sistema software, definendo le caratteristiche e le relazioni esistenti tra i diversi elementi (classi, attributi, moduli, …)

Il meta-modello è la base per l’implementazione dell’UML da parte dei produttori di strumenti di sviluppo (CASE, ambienti visuali, …) e per l’interoperabilità tra i diversi strumenti



In un approccio top-down all’UML si possono distinguere gli elementi fondamentali della sua struttura: Viste, Diagrammi, Elementi del modello

Le viste mostrano i differenti aspetti di un sistema attraverso la realizzazione di un certo numero di diagrammi si tratta di astrazioni, ognuna delle quali analizza il

sistema da modellare con un’ottica diversa (funzionale, non funzionale, organizzativa, ecc.), la somma di queste viste fornisce il quadro d’insieme



I diagrammi permettono di esprimere le viste logiche per mezzo di grafici vi sono diversi tipi di diagrammi destinati ad essere

utilizzati ognuno per una particolare vista

Gli elementi del modello sono i concetti che permettono di realizzare i vari diagrammi indicano gli attori, le classi, i packages, gli oggetti, ecc.


UML: le viste


UML: le viste

Il punto di vista degli Use Cases Coinvolge utenti e sistemi esterni: descrive cosa farà il sistema

senza specificare come lo farà. Il punto di vista del progetto

Descrive gli elementi strutturali, dinamici e comportamentali del sistema.

Il punto di vista del processo Descrive gli aspetti legati al flusso di controllo del sistema ed alla

sua temporizzazione. Il punto di vista dell’implementazione

Descrive i vari componenti del sistema, prodotti dai vari attori del processo, che devono essere assemblati insieme al fine di implementare la soluzione software.

Il punto di vista del deployment Descrive la topologia del sistema: si focalizza sulla distribuzione

geografica dei vari componenti hw e sw.O. Tomarchio Ingegneria Del Software 26

Diagrammi UML

Diagrammi strutturali

delle classi dei componenti di struttura composita di deployment degli oggetti dei package

Diagrammi comportamentali

di attività dei casi d’uso di stato di sequenza di comunicazione

(ex collaborazione) di interazione generale di temporizzazione


inte

razi

one

Troppi diagrammi???

Non spaventiamoci!!!

Nessuno comprende o utilizza UML nella sua interezza; la maggior parte delle persone ne usa un piccolo sottoinsieme

L’80% del lavoro può esser fatto con il 20% di UML (M.Fowler)


Use case diagram

Cattura le funzionalità del sistema dal punto di vista degli utenti Raccoglie un insieme di use case ed attori (un tipo speciale di classi) e le

relazioni tra essi. Rappresenta le modalità di utilizzo del sistema da parte di uno o più utilizzatori

(attori). Descrive l’interazione tra attori e sistema, non la “logica interna” della

funzione. Descrive l’organizzazione ed il modello del comportamento di un sistema.

Costruito nei primi passi dello sviluppo Ragionare sui casi d’uso aiuta ad individuare i requisiti funzionali.

Scopo Specificare il contesto di un sistema Catturare i requisiti di un sistema Validare l’architettura di un sistema Guidare la realizzazione Generare i casi di test

Sviluppato da analisti ed esperti di dominio


Esempio di use case diagram


Class Diagram

Cattura il vocabolario di un sistema Un class diagram rappresenta un insieme di classi,

interface, collaborazioni e relazioni. Specifica i vincoli e le relazioni che sussistono tra le

classi. Forniscono una rappresentazione statica di un sistema.

Costruito e raffinato per tutto lo sviluppo Scopo

Nominare e modellare i concetti nel sistema Specificare le collaborazioni Specificare gli schemi logici di database

Sviluppato da analisti, progettisti e realizzatoriO. Tomarchio Ingegneria Del Software 31

Esempio di class di diagram


Object diagram

Cattura le istanze e i legami rappresenta un insieme di oggetti e le relazioni che

intercorrono tra essi. i suoi elementi sono una istanziazione di elementi specificati

in qualche class diagram. rappresentano la vista statica di un sistema (o vista statica di

un processo) ma dalla prospettiva di un caso reale, o prototipale.

Costruito durante l’analisi e il progetto Scopo

illustrare le strutture di dati / oggetti specificare istantanee


Esempio di object diagram


Component diagram

Cattura la struttura fisica della realizzazione evidenzia l'organizzazione e le dipendenze esistenti tra

componenti, moduli software eseguibili, dotati di identità e con un'interfaccia ben specificata

Sono correlati ai class diagram, poiché un componente, tipicamente, mappa una o più classi, interfacce o collaborazioni

Costruito come parte della specifica architetturale Scopo

Organizzare il codice sorgente Costruire una release eseguibile Specificare un database fisico

Sviluppato da architetti e programmatoriO. Tomarchio Ingegneria Del Software 35

Esempio di component diagram


Deployment diagram

Evidenzia la configurazione dei nodi elaborativi in ambiente di esecuzione (run-time), e dei componenti, processi ed oggetti ubicati in questi nodi

Permette di rappresentare, a diversi livelli di dettaglio, l’architettura fisica del sistema, poiché cattura la topologia dell’hardware di un sistema

Costruito come parte della specifica architetturale Scopo

Specificare la distribuzione dei componenti Identificare i colli di bottiglia delle prestazioni

Sviluppato da architetti, sistemisti di rete e di sistema operativo


Esempio di deployment diagram


Sequence diagram

Cattura la dinamica del comportamento (time-oriented) Descrive dinamicamente le caratteristiche di un sistema

software, evidenziando le interazioni dovute allo scambio di messaggi ed il loro ordinamento temporale

Scopo Modellare il flusso di controllo Illustrare scenari tipici


Esempio di sequence diagram


Communication diagram

Cattura la dinamica del comportamento (message-oriented)

Anch’esso descrive dinamicamente le caratteristiche di un sistema software, evidenziando le interazioni dovute allo scambio di messaggi ed il loro ordinamento temporale

Diagrammi di sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le evidenziano in modo diverso. Tra tali diagrammi è possibile istituire un isomorfismo, cioè è possibile trasformare uno nell’altro.

Scopo Modellare il flusso di controllo Illustrare il coordinamento tra oggetti

Sviluppato da analisti, progettisti e realizzatori


Esempio di communication diagram


Statechart diagram

Cattura la dinamica del comportamento (event-oriented) Descrive il comportamento di un sistema in termini di

stati, transizioni, eventi ed attività, evidenziandone la dinamica

Scopo Modellare il ciclo di vita di un oggetto Modellare oggetti reattivi (interfacce utente, dispositivi,

ecc.) Sviluppato da analisti, progettisti e realizzatori


Esempio di state diagram


Activity diagram

Cattura la dinamica del comportamento (activity-oriented)

Mostrano il flusso da un’attività ad un’altra in un sistema. Rappresentano sistemi di workflow, oppure la logica interna

di un processo (di qualunque livello, dai business proces ai processi di dettaglio).

Permettono di rappresentare processi concorrenti e la loro sincronizzazione.

Scopo Modellare business workflows Modellare operazioni


Esempio di activity diagram


UML: considerazioni finali

UML rappresenta un’evoluzione dei modelli preesistenti, più che una rivoluzione

è adatto a esprimere modelli di varia tipologia, creati per obiettivi diversi

può descrivere un sistema software a diversi livelli di astrazione, dal piano più svincolato dalle caratteristiche tecnologiche fino all’allocazione dei componenti software nei diversi processori in un’architettura distribuita


UML: considerazioni finali

UML è sufficientemente complesso per rispondere a tutte le necessità di modellazione, ma è opportuno “ritagliarlo” in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto


Prossime lezioni

Approfondiremo ciascun diagramma di UML, descrivendone: Sintassi (come costruire un diagramma corretto) Ambito di utilizzo (quando e perché usare un

diagramma di quel tipo)

Esempi, esempi, esempi, …


Introduzione ad UML

Documents

Transcript of Introduzione ad UML