Sistemi distribuiti: Classificazione dei Pattern e caratteristiche dei pattern architetturali

L’idea alla base dei pattern è quella che sapendo che ci sono dei modelli architetturali, e a seconda di questi, possiamo scegliere quali pattern architetturali utilizzare. Spieghiamoci meglio.

Un pattern software è la descrizione strutturata di una soluzione a un problema software ricorrente. Ad esempio se ho un’architettura a servizi, so che ci sono tante componenti distinti che comunicano, che ci deve essere un’interfaccia, che ci deve essere un catalogo con relativi servizi forniti però l’architettura non mi dice altro e ho bisogno di scegliere pattern architetturali per capire come integrare questi servizi soprattutto perché l’integrazione avviene dinamicamente. I pattern possono essere classificati in:

Pattern architetturali (livello più astratto), che modellano lo schema organizzativo di una struttura nell’ ambito di un’architettura software. Mi fa capire come i vari componenti possono interagire tra loro, come far avvenire la comunicazione con il database, ecc.
Pattern di design: prendo ogni componente, in ogni componente abbiamo i package in cui vi sono le singole classi. Anziché modellarle in maniera empirica posso raggrupparle utilizzando degli schemi predefiniti (design pattern) che rendono più elegante lo schema delle classe e che risolvono una determinata problematica.
Pattern di implementazione (framework), livello di minore astrazione perché siamo nella fase di scrittura del codice.

Pattern architetturali

Ipotizziamo di modellare un sistema software, ipotizzando di utilizzare il processo unificato, abbiamo concluso la fase di ideazione e quindi abbiamo individuato i requisiti funzionali e non, che ci permettono di capire che architettura utilizzare e come organizzare i componenti.

In questo ci possiamo avvalere dei pattern architetturali. I pattern non sono tutti uguali ma possono essere raggruppati a seconda dei problemi che risolvono, ad esempio abbiamo famiglia di pattern che risolvono i problemi di come il sistema si deve interfacciare al database. Oppure abbiamo l’insieme dei pattern che gestiscono la comunicazione dei componenti nel sistema distribuito, ed è l’insieme più ampio ed importante dato che la comunicazione è un aspetto molto importante nei sistemi a oggetti distribuiti. Poi abbiamo tutti i pattern che si occupano dell’interfaccia. O ancora i pattern che si occupano di come modellare i componenti sul livello client, sul livello server, e sull’application server.

Altri pattern importanti sono quelli che gestiscono l’application e l’extend. E poi abbiamo i pattern che gestiscono i problemi di sincronizzazione, ossia quando si hanno delle risorse condivise bisogna sincronizzare l’accesso alla risorsa. Pattern per problemi di concorrenza, secondo cui diversi processi richiedono l’uso di un determinato processo e pertanto bisogna schedulare l’accesso alle risorse nonché la concorrenza, e poi problemi di gestione delle risorse.

I pattern relativi alla decomposizione del sistemi in sottosistemi sono i più numerosi, partendo dai requisiti vedo come posso organizzare il sistema avvalendomi di alcuni pattern come ad esempio il Layer (modello a strati, esempio: sistema operativo), Domain Model, Domain object.

Abbiamo poi una seria di pattern che modellano la comunicazione nei sistemi distribuiti, il più importante è il PATTERN BROKER. Sul modello Broker è strutturato il middleware.

L’altro gruppo importante è quello dei pattern che supportano l’interazione uomo macchina, e i più importanti sono il Model View Controller (MVC) e il Presentation Abstraction Control.

I pattern non sono indipendenti, alcuni sono in alternativa, altri lavorano in sinergia, in più si possono mettere insieme per risolvere problemi più grandi. Se si rappresentano tutti otteniamo un enorme struttura che collega tutti i pattern in maniera diretta.