Linea guida: Documento dell'architettura software
Questa guida al tool fornisce una panoramica sul contenuto del documento dell'architettura software.
Relazioni
Descrizione principale

Riferimenti

La sezione dei riferimenti illustra documenti esterni che forniscono informazioni di sfondo, importanti per una comprensione dell'architettura del sistema. Se esiste un ampio numero di riferimenti, strutturare la sezione in sezioni secondarie:

  1. documenti esterni
  2. documenti interni
  3. documenti governativi
  4. documenti non governativi
  5. etc...

Obiettivi e vincoli dell'architettura

L'architettura sarà composta considerando quanto segue:

  • requisiti funzionali, catturati nel modello di casi d'uso
  • requisiti non funzionali, catturati nelle specifiche supplementari

Tuttavia, questi non sono i soli elementi che influiscono sulla struttura dell'architettura; esistono vincoli imposti dall'ambiente in cui deve operare il software, dalle esigenze di riutilizzo di risorse esistenti, dall'imposizione di vari standard, dall'esigenza di compatibilità con sistemi esistenti, etc..  Inoltre, può esserci un insieme preesistente di principi e politiche strutturali che guida lo sviluppo e che devono essere elaborati e  verificati per il progetto.   In questa sezione del documento dell'architettura software vengono descritti gli obiettivi e i vincoli e tutte le decisioni strutturali che ne derivano e che non trovano un obiettivo pronto (quali i requisiti) altrove.  

Quando viene creato questo documento, un input importante è una specifica dell'ambiente di implementazione. Esempi di ciò che deve essere specificato sono una piattaforma di destinazione (hardware, sistema operativo), un sistema a finestre, un tool di sviluppo (linguaggio, programma di creazione GUI), un sistema di gestione del database e le librerie dei componenti.   È anche utile specificare quali tecnologie di interfaccia utente sono consentite e quali non lo sono.  Molti sistemi scelgono di non utilizzare certe tecnologie di presentazione (JavaScript, Applet, Frame, XML, etc.) così che molti sistemi client sono capaci di utilizzare l'applicazione, oppure rendere l'applicazione più facile da sviluppare.   Le decisioni vengono catturate nel documento di architettura del software, mentre i dettagli per come utilizzare e applicare le tecnologie scelte sono documentati in  Prodotto di lavoro: Linee guida specifiche per il progetto.

L'imposizione di queste decisioni viene ottenuto strutturando in frame un insieme di criteri di valutazione dell'architettura che verrà utilizzato come parte della valutazione di iterazione.

I criteri di valutazione vengono anche derivati dai casi di modifica che documentano probabili modifiche successive ai seguenti elementi:

  • le capacità e le proprietà del sistema
  • il modo in cui viene utilizzato il sistema
  • gli ambienti operativi e di supporto del sistema

I casi di modifica chiariscono quelle proprietà del sistema descritte da frasi soggettive, quali "facile da estendere", "facile da portare", "facile da gestire" e "veloce da sviluppare". I casi di modifica sono focalizzati su ciò che è importante e plausibile, piuttosto che su ciò che è possibile.

I casi di modifica cercano di preannunciare le modifiche; queste previsioni raramente si rivelano molto attendibili.

Le proprietà di un sistema sono determinate da utenti, sponsor, fornitori, sviluppatori e altri portatori d'interesse. Le modifiche possono provenire da varie fonti, ad esempio:

  • Portatori di business: processi e obiettivi di business nuovi e modificati
  • Portatori di tecnologie: adattamento del sistema a nuove piattaforme, integrazione con nuovi componenti
  • Modifiche nei profili dell'utente medio
  • Modifiche nelle esigenze di integrazione con altri sistemi
  • Modifiche all'ambito che derivano dalla migrazione di funzionalità da sistemi esterni

Vista caso d'uso

