Questo capitolo esemplifica la progettazione di oggetti responsabilità e collaborazioni applicazione dei pattern GRASP applicazione di UML

Transcript

1 Luca Cabibbo Analisi e Progettazione del Software Esempi di progettazione a oggetti con i pattern GRASP Capitolo 18 marzo 2013 Ogni cosa dovrebbe essere fatta nel modo più semplice possibile, ma non più semplice (di quanto sia possibile)! Albert Einstein 1 *** AVVERTENZA *** I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo 2

2 Introduzione Questo capitolo esemplifica la progettazione di oggetti responsabilità e collaborazioni applicazione dei pattern GRASP applicazione di UML Alcuni punti chiave l assegnazione di responsabilità e la progettazione delle collaborazioni sono passi molto importanti e creativi della progettazione divieto di magia l assegnazione di responsabilità e la progettazione delle collaborazioni può essere spiegata razionalmente e studiata 3 Divieto di magia 4

3 18.1 Realizzazioni di casi d uso In UP, la portata di una sessione di progettazione è caratterizzata in termini di realizzazioni di casi d uso Una realizzazione di caso d uso descrive, nel modello di progetto, come viene realizzato un particolare caso d uso, in termini di oggetti che collaborano [RUP] progetto relativo a uno o più scenari di un caso d uso illustrato da diagrammi di interazione realizzazione di caso d uso è un termine di UP enfatizza la connessione forte tra requisiti e progetto: il progetto deve soddisfare i requisiti per che cosa devo progettare? operazioni di sistema altre operazioni interrogazioni 5 UP: Influenza tra elaborati Sample UP Artifact Relationships Domain Model Business Modeling date... Sale 1 1..* Sales... LineItem... quantity Use-Case Model inspiration for names of some software domain objects Requirements starting events to design for, and detailed postcondition to satisfy Cashier Process Sale Use Case Diagram Operation: enteritem( ) Post-conditions: -... Operation Contracts ideas for the postconditions use case names system operations : Register : Cashier Process Sale 1. Customer arrives Cashier enters item identifier. Use Case Text system events make NewSale() enteritem (id, quantity) : System System Sequence Diagrams Design Model functional requirements that must be realized by the objects : ProductCatalog Glossary Supplementary Specification item details, formats, validation non-functional requirements domain rules : Sale Design enteritem (itemid, quantity) d = getproductdescription(itemid) addlineitem( d, quantity ) Register makenewsale() enteritem() * 1 ProductCatalog getproductdescription() 6

4 18.2 Commento sugli elaborati Realizzazione di caso d uso per ciascuna operazione di sistema va creato un diagramma di interazione che mostra la gestione del messaggio trovato relativo a tale evento/operazione di sistema nello studio di caso POS, per le operazioni di sistema makenewsale, enteritem, endsale, make(cash)payment con attenzione soprattutto alla gestione della trasformazione (cambiamento di stato) causata dall operazione di sistema eventuali altri diagrammi di interazione per risposte (interrogazioni) significative del sistema ad esempio, nello studio di caso, per l interrogazione gettotal va inoltre creato in parallelo un diagramma delle classi di progetto che descrive/riassume le scelte strutturali di progetto classi e interfacce software, con le loro proprietà strutturali (attributo e associazioni) e comportamentali (operazioni) 7 Diagrammi di interazione Usando i diagrammi di comunicazione crea un diagramma per ciascun evento/operazione di sistema Non un unico grosso diagramma! 8

