Progettazione DEL Software PDF

Preview

Summary

Appunti su Progettazione del software...

Description

Vantaggi: Fornisce una analisi piu profonda e sofisticata dei punti di forza e di debolezza di un’architettura. Svantaggi: Piu’ complesso e costoso di presentazioni e revisioni;

Se i partecipanti non sono preparati i benefici sono scarsi.

PROTOTIPI E PROOF OF CONCEPT I prototipi sono utili per ridurre i rischi tecnici. Si usa un prototipo che e’ un sottoinsieme funzionale del sistema; Proof of concept e’ un codice che ha lo scopo di dimostrare la fattibilita’ di un elemento rischioso dell’architettura proposta Vantaggi: Forniscono prove concrete sulla validita’ delle decisioni tecniche e quindi una dimostrazione utile Svantaggi: Costosi da creare e richiedono tempo. Vanno utilizzati solo per le decisioni importanti. SISTEMA SCHELETRO Rappresenta la forma definitiva della validazione di un’architettura. Inizia con una prima versione dello scheletro del sistema che contiene solo un nucleo minimale delle funzionalita’ tale da provare la bonta’ dell’architettura. Vantaggi: La miglior forma di validazione possibile. Puo’ essere riutilizzato anche dopo la validazione Svantaggi Costosa e richiede esperienza e capacita’ di sviluppo notevoli

SAAM E ATAM SAAM e’ il capostipite dei sistemi di validazione basati sugli scenari. Analizza un’architettura rispetto alla modificabilita’ nelle sue forme (ad es. portabilita’, estensibilita’ integrabilita’) e alla copertura funzionale ATAM e’ un’estensione di SAAM per valutare anche importanti qualita’ come prestazioni, sicurezza, disponibilita’. Valutazione e’ condotta in 4 fasi: Partnership and preparation Initial Evaluation Complete Evaluation

Follow-up PUNTI DI RISCHIO , NON RISCHIO, SENSIBILITA’ E COMPROMESSO. Sono importanti da definire nel corso della validazione di una architettura Punti di rischio: importante identificare le decisioni che potrebbero creare problemi futuri in qualche attributo di qualita’ Punti di non rischio: decisioni che promuovono la qualita’ che aiutano a raggiungere gli obiettivi di business Punti di sensibilita’: proprieta’ di uno o piu’ componenti o decisione di un progetto che e’ critica per raggiungere una certa qualita’ Punti di compromesso: (tradeoff point) decisione di progetto che richiede un compromesso tra piu’ qualita’. Si tratta delle decisioni di progetto piu’ critiche. RISULTATI DI UNA VALIDAZIONE Importanti registrare i risultati di una validazione per evitare incomprensioni sule decisioni prese tramite: verbali o resoconti log delle decisioni rapporti di valutazione Il risultato di una validazione e’ la firma formale dei documenti (ad es. per accettazione formale dell’architettura)

TATTICHE ARCHITETTURALI – DISPENSA ASW 310 – VIDEOLEZIONE 17 Il progetto di un sistema consiste di un insieme di decisioni di progetto, alcune sostengono i requisiti funzionali, mentre altre sostengono requisiti di qualita’ I principali approcci architetturali che guidano il raggiungimento degli attributi di qualita’ sono:

-

Tattiche architetturali Stili architetturali (Uno stile architetturale e’ uno stile di decomposizione arch. che di solito sostiene un certo numero di qualita’ mediante l’applicazione di piu’ tattiche)

