Il comportamento di un sottosistema è identificato principalmente dalle interfacce che realizza. Quando un sottosistema
realizza un interfaccia, si dedica al supporto di ciascuna operazione da essa definita. L'operazione potrà essere
realizzata a sua volta da un'operazione sull'elemento di progettazione (cioè, Classe di
progettazione oppure Sottosistema di progettazione) contenuto dal sottosistema; questa
potrebbe richiedere una collaborazione con altri elementi di progettazione.
Le collaborazioni degli elementi del modello interni al sottosistema devono essere documentate utilizzando i diagrammi
di sequenza che mostrano come si realizza il comportamento del sottosistema. Ciascuna operazione eseguita su un
interfaccia realizzata dal sottosistema deve avere uno o più diagrammi di sequenza di documentazione. Tale diagramma è
in possesso del sottosistema e viene utilizzato per progettarne il comportamento interno.
Se il comportamento del sistema è altamente dipendente dagli stati e rappresenta uno o più thread di controllo, le
macchine a stati sono solitamente più utili per la sua descrizione. Le macchine a stati, in questo contesto, sono
solitamente utilizzate assieme alle classi attive per rappresentare la decomposizione dei thread di controllo del
sistema (o in questo caso del sottosistema), e sono descritte nei diagrammi di stato, consultare Linee guida: Diagramma di stato. Nei sistemi in tempo reale,
il comportamento delle Prodotti di lavoro: Capsula verranno descritte anche tramite l'uso
delle macchine a stati. All'interno del sottosistema vi potranno essere thread di
esecuzione indipendenti, rappresentate da classi attive.
Nei sistemi in tempo reale le Prodotti di
lavoro: Capsula verranno utilizzate per incapsulare questi thread.
Esempio:
Le collaborazioni dei sottosistemi per eseguire dei comportamenti richiesti dal sistema potranno essere espresse
utilizzando diagrammi di sequenza:
Questo diagramma mostra come le interfacce dei sottosistemi vengono utilizzate per eseguire lo scenario. In modo
particolare per il sottosistema di gestione rete, si notano interfacce specifiche (in questo caso ICoordinator) ed
operazioni che il sottosistema dovrà supportare. Si nota inoltre che il sottosistema di NetworkHandling è indipendente
dalle interfacce IBHandler e IAHandler.
Osservando l'interno del sottosistema si vede come è realizzato l'interfaccia ICoordinator:
La classe Coordinator si comporta da "proxy" per l'interfaccia ICoordinator, gestendone le operazioni e coordinandone
il comportamento.
Questo diagramma di sequenza "interno" mostra esattamente quali classi forniscono l'interfaccia, cosa deve accadere
internamente per permettere la funzionalità del sottosistema, e quali classi inviano messaggi dal sottosistema. Il
diagramma chiarisce la progettazione interna ed è essenziale per i sottosistemi con progettazioni interne complesse.
Permette inoltre di comprendere semplicemente il comportamento del sottosistema con la speranza di renderlo
riutilizzabile in altri contesti.
Con la creazione di questi diagrammi di "realizzazione delle interfacce", potrà essere necessaria la creazione di nuove
classi e sottosistemi per eseguire il comportamento richiesto. Il processo è simile a quello definito per le analisi
dei casi d'uso, ma invece di lavorare con questi si lavora con le operazioni delle interfacce. Per ciascuna di esse
identificare le classi (oppure in alcuni casi, dove il comportamento richiesto è complesso, un sottosistema contenuto)
all'interno del sottosistema corrente necessarie all'esecuzione dell'operazione. Creare nuove classi/sottosistemi dove
quelle esistenti non possono fornire il comportamento richiesto (cercare rima il riutilizzo).
La creazione di nuovi elementi di progettazione deve portare alla riconsiderazione del contenuto del sottosistema e del
suo confine. Attenzione a non avere classi uguali in due diversi sottosistemi. L'esistenza di tali classi implica che i
confini del sottosistema possono non essere ben delineati. Rivisitare periodicamente Compito:
Identificazione degli elementi della progettazione per equilibrare nuovamente le responsabilità del sottosistema.
È a volte utile creare due separati modelli interni del sottosistema, una specifica destinata al cliente del
sottosistema ed una realizzazione destinata agli implementatori. La specifica potrà includere classi e collaborazioni
"ideali" per descrivere il comportamento del sottosistema in termini di classi e collaborazioni ideali. La
realizzazione corrisponde più da vicino all'implementazione e potrà evolvere in modo da diventarla. Per ulteriori
informazioni sulla progettazione di una specifica e di una realizzazione del sottosistema, consultare, consultare Linee guida del prodotto di lavoro: Sottosistema di progettazione, Specifica e
realizzazione del sottosistema.
|