Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Transcript

1 Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A Progettazione OO E. TINELLI

2 Punto di Partenza Il modello di analisi E una rappresentazione minima del sistema, sufficiente a catturare i requisiti e la logica essenziale del sistema Un buon modello di analisi (modello logico) Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Un modello di analisi contiene: Casi d uso (UC) Diagramma delle Classi di analisi Diagrammi di interazione che rappresentano il comportamento dinamico dettagliato negli UC tracciabilità: fra requisiti utente, fra requisiti utente e requisiti di sistema, fra ogni req. funzionale e le classi che lo realizzano, ecc. E. TINELLI Ingegneria del Software A. A

3 Progetto OO Progettazione di un sistema: rappresenta la fase in cui vengono presi in considerazione i requisiti non funzionali (usabilità, affidabilità, performance, manutenibilità, scalabilità, integrazione con altri sistemi, ecc.) e che porta alla definizione l architettura di un sistema : l ANALISI si concentra sul COSA (aspetti funzionali); Il PROGETTO si concentra sul COME (aspetti non funzionali). Occorre rielaborare il frutto dell analisi, tenendo in considerazione le possibilità offerte dal paradigma object oriented (polimorfismo, ereditarietà, incapsulamento, ecc.), ed individuare una struttura ad oggetti che rappresenti in modo efficace e pertinente il dominio applicativo. Il modello di progetto: contiene: Layer e Sottosistemi, Classi di design definisce completamente le dipendenze, le associazioni (ass./compos./aggreg.), le molteplicità, le generalizzazioni fra le diverse classi per le operazioni definisce la Signature completa: nome operazione, tipo di ritorno, parametri, visibilità, se è di istanza o di classe (statica) per gli attributi definisce: nome, tipo, valori iniziali o di default, visibilità E. TINELLI Ingegneria del Software A. A

4 È necessario mantenere due modelli? Esistono varie strategie: dal rifinire il doc di analisi in modo da diventare doc di progetto a mantenere i due modelli separati e sempre sincronizzati Fattori da considerare: Dimensione, tipologia e tempo di vita del progetto Necessità di introdurre nuove risorse Comprendere il funzionamento del sistema anche a distanza di mesi pianificare interventi di manutenzione e migliorie Verificare che le funzionalità del sistema soddisfino e corrispondano ai requisiti dell utente E. TINELLI Ingegneria del Software A. A

5 Evoluzione delle Classi di Analisi Una Classe di Analisi può diventare: Una singola classe di Design Una parte di una classe Una classe aggregata Un gruppo di classi che ereditano da una stessa classe Un gruppo di classi funzionalmente relazionate Una relazione Una Classe di Analisi potrebbe non essere più necessaria in Progettazione Una Relazione fra Classi di Analisi può diventare una Classe E. TINELLI Ingegneria del Software A. A

6 Evoluzione delle Classi di Analisi Boundary ed Entity Le Classi Boundary diventano Form, WebForm, WebService, controlli grafici, interfacce a sottosistemi, o classi wrapper per dispositivi hardware Le Classi Entity rappresentano tipicamente oggetti persistenti (su DB o altro) la loro evoluzione dipende da come verranno modellate e da una serie di altri parametri: Attributi e loro legami Operazioni sulle Entity Dipendenze con altre parti del sistema Molto spesso bisogna modellarle cercando di ridurre al minimo la dipendenza da specifici modelli di persistenza E. TINELLI Ingegneria del Software A. A

7 Evoluzione delle Classi di Analisi Control Queste classi rappresenteranno puri oggetti software Sono le classi più difficili da progettare Sono responsabili della gestione dei flussi di eventi di UC e coordinano molte azioni Gli oggetti control incapsulano la logica che non è relativa alle interfacce utente o ai dati e che viene indicata come Business Logic La La progettazione delle classi Control richiede spesso l uso l uso e la la conoscenza di di Pattern di di vario livello che che possono migliorare la la struttura statica E. TINELLI Ingegneria del Software A. A

8 Classificazione dei pattern SW Cluster di pattern: raggruppamento per area di applicazione Livello di astrazione: Pattern architetturali: descrivono lo schema organizzativo della struttura che caratterizza un sistema software, individuano le parti del sistema a cui sono associate responsabilità omogenee e le relazioni che esistono tra i diversi sottosistemi (esempio: layering). Design pattern: costituiscono soluzioni sperimentate a problemi concreti, utilizzabili in contesti applicativi differenti riporta la descrizione di un problema noto e propone allo stesso tempo una soluzione elegante. Pattern di implementazione (idiomi): descrivono le modalità implementative da utilizzare per risolvere problematiche di sviluppo sfruttando in modo mirato le caratteristiche peculiari di una particolare piattaforma (per esempio, il.net Framework). E. TINELLI Ingegneria del Software A. A