5 Diagrammi di interazione Usando i diagrammi di sequenza crea un diagramma per ciascun evento/operazione di sistema Non un unico grosso diagramma! 9 Casi d uso e realizzazioni di casi d uso Una realizzazione di caso d uso può essere basata direttamente sul testo del caso d uso insieme agli altri elaborati per i requisiti Scenario principale di successo (o flusso di base): 1. Il Cliente arriva alla cassa POS con gli articoli e/o i servizi da acquistare. 2. Il Cassiere inizia una nuova vendita. 3. Il Cassiere immette il codice identificativo dell articolo. 4. Il Sistema registra la riga di vendita per l articolo e mostra la descrizione dell articolo, il suo prezzo e il totale parziale. Il prezzo è calcolato in base a un insieme di regole di prezzo. Il Cassiere ripete i passi 3-4 fino a che non indica che ha terminato. 5. Il Sistema mostra il totale, con le imposte calcolate. 6. Il Cassiere riferisce il totale al Cliente, e richiede il pagamento. 7. Il Cliente paga e il Sistema gestisce il pagamento. 8. Il Sistema registra la vendita completata e invia informazioni sulla vendita e sul pagamento ai sistemi esterni di Contabilità (per la contabilità e le commissioni) e di Inventario (per l aggiornamento dell inventario). 9. Il Sistema genera la ricevuta. 10. Il Cliente va via con la ricevuta e gli articoli acquistati. Attenzione i requisiti scritti possono essere imperfetti coinvolgi l utente migliora la tua comprensione dei requisiti anche durante la progettazione 10

6 Contratti e realizzazioni di casi d uso Una realizzazione di caso d uso può essere basata sugli SSD e sui contratti delle operazioni creati durante l analisi orientata agli oggetti Contratto CO2: enteritem Operazione: Riferimenti: Pre-condizioni: Post-condizioni: enteritem(itemid: ItemID, quantity: integer) Caso d uso: Elabora Vendita È in corso una vendita. - è stata creata un istanza sli di SalesLineItem - sli è stata associata con la Sale corrente s - sli.quantity è diventato quantity - sli è stato associato con una ProductDescription, in base alla corrispondenza con itemid il progetto deve soddisfare le post-condizioni 11 Contratti e realizzazioni di casi d uso Diagramma di interazione (parziale) che soddisfa una delle postcondizioni del contratto dell operazione enteritem 12

7 Salto rappresentazionale basso (LRG) Il Modello di dominio è fonte di ispirazione (non un vincolo!) per le classi software che parteciperanno alla soluzione 13 Salto rappresentazionale basso (LRG) Il Modello di dominio è fonte di ispirazione (non un vincolo!) per le classi software che parteciperanno alla soluzione attenzione, le post-condizioni dei contratti delle operazioni sono espresse a livello concettuale non software dunque, se le post-condizioni di un operazione di sistema dicono, ad es., è stato creato un oggetto (concettuale) di una classe (concettuale) X, allora questo non implica direttamente che, a livello software, l operazione vada realizzata con la creazione di un oggetto (software) di una classe (software) X tuttavia, una post-condizione di questo tipo potrebbe suggerire di creare un oggetto (o più oggetti) software che rappresentano un oggetto concettuale di tipo X 14

8 18.3 E ora? Il resto del capitolo descrive progetto per POS NextGen progetto per Monopoly Game System basati sull applicazione di UML e dei pattern Realizzazioni di casi d uso per POS Requisiti per POS NextGen in questa iterazione scenario principale di successo di Elabora Vendita semplificato solo pagamento in contanti, no imposte, no sconti, niente dati persistenti caso d uso d avviamento contesto della progettazione in cui va presa in considerazione la creazione e l inizializzazione di molti oggetti radice o degli oggetti di lunga vita Quando considero il caso d uso d avviamento? se scrivo codice all inizio (almeno in modo parziale) se disegno alla fine (per sostenere gli altri casi d uso) 16

