La notazione grafica è forse il mezzo più immediato per far comprendere ad altri un concetto o un’idea. Un diagramma chiaro può valere anche più di mille parole. Il problema è che spesso è difficile realizzare uno schema semplice ma al tempo stesso esauriente. Con questo primo articolo inizia un panoramica su uno dei principali metodi per la descrizione, tramite schemi standard, del funzionamento dei più disparati sistemi: Unified Modeling Language.
Obiettivo di queste puntate su UML è quello di introdurre il lettore all’uso di un linguaggio unificato per la descrizione, non solo di applicazioni software, ma di qualunque tipologia di problema. Questo linguaggio è detto UML, ossia Unified Modeling Language o linguaggio di modellazione unificato. In ingegneria del software UML è un linguaggio di modellazione e specifica basato sul paradigma object-oriented. Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim Rumbaugh e Ivar Jacobson (detti “i tre amigos”) sotto l’egida dello OMG, che tuttora gestisce lo standard di UML. Il linguaggio nacque con l’intento di unificare approcci precedenti (dovuti ai tre padri di UML e altri), raccogliendo le best practices nel settore e definendo così uno standard industriale unificato. UML svolge un’importantissima funzione di lingua franca nella comunità della progettazione e programmazione a oggetti: una sorta di esperanto. Gran parte della letteratura di settore usa UML per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico. L’ultima versione del linguaggio, la 2.0, è stata consolidata nel 2004 e ufficializzata da OMG nel 2005. UML 2.0 riorganizza molti degli elementi della versione precedente in un quadro di riferimento ampliato e introduce molti nuovi strumenti, inclusi alcuni nuovi tipi di diagrammi. Anche se OMG indica UML 2.0 come la versione “corrente” del linguaggio, la transizione è di fatto ancora in corso; le stesse specifiche pubblicate da OMG sono ancora non completamente aggiornate e il supporto dei tool a UML 2.0 è, nella maggior parte dei casi, appena abbozzato. Spesso si pensa a UML come un linguaggio per descrivere il flusso logico di un software, ma in realtà le sue potenzialità si estendono in campi ben più ampi; sistemi o parti di sistemi per la distribuzione dell’energia elettrica, strutture organizzative aziendali o processi di business sono solo alcuni esempi.
Cenni storici
I linguaggi per la modellazione orientata agli oggetti iniziarono a svilupparsi intorno agli anni ’80. Si trattava di metodi differenti che permettevano di descrivere la struttura di un sistema software, in termini di classi, relazioni e comportamenti dinamici. Come spesso accade quando non vi è un organo di unificazione, è molto probabile la diffusione di varie scuole di pensiero che portano a standard differenti e tra loro incompatibili. In questo caso si parlò addirittura di guerre dei metodi o method wars. Intor no alla metà degli anni ’90 vari metodi iniziarono a fondersi per dar vita a metodologie unificate. Tra queste quelle più note sono state:
➤ Il metodo OMT (Object Modeling Technique) di Jim Rumbaugh.
➤ Il metodo Booch di Grady Booch.
➤ Il metodo Jacobson.
I primi due sono entrambi ricercatori presso la Rational Software, mentre Jacobson appartiene alla software house Objectory. Queste metodologie avevano molti aspetti comuni, da qui lo sforzo congiunto dei tre ricercatori (anche chiamati Three Amigos) per giungere ad un modello unificato; questo risultato fu chiamato OOSE (Object Oriented Software Engineering). Intanto, l’impresa dei tre non lasciò indifferente l’OMG (Object Management Group), un consorzio fondato proprio con l’obiettivo di creare e gestire standard per lo sviluppo di software ad oggetti. Nel 1995, l’OMG raccolse tutti i principali metodologisti del settore in un incontro internazionale per discutere della notazione unificata. Nel 1996 l’OMG emise una RFP (Request For Proposal) per tale notazione. Nello stesso anno, Booch, Rumbaugh e Jacobson misero a punto le release 0.9 e 0.91 di UML. Il progetto fu ben accolto dalla comunità internazionale e innumerevoli grandi organizzazioni si unirono a Rational per proseguirlo (per esempio Digital, Hewlett-Packard, IBM, Microsoft, Oracle e Unisys). Questo gruppo esteso realizzò, nel 1997, UML 1.0, che fu sottoposto alla OMG come risposta alla RFP dell’anno precedente. La release 1.1 di UML contribuì a consolidare la semantica del linguaggio e incluse elementi tratti da una proposta avanzata indipendentemente all’OMG da un gruppo composto da IBM, ObjectTime, Ptech e altre.
Le fasi di analisi e progetto
UML è utilizzato per la modellazione di sistemi reali. Tale modellazione include l’analisi e il progetto. Con l’analisi il sistema è inizialmente descritto con un insieme di requisiti, a cui segue l’identificazione delle parti ad alto livello. La fase di progettazione è strettamente connessa a quella di analisi. A tale livello le parti identificate vengono descritte con un livello di dettaglio maggiore, includendo anche le relazioni tra esse. In entrambe le fasi, UML si avvale di appositi diagrammi che consento di soddisfare particolari necessità:
➤ Il modello funzionale (functional model) rappresenta il sistema dal punto di vista dell’utente. Descrive il suo comportamento così come appare all’esterno, a prescindere dal suo funzionamento interno. Questo tipo di modellazione corrisponde, in ingegneria del software, all’analisi dei requisiti. La modellazione funzionale utilizza gli Use Case Diagram (diagrammi dei casi d’uso).
➤ Il modello a oggetti (object model) rappresenta la struttura e sottostruttura del sistema utilizzando i concetti objectoriented di classe, oggetto, le relazioni fra classi e fra oggetti. In ingegneria del software, questo tipo di modellazione può essere utilizzata sia nella fase di analisi del dominio che nelle varie fasi di progetto a diversi livelli di dettaglio. Utilizza class diagram (diagrammi delle classi), object diagram (diagrammi degli oggetti), e deployment diagram (diagrammi di deployment).
➤ Il modello dinamico (dynamic model) rappresenta il comportamento degli oggetti del sistema, ovvero la loro evoluzione nel tempo e le dinamiche delle loro interazioni. È strettamente legato al modello a oggetti e viene impiegato negli stessi casi. Utilizza i sequence diagram (diagrammi di sequenza), gli activity diagram (diagrammi delle attività) e gli statechart diagram (diagrammi degli stati).
Diagrammi per descrivere la realtà
Come descritto in precedenza, UML si avvale di differenti strumenti per definire i vari diagrammi. I building block in UML sono le entità (thing) e le relazioni (relationship). Essi sono combinati in differenti modi, seguendo regole diverse per creare ogni tipo di diagramma previsto dalla specifica. In UML esistono nove tipi di diagrammi di seguito elencati:
■ 1-Use case diagram; sono anche detti UCD o diagrammi dei casi d’uso. Si tratta di diagrammi dedicati alla descrizione delle funzioni o servizi offerti da un sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso. Sono impiegati soprattutto nel contesto della Use Case View (vista dei casi d’uso) di un modello, e in tal caso si possono considerare come uno strumento di rappresentazione dei requisiti funzionali di un sistema. Tuttavia, non è impossibile ipotizzare l’uso degli UCD in altri contesti; durante la progettazione, per esempio, potrebbero essere usati per modellare i servizi offerti da un determinato modulo o sottosistema ad altri moduli o sottosistemi. In molti modelli di processo software basati su UML, la Use Case View e gli Use Case Diagram che essa contiene rappresentano la vista più importante, attorno a cui si sviluppano tutte le altre attività del ciclo di vita del software (si parla di processi use case driven). Un esempio è riportato in figura 1.
Figura 1: esempio di diagramma d’uso (use case diagram).
■ 2-Class diagram; descrive la struttura del sistema, diviso in classi con differenti connessioni e relazioni. La figura 2 ne mostra una rappresentazione. In termini generali, consentono di descrivere tipi di entità, con le loro caratteristiche, e le eventuali relazioni fra questi tipi. Gli strumenti concettuali utilizzati sono il concetto di classe del paradigma objectoriented e altri correlati (per esempio la generalizzazione, che è una relazione concettuale assimilabile al meccanismo object-oriented dell’ereditarietà).
Figura 2: esempio di diagramma delle classi (class diagram).
■ 3-Sequence diagram (interaction diagram); è un diagramma utilizzato per descrivere uno scenario. Uno scenario è una determinata sequenza di azioni in cui tutte le scelte sono state già effettuate; in pratica nel diagramma non compaiono scelte, né flussi alternativi. Quello mostrato in figura 3 è un tipico esempio.
Figura 3: esempio di diagramma sequenziale (sequence diagram).
■ 4-State chart diagram; è un diagramma utilizzato per descrivere il comportamento di entità o di classi in termini di stato (macchina a stati). Il diagramma mostra gli stati che sono assunti dall’entità o dalla classe in risposta ad eventi esterni. Il concetto di stato è spesso posto in relazione al ciclo di vita; l’insieme completo di stati che un’entità o una classe può assumere, dallo stato iniziale a quello finale, ne rappresenta il ciclo di vita. Gli elementi rappresentati da uno State Chart Diagram sono lo stato - distinguendo tra iniziale, intermedio e stato finale - l’evento, l’azione (vedere figura 4).
Figura 4: esempio di diagramma a stati (state chart diagram).
■ 5-Activity diagram; mostra il flusso attraverso un programma da un punto di partenza ad un punto finale. E’ un diagramma che definisce le attività da svolgere per realizzare una data funzionalità. Può essere utilizzato anche in fase di design per dettagliare un determinato algoritmo. In teoria ad ogni Use Case Diagram dovrebbe corrispondere un Activity Diagram.
■ 6-Object diagram; è costituito da un insieme di oggetti con le loro relazioni; può essere considerato come un caso particolare del diagramma delle classi.
■ 7-Collaboration diagram; ha lo scopo di enfatizzare l’ordine strutturale degli oggetti che scambiano messaggi.
■ 8-Component diagram; è la rappresentazione statica di un sistema, evidenziano le sue parti costituenti. Un Diagramma dei Componenti può essere considerato alla stregua di un’estensione dei diagrammi delle classi. In tale diagramma vengono evidenziate principalmente l’organizzazione e le dipendenze tra componenti software. Infatti, spesso, si usa mettere in relazione i diagrammi dei componenti con i diagrammi di deployement, sottolineandone le differenze e gli aspetti comuni: i primi rappresentano la composizione del sistema nei sui elementi software, mentre i secondi descrivono la distribuzione fisica di un sistema. In particolare i componenti possono essere inclusi nei diagrammi di deployement. Un diagramma dei componenti nasce dall’interazione dei componenti, dove per componente si intende una parte di software con una precisa identità e con le interfacce esplicitamente definite.
■ 9-Deployment diagram; è un diagramma di tipo statico previsto per descrivere un sistema in termini di risorse hardware dette nodi e di relazioni fra di esse. Spesso si utilizza un diagramma che mostra come le componenti software sono distribuite rispetto alle risorse hardware disponibili sul sistema; questo diagramma è costruito unendo il Component Diagram e il Deployment Diagram. Un esempio è riportato in figura 5.
Figura 5: esempio di diagramma di dispiegamento (Deployment diagram).
Conclusioni
In questo articolo si sono introdotti i concetti base di UML, nonché le nozioni storiche che hanno portato alla sua affermazione come strumento unificato di modellazione. Si è inoltre discusso dei diagrammi utilizzati per la rappresentazione grafica e le modalità di utilizzo degli stessi. Prossimamente saranno presentati gli oggetti che costituiscono i diagrammi, nonché le relazioni esistenti tra questi, ossia il modo di connette le entità tra loro per produrre una rappresentazione funzionale del problema.
