Operazione: Specifica componente (SOA)
Questa attività specifica i dettagli dei componenti di servizio che realizzano un sottosistema di progettazione.
Scopo

Per elaborare su  uno o più Artefatto: Sottosistema di progettazione descritti durante laOperazione: Progettazione del sottosistema (SOA) e per fornire progetti dettagliati di Artefatto: Componente servizio designs.

Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Descrizione principale

I servizi utilizzati in una soluzione basata su SOA sono realizzati tramite Artefatto: Componente servizio che appartengono ad un sistema secondatio allineato della funzione di business specifica. Ogni componente del servizio avrà la responsabilità di assicurare il QoS dei servizi che realizza. Come asset su scala d'impresa, ogni Componente del servizio qualifica il finanziamento, la gestione e la manutenzione associata a questa. La gestione delle infrastrutture deve essere al proprio posto per assicurare la disponibilità, il bilanciamento del carico, la sicurezza, la prestazione, la versione e la salute generale del componente di servizio che sarà responsabile per l'implementazione della funzionalità di un insieme di servizi e l'assicurazione della qualità del servizio. I componenti funzionali e tecnici possono essere utilizzati in molti componenti di servizio.

Passi
Interfacce componente del modello

I componenti, ed in prticlre i Componenti del servizio, non dorebbro fornire operazioni diretamente, dovrebbro invece utilizzare le interfacce per descrivere un insieme di operazioni e quindi fornire/realizzare le interfacce. Questo viene descrito in generale in RUP, consultare Operazione: Progettazione del sottosistema (SOA) and Operazione: Identificazione elemento progettazione.

Esempio

Nell'esempio Affitta una macchina, è stata identificata l'esigenza (tramite l'analisi del sottosistema)di una prenotazione del componente di servizio. Per assicurare un progetto riutilizzabile e flessibile, è inoltre possibile creare un'interfaccia di prenotazione, o utilizzare la specifica del servizio (daOperazione: Specifica del servizio) per descrivere l'interfaccia al componente del servizio. Il Componente realizza (in termini UML) ogni interfaccia fornita e potrebbe anche indicare la propria dipendenza dalle altre interfacce del componente utilizzando il rapporto di utilizzo UML, come mostrato nel diagramma di segito riportato.

Notare che si sono omessi i dettagli delle interfacce stesse per ciarezza.

Attribti componente del modello
In questa fase, verranno definiti i dettagli di ogni componente del servizio, inclusi gli attributi, i servizi, le politiche e le regole. Il modello che dve documentare la specifica del componente del servizio includerà i seguenti attributi:
  1. Properietà o Attributi
  2. Regole
  3. Variazioni
  4. In base agli <altri componenti>
  5. Composizione di componenti funzionali e tecnici
  6. Servizi forniti
  7. Servizi richiesti
Eventi e messaggi del componente del modello
Durante questa attività, vengono identificati gli eventi che il componente deve percepire e a cui deve rispondere quando vengono attivati. I messaggi del componente in entrata e in uscita sono anche specificati. Per i servizi che sono guidate dalle modifiche ai dati, è necessario prendere una vista incentrata sui dati ed i processi di business non all'interno dell'ambito della soluzione basata sul servizio devono essere identificati e associati per la generazione di eventi e la fornitura di dati ai servizi del consumatore nella soluzione orientata al servizio. Ad esempio, un nuovo client potrebbe essere aggiunto da più processi di business in un pacchetto ISV. In tutti i casi, gli stessi dati potrebbero non essere catturati per il client in base al contesto specifico del processo di business. I servizi del consumatore che devono essere consapevoli dei nuovi clienti tramite un servizio del provider devono essere in grado di gestire il richiamo del nuovo servizio client indipendentemente dal processo di business che lo genera.
Struttura interna del componente del modello

Durante questa attività, è importante creare almeno un diagramma di classe che mostra le relazioni r ea i componenti funzionali e tecnici di ogni componente del servizio. Il modellameno UML standard è applicato a questo punto. L'utilizzo dei modelli viene incoraggiato per strutturare il grafico dell'oggetto risultante in un modo che è estendibile e aperto alle modifiche. Se un ampio grado di modifiche viene anticipato, si consiglia di condurre l'Analisi di variabilità a questo punto.

Come descritto nell'attività precedente, quando si progetta una modifica, o si anticipa un impatto significativo sul progetto e la struttura del sistema IT come risultato delle modifiche del business futuro, allora è saggio impiegare le tecniche di Analisi di variabilità. Queste tecniche riflettono l'associazione ed esternalizzano le variazioi utilizzando modelli di progettazione. Le associazioni e le variazioni scoperte precedentemente possono essere utilizzate come punto di inizio ed aumentate tramite l'utilizzo dei modelli di progettazione comuni come la Strategia, lo Stato [i], l'oggetto della regola [ii], l'oggetto del tipo, ecc...

L'analisi eseguita durante la progettazione dettagliata identifica l'associazione e si incentra sulla creazione di variazioni collegabili e conivolge sei principi che aiutano a separare gli aspetti che cambiano da quelli che cambiano meno dei sistemi software ed isolano ed incapsulano le modifiche:

  1. Separazione e cambiamento del modello dagli aspetti che non cambiano del dominio:Identificazione, Separazione, Incapsulamento e Esternalizzazione delle variazioni in aumento.
  2. Creazione delle gerarchie del tipo per ogni punto di variazione.
  3. Assegnazione tipi di regole ad ogni tipo di variazione.
  4. Implementazione dei tre livelli di astrazione utilizzo del metamodello di eredità aggregato.
  5. Avvio dai livelli di riutilizzo più alti degli oggetti e creazione asset ad ogni livello di riutilizzo; creazione piccoli framework attorno ai punti di variazione. In generale, ogni framework dovrebbe avere non più di 7+-2 classi.
  6. Ogni elemento di riutilizzo ha i propri funzionamenti. Esternalizzazione del funzionamento come dati configurabili che possono essere letti nell'applicazione per consentire un collegamento software.

[i] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addision-Wesley 1994.

[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules, Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

Flusso componente del modello

Durante questa attività, viene identificato il flusso interno di controllo all'interno del componente di servizio. Questo può essere rappresentato come un diagramma di sequenza o di attività.

Considerazione ISV: Il flusso interno del componente in un componente del pacchetto ISV potrebbe o non potrebbe essere esposto e/o configurabile in base al pacchetto. Se gli oggetti nel componente ISV sono esposti e configurabili, il loro flusso potrebbe essere adattato e personalizzato per rispettare meglio la soluzione. Tuttavia, bisognerebbe essere consapevoli di tutti i problemi di manutenzione esistenti associati con questa operazione. In molti casi, non sarà possibile, nemmeno necessario, identificare il flusso interno del componente in un pacchetto ISV. In questo caso, il componente ISV dovrebbe essere considerato una "scatola nera", solo con servizi esposti e realizzati documentati.

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