|
Vero progresso quando i vantaggi di una nuova tecnologia diventano per tutti
|
|
| Home Page |
|
| Articoli |
|
| News |
|
| Forum |
|
| Classi |
|
|
|
|
|
Notazione UML - prima parte
By
Giuseppe Capodieci
10 settembre 2005
|
 |
|
Iniziamo da questo una serie di articoli che illustreranno l'utilizzo di UML per le fasi di analisi e design di un'applicazione. Presupponendo che l'applicazione venga implementata in java, si potrà vedere come questo presupposto influenzerà le scelte che verranno fatte in fase di design della applicazione. Prima di addentrarci nell'argomento, mi sembra comunque necessario partire "dall'inizio" e fare una "carrellata" sulla notazione UML, e sul suo utilizzo, in modo tale che anche i lettori meno esperti possano seguire e comprendere gli articoli che seguiranno.
|
|
|
Introduzione all' UML
|
top
|
|
UML (Unified Model Language) è un linguaggio per specificare in modo visuale, mediante una notazione simbolica standard, le caratteristiche di un sistema software o un modello di business. La standardizzazione del linguaggio è avvenuta mediante un processo iniziato nel 1994 ad opera di tre metodologi noti anche come i "tres amigos" e cioè Grady Booch, James Rumbaugh e Ivar Jacobson al'interno della società Rational. Diventato standard OMG (Object Management Group) che ne cura l'evoluzione, è, al momento della stesura di questo articolo, alla versione 1.5.
|
|
I diagrammi
|
top
|
|
Per poter descrivere un'applicazione, UML mette a disposizione diversi tipi di diagrammi, che permettono di analizzarne ciascuno un particolare aspetto, a partire dalla struttura (aspetto statico), al workflow (aspetto dinamico) fino ad arrivare a descrivere dove (su che tipo di macchina) questa applicazione verrà eseguita. Ma vediamo più in dettaglio i vari diagrammi, analizzandone per ciascuno gli aspetti che "catturano" e la notazione.
|
|
Diagramma dei casi d'uso
|
top
|
|
Cominciamo con il primo e tra i più importanti dei diagrammi, quello dei casi d'uso (use case diagram). I casi d'uso sono i modi in cui un sistema può essere utilizzato da parte di uno o più utilizzatori (attori). In questo diagramma il sistema è visto come una sorta di black box, viene descritto "cosa" fa il sistema, nascondendone l'organizzazione interna ("come" è fatto il sistema). Nel processo di analisi i casi d'uso sono molto utili anche per poter individuare alcuni requisiti del sistema non individuati inizialmente: grazie alla semplicità del diagramma, comprensibile anche ai non "addetti ai lavori", consente una partecipazione attiva di tutte le parti interessati all'applicazione, come il committente e gli utenti, normalmente estranei al mondo IT, agevolando la raggiunta di un accordo su cosa il sistema debba fare. Gli use case costituiscono un fondamentale punto di partenza per le fasi successive di analisi e disegno e sono un riferimento per la fase di test dell'applicazione.
|
|
Elementi del modello
|
top
|
|
 Fig. 1 Elementi del modello Un caso d'uso rappresenta una funzionalità che il sistema mette a disposizione dei suoi utenti.  Fig. 2 Elementi del modello Un attore è un soggetto esterno al sistema che interagisce col sistema, si può trattare di un essere umano, ma anche di un altro sistema software o hardware. Ogni collegamento tra un attore e un caso d'uso rappresenta una comunicazione.  Fig. 3 Elementi del modello
|
|
Diagramma delle classi
|
top
|
Un altro dei diagrammi fondamentali dell'UML è il diagramma delle classi; qui si rappresentano le classi che compongono il sistema e i relativi attributi e operazioni. Una classe legata in qualche modo ad un' altra viene relazionata mediante un'associazione. Questo diagramma cattura l'aspetto statico di un'applicazione, mostrandone la struttura, le parti che la compongono e le relazioni tra queste.
|
|
Dipendenza
|
top
|
|
Due classi sono in qualche modo legate da una relazione di dipendenza quando il cambiamento di stato della classe indipendente modifica lo stato della classe dipendente. 
Fig. 4 Dipendenza
|
|
Generalizzazione
|
top
|
|
Lega un oggetto generale (superclass) ad uno più specifico (subclass) appartenente allo stesso tipo (is-kind-of). 
Fig. 5 Generalizzazione
|
|
Associazione
|
top
|
|
Rappresenta una relazione generica tra due classi, dove una utilizza i servizi (operazioni) dell'altra. A questo tipo di relazione si può associare un nome per esprimere meglio in che modo le classi sono relazionate. 
Fig. 6 Associazione Un particolare tipo di associazione è l'aggregazione che permette di rappresentare un oggetto (whole) come l'insieme delle parti che lo compongono. 
Fig. 7 Associazione Per completezza citiamo un altro diagramma, simile a quello delle classi e cioè il diagramma degli oggetti. Questo diagramma risulta utile nel caso in cui si voglia ad esempio,"fotografare" lo stato del sistema in certo istante e vedere quali oggetti (istanze particolari di una classe) sono coinvolti e il loro stato interno (valori degli attributi).
|
|
Conclusioni
|
top
|
In questo primo articolo abbiamo iniziato la descrizione dei diagrammi UML, partendo dai due più importanti, use case diagram e class diagram. Nel prossimo articolo completeremo la descrizione dei diagrammi UML per poi iniziare con un esempio pratico di analisi e sviluppo di un sistema software.
|
|
|

Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati sotto licenza Creative Commons
|
|
|