Luca Cabibbo Architettura dei Sistemi Software Scenari e applicazione di scenari dispensa asw160 marzo 2017 By failing to prepare, you are preparing to fail. Benjamin Franklin 1 - Fonti Cervantes, H. and Kazman, R. Designing Software Architectures: A Practical Approach. Addison Wesley, 2016. Chapter 2, Architectural Design [SSA] Chapter 10, Identifying and Using Scenarios [SAP] Chapter 4, Understanding Quality Attributes 2
Obiettivi - Obiettivi e argomenti comprendere gli scenari e le loro applicazioni nell architettura del software Argomenti requisiti architetturalmente significativi scenari applicazione di scenari discussione 3 * Requisiti architetturalmente significativi 4 La progettazione dell architettura di un sistema software comprende un insieme di decisioni di progettazione relative alle strutture del sistema gli elementi del sistema e le loro relazioni queste decisioni devono sostenere gli interessi delle parti interessate questi interessi vanno identificati e chiariti durante la definizione dell architettura purtroppo, le informazioni utili all architetto di solito non sono contenute nei requisiti che vengono identificati inizialmente in particolare, l identificazione dei requisiti si concentra soprattutto sugli aspetti funzionali mentre i requisiti di qualità (più importanti per l architettura) sono spesso ignorati o specificati in modo inadeguato in ogni caso, la definizione dell architettura deve iniziare quando i requisiti sono ancora in evoluzione ma quali sono i requisiti utili per la progettazione dell architettura?
Requisiti architetturalmente significativi La definizione dell architettura si deve concentrare su ciò che è architetturalmente significativo un interesse, un requisito, un problema, un elemento del sistema o una decisione di progetto è architetturalmente significativo/a [SSA] se ha un impatto ampio sulla struttura del sistema o su una sua qualità importante come prestazioni, scalabilità, sicurezza, affidabilità o modificabilità un requisito è architetturalmente significativo [SAP] ASR, architetturally significant requirement se ha/avrà un effetto profondo sull architettura ovvero, l architettura potrebbe essere ben diversa senza quel requisito pertanto, la definizione dell architettura deve concentrarsi soprattutto sui requisiti architetturalmente significativi 5 Driver architetturali I requisiti architetturalmente significativi derivano dai cosiddetti driver architetturali i driver (guide) architetturali sono quelle considerazioni, critiche per il successo del sistema, che costituiscono l input alla progettazione dell architettura che guidano la progettazione e danno forma all architettura tipologie principali di driver architetturali scopo della progettazione attributi di qualità funzionalità primarie altri interessi architetturali vincoli 6
Driver architetturali Tipologie principali di driver architetturali scopo della progettazione perché stai progettando questo sistema? è un prototipo, nuovo sistema o l evoluzione di un sistema esistente? con quel orizzonte temporale e con quali obiettivi di riuso futuro? le risposte a queste domande possono certamente influenzare il modo in cui il sistema viene progettato attributi di qualità requisiti importanti per dare forma all architettura ma come rappresentarli? funzionalità primarie i requisiti funzionali più importanti (ad es., il 10%) guidano le definizione della vista funzionale e forniscono il contesto per la definizione delle rimanenti viste dell architettura 7 Driver architetturali Tipologie principali di driver architetturali altri interessi architetturali ci sono altri interessi importanti ai fini della progettazione dell architettura ma che spesso non vengono identificati (almeno inizialmente) come requisiti ad esempio, relativi al rilascio del software e dei suoi aggiornamenti, all allocazione del lavoro ai team, alla gestione delle configurazioni, al logging e al monitoraggio applicativo, alla gestione della sicurezza vincoli ad esempio, relativi ad altri sistemi con cui il sistema deve interagire, alla scelta delle tecnologie, a legge e regolamenti a cui il sistema deve essere conforme 8
* Scenari I requisiti architetturalmente significativo possono di solito essere espressi utilmente in forma di scenari la descrizione dei requisiti architetturalmente significativi come scenari abilita l applicazione di tecniche basate su scenari che sono tra le più efficaci nelle attività legate alle architetture, come la definizione, la validazione, la comunicazione, lo sviluppo e la verifica di un architettura 9 Casi d uso e scenari Ad esempio, i casi d uso sono una rappresentazione dei requisiti basata su scenari uno scenario di caso d uso è una sequenza specifica di azioni e interazioni tra il sistema e alcuni attori che descrive una particolare storia nell uso del sistema un caso d uso è un insieme di scenari correlati di successo e fallimento che descrivono un attore che usa il sistema per raggiungere uno specifico obiettivo Alcuni processi (come UP) sono guidati dai casi d uso questo vuol dire che diverse attività del processo (in particolare, requisiti, analisi, progettazione, test) possono essere svolte con riferimento all organizzazione dei requisiti in casi d uso e scenari mediante l applicazione di tecniche basate su scenari 10
- Scenari architetturali La nozione di scenario è più generale dei casi d uso Uno scenario architetturale o solo scenario [SSA/1e] è una descrizione chiara e concisa di una situazione che il sistema dovrà probabilmente affrontare nel suo ambiente di produzione insieme a una definizione della risposta richiesta del sistema Uno scenario architetturale o solo scenario [SSA] è una descrizione ben definita di un interazione tra un entità esterna e il sistema che definisce l evento che scatena lo scenario l interazione iniziata dall entità esterna la risposta richiesta del sistema 11 Scenari architetturali Gli scenari architetturali consentono di catturare un ampio insieme di requisiti architetturali ad esempio un particolare insieme di interazioni tra il sistema e i suoi utenti una risposta può essere intesa come un risultato fornito ad un utente ma anche come una trasformazione dei dati conosciuti dal sistema una particolare situazione di picco del carico che potrebbe verificarsi come il sistema risponde a un qualche specifico tipo di guasto un cambiamento (nei requisiti) che il team di sviluppo deve poter effettuare nel sistema ogni altra situazione che il progettista del sistema deve prendere in considerazione 12
Tipi di scenari Due tipologie di scenari architetturali scenario funzionale una sequenza di eventi esterni a cui il sistema deve rispondere ad es., uno scenario di caso d uso scenario di qualità definisce come il sistema deve reagire a un cambiamento nel suo ambiente, esibendo una o più proprietà di qualità Uno scenario rappresenta un requisito specifico in modo non ambiguo e verificabile la verifica è di solito funzionale nel primo caso e quantitativa e misurabile nel secondo caso 13 Esempi Un esempio di scenario funzionale uno scenario di caso d uso il sistema è un sito di commercio elettronico il cliente usa il sistema per inserire gli articoli che vuole ordinare e informazioni sul pagamento il sistema registra l ordine e il pagamento, predispone informazioni per la spedizione degli articoli ordinati, aggiorna inventario e contabilità, invia al cliente una ricevuta dell ordine Un esempio di scenario di qualità uno scenario di modificabilità il sistema è in produzione è richiesto che il sistema debba gestire un attributo in più (che può essere rappresentato nella base di dati come una nuova colonna di una tabella esistente) il sistema deve poter essere modificato in due giorni lavorativi 14
Descrizione di scenari funzionali Descrizione di uno scenario funzionale sommario breve descrizione di ciò che lo scenario dovrebbe illustrare stato del sistema (se significativo) lo stato prima dell occorrenza dello scenario di solito in termini di informazioni memorizzate nel sistema ambiente del sistema osservazioni significative sull ambiente di esecuzione per es., normale oppure degradato stimolo esterno risposta richiesta del sistema 15 Descrizione di scenari funzionali Descrizione di uno scenario funzionale sommario stato del sistema (se significativo) ambiente del sistema stimolo esterno definizione di ciò che causa l occorrenza dello scenario per es., un evento di input o un evento temporale risposta richiesta del sistema descrizione di come il sistema dovrebbe reagire allo scenario, dal punto di vista di un osservatore esterno di solito in termini di risposte fornite e/o di cambiamenti delle informazioni memorizzate nel sistema 16
Esempio Scenario: Incremental Statistics Update Sommario come il sistema gestisce un aggiornamento di una base di dati statistica già esistente Stato del sistema esistono già dati aggregati per le vendite trimestrali a cui le statistiche incrementali si riferiscono Ambiente del sistema il sistema è in esecuzione normale, nell ambiente di produzione Stimolo esterno arriva un aggiornamento relativo a parte delle transazioni di vendita del trimestre precedente, mediante l interfaccia esterna Bulk Load Data Risposta richiesta del sistema i dati entranti devono attivare automaticamente l elaborazione delle statistiche in background, per aggiornare i dati aggregati per il trimestre interessato, per riflettere i nuovi dati i dati aggregati precedenti devono rimanere disponibili fino a quando non sono pronti i nuovi dati aggregati 17 Descrizione di scenari di qualità 18 Descrizione di uno scenario di qualità sommario breve descrizione di ciò che lo scenario dovrebbe illustrare stato del sistema (se il comportamento specificato nello scenario dipende da questo stato) prima dell occorrenza dello scenario di solito in termini di stato complessivo del sistema per es., il livello di carico del sistema e non delle informazioni memorizzate nel sistema ambiente del sistema osservazioni significative sull ambiente di esecuzione per es., l indisponibilità di un certo servizio esterno o il comportamento di una specifica infrastruttura cambiamento dell ambiente comportamento richiesto del sistema
Descrizione di scenari di qualità Descrizione di uno scenario di qualità sommario stato del sistema ambiente del sistema cambiamento dell ambiente spiegazione di ciò è cambiato nell ambiente e che causa l occorrenza dello scenario per es., un guasto o un cambiamento nell infrastruttura, un cambiamento nel comportamento di un sistema esterno, un tentativo di attacco, una specifica richiesta di modifica comportamento richiesto del sistema la descrizione di come il sistema dovrebbe reagire al cambiamento del suo ambiente anche in termini quantitativi 19 Esempio Scenario: Daily Data Update Trebles (triplo) in Size Sommario come il sistema si comporta quando il volume dei dati ricevuti è molto maggiore del volume normale dei dati Stato del sistema esistono già dei dati aggregati, il carico del sistema è leggero Ambiente del sistema il sistema è in esecuzione normale, nell ambiente di produzione i dati arrivano ad un ritmo stabile di 1000-1500 item per ora Cambiamento dell ambiente i dati arrivano improvvisamente ad un ritmo di circa 4000 item per ora Comportamento richiesto del sistema quando inizia l elaborazione giornaliera dei dati, il sistema deve elaborare i dati per un certo tempo massimo prestabilito (e configurabile) a quel punto l elaborazione dei dati deve essere interrotta, devono essere mantenute le statistiche precedenti, e lasciato un messaggio diagnostico sulla console del sistema 20
21 Esempio Scenario: Failure in Summary Database Instance cambiamento dell ambiente nello scrivere le nuove statistiche nella base di dati, il sistema riceve un eccezione (ad es., la base di dati segnala un errore, perché un disco è guasto)... Scenario: Additional Summary Dimension Required cambiamento dell ambiente bisogna gestire una nuova dimensione rispetto alla quale aggregare i dati comportamento richiesto del sistema il team di sviluppo deve essere in grado di aggiungere la caratteristica richiesta con uno sforzo complessivo inferiore a un mese-uomo, senza cambiare la struttura complessiva del sistema - Scenari per attributi di qualità [SAP] propone una descrizione un po diversa uno scenario per un attributo di qualità [SAP] descrive uno specifico ASR per un attributo di qualità è composto da sei parti stimolo un evento che arriva nel sistema ad es., un operazione richiesta da un utente, oppure un attacco sorgente dello stimolo l entità (o attore) che genera lo stimolo risposta l attività intrapresa quando si verifica lo stimolo misura della risposta specifica il requisito in modo quantitativo ambiente il contesto in cui si verifica lo stimolo elaborato parte del sistema soggetta allo stimolo deve essere non ambiguo e verificabile 22
Scenari per attributi di qualità 23 Scenari per attributi di qualità Un esempio di scenario per le prestazioni stimolo arriva un aggiornamento giornaliero di circa 10000 item sorgente dello stimolo esterna al sistema ambiente il sistema è in esecuzione normale elaborato sistema o sottosistema di gestione delle statistiche risposta le statistiche sono aggiornate misura della risposta entro 3-4 ore 24
Scenari per attributi di qualità Inoltre, [SAP] identifica alcune classi di qualità (ad es., disponibilità) e propone possibili valori per i vari parametri della descrizione offre dunque un catalogo di scenari (parametrici) predefiniti 25 Esempio 26
Esempio 27 * Applicazione di scenari Nel processo di definizione dell architettura, gli scenari possono essere utilizzati in modi diversi e nell ambito di attività differenti per identificare, descrivere e organizzare i requisiti architetturalmente significativi per guidare la progettazione dell architettura per descrivere, comunicare e comprendere l architettura per validare l architettura per verificare l architettura 28
Scenari e progettazione dell architettura La progettazione dell architettura può essere guidata da scenari scenari sia funzionali che di qualità che succede durante l esecuzione di uno scenario? quali elementi/componenti/sottosistemi sono coinvolti? come collaborano i vari elementi? l obiettivo è progettare una decomposizione in elementi dell intera architettura del sistema identificare gli elementi, le loro responsabilità e interfacce, e le interazioni tra gli elementi ma come progettare questa decomposizione? quale la natura degli elementi? quali le interazioni ammesse? quali criteri e linee guida? a che cosa è possibile ispirarsi nel progettare questa decomposizione? 29 Scenari e progettazione dell architettura Ma come progettare questa decomposizione? quale la natura degli elementi? quali le interazioni ammesse? quali criteri e linee guida? a che cosa è possibile ispirarsi nel progettare questa decomposizione? alcune intuizioni gli scenari di qualità più importanti guidano la scelta degli stili architetturali rilevanti ciascuno stile architetturale dà indicazioni sul tipo degli elementi e delle interazioni ammesse e inoltre fornisce criteri e linee guida per la loro progettazione di solito, la decomposizione è guidata da un opportuna modellazione del dominio del problema ad esempio, da una modellazione delle attività e/o da una modellazione delle informazioni 30
Scenari e progettazione dell architettura Ma come progettare questa decomposizione? quale la natura degli elementi? quali le interazioni ammesse? quali criteri e linee guida? a che cosa è possibile ispirarsi nel progettare questa decomposizione? ulteriori intuizioni alcuni scenari vengono soddisfatti dall applicazione di uno stile architetturale ma altri richiedono di applicare delle tattiche architetturali la gestione di uno scenario è basata in alcuni casi sull interazione tra soli elementi software ma in altri casi può coinvolgere anche elementi non software come elementi dell ambiente di esecuzione o anche persone 31 Scenari e validazione dell architettura Anche la validazione dell architettura può essere guidata dagli scenari per ciascuno scenario, è importante capire se l architettura consente di gestire in modo adeguato a quello scenario ovvero se sostiene quell attributo di qualità o quella funzionalità in modo opportuno se l architettura non è adeguata, perché e di quanto non lo è? quali sono i compromessi nel sostegno ai diversi attributi di qualità 32
- Tecniche per applicare gli scenari Ci sono vari modi o tecniche per applicare gli scenari per ragionare su come l architettura reagisce/deve reagire allo stimolo che caratterizza lo scenario Attenzione le diverse tecniche descritte richiedono sforzi maggiori o minori e possono essere più o meno efficaci in generale, le tecniche più costose e precise vanno applicate solo nei casi veramente importanti, relativi ad aree di rischio maggiore infatti, non tutti gli scenari sono importanti allo stesso modo 33 - Modelli Modelli (cartacei) uno scenario viene usato durante la creazione di un modello ad es., creazione di uno o più diagrammi di UML alcuni dinamici (diagrammi di interazione) e uno statico (un diagramma delle classi) Conseguenze semplici da creare e comprendere sono modelli inerti, che possono essere solo rivisti ma non possono essere eseguiti né verificati 34
Esempio 35 - Walkthrough Un walkthrough passeggiata o prova (come un prova teatrale) è una presentazione formale, con un uditorio competente e attivo, in cui viene illustrato come i vari elementi del sistema si comportano nella gestione di uno o più scenari per comunicare, valutare e validare dei modelli cartacei simile a una revisione formale di un documento ma l ordine della presentazione è guidato dagli scenari e non dalla sequenzialità del documento Conseguenze può essere efficace nel trovare difetti, dimenticanze e scostamenti dal comportamento desiderato preparazione e organizzazione complessa i risultati effettivi dipendono dalla preparazione dei partecipanti 36
Simulazioni - Simulazioni basate su opportuni modelli matematici ci sono strumenti di modellazione grafica (ad es., UML) che consentono alcune simulazioni ci sono simulatori dedicati ad alcune qualità ad es., prestazioni Conseguenze approccio efficace in alcuni casi, e meno costoso dello sviluppo di prototipi i risultati spesso non possono essere riusati in fasi successive dello sviluppo (un prototipo potrebbe esserlo) i risultati sono realistici? 37 - Prototipazione Prototipazione costruire un prototipo (usa e getta) per verificare se l architettura pensata sia effettivamente in grado di gestire alcuni scenari critici per es., per le prestazioni e la scalabilità Conseguenze può fornire un livello di confidenza elevato da usare nei casi di rischio più elevato costoso 38
- Test del sistema Test del sistema effettivo gli scenari vengono di solito usati come base per pianificare i test di sistema (di accettazione) del sistema reale ogni test è relativo a uno specifico scenario questi test vanno implementati ed effettuati durante tutta l implementazione (iterativa) dell architettura e non solo alla fine della sua implementazione Conseguenze poiché comunque vanno fatti, meglio farlo presto e bene 39 - Uso efficace di scenari Alcune buone pratiche per l applicazione efficace degli scenari identifica un insieme focalizzato di scenari utile trovare molti degli scenari ma è bene concentrarsi su quelli effettivamente più significativi e critici usa scenari distinti molti scenari possono variare tra loro di poco utile identificare gruppi di scenari, con alcuni scenari principali dando minore importanza alle variazioni usa presto gli scenari quando l architettura sta prendendo forma può essere difficile considerare alcuni scenari significativi troppo tardi usa anche scenari di qualità oltre a quelli funzionali usa anche scenari di fallimento coinvolgi le parti interessate 40
* Discussione La definizione e l applicazione di scenari è un modo potente per garantire che un architettura esibisca le funzionalità e i comportamenti desiderati ciascuno scenario rappresenta una specifica situazione che il sistema deve affrontare gli scenari sono utili in molte delle attività della definizione dell architettura consentono di ragionare su quali elementi partecipano alla gestione di un certo scenario, con quali responsabilità e sulla base di quali collaborazioni consentono di correlare gli elementi di più viste architetturali nell ambito della gestione di uno specifico scenario ci sono diverse modi utili di applicare gli scenari più o meno semplici e più o meno efficaci ma di solito con un buon rapporto efficacia/sforzo 41