Operazione: Progettazione sottosistema
Questo compito descrive come documentare gli elementi del sottosistema, il loro comportamento e le loro dipendenze nei confronti del sottosistema.
Discipline: Analisi e progettazione
Scopo
  • Definire i comportamenti specificati nelle interfacce del sottosistema in termini di collaborazioni degli elementi di progettazione contenuti e sottosistemi/interfacce esterni.
  • Documentare la struttura interna del sottosistema.
  • Definire le realizzazioni tra le interfacce del sottosistema e le classi contenute.
  • Determinare le dipendenze nei confronti di altri sottosistemi.
Relazioni
Descrizione principale

 Rappresentazione UML 1.x

Le stesse considerazioni relative alla dipendenza del sottosistema sono applicabili nel caso si utilizzi una notazione UML 1.5:


Diagramma descritto nel testo associato.

Esempio di strutturazione a livelli di un sottosistema utilizzando delle dipendenze dirette

Diagramma descritto nel testo associato.

Esempio di strutturazione a livelli di un sottosistema utilizzando delle dipendenze di interfaccia

Per ulteriori informazioni consultare Differenze fra UML 1.x e UML 2.0.

Passi
Distribuzione del comportamento del sottosistema agli elementi del sottosistema
Scopo Specificare il comportamento interno del sottosistema.
Identificare le nuove classi di progettazione o sottosistemi di progettazione necessari a soddisfare i requisiti di comportamento del sottosistema.  

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:

Diagramma descritto nel testo associato.

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:

Diagramma descritto nel testo associato.

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.

Documentazione degli elementi del sottosistema
Scopo Documentare la struttura interna del sottosistema. 

Documentare la struttura interna del sottosistema, creare uno o più diagrammi di classi che mostrano gli elementi contenuti nel sottosistema e le associazioni tra di essi. Un unico diagramma di classe potrà essere sufficiente, ma crearne più di uno ridurrà la complessità e migliorerà l'affidabilità.

Di seguito è riportato un esempio di diagramma di classe:

Diagramma descritto nel testo associato.

Esempio di un diagramma di classe per un sistema di immissione ordini.

Modellato come componente, il contenuto interno del sottosistema potrà essere rappresentato in alternativa all'interno di un rettangolo del componente nel diagramma del componente. Tale rappresentazione consente di includere i punti di iterazione di questo sottosistema con altre parti del sistema, che si realizzano attraverso le sue interfacce.

Di seguito è riportato un esempio di diagramma del componente, che descrive il sottosistema di ordini, il suo contenuto interno ed anche le interfacce fornite e richieste.

Diagramma descritto nel testo associato.

Diagramma componente di esempio per il sottosistema degli ordini

Siccome un componente è una classe strutturata, lo si potrà incapsulare leggermente forzando il passaggio delle comunicazioni esterne attraverso interfacce dichiarate che obbediscono alle porte, cosa che aggiunge precisione alla sua specifica ed all'interconnessione. La rappresentazione permette di "collegare" le istanze di parti tramite connettori, per l'esecuzione di ruoli specifici in un componente di implementazione (fare riferimento a Concetto: Classe strutturata per ulteriori informazioni).

Esempio di un diagramma di struttura composito per il sottosistema di ordini che utilizza le interfacce e le porte di seguito illustrate.

Diagramma descritto nel testo associato.

Diagramma di struttura composito di esempio per il sottosistema degli ordini



In aggiunta, si potrebbe necessitare di un diagramma di stato per documentare gli stati possibili che potranno essere assunti, consultare Tecniche: Diagramma di stato.

La descrizione delle classi contenute nel sottosistema è gestita nel Compito: Progettazione di classi.

Descrizione delle dipendenze del sottosistema
Scopo Documentare le interfacce da cui dipende il sottosistema. 

Quando un elemento contenuto in un sottosistema utilizza dei comportamenti di un elemento contenuto in un altro sottosistema, si crea una dipendenza tra i due. Per facilitare il riutilizzo e ridurre la manutenzione delle dipendenze, è meglio esprimere questo comportamento in termini di dipendenze su una particolare Interfaccia del sottosistema, non su tutto il sottosistema ne sull'elemento in esso contenuto.

Il motivo ha due ragioni:

  • Mantenere la possibilità di sostituire un elemento del modello (inclusi i sottosistemi) con un altro fin quando offrono lo stesso comportamento. Definire il comportamento richiesto per le interfacce, così da esprimere in termini di interfaccia qualsiasi requisito comportamentale che un elemento del modello dovesse avere nei confronti di un altro.
  • Lasciare la massima libertà al progettista nella progettazione del comportamento interno di un sottosistema fino a quando fornisce il corretto comportamento esterno. Se un elemento del modello in un sottosistema referenzia quello di un altro sottosistema, il progettista non sarà più libero di rimuovere tale elemento del modello o ridistribuirne il comportamento su altri. Di conseguenza il sistema sarà più fragile.

Nella creazione delle dipendenze, accertarsi che non ve ne siano di dirette tra gli elementi del modello contenuti nello stesso ed altri sottosistemi. Accertarsi inoltre che non vi siano dipendenze circolari tra sottosistemi ed interfacce; un sottosistema non potrà realizzare un'interfaccia ed esserne allo stesso tempo dipendente.

Le dipendenze tra sottosistemi e tra di essi ed i pacchetti potranno essere disegnate direttamente come mostrate di seguito. Quando rappresentate in questo modo le dipendenze indicano che un sottosistema (Gestione della fatturazione, ad esempio) dipende direttamente da un altro sottosistema (Gestione della pianificazione dei pagamenti).


Diagramma descritto nel testo associato.

Esempio di strutturazione a livelli di un sottosistema utilizzando delle dipendenze dirette

Quando vi è la possibilità che un sottosistema venga sostituito con un altro (con le stesse interfacce), le dipendenze potranno essere riportate in un Interfaccia realizzata dal sottosistema, piuttosto che dal sottosistema in se. Ciò consente l'utilizzo di qualsiasi altro elemento del modello (sottosistema o classe) che realizza la stessa interfaccia. L'uso delle dipendenze delle interfacce permette la progettazione di framework flessibili utilizzando elementi di progettazione sostituibili.


Diagramma descritto nel testo associato.

Esempio di strutturazione a livelli di un sottosistema utilizzando delle dipendenze di interfaccia

 

Ulteriori informazioni