Concetto: Architettura di sistema
Un'architettura di sistema è una rappresentazione di un sistema in cui esiste una corrispondenza di funzionalità sui componenti hardware e software, una corrispondenza dell'architettura software sull'architettura hardware e un'interazione umana con tali componenti.
Relazioni
Descrizione principale

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.