Operazione: Progettazione del sottosistema (SOA)
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
Origine del sottosistema del documento

Durante l'Attività: Analisi dell'area funzionale  viene identificato un insieme di sottosistemi che corrisponde all'input ricevuto da un'associazione del business del componente (consultare Concetto: Modellamento del business del componente). Durante la decomposizione del processo, i nodi di attività a livello della struttura identificati (Concetto: Decomposizione processo di business) possono essere posizionati sui sottosistemi come le operazioni o i servizi che il sottosistema, come facciata, fornisce. La funzionalità di queste operazioni verrà realizzata dai componenti funzionali del componente del servizio. Inoltre, è possibile scegliere di raggruppare queste operazioni su interfacce che sono offerte dal sottosistema. I requisiti non funzionali dell'operazione verranno utilizzati per minare i componenti tecnici ed i servizi richiesti nel sottosistema.

È importante che la relazione tra questi sottosistemi  identificati e la loro origine sia mantenuta in posizione. Nei casi in cui i prodotti di lavoro del livello del business e del modello del servizio siano in UML, le informazioni di dipendenza potrebbero facilmente essere memorizzate nei modelli; altrimenti, tali informazioni dovrebbero essere memorizzate in Esempio: Modello del servizio in Word oppure conservate in un prodotto di lavoro associato.

Considerazioni ISV: I servizi potrebbero essere realizzati tramite sottosistemi esistenti come le applicazioni personalizzate, i pacchetti software e/o i fornitori di software indipendenti. Come spiega la seguente sezione, in alcuni casi, l'identificazione dei nuovi sottosistemi potrebbe riguardare il raggruppamento fisico dei servizi basati sui criteri come l'affinità dei dati, il costo, la prestazione ecc, sebbene l'denitrificazione del sottosistema viene di solito eseguita dall'alto in basso durante l'attività di analisi dell'area funzionale. L'assegnazione dei componenti ai livelli strutturali, per soddisfare i limiti strutturali imposti dai requisiti non funzionali, è spiegata nella Realizzazione del servizio.

Esempio

L'output dall'analisi dell'area funzionale per un agenzia di noleggio di esempio è la spegnete tabella:

Dominio Area funzionale Sottosistema Descrizione
Gestione marketing e clienti Servizio clienti Servizio clienti Fornisce tutte le funzioni automatizzate per l'area funzionale.
Prodotti Gestione delle promozioni Gestione delle promozioni Fornisce tutte le funzioni automatizzate per l'area funzionale.
Logistica noleggio flotta Gestione flotta Gestione flotta Fornisce tutte le funzioni automatizzate per l'area funzionale.
Gestione noleggi Noleggio Noleggio Fornisce tutte le funzioni automatizzate per l'area funzionale.
Gestione noleggi Prenotazioni Prenotazioni Fornisce tutte le funzioni automatizzate per l'area funzionale.
Gestione noleggi Prezzi Prezzi Fornisce tutte le funzioni automatizzate per l'area funzionale.

Il modello UML risultante dei sottosistemi identificati precedentemente saranno i seguenti, notare che le dipendenze del sottosistema sono già fornite nel modello si seguito illustrato.

Per ogni sottosistema i dettagli descritti daRisorsa: Sottosistema di progettazione dovrebbero essere documentati, o potrebbero essere catturati nel modello del servizio in formato documento (consultare Esempio: Modello del servizio in Word), in una forma simile a quella seguente.

Nome Prenotazione
Descrizione Il sottosistema di prenotazione viene utilizzato per creare e gestire le prenotazioni del noleggio auto.
Interfacce
  • Prenota veicolo
  • Modifica prenotazione
  • Ottieni informazioni sulle opzioni
  • Conferma accordo noleggio
  • Trova prenotazione
  • Annulla prenotazione
Funzioni
  • Prenota veicolo
  • Modifica prenotazione
  • Ottieni informazioni sulle opzioni
  • Conferma accordo noleggio
  • Trova prenotazione
  • Annulla prenotazione
Dipendenze Nessuno
Requisiti non funzionali Nessuno



Identificazione e applicazione dei modelli del componente del servizio

In Linea guida: Modelli del componente di servizio si presentano non solo i diversi tipi di componenti che sono comunemente utilizzati per implementare i sottosistemi identificati durante questa attività, ma anche un insieme di modelli che consentono le implementazioni scalabili e flessibili di questi sottosistemi. I modelli, e ovviamente altri parametri esistono - questo non è un insieme completo - e potrebbero essere specificati come parte dell'architettura di un progetto.

La selezione o la personalizzazione di un modello particolare dipende da:

  • I requisiti funzionali e non funzionali della soluzione ed il sottosistema specifico.
  • Le funzioni e le QoS fornite dal middleware sul quale verranno distribuiti i componenti.
  • Il costo e la complessità e il trade-off del vantaggio tra i diversi modelli.
Identificazione del componente del servizio

I sottosistemi di se stessi non sono asset IT e non sono distribuibili nell'infrastruttura IT; questi forniscono un bridge tra le prospettive di business e IT. Ogni sottosistema viene realizzato da uno o più componenti del servizio dove un  Componente del servizio è un asset di scala aziendale (un elemento software gestito con disponibilità garantita, bilanciamento del carico, sicurezza, prestazione e versione). Il componente del servizio è, d'altra parte, realizzato dai componenti funzionali multipli e tecnici in base al diagramma di seguito riportato.

In genere ogni sevizio assegnato ad un sottosistema risulta in un componente del servizio; componenti funzionali e tecnici possono essere condivisi tra i componenti del servizio nello stesso sottosistema.

Identificazione componenti funzionali

I componenti funzionali forniscono un'altra funzione di business ad un componente del servizio; in molti aspetti, la funzione fornita da un componente del servizio dipende interamente dai componenti funzionali e dalla logica di business che implementa su queste.

I componenti funzionali sono spesso da ricercarsi tra i gestori del tipo - componenti che gestiscono un elemento del dominio particolare, ad esempio "Vehicle", "Customer", "Schedule", e così via. Deve essere chiaro che questi elementi del dominio sono più frequentemente grafici di dati a granularità complessa piuttosto che semplici strutture.

Esempio

Considerando l'esempio del noleggio auto, il componente del servizio di prenotazione deve essere in grado di mettere insieme i dettagli relativi al cliente, la posizione in cui desidera noleggiare e i veicoli disponibili per la classespecificata. Inoltre è necessario essere in grado di determinare la posizione del cliente in caso di problemi come ad esempio la non disponibilità dei veicoli. Il seguente diagramma dimostra il modello del componente per la prenotazione.



Identificazione componenti tecnici

I componenti tecnici o di infrastruttura servono per rendere disponibile le funzioni della piattaforma orizzontale; cioè le funzioni che forniscono non sono specifiche del dominio di business ma vanno contro i domini di business. Questi servizi tecnici sono frequentemente forniti dai prodotti middleware inclusi i sistemi operativi e sono utilizzati direttamente dal componente del servizio o dai componenti funzionali sui quali si affidano.

Esempio

Nel completare il modello del componente noleggio (vedere il passo del componente funzionale su riportato) vengono inclusi due componenti tecnici nel modello, uno per la prenotazione per registrare il completamento di una richiesta di prenotazione e uno per indicare che i componenti del veicolo e della posizione si basano sui servizi EJB per conservare i dati di business.

In alternativa è possibile utilizzare un formato tabulare nell'esprimere i componente richiesti ed i loro rapporti ai servizi precedentemente identificati, come mostrato nella figura di seguito riportata.



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 delleProdotti 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

 

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