Linea guida: Capsula
Questa linea guida descrive il concetto software in tempo reale della capsula.
Relazioni
Descrizione principale

Argomenti

Porte

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.

Porte trasmesse

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.

Porte finali

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.

Visibilità porta

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.

Diagramma descritto nel testo di accompagnamento.

Annotazione porta - diagramma di comunicazione (vista interna)

Trigger basati su porte

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.

Macchine a stati

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.

Servizio orario

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.

Tassonomia capsula

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.

Realizzazione del modello ruolo Modello ruolo classificato Realizzazione ruolo classificato Realizzazione ruolo Capsula Modello ruolo Tipo ruolo Diagramma descritto nel testo di accompagnamento.

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.

Rappresentazione UML 2.0

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.