La vista dei casi d'uso presenta un sottoinsieme del Prodotto di lavoro: Modello dei casi d'uso, che fornisce i casi d'uso del sistema significativi da un punto di vista strutturale. Descrive una serie di scenari e/o di casi d'uso che rappresentano una funzionalità in qualche modo centrale e significativa. Descrive inoltre una serie di scenari e/o di casi d'uso che abbiano una sostanziale copertura strutturale (che coinvolge svariati elementi dell'architettura) o che evidenzino un punto delicato nella struttura.

Se il modello è più ampio, verrà organizzato tipicamente in pacchetti; per facilitare la comprensione, la vista dei casi d'uso deve essere organizzata in modo simile per pacchetti, se è suddivisa in pacchetti. Per ciascun caso d'uso significativo, includere una sezione secondaria contenente le seguenti informazioni:

  1. Il nome del caso d'uso.
  2. Una breve descrizione del caso d'uso.
  3. Le descrizioni significative del Flusso di eventi del caso d'uso. Può essere la completa descrizione del Flusso di eventi o le sue sezioni secondarie che descrivono i flussi o gli scenari significativi del caso d'uso.
  4. Le descrizioni significative delle relazioni che coinvolgono il caso d'uso, come le relazioni di estensione e inclusione, o le associazioni di comunicazione.
  5. Una numerazione di diagrammi di casi d'uso significativi correlati al caso d'uso.
  6. Le descrizioni significative dei Requisiti speciali del caso d'uso. Può essere la descrizione Requisiti speciali completa oppure le sue sezioni secondarie che descrivono i requisiti significativi.
  7. Rappresentazioni dell'interfaccia utente significative che chiariscono il caso d'uso.
  8. Le realizzazioni di questi casi d'uso possono essere trovate nella vista logica.

La Vista logica

La vista logica è un sottoinsieme del Prodotto di lavoro: Modello di progettazione che presenta elementi di progettazione significativi da un punto di vista strutturale. Descrive le classi più importanti, la loro organizzazione nei pacchetti e nei sottosistemi e l'organizzazione di questi pacchetti e sottosistemi in livelli. Descrive inoltre le realizzazioni di casi d'uso più importanti, ad esempio, gli aspetti dinamici dell'architettura.

Un sistema complesso può richiedere un numero di sezioni per descrivere la vista logica:

  1. Panoramica

    Questa sezione secondaria descrive la scomposizione complessiva del modello di progettazione in termini di gerarchia e di livelli di pacchetti. Se il sistema ha vari livelli di pacchetti, occorre descrivere prima quelli che sono significativi ad alto livello. Includere tutti i diagrammi che presentano pacchetti significativi ad alto livello, così come le loro interdipendenze e la strutturazione a livelli. In seguito presentare tutti i pacchetti significativi all'interno di questi e così via fino ai pacchetti significativi alla fine della gerarchia.

  2. Pacchetti di progettazione significativi da un punto di vista strutturale

    Per ciascun pacchetto significativo, includere una sezione secondaria con le seguenti informazioni:

    1. Il nome
    2. Una breve descrizione
    3. Un diagramma con tutte le classi e i pacchetti significativi contenuti nel pacchetto. Per una migliore comprensione di questo diagramma può illustrare alcune classi da altri pacchetti, se necessario.
    4. Per ciascuna classe significativa nel pacchetto, includere il nome, una breve descrizione e, facoltativamente, una descrizione di alcune delle maggiori responsabilità, operazioni e attributi. Inoltre, vengono descritte le relazioni importanti, se necessarie per comprendere i diagrammi inclusi.
  3. Realizzazioni dei casi d'uso

    Questa sezione illustra come funziona il software fornendo poche realizzazioni del caso d'uso (o dello scenario) selezionate e spiega come i vari elementi del modello di progettazione contribuiscono alla loro funzionalità. Le realizzazioni fornite vengono selezionate poiché rappresentano alcune funzionalità centrali e significative del sistema finale; oppure per la copertura strutturale - esse esercitano molti elementi strutturali - oppure evidenziano o illustrano uno specifico punto delicato dell'architettura. I casi d'uso e gli scenari corrispondenti di queste realizzazioni possono essere trovati nella vista dei casi d'uso.

    Per ciascuna realizzazione del caso d'uso significativa, includere una sezione secondaria con le seguenti informazioni:

    1. Il nome del caso d'uso realizzato.
    2. Una breve descrizione del caso d'uso realizzato.
    3. Le descrizioni significative del Flusso di eventi - Progettazione della realizzazione del caso d'uso. Può essere la completa descrizione del Flusso di eventi - Progettazione o le sue sezioni secondarie che descrivono i flussi o gli scenari significativi del caso d'uso.
    4. Una numerazione delle interazioni significative dei diagrammi di classe correlati alla realizzazione del caso d'uso.
    5. Le descrizioni significative dei Requisiti derivati della realizzazione del caso d'uso. Può essere la descrizione Requisiti derivati completa oppure le sue sezioni secondarie che descrivono i requisiti significativi.

