LEZIONE x:  Componenti UML


Il linguaggio UML contiene svariati elementi grafici che vengono messi insieme durante la creazione dei diagrammi. Poiché l'UML è un linguaggio, esso utilizza delle regole per combinare i componenti del linguaggio nella creazione dei diagrammi.
L'obiettivo dei diagrammi è quello di costruire molteplici viste di un sistema tutte correlate tra di loro. L'insieme di tali viste costituirà quello che abbiamo definito Visual Modeling.

Passiamo ora in rassegna, brevemente, tutti i diagrammi UML, prima di analizzarli più dettagliatamente in seguito.

Il linguaggio UML consiste di nove diagrammi di base, ma si tenga presente che è assolutamente possibile costruire e aggiungere dei diagrammi differenti dagli standard (che vengono definiti ibridi) rispetto a quelli definiti dal linguaggio.

Class Diagram
Per avere una idea immediata di cosa sia una classe possiamo usare come esempio il fatto che tutti gli oggetti o esseri viventi, spesso, sono riconducibili a determinate categorie (ad esempio: computers, automobili, piante, animali, ecc.). Queste categorie costituiscono le classi.

Definizione:Una classe è una categoria o un gruppo di oggetti (con questo termine includiamo, per comodità anche gli esseri viventi) che hanno attributi simili e comportamenti analoghi.


I Class Diagrams forniscono le rappresentazioni utilizzate dagli sviluppatori.

Object Diagram
Un oggetto è una istanza di una classe - ovvero una qualcosa di specifico che ha dei valori determinati per i suoi attributi e dei comportamenti specifici.

Use Case Diagram
Uno Use Case (caso d'uso) è una descrizione di un comportamento particolare di un sistema dal punto di vista dell'utente. Per gli sviluppatori, gli use case diagram rappresentano uno strumento notevole: infatti tramite tali diagrammi, essi possono agevolmente ottenere una idea chiara dei requisiti del sistema dal punto di vista utente e quindi scrivere il codice senza timore di non aver recepito bene lo scopo finale. Nella rappresentazione grafica, viene utilizzato un simbolo particolare per l'actor (l'utente o un altro sistema che interagisce) che vedremo in seguito.

Definizione: L'actor è l'entità che interagisce con uno use case facendo partire la sequenza di azioni descritte dallo use case stesso e, eventualmente, ricevendo delle precise risposte dal sistema.. Puo' essere una persona o anche un altro sistema.


State Diagram
Ad un determinato istante, durante il funzionamento del sistema, un oggetto si trova in un particolare stato. Gli State Diagrams rappresentano tali stati, ed i loro cambiamenti nel tempo. Ogni state diagram inizia con un simbolo che identifica lo stato iniziale (Start State) e termina con un altro simbolo che rappresenta lo stato finale (End State). Per esempio, ogni persona può essere identificato dai seguenti stati: neonato, infante, bambino, adolescente, adulto, anziano.

Sequence Diagram
I class diagrams e gli object diagrams rappresentano informazione statica. In un sistema funzionante, tuttavia, gli oggetti interagiscono l'uno con l'altro, e queste interazioni avvengono in relazione al trascorrere del tempo. Il sequence diagram mostra le dinamiche, basate sul tempo, delle varie interazioni tra gli oggetti.

Activity Diagram
Le attività che si riscontrano all'interno di use case o all'interno del comportamento di un oggetto accadono, tipicamente, in una sequenza ben definita. Tale sequenza viene rappresentata con gli activity diagrams.

Collaboration Diagram
Gli elementi di un sistema lavorano insieme per realizzare e soddisfare le necessità del sistema. Un linguaggio di modellazione deve avere un modo per rappresentare tale cooperazione. Il Collaboration Diagram nasce proprio per questa ragione.

Component Diagram
Oggi, nell'ingegneria del software viene sempre più utilizzato il modello di organizzazione secondo il quale ognuno nel team di lavoro si occupa di lavorare su un componente differente. Il component diagram descrive questa importante caratteristica.

Deployment Diagram
Il Deployment Diagram mostra l'architettura dal punto di vista fisico e logistico di un sistema. Tale diagramma può descrivere i computer e i vari dispositivi presenti, mostrare le varie connessioni che intercorrono tra di essi e, ancora, il software che è installato su ogni macchina.

Una domanda che ci si potrebbe porre a questo punto è la seguente: Ma è proprio necessario sviluppare tutti e nove i diagrammi che l'UML mette a disposizione?

La risposta a questa domanda può variare in relazione alla complessità del Sistema che si intende costruire ma, in linea di massima, tende ad essere affermativa. La ragione di ciò consiste nel fatto che, come si è già detto, i diagrammi UML sono stati pensati per venire incontro all'esigenza di rendere il Sistema comprensibile da differenti persone con differenti figure professionali.
Probabilmente, ad esempio, un commerciale non trarrà una particolare impressione leggendo un Class Diagram ma potrà, certamente, avere le idee più chiare analizzando uno Use Case Diagram.

  L e z i o n e    s u c c e s s i v a  
[ S o m m a r i o ]