Linea guida: Modelli del componente di servizio
Tale linea guida dimostra un insieme di modelli che può essere utilizzato nello sviluppo dei componenti del servizio nella realizzazione dei servizi.
Relazioni
Descrizione principale

Introduzione

Nella decomposizione del componente di servizio nei componenti tecnici e funzionali che lo costituiscono,è stata delegata la funzionalità fornita dal componente del servizio per soddisfare le responsabilità funzionali del sottosistema . I componenti funzionali forniscono la funzionalità di business richiesta, mentre i componenti tecnici forniscono la funzionalità generica come l'autenticazione, la gestione dell'errore, il controllo, la registrazione, ecc... operativi e non funzionali.

Un modello del servizio è una risorsa del periodo di progettazione. Pertanto, non tratta direttamente con l'implementazione dei servizi. Tuttavia, l'implementazione reale di un servizio o di un insieme di servizi è strettamente eseguita dalla realizzazione di un componente del servizio di una specifica di servizio. La specifica di servizio fornisce il contratto di implementazione; la tecnologia o le tecniche utilizzate per implementare il servizio sono irrilevanti fino all'adempimento del contratto. Nel concetto SOA (Service-Oriented Architecture), è stata introdotta la seguente immagine che mostra la relazione identificata tra i servizi ed i componenti e gli oggetti che forniscono l'implementazione di questi servizi.

 Diagramma descritto nel testo associato

In questo modo, è possibile vedere come utilizzare il Modello di progettazione RUP per riportare la progettazione dei livello del componente e dell'oggetto, riportando, con i modelli di implementazione e gli artefatti, i dettagli del livello dell'oggetto e gli artefatti associati di implementazione e distribuzione. Alcuni aspetti importanti della relazione tra il Modello del servizio ed il modello di progettazione del componente sono quelli che l'insieme di specifiche di servizio rappresentano dei contratti che è necessario soddisfare, operazioni identificate su specifiche che è necessario implementare così come sono e utenti di servizi che utilizzano modelli simili a questo per comprendere l'interfaccia ed il funzionamento dei servizi che prevedono di utilizzare. Perciò, esiste una relazione diretta ed in generale biunivoca tra la specifica del servizio ed alcuni artefatti dell'implementazione che agisce come il punto di accesso dell'implementazione iniziale per il servizio.

Ad esempio, si consideri il diagramma seguente di un provider del servizio che mostra i dettagli di elementi del modello utilizzati nella definizione.

Il diagramma viene descritto nel contenuto testuale.

La chiave per utilizzare il componente del servizio è che dovrebbe essere tracciabile direttamente nel modello nel servizio. Il modo più semplice per realizzare ciò è di utilizzare il dato che l'elemento della specifica di servizio è un'interfaccia UML che può essere realizzata dal componente del servizio, assicurando così la conformità alla specifica strutturale. In questo modo si otterrà il risultato seguente:

Il diagramma viene descritto nel contenuto testuale.

E' ora responsabilità dell'implementatore del componente definire un insieme di componenti e classi che forniscono il funzionamento del componente risultante.

Tipi di componenti del servizio

Componenti funzionali

La composizione di questi componenti funzionali in un componente del servizio a granularità complessa non è solo strutturale; questa riguarda anche la definizione del flusso, cioè, la collaborazione dei componenti funzionali per fornire la funzionalità di supporto ai processi di business. Come si è visto precedentemente, la funzionalità di questi componenti relativi al business viene abilitata tramite i servizi (implementati dall'oggetto di livello più semplice o dalla struttura del sistema precedente) definiti.

È importante notare che questa fase include le attività OOAD tradizionali. Si dispone di un ambito incentrate e ben partizionato per indirizzare il progetto dell'oggetto. Nel progetto orientato all'oggetto tradizionale, si tende a creare grafici di oggetti dipendenti più grandi, mentre se l'analisi del sottosistema segue l'identificazione delle aree funzionali all'interno del business, si dispone di un ambito molto chiaramente definito a cui fare attenzione e verso cui indirizzare le energie del progetto. Questo dà come risultato un insieme di modelli di oggetto accoppiati in modo più debole (i diagrammi di classe e i diagrammi di sequenza attivati dai casi d'uso del sistema).