Una tattica arch. e’ una decisione di progetto che influenza il controllo di un attributo di qualita’, oppure detto in un altro modo: una tattica e’ una trasformazione architetturale che ha effetto sul comportamento del sistema rispetto ad un particolare attributo di qualita’. Le tattiche descrivono delle decisioni progettuali che sono state effettivamente applicate con successo in numerose situazioni e che possono essere applicate in nuove situazioni. Sono piu’ semplicie piu’ facili da comprendere poiche’ influenzano il controllo di un singolo attributo di qualita’. Hanno come scopo di raffinare il progetto di un’architettura, ad esempio basato inizialmente su stili architetturali. Qundi costituiscono un approccio a grana piu’ fine rispetto agli stili arch. Ciascuna tattica controlla in modo diverso il raggiungimento di un attributo di qualita’ L’applicazione di una tattica ha impatto su uno o piu’ elementi architetturali, e/o su una o piu’ relazioni tra elementi, presenti in una o piu’ viste architetturali. L’applicazione di una tattica puo’ avere effetti collaterali, positivi o negativi, sul raggiungimento di altri attributi di qualita’. Una strategia architetturale e’ realizzata attraverso una collezione di tattiche. A CHE PUNTO SIAMO? Abbiamo identificato gli scenari architetturali Abbiamo scelto uno o piu’ stili architetturali in grado di sostenere gli scenari piu’ rilevanti Abbiamo applicato questi stili nelle varie viste e, identificato in ciascuna vista un insieme di elementi architetturali e un insieme di relazioni e interazioni tra essi Quindi entrano in gioco le tattiche affinche’ l’architettura sostenga questi scenari prioritari. Possiamo selezionare una o piu’ tattiche e ogni tattica e’ una scelta di progetto.  TATTICHE PER LE PRESTAZIONI Le prestazioni hanno a che fare con il tempo di esecuzione, ovvero con la capacita’ del sistema a far fronte a requisiti temporali. Consideriamo le tattiche per le prestazioni che hanno l’obiettivo di controllare il tempo di risposta a un evento. Il tempo di riposta di un evento e’ costituito da : -tempo di elaborazione - tempo di attesa , tempo in cui la computazione e’ bloccata in attesa di risorse o in attesa di sincronizzazione .

2

-

-

-

-

-

categorie di tattiche per le prestazioni : 1. Control resource demand (controllare la richiesta di risorse): queste tattiche cercano di ridurre il tempo dedicato alla gestione di un evento ad esempio migliorando l’algoritmo. 2. Manage resources : queste risorse operano dal lato dell’offerta delle risorse, per gestire elaborazioni in modo piu’ efficiente. Tattiche rivolte a ridurre le risorse richieste per elaborare un evento: Increase re source efficiency,(migliora l’efficienza) attraverso il miglioramento dell’algoritmo o scambiando tempo con un'altra risorsa (es. memorizzazione dei dati intermedi per un loro successivo ricalcolo) Reduce overhead . Esempi di overhead possono essere comunicazioni direte, trasformazione del formato dei messaggi , oppure cifratura. Si puo’ ridurre il tempo di risposta eliminando gli intermediari, trovando cmq sempre un compromesso. Bound execution times: in alcuni casi si puo’ accettare un risultato che ha un’approssimazione prevedibile, quindi e’ possibile porre un limite al tempo di esecuzione che puo’ essere dedicato ad elaborare un evento. Es. limitare il numero di iterazioni di una algoritmo iterativo. Utilizza risorse migliori: processori, memorie,reti per ridurre il tempo di risposta. Aumento dei costi. Introduci la concorrenza: gestendo attivita’ diverse di questa elaborazione in parallelo in modo concorrente, ad esempio usando thread diversi. Introduci più copie della computazione e/o dei dati: replicazione delle risorse riducendo la contesa che si verificherebbe utilizzando risorse singole. Es. replicazione di un server insieme ad un meccanismo di load balancing. E’ anche possibile replicare dei dati, e consentirne l’accesso concorrente ad esempio, mediante meccanismi di caching o di data replication Schedula l’utilizzo delle risorse: in caso di contesa delle risorse, l’arbitraggio e la schedulazione delle stesse puo’ consentirne un utilizzo piu’ efficiente. E’ possibile schedulare processori, buffer e reti, attraverso differenti tipi di strategie quali FIFO, fixed priority, dynamic priority, static scheduling.

 TATTICHE PER LA MODIFICABILITA’ Tattiche per controllare il tempo e il costo per implementare, testare e deployare un cambiamento atteso. La modificabilità è un attributo di qualità che riguarda il costo dei cambiamenti e si riferisce alla facilità con cui un sistema software può accomodare cambiamenti. Tipi di cambiamenti:   