9 * Discussione sulla gestione dei dati Potrebbe sembrare poco realistico fare la progettazione nell ipotesi niente dati persistenti dunque, nessuna base di dati tuttavia, capiremo (anche se solo alla fine del corso) che un progetto fatto con quest ipotesi ha assolutamente senso infatti, con l uso di opportuni strumenti metodologici e tecnologici, introdurre nel progetto (e nel codice) la gestione della persistenza dei dati richiede solo delle modifiche marginali e comunque compatibili con l assegnazione di responsabilità basata sui pattern GRASP, come esemplificato in questo capitolo In pratica, all esame di APS si fanno normalmente le seguenti ipotesi il sistema in discussione gestisce i propri dati solo in memoria principale durante il caso d uso di avviamento vengono creati e caricati in memoria tutti gli oggetti le cui informazioni sono già effettivamente disponibili al momento dell avviamento 17 * Dal testo dei compiti d esame Ipotesi di lavoro, valide per tutti gli esercizi di progettazione. In tutti gli esercizi che seguono, si faccia l ipotesi che il sistema in discussione gestisca i propri dati solo in memoria principale. Si supponga anche che durante il caso d uso di avviamento vengano creati e caricati in memoria tutti gli oggetti le cui informazioni siano già effettivamente disponibili al momento dell avviamento. Per ciascuna operazione di sistema va creato un diagramma di interazione che descrive l interazione relativa alla trasformazione (cambiamento di stato) provocata dall operazione di sistema. Per quanto riguarda invece le relative risposte (interrogazioni) eventualmente restituite dal sistema, se non è richiesto esplicitamente allora non bisogna mostrare nei diagrammi di interazione né il calcolo dei dati da restituire né la loro visualizzazione. Tuttavia, per le risposte del sistema, è comunque necessario verificare che i dati da restituire possano essere (facilmente) calcolati sulla base delle navigabilità tra gli oggetti che sono state progettate (vedi anche il punto successivo). Le soluzioni individuate dovranno essere compatibili (in particolare in termini di visibilità, ovvero di navigabilità delle associazioni) con le realizzazioni di tutti i casi d uso mostrati (UC1-UCX). Nei diagrammi di interazione, mostrare IN MODO ESPLICITO: tutti i MESSAGGI scambiati tra oggetti, tutte le CREAZIONI di oggetti e tutte le FORMAZIONI e ROTTURE di collegamenti. Nei diagrammi di interazione, motivare le scelte di progetto fatte indicando i pattern GRASP e GoF applicati. Nei diagrammi delle classi di progetto, mostrare: (1) per ciascuna classe: il nome della classe, i nomi dei suoi attributi, i nomi delle sue operazioni; e (2) per ciascuna associazione e ciascuna sua estremità navigabile: la freccia di navigabilità, il nome dell estremità, la molteplicità e, in caso di associazione navigabile a molti, il tipo di collezione scelta. 18

10 * Scenario (SSD) di riferimento : Cashier Process Sale Scenario makenewsale() :System loop [ more items ] enteritem(itemid, quantity) description, total endsale() total with taxes attenzione, questa operazione si dovrebbe chiamare makecashpayment makepayment(amount) change due, receipt 19 * Modello di dominio di riferimento 20

11 * Modello di dominio di riferimento attenzione, alcune classi tra quelle identificate in precedenza non vengono prese in considerazione nella scrittura dei contratti la classe CashPayment qui viene chiamata Payment ma le sue istanze sono effettivamente dei pagamenti in contanti, gli unici presi in considerazione in questa iterazione Progetto: makenewsale Scenario di riferimento per questa iterazione: 2. Il Cassiere inizia una nuova vendita. Contratto CO1: makenewsale Operazione: Riferimenti: Pre-condizioni: Post-condizioni: makenewsale() Caso d uso: Elabora Vendita nessuna - è stata creata un istanza s di Sale - s è stata associata al Register - gli attributi di s sono stati inizializzati 22

12 makenewsale: inizio della progettazione La prima domanda in una realizzazione di caso d uso chi è il controller per questa operazione di sistema? quale pattern devo applicare? quali le possibilità suggerite? sicuro di aver considerato tutte le alternative? quale la scelta? 23 makenewsale: inizio della progettazione La prima domanda in una realizzazione di caso d uso chi è il controller per questa operazione di sistema? Devo applicare Controller 24

13 makenewsale: inizio della progettazione La prima domanda in una realizzazione di caso d uso chi è il controller per questa operazione di sistema? Devo applicare Controller facade controller o controller di caso d uso? se scelgo un facade controller, dopo dovrò verificare le operazioni di sistema sono in numero adeguato oppure troppe? il controller è complessivamente altamente coeso e debolmente accoppiato oppure no? quale controller scelgo in questo caso? 25 makenewsale: scelta del controller Quale controller scelgo? 26

14 makenewsale: scelta del controller Quale controller scelgo? Register ispirato al modello di dominio ora indica un oggetto software nel modello di progetto rappresenta (ma non è) il registratore di cassa ovvero, un punto d accesso al sistema da parte dell attore primario del caso d uso in discussione Nei sistemi client/server, è comune scegliere come controller un oggetto che rappresenta un punto d accesso al sistema da parte dell attore primario del caso d uso 27 Scelta del controller Scelta del controller 28

