Architettura software e introduzione al design
L'architettura di un sistema descrive i suoi componenti principali, le loro relazioni (strutture) e il modo in cui interagiscono tra loro. L'architettura e il design del software includono diversi fattori contributivi come strategia aziendale, attributi di qualità, dinamiche umane, design e ambiente IT.
Possiamo separare l'architettura e la progettazione del software in due fasi distinte: architettura del software e progettazione del software. InArchitecture, le decisioni non funzionali sono espresse e separate dai requisiti funzionali. Nella progettazione vengono soddisfatti i requisiti funzionali.
Architettura software
L'architettura funge da blueprint for a system. Fornisce un'astrazione per gestire la complessità del sistema e stabilire un meccanismo di comunicazione e coordinamento tra i componenti.
Definisce a structured solution per soddisfare tutti i requisiti tecnici e operativi, ottimizzando al contempo gli attributi di qualità comuni come prestazioni e sicurezza.
Inoltre, implica una serie di decisioni significative sull'organizzazione relative allo sviluppo del software e ciascuna di queste decisioni può avere un impatto considerevole sulla qualità, la manutenibilità, le prestazioni e il successo complessivo del prodotto finale. Queste decisioni comprendono:
Selezione degli elementi strutturali e delle loro interfacce di cui è composto il sistema.
Comportamento come specificato nelle collaborazioni tra questi elementi.
Composizione di questi elementi strutturali e comportamentali in un grande sottosistema.
Le decisioni architettoniche sono in linea con gli obiettivi aziendali.
Gli stili architettonici guidano l'organizzazione.
Progettazione software
La progettazione del software fornisce un file design planche descrive gli elementi di un sistema, come si adattano e lavorano insieme per soddisfare i requisiti del sistema. Gli obiettivi di avere un piano di progettazione sono i seguenti:
Per negoziare i requisiti di sistema e definire le aspettative con i clienti, il marketing e il personale di gestione.
Agire come modello durante il processo di sviluppo.
Guida le attività di implementazione, inclusi progettazione dettagliata, codifica, integrazione e test.
Viene prima della progettazione dettagliata, della codifica, dell'integrazione e del test e dopo l'analisi del dominio, l'analisi dei requisiti e l'analisi dei rischi.
Obiettivi dell'architettura
L'obiettivo principale dell'architettura è identificare i requisiti che influenzano la struttura dell'applicazione. Un'architettura ben strutturata riduce i rischi aziendali associati alla creazione di una soluzione tecnica e crea un ponte tra i requisiti tecnici e aziendali.
Alcuni degli altri obiettivi sono i seguenti:
Esponi la struttura del sistema, ma nascondi i dettagli di implementazione.
Realizza tutti i casi d'uso e gli scenari.
Cerca di soddisfare le esigenze dei vari stakeholder.
Gestisci i requisiti funzionali e di qualità.
Ridurre l'obiettivo della proprietà e migliorare la posizione di mercato dell'organizzazione.
Migliora la qualità e le funzionalità offerte dal sistema.
Migliora la fiducia esterna nell'organizzazione o nel sistema.
Limitazioni
L'architettura del software è ancora una disciplina emergente all'interno dell'ingegneria del software. Presenta le seguenti limitazioni:
Mancanza di strumenti e modi standardizzati per rappresentare l'architettura.
Mancanza di metodi di analisi per prevedere se l'architettura si tradurrà in un'implementazione che soddisfa i requisiti.
Mancanza di consapevolezza dell'importanza della progettazione architettonica per lo sviluppo del software.
Mancanza di comprensione del ruolo dell'architetto del software e scarsa comunicazione tra le parti interessate.
Mancanza di comprensione del processo di progettazione, esperienza di progettazione e valutazione del design.
Ruolo dell'architetto del software
Un Software Architect fornisce una soluzione che il team tecnico può creare e progettare per l'intera applicazione. Un architetto del software dovrebbe avere esperienza nelle seguenti aree:
Competenza nel design
Esperto nella progettazione di software, inclusi diversi metodi e approcci come la progettazione orientata agli oggetti, la progettazione guidata dagli eventi, ecc.
Guida il team di sviluppo e coordina gli sforzi di sviluppo per l'integrità del design.
Dovrebbe essere in grado di rivedere le proposte di progettazione e il compromesso tra di loro.
Competenza nel dominio
Esperto del sistema in fase di sviluppo e programma per l'evoluzione del software.
Assistere nel processo di indagine sui requisiti, assicurando completezza e coerenza.
Coordinare la definizione del modello di dominio per il sistema in fase di sviluppo.
Competenza tecnologica
Esperto sulle tecnologie disponibili che aiuta nell'implementazione del sistema.
Coordinare la selezione di linguaggio di programmazione, framework, piattaforme, database, ecc.
Competenza metodologica
Esperto in metodologie di sviluppo software che possono essere adottate durante SDLC (Software Development Life Cycle).
Scegli gli approcci appropriati per lo sviluppo che aiutano l'intero team.
Ruolo nascosto dell'architetto del software
Facilita il lavoro tecnico tra i membri del team e rafforza il rapporto di fiducia nel team.
Specialista dell'informazione che condivide la conoscenza e ha una vasta esperienza.
Proteggi i membri del team da forze esterne che li distrarrebbero e apporterebbero meno valore al progetto.
Deliverables dell'architetto
Una serie di obiettivi funzionali chiari, completi, coerenti e raggiungibili
Una descrizione funzionale del sistema, con almeno due strati di decomposizione
Un concetto per il sistema
Un progetto sotto forma di sistema, con almeno due strati di decomposizione
Una nozione dei tempi, degli attributi dell'operatore e dei piani operativi e di implementazione
Viene seguito un documento o un processo che garantisce la scomposizione funzionale e il controllo della forma delle interfacce
Attributi di qualità
La qualità è una misura dell'eccellenza o lo stato di essere liberi da carenze o difetti. Gli attributi di qualità sono le proprietà del sistema che sono separate dalla funzionalità del sistema.
L'implementazione degli attributi di qualità rende più facile distinguere un buon sistema da uno cattivo. Gli attributi sono fattori generali che influenzano il comportamento di runtime, la progettazione del sistema e l'esperienza utente.
Possono essere classificati come:
Attributi statici di qualità
Riflette la struttura di un sistema e di un'organizzazione, direttamente correlati all'architettura, al design e al codice sorgente. Sono invisibili all'utente finale, ma influenzano i costi di sviluppo e manutenzione, ad esempio: modularità, testabilità, manutenibilità, ecc.
Attributi di qualità dinamici
Riflette il comportamento del sistema durante la sua esecuzione. Sono direttamente correlati all'architettura del sistema, al design, al codice sorgente, alla configurazione, ai parametri di distribuzione, all'ambiente e alla piattaforma.
Sono visibili all'utente finale ed esistono in fase di runtime, ad esempio throughput, robustezza, scalabilità, ecc.
Scenari di qualità
Gli scenari di qualità specificano come evitare che un errore diventi un errore. Possono essere divisi in sei parti in base alle specifiche degli attributi:
Source - Un'entità interna o esterna come persone, hardware, software o infrastrutture fisiche che generano lo stimolo.
Stimulus - Una condizione che deve essere considerata quando arriva su un sistema.
Environment - Lo stimolo si verifica entro determinate condizioni.
Artifact - Un intero sistema o parte di esso come processori, canali di comunicazione, archiviazione persistente, processi ecc.
Response - Un'attività intrapresa dopo l'arrivo dello stimolo come rilevare guasti, recuperare da guasto, disabilitare la sorgente dell'evento ecc.
Response measure - Dovrebbe misurare le risposte avvenute in modo che i requisiti possano essere testati.
Attributi di qualità comuni
La tabella seguente elenca gli attributi di qualità comuni che un'architettura software deve avere:
Categoria | Attributo di qualità | Descrizione |
---|---|---|
Qualità del design | Integrità concettuale | Definisce la consistenza e la coerenza del design complessivo. Ciò include il modo in cui sono progettati componenti o moduli. |
Manutenibilità | Capacità del sistema di subire modifiche con una certa facilità. | |
Riusabilità | Definisce la capacità di componenti e sottosistemi idonei per l'uso in altre applicazioni. | |
Qualità di runtime | Interoperabilità | Capacità di uno o più sistemi di funzionare con successo comunicando e scambiando informazioni con altri sistemi esterni scritti e gestiti da soggetti esterni. |
Gestibilità | Definisce quanto sia facile per gli amministratori di sistema gestire l'applicazione. | |
Affidabilità | Capacità di un sistema di rimanere operativo nel tempo. | |
Scalabilità | Capacità di un sistema di gestire l'aumento del carico senza influire sulle prestazioni del sistema o la capacità di essere prontamente ampliato. | |
Sicurezza | Capacità di un sistema di prevenire azioni dannose o accidentali al di fuori degli usi previsti. | |
Prestazione | Indicazione della capacità di risposta di un sistema per eseguire qualsiasi azione entro un dato intervallo di tempo. | |
Disponibilità | Definisce la proporzione di tempo in cui il sistema è funzionale e funzionante. Può essere misurato come percentuale del tempo di inattività totale del sistema in un periodo predefinito. | |
Qualità del sistema | Supportabilità | Capacità del sistema di fornire informazioni utili per identificare e risolvere problemi quando non funziona correttamente. |
Testabilità | Misura la facilità con cui creare criteri di test per il sistema e i suoi componenti. | |
Qualità degli utenti | Usabilità | Definisce in che misura l'applicazione soddisfa i requisiti dell'utente e del consumatore essendo intuitiva. |
Qualità dell'architettura | Correttezza | Responsabilità per soddisfare tutti i requisiti del sistema. |
Qualità non runtime | Portabilità | Capacità del sistema di funzionare in diversi ambienti informatici. |
Integralità | Capacità di far funzionare correttamente insieme componenti sviluppati separatamente del sistema. | |
Modificabilità | Facilità con cui ogni sistema software può adattarsi alle modifiche al proprio software. | |
Attributi di qualità aziendale | Costo e programma | Costo del sistema rispetto al time to market, durata prevista del progetto e utilizzo del legacy. |
Commerciabilità | Uso del sistema rispetto alla concorrenza sul mercato. |