<para>Questo capitolo ti darà una rapida panoramica dei fondamenti di &UML;. Tieni presente che questo non è un corso completo di &UML;, ma piuttosto una breve introduzione a &UML;, che può essere letta come un corso di &UML;. Se vuoi saperne di più sul Linguaggio di Modellazione Unificato, o in generale sull'analisi e la progettazione del software, riferisciti a uno dei molti libri disponibili sull'argomento. Ci sono anche molti corsi su Internet che puoi usare come punto di partenza. </para>
<para>Il Linguaggio di Modellazione Unificato (&UML;) è un linguaggio o notazione di diagrammi per specificare, visualizzare e documentare modelli di sistemi di software a oggetti. &UML; non è un metodo di sviluppo, cioè non ti dice cosa fare prima e dopo o come progettare il tuo sistema, ma ti aiuta a visualizzare la tua progettazione e comunicare con gli altri. &UML; è controllato dal Gruppo di Gestione Oggetti (<acronym>OMG</acronym>) ed è lo standard industriale per descrivere graficamente il software. </para>
<para>&UML; è progettato per la progettazione di software a oggetti, e ha un uso limitato per altri paradigmi di programmazione. </para>
<para>&UML; si compone di molti elementi di modelli che rappresentano le diverse parti di un sistema software. Gli elementi &UML; sono usati per creare diagrammi, che rappresentano una certa parte, o punto di vista del sistema. &umbrello; supporta i seguenti tipi di diagrammi: </para>
<listitem><para><emphasis><link linkend="use-case-diagram">I diagrammi di caso d'uso</link></emphasis> mostrano gli attori (persone o altri utenti del sistema), i casi d'uso (gli scenari di quando usano il sistema), e le loro relazioni</para> </listitem>
<listitem><para><emphasis><link linkend="class-diagram">I diagrammi di classe</link></emphasis> mostrano le classi e le relazioni tra loro</para> </listitem>
<listitem><para><emphasis><link linkend="sequence-diagram">I diagrammi di sequenza</link></emphasis> mostrano gli oggetti e una sequenza di chiamate a metodi che essi fanno ad altri oggetti.</para> </listitem>
<listitem><para><emphasis><link linkend="collaboration-diagram">I diagrammi di collaborazione</link></emphasis> mostrano gli oggetti e le loro relazioni, ponendo l'attenzione sugli oggetti che partecipano nello scambio di messaggi</para>
<listitem><para><emphasis><link linkend="state-diagram">I diagrammi di stato</link></emphasis> mostrano gli stati, i cambi di stato e gli eventi in un oggetto o in una parte del sistema</para> </listitem>
<listitem><para><emphasis><link linkend="activity-diagram">I diagrammi di attività</link></emphasis> mostrano le attività e i cambiamenti da un'attività all'altra con gli eventi che accadono in qualche parte del sistema</para></listitem>
<listitem><para><emphasis><link linkend="component-diagram">I diagrammi dei componenti</link></emphasis> mostrano i componenti della programmazione di alto livello (come KPart o Java Beans).</para></listitem>
<listitem><para><emphasis><link linkend="deployment-diagram">I diagrammi di dispiegamento</link></emphasis> mostrano le istanze dei componenti e le loro relazioni.</para></listitem>
<para>I diagrammi di caso d'uso descrivono le relazioni e le dipendenze tra un gruppo di <emphasis>Casi d'uso</emphasis> e gli attori partecipanti al processo.</para>
<para>È importante notare che i diagrammi di caso d'uso non sono adatti a rappresentare la progettazione, e non possono descrivere le parti interne di un sistema. I diagrammi di caso d'uso servono a facilitare la comunicazione con gli utenti futuri del sistema e con il cliente, e sono particolarmente utili a determinare le funzionalità necessarie che il sistema deve avere. I diagrammi di caso d'uso dicono <emphasis>cosa</emphasis> deve fare il sistema, ma non specificano <emphasis>come</emphasis> si deve fare (e non possono).</para>
<para>Un <emphasis>Caso d'uso</emphasis> descrive, dal punto di vista degli attori, un gruppo di attività in un sistema che produce un risultato concreto e tangibile.</para>
<para>I casi d'uso sono descrizioni delle interazioni tipiche tra gli utenti di un sistema e il sistema stesso. Rappresentano l'interfaccia esterna del sistema, e specificano un modulo di requisiti di cosa il sistema deve fare (ricorda, solo cosa, non come). </para>
<para>Lavorando con i casi d'uso, è importante ricordare alcune semplici regole: <itemizedlist>
<listitem><para>Ogni caso d'uso è relativo ad almeno un attore</para></listitem>
<listitem><para>Ogni caso d'uso ha un iniziatore (&ie; un attore)</para></listitem>
<listitem><para>Ogni caso d'uso porta a un risultato rilevante (un risultato con <quote>valore di business</quote>)</para>
<listitem><para><emphasis><<inclusione>></emphasis> che specifica che un caso d'uso avviene <emphasis>all'interno</emphasis> di un altro caso d'uso</para></listitem>
<listitem><para><emphasis><<estensione>></emphasis> che specifica che in certe situazioni, o a un certo punto (chiamato punto di estensione) un caso d'uso sarà esteso da un altro.</para></listitem>
<listitem><para>La <emphasis>generalizzazione</emphasis> specifica che un caso d'uso eredita le caratteristiche del <quote>sovra</quote>caso d'uso, e può sostituirne alcune o aggiungerne nuove in un modo simile all'ereditarietà tra classi. </para>
<para>Un attore è un'entità esterna (fuori dal sistema) che interagisce con il sistema partecipando a (e spesso iniziando) un caso d'uso. Gli attori possono essere persone reali (per esempio utenti del sistema), altri sistemi o eventi esterni. </para>
<para>Gli attori non rappresentano le persone <emphasis>fisiche</emphasis> o i sistemi, ma il loro <emphasis>ruolo</emphasis>. Ciò significa che quando una persona interagisce con il sistema in modi diversi (assumendo ruoli diversi) sarà rappresentata da diversi attori. Per esempio una persona che fornisce supporto per telefono e immette ordini dal cliente nel sistema sarebbe rappresentato da un attore <quote>Squadra di supporto</quote> e un attore <quote>Rappresentante di vendita</quote> </para>
<para>Le descrizioni di caso d'uso sono racconti testuali del caso d'uso. Prendono normalmente la forma di una nota o di un documento che è in qualche modo collegato al caso d'uso, e ne spiega i processi o le attività. </para>
<para>I diagrammi di classe mostrano le diverse classi che costituiscono un sistema e come si relazionano una all'altra. I diagrammi di classe sono detti essere diagrammi <quote>statici</quote> perché mostrano le classi, insieme ai loro metodi e attributi oltre alle relazioni statiche tra loro: quali classi <quote>sanno</quote> di quali classi o quali classi <quote>fanno parte</quote> di un'altra classe, ma non mostrano le chiamate ai metodi tra di loro. </para>
<para>Una classe definisce gli attributi e i metodi di un insieme di oggetti. Tutti gli oggetti di questa classe (istanze di questa classe) condividono lo stesso comportamento, e hanno lo stesso insieme di attributi (ogni oggetto ha il suo insieme). A volte il termine <quote>Tipo</quote> è usato invece di classe, ma è importante ricordare che questi due non sono la stessa cosa, e Tipo è un termine più generale. </para>
<para>In &UML; le classi sono rappresentate da rettangoli con il nome della classe, e possono anche mostrare gli attributi e le operazioni della classe in due altri <quote>scompartimenti</quote> all'interno del rettangolo. </para>
<para>In &UML; gli attributi sono mostrati con almeno il loro nome, e possono mostrare anche il loro tipo, il valore iniziale e altre proprietà. Gli attributi possono anche essere mostrati con la loro visibilità: </para>
<para>Anche le operazioni (metodi) sono mostrate con almeno il loro nome, e possono mostrare anche i loro parametri e i tipi restituiti. Le operazioni possono, come gli attributi, mostrare la loro visibilità: <itemizedlist>
<listitem><para><literal>+</literal> sta per operazioni <emphasis>pubbliche</emphasis></para></listitem>
<listitem><para><literal>#</literal> sta per operazioni <emphasis>protette</emphasis></para></listitem>
<listitem><para><literal>-</literal> sta per operazioni <emphasis>private</emphasis></para></listitem>
<para>Le classi possono avere modelli, un valore che è usato per una classe o untipo non specificato. Il tipo di modello è specificato quando viene iniziata una classe (&ie; cioè viene creato un oggetto). I modelli esistono nel C++ moderno e saranno introdotti in Java 1.5 dove saranno chiamati Generics. </para>
<para>L'ereditarietà è uno dei concetti fondamentali della programmazione a oggetti, in cui una classe <quote>acquisisce</quote> tutti gli attributi e le operazioni della classe da cui eredita, e può sostituire o modificare alcuni di loro, oltre ad aggiungere più attributi e operazioni di suo.</para>
<para>In &UML;, un'associazione di <emphasis>Generalizzazione</emphasis> tra due classi le mette in una gerarchia rappresentante il concetto di ereditarietà di una classe derivata da una classe di base. In &UML; le generalizzazioni sono rappresentate da una linea che connette le due classi, con una freccia sul lato della classe di base. <screenshot>
<para>Un'associazione rappresenta una relazione tra classi, e dà la semantica e la struttura comuni a molti tipi di <quote>connessioni</quote> tra oggetti.</para>
<para>Le associazioni sono i meccanismi che permettono agli oggetti di comunicare tra loro. Descrivono la connessione tra diverse classi (la connessione tra gli oggetti reali è chiamata una connessione tra oggetti, o <emphasis>collegamento</emphasis>). </para>
<para>Le associazioni possono avere un ruolo che specifica lo scopo dell'associazione e può essere uni- o bidirezionale (indica se i due oggetti che partecipano alla relazione possono mandare messaggi all'altro, o se solo uno di loro sa dell'altro). Ogni parte dell'associazione ha un valore di molteplicità, che detta quanti oggetti su questo lato dell'associazione possono relazionarsi a un oggetto sull'altro lato. </para>
<para>In &UML; le associazioni sono rappresentate come linee che connettono le classi che partecipano alla relazione, e possono anche mostrare il ruolo e la molteplicità di ciascuno dei partecipanti. La molteplicità è mostrata come un intervallo [minimo..massimo] di valori non negativi, con un asterisco (<literal>*</literal>) sul lato massimo per rappresentare l'infinito. <screenshot>
<para>Le aggregazioni sono un tipo speciale di associazioni nel quale le due classi partecipanti non hanno un rango uguale, ma hanno una relazione <quote>intero-parte</quote>. Un'aggregazione descrive come la classe che ha il ruolo dell'intero è composta di (ha) altre classi, che hanno il ruolo di parti. Per le aggregazioni, la classe che fa da intero ha sempre molteplicità di uno. </para>
<para>In &UML; le aggregazioni sono rappresentate da un'associazione che mostra un rombo sul lato dell'intero. <screenshot>
<para>Le composizioni sono associazioni che rappresentano aggregazioni <emphasis>molto forti</emphasis>. Ciò vuol dire che anche le composizioni formano relazioni intero-parte, ma la relazione è così forte che la parte non può esistere di per sé. Esistono solo all'interno dell'intero, e se l'intero è distrutto anche le parti muoiono.</para>
<para>In &UML; le composizioni sono rappresentate da un rombo solido sul lato dell'intero. </para>
<para>Le interfacce sono classi astratte, che vuol dire che non se ne possono creare istanze direttamente. Possono contenere operazioni ma non attributi. Le classi possono ereditare dalle interfacce (attraverso una associazione di realizzazione) e possono essere create delle istanze di questi diagrammi.</para>
<para>I tipi di dati sono delle primitive tipicamente incorporate in un linguaggio di programmazione. Gli esempi comuni includono gli interi e i booleani. Non possono avere relazioni con le classi, ma le classi possono avere relazioni con loro.</para>
<para>Le enumerazioni sono semplici elenchi di valori. Un esempio tipico è un'enumerazione dei giorni della settimana. Le opzioni di un'enumerazione sono chiamate letterali dell'enumerazione. Come i tipi di dati non possono avere relazioni con le classi, ma le classi possono avere relazioni con loro.</para>
<para>I pacchetti rappresentano un namespace in un linguaggio di programmazione. In un diagramma sono usati per rappresentare parti di un sistema che contiene più di una classe, forse centinaia di classi.</para>
<para>I diagrammi di sequenza mostrano lo scambio di messaggi (&ie; la chiamata ai metodi) tra diversi oggetti in una situazione temporale precisa. Gli oggetti sono istanze di classi. I diagrammi di sequenza mettono particolare enfasi sull'ordine e l'ora a cui i messaggi sono inviati agli oggetti.</para>
<para>Nei diagrammi di sequenza gli oggetti sono rappresentati con linee verticali tratteggiate, con il nome dell'oggetto in cima. Anche l'asse temporale è verticale, e aumenta andando in giù, in modo che i messaggi sono inviati da un oggetto all'altro nella forma di frecce con l'operazione e il nome del parametro. </para>
<para>I messaggi possono o essere sincroni, il tipo normale di chiamate ai messaggi dove il controllo è passato all'oggetto chiamato fino a quando quel metodo ha finito l'esecuzione, o asincrono, dove il controllo è ripassato direttamente all'oggetto chiamante. I messaggi sincroni hanno un riquadro verticale a lato dell'oggetto chiamato per mostrare il flusso di controllo del programma.</para>
<para>I diagrammi di collaborazione mostrano le interazioni che avvengono tra gli oggetti che partecipano a una situazione specifica. È più o meno la stessa informazione mostrata nei diagrammi di sequenza, ma lì l'enfasi è messa su come le interazioni avvengono nel tempo, mentre i diagrammi di collaborazione mettono in primo piano le relazioni tra gli oggetti e la loro topologia.</para>
<para>Nei diagrammi di collaborazione i messaggi inviati da un oggetto a un altro sono rappresentati da frecce, che mostrano il nome, i parametri e la sequenza del messaggio. I diagrammi di collaborazione sono specialmente adatti a mostrare un particolare flusso o situazione di programma e sono uno dei migliori tipi di diagramma per dimostrare o spiegare rapidamente un processo nella logica del programma. </para>
<para>I diagrammi di stato mostrano i diversi stati di un oggetto durante la sua vita e gli stimoli che gli fatto cambiare stato. </para>
<para>I diagrammi di stato vedono gli oggetti come <emphasis>macchine di stato</emphasis> o automi finiti che possono essere in uno stato di un insieme di stati finiti e che possono cambiare stato con uno stimolo di un insieme finito di stimoli. Per esempio un oggetto di tipo <emphasis>ServerDiRete</emphasis> può essere in uno dei seguenti stati durante la sua vita: </para>
<para>Gli stati sono i mattoni del diagramma di stato. Uno stato appartiene a esattamente una classe e rappresenta un riassunto dei valori che gli attributi di una classe possono assumere. Uno stato &UML; descrive lo stato interno di un oggetto di una classe particolare </para>
<para>Nota che non tutti i cambiamenti negli attributi di un oggetto dovrebbe essere rappresentato da uno stato, ma solo quei cambiamenti che influenzano significativamente il funzionamento dell'oggetto</para>
<para>Ci sono due tipi speciali di stati: Inizio e Fine. Sono speciali perché non ci sono eventi che possono far tornare un oggetto al suo stato di Inizio, allo stesso modo in cui non è possibile riportare un oggetto dal suo stato di Fine una volta che lo raggiunge. </para>
<para>I diagrammi di attività descrivono la sequenza di attività in un sistema con l'aiuto delle attività. I diagrammi di attività sono una forma speciale dei diagrammi di stato, che contengono solo (o per lo più) attività. </para>
<para>I diagrammi di attività sono simili ai diagrammi di flusso procedurali, con la differenza che tutte le attività sono chiaramente connesse a degli oggetti.</para>
<para>I diagrammi di attività sono sempre associati a una <emphasis>classe</emphasis>, un'<emphasis>operazione</emphasis> o un <emphasis>caso d'uso</emphasis>.</para>
<para>I diagrammi di attività supportano attività sequenziali e parallele. L'esecuzione parallela è rappresentata con le icone Separa/Attendi; per le attività in esecuzione in parallelo, non è importante l'ordine in cui sono eseguite (possono essere eseguite allo stesso tempo o una dopo l'altra)</para>
<para>Un'attività è un singolo passo in un processo. Un'attività è uno stato del sistema con attività interna e, almeno, una transizione all'esterno. Le attività possono anche avere più di una transizione all'esterno se hanno più condizioni. </para>
<para>Le attività possono formare gerarchie, vale a dire che un'attività può essere composta di più attività di <quote>dettaglio</quote>, nel qual caso le transizioni all'interno e all'esterno dovrebbero corrispondere alle transizioni all'interno e all'esterno del diagramma dei dettagli. </para>
<para>Ci sono alcuni elementi in &UML; che non hanno una vera e propria semantica per il modello, ma aiutano a chiarificare parti del diagramma. Questi elementi sono </para>
<listitem><para>Note di testo e ancore</para></listitem>
<listitem><para>Riquadri</para></listitem>
</itemizedlist>
<para>Le righe di testo sono utili per aggiungere brevi informazioni testuali a un diagramma. È testo libero e non ha significato per il modello stesso. </para>
<para>Le note sono utili per aggiungere informazioni più dettagliate su un oggetto o una situazione specifica. Hanno il grande vantaggio che le note possono essere ancorate a elementi &UML; per mostrare che la nota <quote>appartiene</quote> a un oggetto o una situazione specifici. </para>
<para>I riquadri sono rettangoli liberi che possono essere usati per raggruppare insieme degli elementi per rendere i diagrammi più leggibili. Non hanno nessun significato logico nel modello.</para>
<para>I diagrammi dei componenti mostrano i componenti software (tecnologie componenti come KPart, componenti CORBA, Java Beans o solo sezioni del sistema che sono chiaramente distinguibili) e i manufatti di cui sono fatti come file di codice sorgente, librerie di programmazione o tabelle di banche dati relazionali.</para>
<para>I diagrammi di dispiegamento mostrano le istanze dei componenti durante l'esecuzione e le loro associazioni. Includono i nodi, che sono risorse fisiche, tipicamente un computer singolo. Mostrano anche interfacce e oggetti (istanze di classi).</para>
