Contenuti - La progettazione - Progettazione architetturale - Progettazione di dettaglio - Qualità della progettazione - Approfondimento: viste multiple Progettare prima di produrre Dall’analisi alla progettazione Dall’uso alla (ri-)progettazione Obiettivi della progettazione - Soddisfare i requisiti di qualità fissati dal committente e dal fornitore - Definire l’architettura del prodotto - Impiegando componenti con specifica chiara e coesa - Realizzabili con risorse date e costi fissati - Con struttura che faciliti cambiamenti futuri dovuti a modifica od evoluzione dei requisiti - L’architettura non è il fine, ma lo strumento per il raggiungimento degli obiettivi di progetto Definizione di architettura - La decomposizione del sistema software in componenti costitutive - L’ organizzazione di tali componenti - Organizzazione = ruoli, responsabilità ed interazioni - Le interfacce necessarie all’interazione tra tali componenti - I modelli di composizione delle componenti - Criteri, limiti, vincoli Problemi di progettazione – 1 - Problemi strutturali ? architettura interna - P.es.: sistema distribuito vs. sistema centralizzato - Problemi infrastrutturali ? architettura esterna - P.es.: piattaforma di sistema operativo; supporto DBMS; sistema di comunicazione e trasporto dati; sistema di interfaccia utente - Problemi tecnologici - P.es.: linguaggi di programmazione e strumenti di sviluppo associati - Problemi realizzativi - P.es.: componenti acquistabili, riusabili o da sviluppare ex-novo - Problemi tecnici - P.es.: scelte algoritmiche Problemi di progettazione – 2 - Problemi organizzativi - Quantificazione del lavoro - P.es.: stimata mediante COCOMO - Uso delle risorse e ripartizione dei compiti - P.es.: piano di progetto - Allestimento dell’ambiente di lavoro - P.es.: sviluppo, test, versionamento, configurazione Strumenti di progettazione Progettazione architetturale - Dominare la complessità del sistema - Organizzare il sistema in componenti di bassa complessità - Secondo la logica del “divide et impera” - Per ridurre le difficoltà di comprensione e realizzazione - Identificare schemi realizzativi e componenti riusabili - Riconoscere le componenti terminali - Che non necessitano di ulteriori trasformazioni - Il beneficio ottenibile non vale il costo di decomposizione - Eccessiva esposizione di dettagli ? troppe assunzioni sul funzionamento - Cercare un buon bilanciamento - Più semplici le componenti più complessa la loro interazione Strategie di decomposizione Schemi architetturali Linguaggi di descrizione architetturale - Descrizione degli elementi - Componenti, porte e connettori (p.es. diagramma delle classi in UML) - Descrizione dei protocolli di interazione - Tra componenti, tramite connettori - Supporto ad analisi - Consistenza (analisi statica ad alto livello) - Conformità ad attributi di qualità - Comparazione tra soluzioni architetturali diverse Progettazione di dettaglio: attività - Definizione delle unità realizzative (moduli) - Un carico di lavoro realizzabile dal singolo programmatore - Un “sottosistema” definito (una componente terminale od un aggregato di esse) - Un insieme di funzionalità affini (un modulo package) - Non necessariamente nel senso Java! - Specifica delle unità - Definizione delle caratteristiche significative - Quelle che occorre fissare in fase di progettazione - Dal nulla o tramite specializzazione di componenti esistenti Progettazione di dettaglio: obiettivi - Assegnare unità logiche a componenti fisiche - Anche per organizzare il lavoro di programmazione - Produrre la documentazione necessaria - Perché la programmazione possa procedere senza bisogno di ulteriori informazioni - Per attribuire i requisiti alle unità (tracciamento) - Per definire le configurazioni ammissibili del sistema - Definire gli strumenti per le prove di unità - Casi di prova e componenti ausiliarie per le prove e l’integrazione Progettazione orientata agli oggetti Riuso Qualità della progettazione Incapsulazione - Componenti “black box” - Fornitori e clienti di funzionalità (relazione d’uso) - È nota solo la loro interfaccia (dichiarazione dei servizi) - Sono mantenuti nascosti - Algoritmi usati - Strutture dati interne - Vantaggi di un alto grado di incapsulazione - Nessuna assunzione sul funzionamento della componente - Maggiore manutenibilità - Maggiori opportunità di riuso Coesione - Proprietà endogena di componente - Funzionalità “vicine” devono stare nello stesso componente - Vicinanza per tipologia, algoritmi, dati in ingresso ed in uscita - Vantaggi di un elevato grado di coesione - Migliora la manutenibilità e facilita il riuso - Riduce il grado di dipendenza fra componenti - Facilita la comprensione dell’architettura del sistema - Chi fa cosa Accoppiamento - Proprietà esogena di componenti - Quanto le componenti si usano fra di loro - U = M x M massimo accoppiamento - U = 0 minimo accoppiamento - Metriche: Fan-in e fan-out strutturale - SFIN elevato è indice di riuso (utilità) - SFOUT elevato è indice di accoppiamento (dipendenza) - Buona progettazione - SFIN delle componenti (elevato) - SFOUT del sistema (elevato) * Bisogno del 100% delle sue componenti Attributi di architettura - Capacità prestazionale - Maggiore località delle operazioni riduce l’onere di comunicazione tra sottosistemi - Sicurezza da intrusioni - Architettura a livelli gerarchici (information hiding) - Le parti più critiche nei livelli più interni - Sicurezza da malfunzionamenti gravi - Componenti critiche isolate e protette da possibili interferenze esterne - Continuità di servizio (availability) - Presenza di componenti ridondanti - Manutenibilità - Componenti a grana fine, con fan-out basso o nullo Architetture software: viste multiple - Viste diverse per scopi diversi - Committente: per avere una visione d’insieme del prodotto - Fornitore: per capire i confini del proprio lavoro - Analista: per individuare i vincoli ed i rischi tecnologici - Progettista: per localizzare i confini della propria attività - Architetto: per ragionare circa evoluzione e riuso Le 4 viste di Soni, Nord e Hofmeister - Concettuale - Componenti e connettori: problemi visti in termini di requisiti e di dominio - Moduli - Sottosistemi ed interfacce: problemi visti in termini strategici e tecnologici - Esecuzione - Entità a tempo d’esecuzione: problemi di prestazioni e di risorse - Codice - Sorgenti ed eseguibili: problemi di costruzione e di evoluzione L’architettura nel RUP - 1 - Rational Unified Process (RUP, “4+1 view”) - Quattro viste - Logica, Realizzativa, Processuale ed Operativa - Quinta vista d’appoggio alle 4 precedenti: casi d’uso - Riferimento per analisi e verifica - Cattura le interazioni più importanti del sistema (da 1 dei 4 punti di vista) con il corrispondente contesto - Architettura come espressione astratta dei modelli creati durante l’analisi e la progettazione L’architettura nel RUP - 2 Riepilogo Riferimenti