Operazione: Dipendenze del sottosistema del modello
Questa attività estende il progetto del sottosistema RUP tradizionale con i dettagli specifici di una soluzione SOA, specialmente dove i sottosistemi sono stati identificati dai modelli di analisi del business. Una volta eseguita la transizione dal dominio del business al dominio IT; vengono associate aree funzionali identificate definite dal primo ai sottosistemi, e le loro controparti IT.
Scopo

Per collegare i modelli di business alle controparti IT, si esegue quanto segue:

Relazioni
Descrizione principale

Si inizia con la determinazione e la documentazione delle dipendenze tra i sottosistemi che corrispondono alle aree funzioni che sono state identificate durante l'Attività: Analisi dell'area funzionale. Di solito un'area funzionale corrisponde ad un singolo sottosistema; cioè, l'assunzione semplificata accurata in molti se non nella maggior parte dei casi. Se si decide di associazione un'area funzionale a diversi sottosistemi, questo è fattibile e valido; ma di solito significa che la decomposizione del dominio non è stata sufficiente e che le aree funzionali non sono abbastanza granulari.

Passi
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

 

Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni