Prodotto di lavoro: Capsula
Questo artefatto è un pattern specifico che rappresenta un thread di controllo incapsulato nel sistema.
Relazioni
Input inObbligatorio:
  • Nessuno
Facoltativo: Esterno:
  • Nessuno
Descrizione principale

Le capsule rappresentano uno specifico pattern di struttura de composizione di classe che si è dimostrata utile nella modellazione e progettazione dei sistemi che hanno un altro grado di simultaneità. L'utilizzo di una capsula come notazione sintetizzata per uno specifico e collaudato pattern di progettazione rende la progettazione più facile e meno incline a errori.

Una capsula viene rappresentata come un classe, <<capsula>> stereotipata. Una capsula è un elemento composito, come descritto nella seguente figura.

Diagramma descritto nel testo di accompagnamento.

Composizione della capsula

Come indicato sopra, una capsula può essere dotata di porte e "contenere" classi passive e/o classi secondarie. Può anche avere una macchina a stati che descrive completamente il comportamento della capsula. Una tassonomia specifica delle capsule e dei vari modi in cui possono essere utilizzate, viene descritta in Linea guida: Capsula.

Proprietà
Facoltativo
PianificatoYes
Personalizzazione
Opzioni di rappresentazioneRappresentazione UML: Classe, stereotipata come <<capsula>>. Si noti che questa rappresentazione si basa sull'annotazione UML 1.5. Una buona parte della rappresentazione può essere effettuata in UML 2.0 utilizzando le informazioni contenute nella sezione Concetto: Classe strutturata.  Per ulteriori informazioni, fare riferimento a Differenze tra UML 1.x e UML 2.0 .

Una capsula è un elemento composito, come descritto nella seguente figura.

diagramma di elemento composito

Composizione della capsula

Una capsula può essere dotata di porte e "contenere" classi passive e/o classi secondarie. Può anche avere una macchina a stati che descrive completamente il comportamento della capsula. Una tassonomia specifica delle capsule e dei vari modi in cui possono essere utilizzate, viene descritta in Linea guida: Capsula.

Proprietà

Una capsula incapsula un thread di controllo. Una capsula è un'astrazione di un thread di controllo indipendente nel sistema; è la principale unità di simultaneità nel sistema. L'isolamento aggiuntivo dei thread di controllo può essere raggiunto attraverso l'utilizzo del processo e dei thread del sistema operativo, associando le capsule a specifici processi e thread del sistema operativo. I messaggi alle capsule arrivano attraverso una porta e vengono elaborati in modo sequenziale; se l'istanza di capsula è occupata, i messaggi vengono accodati. Le capsule costringono l'esecuzione della semantica fino al completamento, in modo che alla ricezione di un evento, viene completamente elaborato indipendentemente dal numero o dalla priorità di altri eventi in arrivo.

Una capsula interagisce con l'ambiente circostante attraverso le porte. Una porta è un oggetto di confinebasato su segnale che media l'interazione della capsula con il mondo esterno. Una porta implementa una specifica interfaccia e può dipendere da una specifica interfaccia. Una capsula non può avere attività o parti pubbliche diverse dalle porte, che ne rappresentano l'esclusivo mezzo di interazione con il mondo esterno.

Ogni porta svolge un particolare ruolo in una collaborazione. La collaborazione descrive il modo in cui la capsula interagisce con gli altri oggetti. Per acquisire la semantica complessa di tali interazioni, le porte vengono associate con un protocollo che definisce il flusso valido di informazioni (segnali) tra le porte connesse delle capsule. Il protocollo acquisisce gli obblighi contrattuali che esistono tra le capsule. Forzando le capsule a comunicare unicamente attraverso le porte, è possibile separare completamente le implementazioni interne della capsula dall'ambiente circostante alla capsula. Ciò rende la capsula altamente riutilizzabile.

Una semplice funzionalità di capsula viene realizzata direttamente dalla macchina a stati della capsula. Capsule più complesse associano la macchina a stati con una rete interna di capsule secondarie unite da connettori. Queste capsule secondarie sono capsule a tutti gli effetti e possono a loro volta essere decomposte in capsule secondarie. Questo tipo di decomposizione può essere portato a qualsiasi profondità necessaria, consentendo la modellazione di strutture complesse in modo arbitrario soltanto con questo insieme di base di costrutti di modellazione strutturali. La macchina a stati (facoltativa per le capsule composite), le capsule secondarie e le relative reti di connessioni rappresentano le parti dell'implementazione della capsula e vengono nascoste agli osservatori esterni.

