Concetto: Architettura software
L'architettura software rappresenta la struttura o le strutture del sistema, che è composto da componenti software, le proprietà visibili esternamente di quei componenti e le relazioni fra loro.
Relazioni
Descrizione principale

Introduzione

L'architettura software è un concetto facile da capire e che molti sistemisti sentono intuitivamente, specialmente con un po' di esperienza, ma che è difficile da definire precisamente. In particolare, è difficile tracciare una linea netta fra progettazione e architettura (architettura è un aspetto della progettazione che concentra l'attenzione su delle funzioni specifiche).

In Un'introduzione all'architettura software, David Garlan e Mary Shaw suggeriscono che l'architettura software è un livello di progettazione relativo alle problematiche: "Oltre gli algoritmi e le strutture di dati del calcolo; la progettazione e la specifica del sistema globale emergono come un nuovo tipo di problema. Le problematiche strutturali includono una grossolana organizzazione e la struttura di controllo globale; i protocolli per le comunicazioni, la sincronizzazione e l'accesso ai dati; l'assegnazione di funzionalità agli elementi della progettazione; la distribuzione fisica; la composizione degli elementi di progettazione; la scala e le prestazioni; e la selezione fra le alternative di progettazione." [GAR93]

Ma c'è altro nell'architettura oltre la struttura; il gruppo lavorativo IEEE sull'architettura la definisce "il concetto di più alto livello di un sistema nel suo ambiente" [IEP1471]. Comprende anche l'"adattamento" con l'integrità del sistema, con i vincoli economici, con le questioni estetiche e con lo stile. Non è limitato ad una focalizzazione rivolta verso l'interno ma prende in considerazione il sistema come un tutt'uno col suo ambiente di utenti e il suo ambiente di sviluppo - una focalizzazione verso l'esterno.

In RUP, l'architettura di un sistema software (ad un dato momento) è l'organizzazione o la struttura dei componenti significativi del sistema che interagiscono mediante interfacce, con i componenti composti da componenti e interfacce successivamente più piccoli.

Descrizione dell'architettura

Per parlare dell'architettura software e rifletterci sopra è necessario prima definire una rappresentazione strutturale, un modo di descrivere gli aspetti importanti di un'architettura. In RUP, questa descrizione viene catturata nel Documento dell'architettura software.

Viste strutturali

Si è scelto di rappresentare l'architettura software in più viste strutturali. Ogni vista strutturale si occupa di un insieme specifico di questioni, specifiche per gli stakeholder nel processo di sviluppo: gli utenti, i progettisti, i responsabili, i sistemisti, gli addetti alla manutenzione ecc. ecc.

Le viste catturano le principali decisioni di progettazione strutturale mostrando come l'architettura software sia scomposta in componenti e come questi componenti siano collegati da connettori per produrre forme utili [PW92]. Queste scelte di progettazione devono essere legate ai Requisiti, funzionali e supplementari, ed ad altri vincoli. Ma queste scelte a loro volta mettono ulteriori vincoli ai requisiti e alle future decisioni di progettazione ad un livello inferiore.

Un tipico insieme di viste strutturali

L'architettura viene rappresentata da un numero diverse viste strutturali differenti, che nella loro essenza sono estratti che illustrano gli elementi "strutturalmente significativi" dei modelli. In RUP, si inizia con un tipico insieme di viste, denominato "modello di viste 4+1" [KRU95]. E' composto da:

Le viste strutturali sono documentate in un Documento dell'architettura software. È possibile prevedere ulteriori viste per esprimere diverse speciali considerazioni: la vista dell'interfaccia utente, la vista della sicurezza, la vista dei dati ecc. Per i sistemi semplici, è possibile omettere alcune delle viste contenute nel modello di viste 4+1.

Focalizzazione strutturale

Anche se le viste precedenti possono rappresentare l'intera progettazione di un sistema, l'architettura di per sé riguarda solo alcuni aspetti specifici:

  • La struttura del modello - i pattern organizzativi, ad esempio i Livelli.
  • Gli elementi essenziali - casi d'uso critici, classi principali, meccanismi comuni ecc., invece che tutti gli elementi presenti nel modello.
  • Alcuni scenari chiave che mostrano i principali flussi di controllo in tutto il sistema.
  • I servizi, per catturare la modularità, le funzioni facoltative, gli aspetti della linea del prodotto.

In sintesi, le viste strutturali sono astrazioni, o semplificazioni dell'intera progettazione, in cui le caratteristiche importanti vengono rese più visibili mettendo da parte i dettagli. Queste caratteristiche sono importanti quando si parla di:

  • Evoluzione del sistema (passare al ciclo di sviluppo successivo).
  • Riutilizzo dell'architettura, o di parte di essa, nel contesto di una linea di prodotti.
  • Valutazione delle qualità supplementari, ad esempio le prestazioni, la disponibilità, la portabilità e la sicurezza.
  • Assegnazione del lavoro di sviluppo ai team o ai subappaltatori.
  • Decisioni sull'inclusione di componenti già pronti.
  • Inserimento in un sistema più vasto.

Pattern strutturali

I Pattern strutturali sono dei moduli già pronti che risolvono problemi strutturali ricorrenti. Un framework strutturale o un'infrastruttura strutturale (middleware) è un insieme di componenti sui quali è possibile creare un determinato tipo di architettura. Molte delle principali difficoltà strutturali devono essere risolte nel framework o nell'infrastruttura, in genere diretta ad un dominio specifico: comando e controllo, MIS, sistema di controllo, ecc.

Esempi di pattern strutturali

[BUS96] raggruppa i pattern strutturali in base alle caratteristiche dei sistemi in cui sono più applicabili, con una categoria che si occupa delle problematiche di strutturazione di carattere più generale. La tabella mostra le categorie presentate in [BUS96] ed i pattern contenuti.

Categoria Pattern
Struttura Livelli
Pipe e filtri
Lavagna
Sistemi distribuiti Broker
Sistemi interattivi Modello-Vista-Controller
Presentazione-Astrazione-Controllo
Sistemi adattabili Riflessione
Microkernel

Due fra questi vengono presentati in maniera più dettagliata di seguito, per chiarire questi concetti; per informazioni complete consultare [BUS96]. I pattern sono presentati nella forma ampiamente diffusa riportata di seguito:

  • Nome pattern
  • Contesto
  • Problema
    • Forze che descrivono gli aspetti diversi del problema che devono essere considerati
  • Soluzione
    • Fondamento logico
    • Contesto risultante
    • Esempi
Nome pattern

Livelli

Contesto

Un grosso sistema che richiede la scomposizione.

Problema

Un sistema che deve gestire le problematiche su livelli diversi di astrazione.   Ad esempio: problematiche di controllo hardware, problematiche di servizi comuni e problematiche specifiche per dominio. Non è auspicabile scrivere componenti verticali che gestiscono le problematiche a tutti i livelli. La stessa problematica dovrebbe essere gestita (probabilmente in maniera non congruente) più volte in componenti diversi.

Forze

  • Le parti del sistema devono essere sostituibili.
  • Le modifiche nei componenti non devono diffondersi.
  • Le responsabilità simili devono essere raggruppate.
  • Dimensione dei componenti (i componenti complessi potrebbero dover essere scomposti).
Soluzione

Strutturare i sistemi in gruppi di componenti che formano dei livelli gli uni sugli altri. I livelli superiori devono poter utilizzare solo i livelli inferiori (mai quelli superiori). Cercare di non utilizzare servizi diversi da quelli del livello direttamente inferiore (non saltare livello a meno che i livelli intermedi non aggiungano semplicemente dei componenti di passaggio (pass-through).

Esempi:

1. Livelli generici

Il diagramma è descritto nel contenuto.

Un'architettura rigida a livelli asserisce che gli elementi di progettazione (classi, pacchetti, sottosistemi) utilizzano solo i servizi dei livelli immediatamente inferiori.  I servizi possono includere la gestione eventi, la gestione errori, accesso al database, ecc. Contiene meccanismi più palpabili, al contrario delle chiamate non elaborate del livello del sistema operativo, documentate nel livello più basso.

2. Livelli del sistema di business

Il diagramma è descritto nel contenuto.

Il precedente diagramma mostra un altro esempio di strutturazione a livelli, in cui sono presenti livelli verticali specifici per l'applicazione e livelli orizzontali dell'infrastruttura. L'obiettivo è di avere "stovepipe" di business molto brevi e di potenziare l'accomunanza nelle applicazioni.  In caso contrario, è possibile avere a disposizione più persone che risolvono lo stesso problema, potenzialmente in modo diverso.

Per ulteriori informazioni, consultare Linee guida: Livelli.

Nome pattern

Lavagna

Contesto

Un dominio in cui non è noto o non adatto alcun approccio chiuso (algoritmico) per la risoluzione del problema. Gli esempi sono dei sistemi AI, riconoscimento vocale e sistemi di sorveglianza.

Problema

Più agenti atti alla risoluzione del problema (agenti di conoscenze) devono collaborare per risolvere il problema che non può essere risolto da nessuno dei singoli agenti. I risultati del lavoro dei singoli agenti deve essere accessibile a tutti gli alti agenti in modo da poter valutare se sono in grado di contribuire a trovare una soluzione e poter pubblicare il risultato dei loro lavoro.

Forze

  • La sequenza in cui gli agenti di conoscenze possono contribuire a risolvere il problema non è determinante e può dipendere dalle strategie di risoluzione del problema.

  • L'input dei diversi agenti (risultati o soluzioni parziali) può avere rappresentazione diverse.

  • Gli agent non sono direttamente a conoscenza dell'esistenza degli altri ma possono valutare le reciproche contribuzioni pubblicate.

Soluzione

Diversi agenti di conoscenze (Knowledge Agent) hanno accesso ad un archivio di dati condivisi denominato Lavagna. La lavagna fornisce un'interfaccia per ispezionarne ed aggiornarne il contenuto. Il modulo/oggetto Controllo attiva gli agenti che seguono una strategia. All'attivazione, un agente ispeziona la lavagna per vedere se può contribuire alla soluzione del problema. Se l'agente stabilisce che può contribuire, l'oggetto di controllo consente agli agenti di collocare la sua soluzione parziale (o finale) sulla lavagna.

Esempio:

Il diagramma è descritto nel contenuto.

Questo mostra la vista strutturale o statica modellata con UML. Questa sarebbe parte di una collaborazione con parametri, che viene quindi collegata a parametri effettivi per istanziare il pattern.

Stile strutturale

Un'architettura software, o semplicemente una vista strutturale, può avere un attributo denominato stile strutturale, che riduce la serie di possibili forme fra le quali scegliere, ed impone un certo grado di uniformità all'architettura. Lo stile può essere definito da un insieme di pattern, o dalla scelta di componenti specifici o connettori, come blocchi di costruzione di base. Per un dato sistema, parte dello stile può essere acquisito come parte della descrizione strutturale contenuta in una guida allo stile dell'architettura (fornita nel prodotto di lavoro  Linee guida specifiche per il progetto in RUP. Lo stile gioca un ruolo importante nella comprensibilità e integrità dell'architettura.

Piani strutturali

La descrizione grafica di una vista strutturata viene denominata piano strutturale. Per le varie viste descritte in precedenza, i piani sono composti dai seguenti diagrammi provenienti da UML (Unified Modeling Language) [UML01]:

  • Vista logica. Diagrammi di classi, macchine a stati e diagrammi di oggetti
  • Vista dei processi. Diagrammi di classi e diagrammi di oggetti (che comprendono processi e thread)
  • Vista di implementazione. Diagrammi di componenti
  • Vista di distribuzione. Diagrammi di distribuzione
  • Vista di casi d'uso. Diagrammi di casi d'uso che descrivono i casi d'uso, gli attori e le classi ordinarie di progettazione; diagrammi di sequenza che descrivono gli oggetti di progettazione e la loro collaborazione

Il processo di creazione dell'architettura

In RUP, l'architettura è principalmente un risultato del flusso di lavoro di analisi & progettazione. Quando il progetto attiva il flusso di lavoro, iterazione dopo iterazione, l'architettura evolve fino a divenire rifinita e pulita. Poiché ogni iterazione include l'integrazione ed il test, l'architettura è abbastanza solida, quando il prodotto viene distribuito. L'architettura è il principale scopo delle iterazioni della fase Elaborazione, al termine della quale l'architettura viene normalmente resa linea di base.