Le classi di analisi

Corso di Laurea Specialistica in Ingegneria Informatica
Class Discovery
E. TINELLI
Corso di Ingegneria del Software
A. A. 2008 - 2009
Contenuti
• Classi di analisi: definizione ed esempi
• Tecniche per la definizione delle classi di analisi
• Regole pratiche
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
2
Le classi di analisi (1/2)
• Rappresentano un’astrazione
ben definita nel dominio del
problema e dovrebbero
corrispondere a concetti
concreti del dominio del sistema
(cliente, prodotto, ordine, ecc.)
• Una classe di analisi non deve
essere originata da
considerazioni di progettazione
Articolo_Biblioteca
Numero di catalogo
Data di acquisto
Prezzo
Tipo
Stato
Numero di copie
Acquista()
Cataloga()
Disponi()
Presta()
Ritorna()
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
Attributi
Operazioni
3
Le classi di analisi (2/2)
• Attributi – descrivono una classe ed il suo significato nel dominio del
problema
• Operazioni – definiscono il comportamento di un oggetto e si distingue
tra: operazioni che manipolano i dati; operazioni di calcolo; operazioni
che richiedono lo stato di un oggetto; operazioni che monitorano un
oggetto per verificare un evento.
• Associazione – un modo per rappresentare le proprietà di una classe
N.B. Le proprietà rappresentano le caratteristiche strutturali di una classe
definite mediante due notazioni molto diverse: attributi e associazioni.
Quale scegliere? In generale si usano gli attributi per gli “oggetti valore”
(date, valori booleani, stringhe di caratteri, ecc.) e le associazioni per le classi
più significative o quando possono essere definiti più elementi di quel tipo.
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
4
Esempio 1
Boolean
1
preparato
Ordine
Ordine
*
Associazione
*
NOrdine
dataOrdine
consegna()
chiudi()
Equivalente a …
NOrdine
dataOrdine
preparato
dataConsegna
consegna()
chiudi()
0…1 dataConsegna
Data
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
5
Esempio 2
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
6
Tecniche per la definizione delle classi di analisi
• Analisi nome/verbo
• Analisi Class-Responsibility-Collaborator
• Analisi use case driven – gli scenari sono stati descritti e
numerati Æ portano alla definizione degli oggetti, delle
responsabilità di ogni oggetto e di come gli oggetti
collaborano tra loro
• Analisi Common Class Pattern – linee guida che
considerano la classificazione degli oggetti (es. concetti,
eventi, persone, processi organizzativi, luoghi, ecc.)
• Approccio ibrido – combina gli approcci precedenti (es.
studio del dominio del problema, applicazione delle linee
guida del Common Class Pattern, aggiunta di classi con
l’analisi nome/verbo, verifica delle classi con l’analisi usecase driven, analisi CRC per la fase di analisi e negoziazione)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
7
Analisi nome/verbo
• Analizzando direttamente il linguaggio del problema (i testi)
si individuano i nomi o le frasi nominali (classi o attributi) e
i verbi (responsabilità/operazioni di una classe)
• Problemi:
– Sinonimia e omonimia
– Classi “nascoste”
• Potenziali fonti di informazione:
–
–
–
–
Specifiche dei requisiti
Casi d’uso
Glossario
Documentazione varia (dominio, architettura, ecc.)
• Classificazione delle classi: Irrelevant Class, Relevant Class,
Fuzzy Class
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
8
Analisi nome/verbo - Esempio
• Requisiti relativi ad un sistema che gestisce le Iscrizioni
all’Università:
– Ogni corso di laurea ha corsi obbligatori e corsi facoltativi
– Ogni corso ha un numero di crediti e può appartenere a diversi corsi
di laurea
– Ogni corso di laurea specifica il minimo numero di crediti per laurearsi
– Gli studenti possono combinare dei corsi offerti dalla facoltà in modo
da definire un programma di studio individuale
• Bisogna individuare nomi, frasi nominali, verbi e predicati
verbali
Classi Rilevanti: Corso, Laurea, Studente, Corsi offerti
Classi Fuzzy: Corsi obbligatori, Corsi facoltativi, Programma di studio
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
9
Analisi CRC
• Raccolta di schede che rappresentano le classi suddivise in 3 parti: nome
della classe (e descrizione), le responsabilità ed i collaboratori
• Responsabilità: sono gli attributi e le operazioni rilevanti per la classe
• Collaboratori: le classi che sono necessarie per completare una
responsabilità della classe in oggetto (richiesta di informazioni o richiesta di
azione)
• Una possibile classificazione delle classi:
– Classi per entità – rappresentano in genere elementi che possono essere
memorizzati in un database
– Classi di confine – vengono utilizzate per definire l’interfaccia con cui
l’utente finale interagisce
– Classi di controllo – considerate di solito in fase di progettazione
gestiscono la creazione/aggiornamento di oggetti entità, la comunicazione tra
insiemi di oggetti, la convalida dei dati scambiati, ecc.
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
10
Una buona classe di analisi ha …
• La massima coesione interna
• La minima interdipendenza con altre classi
• Esempio: sistema di commercio elettronico
– La classe CarrelloSpesa avrà responsabilità del tipo:
• Aggiungi un prodotto al carrello
• Rimuovi un prodotto dal carrello
• Mostra i prodotti del carrello
Insieme coeso di responsabilità
– Alla classe CarrelloSpesa posso aggiungere responsabilità quali:
• Verifica la carta di credito
• Accetta il pagamento
• Stampa una ricevuta
??
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
11
Regole pratiche
• Evitare di avere classi troppo piccole o classi troppo complesse
(considerare tra le 3 e le 5 responsabilità per classe) Æ se l’intelligenza
del sistema viene distribuita più uniformemente sulle varie classi si
migliora la coesione del sistema e si facilita la manutenzione
• Le responsabilità di una classe devono esibire lo stesso livello di
astrazione
• Per identificare i collaboratori si possono esaminare 3 relazioni: “fa parte
di”, “è a conoscenza di”, “dipende da”;
• Incapsulazione: le informazioni ed il relativo comportamento dovrebbero
risiedere nella stessa classe
• Nessuna classe può essere isolata
• Evitare i “functoid”
• Evitare gli alberi di ereditarietà profondi
• Una classe con un unico attributo può essere utile per la progettazione
ma è probabilmente meglio rappresentata come attributo in fase di analisi
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
12