1.  in quali programmi o processi le classi e oggetti sono fisicamente allocati?
2. in quale nodo (computer o altro dispositivo hw) i programmi ed i processi sono eseguiti?
3. quali computer o altri dispositivi hardware sono presenti nel sistema, e come sono connessi gli uni agli altri?
4. quali sono le dipendenze tra le varie parti del sistema? La modifica di una sua parte quali ripercussioni genera sulla restante parte del sistema?

Come spesso accade, la capacità di progettare buone architetture deriva dall’esperienza ed in particolare dal riutilizzo e/o miglioramento di soluzioni risultate soddisfacenti in precedenti progetti. Altre volte l’organizzazione è già parzialmente stabilita dallo standard architetturale a cui si intende far riferimento; ad esempio se si decidesse di utilizzare il modello EJB, la struttura SW di massima risulterebbe già stabilita dalle relative direttive, e quella dell’hardware dipenderebbe in gran parte (e paradossalmente) dall’application server prescelto.
Altre volte le varie aziende dispongono di una propria suite di prodotti di integrazione, per cui l’architettura consiste nell’adattare la stessa alle problematiche peculiari dell’ambiente del cliente (il famoso processo di customizzazione).
Pertanto, sebbene la progettazione dell’architettura fisica di un sistema dovrebbe essere la logica conseguenza del disegno dello stesso, e quindi dei risultati emersi nelle viste precedenti, molte volte non è così, ed anzi si procede con una sorta di processo inverso o quantomeno Buttom up… D’altronde un imperativo del modo di pensare O.O. non è forse la riusabilità a tutti i livelli?
Spesso, affrontando la progettazione di un nuovo sistema, si inizia proprio con il tracciare qualche idea di massima dell’architettura fisica del sistema, e quindi si comincia con il focalizzare l’attenzione proprio su quella che spesso viene vista come una delle ultime fasi del processo di progettazione del software.
Vista la difficoltà intrinseca del processo di modellazione di un sistema ogni metodo volto a ridurne la complessità non può che essere il ben venuto.
Ma quali proprietà deve possedere un’architettura per poter essere considerata buona?

• completezza: corretta descrizione di tutte le parti che formano il sistema, sia dal punto di vista funzionale, sia da quello fisico;
• precisione: dettagliata illustrazione grafica del sistema (mappa) che permetta agli sviluppatori di individuare agevolmente la collocazione di ogni singola funzionalità.
• flessibilità: aggiornamenti ed estensioni devono poter essere eseguiti agevolmente su una specifica parte del sistema, senza che le restanti ne siano coinvolte negativamente.
• semplicità: deve essere dotata di interfacce ben definite con ben esplicite dipendenze tra le differenti parti, in modo tale che il disegnatore possa concentrarsi sulle singole parti senza dover necessariamente possedere una completa e dettagliata visione di tutte le particolarità delle restanti parti del sistema.
• riusabilità: supportare il riutilizzo sia incorporando delle parti precedentemente progettate, sia attraverso il disegno di parti sufficientemente generiche da poter essere utilizzate in progetti futuri.

Diagrammi dei componenti
“Il diagramma dei componenti descrive l’organizzazione e le relative interdipendenze di un insieme di componenti; tali diagrammi indirizzano la vista statica implementativa di un sistema.” (UML) 
Il diagramma dei componenti, in ultima analisi, è una specializzazione del diagramma delle classi che focalizza l’attenzione sui componenti del sistema.
 
 
 

Componenti
I componenti software vivono nel mondo “materiale” dei bit e perciò sono importanti blocchi nella modellazione degli aspetti fisici del sistema. Sono utilizzati per modellare gli oggetti fisici che risiedono in un nodo, come programmi eseguibili, librerie, tabelle, files, documenti, ...
Secondo la definizione ufficiale UML, “un componente è un elemento fisico rimpiazzabile di un sistema, il quale si conforma e fornisce l’implementazione di un insieme di interfacce”.
Dall’analisi della precedente definizione emergono chiaramente tre concetti sui quali vale la pena spendere qualche riga; in particolare un componente è:

1. un “oggetto fisico” (nei limiti della fisicità concessa dal mondo virtuale!) e non un’astrazione o un concetto;
2. un elemento rimpiazzabile. Ciò significa che deve poter essere sempre sostituito da un altro che risulti conforme alla relativa interfaccia senza generare ripercussioni negative sulla restante parte del sistema. Ciò permette di realizzare dei sistemi assemblando componenti eseguibili, e di poter aggiungerne nuovi o sostituirne altri senza dover necessariamente ricostruire l’intero sistema. Questo è reso possibile dal concetto di interfaccia;
3. è parte di un sistema. E’ abbastanza inconsueto che un componente venga utilizzato per rimanere isolato, tipicamente esso collabora con altri componenti al fine di realizzare ben precise funzionalità del sistema.