Elementi di progettazione significativa da un punto di vista strutturale

Per agevolare la decisione di cosa sia significativo da un punto di vista strutturale, vengono forniti alcuni esempi di elementi qualificanti e le relative caratteristiche:

  • Un elemento del modello che comprende un'astrazione maggiore del dominio del problema, quale:
    • Un piano di volo in un sistema di controllo del traffico aereo.
    • Un impiegato con un sistema di buste paga.
    • Un abbonato telefonico in un sistema telefonico.

I tipi secondari non devono essere necessariamente inclusi, ad esempio non è importante la distinzione tra un piano di volo standard ICAO e un piano di volo interno americano; si tratta sempre di piani di volo che condividono una quantità significativa di attributi e operazioni.

Non è importante la distinzione tra un abbonato telefonico con una linea di dati oppure uno con una linea vocale, finché la gestione delle chiamate procede all'incirca nello stesso modo.

  • Un elemento del modello utilizzato da molti altri elementi del modello.
  • Un elemento del modello che comprende un meccanismo maggiore (servizio) del sistema
  • Meccanismi di progettazione
    • Meccanismo di persistenza (repository, database, gestione memorie).
    • Meccanismo di comunicazione (RPC, broadcast, servizio broker).
    • Errore di gestione o recupero del meccanismo.
    • Meccanismo di visualizzazione e altre interfacce comuni (finestre, cattura dati, condizionamento del segnale, etc).
    • Meccanismo di parametrizzazione.

In generale, qualsiasi meccanismo può essere utilizzato in molti pacchetti differenti (in contrasto con totalmente interno al pacchetto), per cui è meglio avere una singola implementazione comune in tutto il sistema oppure almeno una singola interfaccia che nasconde varie implementazioni alternative.

  • Un elemento del modello che partecipa in un'interfaccia principale del sistema con, ad esempio, uno dei seguenti elementi:
    • un sistema operativo.
    • un prodotto pronto (sistemi a finestre, sistemi informativi geografici).
    • una classe che implementa o supporta un pattern strutturale (quali i pattern per gli elementi del modello di separazione, compresi il pattern di controllo modello-vista, oppure il pattern broker).
  • Un elemento del modello con visibilità localizzata, ma che può avere un ampio impatto sulle prestazioni complessive del sistema, ad esempio:
    • un meccanismo di polling per effettuare la scansione dei sensori ad una velocità molto elevata.
    • un meccanismo di traccia per la risoluzione dei problemi.
    • un meccanismo del punto di controllo per un sistema di alta disponibilità (punto di controllo e riavvio).
    • una sequenza di avvio.
    • un aggiornamento in linea del codice.
    • una classe che incapsula un algoritmo nuovo e tecnicamente rischioso, oppure un algoritmo che sia critico, da un punto di vista della sicurezza o della riservatezza, ad esempio, il calcolo del livello di irradiazione, criteri per evitare una collisione aerea in uno spazio aereo congestionato, codifica di password.

