Concetto: Partizionamento della soluzione
In questo concetto, si discutono i principi del partizionamento di un sistema in cluster logici di elementi basati su vari obiettivi. Gli obiettivi potrebbero riflettere confini del business, confini fisici o confini di problemi di argomento più astratto.
Relazioni
Descrizione principale

Introduzione

Si è scritto molto sulla decomposizione delle progettazioni software in componenti o sottosistemi. E' stato scritto molto anche sulla necessità di comprendere la topologia dello sviluppo richiesta da un applicazione inizialmente, nel ciclo di vita, così che sia possibile prendere delle decisioni strutturalmente corrette. Tuttavia, oggigiorno esistono solo pochi meccanismi identificati o utilizzati come supporto nel partizionamento logico di un sistema durante l'analisi strutturale come le decisioni riguardo la topologia logica di una soluzione ed i vincoli imposti da requisiti non funzionali che possano essere facilmente indirizzati a livello di modello prima della generazione dei prodotti di lavoro dettagliati di progettazione e d'implementazione. La pagina seguente traccia un insieme di elementi del modello semplici che consente questo ragionamento. Mentre vengono sviluppate tenendo presente le soluzioni orientate al servizio, queste tecniche sono applicabili a qualsiasi modellamento dell'architettura software.

Partizioni e livelli

Le definizioni seguenti vengono estratte dal glossario RUP (Rational Unified Process) e contrastano con le nozioni di livelli e partizioni. E' abbastanza interessante che il termine livello, comune nella descrizione della architettura logica di una soluzione, non sia contenuto nel glossario RUP.

Livello
(1) Un modo specifico di raggruppare dei pacchetti in un modello allo stesso livello di astrazione.
(2) L'organizzazione di classificatori o di pacchetti allo stesso livello di astrazione. Un livello rappresenta una suddivisione orizzontale attraverso un'architettura, laddove una partizione rappresenta una suddivisione verticale.
Partizione
(1) grafici di attività: Una parte di un grafico di attività che organizza le responsabilità per le azioni. Vedere anche: swimlane .
(2) architettura: Un sottoinsieme di classificatori o di pacchetti allo stesso livello di astrazione. Una partizione rappresenta una suddivisione verticale attraverso un'architettura, laddove un livello rappresenta una suddivisione orizzontale.

Pertanto, una partizione contiene un insieme di elementi che rappresentano alcune parti dell'architettura, ma l'Architetto del software come suddivide un modello? La risposta è ingannevolmente semplice: le partizioni ed i livelli sono costrutti organizzativi, ad un livello strutturale rappresentano solo un'organizzazione logica. Pertanto, quali aspetti dell'organizzazione di una soluzione si desidera rappresentare? Ad esempio, se la vista dei modelli in fase di sviluppo viene trattata in modo sicuro allora è possibile desiderare di rappresentare zone protette [JOHNSTON].

Per ulteriori informazioni consultare i concetti Livellamento e Modelli di distribuzione.

Cosa rappresenta una partizione.

Come precedentemente affermato, una partizione potrebbe essere utilizzata per rappresentare un qualsiasi obiettivo organizzativo particolare su cui l'architetto desideri focalizzare l'attenzione. Seguono delle viste comuni costruite in un modello. Si noti che un aspetto chiave delle partizioni è che non implicano proprietà/contenuto e pertanto un servizio potrebbe essere visualizzato in più partizioni simultaneamente.

Organizzazione della soluzione logica; in questo caso le partizioni rappresentano il clustering logico di elementi in una soluzione fornita. Ad esempio, in un'applicazione business è possibile utilizzare le partizioni per rappresentare la separazione in servizi di interazione dell'utente, in servizi business ed in servizi dell'infrastruttura. Una tale vista corrisponde più all'utilizzo di un livello in RUP per descrivere i livelli di un'applicazione. Tuttavia, poiché i servizi non vengono facilmente suddivisi in livelli allo stesso modo di una soluzione basata sul componente o sull'oggetto, vengono utilizzate le partizioni. Per ulteriori informazioni su queste classificazioni di servizi, consultare il Concetto: Portafoglio servizi.

Il diagramma viene descritto nel contenuto testuale.

Distribuzione fisica di alto livello; in questo caso è possibile utilizzare le partizioni per indicare i servizi remoti rispetto ai locali, almeno quando la distanza fisica impone dei vincoli sull'architettura. Ad esempio, notare che i servizi dell'utente, dell'account e degli ordini sono ospitati nel centro dati principale e il gateway EDI (Electronic Data Interchange) è ospitato in un centro dati secondario è importante quando si scopre, inoltre che la connessione a banda larga tra questi centri è gestita ed è necessario controllare attentamente la comunicazione tra questa partizioni.
Applicazione del business/confine di proprietà; in questo caso, le partizioni vengono utilizzate per rappresentare la proprietà di servizi da parte di un'area del business o di un'area dell'applicazione. Ad esempio, si potrebbe indicare che determinati servizi sono "di proprietà" di risorse umane, alcuni delle vendite ed altri del marketing. Ora, mentre questo non è un obiettivo strutturale, è necessario che la maggior parte dei progetti interagiscano con aspetti che non coinvolgono la tecnologia o l'architettura ma aspetti sociali e politici dell'organizzazione. Le partizioni consentono di vedere il modo in cui l'interazione tra i servizi intersechi tali confini e possa influire sul processo di sviluppo richiedendo il supporto degli azionisti per modifiche organizzative incrociate. In questo caso Risorsa: Sistemi di business identificato durante l'analisi di business forma le categorie per questo modello.
Confini del processo del business; in questo caso si rappresentano aree del processo da parte a parte con le partizioni, cioè raggruppamenti di servizi da parte del processo da essi supportato. Il diagramma sottostante contrasta la vista processi (ombreggiata) con la vista sistemi di business rappresentata come barra verticale. E' importante in molti casi collegare queste due viste dei servizi già distribuiti e di servizi pianificati da un progetto.