Una capsula può essere un elemento composito. Le capsule possono essere composte da altre capsule e da classi passive. Le capsule e le classi passive vengono unite tramite connettori o collegamenti in una collaborazione; tale collaborazione definisce la struttura della capsula e quindi viene definita una collaborazione di specifiche. Una capsula può avere una macchina a stati che può inviare e ricevere segnali tramite le porte finali della capsula e che ha il controllo su determinati elementi della struttura interna. Perciò, tale macchina a stati può essere considerata come l'implementazione del comportamento riflessivo, cioè, il comportamento che controlla l'attività della stessa capsula.

Porte 

Le porte sono oggetti il cui obiettivo è quello di agire come oggetti di confine per un'istanza di capsula. "Appartengono" all'istanza capsula nel senso che vengono create insieme alla relativa capsula e distrutte quando viene distrutta la capsula. Ogni porta ha una propria identità e stato diversi da quelli dell'istanza capsula a cui appartiene (per lo stesso motivo per cui qualsiasi parte è distinta dal suo contenitore).

Sebbene le porte siano oggetti di confine che agiscono come interfacce, non possono associarsi direttamente alle interfacce UML. Un'interfaccia comportamentale è semplicemente un'azione comportamentale e non ha alcuna struttura di implementazione. Una porta, d'altro canto, comprende sia la struttura che il comportamento. È una parte composita della struttura della capsula, non semplicemente un costrutto sul proprio comportamento. Realizza il pattern architettonico che può essere chiamato "interfaccia manifesta".

In UML, si modella una porta come una classe con lo stereotipo di <<porta>>. Come indicato in precedenza, il tipo di una porta viene definito dal ruolo di protocollo svolto da quella porta. Poiché i ruoli di protocollo sono classi astratte, la classe attuale che corrisponde a questa istanza è quella che implementa il ruolo di protocollo associato alla porta. In UML la relazione tra la porta è il ruolo di protocollo viene trattata come realizza relazioni. L'annotazione per tale relazione è una linea tratteggiata con una punta di freccia triangolare solida sull'estremità della specifica. È una forma di generalizzazione per cui l'elemento di origine, la porta, eredita solo la specifica di comportamento della destinazione, il ruolo di protocollo, ma non la sua struttura.

Una capsula è una composizione di relazioni con le proprie porte. Se la molteplicità della estremità di destinazione di tale relazione è maggiore di uno, significa che esistono più istanze della porta al runtime, ognuna partecipante in una separata istanza del protocollo. Se la molteplicità è un intervallo di valori, significa che il numero di porte può variare al runtime e che le porte possono essere dinamicamente create e distrutte (forse soggette a costrutti).

diagramma di capsula che mostra le porte

Porte, protocolli, e ruoli di protocollo

La figura precedente mostra un esempio di porta singola denominata b appartenente alla classe di capsula CapsuleClassA. Questa porta realizza il ruolo principale del protocollo definito dalla classe di protocollo ProtocolA. Tenere presente che la classe di porte attuale, PortClassX, essendo una classe di implementazione che può variare da implementazione a implementazione, non è normalmente di interesse per il modeler fino alla fase di implementazione. Al contrario, le informazioni che sono di interesse sono il ruolo di protocollo che questa porta implementa. Per questo motivo e anche per motivi di convenienza di annotazione, l'annotazione mostrata in Figura 1 non viene normalmente utilizzata e viene sostituita dalla forma più compatta descritta nella successiva sezione.

Annotazione

Nei diagrammi di classe, le porte di una capsula vengono elencate in una speciale sezione dell'elenco etichettata come illustrato. La sezione dell'elenco di porte appare normalmente dopo le sezioni dell'elenco di attributi e operatori. Questa annotazione riceve i vantaggi della caratteristica UML che consente l'aggiunta di sezioni denominate specifiche.

diagramma di classe per le porte

Annotazione di porta - rappresentazione di diagramma di classe

Tutte le porte esterne (porte di trasmissione e porte pubbliche di estremità) hanno pubblica visibilità mentre le porte interne sono protette dalla visibilità (ad es., la porta b2). Il ruolo (tipo) di protocollo di una porta viene normalmente identificato da un nome di percorso poiché i nomi del ruolo di protocollo sono univoci solo all'interno dello scopo di un determinato protocollo. Ad esempio, la porta b svolge il ruolo principale definito nella classe di protocollo chiamata ProtocolA. Per il caso molto frequente dei protocolli binari, viene utilizzata una semplice convenzione di annotazione: viene utilizzato un simbolo tilde ("~") come suffisso per identificare il ruolo di protocollo accoppiato (ad es., porta b2) mentre il nome di ruolo di base è implicito senza annotazione speciale (ad es., porta b1). Le porte con molteplicità diversa da 1 hanno il fattore di molteplicità incluso tra parentesi quadre.Ad esempio, porta b1[3] ha un fattore di molteplicità pari a 3 mentre una porta progettata da b5[0..2] ha un numero di istanze variabile che non supera 2.