I criteri, per quanto siano significativi da un punto di vista strutturale, si evolvono in iterazioni nella fase iniziale del progetto, appena di rivelano difficoltà tecniche e si inizia a comprendere meglio il sistema. Tuttavia, come regola, occorre etichettare almeno il 10% degli elementi del modello come "significativi da un punto di vista strutturale." Altrimenti il rischio diluisce il concetto di architettura e "tutto rappresenta architettura".

Quando si definiscono e includono elementi del modello, significativi da un punto di vista strutturale, nella vista logica, occorre considerare anche i seguenti aspetti:

  • Identificare il potenziale per l'accomunanza e il riutilizzo. Quali classi possono essere classi secondarie di una classe comune oppure istanze della stessa classe con parametri?
  • Identificare il potenziale per la parametrizzazione. Quale parte della progettazione può essere resa più riutilizzabile o flessibile utilizzando parametri runtime (quale il comportamento gestito da tabelle o i dati delle risorse caricati all'avvio)?
  • Identificare il potenziale per l'utilizzo di prodotti pronti.

La vista processi

La vista processi descrive la struttura dei processi del sistema. Poiché la struttura del processo ha un grande impatto strutturale, occorre presentare tutti i processi. All'interno dei processi, occorre presentare solo i thread significativi da un punto di vista strutturale. La vista processi descrive i compiti (processi e thread) coinvolti nell'esecuzione del sistema, così come l'allocazione degli oggetti e delle classi al compito.

Per ciascuna rete dei processi, includere una sezione secondaria con le seguenti informazioni:

  1. Il nome
  2. I processi coinvolti.
  3. Le interazioni tra i processi, sotto forma dei diagrammi di comunicazione, in cui gli oggetti sono processi reali che comprendono i propri thread di controllo. Per ciascun processo, descrivere brevemente il comportamento, la durata del ciclo di e le caratteristiche di comunicazione.

La vista distribuzione

In questa sezione viene descritta una o più configurazioni fisiche di rete (hardware) in cui viene distribuito ed eseguito il software. Inoltre viene descritta l'allocazione dei compiti (dalla vista processi) ai nodi fisici. Per ciascuna configurazione di rete, includere una sezione secondaria con le seguenti informazioni:

  1. Il nome
  2. Un diagramma di distribuzione che illustra la configurazione, seguito da una mappatura ai processi di ciascun processore.
  3. Se esistono molte possibili configurazioni fisiche, descriverne solo una tipica e quindi spiegare le regole di mappatura generale da seguire nella definizione di altre. Occorre anche includere, in molti casi, le descrizioni delle configurazioni di rete per l'esecuzione di test e simulazioni software.

Questa vista viene generata dal Prodotto di lavoro: Modello di distribuzione.

La vista implementazione

In questa sezione viene descritta la scomposizione del software in livelli e sottosistemi di implementazione nel modello di implementazione. Fornisce inoltre una panoramica dell'allocazione degli elementi di progettazione (dalla vista logica) all'implementazione. Contiene due sezioni secondarie:

  1. Panoramica

    Questa sezione secondaria assegna un nome e definisce i vari livelli e il loro contenuto, i ruoli che regolano l'inclusione ad un livello dato e i confini tra i livelli. Comprende un diagramma dei componenti che illustrano le relazioni tra componenti.

  2. Livelli

    Per ciascun livello, includere una sezione secondaria con le seguenti informazioni:

    1. Il nome
    2. Un diagramma dei componenti che illustra i sottosistemi di implementazione e le loro dipendenze di importazione.
    3. Se appropriato, una struttura della relazione del livello con gli elementi nella vista logica o dei processi.
    4. Una enumerazione dei sottosistemi di implementazione presenti nel livello. Per ciascun sottosistema di implementazione, procedere come segue:
      • Assegnare un nome, un'abbreviazione o un nome descrittivo, e un fondamento logico per la loro esistenza;
      • Se appropriato, indicare la relazione del sottosistema di implementazione con gli elementi nella vista logica o dei processi. In molti casi, il sottosistema di implementazione fornirà uno o più sottosistemi dalla vista logica.
      • Se il sottosistema di implementazione contiene sottosistemi di implementazione, significativi da un punto di vista strutturale, e/o
        directory, riflettere questa situazione nella gerarchia della sezione secondaria.
      • Se il sottosistema di implementazione non mappa una directory di implementazione una ad una, includere una spiegazione di come è definito il sottosistema di implementazione in termini di directory e/o di file di implementazione.

La vista dati

Questa vista è rilevante solo per sistemi che coinvolgono persistenza supportata da database. Descrive elementi persistenti, significativi da un punto di vista strutturale, nel modello dati. Descrive una panoramica del modello dati e della sua organizzazione in termini di tabelle, viste, indici, trigger e procedure memorizzate, utilizzare per fornire persistenza al sistema. Descrive inoltre la mappatura di classi persistenti (dalla vista logica) alla struttura dati del database.

In genere comprende:

  • La mappatura dalle classi chiave di progettazione persistenti, specialmente dove la mappa è non irrilevante.
  • Le parti significative, da un punto di vista strutturale, del sistema che sono state implementate nel database, sotto forma di procedure e trigger memorizzati.
  • Decisioni importanti in altre viste che hanno implicazioni con i dati, quali la scelta della strategia delle transazioni, la distribuzione, la simultaneità, la tolleranza degli errori. Ad esempio, la scelta di utilizzare la gestione di transazioni, basata su database (dipendendo dal database per il commit o l'interruzione delle transazioni) richiede che il meccanismo di gestione degli errori, utilizzato nell'architettura, comprenda una strategia per il recupero di una transazione non riuscita, aggiornando lo stato degli oggetti di persistenza che sono nella memoria cache dell'applicazione.

Occorre presentare elementi di dati significativi da un punto di vista strutturale, descriverne le responsabilità, così come alcune relazioni e comportamenti molto importanti (trigger, procedure memorizzate, etc). .

Dimensioni e prestazioni

In questa sezione vengono descritte le caratteristiche di definizione volumetrica e delle responsabilità, da un punto di vista strutturale, del sistema. Queste informazioni possono comprendere:

  • Il numero di elementi chiave che il sistema deve gestire (quale il numero di voli simultanei per un sistema di controllo del traffico aereo, il numero di telefonate simultanee in uno switch telefonico, il numero di utenti online simultanei in un sistema di prenotazioni aeree, etc)..
  • Le misure chiave delle prestazioni del sistema, quali il tempo di risposta medio per gli eventi chiave; l'incidenza media, massima e minima della produttività.
  • L'impatto (in termini di disco e memoria) dei programmi eseguibili, essenziale se un sistema incorporato deve esistere all'interno di vincoli estremamente limitanti.

La maggior parte di queste qualità vengono catturate come requisiti; vengono presentate qui poiché condizionano l'architettura in modo significativo e giustificano un'attenzione speciale. Per ciascun requisito, discutere come l'architettura supporti questo requisito.

Qualità

In questa sezione, elencare le dimensioni chiave delle qualità del sistema che condizionano l'architettura. Queste informazioni possono comprendere:

  • I requisiti delle prestazioni operative, quali MTBF (Mean-Time Between Failure).
  • Gli obiettivi delle qualità, quali "nessun tempo morto non pianificato".
  • Gli obiettivi di estensibilità, quali "il software sarà aggiornabile durante l'esecuzione del sistema".
  • Gli obiettivi di portabilità, quali le piattaforme hardware, i sistemi operativi, i linguaggi.

Per ciascuna dimensione, discutere come l'architettura supporti questo requisito. È possibile organizzare la sezione in base alle differenti viste (logica, di implementazione, etc) oppure in base alla qualità. Quando caratteristiche particolari sono importanti nel sistema, ad esempio, la sicurezza, la riservatezza o la privacy, il supporto strutturale per queste caratteristiche deve essere attentamente delineato in questa sezione.