9 Principi di progettazione Modularità il software viene suddiviso in più componenti (moduli) che vengono integrati per soddisfare i requisiti del problema Non si deve eccedere nella modularizzazione poiché la semplicità di ognuno dei moduli produrrà un aumento della complessità di integrazione La modularità facilita la pianificazione dello sviluppo SW, la manutenzione ed il collaudo del sistema Incapsulamento Incapsulamento delle informazioni - le informazioni di una classe sono modificabili solo dalle operazioni della classe stessa, i.e. non sono direttamente accessibili dall esterno Incapsulamento dell implementazione - i dettagli dell implementazione interna non sono colti all esterno, i.e. un attributo può essere implementato in un modo ed essere percepito in un altro all esterno N.B. L uso delle classi, di per sé, non garantisce l incapsulamento Riuso Ereditarietà Progettazione per componenti E. TINELLI Ingegneria del Software A. A

10 Classi di Progettazione Le classi di progettazione sono classi le cui specifiche sono talmente complete da poter essere implementate Una classe di progettazione è ben formata se rispetta le seguenti caratteristiche: completezza e sufficienza una classe è completa se fornisce ai suoi clienti tutto ciò che essi si aspettano ed è sufficiente se tutti i suoi metodi sono finalizzati esclusivamente alla realizzazione delle sue responsabilità; essenzialità i metodi devono essere progettati per offrire un unico servizio primitivo e atomico (può essere violato solo per aumentare le prestazioni del sistema); massima coesione ogni classe deve modellare un unico concetto astratto con un insieme di responsabilità molto correlate tra loro; minima interdipendenza una classe deve essere associata all insieme minimo di altre classi che le consente di realizzare le proprie responsabilità (all interno di un package l interdipendenza può essere alta). E. TINELLI Ingegneria del Software A. A

11 Importanza delle interfacce - sottosistemi L'idea è quella di separare le specifiche di una funzionalità (l'interfaccia) dall'implementazione della stessa da parte di un classificatore, quale una classe poiché l'interfaccia definisce solo un contratto che viene implementato dal classificatore. Le interfacce sono efficienti e utili nella modellazione dei sottosistemi. E. TINELLI Ingegneria del Software A. A

12 Dipendenze tra package Un package è un meccanismo per organizzare elementi simili in gruppi Usi Organizzare il modello in via di sviluppo Unità di gestione della configurazione Ridurre la complessità del sistema (modularità) E. TINELLI Ingegneria del Software A. A

13 Progettazione dell interfaccia utente La progettazione dell interfaccia utente include: Elementi estetici (elementi grafici, colori, meccanismi di interazione) Elementi economici (posizionamento delle informazioni, navigazione dell interfaccia utente) Elementi tecnici (modello degli utenti, componenti riutilizzabili) I passi della progettazione Sulla base delle specifiche dei requisiti definire gli oggetti dell interfaccia e le relative operazioni Definire le azioni degli utenti che modificano lo stato dell interfaccia Rappresentare ogni stato così come si presentaerà all utente finale Fattori da considerare per garantire l usabilità dell interfaccia utente: Tempi di risposta Sistemi guida Messaggi di errore Menu e comandi E. TINELLI Ingegneria del Software A. A

14 Progetto di Sistema Progetto dell Architettura - si occupa della selezione dello stile architetturale da adottare e della formalizzazione del sistema in componenti: 1) delle loro interfacce di comunicazione e 2) della modalità di dispiegamento (deployment). Sono prese in considerazione: le capacità e i vincoli (dal documento dei requisiti) i modelli (dalle specifiche dei requisiti) - classi e casi d uso Progetto di Dettaglio - si occupa del raffinamento/completamento dei modelli di progetto (es. classi), della definizione dei confini del sistema mediante: 1) raffinamento delle entità; 2) controllo dei flussi dei processi di business; 3) gestione degli accessi a servizi esterni. Sono coinvolti: i vincoli e le capacità (dal documento dei requisiti) i modelli (dalle specifiche dei requisiti) - classi, casi d uso, diagrammi di sequenza principi di progettazione e soluzioni (es. design patterns) Progetto dei Dati - si occupa della formalizzazione degli archivi per la persistenza dei dati a supporto del sistema: Database (relazionali, OO, relazionali-oo); File System (xml, csv,ecc.). Sono presi in considerazione: i requisiti informativi (dal documento dei requisiti) le classi di analisi(dalle specifiche dei requisiti) L accesso del sistema ai dati può essere supportato da classi specifiche - Classi dbinterface E. TINELLI Ingegneria del Software A. A

15 Indice struttura doc di progetto Scelte progettuali Architettura Definizione dell architettura (stile/i architetturali) Diagramma delle Componenti Descrizione delle interfacce Diagramma di Configurazione Progettazione interfaccia utente Progetto di Dettaglio Diagramma delle Classi Specifiche delle Classi Pattern utilizzati Diagrammi comportamentali per gli scenari, processi, classificatori più complessi Progetto dei Dati Database Modello E-R Progettazione Logica & regole di business Progettazione fisica (indici, trigger, stored procedure, ecc.) File System (eventuale) Descrizione File Appendice E. TINELLI Ingegneria del Software A. A