05. Corso completo di Programmazione Java – Introduzione a UML e Diagrammi di Classe

Quanti di voi da bambini hanno messo mano ai colorati mattoncini del Lego e hanno dato sfogo alla fantasia, progettando castelli medioevali, astronavi spaziali e macchine da corsa?

Ebbene: lo sviluppo del software può essere assimilato, con una metafora ampia ma abbastanza corretta, alla creazione di modelli Lego. Ci sono componenti da assemblare, incastrare, far funzionare assieme in modo da realizzare una soluzione informatica a tutto tondo, che inserita in un contesto di business possa fornire valore; il valore introdotto può essere uno snellimento dei processi, una maggiore efficienza o addirittura supportare processi prima non immaginabili.

Per questo motivo abbiamo deciso di inserire una overview del linguaggio di modelizzazione UML 2.0 in questo corso di programmazione Java: riteniamo che sia un valore aggiunto che mantiene la sua utilità a prescindere dal linguaggio di programmazione (a oggetti) che andremo ad usare in fase di sviluppo.

Programmare ad oggetti

L’utilizzo di un linguaggo ad oggetti, come vedremo, è un presupposto importante per realizzare componenti generici, integrabili, riusabili. Ed è importante utilizzare questi linguaggi sfruttando al massimo le loro caratteristiche. A questo proposito, con a monte la considerazione che usare un linguaggio ad oggetti non è la stessa cosa di programmare ad oggetti, ci viene in aiuto la modellizzazione e progettazione della nostra applicazione. Cioè, prima di scrivere anche solo una linea di codice è importante fermarsi a ragionare per capire:

• Quali sono le entità in gioco nel nostro dominio; queste diventeranno le classi nel linguaggio di programmazione a oggetti;
• Come si relazionano tra loro le varie entità;
• Come sono distribuite le responsabilità tra le entità in gioco: chi fa cosa e come avviene la collaborazione per arrivare a raggiungere l’obiettivo prefissato;
• Architettura: organizzazione dei progetti, tiers, individuazione di componenti riusabili, di servizi generici e così via .

Cominciare a programmare senza avere uno scenario più o meno chiaro dei punti di cui sopra è molto rischioso e spesso segna la differenza tra uno “Spaghetti Coder” che mette in atto il “Cowboy Programming” (fonti storiche rivelano che i Cowboy mangiano spaghetti, non fagioli 🙂 ) e un professionista dedito a consegnare un prodotto affidabile che andrà ad operare in un contesto di produzione reale.

La modellazione – UML

Come si fa la modellizzazione? Si può fare in tanti modi e con tanti strumenti, difficile dire quali sono meglio di altri. Tuttavia quello che vi posso dire è che non è quasi mai una buona idea inventarsi un proprio standard per fare modellizzazione, soprattutto quando uno standard valido esiste già. E si dà il caso che esista: UML 2.0 (Unified Modeling Language) è un linguaggio standard di modellizzazione grafica che si propone di essere:

• Chiaro e univoco, a differenza dei linguaggi parlati come l’Italiano o l’Inglese;
• Veloce da usare e da interpretare;
• Universale.

Per questo motivo, senza alcun dubbio vi suggerisco di utilizzarlo, perché la notazione seguente:

è chiara solo per chi l’ha inventata e per chi gli vuole bene, mentre questa:



rispetta uno standard che può essere fruito da molte più persone.

Tipi di diagrammi

Nell’UML 2.0 ci sono molti tipi di diagrammi:

• Diagrammi strutturali, che si dividono in:
  • Class diagram
  • Component diagram
  • Composite structure diagram
  • Deployment diagram
  • Package diagram
  • Object diagram
• Diagrammi di comportamento, che si dividono in:
  • Class diagram
  • Activity diagram
  • Communication diagram
  • Interaction overview diagram
  • Sequence diagram
  • State machine diagram
  • Timing diagram
  • Use case diagrams

Fermo, voglio scendere!

Sì, lo so: state pensando che c’è un sacco da imparare in UML e che il gioco non vale la candela. Beh, in reltà i diagrammi più diffusi e utili sono i diagrammi di classe, che sono quelli che andremo a vedere in questo post. In un successivo affronteremo i diagrammi di stato, quelli di attività e gli use case.

Però la considerazione che mi preme di fare sull’UML è questa: nasce come linguaggio grafico e con molte notazioni opzionali proprio per essere usato a tutti i livelli: è possibile fare un diagramma che descrive ogni singolo particolare o uno che fornisce una overview generale, è possibile usare strumenti software per tracciarli, ma è anche possibile fare uno sketch con carta e penna…insomma: UML è un po’ come l’inglese, non dobbiamo leggere Shakespeare, ma capirci nel modo più chiaro e veloce possibile, qualche “sgrammaticatura” è perdonata!

Diagrammi di classe

I diagrammi di classe sono i più diffusi e importanti diagrammi. Mostrano quali sono le entità in gioco nel dominio applicativo, i loro attributi (o proprietà), le operazioni che possono compiere (che sono quindi loro responsabilità) e le relazioni che le legano. Siete pronti a costruirne uno insieme?

MiniShop Online