Componenti tecnici

La composizione dei componenti tecnici in componenti di servizio a granularità complessa si verifica nello stesso modo dei componenti funzionali. I componenti tecnici come l'autenticazione, la registrazione e il report possono essere utilizzati nei processi di business.  Questi componenti comuni sono necessari per formare l'infrastruttura per supportare i componenti funzionali.  Una delle variazioni chiave nei processi di business è dovuta alle regole di business come di seguito illustrato nella figura "Modello componente aziendale". Queste variazioni sono tipicamente riportate durante la progettazione orientata alla variazione.

Modelli del componente di servizio

L'aver affermato che il componente del servizio realizza semplicemente la specifica di servizio, non fornisce all'implementatore molta assistenza nel passare da una definizione del servizio a granularità complessa ad un insieme di classi e artefatti di implementazione a granularità semplice richiesti per fornire il funzionamento del servizio. A questo riguardo, è comune fare affidamento su modelli che forniscano la struttura al componente del servizio risultante o come struttura iniziale oppure come modelli specifici per indirizzare requisiti di politica particolari.

Modello scelto, guidato da NFR, architettura [più]

Si noti che gli stereotipi aggiuntivi introdotti qui sono descritti in Risorsa: Componente del servizio.

Modelli base del componente del servizio

Nella definizione della struttura iniziale di un servizio, il modello seguente viene fornito come punto di partenza per la personalizzazione ed il completamento.

Il diagramma viene descritto nel contenuto testuale.

Gli elemento del modello sono:

  • Componente di facciata; la facciata realizza la stessa interfaccia dello stesso componente del servizio e fornisce le capacità di base per la convalida del messaggio prima di passare la richiesta sui componenti per-operazione per l'esecuzione. In questo casi, per chiarezza, i componenti vengono stereotipati come <<facciata>>.
  • Componente per-operazione; fornita la granularità dei servizi, è utile nella maggior parte dei casi disporre di un componente/una classe per l'implementazione di ciascuna operazione fornita dal servizio.

Quanto segue mostra la vista composta della struttura di questo modello. In questo caso, la facciata viene delegata dallo stesso componente del servizio. Pertanto, gli utenti che chiamano le operazioni sul componente del servizio verranno attualmente serviti dal componente di facciata. Si noti che sarebbe possibile utilizzare le porte UML 2.0 oltre che esporre le interfacce e rendere questa delega esplicita utilizzando i connettori.

Il diagramma viene descritto nel contenuto testuale.

Modelli del componente del servizio di un'operazione singola

In alcuni casi in cui i servizi sono identificati nel modello del servizio con più operazioni, è più appropriato implementare le operazioni individualmente some servizi autonomi separando le viste del servizio logico e del servizio fisico. Un tale modello ha degli svantaggi in termini di flessibilità di origine, elevata disponibilità, versione ed evoluzione ma perde la nozione di un'interfaccia in un servizio come un insieme di operazioni relative.

I componenti del servizio di modellamento secondo questo modello hanno un <<Componente del servizio>> singolo che realizza un'interfaccia singola con un'operazione singola, tutti denominati secondo convenzioni comuni e illustrati di seguito.

Il diagramma viene descritto nel contenuto testuale.

In questo caso, come menzionato, non esiste alcuna realizzazione diretta della specifica di servizio originale da ogni elemento nel modello precedente. Pertanto, sembra utile introdurre un elemento nel modello che possa fornire tracciabilità alla specifica di servizio. Nell'esempio sottostante, è stato introdotto un componente, <<sottosistema>> stereotipato che implementa la specifica di servizio ed è proprietario degli elementi precedentemente descritti.

Il diagramma viene descritto nel contenuto testuale.

