Introduzione
Nell’articolo
precedente sono stati illustrati gli strumenti messi a disposizione dallo
Unified Modeling Language per modellare la proiezione software della architetturra
fisica di un sistema. In particolare è stata introdotta la component
view, e si è visto come essa sia interamente costituita dagli omonimi
diagrammi, nei quali l’elemento base, intorno al quale ruota l’intera vista,
è il componente. Nel presente articolo si focalizza l’attenzione
sulla proiezione Hw dell’architettura fisica di un sistema fornita dalla
deployment view, in cui, in modo del tutto analogo alla component view,
l’elemento base è costituito dai nodi: elementi che esistono nel
mondo reale (in questo caso nel senso etimologico del termine) e rappresentano
risorse computazionali, aventi almeno funzione di memorizzazione e tipicamente
anche capacitá elaborative. I nodi rappresentano i processori o
i dispositivi in cui vengono allocati i componenti per poter essere eseguiti
e la relativa sommatoria, corredata da opportuni collegamenti, costituisce
l’ambiente Hw nel quale il sistema viene eseguito.
La
Deployment View presenta molte analogie con la Componet View, ed il rapporto
che intercorre tra componenti e nodi è che, mentre i componenti
permettono di raggruppare le entità scaturite dall’analisi logica
del sistema (classi, interfacce, …) i nodi rappresentano i dispositivi
dove tali componenti vengono allocati e tipicamente eseguiti.
Stabilire
un ordine cronologico nell’uso delle viste dello UML è spesso molto
immediato ed intuitivo: si parte dalla Use Case View, si prosegue con la
Design, poi la Component e così via. Nelle situazioni reali tale
processo non è mai diretto: raramente si riesce a completare in
modo esaustivo ciascuna vista attraverso una sola esecuzione del processo;
normalmente si procede con uno sviluppo di tipo itereativo. Durante lo
studio delle viste successive, o a seguito di feed del cliente, spesso
emergono lacune che generano la necessità di apportare delle modifiche
progettuali e quindi di eseguire una nuova iterazione dell’intero processo
o di parte di esso. Di ciò non bisogna preoccuparsi troppo finché
tali lacune restano limitate. Comunque, nell’iter del processo di progettazione
di un sistema, la Physical View non occupa una posizione ben determinata
e precisa: spesso è la base di partenza, o perché la topologia
hardware è già predisposta dal cliente e o perché
si tratta di una configurazione “classica”, mentre altre volte e la logica
conseguenza di quanto prodotto nelle viste precedenti.
Per
dirla tutta, nella pratica, la progettazione della vista implementativa
(component e physical view) non è quasi mai un’attività affidata
completamente al personale tecnico o comunque è sempre fortemente
vincolata da fattori di carattere commerciale; ogni azienda informatica
dispone di propri prodotti, o di canali preferenziali con determinati vendors,
oppure, più semplicemente, dispone di un elevato skill in una precisa
suite di prodotti e quindi, nel proporre una soluzione al cliente, tende
a usare tali prodotti, anche magari quando non risultano essere l’ideale
: può capitare di veder installato un costosissimo DBMS manager
solo per gestire 1 o due tabelle!
Pertanto,
in tale ottica, l’architettura fisica rappresenta, il più delle
volte, il riproponimento di soluzioni ampiamente sperimentate ed affinate
con l’eperienza maturata presso e a spese dei vari clienti.
Comunque,
così come sono presenti una serie di pattern per la design view,
esiste anche tutta una serie di physical pattern utilizzabili per la vista
fisica del sistema.
Diagrammi di “dispiegamento”.
I
deployment diagram, come i component, sono utilizzati per modellare gli
aspetti fisici di un sistema orientato agli oggetti; mentre però
i component diagram focalizzano l’attenzione sulla decomposizione in moduli
del sistema Sw, i deployment mostrano la configurazione, a tempo di esecuzione,
dei nodi hw e dei componenti che risiedono su di essi.
Si
tratta di particolari diagrammi delle classi che focalizzano la loro attenzione
sui nodi del sistema.
Pertanto,
corredati da opportune informazioni, i nodi costituiscono la vista statica
(non potrebbe essere altrimenti) della configurazione del dispiegamento
del sistema software sui dispositivi hw che lo formano.
Nodi
Un
nodo é un elemento fisico e rappresenta una risorsa computazionale,
tipicamente fornita almeno di funzione di memorizzazione e spesso di capacità
elaborative.
Graficamente
viene rappresentato per mezzo di un cubo o parallelepipedo; nulla vieta,
anzi è auspicabile ricorrere ad opportuni stereotipi (nomali PC,
chioschi, smart card, ecc.) al fine di fornuire una più adeguata
e suggestiva rappresentazione dell’elemento che si vuole descrivere. Molto
probabilmente i nodi sono gli elementi dello UML che meglio si prestano
al concetto di stereotipizzazione, e che possiedono il più vasto
repertorio di icone utilizzabili: touch screen, smart card, java rings,
desk top, lap top, fax, telefoni cellulari, telecamere, modem, e così
via.
Come
al solito, ogni nodo deve essere corredato da un nome univoco che ne consenta
il riconoscimento e l’individuazione all’interno dei vari diagrammi. Tale
nome può essere semplice o corredato dal percorso (il famoso path
name), ossia il prefisso l’eventuale package di appartenenza. Le regole
per la composizione del nome sono quelle più volte menzionate negli
articoli articoli precedenti.
Tipicamente
del nodo viene fornito unicamente il nome, ma, così come avviene
per le classi, nulla vieta di aggiungervi tag value e/o sezioni supplementari
al fine di fornire maggiori dettagli (Figura 1). Chiaramente è sempre
opportuno inserire le informazioni ritenute utili, mentre bisogna evitare
tutti quei dati che, come tali, non aumentano il contenuto informativo
e, paradossalmente, rendono il diagramma più pensante e meno leggibile.
Figura
1. Esempi di nodi.
Già
da questi prime informazioni si può evincere una stretta somiglianza
tra i nodi e i componenti: in particolare entrambi possono:
-
partecipare
a relazioni di dipendenza, generalizzazione, associazione;
-
essere
annidati;
-
possedere
delle istanze;
-
partecipare
ad interazioni, e cosi’ via.
Ciononostante,
esistono delle importanti differenziazioni che vale la pena evidenziare:
-
i componenti
partecipano all’esecuzione del sistema; i nodi eseguono i componenti;
-
i componeti
rappresentano il raggruppamento di entita’ scaturite nel processo di analisi
logica del sistema; i nodi rappresentano il dispiegamento fisico dei componenti;
Le classi
scaturite dal processo di disegno del sistema, confluiscono in uno più
componenti allocati, a tempo di esecuzione, su uno o più nodi.
Volendo
è possibile evidenziare il rapporto che esiste tra nodi e componenti
attraverso il ricorso a relazioni di dipendenza, come illustrato in figura
2, ossia: un nodo dipende dai processi che vi sono allocati.
Figura
2. Relazione di dipendenza tra nodi e componenti.
Per
esigenze grafiche, si preferisce evitare rappresentazioni come quelle in
figura in quanto generano grafici eccessivamente estesi e decisamente poco
leggibili; è preferibile evidenziare i componenti allocati su un
nodo semplicemente scrivendone il nome in un’opportuna sezione come illustrato
in figuira 1.
L’insieme
degli oggetti o componenti che sono allocati insieme in un nodo vengono
detti distribution unit (unità di distribuzione).
Dacché
un deployment digram non è altro che una particolare “specializzazione”
del diagramma delle classi focalizzata sul concetto di nodo, esistono tutta
una serie di analogie tra i nodi e classi; si può notare che anche
per i nodi è possibile specificare degli attributi come per esempio
il tipo di microprocessore, la frequenza di funzionamento, la capacità
della memoria ecc., e, cosa del tutto inaspettata (e non sempre utile),
è possibile specificare funzioni come turnOn, turnOff, suspend,
ecc. ecc. Ancora, anche i nodi possono essere raggruppati in package ed
è possibile associarli tra di essi per mezzo delle relazioni di
dipendenza, associazione, e così via. Poiché i nodi sono
molto simili alle classi è possibile utilizzare tutte le features
previste per le relative relazioni: roles, cardinalità, vincoli
ecc.
La
relazione più utilizzata per collegare tra loro i nodi è
sicuramente l’associazione che, in questo contesto, rappresenta una connessione
fisica tra dispositivi hw.
Nella
figura presente viene proposta la deployment view di un comune supermercato
che offre, ai propri clienti,la possibilità di poter effettuare
la spesa via Internet, stando comodamente seduti nella propria poltrona
di casa.
Figura
3. Esempio di deployment diagram di un supermercato che consente di fare
la spese via Internet.
Processori e dispositivi
In
genere, in prima analisi, i nodi vengono suddivisi in due grandi categorie:
-
i processori
(processors), ossia nodi con capaictà elaborative e quindi in grado
di eseguire componenti;
-
i dispositivi
(device), ossia nodi che non dispongono di capacità elaborative
e, in generale, rappresentano elementi che vengono utilizzati come interfacce
del mondo reale.
Nella
stragrande maggioranza dei casi nella proiezione Hw della struttura fisica
di un sistema si incontrano processors (Pc client, server, ecc. ecc.);
mentre più raramente si trovano esempi di device. Nel diagramma
di fiugra 3 sono presenti dicersi device, quali il “BarCode Scanner” e
il “registratore di cassa”.
Figura
4. Esempio di figura 3 realizzato utilizando opportuni stereotipi.
Nel
diagramma in figura 4 è illustarta una versione del diagramma di
figura 3. La variante consiste nell’utilizzo di opportuni stereotipi. Come
si può ben notare il diagramma assume un aspetto decisamente più
intuitivo ed accattivante. Per la precisione, il bar code scanner illustrato
in figura non è esattamente quello utilizzato nelle casse dei supermercati:
si tratta di uno scanner molto sofisticato equipaggiato di un vero PC,
e come tale appartiene alla categoria dei processors. Quello invece installato
normalmente nelle comuni casse svolge unicamente funzione di acquisizione
del codice e quindi è un povero device.
Inoltre,
si è deciso di impostare esplicitamente le cardinalità nelle
relazioni di associazione al fine di fornire una amigliore rappresentazione
della configurazione HW del sistema.
I componenti nei
deployment diagram
Modellando
la proiezione Hw dell’architettura fisica di un sistema, risulta molto
utile, ma non obbligatorio, evidenziare la distribuzione dei componenti
sui nodi che costituiscono il sistema.
La
relativa rappresentazione grafica può essere effettuata o per mezzo
di esplicite relazioni di dipendenza tra i nodi ed i componenti ivi allocati,
o, più semplicemente, inserendo un apposito compartimento nella
rappresentazione grafica del nodo (come peraltro già fatto in precedenza).
Una
variante molto apprezzata è l’implementation diagram ottenuto dalla
fusione del component e del deployment diagram come riportato nella figura
seguente. Il vantaggio, nei sitemi di dimensioni contenute, è di
avere un’immediata visione e comprensione del sistema nel suo globale.
Chiaramente questo risultato è ottenibile quando il numero dei nodi
e dei componenti è contenuto, altrimenti si corre il rischio di
ottenere l’esito opposto: i digrammi tendono ad aumentare vertiginosamente
determinando grossi problemi in fase di visualizzazione e stampa.
Ovviamente
non è sempre necessario e auspicabile tentare di catturare tutti
i dettagli di una vista in un solo diagramma!
Conclusioni
Il
presente articolo è stato dedicato alla illustrazione dei Deployment
diagram: una delle due tipologie di diagrammi previste dallo UML per modellare
la proiezione fisica di un sistema orientato agli oggetti. In particolare
nel deployment diagram viene focalizzata l’attenzione sull’aspetto Hw:
attraverso il suo utilizzo è possibile rappresentare la vista statica
di dispiegamento di un sistema. Tipicamente si tratta di modellare la topologia
del hardware necessario per eseguire il sistema. Gli elementi fondamentali
di questa vista sono i nodi; ossia elementi fisici che esistono nel mondo
reale e rappresentano risorse computazionali, tipicamente fornite almeno
di funzione di memorizzazione (device) e spesso di capacità elaborative
(processori). Come nel caso dei component diagram, i deployment diagram
sono essenzialmente dei class diagrams che focalizzano l’attenzione sui
nodi fisici che costituiscono il sistema.
Chiramente
se il sistema oggetto di studio è un applicativo destinato a funzionare
su un computer senza grosse necessità di connessione con dispositivi
diversi da quelli standard, la realizzazione di un deployment diagram risulta
del tutto inutile. Se invece (caso tipico), il sistema è distribuito,
quindi le varie componenti vengono allocate su su diversi nodi allora il
deployment diagram è decisamente un utile mapping tra le componenti
software e i relativi nodi di allocazione.
Come
al solito nella pratica la progettazione della deployment view è
fortemente vincolata da accordi di carattere commerciali tra la propria
società ed i vari vendors, e comunque si tende a riproporre architetture
ampiamente sperimentate e migliorate con l’esperienza maturata presso i
clienti.
Bibliografia
[1]
The Unified Modeling Language User Guide
Grady
Booch, James Rumbaugh, Ivar Jacobson, Addison Wesley
Questo
libro vanta il primato di essere stato scritto dai progettisti originali
del linguaggio, sebbene sia conosciuto come “Grady’s book”, dal nome del
suo primo autore. La mancanza di una sua copia (magari autografata!) può
generare giudizi di scarsa professionalità per coloro che operano
nel settore della progettazione O.O... Ciò però, costituisce
una condizione necessaria, ma non sufficiente, in quanto bisogna, assolutamente,
aggiungere una copia del [3] e una del [4]. Sono soldi spesi bene! Forse,
il limite del libro, se proprio se ne vuole trovare uno, è quello
di essere poco accessibile ad un pubblico non espertissimo di progettazione
O.O. Un altro piccolo inconveniente è che, probabilmente, taluni
esempi possano sembrare di carattere accademico: poco rispondenti alle
problematiche del mondo reale.
[2]
UML Toolkit
Hans-Erik
Eriksson, Magnus Penker, Wiley
Questo
libro si fa particolarmente apprezzare per via del taglio pratico dello
stesso. Illustra in modo semplice il linguaggio, attraverso numerosi esempi,
limitando le digressioni di carattere teorico. Si suppone infatti, che
coloro che si occupano di progettazione O.O. abbiano una certa familiarità
con i relativi concetti. Chissà perché si ha la sensazione
che non sia sempre così! Naturalmente, studiare libri che illustrano
gli aspetti teorici dell’informatica, è sempre qualcosa più
che auspicabile. È altresì vero però, che coloro che
non hanno tempo da perdere, per la lettura di concetti arcinoti, gradiscono
arrivare rapidamente al nocciolo. Ciò spesso equivale a strappare
alle nottate lavorative ore preziose per il sonno.
[3]
The Unified Modeling Language Reference Manual
Grady
Booch, James Rumbaugh, Ivar Jacobson, Addison Wesley
Il
commento da riportare per questo libro, noto per come “Rumbaugh’s book”,
è sostanzialmente equivalente a quanto riportato per il primo. Esso
però offre un livello di difficoltà decisamente inferiore,
e pertanto dovrebbe essere più accessibile. Come suggerisce il nome,
si tratta di un manuale, per cui ne rispetta la tipica struttura.
[4]
Design Patterns: Elements of Reusable Object-Oriented Software
Erich
Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch, Addison
Wesley.
Si
tratta di un ottimo libro che bisogna assolutamente avere se si vuole lavorare
nell’ambito della progettazione O.O. . I “pattern” riportati, forniscono
un ottimo ausilio al processo di disegno del software. L’utilizzo del libro
contribuisce ad aumentare la produttività, fornisce soluzioni chiare,
efficienti e molto eleganti. La fase di disegno del software, spesso, si
riduce ad individuare e personalizzare i “pattern” che risolvono la problematica
specifica. Si è di fronte ad una nuova frontiera della progettazione
O.O.: il riutilizzo di parti del progetto. L’unica pecca imputabile, è
che i vari diagrammi non sempre rispettano il formalismo UML.
[5]
www.omg.org
Si
tratta del sito ufficiale del Object Managment Group.
[6]
www.mokabyte.it, numero 34 (Ottobre 1999)
UML
e lo sviluppo del software.
[7]
www.mokabyte.it, numero 35 (Novembre 1999)
Use
Case: l’analisi dei requisiti secondo l’U.M.L.
[8]
www.mokabyte.it, numero 36 (Dicembre 1999)
Diagrammi
delle classi e degli oggetti: proiezione statica della Design View.
[9]
www.mokabyte.it, numero 37 (Gennaio 2000)
Proiezione
statica della “Design View” parte seconda: esempi “celebri” di diagrammi
delle classi..
[10]
www.mokabyte.it, numero 38 (Febbraio 2000)
Proiezione
dinamica della “Design View” prima parte diagrammi di interazione.
[11]
www.mokabyte.it, numero 39 (Marzo 2000)
Proiezione
dinamica della “Design View” seconda parte: state chart diagra,.
[12]
www.mokabyte.it, numero 40 (Aprile 2000)
Proiezione
dinamica della “Design View”; terza ed ultima parte: activity diagram
[13]
www.mokabyte.it, numero 41 (Maggio 2000)
Component
View: decomposizione in moduli dell’architettura software del sistema. |
