Diagramma dei com­po­nen­ti: mo­del­la­zio­ne di sistema ef­fi­cien­te con moduli software

L’Unified Modeling Language, in italiano “lin­guag­gio di mo­del­la­zio­ne unificato”, offre uno standard ISO uni­ver­sa­le per lo sviluppo di software e ar­chi­tet­tu­re di sistema complesse. Il lin­guag­gio di mo­del­la­zio­ne, ab­bre­via­to in “UML”, utilizza diversi tipi di diagramma per pro­get­ta­zio­ni e processi di sviluppo nella pro­gram­ma­zio­ne orientata agli oggetti.

Nell’attuale versione (UML 2.5) si fa una dif­fe­ren­za tra 14 tipi di diagramma, grosso modo suddivisi in diagrammi com­por­ta­men­ta­li e strut­tu­ra­li. Al secondo sot­to­grup­po ap­par­ten­go­no i diagrammi dei com­po­nen­ti. Vi spie­ghe­re­mo cos’è un diagramma dei com­po­nen­ti, a cosa serve e come si crea con un esempio concreto.

I diagrammi dei com­po­nen­ti UML rap­pre­sen­ta­no le relazioni tra singoli com­po­nen­ti di sistema in una vista di pro­get­ta­zio­ne statica. Nel farlo possono essere con­si­de­ra­ti aspetti di mo­del­la­zio­ne sia logici che fisici.

Nel contesto UML, i com­po­nen­ti sono parti modulari di un sistema, che sono in­di­pen­den­ti e possono essere so­sti­tui­ti da com­po­nen­ti equi­va­len­ti. Sono chiusi in sé e in­cap­su­la­no tutte le strutture complesse de­si­de­ra­te. Per gli elementi in­cap­su­la­ti sono possibili contatti con altri com­po­nen­ti solo tramite in­ter­fac­cia. I com­po­nen­ti possono mettere a di­spo­si­zio­ne le proprie in­ter­fac­ce, ma anche ricorrere a in­ter­fac­ce di altri com­po­nen­ti, per avere accesso ad esempio alle loro funzioni o servizi. Allo stesso tempo, in un diagramma dei com­po­nen­ti, le in­ter­fac­ce do­cu­men­ta­no le relazioni e in­ter­di­pen­den­ze di un’ar­chi­tet­tu­ra software.

I com­po­nen­ti in­cap­su­la­no di norma delle classi e vengono quindi definiti anche come sot­to­se­zio­ni o spe­cia­liz­za­zio­ni di una classe. Come una classe di­spon­go­no di una struttura composita e possono essere definiti in maniera più det­ta­glia­ta tramite attributi, metodi e ope­ra­zio­ni. I com­po­nen­ti possono essere un insieme di classi e nel tempo, ad esempio, im­ple­men­ta­ti da una o più classi. Anche se i com­po­nen­ti vengono spesso equi­pa­ra­ti alle classi ci sono anche dif­fe­ren­ze: mentre i com­po­nen­ti hanno bisogno so­stan­zial­men­te di in­ter­fac­ce per l’in­te­ra­zio­ne, in una classe si può anche avere accesso diretto a un metodo.

Il concetto di com­po­nen­te è molto ampio in UML. Fanno parte dei com­po­nen­ti diversi elementi del sistema come banche dati, pacchetti (packages), file e librerie (per es. Dynamic Link Libraries/DLLs). Oltre ai com­po­nen­ti di tipo tecnico, come per l’accesso ad una banca dati, ci sono anche com­po­nen­ti spe­cia­liz­za­ti, che possono ad esempio fare ri­fe­ri­men­to a settori o processi di attività. Per com­pren­de­re tali relazioni, che possono anche essere di ampio respiro, UML prevede lo ste­reo­ti­po <<subsystem>>.

Dato che i diagrammi dei com­po­nen­ti modellano un sistema orientato all’at­tua­zio­ne, esistono speciali com­po­nen­ti di im­ple­men­ta­zio­ne che se­le­zio­na­no in maniera mirata singoli aspetti della rea­liz­za­zio­ne. I com­po­nen­ti possono essere uti­liz­za­ti ad esempio per im­ple­men­ta­re altri com­po­nen­ti, come gli Exe­cu­ta­bles (file ese­gui­bi­li con esten­sio­ne*.exe) in Windows.

