Argomenti
Poiché le porte si trovano ai limiti di una capsula, sono visibili sia dall'esterno della capsula che dall'interno.
Quando vengono visualizzate dall'esterno, tutte le porte presentano la stessa impenetrabile interfaccia oggetto e non
possono essere differenziate ad eccezione della loro identità e ruolo che hanno nel protocollo. Tuttavia, quando
vengono visualizzate all'interno della capsula, si rileva che le porte possono essere di due tipi: porte di
trasmissione e porte finali. La differenza consiste nelle loro connessioni interne - le porte di
trasmissione sono collegate a capsule secondarie mentre le porte finali sono collegate alla macchina a stati della
capsula. In poche parole, le porte di trasmissione servono per esportare in modo selettivo le "interfacce" di capsule
secondarie interne mentre le porte finali sono oggetti delimitanti per la macchina a stati di una capsula. Sia le porte
di trasmissione che quelle finali possono apparire ai limiti della capsula e, come sottolineato, sono indistinguibili
dall'esterno.
Le Porte trasmesse sono porte che fanno semplicemente passare tutti i segnali. Esse forniscono "un'apertura"
nell'involucro esterno di una capsula che può essere utilizzata dalle relative capsule secondarie per comunicare con il
mondo esterno senza essere effettivamente esposte ad esso (e vice versa). Una porta trasmessa è collegata, tramite un
connettore, ad una capsula secondaria ed è normalmente collegata anche dall'esterno a qualche altra capsula "peer".
Esse ricevono segnali provenienti dall'esterno e li trasmettono semplicemente all'altra estremità mantenendo la
direzione del flusso del segnale. Questa operazione viene eseguita senza alcun ritardo o perdita di informazioni a meno
che non vi sia un connettore collegato all'altra estremità. In tal caso, il segnale viene perso.
Le porte di trasmissione consentono la diretta delega (overhead zero) dei segnali destinati ad una capsula per una
capsula secondaria senza richiedere l'intervento di una macchina a stati della capsula. Le porte di trasmissione
possono solo apparire al limite di una capsula e, conseguentemente, hanno sempre una visibilità pubblica.
Per essere utile, una catena di connettori deve infine terminare con una porta finale che comunica con una macchina a
stati. Le porte finali sono oggetti delimitanti per le macchine a stati delle capsule (sebbene, come si osserverà,
alcune di esse servono anche come oggetti delimitanti per le capsule). Le porte finali sono le ultime sorgenti e
raccolgono tutti i segnali inviati dalle capsule. Questi segnali sono generati dalle macchine a stati delle capsule.
Per inviare un segnale, una macchina a stati richiama un'operazione di invio o chiamata su una delle proprie porte
finali. Il segnale viene quindi trasmesso mediante il connettore collegato, possibilmente passando attraverso una o più
porte di trasmissione e connettori concatenati, finché non incontra definitivamente un'altra porta finale, di solito in
una capsula diversa. Poiché la comunicazione basata sui segnali può essere asincrona, una porta finale dispone di una
coda per contenere i messaggi che sono stati ricevuti ma non ancora elaborati dalla macchina a stati (ad esempio, funge
da casella postale). La ricezione del segnale e la distribuzione della macchina a stati che riceve viene eseguita dalla
macchina a stati secondo le semantiche UML standard.
Come per le porte di trasmissione, le porte finali possono apparire ai limiti di una capsula con visibilità pubblica.
Queste porte vengono definite porte finali pubbliche. Tali porte sono oggetti delimitanti sia della macchina a
stati che della capsula di contenimento. Tuttavia, le porte finali possono anche apparire completamente all'interno
della capsula come parte della propria struttura di implementazione interna. Queste porte sono utilizzate dalla
macchina a stati per comunicare con le relative capsule secondarie o con i livelli di supporto
dell'implementazione esterni. Tali porte finali interne sono definite porte finali protette poiché hanno una
visibilità protetta.
Si noti che il tipo di porta viene totalmente determinato dalla relativa connettività interna e dalla sua visibilità
all'esterno della capsula; i diversi termini (porta trasmessa, porta finale pubblica, porta finale privata) fanno parte
semplicemente di una terminologia stenografica. Una porta pubblica che non è collegata internamente può diventare una
porta trasmessa o una porta finale a seconda di come viene successivamente collegata oppure potrebbe restare non
collegata ed essere una raccolta di segnali in entrata.
Da un punto di vista esterno, una porta è una porta; non è possibile o addirittura desiderabile determinare se una
porta è una porta trasmessa o una porta finale. Tuttavia, quando viene mostrata la scomposizione di una capsula, è
possibile osservare all'interno la capsula e distinguere la porta finale/porta trasmessa come indicato graficamente di
seguito.
Annotazione porta - diagramma di comunicazione (vista interna)
In pratica, accade spesso che due o più porte della stessa capsula utilizzano lo stesso protocollo ma sono distinte in
modo semantico. Inoltre, lo stesso segnale può apparire in più di un ruolo di protocollo supportato da diverse porte di
una capsula. In entrambi i casi, potrebbe essere necessario individuare la specifica porta finale che ha ricevuto il
segnale corrente. Ciò consente alle applicazioni di gestire lo stesso segnale in modo diverso a seconda della fonte di
quel segnale oltre allo stato. Viene indicato questo tipo di trigger come trigger basati su porte. I trigger
basati su porte sono modellati in UML utilizzando le condizioni di riferimento che eseguono il controllo per una
particolare porta sorgente.
La specifica per la parte della macchina a stati di una capsula così come la specifica delle sequenze valide del
protocollo vengono effettuate utilizzando le macchine a stati UML standard.
Come si può prevedere, nella maggior parte dei sistemi in tempo reale il tempo è un argomento di primario ordine. In
generale, due modalità di situazioni basate sul tempo necessitano di essere modellate: la capacità di attivare le
operazioni ad una determinata ora del giorno e dopo la scadenza di un certo intervallo rispetto un orario
prestabilito.
La maggior parte dei sistemi in tempo reale richiede una funzione di tempificazione esplicita e direttamente
accessibile (controllabile) - un servizio orario. Questo servizio, che si può accedere attraverso una porta
standard (punto di accesso del servizio), converte il tempo in eventi che possono quindi essere gestiti allo stesso
modo di altri eventi basati sui segnali. Ad esempio, con un tale servizio, una macchina a stati può richiedere di
ricevere una notifica mediante un evento di "timeout" quando viene raggiunto uno specifico orario del giorno oppure
quando è scaduto un determinato intervallo.
Le capsule come concetto possono essere utilizzate in un diverso numero di modi. Per riflettere ciò, è possibile
descrivere una tassonomia e gerarchia di capsule per includere i comuni utilizzi delle capsule.
Tassonomia capsula che mostra la gerarchia di generalizzazione
La tassonomia base della capsula è:
-
Capsula
Una capsula base, priva di porte o di una struttura interna o di una funzionalità non è estremamente
interessante - ha pochissime funzioni. Una capsula di questo tipo può essere utilizzata per definire una
capsula astratta da cui altre capsule sono derivate. Poiché non sono state definite porte, strutture o
funzionalità, questo tipo di capsula è utile soltanto per definire un "segnaposto" che sarà successivamente
perfezionato.
-
Tipo di ruolo
Una capsula "tipo di ruolo" consiste in una definizione che descrive una capsula astratta con una o più porte;
non vi è alcuna struttura o funzionalità definita. Una capsula di questo tipo è utilizzata in casi in cui le
"interfacce" (porte) di una serie di capsule necessitano di una definizione una sola volta, con le specifiche
realizzazioni di quelle interfacce definite dai tipi secondari della capsula 'tipo di ruolo'.
-
Modello ruolo
Una capsula "modello ruolo" consiste in una definizione di capsula con una struttura interna (definita da una
collaborazione di specificazione) di capsule nidificate ed interconnesse virtualmente e potenzialmente una o
più porte. Una capsula di questo tipo è utilizzata per definire una "maschera" per la struttura di un sistema,
i cui 'dettagli' sono delegati alle capsule contenute. Se la capsula modello ruolo dispone di porte, tali porte
definiscono le 'interfacce' per la capsula.
La funzionalità del 'modello ruolo' è imprecisata (non vi è alcuna macchina a stati definita); la funzionalità
deve essere definita dai tipi secondari della capsula.
-
Realizzazione ruolo
Una capsula "realizzazione ruolo" definisce la funzionalità (via una macchina a stati) per la capsula, ma senza
strutture interne o interfacce. Fornisce fondamentalmente una definizione astratta della funzionalità per tutte
le capsule derivative, che devono a loro volta definire la loro struttura interna o interfaccia. La definizione
della funzionalità può essere vista come 'asserzione di progettazione' che deve essere soddisfatta da tutte le
capsule che sono derivate dalla capsula 'realizzazione ruolo'.
Esistono tre utili incroci di questi tipi base, che rappresentano le combinazioni delle definizioni base:
-
Realizzazione ruolo classificato
Questo tipo di capsula definisce sia un'interfaccia che la funzionalità di una serie di capsule, ma non vincola
la struttura interna delle capsule derivative. E' fondamentalmente una capsula 'realizzazione ruolo' che
definisce ulteriormente un'interfaccia.
-
Modello ruolo classificato
Questo tipo di capsula definisce un'interfaccia e la funzionalità di una serie di capsule, ma non vincola la
funzionalità di quelle capsule. Il conseguente beneficio consiste nel definire una maschera per l'interfaccia e
la struttura che può essere quindi successivamente specificata come richiesto dalle capsule derivative.
-
Realizzazione modello ruolo
Questo tipo di capsula definisce una struttura interna per la capsula e la relativa funzionalità astratta ma
non definisce l'interfaccia. Questo tipo di capsula è utile in casi dove un numero di capsule potrebbero
condividere una quantità significativa di struttura interna e funzionalità, ma avere diverse interfacce.
Il tipo di capsula restante, 'realizzazione modello ruolo classificato', che definisce la struttura e l'interfaccia,
più la funzionalità in astratto (per l'interfaccia) e nello specifico (per la struttura interna) è complesso e di
difficile comprensione per non parlare dell'implementazione in modo corretto. Questa capsula viene menzionata per i
casi in cui le verifiche delle unità sulla capsula devono essere definite come parte della capsula stessa, da qui le
due macchine a stati separate. In molti casi, è meglio evitare tale costruzione.
Si noti che la rappresentazione RUP corrente per le capsule è basata 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 consultare Differenze fra UML 1.x e UML 2.0.
|