Come si può notare, vi sono tre modi diversi per rappresentare una classe.

* Il rettangolo di sinistra evidenzia solo il nome della classe. Questo tipo di rappresentazione è molto utile quando non occorrono ulteriori informazioni, o quando si vuole enfatizzare le relazioni tra le classi del sistema piuttosto che il loro contenuto.

* Il rettangolo di centro mostra sia il nome che i metodi della classe. In questo caso l’Autovettura ha il metodo ApriSportello. Il segno + che precede ApriSportello indica che il metodo è public (pubblico), ovvero che ad esso può accedere qualsiasi oggetto del sistema.

* Il rettangolo di destra evidenzia sia il nome della classe, con i suoi metodi pubblici, che i campi ad essa relativi. In questo caso, il segno - indica che il campo lunghezza è private (privato), ovvero che non può essere utilizzato direttamente dagli altri oggetti della classe.

Vi è da dire che gli elementi di una classe, oltre che private e public, possono essere protected (protetti). Il simbolo utilizzato per denotare questo tipo di accesso è #. Si può accedere agli elementi protetti di una classe o dall’interno della classe stessa o dall’interno di un’altra classe che risulta essere una specializzazione della classe a cui appartiene l’elemento protected.

Come già accennato, nei Class Diagram vi sono dei costrutti che permettono di rappresentare le relazioni che intercorrono tra le classi.

La Figura 2 mostra la relazione tra la classe Veicolo e altre classi da essa derivate.

Figura 2 - La relazione is-a esistente tra Veicolo e le classi da essa derivate

Tale relazione è la ben nota is-a relationship. Infatti, la classe Autovettura è un (is-a) Veicolo, come pure la classe Moto. In UML, per indicare che una classe è derivata da un’altra, si usa una freccia come quella mostrata in figura. Inoltre, il fatto che la classe Veicolo sia in corsivo sta a significare che essa è astratta o un’interfaccia. Ciò implica che non è possibile istanziare alcun oggetto di tale classe.

Come abbiamo visto, vi sono due tipi di relazione has-a: aggregazione e composizione. Un esempio di aggregazione è mostrato in Figura 3.

Figura 3 - Un esempio di Aggregazione

Come si può notare, per rappresentare un�aggregazione in UML si utilizza un rombo vuoto. Il diagramma di Figura 4.3 può essere letto nel seguente modo: Un Parcheggio possiede degli oggetti di tipo Veicolo i quali possono essere istanze di Autovettura e/o Moto.

In questo diagramma emerge un aspetto importante, ovvero il fatto che l’oggetto di tipo Parcheggio dovrà interagire con oggetti di tipo Veicolo, senza interessarsi del fatto che essi siano istanze di Autovettura o Moto. In tal modo, se si decidesse in futuro di estendere il progetto aggiungendo, ad esempio, la classe Autocarro, come classe derivata da Veicolo, non si dovrebbero apportare cambiamenti radicali al codice di Parcheggio poiché esso continua ad interagire solo con oggetti di tipo Veicolo. Questo è il cosiddetto Strategy Pattern; esso costituisce uno dei Design Pattern sintetizzati dalla cosiddetta Gang of Four (GoF), affettuoso soprannome dato ai quattro autori dell’omonimo libro Design Patterns [4]. Entreremo un po’ più in dettaglio dei design pattern nel prossimo paragrafo. Per ora è sufficiente sapere che essi sono dei modelli generali che si adattano bene alla risoluzione di molti problemi di sviluppo del software effettuato tramite la progettazione object-oriented.

L’altro tipo di relazione has-a si ha quando l’oggetto contenuto è una parte inscindibile dell’oggetto contenente. Questa è la cosiddetta composizione. Un esempio di tale relazione è visibile in Figura 4.

Figura 4 - Un esempio di Composizione

Come è possibile notare, la composizione si indica con un rombo pieno. La relazione espressa nella Figura 4.4 si legge: Un’Autovettura possiede degli oggetti di tipo Ruota.

L’ultimo tipo di relazione che vedremo è la uses (utilizza) relationship. Un esempio di questa relazione è mostrato in Figura 5.

Figura 5 - Un esempio di Uses Relationship

Il diagramma deve essere letto nel seguente modo: Una Moto utilizza una StazioneDiServizio. Come è possibile notare dalla figura, la relazione di tipo uses viene rappresentata per mezzo di una freccia tratteggiata.

Fino ad ora abbiamo visto come rappresentare, tramite UML, le classi e le relazioni che intercorrono tra esse. A volte sorge, tuttavia, la necessit� di indicare la cardinalit� della relazione che lega una classe ad un’altra. Ad esempio, quanti oggetti di tipo Veicolo possiede un Parcheggio? La sintassi UML utilizzata per rappresentare la cardinalità è quella illustrata in Figura 6.

Figura 6 - Un primo esempio di cardinalita’ di una relazione

Il diagramma va letto nel seguente modo: Un Parcheggio può avere 0 o più oggetti di tipo Veicolo ed un Veicolo può trovarsi in 0 o 1 Parcheggio. Un altro esempio è mostrato in Figura 7.

Figura 7 - Un secondo esempio di cardinalità di una relazione

In questo caso un’Autovettura può avere uno ed un solo Volante e un Volante appartiene esattamente ad un’Autovettura.