articola le decisioni di design che determinano le proprietà comportamentali e strutturali primarie di un programma (sistema software). Le decisioni strategiche affrontano preoccupazioni globali, a livello di sistema, e portano le implicazioni più consequenziali. Le decisioni strategiche includono la scelta del paradigma di programmazione (‘programmazione orientata agli oggetti’), lo stile architetturale (‘tubi e filtri’), il framework applicativo (‘Microsoft Foundation Classes’), gli standard di ingegneria del software basati sui componenti (‘Enterprise JavaBeans’), e i principi di progettazione (‘classe base universale’), così come le assunzioni che possono portare al mismatch architetturale (‘Il Softbench Broadcast Message Server si aspettava che tutti i componenti avessero un’interfaccia utente grafica’) e regolarità governate dalla legge (‘ogni classe nel sistema eredita dalla classe C’). A causa delle conseguenze che portano, le decisioni strategiche devono essere prese all’inizio del processo di sviluppo del software e dovrebbero essere stabilite esplicitamente prima di qualsiasi progettazione dettagliata.
Al contrario, le dichiarazioni di progettazione tattica articolano decisioni di progettazione che riguardano un modulo specifico. Le decisioni tattiche spesso descrivono un modello di correlazione tra un insieme di moduli (oggetti, procedure, classi ecc.) e un altro. Intuitivamente parlando, le dichiarazioni tattiche sono “locali” nel senso che il loro scopo è limitato a qualche parte del programma e non al di fuori di esso. Le decisioni tattiche includono la scelta di design pattern (‘Factory Method’), refactorings (‘Replace Conditional With Polymorphism’), e idiomi di programmazione (‘counted pointer’), e di solito sono prese molto dopo le decisioni strategiche di design nel processo di sviluppo del software.
Anche se sono ampiamente d’accordo con la regola generale di globale = strategico e locale = tattico, non dovrebbe essere considerata un assoluto. È possibile che un segmento di un sistema abbia aspetti che influenzano fortemente l’architettura complessiva (giustificando i criteri di importanza di Booch). Questa è la ragione per cui non ritengo che i requisiti funzionali siano design e quelli non funzionali siano architettura.
Arnon Rotem-Gal-Oz, responsabile dell’architettura presso Nice Systems, identifica diversi aspetti dell’architettura nella sua presentazione “Software Architecture”. L’architettura comprende i componenti principali di un sistema; le loro relazioni e interazioni. I dati e il comportamento di questi componenti principali sono rilevanti per l’architettura solo dal punto di vista delle interazioni tra questi componenti. Come Booch, Rotem-Gal-Oz caratterizza l’architettura come le parti più difficili da cambiare del sistema. Come Eden, Kazman e Hirshfeld, definisce l’architettura come le decisioni di design che devono essere prese prima nel processo.
Il valore delle decisioni di design strategiche e fondamentali dovrebbe essere ovvio. Poiché questi aspetti del sistema sono sia difficili che costosi da cambiare, ci dovrebbe essere un notevole incentivo a fare scelte ottimali. Come notato da Kevlin Henney in “What is Software Architecture?” su developerFusion:
La questione non è se un sistema abbia o meno un’architettura, ma se la sua architettura sia buona o meno. Tutti i sistemi hanno un’architettura, intenzionale o accidentale, esplicita o implicita, buona o cattiva – anche i sistemi “senza architettura” hanno un’architettura!
Avendo collegato l’architettura al costo del cambiamento, abbiamo un modo semplice di valutare la qualità dell’architettura. Non è che una buona architettura rende un sistema economico da creare; è che è anche economico da evolvere. In altre parole, una buona architettura è quella in cui l’importanza delle decisioni di progettazione è ridotta al minimo. Si è liberi di cambiare molti aspetti di un sistema senza la paura che tali cambiamenti siano impegnativi, costosi o creino una cascata di bug. Una buona architettura è quindi un’architettura sostenibile.
Data la criticità di queste decisioni di design, ha poco senso lasciarle al caso. È improbabile che un’architettura sostenibile e flessibile emerga organicamente. Saranno necessarie una pianificazione e una coordinazione sufficienti da parte di qualcuno nel ruolo di architetto (indipendentemente dal fatto che il ruolo sia a tempo pieno o parziale). Le decisioni di design localizzate possono poi essere prese all’interno di quel quadro in modo decentralizzato.
Occasione sento la gente che ancora solleva il mantra agile contro il Big Design/Requirements Up Front. Il fatto è che il Manifesto Agile non ha mai detto di nascondere intenzionalmente la testa nella sabbia per quanto riguarda lo scopo del sistema. Era una spinta contro il passare mesi in analisi senza che venisse fuori nient’altro che documenti, ma l’obiettivo era di raggiungere una via di mezzo. Nessuno ha mai detto “no design up-front” o “no requirements up front”.
(Udi Dahan da “A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function