15 makenewsale: DCD parziale Register makenewsale() 29 makenewsale: prosecuzione Dopo aver assegnato una responsabilità, la domanda successiva è come fa l oggetto a cui ho assegnato una responsabilità a soddisfare la responsabilità che gli è stata assegnata? in questo caso che cosa deve fare il Register per soddisfare la responsabilità dell operazione di sistema makenewsale? Contratto CO1: makenewsale Operazione: Riferimenti: Pre-condizioni: Post-condizioni: makenewsale() Caso d uso: Elabora Vendita nessuna - è stata creata un istanza s di Sale - s è stata associata al Register - gli attributi di s sono stati inizializzati 30

16 * Una precisazione Il contratto dell operazione di sistema makenewsale ha, tra le sue post-condizioni, la creazione di un istanza s di Sale attenzione, il contratto parla della creazione di un oggetto Sale concettuale per LRG, è lecito pensare che un oggetto Sale concettuale possa essere rappresentato da un oggetto Sale software pertanto, stiamo identificando una responsabilità che riguarda la creazione di un oggetto software 31 Creazione di una nuova vendita Chi crea la Sale? quale pattern devo applicare? quali le possibilità suggerite? sicuro di aver considerato tutte le alternative? quale la scelta? 32

17 Creazione di una nuova vendita Chi crea la Sale? Devo applicare Creator Pattern Creator Problema chi deve essere responsabile della creazione di una nuova istanza di una classe (A)? Soluzione assegna alla classe B la responsabilità di creare un istanza della classe A se è vera una o più delle seguenti condizioni (più sono vere, meglio è) B contiene o aggrega con una composizione oggetti di tipo A B registra A B utilizza strettamente A B possiede i dati per l inizializzazione di A, che saranno passati ad A al momento della sua creazione B è un esperto rispetto alla creazione di A B è detto un creatore di oggetti A se sono applicabili più opzioni, preferisci una classe B che aggrega o contiene oggetti A 33 Creazione di una nuova vendita Chi crea la Sale? 34

18 Creazione di una nuova vendita Chi crea la Sale? :Register makenewsale create :Sale 35 makenewsale: DCD parziale 36

19 makenewsale: prosecuzione La prossima responsabilità Contratto CO1: makenewsale Operazione: Riferimenti: Pre-condizioni: Post-condizioni: makenewsale() Caso d uso: Elabora Vendita nessuna - è stata creata un istanza s di Sale - s è stata associata al Register - gli attributi di s sono stati inizializzati come formare il collegamento tra il Register e la Sale? 37 * makenewsale: collegamento Register-Sale Tre possibilità (principali) il Register referenzia la Sale corrente la Sale referenzia il suo Register navigabilità doppia 38

20 makenewsale: DCD parziale 39 makenewsale: DCD parziale spesso, quando un oggetto crea un altro oggetto, allora l oggetto creatore mantiene un riferimento all oggetto creato attenzione, talvolta accade il contrario, o entrambi gli oggetti si referenziano l un l altro in questo caso è utile che il Register (il controller) mantenga un riferimento alla Sale corrente durante tutta l esecuzione del caso d uso (un informazione dello stato della sessione) lo capiremo meglio andando avanti 40

21 makenewsale: vendita corrente ma come fa il Register a mantenere un riferimento all oggetto Sale appena creato? 41 makenewsale: vendita corrente :Register makenewsale create s:sale this.currentsale = s 42

22 Creazione di una nuova vendita La Sale appena creata, come inizializza il suo stato? 43 makenewsale: DCD parziale un associazione tra Sale e SalesLineItem deve essere sicuramente mantenuta navigabile in un verso oppure nell altro la scelta fatta ora nel libro sarà in effetti motivata più avanti 44

23 Creazione di una nuova vendita La Sale appena creata, come inizializza il suo stato? 45 * Ricapitolando Nella progettazione a oggetti chiediti qual è una responsabilità da assegnare sulla base del tipo di responsabilità, seleziona il pattern GRASP da applicare sulla base del pattern, scegli l oggetto a cui assegnare la responsabilità chiediti come fa l oggetto scelto a soddisfare la responsabilità questo può portare all identificazione di altre responsabilità da assegnare 46

