Il processo di sviluppo software

Corso di Laurea Specialistica in Ingegneria Informatica
Progettazione OO
E. TINELLI
Corso di Ingegneria del Software
A. A. 2008 - 2009
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. 20082008-2009
2
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. 20082008-2009
3
È 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. 20082008-2009
4
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. 20082008-2009
5
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. 20082008-2009
6
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
Laprogettazione
progettazionedelle
delleclassi
classiControl
Controlrichiede
richiedespesso
spessol’uso
l’usoeelala
conoscenza
conoscenzadidiPattern
Patterndidivario
variolivello
livelloche
chepossono
possono
migliorare
migliorarelalastruttura
strutturastatica
statica
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
7
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. 20082008-2009
8
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. 20082008-2009
9
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. 20082008-2009
10
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. 20082008-2009
11
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. 20082008-2009
12
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. 20082008-2009
13
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. 20082008-2009
14
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. 20082008-2009
15