Come esempio per il nostro diagramma di classe andiamo a modellare un mini sistema di e-commerce: un cliente che ha un indirizzo può effettuare uno o più ordini, ciascuno contenente più articoli, con la propria quantità. Il pagamento può avvenire in 2 modi: carta di credito o contrassegno.

Cominciamo dall’entità

Nel nostro dominio abbiamo un cliente: in UML questo si scrive così:

Poi alla nostra entità vorremmo aggiungere degli attributi, ovvero proprietà che la caratterizzano:

Associazioni

Mettiamo adesso in relazione l’entità Cliente con l’entità Indirizzo. Vogliamo graficamente poter specificare che un Cliente avrà un indirizzo di residenza, mentre un indirizzo può avere più clienti che vi risiedono. In UML questa frase verbosa diventa:

Le associazioni sono semplici linee. La molteplicità è opzionale (se assente equivale ad 1) e i ruoli, contrassegnati dalle stringhe di testo alle due estremità della associazione, sono anch’essi opzionali, anzi bene non scriverli quando possono essere capiti dal contesto.

Aggregazione e Composizione (?)

Aggregazione e Composizione sono due tipi speciali di associazioni. Un’aggregazione specifica un’associazione di tipo “parte – intero” in cui una classe che rappresenta l'”intero” è costituita da più classi che la compongono. Una composizione è una forma più forte di aggregazione in cui un componente può appartenere soltanto ad un “intero”.

Un tipico esempio di composizione lo abbiamo nel nostro esempio del MiniShop Online: l’ordine si compone di righe ordine. L’ordine non esiste senza almeno una riga, le righe a loro volta non hanno senso se non come facenti parte di un ordine; l’inclusione è fisica è vincolante: se cancello l’ordine andrò certamente a cancellare anche le righe. Questo tipo di relazione in UML si rappresenta come di seguito:

Notiamo inoltre che l’entità Ordine e RigaOrdine sono rappresentate divise in 3 scomparti: il primo, obbligatorio, contiene il nome dell’entità (del tipo, della classe, tutti più o meno sinonimi, o quasi 🙂 ), il secondo gli attributi (o le proprietà), il terzo le operazioni (o i metodi). Le operazioni sono in sostanza funzioni (o procedure) relative a una determinata entità: sono i compiti che quell’entità sa e/o deve svolgere. Le entità, ciascuna per le proprie competenze, collaboreranno nel portare a fondo le operazioni richieste.

Nel linguaggio a oggetti c’è uno shift deciso dalla mega funzione che fa tutto quanto il programma deve fare (ovvero è il programma) verso una distribuzione di compiti tra entità del dominio.

Ereditarietà

In UML è possibile specificare una relazione di ereditarietà. Per capire se una relazione tra le entità A e B sia di ereditarietà dobbiamo formulare la frase “A è un B”: se la frase ha senso abbiamo tra le mani una relazione di ereditarietà. Ad esempio: l’entità Studente eredita dall’entità Persona, infatti uno “Studente è una Persona”. Tornando al nostro MiniShop abbiamo detto che ci sono due tipi di Pagamento: carta di credito e contrassegno; loro rappresentano due diversi tipi di pagamento e questa situazione in UML si modella come segue:

Vedremo nel seguito che Java, come tutti i linguaggi a oggetti, consente di realizzare questo tipo di importanti relazioni, che aprono la strada al riutilizzo del codice e al polimorfismo. “Poliché?” Non temete, ne parleremo :-).

Il diagramma completo

Riportiamo adesso il diagramma di classe UML completo che descrive il nostro MiniShop Online:

Alcuni strumenti per tracciare diagrammi UML

Ci siamo detti che non è necessario avere degli strumenti sofisticati per tracciare diagrammi UML. Tuttavia per chi volesse utilizzare qualche tool non c’è che l’imbarazzo della scelta: ci sono molti software adatti allo scopo, sia commerciali che free/open source. In più di una occasione ho utilizzato ArgoUML, gratuito e completo. Visitando invece yUML avete a disposizione la possibilità di creare diagrammi UML all’interno del vostro browser, esportarli come immagine o pubblicarli direttamente sul vostro blog. Vi segnalo infine Umbrello UML Modeller, solo per Linux.

Riferimenti

Ci sono molte ottime risorse online sull’UML: tutorial, guide complete, articoli et similia che potete trovare semplicemente “googolando”. Vi segnalo invece 2 libri che, tra gli altri, mi hanno colpito:

• UML distilled. Guida rapida al linguaggio di modellazione standard, tra i cui autori troviamo Martin Fowler;
• Dall’idea al codice con UML 2. Guida all’utilizzo di UML attraverso esempi, in italiano, compatto e molto chiaro con esercizi di modelizzazione a partire da un problema reale.

Infine se, come a me, la passione per il Lego ancora non vi è passata, sappiate che la Lego mette a disposizione gratuitamente il Lego Digital Design per progettare online e condividere i propri capolavori di creatività.

Conclusioni

In questo post abbiamo appena intravisto la punta dell’iceberg: anche il solo diagramma di classi può essere molto più dettagliato, è possibile specificare molteplicità anche per gli attributi, valori di default, inserire note, specificare che una entità può essere astratta o un’interfaccia….ops, questo non ve lo dovevo dire…così vi sciupo la sorpresa!

Alla prossima!

Il corso continua con…

06 – Introduzione all’OOP – Parte I.