24 Progetto: enteritem Scenario di riferimento per questa iterazione: 3. Il Cassiere immette il codice identificativo dell articolo e la quantità. 4. Il Sistema registra la riga di vendita per l articolo e mostra la descrizione dell articolo Contratto CO2: enteritem Operazione: enteritem(itemid: ItemID, quantity: integer) Riferimenti: Caso d uso: Elabora Vendita Pre-condizioni: È in corso una vendita s. Post-condizioni: - è stata creata un istanza sli di SalesLineItem - sli è stata associata con la Sale corrente s - sli.quantity è diventato quantity - sli è stato associato con una ProductDescription, in base alla corrispondenza con itemid 47 Devo progettare per la visualizzazione dei dati? Il caso d uso afferma che dopo l esecuzione di enteritem va mostrata la descrizione e il prezzo dell articolo bisogna progettare per la visualizzazione dei dati? Per il principio di separazione modello-vista visualizzare dati non è responsabilità dello strato del dominio è tuttavia responsabilità dello strato del dominio calcolare i dati da visualizzare Per il momento, nel progetto ignoriamo la gestione della visualizzazione dei dati nella progettazione c è un attenzione diversa per la componente di trasformazione e quella di interrogazione di un operazione di sistema attenzione, questo non significa che non terremo conto delle interrogazioni durante la progettazione 48

25 Scelta del controller Chi è il controller per enteritem? 49 Creazione di una nuova SalesLineItem Chi crea il nuovo oggetto SalesLineItem? quale pattern devo applicare? quali le possibilità suggerite? sicuro di aver considerato tutte le alternative? quale la scelta? 50

26 Creazione di una nuova SalesLineItem Chi crea il nuovo oggetto SalesLineItem? 51 Creazione di una nuova SalesLineItem Chi crea il nuovo oggetto SalesLineItem? ok, devo applicare Creator che suggerisce oppure ok, il creatore è Sale ma quale Sale? 52

27 Creazione di una nuova SalesLineItem Chi deve chiedere alla Sale corrente di creare il nuovo oggetto SalesLineItem? quale pattern devo applicare? quali le possibilità suggerite? sicuro di aver considerato tutte le alternative? quale la scelta? 53 Creazione di una nuova SalesLineItem Chi deve chiedere alla Sale corrente di creare il nuovo oggetto SalesLineItem? Devo applicare Information Expert Pattern Information Expert Problema qual è un principio generale nell assegnazione di responsabilità agli oggetti? Soluzione assegna una responsabilità all esperto delle informazioni la classe che ha le informazioni necessarie a soddisfare la responsabilità 54

28 Creazione di una nuova SalesLineItem Chi deve chiedere alla Sale corrente di creare il nuovo oggetto SalesLineItem? Devo applicare Information Expert che cosa mi suggerisce? 55 Creazione di una nuova SalesLineItem Creazione di un nuovo oggetto SalesLineItem 56

29 Creazione di una nuova SalesLineItem Creazione di un nuovo oggetto SalesLineItem questo messaggio può essere inviato sulla base di una visibilità stabilita dall operazione precedente makenewsale non sarebbe stato possibile realizzare questa collaborazione se tra Sale e Register fosse stata scelta la navigabilità opposta 57 Associazione tra Sale e SalesLineItem Chi associa il nuovo oggetto SalesLineItem alla Sale corrente? 58

30 Associazione tra Sale e SalesLineItem Chi associa il nuovo oggetto SalesLineItem alla Sale corrente? quali alternative? quali le alternative sensate? come si potrebbero gestire? 59 Trovare la ProductDescription Chi è responsabile di trovare una ProductDescription, dato il suo itemid? 60

31 Trovare la ProductDescription Chi è responsabile di chiedere al ProductCatalog di trovare la ProductDescription? Un oggetto può chiedere a un altro oggetto di eseguire un operazione solo se ne ha visibilità Register ma come conosce il ProductCatalog? perché non Sale o SalesLineItem? 61 Trovare la ProductDescription Chi è responsabile di trovare una ProductDescription, dato il suo itemid? un pattern : ID to Object (paragrafo 26.8) 62

32 Associazione tra sli e pd Chi associa il nuovo oggetto SalesLineItem alla ProductDescription corrispondente? quando? 63 enteritem: progetto completo 64