Graficamente un componente viene rappresentato attraverso un rettangolo munito di due linguette poste nel lato sinistro. Ogni componente deve possedere un nome univoco che lo distingua dagli altri. Come al solito, il nome può essere semplice oppure composto dal relativo percorso costituito dal o dai package di appartenenza.
Tipicamente di un componente viene fornito unicamente il nome, ma nulla vieta di aggiungervi i famosi adornamenti, come per esempio i “tag value”, o compartimenti supplementari per specificarne ulteriori dettagli.
 

Come emerge dagli esempi riportati in figura 1, i componenti possono essere di vari tipi; quelli più comuni sono:
· programmi eseguibili;
· librerie (statiche o dinamiche);
· tabelle di database;
· file sorgenti o di dati;
· documenti.

Per alcuni di tali stereotipi sono previste apposite icone come riportato nell’immagine seguente:
 

Tra il concetto di componente e quello di classe esiste una forte analogia; in particolare, entrambi possono:

1. implementare un insieme di interfacce;
2. partecipare a relazioni di dipendenza, associazione e generalizzazione;
3. essere annidati;
4. avere delle istanze;
5. partecipare ad interazioni.

Ciononostante, sono altresì presenti una serie di differenze significative:

1. le classi rappresentano delle astrazioni mentre i componenti rappresentano degli oggetti “fisici”;
2. i componenti rappresentano package fisici o componenti logici e possono essere presenti a diversi livelli di astrazione;
3. le classi possono avere dati e metodi, mentre i componenti possono avere unicamente delle operazioni eseguibili solo attraverso le relative interfacce.

In sistemi molto grandi potrebbe risultare alquanto complicato e decisamente poco chiaro, rappresentare la Component View in termini dei singoli componenti. Spesso si preferisce raggrupparli in package, così come avviene per le classi, al fine di dar luogo a diagrammi più immediati e che non richiedano un tempo eccessivo di realizzazione.
 
 
 

Tipologie dei componenti
L' UML suddivide le tipologie di componenti in tre grandi categorie, che sono:
· spiegamento (deployment). Si tratta dei componenti necessari e sufficienti per costituire il sistema eseguibile, come le librerie di collegamento dinamico (DLL) e gli eseguibili. Comunque, la definizione UML di componente è così ampia da comprendere i classici oggetti presenti in architetture distribuite, così come pagine HTML, tabelle, file di inizializzazione, ecc. ecc.

• prodotto di lavoro (work product). A questa tipologia appartengono oggetti come i moduli di codice sorgente, che, come tali, non fanno parte direttamente del sistema eseguibile ma che servono a generarlo.
• esecuzione (execution). Questi componenti sono creati come conseguenza dell’esecuzione del sistema.

Interfacce
Un’interfaccia è una collezione di operazioni che specificano un servizio generale fornito da una classe o da un componente. Pertanto esse esprimono il comportamento, parziale o totale, di un elemento così come è percepito dall’esterno.
La stragrande maggioranza della architetture moderne (CORBA, EJB, COM+, …) utilizza massicciamente il concetto di interfaccia come collante tra i vari componenti. Chiaramente, ciò rende possibile ai server sw di pilotare le varie “classi di estensione” senza necessariamente averne conoscenza diretta.
L’importanza delle interfacce è che consentendo di stabilire a priori il comportamento degli oggetti, rendono possibile lo sviluppo parallelo del sistema, consentono di trattare un insieme di classi/componenti (quelle/i che la implementano) in modo del tutto astratto, forniscono le basi per produrre protocolli di comunicazione, rendono le varie parti del sistema indipendenti le une dalle altre, rendendo possibile la reingegnerizzazione di determinati componenti senza ripercussione sui restanti.
Tipicamente, in UML, un’interfaccia viene rappresentata tramite un cerchio con vicino il nome; nulla vieta però di rappresentarla come una normale classe; anzi spesso si ricorre a tale notazione al fine di poter specificare chiaramente le operazioni che l’interfaccia espone. In tal caso il collegamento tra la classe che implementa un’interfaccia e l’interfaccia stessa avviene per mezzo di una linea tratteggiata con un triangolo vuoto all’estremità.
Il componente che ne pilota un altro tramite la relativa un’interfaccia (detta export interface), è associato a quest’ultima per mezzo di una relazione di dipendenza. Per il componente pilotante l’interfaccia è detta “import interface” e, ovviamente, ogni componente può importare ed esportare diverse interfacce. 

