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