33 enteritem: DCD parziale 1 catalog ProductCatalog getproductdesc() descriptions {Map} 1..* ProductDescription description : Text price : Money itemid: ItemID Sale description 1 Register enteritem() currentsale 1 iscomplete : Boolean time : DateTime makelineitem() lineitems {ordered} 1..* SalesLineItem quantity : Integer 65 * enteritem: DCD parziale Un osservazione sulla formazione e sull uso dei collegamenti 1 catalog ProductCatalog getproductdesc() descriptions {Map} 1..* ProductDescription description : Text price : Money itemid: ItemID description 1 Sale Register enteritem() currentsale 1 iscomplete : Boolean time : DateTime makelineitem() lineitems {ordered} 1..* SalesLineItem quantity : Integer l interazione per un operazione/interrogazione di sistema può navigare alcuni collegamenti qui, quelli mostrati in blu formare altri collegamenti qui, quelli mostrati in rosso alla fine bisogna verificare che (1) ogni collegamento progettato sia utile e che (2) venga effettivamente formato 66

34 * Perché trovare la ProductDescription? Perché bisogna trovare la ProductDescription? Ovvero, perché il parametro di enteritem è un id (cioè una stringa) e non una ProductDescription (cioè un riferimento)? ricordiamo che id è un parametro che viene passato dallo strato dell interfaccia utente in molti sistemi, lo strato dell interfaccia utente è in esecuzione in un processo diverso da quello dello strato del dominio i riferimenti a oggetti hanno senso solo nell ambito di un singolo processo quindi, non ha senso che le richieste che devono attraversare il confine tra processi diversi contengano dei riferimenti a oggetti è invece comune che le richieste che devono attraversare il confine tra processi diversi contengano degli identificatori (intesi come chiavi) di oggetti 67 Trovare la ProductDescription Nella versione finale, la ProductDescription sarà trovata e caricata da una base di dati per ora, immaginiamo che il sistema gestisce tutti gli oggetti in memoria principale tutti gli oggetti di cui le informazioni sono disponibili vengono creati e caricati in memoria durante il caso d uso d avviamento più avanti, parleremo del collegamento tra strato del dominio e il gestore della persistenza uso di una base di dati relazionale per gestire dati persistenti il ProductCatalog potrà comunque essere usato come intermediario per interfacciarsi alla base di dati 68

35 * Ricapitolando Nella progettazione a oggetti chiediti qual è una responsabilità da assegnare sulla base del tipo di responsabilità, seleziona il pattern GRASP da applicare sulla base del pattern, scegli l oggetto A a cui assegnare la responsabilità chiediti come fa l oggetto scelto A a soddisfare la responsabilità questo può portare all identificazione di altre responsabilità da assegnare chiediti quali sono le collaborazioni richieste chiediti anche qual è l oggetto B a cui assegnare la responsabilità di chiedere all oggetto A di soddisfare una sua responsabilità 69 * Deviazione ehi, è un buon momento per parlare di visibilità! oppure, se vuoi, possiamo aspettare ancora un pochino ma mi raccomando, non molto! 70

36 Progetto: endsale Si veda il libro Progetto: gettotal Si veda il libro 72

37 * Discussione L operazione gettotal non è una vera e propria operazione di sistema piuttosto, rappresenta una risposta del sistema, ovvero un interrogazione durante la progettazione è comunque importante prendere in considerazione anche le interrogazioni soprattutto perché possono guidare o motivare scelte di progetto relative alla visibilità tra oggetti ad es., se non fosse richiesto il calcolo del totale di una vendita, allora forse potrebbe essere inutile gestire l associazione tra una Sale e le sue SalesLineItem forse potrebbe essere addirittura inutile quest ultima classe 73 * Discussione L operazione gettotal non è una vera e propria operazione di sistema piuttosto, rappresenta una risposta del sistema, ovvero un interrogazione nei casi più semplici, è sufficiente ispezionare il DCD per verificare se le interrogazioni di interesse (per il caso d uso corrente ma anche per altri casi d uso) possono essere soddisfatte in termini delle associazioni scelte, delle loro navigabilità e di come/quando vengono effettivamente gestite tuttavia, nei casi più complessi, può essere utile creare dei diagrammi di interrogazione per mostrare come sia effettivamente possibile calcolare informazioni che devono essere visualizzate attenzione per il momento ci stiamo occupando solo del calcolo dei dati ma non ancora per la loro visualizzazione notare che il messaggio trovato gettotal non è indirizzato al controller, ma piuttosto all esperto designato per l operazione 74