Utilizzi dei component diagram: componenti eseguibili
Il fine principale dei diagrammi dei componenti è sicuramente modellare le parti fisiche che determinano l’implementazione del sistema. Il risultato di tale processo risulta di fondamentale importanza per la gestione sia della configurazione, sia del rilascio di versioni successive del sistema o di sue parti (versioning). 
Naturalmente quando il sistema risulta composto da un solo file eseguibile, non ha molto senso andarne a realizzare il component diagram; normalmente però, i sistemi che si rispettino risultano costituiti da tutta una serie di componenti: file eseguibili, librerie, tabelle, ecc. che spesso risiedono su macchine diverse: in tali contesti la realizzazione di un diagramma dei componenti è indispensabile.
Nei sistemi inoltre, non è infrequente, anzi è auspicabile, che alcuni componenti risultino condivisi da più applicazioni allocate in diversi nodi del sistema. In questo scenario si comprende bene come i diagrammi dei componenti siano un valido ausilio nella gestione del processo di aggiornamento del sistema o di sue parti: la verifica dell’impatto sul sistema dell’aggiornamento di alcuni componenti è immediata.
Pertanto, si utilizzano i diagrammi dei componenti per visualizzare, specificare, costruire e documentare la configurazione delle versioni di eseguibili, includendo la collocazione dei componenti che costituiscono il sistema e le relazioni tra di essi. 

Figura 4. Esempio di component diagram di un componente eseguibile.

3.2. Codice sorgente.
Sebbene l’obiettivo principale dei component diagramm sia quello di modellare i componenti eseguibili del sistema, esso risulta un valido strumento per documentare le parti di codice sorgente utilizzate per produrre appunto i componenti eseguibili. 
I diagrammi prodotto di tale processo risultano molti utili per visualizzare le dipendenze a tempo di compilazione tra i file sorgenti la cui necessità è particolarmente sentita quando non si utilizzano tools di sviluppo.
Naturalmente, nella maggior parte dei casi, o addirittura nella quasi totalità, si preferisce demandare la gestione delle dipendenze tra i file sorgenti all’ambiente di sviluppo e pertanto è consigliabile, in questo contesto, utilizzare il component diagram per visualizzare e documentare tali relazioni.
Ovviamente quando il sistema assume dimensioni rilevanti risulta improponibile e comunque poco utile realizzare il component diagram in termini delle singole classi, interfacce, ecc. che costituiscono il sistema; in questi casi è auspicabile modellare il sistema considerando come blocchi elementari opportuni raggruppamenti degli elementi base: i package. 

Come si può vedere dalla precedente figura, tracciare l’impatto delle modifiche di un file è un’operazione alquanto immediata e consiste in una semplice ispezione visiva; per esempio l’aggiornamento del file header Signal.h richiederebbe la compilazione dei file Signal.cpp e Interp.cpp.
 
 
 

Basi di dati
Uno schema logico di una base di dati cattura il “vocabolario” di un sistema di dati persistente con semantica e relative relazioni. Dal punto di vista fisico, questi oggetti vengono memorizzati in un database per poter essere acceduti in seguito. I più comuni motori di gestione delle basi di dati possono essere relazionali, ad oggetti o delle forme ibride. Quando ci si trova nell’ultimo caso, non si ha alcun problema in quanto vi è una corrispondenza diretta tra le classi scaturite dal processo di disegno del sistema e la struttura del database, mentre nel caso in cui il DBMS sia di tipo relazionale è necessario realizzare un’interfaccia per il mapping dei due mondi, la cui complessità è tutt’altro che trascurabile, specie in presenza di relazioni di eredità. In tal caso si possono considerare principalmente due tecniche:
1. raggruppare le relazioni di ereditarietà in modo tale che tutte le classi figlie si trovino allo stesso livello. Il limite di questa tecnica è che è necessario memorizzare diverse informazioni ridondanti in molte istanze delle classi figlie;
2. separare le tabelle padri da quelle figlie. Probabilmente si tratta della soluzione più valida ma che comunque richiede di eseguire continue interrogazioni per scorrere gli oggetti che realizzano la relazione.
Ovviamente esistono tutta una serie di librerie commerciali che risolvono l’intero problema ed alcune di esse sono fornite direttamente dai produttori delle basi di dati. Altri produttori, pur fornendo dei RDBMS, hanno provveduto ad aggiungere dei strati superiori di “emulazione” che si occupano di fornire al mondo esterno una visione O. O. delle basi di dati memorizzate.
 

