Rappresentazione 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.
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.
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.
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).
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.
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.
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 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.
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.
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.
Porte con fattore di molteplicità maggiore di 1
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.
|