38 Progetto: makepayment Si veda il libro 75 * Discussione Attenzione l operazione makepayment dovrebbe chiamarsi makecashpayment la classe Payment dovrebbe chiamarsi CashPayment 76

39 * Ricapitolando Nella progettazione a oggetti chiediti qual è una responsabilità da assegnare sulla base del tipo di responsabilità, seleziona il pattern GRASP da applicare sulla base del pattern, scegli l oggetto A a cui assegnare la responsabilità chiediti come fa l oggetto scelto A a soddisfare la responsabilità questo può portare all identificazione di altre responsabilità da assegnare chiediti quali sono le collaborazioni richieste chiediti anche qual è l oggetto B a cui assegnare la responsabilità di chiedere all oggetto A di soddisfare una sua responsabilità chiediti se ci sono alternative, e valutale in termini di coesione e di accoppiamento 77 Calcolo del resto Si veda il libro 78

40 * Ricapitolando In una realizzazione di caso d uso crea un diagramma di interazione per ciascuna operazione di sistema in particolare, con attenzione ai cambiamenti di stato causati dall operazione di sistema per ciascuna risposta del sistema chiediti se il progetto è in grado di calcolare le informazioni da restituire nel caso, crea un diagramma di interrogazione per i calcoli più complessi non ti occupare (per ora) della visualizzazione dei dati 79 DCD per NextGen POS (libro) Store address : Address name : Text addcompletesale() 1 catalog catalog 1 ProductCatalog getproductdesc() descriptions {Map} 1..* ProductDescription description : Text price : Money itemid: ItemID register 1 Register endsale() enteritem() makenewsale() makepayment() currentsale 1 completedsales {ordered} Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem() makepayment() gettotal() * lineitems {ordered} payment 1 1..* SalesLineItem quantity : Integer getsubtotal() Payment amount : Money description 1 80

41 * DCD per NextGen POS Store address : Address name : Text store addcompletesale() 1 1 catalog ProductCatalog getproductdesc() descriptions {Map} 1..* ProductDescription description : Text price : Money itemid: ItemID Register endsale() enteritem() makenewsale() makecashpayment() currentsale 1 completedsales {ordered} Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem() makecashpayment() gettotal() * lineitems {ordered} payment 1 1..* SalesLineItem quantity : Integer getsubtotal() CashPayment amount : Money description Collegamento tra UI e dominio Lo strato UI ha bisogno della visibilità di (alcuni) oggetti del dominio quali oggetti deve poter vedere la UI? sicuramente il controller Register forse anche altri oggetti notevoli ad es., la Sale corrente attenzione però all accoppiamento! è possibile farlo in più modi scelta di questa prima iterazione nella creazione della UI, il controller viene passato come parametro la UI potrà poi conoscere altri oggetti notevoli tramite il controller Ci sono altre possibilità, che esamineremo nelle successive iterazioni in particolare accesso mediante un Singleton o una Factory accesso mediante Observer 82

42 Collegamento tra UI e dominio 83 Collegamento tra UI e dominio 84

43 Progetto: avviamento Molti sistemi (se non tutti) hanno un caso d uso d avviamento svolge le operazioni iniziali per l avvio del sistema comprende in particolare la creazione e l inizializzazione di molti oggetti radice o degli oggetti di lunga vita l operazione di sistema startup è la prima ad essere eseguita di solito però non è la prima ad essere progettata 85 Progetto: avviamento Come progettare per il caso d uso di avviamento? un idioma progettuale comune usa un oggetto di dominio iniziale il primo oggetto software di dominio ad essere creato responsabile della creazione degli altri oggetti di dominio che sono inizialmente necessari quale oggetto di dominio iniziale per il sistema POS? Store 86

