Introduzione
Come parte del processo di analisi, l'architetto sviluppa un diagramma iniziale di località. La vista delle località è
una sintesi delle considerazioni non funzionali e fornisce un contesto per l'indirizzamento del modo in cui i requisiti
non funzionali come l'affidabilità e la capacità vengono risolti.
La pratica di progettazione standard consente il budgeting di capacità, le frequenze di errore permesse e così via.
Questo impegno lavorativo produce un insieme di requisiti ulteriori derivati per ogni elemento di località. Le
caratteristiche della località vengono determinate da questi requisiti. I requisiti e le caratteristiche derivati
vengono riesaminati mentre il partizionamento dei sottosistemi viene determinato e perfezionato (attraverso le
località).
I requisiti integrativi a livello di sistema hanno inoltre un impatto sugli stessi sottosistemi (hardware, software,
persone), con le caratteristiche dei sottosistemi, in combinazione con le caratteristiche della località, per produrre
le caratteristiche di sistema desiderate.
Misurazioni della qualità del servizio
QoS (Quality of service) è una nozione che include aspetti dei requisiti non funzionali. L'elenco di tali
caratteristiche è potenzialmente grande, includendo molte "abilità," come affidabilità, manutenibilità ed
utilizzabilità e possibilmente specialità di progettazione quali la sicurezza, i fattori umani e così via. I problemi
significativi della specialità di progettazione vengono solitamente risolti dagli esperti in tali discipline. I
problemi che capitano spesso all'ingegnere del software e del sistema sono quelli che hanno a che fare con:
-
Prestazioni: come, rispetto al tempo, il sistema esegue le funzioni relative, ossia, la velocità di risposta,
l'analisi, le scadenze.
-
Affidabilità/Tolleranza dell'errore: per quanto tempo il sistema continuerà a eseguire le funzioni richieste prima
di un errore e come affronta gli errori parziali. Il sistema MTBF (Mean Time Between Failure) è una misurazione di
affidabilità.
-
Manutenibilità: quanto semplice è mantenere il sistema in esecuzione e diagnosticare e correggere i problemi nel
sistema. Il sistema MTTR (Mean Time To Repair) è una misurazione di manutenibilità.
Prima della costruzione del sistema, è necessario che l'ingegnere del sistema spesso si basi su modelli del sistema
come modo di definire soluzioni alternative e assegnazioni e budgeting di requisiti non funzionali. Questi modelli
vengono analizzati per verificare quanto incontrano la qualità desiderata dei livelli di servizio ed è qui di possibile
selezionare una soluzione (di solito con un costo come fattore). Tali studi commerciali sono importanti nella
progettazione del sistema a tutti i livelli di perfezionamento. La sintesi delle soluzioni candidate dipende molto
dall'abilità e dall'esperienza dell'architetto. L'analisi di queste soluzioni (attraverso modellazione matematica,
simulazione e così via) dovrebbe essere relativamente meccanica. Anche così, l'affidabilità di queste analisi varierà
in modo considerevole con la validità dei dati di input e la fedeltà dei modelli.
È disponibile un insieme di tecniche per rendere possibile l'analisi dei modelli rispetto alle misurazioni QoS sopra
elencate, ad esempio, RMA (Rate Monotonic Analysis) per l'esame delle prestazioni dei sistemi software integrati
in tempo reale [consultare Klein, M. H., un manuale per professionisti per l'analisi in tempo reale: Guide to Rate
Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993], e Failure Mode Effects and Criticality
Analysis (FMECA), per l'identificazione e la caratterizzazione degli errori dell'hardware e dei rischi della
sicurezza[consultare Kececioglu, Dimitri, Reliability Engineering Handbook, Vol. 2, PTR Prentice Hall, 1991].
Un supporto per questo tipo di analisi viene aggiunto all'UML tramite una fornitura di profili, ad esempio "UML
Profile for Schedulability, Performance, and Time Specification" e"UML Profile for Modeling Quality of Service
and Fault Tolerance Characteristics and Mechanisms." Questi profili (disponibili all'indirizzo web www.omg.org) definiscono le annotazioni per i modelli UML che consentono
loro di essere analizzati per le caratteristiche definite nel profilo e le previsioni quantitative eseguite riguardo
queste caratteristiche, utilizzando varie tecniche e tool per l'analisi dei modelli futuri ed esistenti.
|