per aggiungere, modificare o rimuovere funzionalità per correggere difetti e per migliorare alcune qualità per migliorare l’esperienza d’uso del sistema

per abbracciare nuove tecnologie, nuove piattaforme, nuovi protocolli e standard 

per far interoperare sistemi diversi – anche se non sono mai stati progettati per farlo

Ipotizziamo che l’unità di modifica sia una “responsabilità” .Una responsabilità è un’azione, una decisione da prendere o una conoscenza da mantenere da parte di un sistema software o di un suo elemento.

Quindi il ragionamento che dobbiamo fare e’ il tipo di contributi al costo (medio) per la modifica di una responsabilità R. In particolare consideriamo il costo: per la modifica dell’elemento Er responsabile di R per la modifica degli elementi a cui si propaga questa modifica Infine dobbiamo considerare il costo del deployment Il costo di queste modifiche dipende da:  coesione dell’elemento ER e degli altri elementi da modificare  accoppiamento verso gli elementi da modificare  dimensione di un modulo puo’ avere un impatto sul costo per modificare il modulo. La coesione è una misura della forza delle relazioni tra le responsabilità di uno specifico modulo E’ anche una misura (inversa) della probabilità che uno scenario di cambiamento che ha impatto su una responsabilità del modulo richieda anche il cambiamento di responsabilità differenti (di altri moduli) L’accoppiamento è una misura della forza delle dipendenze tra moduli Per questo, è anche una misura (diretta) della probabilità che un cambiamento che ha impatto su una responsabilità richieda anche il cambiamento di responsabilità differenti TATTICHE PER AUMENTARE LA COESIONE Le tattiche per aumentare la coesione hanno in genere l’obiettivo di ridurre il numero di moduli sui quali un certo cambiamento si ripercuote direttamente. 1. SEPARAZIONE DI UN MODULO. Separare un modulo per separare le responsabilita’. Quindi le sottoresponsabilita’ possono essere modificate separatamente. Quindi si fa in modo che ciascuno dei cambiamenti previsti abbia una portata limitata. 2. AUMENTARE LA COERENZA SEMANTICA la coerenza semantica si riferisce alle relazioni tra le responsabilità assegnate a un modulo anche con riferimento a un insieme di cambiamenti attesi. ad esempio, siano A e B delle responsabilità che sono coese rispetto ad un qualche criterio, ad esempio funzionale.

TATTICHE PER RIDURRE L’ACCOPPIAMENTO Le tattiche per ridurre l’accoppiamento hanno in genere l’obiettivo di ridurre il numero di moduli sui quali un certo cambiamento si ripercuote indirettamente,

