Analisi e progettazione ad oggetti

Transcript

1 Analisi e progettazione ad oggetti

2 Richiami di Analisi e progettazione ad oggetti L idea di base della analisi ad oggetti è di partire da una descrizione del problema in termini di entità e relazioni tra di esse, per poi arrivare ad identificare le classi e le loro relazioni, utilizzando i principi base della programmazione ad oggetti, ereditarietà, polimorfismo ed incapsulamento Si possono individuare tre fasi 1. Identificare le classi 2. Attribuire le responsabilità ed i comportamenti a ciascuna classe 3. Descrivere le relazioni fra le classi 2

3 Identificare le classi Nella prima fase si identificano i concetti principali che identificano l applicazione o il problema da affrontare Possono identificare sia entità (animate o no), come Persona, Libro, Auto; che concetti (conto corrente, pagamento, partita) E utile fare un elenco di tutte le classi possibili, che poi possono essere eliminate 3

4 Esempio gestione dei conti Possibili classi corrente in una banca Banca, cliente, conto corrente, versamento, bonifico, saldo, ottenere valuta estera 4

5 Attribuire i comportamenti Identificazione metodi e attributi Per identificare i metodi e gli attributi degli oggetti si può far riferimento alle azioni che effettuano le identità identificate come oggetti Gli attributi rappresentano le principali proprietà degli oggetti, i metodi sono i comportamenti richiesti per la risoluzione del problema Identificare possibili aggregazioni tra oggetti per rappresentare aspetti più complessi (il conto corrente associato ad un risparmiatore) 5

6 Esempio (continua) Calcolare il saldo conto Effettuare un bonifico a favore di un beneficiario 6

7 Le responsabilità Cercare comportamenti comuni a più classi e verificare se sia possibile creare una classe astratta Bisogna identificare chiaramente le responsabilità, e distribuirle equamente (non accollarle in una sola o poche classi, non usare classi ridondanti) 7

8 Esempio (continua) Chi deve calcolare il saldo conto? IL cliente o la banca? Chi deve convertire la valuta? La banca può chiedere aiuto? 8

9 Relazione client / server Distinguere tra i ruoli tra richiedente e fornitore (client / server) Un client sa di cosa ha bisogno, e come richiederlo al server. Si disinterssa di come il lavoro venga svolto, se questo viene delegato dal server ad altri Allo stesso modo il server sa adempiere alla richiesta dei client, ma non è interessato alla natura del client, ne vuole rilevare come viene svolto il lavoro (se a sua volta viene delegato) 9

10 Assegnare le responsabilità Un aspetto centrale nel design ad oggetti è una giusta attribuzione delle responsabilità tra le classi, per assicurare sial la modularità che il riuso degli oggetti In generale, si deve evitare di creare classi troppo accentratrici, con metodi complessi che rimandano alla programmazione procedurale più che a quella ad oggetti Le classi dovrebbero essere egoiste cercare di rifiutare responsabilità, di lavorare di meno e di delegare 10

11 Identificare le relazioni E importare identificare correttamente le relazioni in gioco, in termini di collaborazioni aggregazioni generalizzazioni Evitare le relazioni inutili e di eccedere nelle dipendenze 11

12 Implementazione delle relazioni Generalizzazione (Ereditarietà ): E un.. Aggregazione/Associazione: Ha (Composizione creazione) Dipendenza: Conosce (Composizione) Usare ereditarietà se effettivamente è richiesto il polimorfismo Cercare di non modificare il comportamento della classe base 12

13 La banca cambia la valuta con la collaborazione della banca centrale Il cliente dispone un bonifico alla banca dando gli estremi del beneficiario 13

14 Sviluppo evolutivo Nell'analisi e nella programmazione ad oggetti si predilige uno sviluppo evolutivo del progetto, attraversi più cicli di requisiti/analisi/progettazione/test/verifica, rispetto ad un tradizionale separazioni delle fasi a cascata 14

15 Ereditarietà ed aggregazione 15

16 Estensione del modello per includere segretarie, impiegati di magazzino, venditori 16

17 Riassestamento della gerarchia per tenere conto delle caratteristiche introdotte: attribuire le nuove caratteristiche nella super classe? 17

18 Introdurre delle classi intermedie? 18

19 Come prevedere le future espansioni del modello? 19

20 Spesso è preferibile interpretare le relazioni in termine di composizione/aggregazione piuttosto che di ereditarietà 20

21 Interpretare le relazioni in termini di ereditarietà aggregazione dipendenza influisce l intero ciclo di vita del software ad oggetti L aggregazione spesso deve essere preferita all ereditarietà quando favorisce l evoluzione del modello, inoltre si presta meglio anche ad essere interpretata nei modelli ER (database) 21