Introduzione
Il termine architettura viene ora ampiamente utilizzato al di fuori della connotazione tradizionale di edificio
ed esistono diverse definizioni di "architettura" (nel contesto dei sistemi) e di "architettura di sistema (o di
sistemi)", ad esempio:
"Architettura di sistema: la struttura di sistema unificante e fondamentale, definita in termini di funzionalità,
vincoli, processi, interfacce ed elementi del sistema".
[definizione approvata da INCOSE Systems Architecture Working Group a INCOSE '96 a Boston, MA l'8 luglio 1996]
"L'architettura di sistema comprende le proprietà fisiche principali, lo stile, la struttura, le interazioni e lo
scopo di un sistema".
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz
Pirbhai, Dorset House Publishing 2000]
"Architettura: i concetti e le regole che definiscono la struttura, la funzionalità semantica e le relazioni tra le
parti di un sistema; un piano di qualcosa da costruire. Include gli elementi che comprendono la tal cosa, le
relazioni tra gli elementi, i vincoli che incidono su tali relazioni, una focalizzazione sulle parti della tal cosa
e una focalizzazione sulla cosa come un unico elemento.
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, che fa riferimento a ISO/IEC 10746-2:
Information Technology - Open Distributed Processing - Reference Model: Foundations, come fonte]
"Architettura: la struttura dei componenti in un programma/sistema, le relative relazioni e i principi e le linee
guida che regolano la loro progettazione ed evoluzione nel tempo".
[DoD 5000.59-P, "Modeling and Simulation Master Plan," Ottobre 1995]
Un'architettura è "la struttura dei componenti, le relative relazioni e i principi e le linee guida che regolano la
loro progettazione ed evoluzione nel tempo".
[IEEE STD 610.12, esteso lievemente da IAP (Integrated Architectures Panel) di ITF (Integration Task Force) C4ISR
in DoD Architecture Framework, Versione 1.0]
Vengono utilizzate parole e costruzioni differenti e non tutte le definizioni includono esattamente gli stessi
aspetti, ma vi sono sovrapposizioni significative. Tali definizioni rivelano che l'architettura di sistema riguarda i
seguenti elementi:
-
la struttura del sistema in termini di elementi, componenti e parti
-
le relazioni tra gli elementi
-
i vincoli che influiscono sugli elementi e sulle relative relazioni
-
la funzionalità dimostrata dal sistema e le interazioni che si verificano tra gli elementi per
ottenere tale funzionalità
-
i principi, le regole e il fondamento logico che ha consentito che il sistema diventasse quello che è
(e che ne regola l'evoluzione)
-
le caratteristiche e le proprietà logiche e fisiche del sistema
-
lo scopo del sistema
Quindi, per fornire in modo esauriente tutti questi aspetti, è necessaria una serie di informazioni ricche e
potenzialmente complesse, ma occorre tenere a mente che non tutti gli stakeholder hanno necessità di vedere o di
comprendere tutti gli aspetti contemporaneamente. L'idea di punti di vista consente la separazione di questi
concetti e la presentazione in una classe di stakeholder composta solo degli elementi necessari per un'effettiva
partecipazione. Dalla prospettiva di un determinato punto di vista, è anche possibile visualizzare il sistema a
differenti "risoluzioni", dalla risoluzione bassa, corrispondente a un elevato livello di astrazione, alla
risoluzione elevata, corrispondente a una specifica concreta (di parti e così via) per l'implementazione.
Punti di vista
Un punto di vista (su un sistema) è "una forma di astrazione ottenuta utilizzando una serie selezionata di concetti
architettonici e di ruoli di struttura, per focalizzarsi su particolari elementi all'interno di un sistema" [ISO/IEC
10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations]. La tabella elenca alcuni
dei punti di vista scelti per acquisire i vari aspetti. Questi punti di vista sono allineati con quelli presenti in
ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview.
Punto di vista
|
Problematica
|
Impatto
|
Risorsa lavorativa
|
Attinente ai ruoli e alle responsabilità delle risorse lavorative del sistema o dell'organizzazione
(e ai criteri che li riguardano).
|
Attività delle risorse lavorative, interazione umana/sistema. Specifica delle prestazioni umane e
fattori umani.
|
Informazioni
|
Il tipo di informazioni gestite dal sistema e di vincoli sull'utilizzo e l'interpretazione di tali
informazioni.
|
Integrità delle informazioni, limitazioni di capacità.
Accessibilità delle informazioni, tempestività.
|
Logico
|
La scomposizione del sistema in una serie di sottosistemi che interagiscono nelle interfacce,
collaborando per fornire i servizi del sistema.
|
Il sistema mostra la funzionalità desiderata.
Il sistema è estensibile, adattabile e gestibile.
Le risorse sono riutilizzabili.
|
Distribuzione/Fisico
|
L'infrastruttura necessaria per supportare la distribuzione e la funzionalità del sistema.
|
Adeguatezza delle caratteristiche fisiche del sistema per ospitare la funzionalità e soddisfare i
requisiti non funzionali.
|
Processo
|
Simultaneità, scalabilità, prestazioni, produttività, affidabilità
|
Adeguatezza della velocità di risposta, produttività, tolleranza degli errori.
|
Punti di vista comuni del sistema.
Questi punti di vista sono alcuni dei più comuni per sistemi intensivi di software. Molte delle architetture di sistema
richiedono inoltre punti di vista specifici del dominio. Gli esempi includono la sicurezza, la protezione e i punti di
vista meccanici. I punti di vista rappresentano differenti aree di interesse che è necessario considerare nella
progettazione e nell'architettura del sistema. Se esistono stakeholder o esperti del sistema le cui preoccupazioni sono
importanti per l'architettura generale, è probabile che vi sia l'esigenza, per una serie di prodotti di lavoro del
punto di vista, di catturare le loro decisioni di progettazione.
E' importante costruire un team dell'architettura di sistema con uno staff competente, che si curi dei diversi punti di
vista. Il team potrebbe consistere in analisti del sistema e utenti che si prendono la responsabilità primaria per il
punto di vista delle risorse lavorative, architetti software che seguono il punto di vista logico e tecnici che si
occupano del punto di vista fisico, oltre che esperti sui punti di vista specifici del dominio.
Livelli di astrazione
Oltre ai punti di vista, un'architettura di sistema richiede dei livelli di specifica. Man mano che l'architettura
viene sviluppata, essa si evolve da una specifica generale e astratta a una specifica più specifica e dettagliata. Il
RUP identifica quattro livelli strutturali, come mostrato nella tabella seguente.
Livello del modello
|
Manifestazioni
|
Contesto
|
Il sistema e i relativi attori.
|
Analisi
|
Partizionamento iniziale del sistema per stabilire l'approccio concettuale.
|
Progettazione
|
Realizzazione del modello di analisi in hardware, software e persone.
|
Implementazione
|
Realizzazione del modello di progettazione in configurazioni specifiche.
|
Livelli del RUP strutturali
Attraverso tali livelli, la progettazione va dall'astratto al fisico. Il modello di contesto cattura tutte le entità
esterne (attori) che interagiscono con il sistema. Tali attori possono essere esterni per l'azienda che distribuisce il
sistema o interni per l'azienda. In entrambi i casi, gli attori potrebbero essere risorse lavorative umane o altri
sistemi. A livello dell'analisi, le partizioni non riflettono le scelte di hardware, software e persone. Riflettono,
invece, gli approcci di progettazione per dividere le azioni che il sistema deve eseguire e le modalità di
distribuzione dell'impegno. A livello della progettazione, le decisioni vengono prese riguardo al genere di componenti
hardware e software e ai ruoli delle risorse lavorative che sono necessari. A livello dell'implementazione, vengono
attuate scelte specifiche di tecnologia hardware e software per implementare la progettazione. Ad esempio, a livello
della progettazione, è possibile specificare un server di dati. A livello dell'implementazione, la decisione riguarda
l'utilizzo di una specifica piattaforma per l'esecuzione di un'applicazione database specifica.
Modelli e diagrammi
Un modello è una rappresentazione di un sistema, che generalmente si rivolge a una determinata area di
interesse. Un sistema è, quindi, rappresentato da una serie di modelli, perché esistono numerose considerazioni per
l'utilizzo o lo sviluppo del sistema. Ogni modello può essere costruito con livelli di astrazione variabili, dal più
generale che nasconde o incapsula i dettagli, a uno più specifico che espone maggiormente i dettagli e le decisioni di
progettazione esplicite.
Un punto di vista, come indica il termine, è una "posizione" nozionale da cui vengono resi visibili alcuni
aspetti o questioni relativi a un sistema, che implicano l'applicazione di una serie di concetti e regole per formare
un filtro concettuale. Generalmente, non è sufficiente (per la comprensione) esaminare il sistema reale o i modelli che
saranno (o dovranno essere) costruiti per rappresentare e descrivere i concetti.
Le viste sono proiezioni di modelli che mostrano entità rilevanti da uno specifico punto di vista. Tali
proiezioni vengono generalmente illustrate da diagrammi di un certo tipo.
L'intersezione del punto di vita e il livello di astrazione o di specificità del modello contengono (o almeno
identificano) le viste di uno o più dettagli rilevanti per tale punto di vista o concetto, a tale livello di
astrazione.
la struttura del sistema viene, quindi, catturata in una serie di modelli (e diagrammi che li visualizzano) che
esprimono l'architettura da vari punti di vista e livelli. Come mostrato nella tabella di framework del modello
riportata di seguito, non esiste un modello/diagramma per ogni combinazione di livello-punto di vista. A livello
dell'implementazione, un singolo modello cattura la realizzazione dei componenti hardware e software per ogni
configurazione di sistema.
Livello del modello
|
Punti di vista
|
Risorsa lavorativa
|
Logico
|
Informazioni
|
Distribuzione/Fisico
|
Processo
|
Contesto
|
Vista dell'organizzazione UML
|
Diagramma del contesto di sistema
|
Vista di dati dell'azienda
|
Vista di località dell'azienda
|
Vista del processo business
|
Analisi
|
Vista delle risorse lavorative del sistema generalizzate
|
Vista del sottosistema
|
Vista di dati del sistema
|
Vista di località del sistema
|
Vista del processo di sistema
|
Progettazione
|
Vista delle risorse lavorative del sistema
|
Viste della classe del sottosistema
Viste del componente software
|
Schema di dati del sistema
|
Vista del nodo descrittore
|
Vista del processo dettagliato
|
Implementazione
|
Istruzioni e specifiche del ruolo delle risorse lavorative
|
Configurazioni: Diagrammi di sviluppo con componenti software e hardware del sistema.
|
Molte delle viste specificate nella tabella derivano da modelli UML standard. Ad esempio, nel livello Analisi del punto
di vista Logico, il sistema viene scomposto in sottosistemi che collaborano per soddisfare i requisiti dell'utente. I
sottosistemi vengono utilizzati con la stessa semantica dello standard UML. Tali sottosistemi, a turno, vengono
scomposti in sottosistemi o (infine) in classi. Il livello Progettazione del punto di vista Logico è la vista del
Modello di classe dettagliato. Tale modello è anche un modello di classe UML standard, incentrato sulle classi attive
nel sistema. I punti di vista specifici del dominio necessitano anche di viste dei prodotti di lavoro per uno o più
livelli. E' necessario che la serie di prodotti di lavoro del progetto, all'interno di questo framework, faccia parte
del caso di sviluppo del progetto.
|