ovvero, moduli le cui responsabilità non vanno cambiate direttamente per realizzare il cambiamento ma si può doverne comunque cambiare l’implementazione per accomodare cambiamenti in altri moduli. Un ripple effect da una modifica è la necessità di effettuare un cambiamento a moduli su cui la modifica non si ripercuote direttamente 1. INCAPSULAMENTO scopo dell’incapsulamento di un elemento A è ridurre la probabilità di propagazione dei cambiamenti nell’elemento A verso altri elementi ciò richiede una separazione netta tra interfacce e implementazione – sulla base di interfacce esplicite e stabili il criterio di decomposizione dell’incapsulamento è quello di isolare ciascun cambiamento atteso in un singolo modulo, per prevenire la propagazione dei cambiamenti ad altri moduli 2. USA UN INTERMEDIARIO un intermediario può rompere la dipendenza tra un elemento A e un elemento B l’intermediario ha lo scopo di gestire le attività associate con la dipendenza il tipo di intermediario da utilizzare dipende dal tipo di dipendenza che si vuole rompere ad esempio, se A produce messaggi e B li consuma, l’uso di un canale di comunicazione può rimuovere la conoscenza di A sul fatto che il consumatore dei suoi messaggi sia B alcuni esempi di intermediari un design pattern per ridurre la dipendenza dai servizi – ad es., facade, proxy, adapter, bridge, mediator, ... un broker o un servizio di directory una factory, per ridurre la dipendenza dall’esistenza. Restrict dependencies si tratta di un caso speciale dell’uso di un intermediario questa tattica consiste nel rimuovere una dipendenza relativa a una necessità di comunicazione, incanalando questa comunicazione in un intermediario ad esempio, applicata nell’architettura a strati stretta. 3. REFACTOR  questa tattica generalizza la tecnica del refactoring (sviluppata nel contesto dei metodi agili) ad un contesto architetturale  in generale, ha lo scopo di ridurre duplicazioni nel codice (che sono una forma di accoppiamento)  ad esempio, quando un cambiamento ha impatto su due moduli  – perché hanno delle responsabilità duplicate (almeno in modo parziale) in questo caso, queste responsabilità vanno estratte dai due moduli e messe a “fattor” comune la co-locazione di responsabilità comuni riduce l’accoppiamento – dato che l’accoppiamento misura le dipendenze tra moduli differenti 4. ASTRAI I SERVIZI COMUNI un modo per sostenere il riuso è realizzare moduli specializzati che forniscono servizi comuni ad altri moduli se questi servizi comuni sono a un livello opportuno di astrazione (ovvero, implementati in una forma generale, più generale che non rispetto ai singoli utilizzi), allora è sostenuta anche la modificabilità Esempio: un browser web – che supporta plug-in dedicati alla presentazione di contenuti specifici --- cambiamenti attesi: cambiamenti (miglioramenti) nelle funzionalità base del browser devono poter essere fruite dai diversi plug-in – e non devono richiedere un loro aggiornamento - il browser può fornire ai suoi plug-in un insieme di servizi atomici comuni – che i diversi plug-in possono utilizzare per realizzare funzionalità più complesse o specifiche . - questo avverrà più facilmente se i servizi offerti dal browser sono effettivamente comuni e astratti, ovvero indipendenti da ogni specifico (plug-in) consumatore dei servizi. TATTICHE PER POSTICIPARE IL COLLEGAMENTO

Finché c’è un’opportuna preparazione, più tardi nel ciclo di vita si può applicare una modifica, minore è il suo costo. Quindi vi sono tattiche per effettuare modifiche: al tempo della codifica al tempo della compilazione al tempo del rilascio all’inizializzazione a runtime  TATTICHE PER LA DISPONIBILITA’

La disponibilita’ e’ la proprietà di un sistema di essere pronto a svolgere i compiti quando gli vengono richiesti. E’ interessata ai guasti e ai fallimenti di un sistema un fallimento si verifica quando il sistema non eroga più un servizio in modo coerente con la sua specifica i fallimenti sono osservabili esternamente dagli utenti del sistema . Si dice che c’è un’interruzione (outage) di servizio. Il periodo di tempo in cui il sistema è fuori servizio per un  outage è chiamato un downtime un guasto è una problematica interna al sistema – ad es., la rottura di un disco o un nodo, o un errore di programmazione un fallimento è causato da un guasto (o una loro combinazione) anche se ogni guasto ha la potenzialità di causare un fallimento, non sempre un guasto produce un fallimento un sistema può essere tollerante a un certo guasto (o una loro combinazione) se il verificarsi di quel guasto non provoca un fallimento del sistema La misura della disponibilità è definita come un rapporto percentuale disponibilità = periodo di tempo in cui il sistema è operativo / periodo di riferimento Per business continuity (BC) si intende la capacità di un’organizzazione di continuare a esercitare il  proprio business a fronte di guasti o eventi catastrofici. Con riferimento all’hardware, la disponibilità di un componente può essere calcolata come disponibilità = MTBF / MTBF + MTTR Mean Time Between Failures Mean/Maximum Time To Repair or Resolve Molte tattiche per la disponibilità hanno l’obiettivo di eliminare punti di fallimento singoli