Tirando le fila, più com­po­nen­ti creano un’ar­chi­tet­tu­ra di sistema ampia. I com­po­nen­ti possono includere anche altri com­po­nen­ti così come disporsi uno sull’altro; un com­po­nen­te, quindi, può anche pre­sup­por­re l’esistenza di altri com­po­nen­ti (relazione di di­pen­den­za). Inoltre i moduli software possono riferirsi a diverse fasi di rea­liz­za­zio­ne: alcuni com­po­nen­ti servono so­prat­tut­to alla pia­ni­fi­ca­zio­ne e pro­get­ta­zio­ne in fase di bozza, mentre altri si svi­lup­pa­no solamente all’ese­cu­zio­ne del software. A tal proposito si parla di com­po­nen­ti di progetto e com­po­nen­ti di runtime.

Un diagramma dei com­po­nen­ti ha lo scopo di fornire una pa­no­ra­mi­ca di sistema che dia una visione d’insieme, che documenti l’or­ga­niz­za­zio­ne dei com­po­nen­ti del sistema e delle relazioni e in­ter­di­pen­den­ze tra gli stessi. I diagrammi dei com­po­nen­ti offrono un punto di vista orientato all’ese­cu­zio­ne, danno quindi allo svi­lup­pa­to­re in­for­ma­zio­ni relative al fun­zio­na­men­to del sistema nel suo insieme e sul rag­giun­gi­men­to dei suoi compiti e obiettivi.

Im­por­tan­ti obiettivi e scopi d’uso del tipo di diagramma sono la mo­del­la­zio­ne di sistemi software basati sui com­po­nen­ti, la specifica di un’ar­chi­tet­tu­ra software e la sud­di­vi­sio­ne di un sistema in sot­to­si­ste­mi (ad es. in­ter­fac­ce grafiche/GUI, area business e per­si­sten­za con banche dati re­la­zio­na­li). Inoltre, alle sottoaree e alle loro in­ter­fac­ce vengono at­tri­bui­ti compiti e funzioni concrete all’interno di un sistema.

I diagrammi dei com­po­nen­ti UML sono un elemento im­por­tan­te in economia per lo scambio con i clienti, dato che una riduzione di com­ples­si­tà rende i progetti più fa­cil­men­te com­pren­si­bi­li e co­mu­ni­ca­bi­li. Inoltre i diagrammi dei com­po­nen­ti sup­por­ta­no e sem­pli­fi­ca­no la gestione dello sviluppo software, in quanto riu­ni­sco­no le classi in com­po­nen­ti gestibili.

L’approccio modulare del tipo di diagramma con­tri­bui­sce inoltre all’eco­no­mi­ci­tà e all’ef­fi­cien­za dei progetti, visto che i sistemi di software possono essere modellati anche come relazioni strut­tu­ra­te di funzioni formate da com­po­nen­ti riu­ti­liz­za­bi­li. I diagrammi dei com­po­nen­ti vi­sua­liz­za­no in modo chiaro quali elementi usare ri­pe­tu­ta­men­te e in quali posizioni di un’ar­chi­tet­tu­ra. I progetti di sistema possono essere orientati in maniera ottimale verso la riu­ti­liz­za­bi­li­tà dei com­po­nen­ti e la loro in­te­ra­zio­ne ef­fi­cien­te.

I sistemi di software basati sui com­po­nen­ti con­sen­to­no di ri­spar­mia­re tempo e costi nella fase di pia­ni­fi­ca­zio­ne e at­tua­zio­ne dei sistemi, visto che si può attingere a quanto già presente. Inoltre moduli software provati e testati di­mi­nui­sco­no i rischi e riducono le fonti di errore, so­prat­tut­to per la rea­liz­za­zio­ne di progetti complessi. Per la creazione di sistemi è possibile ac­qui­sta­re anche moduli di pro­dut­to­ri terzi, perciò si riesce a com­pen­sa­re anche la mancanza di un proprio know-how.

A partire da questi elementi di base è possibile ad esempio creare un semplice diagramma dei com­po­nen­ti tramite il software open source gratuito JGraph.

La pro­fon­di­tà di rap­pre­sen­ta­zio­ne di un diagramma dei com­po­nen­ti può essere ampliata definendo in maniera ancora più det­ta­glia­ta gli elementi che ne fanno parti tramite uno standard UML ancora più preciso. Una classe uti­liz­za­ta può essere definita più da vicino tramite attributi e ope­ra­zio­ni. Il nostro articolo sui diagrammi di classe illustra in maniera chiara le opzioni per una spe­ci­fi­ca­zio­ne det­ta­glia­ta delle classi. Altre opzioni di pro­get­ta­zio­ne e mo­del­la­zio­ne sono offerti dai diagrammi dei casi d’uso e dai diagrammi di stato.