Sergio Di Martino » 10.Le Architetture Software

Obiettivi della lezione

Comprendere le principali Architetture Software

• Concetto di Architettura
• Layer e Partizioni

Tipi di Architetture

• Repository Architecture
• Client/Server Architecture
• Peer-To-Peer Architecture

Definizione di Architettura SW

“L’architettura software è l’organizzazione di base di un sistema, espressa dai suoi componenti, dalle relazioni tra di loro e con l’ambiente, e i principi che ne guidano il progetto e l’evoluzione.”

[IEEE/ANSI 1471–2000]

Informalmente, un’architettura software è la struttura del sistema, costituita dalle varie parti che lo compongono, con le relative relazioni. L’architettura di un sistema software viene definita nella prima fase di System Design (definizione dei sottosistemi).

Architetture

Definire un’architettura software significa mappare funzionalità su moduli.

Es: Modulo di interfaccia utente, modulo di accesso a db, modulo di gestione della sicurezza, etc…

Anche la definizione delle architetture deve seguire i concetti di Alta Coesione e Basso Accoppiamento: ogni sottosezione dell’architettura dovrà fornire servizi altamente relati tra loro, cercando di limitare il numero di altri moduli con cui è legato.

La definizione dell’architettura viene di solito fatta da due punti di vista diversi, che portano alla soluzione finale:

• identificazione e relazione dei sottosistemi;
• definizione politiche di controllo.

Entrambe le scelte sono cruciali: è difficile modificarle quando lo sviluppo è partito, poiché molte interfacce dei sottosistemi dovrebbero essere cambiate.

Identificazioni di sottoinsiemi – Layers e Partizionamenti

La definizione dell’architettura logica di un sistema grande è di solito ottenuta decomponendolo in sottosistemi, usando layer e partizioni.
Sono due visioni ortogonali tra loro:

1. Un Layer è uno strato che fornisce servizi.

Es: Interfaccia Utente; Accesso al DB.

2. Una Partizione è un’organizzazione di moduli.

Es: Funzionalità Carrello di un sito di commercio.

Layers

Una decomposizione gerarchica di un sistema consiste di un insieme ordinato di layer (strati).

Un layer è un raggruppamento di sottosistemi che forniscono servizi correlati, eventualmente realizzati utilizzando servizi di altri layer.

Un layer può dipendere solo dai layer di livello più basso.

Un layer non ha conoscenza dei layer dei livelli più alti.

Architettura chiusa: ogni layer può accedere solo al layer immediatamente sotto di esso.

Architettura aperta: un layer può anche accedere ai layer di livello più basso.

Partition

Un altro approccio per trattare con la complessità consiste nel suddividere (partitioning) il sistema in sottosistemi paritari (peer) fra loro, ognuno responsabile di differenti classi di servizi.

In generale una decomposizione in sottosistemi è il risultato di un’attività di partitioning e di layering.

Prima si suddivide il sistema in sottosistemi al top-level che sono responsabili di specifiche funzionalità (partitioning).

Poi, ogni sottosistema è organizzato in diversi layer, se il livello di complessità lo richiede, finché non sono semplici abbastanza da poter essere implementate da un singolo sviluppatore (layering).

Architettura Logica: Layers e Partizioni

Principali architetture -Principali Software Architectures

Nell’ingegneria del sofware sono stati definiti vari stili architetturali che possono essere usati come base di architetture software:

• Repository Architecture;
• Client/Server Architecture;
• Peer-To-Peer Architecture.

Architetture client/server a 2 livelli

Vantaggi
E’ la più semplice architettura distribuita.
Svantaggi
Traffico di messaggi intenso (frontend comunica continuamente con server dati).
Logica di business non gestita in una componente separata dell’architettura: suddivisa tra frontend e backend:

• client e server di applicazione dipendono l’uno dall’altro;
• difficile riutilizzare interfaccia in servizio che accede a dati diversi;
• tendenza a cablare la business logic nell’interfaccia utente → cambio di logica significa cambiare anche interfaccia.

Mancato riconoscimento dell’importanza della business logic.

Es: servizio accessibile da più device (telefonino, desktop) → stessa logica, interfaccia diversa.

Architetture 2-Tiers vs. 3-Tiers

Confronto tra un'architettura a due livelli ed una a tre livelli.

Architetture three-tier – I

Introdotte all’inizio degli anni ‘90.

Business logic trattata in modo esplicito:

• livello 1: gestione dei dati (DBMS, file XML, …..);
• livello 2: business logic (processamento dati, …);
• livello 3: interfaccia utente (presentazione dati, servizi).

Ogni livello ha obiettivi e vincoli di design propri
Nessun livello fa assunzioni sulla struttura o implementazione degli altri:

• livello 2 non fa assunzioni su rappresentazione dei dati, né sull’implementazione dell’interfaccia utente;
• livello 3 non fa assunzioni su come opera la business logic..

Architetture three-tier – I (segue)

Non c’è comunicazione diretta tra livello 1 e livello 3:

• interfaccia utente non riceve, né inserisce direttamente dati nel livello di data management;
• tutti i passaggi di informazione nei due sensi vengono filtrati dalla business logic.

I livelli operano senza assumere di essere parte di una specifica applicazione:

• applicazioni viste come collezioni di componenti cooperanti;
• ogni componente può essere contemporaneamente parte di applicazioni diverse (e.g., database, o componente logica di configurazione di oggetti complessi).

Vantaggi di architetture three-tier

Flessibilità e modificabilità di sistemi formati da componenti separate:

• componenti utilizzabili in sistemi diversi;
• modifica di una componente non impatta sul resto del sistema (a meno di cambiamenti nelle API);
• ricerca di bug più focalizzata (separazione ed isolamento delle funzionalità del sistema);
• aggiunta di funzionalità all’applicazione implica estensione delle sole componenti coinvolte (o aggiunta di nuove componenti).

Interconnettività:

• API delle componenti superano il problema degli adattatori del modello client server _ N interfacce diverse possono essere connesse allo stesso servizio etc;
• Facilitato l’accesso a dati comuni da parte di applicazioni diverse (uso dello stesso gestore dei dati da parte di business logics diverse).

Gestione di sistemi distribuiti:

• business logic di applicazioni distribuite (e.g., sistemi informativi con alcuni server replicati e client remoti) aggiornabile senza richiedere aggiornamento dei client.

Svantaggi di architetture three-tier

Dimensioni delle applicazioni ed efficienza:

• pesante uso della comunicazione in rete → latenza del servizio;
• comunicazione tra componenti richiede uso di librerie SW per scambio di informazioni → codice voluminoso

Problemi ad integrare Legacy software.

Molte imprese usano software vecchio (basato su modello monolitico) per gestire i propri dati →

• difficile applicare il modello three-tier per nuove applicazioni;
• introduzione di adapters per interfacciare il legacy SW.

Architetture n-Tier

Evoluzione delle 3-tier, su N livelli.

Permettono configurazioni diverse.

Elementi fondamentali
1. Interfaccia utente (UI):

• gestisce interazione con utente;
• può essere un web browser, WAP minibrowser, interfaccia grafica, …

2. Presentation logic:

• definisce cosa UI presenta e come gestire le richieste utente.

3. Business logic:

• gestisce regole di business dell’applicazione.

4. Infrastructure services:

• forniscono funzionalità supplementari alle componenti dell’applicazione (messaging, supporto alle transazioni, …).

5. Data layer:

• livello dei dati dell’applicazione.