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.
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.
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.
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:
-
La Vista dei casi d'uso, che contiene i casi d'uso e gli scenari che
includono il comportamento strutturalmente significativo, le classi o i rischi tecnici. Si tratta di un
sottoinsieme del Modello di casi d'uso.
-
La Vista logica, che contiene le classi di progettazione più importanti e la loro organizzazione
in pacchetti e sottosistemi, e l'organizzaz di questi pacchetti e sottosistemi
in livelli. Contiene anche delle realizzazioni di casi d'uso. E' un sottoinsieme del Modello di progettazione.
-
La Vista di implementazione, che contiene una panoramica del Modello di implementazione e la sua organizzazione in termini di
moduli in pacchetti e livelli. Viene descritta anche l'assegnazione di pacchetti e classi (della Vista logica) ai
pacchetti e ai moduli della Vista di implementazione. E' un sottoinsieme del Modello di implementazione.
-
La Vista dei processi, che contiene la descrizione delle attività implicate (processo
e thread), delle loro interazioni e configurazioni e dell'assegnazione degli oggetti di progettazione e delle
classi alle attività. La vista deve essere utilizzata solo se il sistema ha un grado significativo di Simultaneità. In RUP, è un sottoinsieme del Modello di progettazione.
-
La Vista di distribuzione, che contiene la descrizione di vari nodi fisici per le
configurazioni delle piattaforme più tipiche, e l'assegnazione delle attività (dalla Vista dei processi) ai nodi
fisici. Questa vista deve essere utilizzata solo se il sistema viene distribuito. E' un sottoinsieme del Modello di distribuzione.
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.
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.
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
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 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:
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.
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.
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
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.
|