Ovviamente la rappresentazione in figura non è sufficiente per rappresentare la struttura e le relazioni esistenti tra le tabelle; tale lacuna può essere colmata aggiungendo agli stereotipi rappresentanti le tabelle le relative colonne come se fossero comuni proprietà. Infine, alle singole tabelle possono essere associate delle “store-procedure” la cui rappresentazione può essere semplicemente ottenuta evidenziandole come metodi.
Comunque, al fine di eseguire lo studio del sistema nel modo più dettagliato possibile e di fornirne una visione più chiara e semplice, è possibile integrare il modello UML con diagrammi aggiuntivi come per esempio entità relazioni.
 
 
 

Conclusioni
Il presente articolo è stato dedicato alla illustrazione dell’architetture fisica di un sistema e dei meccanismi di modellazione messi a disposizione dall’UML, in particolare si è focalizzata l’attenzione sulla relativa proiezione sw ottenuta per mezzo della component view.
Si è visto che sebbene lo studio dell’architettura fisica del sistema dovrebbe essere una delle ultime fasi del processo di modellazione, molto spesso si comincia il relativo studio proprio da questa fase, tracciando qualche ipotesi di architettura su un pezzo di carta o su una lavagna. Altre volte, quando si ricorre a standard architetturali ben noti o quando l’azienda per la quale si lavora dispone già di un suo prodotto di integrazione, l’architettura fisica del sistema è, in gran parte, stabilita a priori.
Come per tutte le altri fasi della progettazione, anche in questa l’esperienza gioca un ruolo importante; infatti nell’affrontare la modellazione fisica di un nuovo sistema si tenta di riciclare soluzioni dimostratesi valide in precedenti progettazioni.
Si è visto ancora che la component view permette di rappresentare, attraverso gli omonimi diagrammi, la decomposizione in moduli del sistema sw e che tali diagrammi altro non sono che una specializzazione del diagramma delle classi la cui peculiarità è focalizzare l’attenzione sui componenti del sistema.
L’utilizzo principale che se ne fa dei diagrammi dei componenti è sicuramente modellare le parti fisiche che determinano l’implementazione del sistema. Il risultato di tale processo risulta di fondamentale importanza per la gestione sia della configurazione, sia del rilascio di versioni successive del sistema o di sue parti (versioning).
Attraverso l’ispezione visiva di tali diagrammi è possibile tracciare l’impatto sul sistema delle modifiche di un suo componente.
I component diagram sono molto utili anche per visualizzare le dipendenze tra i vari file sorgenti, le tabelle di cui è composto un database ecc.
Per terminare si ricordi che ogni diagramma dei componenti è una rappresentazione grafica della vista implementativa di un sistema e non è assolutamente necessario realizzarne uno solo per visualizzare l’intero sistema; è consigliabile realizzarne una serie, ognuno specializzato per un determinato sottosistema.
Si approfondirà il discorso nel prossimo articolo nel quale si affronterà la proiezione Hw della Physical view.
 
 
 

Puntualizzazioni e scuse
In una serie di articoli (tra cui anche nel precedente [12]), è stato affermato che Rational Rose non prevede i famosi Activity Diagram. Tale affermazione è vera per le versioni di Rational Rose precedenti alla “2000”. (Finalmente è chiaro il problema del millennium bug: il suffisso 2000 da aggiungere a tutte le nuove versioni degli applicativi.. Altro che virus!).
Bisogna tener presente che gli articoli vengono preparati con mesi di anticipo rispetto alla relativa pubblicazione e quindi non è sempre possibile offrire un elevatissimo grado di aggiornamento. Ciò premesso, su segnalazione di un attento lettore, a cui vanno i personali ringraziamenti dell’autore, va puntualizzato che finalmente con la versione 2000 è stata saturata tale lacuna: Rational Rose 2000 prevede la possibilità di realizzare activity diagram… Va comunque detto che ci sono volute ben 4 versioni per far capire tale lacuna: meglio tardi che mai.
Per terminare, l’autore vuole cogliere l’occasione per porgere le personali scuse per non essere stato in grado, con particolare riferimento all’ultimo periodo, di rispondere alle tante e-mail di richiesta supporto: il nuovo lavoro e la conseguente emigrazione londinese ha generato una serie di processi che, in ultima analisi, hanno determinato l’utilizzo di tutti i cicli CPU e l’allocazione di tutte le risorse… Un po’ come dovrebbe avvenire eseguendo il famoso processo “marriage”. 
 
 
 
 
 

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 39 (Marzo 2000)
Proiezione dinamica della “Design View”; terza ed ultima parte: activity diagram