Connettori

Un connettore rappresenta un canale di comunicazione che fornisce le infrastrutture di trasmissione per il supporto di un particolare protocollo basato sui segnali. Una caratteristica chiave dei connettori è quella che possono interconnettere solo le porte che svolgono ruoli complementari nel protocollo associato al connettore. In principio, i ruoli di protocollo non dovevano necessariamente appartenere allo stesso protocollo, ma in quel caso dovevano essere compatibili con il protocollo del connettore.

I connettori sono viste astratte di canali di comunicazione basata sui segnali che interconnettono due o più porte. Le porte vincolate da una connessione devono svolgere mutualmente ruoli complementari ma compatibili in un protocollo. Nei diagrammi di collaborazione, vengono rappresentate da ruoli di associazione che interconnettono le porte appropriate. Se si sottraggono le porte da questa figura, i connettori acquisiscono proprio le relazioni di comunicazione chiave tra le capsule. Tali relazioni hanno rilevanza architettonica poiché identificano quali capsule possono influenzarsi a vicenda attraverso la comunicazione diretta. Le porte vengono incluse per consentire l'incapsulamento delle capsule in conformità all'occultamento dei principi di informazione e la separazione delle considerazioni.

La somiglianza tra i connettori e i protocolli potrebbe suggerire che i due concetti siano equivalenti. Tuttavia, questo non è il caso poiché i protocolli sono specifiche astratte di comportamento desiderato mentre i connettori sono oggetti fisici la cui funzione è solo quella di convogliare i segnali da una porta all'altra . Di solito, gli stessi connettori sono condotti passivi. (In pratica, i connettori fisici possono a volte deviare dal comportamento specificato. Ad esempio, come conseguenza di un errore interno, un connettore può perdere, riordinare o duplicare i messaggi. Questo tipo di errore è comune nei canali di comunicazione distribuiti).

Un connettore viene modellato da un'associazione esistente tra due o più porte delle corrispondenti classi di capsule. (Per le applicazioni avanzate in cui il connettore ha proprietà fisiche, è possibile utilizzare una classe di associazione poiché il connettore è di fatto un oggetto con uno stato e una identità. Come per le porte, la classe attuale che viene utilizzata per realizzare un connettore è una problematica di implementazione). La connessione al protocollo supportato è implicita attraverso le porte connesse. Di conseguenza, non viene richiesta alcuna estensione UML per la rappresentazione dei connettori.

La collaborazione di specifica

La struttura interna completa di una capsula viene rappresentata da una collaborazione di specifica. Tale collaborazione comprende una specifica di tutte le relative porte, capsule secondarie e connettori. Come le porte, le capsule secondarie e i connettori sono strettamente legati alla capsula e non possono esistere indipendentemente da essa. Vengono create quando viene creata la capsula e distrutte quando viene distrutta la loro capsula.

Alcune capsule secondarie nella struttura possono non essere create nello stesso momento di creazione della capsula che le contiene. Invece, possono essere create successivamente, quando e se necessario, dalla macchina a stati della capsula. La macchina a stati può anche distruggere tali capsule in qualsiasi momento. Ciò si attiene alle regole UML sulla composizione.

La struttura di una capsula può contenere ruoli chiamati plug-in. Questi sono, in effetti, dei segnaposti per capsule secondarie che vengono riempiti dinamicamente. Ciò è necessario perché non è sempre noto in anticipo quali specifici oggetti svolgeranno quei ruoli al runtime. Una volta che tali informazioni sono disponibili, l'istanza di capsula appropriata (che appartiene ad altre capsule composite) può essere "inserita" in tale alloggiamento e vengono automaticamente stabilite le associazioni dei connettori con le relative porte ad altre capsule secondarie nella collaborazione. Quando la relazione dinamica non è più necessaria, la capsula viene "rimossa" dall'alloggio del plug-in insieme ai relativi connettori.

La capsule secondarie e i plug-in creati dinamicamente consentono alla modellazione di modificare dinamicamente le strutture assicurando che tutte le relazioni valide di comunicazioni e contenimento tra capsule siano specificate in modo esplicito. Questo è il punto basilare nell'assicurare l'integrità architettonica in un sistema di tempo reale complesso.

