UML

a progettazione di un software è una fase estremamente delicata; dalla scelte effettuate in questa sede dipenderà la possibilità e la potenzialità di crescita del sistema che si sta realizzando.  

Per tale motivo è indispensabile condurre in modo scientifico la progettazione di un software; a tal fine risulta fondamentale avere degli opportuni strumenti di modellizzazione.

L’UML (Unified Modeling Language) è un formalismo che permette di specificare, costruire, visualizzare e documentare manufatti di sistemi software, di processi produttivi e di altri sistemi anche abbastanza diversi da quelli software.

In particolare, l’UML è il formalismo di progettazione preferito dalla comunità object-oriented. Esso viene utilizzato per creare “modelli di programmi”; con tale termine intendiamo una rappresentazione diagrammatica dei programmi in cui emergono le relazioni tra gli oggetti che fanno parte dell’applicazione.

L’UML ha diversi tipi di diagrammi; alcuni di essi sono orientati all’analisi, altri al progetto e altri all’implementazione. Ogni diagramma evidenzia specifiche relazioni tra le diverse entità coinvolte.

Vediamo, ora, quali sono i principali diagrammi UML utilizzati. Di questi approfondiremo solo il Class Diagram.

I principali diagrammi UML sono:

• Gli Use Case Diagram. Essi descrivono il comportamento del sistema dal punto di vista dell’utente. Per gli sviluppatori, gli Use Case Diagram rappresentano uno strumento che può essere utilizzato per ottenere un’idea chiara dei requisiti del sistema dal punto di vista utente e per poter realizzare il sistema avendo ben chiaro lo scopo finale. L’actor è l’entità che interagisce con uno Use Case facendo partire la sequenza di azioni descritte dal diagramma stesso ed, eventualmente, ricevendo delle precise risposte dal sistema.. L’actor può essere una persona oppure un altro sistema.

• Gli Activity Diagram. Le attività effettuate dagli oggetti di un determinato sistema accadono, tipicamente, in una sequenza ben definita. Gli Activity Diagram vengono utilizzati proprio per rappresentare tale sequenza.

• I Class Diagram. Essi vengono utilizzati per rappresentare le classi che fanno parte del progetto e le relazioni che le legano.

• Gli Object Diagram. Essi sono uno speciale tipo di Class Diagram. Un oggetto è un’istanza di una classe che rappresenta il suo stato in un determinato istante in cui il sistema è in fase di running. L’Object Diagram “cattura” lo stato di diverse classi nel sistema e le relazioni che intercorrono tra esse in un determinato istante di tempo.

• Gli State Diagram. Ad un determinato istante, durante il funzionamento del sistema, un oggetto si trova in un particolare stato. Gli State Diagram 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, ciascuna persona può essere identificato dai seguenti stati: neonato, infante, bambino, adolescente, adulto, anziano.

• I Sequence Diagram. I Class Diagram e gli Object Diagram rappresentano informazione statica. In un sistema funzionante, tuttavia, gli oggetti interagiscono l’uno con l’altro, e tali interazioni avvengono al trascorrere del tempo. Il Sequence Diagram mostra le dinamiche, basate sul tempo, delle varie interazioni tra gli oggetti.

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

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

• I Component Diagram. Oggi, nell’ingegneria del software, viene sempre più utilizzato il modello di organizzazione secondo cui ogni persona di un team lavora su un componente differente. Il Component Diagram descrive questa importante caratteristica.