Questo modello inoltre, non introduce il componente di <<facciata>> poiché gli utenti dei servizi sono responsabili per l'identificazione dei servizi che utilizzano.

Modello mediato dell'operazione

Dove esiste la possibilità che una richiesta degli utenti del servizio venga avviata ad un componente dell'operazione di una selezione per l'esecuzione, è possibile estendere il modello con un mediatore per avviare questi messaggi, come di seguito illustrato. Si noti, per chiarezza, che il componente/la classe è stato stereotipato come <<mediatore>>. Il meccanismo esatto utilizzato per la mediazione non è definito. Un insieme statico di implementazioni potrebbe essere noto prima del tempo, è possibile utilizzare un registro di un certo tipo per mappare all'implementazione particolare in base all'utente, il contenuto del messaggio di richiesta e così via. Non è previsto che questo modello venga utilizzato con il modello di operazione singola precedentemente mostrato.

Il diagramma viene descritto nel contenuto testuale.

Ciò riguarda inoltre la vista composta della struttura del componente del servizio; come precedentemente mostrato, la connessione del mediatore viene illustrata dalla facciata che lo utilizza per dirigere le chiamate ai componenti dell'operazione.

Il diagramma viene descritto nel contenuto testuale.

Se viene utilizzato un registro, esterno allo stesso mediatore, non è necessariamente possibile mostrare le dipendenze statiche di utilizzo dal mediatore ai componenti dell'operazione o i connettori tra le parti nel diagramma composto della struttura. Così, come è possibile modellare una dipendenza dal mediatore ai componenti mediati dell'operazione? Nel diagramma seguente, è stata introdotta un'interfaccia che deve essere implementata da ciascun componente dell'operazione. E' quindi possibile modellare l'utilizzo dal mediatore all'interfaccia, come precedentemente mostrato.

Il diagramma viene descritto nel contenuto testuale.

Inoltre, viene modificata la relazione nel diagramma composto della struttura, inclusa una parte nuova immessa dall'interfaccia e viene indicata la molteplicità tra il mediatore ed i componenti dell'operazione sul connettore, come precedentemente mostrato.

Il diagramma viene descritto nel contenuto testuale.

Componenti di accessi dati

Inoltre, dove le operazioni del servizio condividono i requisiti comuni sui dati, potrebbe essere utile evidenziare i componenti specifici fornendo le capacità di gestione dei dati all'implementazione. Si noti, per chiarezza, che il componente/la classe sono stati stereotipati come <<accesso dati>>.

Il diagramma viene descritto nel contenuto testuale.

Modello del componente aziendale

Il modello del componente aziendale di seguito riportato mostra il componente del servizio che agisce come facciata per i componenti funzionali e tecnici sottostanti. I servizi sono esposti sul bordo del componente del servizio sulla facciata del componente. Le richieste per i servizi sulla facciata vengono inoltrate ad un mediatore che quindi instrada il messaggio ad un componente funzionale o tecnico appropriato.

Diagramma descritto nel testo associato

Modello componente aziendale

Vengono di seguito illustrate le dipendenze e le necessità dei componenti funzionali e tecnici, per l'esempio Noleggia un auto.

Diagramma descritto nel testo associato

Componente del servizio di prenotazione Noleggia un auto utilizzando il modello del componente aziendale

La raccolta di modelli del componente del sottosistema viene raggruppata nel modello del componente funzionale che mostra la dipendenza dei componenti funzionali sui componenti tecnici e le interrelazioni tra i componenti funzionali stessi. I processi secondari a livello della struttura assegnati alla facciata del sottosistema devono essere specificati come servizi che il sottosistema fornisce. Questi processi secondari sono supportati ed implementati tramite un insieme di casi d'uso del sistema a granularità più semplice incapsulato nella struttura del sottosistema. Ci si affida ai componenti funzionali per la realizzazione dei casi d'uso. D'altro lato i componenti funzionali dipendono dai componenti tecnici e dalle utilità per le loro necessità di infrastruttura.