Principi chiave
L'architettura software è descritta come l'organizzazione di un sistema, in cui il sistema rappresenta un insieme di componenti che realizzano le funzioni definite.
Stile architettonico
Il architectural style, chiamato anche come architectural pattern, è un insieme di principi che dà forma a un'applicazione. Definisce un quadro astratto per una famiglia di sistemi in termini di modello di organizzazione strutturale.
Lo stile architettonico è responsabile di:
Fornire un lessico di componenti e connettori con regole su come combinarli.
Migliora il partizionamento e consenti il riutilizzo del design fornendo soluzioni ai problemi che si verificano di frequente.
Descrivere un modo particolare per configurare una raccolta di componenti (un modulo con interfacce ben definite, riutilizzabile e sostituibile) e connettori (collegamento di comunicazione tra i moduli).
Il software creato per i sistemi basati su computer mostra uno dei tanti stili architettonici. Ogni stile descrive una categoria di sistema che comprende:
Un insieme di tipi di componenti che svolgono una funzione richiesta dal sistema.
Un insieme di connettori (chiamata di subroutine, chiamata di procedura remota, flusso di dati e socket) che consentono la comunicazione, il coordinamento e la cooperazione tra i diversi componenti.
Vincoli semantici che definiscono come i componenti possono essere integrati per formare il sistema.
Un layout topologico dei componenti che indica le loro interrelazioni di runtime.
Progettazione architettonica comune
La tabella seguente elenca gli stili architettonici che possono essere organizzati in base all'area di interesse principale:
| Categoria | Progettazione architettonica | Descrizione |
|---|---|---|
| Comunicazione | Bus dei messaggi | Prescrive l'uso di un sistema software in grado di ricevere e inviare messaggi utilizzando uno o più canali di comunicazione. |
| Architettura orientata ai servizi (SOA) | Definisce le applicazioni che espongono e consumano funzionalità come servizio utilizzando contratti e messaggi. | |
| Distribuzione | Client / server | Separare il sistema in due applicazioni, in cui il client effettua richieste al server. |
| 3 livelli o N livelli | Separa la funzionalità in segmenti separati con ogni segmento che è un livello situato su un computer fisicamente separato. | |
| Dominio | Progettazione basata sul dominio | Incentrato sulla modellazione di un dominio aziendale e sulla definizione di oggetti aziendali basati su entità all'interno del dominio aziendale. |
| Struttura | Basato su componenti | Suddividi la progettazione dell'applicazione in componenti logici o funzionali riutilizzabili che espongono interfacce di comunicazione ben definite. |
| Stratificato | Dividi le preoccupazioni dell'applicazione in gruppi impilati (livelli). | |
| Orientato agli oggetti | Basato sulla divisione delle responsabilità di un'applicazione o di un sistema in oggetti, ciascuno contenente i dati e il comportamento relativo all'oggetto. |
Tipi di architettura
Esistono quattro tipi di architettura dal punto di vista di un'impresa e, collettivamente, queste architetture vengono denominate enterprise architecture.
Business architecture - Definisce la strategia di business, governance, organizzazione e processi aziendali chiave all'interno di un'impresa e si concentra sull'analisi e sulla progettazione dei processi aziendali.
Application (software) architecture - Funge da modello per i singoli sistemi applicativi, le loro interazioni e le loro relazioni con i processi aziendali dell'organizzazione.
Information architecture - Definisce le risorse di dati logiche e fisiche e le risorse di gestione dei dati.
Information technology (IT) architecture - Definisce gli elementi costitutivi dell'hardware e del software che costituiscono il sistema informativo complessivo dell'organizzazione.
Processo di progettazione dell'architettura
Il processo di progettazione dell'architettura si concentra sulla scomposizione di un sistema in diversi componenti e sulle loro interazioni per soddisfare requisiti funzionali e non funzionali. Gli input chiave per la progettazione dell'architettura software sono:
I requisiti prodotti dalle attività di analisi.
L'architettura hardware (l'architetto del software a sua volta fornisce i requisiti all'architetto del sistema, che configura l'architettura hardware).
Il risultato o l'output del processo di progettazione dell'architettura è un file architectural description. Il processo di progettazione dell'architettura di base è composto dai seguenti passaggi:
Comprendi il problema
Questo è il passaggio più cruciale perché influisce sulla qualità del design che segue.
Senza una chiara comprensione del problema, non è possibile creare una soluzione efficace.
Molti progetti e prodotti software sono considerati fallimenti perché non hanno effettivamente risolto un valido problema aziendale o hanno un ritorno sull'investimento (ROI) riconoscibile.
Identifica gli elementi di design e le loro relazioni
In questa fase, costruire una linea di base per definire i confini e il contesto del sistema.
Scomposizione del sistema nelle sue componenti principali in base ai requisiti funzionali. La scomposizione può essere modellata utilizzando una matrice della struttura di progettazione (DSM), che mostra le dipendenze tra gli elementi di progettazione senza specificare la granularità degli elementi.
In questa fase, la prima convalida dell'architettura viene eseguita descrivendo un numero di istanze di sistema e questa fase viene definita progettazione architettonica basata sulla funzionalità.
Valuta il progetto dell'architettura
A ogni attributo di qualità viene fornita una stima, quindi per raccogliere misure qualitative o dati quantitativi viene valutato il progetto.
Implica la valutazione dell'architettura per la conformità ai requisiti degli attributi di qualità architettonica.
Se tutti gli attributi di qualità stimati sono conformi allo standard richiesto, il processo di progettazione architettonica è terminato.
In caso contrario, si entra nella terza fase della progettazione dell'architettura software: la trasformazione dell'architettura. Se l'attributo di qualità osservato non soddisfa i suoi requisiti, è necessario creare un nuovo design.
Trasforma il design dell'architettura
Questa fase viene eseguita dopo una valutazione del progetto architettonico. Il progetto architettonico deve essere modificato fino a soddisfare completamente i requisiti degli attributi di qualità.
Si occupa di selezionare soluzioni di design per migliorare gli attributi di qualità preservando la funzionalità del dominio.
Un disegno viene trasformato applicando operatori, stili o modelli di disegno. Per la trasformazione, prendi il progetto esistente e applica operatori di progettazione come decomposizione, replica, compressione, astrazione e condivisione delle risorse.
Il progetto viene nuovamente valutato e lo stesso processo viene ripetuto più volte se necessario e persino eseguito in modo ricorsivo.
Le trasformazioni (cioè le soluzioni di ottimizzazione degli attributi di qualità) generalmente migliorano uno o alcuni attributi di qualità mentre influiscono negativamente sugli altri
Principi chiave dell'architettura
Di seguito sono riportati i principi chiave da considerare durante la progettazione di un'architettura:
Costruisci per cambiare invece di costruire per durare
Considera come l'applicazione potrebbe dover cambiare nel tempo per affrontare nuovi requisiti e sfide e crea la flessibilità necessaria per supportarla.
Riduci il rischio e modello da analizzare
Utilizza strumenti di progettazione, visualizzazioni, sistemi di modellazione come UML per acquisire requisiti e decisioni di progettazione. Possono essere analizzati anche gli impatti. Non formalizzare il modello nella misura in cui sopprime la capacità di iterare e adattare facilmente il progetto.
Usa modelli e visualizzazioni come strumento di comunicazione e collaborazione
Una comunicazione efficiente del design, delle decisioni e delle modifiche in corso al design è fondamentale per una buona architettura. Usa modelli, viste e altre visualizzazioni dell'architettura per comunicare e condividere il progetto in modo efficiente con tutte le parti interessate. Ciò consente una comunicazione rapida delle modifiche al design.
Identificare e comprendere le decisioni ingegneristiche chiave e le aree in cui vengono commessi più spesso gli errori. Investire nell'ottenere le decisioni chiave giuste la prima volta per rendere il progetto più flessibile e con meno probabilità di essere interrotto dai cambiamenti.
Usa un approccio incrementale e iterativo
Inizia con l'architettura di base e poi evolvi le architetture candidate mediante test iterativi per migliorare l'architettura. Aggiungi in modo iterativo i dettagli al design su più passaggi per ottenere l'immagine grande o giusta e quindi concentrarti sui dettagli.
Principi chiave di progettazione
Di seguito sono riportati i principi di progettazione da considerare per ridurre al minimo i costi, i requisiti di manutenzione e massimizzare l'estensibilità, l'usabilità dell'architettura:
Separazione degli interessi
Dividere i componenti del sistema in caratteristiche specifiche in modo che non vi siano sovrapposizioni tra le funzionalità dei componenti. Ciò fornirà un'elevata coesione e un basso accoppiamento. Questo approccio evita l'interdipendenza tra i componenti del sistema che aiuta a mantenere il sistema facile.
Principio di responsabilità unica
Ogni modulo di un sistema dovrebbe avere una responsabilità specifica, che aiuta l'utente a comprendere chiaramente il sistema. Dovrebbe anche aiutare con l'integrazione del componente con altri componenti.
Principio di minima conoscenza
Qualsiasi componente o oggetto non dovrebbe avere la conoscenza dei dettagli interni di altri componenti. Questo approccio evita l'interdipendenza e aiuta la manutenibilità.
Riduci al minimo i grandi progetti in anticipo
Ridurre al minimo la progettazione di grandi dimensioni in anticipo se i requisiti di un'applicazione non sono chiari. Se è possibile modificare i requisiti, evitare di creare un progetto di grandi dimensioni per l'intero sistema.
Non ripetere la funzionalità
La funzionalità Non ripetere specifica che la funzionalità dei componenti non deve essere ripetuta e quindi un pezzo di codice deve essere implementato in un solo componente. La duplicazione di funzionalità all'interno di un'applicazione può rendere difficile l'implementazione delle modifiche, diminuire la chiarezza e introdurre potenziali incongruenze.
Preferisci la composizione all'ereditarietà durante il riutilizzo della funzionalità
L'ereditarietà crea dipendenza tra classi figlie e classi madri e quindi blocca il libero utilizzo delle classi figlie. Al contrario, la composizione offre un grande livello di libertà e riduce le gerarchie di ereditarietà.
Identifica i componenti e raggruppali in livelli logici
Componenti di identità e area di interesse necessari nel sistema per soddisfare i requisiti. Quindi raggruppare questi componenti correlati in un livello logico, che aiuterà l'utente a comprendere la struttura del sistema ad alto livello. Evitare di mescolare componenti di diversi tipi di preoccupazioni nello stesso strato.
Definire il protocollo di comunicazione tra i livelli
Comprendere come i componenti comunicheranno tra loro, il che richiede una conoscenza completa degli scenari di distribuzione e dell'ambiente di produzione.
Definisci il formato dei dati per un livello
Vari componenti interagiranno tra loro tramite il formato dei dati. Non mischiare i formati dei dati in modo che le applicazioni siano facili da implementare, estendere e mantenere. Cerca di mantenere lo stesso formato dei dati per un livello, in modo che i vari componenti non debbano codificare / decodificare i dati durante la comunicazione tra loro. Riduce un sovraccarico di elaborazione.
I componenti del servizio di sistema dovrebbero essere astratti
Il codice relativo alla sicurezza, alle comunicazioni o ai servizi di sistema come la registrazione, la creazione di profili e la configurazione deve essere astratto nei componenti separati. Non mescolare questo codice con la logica aziendale, poiché è facile estendere il design e mantenerlo.
Eccezioni di progettazione e meccanismo di gestione delle eccezioni
Definire le eccezioni in anticipo, aiuta i componenti a gestire errori o situazioni indesiderate in modo elegante. La gestione delle eccezioni sarà la stessa in tutto il sistema.
Convenzioni di denominazione
Le convenzioni di denominazione dovrebbero essere definite in anticipo. Forniscono un modello coerente che aiuta gli utenti a comprendere facilmente il sistema. È più facile per i membri del team convalidare il codice scritto da altri e quindi aumenterà la manutenibilità.