Abbiamo più volte affrontato la questione dei Requisiti Non Funzionali o di Qualità, e affermato la loro fondamentale rilevanza nella definizione dell’Intentional Architecture. Inoltre, abbiamo visto come in Agile sia possibile pensare a delle (Technical) User Story che contemplino gli NFR e come esista una loro congiunzione diretta all’ALM con un occhi particolare a DAD.
A questo punto, cerchiamo di rispondere più in dettaglio ad una semplice domanda che, però, cela una risposta complessa:
“Come catturo opportunamente gli NFR, in modo sintetico e non ambiguo?”
Una soluzione interessante è quella proposta da Bass, Clements e Kazman in “Software Architecture in Practice”, che propone di definire uno specifico attributo di qualità (o meglio di dettagliare quali aspetti di esso afferiscono al contesto/progetto specifico) attraverso un Quality Attribute Scenario.
Quality Attribute Scenario
Nel dettaglio, uno tale scenario è esplicitato attraverso 6 elementi:
- Stimolo (Stimuls), ovvero l’evento che sollecita il sistema;
- Source of Stimuls (Sorgente dello Stimolo), la sorgente da cui proviene lo stimolo;
- Artefatto (Artifact), la parte del sistema sottoposta allo stimolo. Chiaramente può essere l’intero sistema;
- Environment (Contesto), il contesto in cui si verifica lo stimolo;
- Response (Risposta), come il sistema risponde allo stimolo;
- Response Misure (Misura della Risposta), permette di valutare se la risposta del sistema è soddisfacente.
Vediamo un esempio concreto di scenario generale afferente alla requisito di Availability (Disponibilità)
Quality Attribute Scenario for Availability
In cui troviamo:
Elemento |
Possibili Specifiche (nel dettaglio ne verrà selezionato solo uno) |
Source of Stimulus |
Interno/Esterno Persone/Hardware/Software Infrastrutture e Ambienti fisici |
Stimulus |
Fault, Tempi di risposta incorretti, Risposte Incorrette |
Artifact |
Processori, Canali di Comunicazione, Sistemi di Storage, Processi |
Environment |
Esercizio, Startup, Riavvio, In Manutenzione, ecc… |
Response |
Evitare che i fault si tramutino in failure Tracciare il fault: log, notifiche Inibire la sorgente dello stimolo |
Response Measure |
Tempo o relativo intervallo di disponibilità Percentuale di Availability Tempo per individuare un fault e tempo di recovery |
Personalmente ritengo che questo approccio permetta di definire dettagliatamente gli NFR, scrollandogli di dosso quella aleatorietà che spesso gli si associa con affermazioni del tipo “Il Sistema deve essere sicuro!”, prendendo, eventualmente, come riferimento gli attributi esplicitati nello standard ISO 9126 (ISO/IEC 25000 dal 2005).
Una volta definiti gli scenari è possibile passare alla stesura di una prima ipotesi di Intentional Architecture, utilizzando Tattiche e Pattern Architetturali per abbracciare l’insieme degli NFR. Inoltre è possibile definire le (Technical) User Story per il ciclo di sviluppo, o un'altra formalizzazione delle specifiche dipendente dalla metodologia scelta.
La cosa su cui ritengo untile spendere un ulteriore passaggio è che tale approccio si applica sia agli attributi che afferiscono ai componenti e alle loro iterazioni (component-and-connector) sia agli attributi relativi alla definizione statica dell’architettura (modules). Quest’ultimo aspetto non è immediato come quello che più afferisce al funzionamento del sistema, ma è altrettanto fondamentale. Un esempio per tutti è la Modifiability, alias l’attitudine del sistema ad essere modifica e/o adattato.
Modifiability Scenario relativo al cambio della UI
Come si vede dalla figura precedente, l’Environment è “Design Time” e quindi implica uno scenario che afferisce alla specifica fase di definizione della struttura del sistema.