Consideriamo tattiche per la disponibilità, -

per impedire ai guasti di provocare fallimenti o limitare l’effetto del fallimento e rendere possibile il ripristino

Definiamo un gruppo di protezione per un servizio S come un insieme di nodi di elaborazione (server) dedicati all’erogazione del servizio S In un gruppo di protezione, in un dato momento uno o più nodi sono attivi – ovvero, sono utilizzati per erogare effettivamente il servizio ai client del servizio possono essere anche presenti altri nodi, che sono delle riserve ridondanti il caso più semplice di gruppo di protezione è la ridondanza 1+1  un nodo attivo e un nodo di riserva. Attenzione, una riserva per un servizio S potrebbe essere completamente inattiva, oppure impegnata nei confronti del servizio S – ma non utilizzata direttamente dai client del servizio – oppure impegnata nell’erogazione di altri servizi S’, S’’, ...

TATTICHE PER IL RIPRISTINO DEI GUASTI: RIDONDANZA ATTIVA (HOT SPARE) si riferisce a una configurazione in cui tutti i nodi (attivi o riserve) in un gruppo di protezione ricevono ed elaborano in parallelo gli stessi identici eventi – pertanto sono normalmente tutti nello stesso stato (ovvero, sono sincronizzati) se si verifica un guasto in un nodo attivo, uno dei nodi di riserva lo può sostituire immediatamente, poiché è già sincronizzato il downtime del sistema può essere nell’ordine dei millisecondi RIDONDANZA FREDDA (COLD SPARE) si riferisce a una configurazione in cui i nodi di riserva di un gruppo di protezione sono tenuti fuori servizio fino a quando non è necessaria la sostituzione di un nodo attivo i nodi di riserva sono configurati per poter sostituire altri nodi che potrebbero fallire quando si verifica un guasto in un nodo attivo, il nodo di riserva viene avviato, eventualmente configurato, e il suo stato aggiornato/sincronizzato (vedi ad esempio Rollback) – solo allora può sostituire il nodo che è fallito il downtime del sistema può essere nell’ordine dei minuti RIDONDANZA PASSIVA (WARM SPARE) solo i nodi attivi del gruppo di protezione ricevono ed elaborano gli eventi di input – ai nodi attivi viene data anche la responsabilità di notificare periodicamente i nodi di riserva con i cambiamenti di stato che si sono verificati se si verifica un guasto in un nodo attivo, uno dei nodi di riserva  lo può sostituire – ma solo dopo che il suo stato è stato opportunamente aggiornato/sincronizzato. E’ un compromesso (affidabilità/complessità) tra le due tattiche precedenti – il downtime può essere nell’ordine dei secondi

PROGETTARE CON I DESIGN PATTERN LEZ.13 Un pattern software è una soluzione provata e ampiamente applicabile a un particolare problema di progettazione che è descritta in una forma standard, in modo che possa essere facilmente condivisa e riusata Tipi di pattern software pattern GRASP

design pattern pattern architetturali idiomi di programmazione( Un idioma è un pattern di basso livello, specifico di un linguaggio di programmazione) Un design pattern è la descrizione di classi e oggetti che comunicano, personalizzati per risolvere un problema generale di progettazione in un contesto particolare. Detto in altro modo: un design pattern fornisce uno schema per raffinare gli elementi di un sistema software o le relazioni tra di essi [SSA] descrive una struttura ricorrente di elementi di progetto interconnessi, che risolvono un problema di progettazione generale in un contesto particolare in particolare, i design pattern possono essere usati nell’ambito della progettazione di dettaglio di singoli elementi architetturali – nonché delle interazioni tra di essi Esempi di design pattern Singleton, Adapter, Proxy, Observer, ...

Tipi di design pattern strutturali creazionali comportamentali...