44 Creazione dell oggetto di dominio iniziale public class Main { public static void main(string[] args) { /* Store è l oggetto di dominio iniziale. * Lo Store esegue l operazione di startup, * che crea altri oggetti di dominio. */ Store store = new Store(); } /* Avvia l interfaccia grafica, passandogli il controller. */ Register register = store.getregister(); ProcessSaleJFrame frame = new ProcessSaleJFrame(register); /* L interfaccia grafica può così mantenere un riferimento * al controller per tutta la durata dell applicazione. */ } 87 Scelta dell oggetto di dominio iniziale L oggetto di dominio iniziale va scelto tra quelli che sono vicini alla radice della gerarchia di contenimento/aggregazione degli oggetti di dominio un oggetto che contiene (direttamente o indirettamente) tutti o molti altri oggetti oppure, un facade controller scegliendo anche sulla base di High Cohesion e Low Coupling Quale oggetto di dominio iniziale per il sistema POS NextGen? Store 88

45 Progetto dell operazione startup L esecuzione di startup deve abilitare l esecuzione dei diagrammi di interazione progettati in precedenza quali oggetti devono essere creati e inizializzati? l oggetto di dominio iniziale, Store un oggetto Register un oggetto ProductCatalog e tutti gli oggetti ProductDescription quali collegamenti devono essere stati formati? dall oggetto Register all oggetto ProductCatalog per enteritem dall oggetto ProductCatalog a tutti gli oggetti ProductDescription che contiene per enteritem dall oggetto Store all oggetto Register per lo startup dall oggetto Register all oggetto Store per makepayment, per registrare una vendita completata (!!!, manca sul libro) 89 Progetto per startup (libro) 90

46 * Progetto per startup completedsales: List<Sale> 3: create pass a reference to the ProductCatalog and the Store to the Register, so that it has permanent visibility to it create s:store 2: create(s,pc) :Register by Creator 1: create pc: ProductCatalog 1.1: create 1.2.2*: put(id, pd) descriptions: Map<ProductDescription> 1.2: loadprodspecs() 1.2.1*: create(id, price, description) pd: ProductDescription 91 * DCD per NextGen POS Store address : Address name : Text addcompletesale() store «create» 1 1 catalog ProductCatalog getproductdesc() descriptions {Map} 1..* ProductDescription description : Text price : Money itemid: ItemID register 1 Register endsale() enteritem() makenewsale() makecashpayment() currentsale 1 completedsales {ordered} Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem() makecashpayment() gettotal() * lineitems {ordered} payment 1 1..* SalesLineItem quantity : Integer getsubtotal() CashPayment amount : Money description 1 92

47 18.5 Realizzazioni di casi d uso per MGS Si veda il libro 93 * Un avvertenza Un avvertenza sul libro, nell ambito dell iterazione 1, sono stati volutamente commessi alcuni errori (o sono state prese delle decisioni che possono essere migliorate) nell analisi e nella progettazione sia per il sistema POS ma soprattutto per il gioco del Monopoly queste imprecisioni che verranno poi corrette nelle iterazioni successive lo spirito con cui è stata fatta questa scelta è comune commettere errori è utile capire che è possibile gestire gli errori commessi nonché capire come essi vanno gestiti in ogni caso, lo studio non dovrebbe essere interrotto al materiale dell iterazione 1 94

48 18.6 OOD iterativo ed evolutivo 95 UP: OOD iterativo ed evolutivo Disciplina Modellazione del business Requisiti Progettazione Elaborato Modello di dominio Ideaz. (I1) Elab. (E1..En) Modello dei casi d'uso s r Visione s r Specifiche supplementari s r Glossario s r s Costr. (C1..Cn) Modello di progetto s r Documento dell'architettura software Modello dei dati s r s Trans. (T1..T2) Implementazione Modello di implementazione s r r Gestione del progetto Piano di sviluppo software s r r r Test Modello di test s r Infrastruttura Scenario di sviluppo s r 96

49 18.7 Conclusioni La progettazione di oggetti è basata su progettazione di interazioni tra oggetti identificazione e assegnazione di responsabilità Le scelte progettuali hanno un impatto profondo sulle qualità del sistema estendibilità, chiarezza, mantenibilità, riusabilità, Ci sono principi su cui basare le scelte progettuali i pattern GRASP riassumono alcuni dei principi per l assegnazione di responsabilità nell OOD più generali e più comunemente usati 97