Le porte possono anche essere descritte nei diagrammi di collaborazione di specifica. In questi diagrammi, gli oggetti vengono rappresentati dagli appropriati ruoli di classificatore, cioè, le capsule secondarie dai ruoli di capsula e le porte dai ruoli di porta. Per ridurre il disordine visivo, i ruoli di porta vengono generalmente mostrati sotto forma di icona, rappresentata da piccoli quadrati bianchi o neri. Le porte pubbliche vengono rappresentate da icone di ruolo di porta, che si estendono al confine dei corrispondenti ruoli di capsula come mostrato nella precedente figura . Questa notazione stenografica consente a tali porte di essere collegate dall'interno e dall'esterno della capsula senza attraversamenti di linee non necessari e le identifica anche chiaramente come oggetti di confine.

diagramma di porte pubbliche e di ruoli di capsula

Annotazione di porta - diagramma di collaborazione di specifica

Si noti che le etichette vengono adornate a ruoli di porta e non devono essere confuse con i nomi finali di associazione del connettore. Inoltre, poiché le porte vengono identificate in modo univoco dai relativi nomi, è possibile, come utilità grafica, sistemare i ruoli di porta pubblica attorno al perimetro di una casella di capsula secondaria in qualsiasi ordine. Questo sistema può essere utilizzato per minimizzare gli attraversamenti tra linee di connettore.

Per il caso dei protocolli binari, è possibile utilizzare un'icona stereotipa aggiuntiva: la porta che svolge il ruolo accoppiato viene indicata da un quadrato colorato di bianco (in opposizione a quello colorato di nero). In tal caso, il nome del protocollo e il suffisso di tilde sono sufficienti per identificare il ruolo di protocollo con ruolo accoppiato; il nome del ruolo di protocollo è ridondante e deve essere omesso. In modo simile, l'utilizzo del solo nome di protocollo su un quadrato nero indica il ruolo di base del protocollo. Ad esempio, se il ruolo "principale" nel protocollo ProtQ  viene dichiarato come base, allora i diagrammi nella figura successiva e in quella precedente sono equivalenti. Tale convenzione rende facile vedere quando i ruoli di protocollo complementari sono connessi.

diagramma del ruolo di protocollo

Convenzioni simboliche per i protocolli binari

Le porte con un fattore di molteplicità maggiore di uno possono essere anche indicate graficamente utilizzando il simbolo di oggetto multiplo dello standard UML come mostrato nella successiva figura. Ciò non è obbligatorio (la stringa di molteplicità è sufficiente) ma evidenzia la possibilità di istanze multiple della porta.

diagramma UML per oggetti multipli

Porte con fattore di molteplicità maggiore di 1

La macchina a stati

La macchina a stati facoltativa associata a una capsula è solo un'altra parte dell'implementazione della capsula. Tuttavia, possiede determinate proprietà speciali che la distinguono dagli altri componenti di una capsula:

  • Non può essere suddivisa ulteriormente in capsule secondarie. Specifica il comportamento in modo diretto. Le macchine a stati, comunque, possono essere suddivise in gerarchie di macchine a stati più semplici utilizzando le funzionalità standard UML.
  • È possibile al massimo una macchina a stati per capsula (sebbene le capsule secondarie possano avere le loro macchine a stati). Le capsule che non dispongono di macchine a stati sono semplici contenitori per capsule secondarie.
  • Gestisce i segnali in arrivo su qualsiasi porta finale di una capsula e può inviare segnali attraverso tali porte.
  • È la sola entità che può accedere alle parti protette interne nella propria capsula. Ciò significa che agisce come controllerdi tutte le altre classi secondarie. In virtù di ciò, può creare e distruggere le capsule secondarie che vengono identificate come dinamiche e può inserire e rimuovere le capsule secondarie esterne secondo necessità.

Le capsule secondarie create dinamicamente vengono indicate semplicemente da un fattore di molteplicità variabile. Come per gli alloggiamenti di plug-in, possono essere specificate da un tipo di interfaccia semplice. Ciò significa che, in fase di creazione dell'istanza, è possibile istanziare qualsiasi classe di implementazione che supporta tale interfaccia. Ciò provvede alla generalità nelle specifiche strutturali.

Malgrado le relative limitazioni aggiuntive, la macchina a stati associata a una capsula viene modellata dal collegamento standard tra un classificatore UML e una macchina a stati. L'implementazione/decomposizione di una capsula viene modellata da un elemento di collaborazione UML standard che può essere associato a un classificatore. 

Ulteriori informazioni
Elenchi di controllo
Linee guida