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:
-
Properietà o Attributi
-
Regole
-
Variazioni
-
In base agli <altri componenti>
-
Composizione di componenti funzionali e tecnici
-
Servizi forniti
-
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:
-
Separazione e cambiamento del modello dagli aspetti che non cambiano del dominio:Identificazione, Separazione,
Incapsulamento e Esternalizzazione delle variazioni in aumento.
-
Creazione delle gerarchie del tipo per ogni punto di variazione.
-
Assegnazione tipi di regole ad ogni tipo di variazione.
-
Implementazione dei tre livelli di astrazione utilizzo del metamodello di eredità aggregato.
-
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.
-
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.
|
Assegnazione componenti ai livelli
La strutturazione a livelli offre i seguentu vantaggi:
-
I livelli aiutano a portare attributi di qualità di modificabilità e portabilità in un sistema IT. Una modifica ad
un livello inferiore che non ne influenza l'interfaccia non richiede nessuna modifica ad un livello superiore. Ad
esempio, tutti i server di applicazione conformi a J2EE™ che rispettano lo standar J2EE™ potrebbero essere
liberamente sostituiti con la modifica al software di livello di applicazione. Una modifica ad un livello inferiore
che non influenza le funzioni che richiede dagi livelli inferiori non influenzerà nessun livello inferiore. In
generale, le modifiche ad un sistema software strutturato in livelli che non influenza nessuna interfaccia sono
confinate ad un livello singolo.
-
I livelli sono parte di un ruolo blueprint che l'architettura interpreta per costruire il sistema. Conoscendo i
livelli nei quali il software risiede, gli sviluppatori consocono su quali servizi si possono affidare
nell'ambiente di codifica. I livelli potrebbero definire le assegnazioni del lavoro per i team di sviluppo (sebbene
non sempre).
-
I livelli sono parte di un ruolo di comunicazione giocato dall'architettura. In un sistema ampio, il numero di
dipendenze tra i moduli si espande in modo rapido. L'organizzazione del software in livelli con le interfacce è uno
strumento importante per gestire la complessità e comunicare la struttura agli sviluppatori.
-
I livelli aiutano con il ruolo di analisi interpretato dall'architettura. Questi possono essere utilizzati per
l'analisi dell'impatto delle modifiche al progetto.
La strutturazione in livelli può essere streatta e non stretta. Uno schema di strutturazione in livelli stretto
significa che i componenti possono solo utilizzare i componente nello stesso livello o livelli immediatamente al di
sotto di questi. Uno schema di suddivisione in livelli significa che i componenti possono utilizzare i componenti nello
stetto o in qualsiasi livello inferiore. Notare che come regola generale, tuttavia, ai componenti non dovrebbe
essere consentito utilizzare i componenti nei livelli superiori. Se i componenti hanno dipendenze sui componenti nei
livelli superiori, allora diventa difficile sostituire i componenti del livello superiore senza dover modificare i
componenti del livello inferiore. Per ulteriori informazioni, incluse le tecniche per il modellamento dei
livelli, consultare Concetto: Partizionamento della soluzione.
Un punto importante è notare che i livelli software non sono uguali ai livelli. L'assegnazione alle macchine in un
ambiente distribuito, il flusso di dati tra gli elementi e la presenza e l'utilizzo di canali di comunicazione, tutto
tende ad essere espresso in immagini in file che possono essere incomprensibili per i diagrammi di livello. I diagrammi
a file tendono a mostrare freccie a due punte che indicano una certa comunicazione bidirezionale. La comunicazione
bidirezionale (simmetrica) è una cattiva notizia in un diagramma a strati. Inoltre, l'assegnazione di un componente ad
una file si basa sul posizionamento delle regole considerate durante la definizione dell'architettura operativa ed è
definita dalle caratteristiche del livello di servizio richiesto del sistema. La differenza principale tra i diagrammi
di livello e le immagini in fila è che il primo non ha alcuna nozione del posizionamento mentre le altre ovviamente ce
l'hanno.
Regola pratica a livelli
-
Tutti i componenti che forniscono una funzionalità del business indipendente dall'applicazione può andare in un
livello. Le funzioni del business indiepndenti dall'applicazione sono la "gestione del cliente" e la "gestione del
prodotto" che si applica ad un intervallo di diverse applicazioni.
-
Tutti i componenti che forniscono funzioni tecniche, come la gestione dell'errore, l'autenticazione, la
registrazione ed il controllo possono andare in un altro livello. Questi componenti sono indipendenti dal business
e dall'applicazione. In alcuni casi, la prossimità di componenti tecnici e funzionali può richiedere che vengano
posti in un livello comune. Queste sono decisioni strutturali e devono essere documentate come tali.
-
I componenti middleware come l'accodamento dei messaggi ed il software DBMS relazionale possono andare in un altro
livello. Questi vengono denominati "Fabrica".
Esempio
La seguente è una vista a livelli di una SOA che mostra i livelli tipici (e soprattutto consigliati) per gli elementi
diversi presenti in una soluzione.
Ora, in questo schema a livelli, è consigliabile semplicemente relizzare come i componenti risiedono, i componenti
importanti vengono posti per l'esempio Noleggi auto nel livello dei componenti del servizio, come di seguito
illustrato. Notare che si desidera impiegare i livelli stretti nel modello e così viene utilizzata la
composizione UML per contenere i componenti nel livello del componente del servizio ed esporre solo la funzione dei
componenti del servizio utilizzando porte delegate dove la porta fornisce la stessa interfaccia del componente del
servizio stesso.
|
|