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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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>>.
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.
Modello componente aziendale
Vengono di seguito illustrate le dipendenze e le necessità dei componenti funzionali e tecnici, per l'esempio Noleggia
un auto.
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.
|