Il diagramma viene descritto nel contenuto testuale.

Tale relazione tra l'area del business verticale e il processo del business incrociato è importante per comprendere il modo in cui ciascuna area del business fornisca servizi ai processi che realmente eseguono il business. Riguardo all'esempio, questa vista raggruppa i servizi precedentemente identificati in partizioni nuove come di seguito illustrato.

Il diagramma viene descritto nel contenuto testuale.

Per ulteriori informazioni sulla connessione tra il modellamento del processo e l'identificazione del servizio consultare l'Attività: Analisi asset esistente.

Partizioni nel modello del servizio

Nel Modello del servizio un elemento del modello particolare, la Partizione del servizio, viene utilizzato per modellare le partizioni logiche. La rappresentazione UML 2.0 per le partizioni è basata sull'utilizzo dell'elemento del modello Class (mentre alcuni utenti preferiscono utilizzare i tipi secondari di Classe come il Componente o il Nodo quando questo risponde meglio alle proprie necessità) ed utilizza una struttura composta per definire i servizi in una partizione e la comunicazione tra questi. L'elementoPartizione del servizio è illustrato nelle immagini precedenti e può contenere non solo le istanze dei Provider dei servizi ma anche le istanze di altre partizioni per cui potrebbe essere ulteriormente composto se appropriato. Una partizione del servizio potrebbe specificare inoltre uno o più Gateway del servizio cioè porte UML 2.0 denominate e inserite. Tali porte vengono inserite dalle Specifiche di servizio allo stesso modo di un Servizio e pertanto possono essere percepite come servizi virtuali che specificano l'interfaccia di una partizione.

Così, ad esempio potrebbe essere appropriato notare che all'area del processo di gestione dell'ordine si accede dalla stessa interfaccia del provider del servizio della voce dell'ordine nel diagramma superiore. Si termina promuovendo l'interfaccia dal servizio al di fuori della partizione. Il diagramma seguente rappresenta questa operazione ed illustra il modo in cui il provider del servizio della voce dell'ordine comunica con gli altri servizi nella partizione.

Il diagramma viene descritto nel contenuto testuale.

Una capacità del gateway del servizio è l'abilità di mediare i binding della comunicazione tra client all'esterno ed i servizi all'interno di una partizione. Ciò consente che i servizi trattino con determinati binding del protocollo all'interno di una partizione, ad esempio utilizzino prestazioni più elevate o un protocollo più sicuro all'interno dei confini ed espongano determinate capacità ai client su un protocollo diverso. Per ulteriori informazioni, consultare la linea guida Mediazione del servizio.

Si noti inoltre che poiché le partizioni sono basate sull'utilizzo di strutture composte UML 2.0 non c'è relazione di "contenuto" tra la partizione ed i servizi ed è possibile, come precedentemente illustrato, rappresentare gli stessi servizi in più partizioni o viste. Se questa flessibilità è legata alla capacità dei gateway del servizio, l'architetto ed il progettista del software possono creare dei cluster unendo i servizi in raggruppamenti logici e consentendo ai gateway del servizio di esporre dolo le interfacce pertinenti ai client.

Specifica delle partizioni strette

Una partizione stretta è una partizione in cui i client/servizi esterni alla partizione possono accedere a tutti i servizi all'interno della partizione attraverso gateway del servizio. Ciò implica che la partizione del servizio disponga di una serie propria di interfacce e perciò potrebbe essere vista come un provider del servizio logico di alto livello. Ciò è particolarmente utile per le partizioni che rappresentano confini dell'applicazione business o confini del processo business. Consente inoltre al processo rappresentato di identificare le interfacce che espone al resto del business e quale dei servizi che supportano l'area del processo viene reso pubblicamente disponibile. La partizione di gestione dell'ordine precedente è una partizione stretta, ma il concetto di "stretto" può essere definito solo valutando una partizione e non è una proprietà dell'elemento del modello stesso.

Nell'esempio di seguito riportato la partizione a sinistra potrebbe essere considerato stretta poiché il client (al di fuori della partizione) può solo comunicare con il provider degli ordini (nella partizione) tramite un gateway. D'altra parte la partizione mostrata a destra del diagramma potrebbe non essere considerato come partizione stretta poiché il client comunica direttamente con il provider degli ordini nella partizione.

È importante capire che il modellamento delle partizioni strette, anche l'utilizzo dei gateway, è facoltativa e dovrebbe essere considerata semplicemente come uno strumento che consente il modellamento di comunicazioni esplicite tra le partizioni (qualsiasi cosa rappresentino) e per molti scopi l'ulteriore sovraccarico potrebbe non essere garantito.

Riferimenti

[JOHNSTON] Simon Johnston, Modellazione degli obiettivi di sicurezza in SOA (Service-Oriented Architecture). IBM developerWorks 2004.