Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Scienze Matematiche Fisiche e Naturali
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

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.

Macchina Virtuale (Dijkstra, 1965)

Prima formalizzazione di architettura a layers.

Un sistema dovrebbe essere sviluppato da un insieme di macchine virtuali, ognuna costruita in termini di quelle al di sotto di essa.

Esempio di sistema con quattro livelli.

Esempio di sistema con quattro livelli.


Architetture Chiuse e Aperte

Architettura Chiusa
Una macchina virtuale può solo chiamare le operazioni dello strato immediatamente sottostante.

Design goal: alta manutenibilità e portabilità. Ogni layer conosce solo i servizi offerti da quello immediatamente sottostante. Modifiche più in profondità non si riflettono sui layer sovrastanti.
Esempi: La Pila ISO/OSI, oppure l’architettura di Java, che attraverso la JVM scherma all’applicazione i servizi offerti dal sistema operativo.

Architettura Aperta
Una macchina virtuale può utilizzare i servizi delle macchine dei layer sottostanti, a vario livello.
Design goal: efficienza a runtime. In questo modo, ogni livello soprastante può comunicare direttamente con il fornitore di un dato servizio, senza passare attraverso layer intermediari.
Spesso utilizzata in videogames o in quelle applicazioni dove le performances sono fondamentali.

Architettura Chiusa.

Architettura Chiusa.

Architettura Aperta.

Architettura Aperta.


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.

Repository Architecture

Descrizione
I sottosistemi accedono ad una singola struttura dati, chiamata repository.
I sottosistemi sono “relativamente indipendenti” (interagiscono solo attraverso il repository).

Vantaggi
Modo efficiente di condividere grandi moli di dati: write once for all to read.
Un sottosistema non si deve preoccupare di come i dati sono prodotti/usati da ogni altro sottosistema.
Gestione centralizzata di backup, security, access control, recovery da errori…
Il modello di condivisione dati è pubblicato come repository schema → facile aggiungere nuovi sottosistemi.

Svantaggi
I sottosistemi devono concordare su un modello dati di compromesso→ minori performance.
Data evolution: la adozione di un nuovo modello dati è difficile e costosa: deve venir applicato a tutto il repository; tutti i sottosistemi devono essere aggiornati.

Diversi sottosistemi possono avere diversi requisiti su backup, security… non supportati.

Class Diagram dell’architettura Repository.

Class Diagram dell'architettura Repository.

Esempio di istanza di Repository.

Esempio di istanza di Repository.


Client-Server Architecture

Descrizione
E’ un’architettura distribuita dove dati ed elaborazione sono distribuiti su una rete di nodi di due tipi:

  1. i server sono processori che offrono servizi specifici;
  2. i client sono macchine meno prestazionali sulle quali girano le applicazioni-utente, che utilizzano i servizi dei server.

Schema generale
Il Server fornisce servizi ad istanze di altri sottosistemi, detti Client che sono responsabili dell’interazione con l’utente.
I Client chiamano il server che realizza alcuni servizi e restituisce il risultato.
I Client conoscono l’interfaccia del Server (i suoi servizi).
I Server non conoscono le interfacce dei Client.
La risposta è in generale immediata.
Gli utenti interagiscono solo con il Client.

Class Diagram dell’architettura Client-Server.

Class Diagram dell'architettura Client-Server.


Strati funzionali nell’architettura C/S

Praticamente qualunque applicazione software può essere suddivisa logicamente in tre parti:

  1. la presentazione che gestisce l’interfaccia utente (gestione degli eventi grafici, controlli formali sui campi in input, help, …);
  2. la logica applicativa vera e propria;
  3. la gestione dei dati persistenti su database.

Di conseguenza, ogni applicazione può essere vista come composta da (almeno) tre layers.

Data questa osservazione, le architetture a 2 livelli risultano essere una forzatura, chiedendo di suddividere su 2 strati i 3 layer concettuali che compongono un’applicazione.

Schema concettuale della maggior parte delle applicazioni software.

Schema concettuale della maggior parte delle applicazioni software.


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.

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.

Peer-to-Peer Architecture

E’ una generalizzazione dell’Architettura Client/Server.

Ogni sottositema può agire sia come Client o come Server, nel senso che ogni sottosistema può richiedere e fornire servizi.

Il flusso di controllo di ogni sottosistema è indipendente dagli altri, eccetto per la sincronizzazione sulle richieste.

Class Diagram di un’architettura Peer-to-Peer.

Class Diagram di un'architettura Peer-to-Peer.


  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion