Responsibility Driven Design

Transcript

1 Responsibility Driven Design Laboratorio di Ingegneria del Software Andrea Bei

2 Progettazione a oggetti (OOD) Progettare a oggetti una funzionalità espressa da un requisito ( use case, SSD, ) significa Identificare gli oggetti, coerenti rispetto al modello di dominio e alla architettura applicativa, la cui collaborazione realizza la funzionalità Assegnare correttamente le responsabilità agli oggetti identificati applicando i Design Pattern Nell OOD l UML è usato per rappresentare le decisioni progettuali di identificazione di oggetti e classi e assegnazione di responsabilità (Class Diagram e Interaction Diagram) 2

3 Progettazione a oggetti con UML Modellazione dinamica: realizzazione di diagrammi dinamici quali interazione (sequenza o comunicazione), automi a stati, di attività obiettivo: progettare la logica e il comportamento degli oggetti (i metodi) è la più importante perchè si individuano le responsabilità degli oggetti Modellazione statica: realizzazione dei diagrammi delle classi, dei package e di deployment obiettivo: progettare nomi delle classi e dei package, degli attributi e delle operazioni 3

4 Output della progettazione OO Sample UP Artifact Relationships Domain Model Business Modeling date... Sale..* Sales... LineItem... quantity Use-Case Model Process Sale 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. 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(...)... *... ProductCatalog getproductdescription(...)... 4

5 Introduzione ai Design Pattern Chi progetta usa l esperienza (personale e di gruppo) nella progettazione di un nuovo sistema sw si riusano soluzioni progettuali già sperimentate in passato E importante Codificare e registrare l esperienza di soluzioni di progettazione per poterla riusare Comunicare l esperienza ad altri progettisti Apprendere dall esperienza di altri progettisti 5

6 Introduzione ai Design Pattern I Design Patterns sono emersi da alcuni anni come una delle tecniche più efficaci per registrare e trasferire la conoscenza e l'esperienza dei progettisti, rendendola disponibile in modo comprensibile Sono soluzioni comuni a problemi ricorrenti in un contesto specifico Aiutano a progettare in modo giusto e in minor tempo. Nascono nel 977 nel campo delle architetture edili (Christopher Alexander) e si estendono alle architetture software nel 994 con il testo di Gamma, Helm, Vlissides e Johnson Design Patterns, successivamente denominato Gang of Four (GoF) 6

7 Design Pattern: definizione/vantaggi Definizione: Un Pattern è costituito da Descrizione del problema Descrizione della soluzione in un contesto specifico Vantaggi: Facilitano il riuso di architetture e progetti validi Catturano l esperienza e la saggezza degli esperti Permettono di evitare perdite di tempo nella ricerca di soluzioni già esistenti Creano un linguaggio che semplifica la comunicazione e la comprensione tra gli addetti ai lavori (progettista-progettista, progettista-sviluppatore,.) Supportano il lavoro in team Incrementano la qualità del software: favoriscono il riuso, la manutenibilità, l estendibilità, la comprensibilità 7

8 Design Pattern: classificazione (/2) Design Patterns per la progettazione e lo sviluppo del software (modelli di progetto) Analysis Patterns per definire modelli di analisi riutilizzabili per problemi ricorrenti (modelli di dominio) Organization Patterns per definire organizzazioni e progetti (modelli di dominio) Process Patterns per definire processi (modelli di dominio) 8

9 Design Pattern: classificazione (2/2) I Design Pattern possono essere classificati in funzione del loro livello di astrazione/dettaglio Architectural Design Patterns Descrivono l organizzazione strutturale fondamentale di un sistema software (architettura applicativa) in termini di sottosistemi loro responsabilità e modalità di interazione es: Uno dei design pattern architetturali classici prevede le archittetura a livelli Design Patterns Forniscono uno schema per raffinare i sottosistemi o componenti di un sistema software. In genere descrivono strutture di oggetti che collaborano per risolvere un generico problema di progettazione in un particolare contesto. Idioms o Coding Design Patterns Pattern di basso livello specifico di un linguaggio di programmazione. Un idioma descrive come implementare particolari aspetti dei componenti o le relazioni tra essi utilizzando caratteristiche del linguaggio di programmazione scelto. 9

10 Design Pattern: descrizione Generalmente la descrizione di un pattern include: Una descrizione del problema, tra cui: un esempio concreto di problema una soluzione specifica al problema concreto Considerazioni che guidano alla formulazione di una soluzione generica Una soluzione generica Le conseguenze, positive e negative, nell utilizzare una data soluzione per risolvere un problema Un elenco di pattern simili I cataloghi di pattern contengono schede contenenti le informazioni sopra elencate, per ogni pattern 0

11 Tipica scheda pattern Pattern Name Synopsis Esposizione sintetica e sistematica del pattern Context Descrizione del problema che il pattern risolve Forces Riassunto delle considerazioni che conducono alla soluzione generica presentata nella sezione Solutions Solution Descrizione di una soluzione generica al problema che il pattern risolve Consequences Spiegazione delle implicazioni, positive e negative, nell utilizzo del pattern Implementation Presentazione degli aspetti da considerare in fase di implementazione In alcuni casi, descrizioni di varianti e/o semplificazioni Code Example Codice di esempio che mostra un semplice utilizzo pratico del pattern Related Patterns Elenco di pattern in qualche modo correlati

12 Progettazione guidata dalle responsabilità Metafora OO-mondo reale: si pensi agli oggetti software come a delle persone che hanno delle responsabilità e che collaborano con altre persone per svolgere un lavoro (Responsibility Driven Design) gli oggetti software sono dotati di responsabilità (ciò che fanno o conoscono) 2 tipi di responsabilità: Di fare: effettuare una azione (creare un oggetto, eseguire un calcolo,...) di delegare una azione (provocare una azione in altri oggetti) Di conoscere: conoscere i propri dati privati conoscere oggetti correlati conoscere cose che può derivare o calcolare I Design Pattern GRASP descrivono dei principi di base per assegnare le responsabilità agli oggetti e sostenere 2

13 Pattern GRASP GRASP (General Responsibility Assignment Software Patterns) Pattern GRASP di base Creator Expert Low Coupling Controller High Cohesion Altri pattern GRASP Polymorphism Pure Fabrication, Indirection Protected Variations 3

14 Creator Problema: Chi crea un oggetto A? Soluzione: Assegnare a B la responsabilità di creare un oggetto A se si verifica una delle seguenti condizioni. B contiene o aggrega oggetti di tipo A B registra A B utilizza A B possiede i dati per inizializzare A Nel caso non sia presente ancora nessuna classe ci si ispira al modello di dominio per ottenere una configurazione creatore-creato con LRG basso (Low-Representional-Gap) 4

15 Creator esempio Studio di Caso Monopoly Modello di dominio Chi crea Square? Per Creator è Board Board contiene oggetti Square Per LRG si introducono le classi software Board e Square Modello di progetto 5

16 Creator esempio 2 Studio di Caso POS Chi crea SalesLineItem? time Sale Contains Modello di dominio Per Creator è Sale Sale contiene oggetti SalesLineItem Per LRG si introducono le classi software Sale e SalesLineItem Sales LineItem quantity..* : Register : Sale makelineitem(quantity) * Described-by create(quantity) Product Description description price itemid Modello di progetto : SalesLineItem 6

17 Creator vantaggi e controindicazioni Vantaggi Accoppiamento basso. L atto della creazione della classe A da parte della classe B non incrementa l accoppiamento in quanto la classe A deve essere già visibile dalla classe B Controindicazioni Può non essere conveniente applicarlo in alcuni casi. Es: si usano molte istanze di una stessa classe (es: una classe pacchetto IP ricevuto) e si riciclano oggetti già creati ma non più utilizzati invece di creare ulteriori istanze la creazione non è banale e serve una classe di supporto (helper) per eseguirla 7

18 Information Expert Problema: Come assegnare responsabilità agli oggetti? Soluzione: Assegnare una responsabilità alla classe che possiede le informazioni per soddisfarla (Expert) Ricerca dell Expert Si ricerca nel modello di progetto Se non esiste nel modello di progetto si cerca nel modello di dominio per ispirarci l aggiunta della classe Expert nel modello di progetto 8

19 Information Expert: esempio Studio di Caso Monopoly Chi ha la responsabilità di accedere ad una square dato un nome? Modello di dominio Per Expert è Board Board aggrega oggetti Square quindi Board ha le informazioni su tali oggetti (è l Expert) quindi Board ha la responsabilità di accedere a Square Modello di progetto 9

20 Information Expert: esempio 2 Studio di Caso Monopoly Chi ha la responsabilità di conoscere il totale della vendita? time Sale Contains Modello di dominio Per Expert è Sale E necessario conoscere i totali parziali Per conoscere i totali parziali occorre conoscere i SalesLineItem Sale conosce i SalesLineItem (perchè li aggrega) quindi è l Expert Sales LineItem quantity..* * Described-by Product Description description price itemid Modello di progetto t = gettotal :Sale Sale NUOVO METODO New method time... gettotal() 20

21 Information Expert: esempio 2 Studio di Caso Monopoly time Sale Modello di dominio Chi ha la responsabilità di conoscere i totali parziali? Contains Per Expert è SalesItem E necessario conoscere quantity (SalesLineItem) e price (ProductDescription) SalesLineItem conosce quantity e ProductDescription quindi è l Expert Sales LineItem quantity iterazione this notation su will tutti imply gli we elementi are iterating della over collezione all elements of a collection..* t = gettotal : Sale *: st = getsubtotal lineitems[ i ] : SalesLineItem * Described-by time... Product Description description price itemid Modello di progetto Sale gettotal() SalesLineItem NUOVO METODO New method quantity getsubtotal() 2

22 Information Expert: esempio 2 Studio di Caso Monopoly Modello di progetto t = gettotal : Sale *: st = getsubtotal lineitems[ i ] : SalesLineItem time... Sale gettotal() Chi ha la responsabilità di conoscere il prezzo di un prodotto? Per Expert è ProductDescription ProductDescription conosce price quindi è l Expert time Sale Contains Modello di dominio.: p := getprice() :Product Description NUOVO METODO New method SalesLineItem quantity getsubtotal() Product Description description price itemid getprice() Sales LineItem quantity..* * Described-by Product Description description price itemid 22

23 Information Expert: il principio di animazione L assolvimento di una responsabilità spesso richiede informazioni sparse tra diversi oggetti (vedi es. precedente) Uno degli oggetti inizia una collaborazione con gli oggetti che possiedono le informazioni parziali (es: Sale con SalesLineItem e ProductDescription) per assolvere alla responsabilità complessiva Nel mondo reale una vendita non dice il proprio valore perchè è un oggetto inanimato.per il principio di animazione nella programmazione OO tutti gli oggetti sono vivi o animati e fanno cose relative alle informazioni di cui sono a conoscenza 23

24 Information Expert: vantaggi e controindicazioni Vantaggi Supporta High Coesion e Low Coupling Controindicazioni In alcuni casi si può avere un conflitto con altri 2 principi: High Coesion e Low Coupling. Es: Chi è responsabile di salvare in un database le informazioni di una Sale? Per Expert è la classe Sale ma in questo modo si diminuisce la coesione funzionale di Sale (Sale si occupa di aspetti tecnici come il salvataggio su un DB) e si aumenta il suo accoppiamento (cfr. più avanti nelle slide) In tali casi non va applicato 24

25 Coupling Coupling (Accoppiamento) E una misura di quanto un elemento (classe, package, sottosistema, strato) sia connesso, abbia conoscenza e sia dipendente da altri elementi L accoppiamento va ridotto al minimo necessario per aumentare La manutenibilità (ridurre l impatto dei cambiamenti) La riusabilità Comprensibilità dei singoli elementi indipendentemente La classe A è accoppiata alla classe B. Infatti: A dipende da B (l operazione dox di A dipende dalle operazioni doa,dob,doc di B) Cambiamenti di comportamento delle operazioni doa, dob o doc provocano cambiamenti di comportamento di dox Il riuso della sola classe A non è possibile, è necessaria anche la classe B A B 25

26 Coupling Coupling (Accoppiamento) In un sistema software gli elementi collaborano tra loro (per il principio di animazione) quindi è normale che dipendano gli uni dagli altri. In conclusione: l accoppiamento è necessario ma va mantenuto il più basso possibile Nella programmazione OO le forme più comuni di accoppiamento tra due tipi TypeX e TypeY sono: TypeX ha un attributo TypeY o referenzia un istanza TypeY Un oggetto TypeX richiama servizi di un oggetto TypeY TypeX ha un metodo che referenzia oggetti di tipo TypeY (variabili locali, parametri o tipi ritornati) TypeX è una sottoclasse diretta o indiretta TypeY è un interfaccia e TypeX implementa direttamente o indirettamente questa interfaccia 26

27 Low Coupling (accoppiamento basso) Problema: come ridurre l impatto dei cambiamenti, aumentare manutenibilità e riusabilità? Soluzione: Assegnare la responsabilità in modo che l accoppiamento rimanga basso. Usare questo principio per valutare le alternative progettuali. A parità di altre condizioni si consideri il progetto con minore accoppiamento 27

28 Low Coupling: esempio Studio di Caso Monopoly Problema: dato un nome di una Square chi deve avere la responsabilità di restituire la Square corrispondente? Soluzione (Poor Design) Si crea una classe arbitraria (Dog) a cui si da questa responsabilità Dog è accoppiato sia a Board che a Square. (accoppiamento a 2 classi) 2 Soluzione Si applica Expert. Chi ha le informazioni per assolvere alla responsabilità? Board. Board è accoppiato a Square (accoppiamento a classe) 28

29 Low Coupling: esempio 2 Studio di Caso POS Problema: Chi deve creare un Payment? Soluzione Per Creator è Register. Register risulta accoppiato a 2 classi (Payment e Sale) makepayment() : create() : Register p : Payment 2: addpayment(p) :Sale 2 Soluzione Tale soluzione sostiene Low Coupling e quindi è migliore makepayment() : makepayment() : Register :Sale.. create() :Payment 29

30 Low Coupling: vantaggi e controindicazioni Vantaggi (di un elemento con Low Coupling) Riusabilità Indipendenza dai cambiamenti di altri elementi Comprensibilità indipendentemente da altri elementi Controindicazioni Un accoppiamento alto di un elemento A con B non è un problema se A è consolidato (non instabile) e pervasivo (es: classi java.util) Applicare Low Coupling principalmente con gli elementi inerentemente instabili (es: UI) 30

31 Controller Problema: Qual è il primo oggetto oltre allo strato UI a ricevere e coordinare ( controllare ) una operazione di sistema? ) Modello dei casi d uso, SSD per il gioco del monopoly 2) Dal Modello dei Casi d Uso al Modello di Progetto ( zoom su System per playgame): Per il principio di separazione modellovista gli oggetti dell UI Layer non devono avere logica applicativa ma delegare le richieste al domain layer. Qual è il primo oggetto del domain layer che riceve la richiesta? Board? Square?... :System 3

32 Controller Soluzione:Assegnare la responsabilità ad un oggetto che rappresenta una delle seguenti scelte: Facade Controller: L oggetto deve rappresentare il sistema complessivo, un oggetto radice o un dispositivo fisico nel quale viene eseguito il software. il sistema complessivo Controller di caso d uso o di sessione: L oggetto deve rappresentare uno scenario di caso d uso all interno del quale è presente l operazione di sistema. L oggetto viene chiamato <nome>handler, <nome>coordinator o <nome>session. Es: il caso d uso in cui si verifica playgame e chiamato PlayMonopolyGame. Il Controller sarà PlayMonopolyGameHandler o PlayMonopolyGameSession 32

33 Controller: esempio Studio di Caso POS Problema: chi è il controller dell operazione di sistema enteritem? : Cashier presses button actionperformed( actionevent ) UI Layer :SaleJFrame enteritem(itemid, qty) Operazione di sistema system operation message Soluzione: Register, un dispositivo fisico su cui viene eseguito il sw Domain Layer :??? enteritem(id, quantity) Qual è la responsabile di ricevere questo messaggio? Which class of object should be responsible for receiving this system event message? It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects. Il controller non esegue il lavoro ma delega a sua volta The controller is a kind of "facade" onto the domain layer from the interface layer. E una sorta di Facade :Register 2 Soluzione: ProcessSaleHandler, un controller di caso d uso enteritem(id, quantity) :ProcessSaleHandler 33

34 Controller: esempio System endsale() enteritem() makenewsale() makepayment() makenewreturn() enterreturnitem() Register endsale() enteritem() makenewsale() makepayment() makenewreturn() enterreturnitem()... Studio di Caso POS Controindicazioni: se le operazioni sono troppe si ha un conflitto con High Coesion. Da usare se ci sono poche operazioni! Operazione di sistema identificate durante l analisi degli SSD system operations discovered during system behavior analysis Soluzione: Facade Controller allocation of system operations during design, using one facade controller System ProcessSale Handler HandleReturns Handler endsale() enteritem() makenewsale() makepayment() enterreturnitem() makenewreturn() endsale() enteritem() makenewsale() makepayment() 2 Soluzione: Controller di caso d uso allocation of system operations during design, using several use case controllers... enterreturnitem() makenewreturn()... Attenzione: non corrisponde a nessuna classe concettuale ( Pure Fabrication ) 34

35 Coesion Coesion (Coesione) E una misura di quanto sono correlate le operazioni di un elemento (classe, package, sottosistema, strato) dal punto di vista funzionale. Es: Oggetto Big, 00 metodi molto diversi per tipo di responsabilità (es: accesso ai db, log, calcoli matematici) è poco coeso ovvero poco focalizzato dal punto di vista funzionale Oggetto Small, 0 metodi con un solo tipo di responsabilità (calcoli matematici) è molto coeso 35

36 High Coesion Problema: Come mantenere gli oggetti focalizzati, comprensibili e gestibili e, come effetto collaterale, sostenere Low Coupling Soluzione: Assegnare le responsabilità in modo che la coesione rimanga alta. Usare questo principio per valutare alternative di progetto 36

37 Coesione, Accoppiamento e Modularità Modularità La modularità è la proprietà di un sistema decomposto in un insieme di moduli coesi e debolmente accoppiati Mutua influenza di coesione e accoppiamento Generalmente alta coesione produce basso accoppiamento e viceversa 37

38 Progettazione OO con pattern GRASP Realizzazione di un caso d uso Definizione: descrive come viene realizzato un caso d uso all interno del Modello di Progetto in termini di oggetti che collaborano In realtà una realizzazione di caso d uso è relativa ad uno solo dei possibili scenari di caso d uso Sarebbe più corretto parlare di realizzazione di scenario di caso d uso (ma non è una espressione usata nella pratica) 38

39 Relazione tra elaborati I casi d uso suggeriscono le operazioni di sistema (SSD) Le operazioni di sistema diventano i messaggi iniziali entranti nel Controller per i diagrammi di interazione I diagrammi di interazione illustrano come gli oggetti collaborano per realizzare i casi d uso Punti di attenzione: Il Modello di dominio e gli elaborati del modello dei casi d uso sono un input impreciso e incompleto per la progettazione Si può progettare a partire da casi d uso e SSD e opzionalmente dai contratti delle operazioni Business Modeling inspiration for names of some software domain objects Requirements starting events to design for, and detailed postcondition to satisfy Design Cashier date... Process Sale Operation: enteritem( ) Post-conditions: -... Sale Use Case Diagram Operation Contracts enteritem (itemid, quantity)... Domain Model..* Sales... LineItem Use-Case Model ideas for the postconditions : Register Sample UP Artifact Relationships use case names system operations Register makenewsale() enteritem(...)... : Cashier quantity Process Sale. Customer arrives Cashier enters item identifier. Use Case Text system events make NewSale() enteritem (id, quantity) : System System Sequence Diagrams Design Model d = getproductdescription(itemid) addlineitem( d, quantity ) * functional requirements that must be realized by the objects : ProductCatalog Glossary ProductCatalog getproductdescription(...)... Supplementary Specification item details, formats, validation non-functional requirements domain rules : Sale 39

40 Caso di studio POS Realizzazione del caso d uso Process Sale Scenario : pagamento in contanti di Process Sale Simple cash-only Process Sale scenario:. Il Cliente arriva alla cassa POS con gli articoli e/o i servizi da. Customer arrives at a POS checkout acquistare with goods and/or services to purchase. 2. Il Cassiere inizia una nuova vendita 2. Cashier starts a new sale. 3. Il Cassiere inserisce il codice 3. Cashier enters item identifier. identificativo dell articolo e la 4. System records sale line item and presents quantità item description, price, and 4. running Il Sistema total. registra la riga di vendita Cashier per repeats l articolo steps e 3-4 presenta until indicates la done. descrizione dell articolo, il prezzo e 5. System il totale presents parziale. total Si with ripetono taxes i passi calculated. 3-4 fino a che l operazione non 6. Cashier termina tells Customer the total, and 5. asks Il for sistema payment. mostra il totale con le 7. Customer imposte pays calcolate and System handles 6. payment. Il Cassiere riferisce il totale al... Cliente, e richiede il pagamento 7. Il Cliente paga e il sistema gestisce il pagamento loop : Cashier Process Sale Scenario :System makenewsale [ more items ] enteritem(itemid, quantity) description, total endsale total with taxes makepayment(amount) change due, receipt 40

41 Caso di studio POS (modello di dominio) Records-sale-of 0.. Sales LineItem quantity Contained-in Paid-by Sale datetime / total..* * Ledger Captured-on 0.. Is-for Logscompleted Recordsaccountsfor id Product Catalog Store name address Register Used-by * Houses..* Contains..* Stocks Works-on * Product Description itemid description price * Item Describes..* CashPayment Customer Cashier amounttendered id 4

42 Caso di studio POS Progettazione di makenewsale Scelta del controller. Per il Pattern Controller si hanno le scelte: Facade Controller Store (oggetto radice) Register (un dispositivo fisico su cui gira il sw) POSSystem (rappresenta il sistema complessivo) Controller di caso d uso ProcessSaleHandler o ProcessSaleSession Dato che le operazioni sono poche la scelta ricade su uno dei Facade Controller quindi Si introduce la classe software Register Scelta di chi crea una Sale (vendita) Porzione di interesse del modello di dominio Contratto: makenewsale() Riferimenti: caso d uso ProcessSale Pre-condizioni: nessuna Post-condizioni:. è stata creata una istanza s di Sale 2. s è stata associata con Register 3. gli attributi di s sono stati inizializzati Dall analisi del Modello di dominio si vede che Register registra istanze di Sale quindi: Per LRG si introduce la classe software Sale Per il Pattern Creator è Register che può creare Sale Deve essere creata una collezione vuota che conterrà i SalesLineItem La collezione sarà mantenuta da Sale quindi per Creator Sale è un buon candidato per creare la collezione 42

43 Caso di studio POS 2 Progettazione di makenewsale (diagramma di comunicazione) Per Controller by Creator si sceglie il and Facade Controller Controller Register makenewsale :Register create Register crea Sale per Register Creator creates a Sale by Creator :Sale Per Creator, Sale crea by Creator, una collezione Sale creates an empty che conterrà collection (such as a istanze di List) which will SalesLineItem eventually hold SalesLineItem instances create lineitems : List<SalesLineItem> la specifica di esecuzione è interna al this execution specification is implied to be costruttore si Sale within the constructor of the Sale instance 43

44 Caso di studio POS 3 Contratto Operazione:enterItem(itemID:ItemID,qua ntity:integer) Riferimenti: caso d uso ProcessSale Pre-condizioni: è in corso una vendita Post-condizioni:. è stata creata una istanza sli di SalesLineItem 2. sli.quantity = quantity 3. sli è stata associata con la Sale (vendita) corrente 4. sli è stata associata ad una ProductDescription, in base alla corrispondenza con ItemID Porzione di interesse del modello di dominio Progettazione di enteritem Scelta del controller (Pattern Controller) Si usa Register (Facade Controller) Scelta di chi crea una SalesLineItem Dall analisi del Modello di Dominio si vede che Sale contiene SalesLineItem quindi Per LRG si introduce la classe sw SalesLineItem (Sale già esiste) Per Creator Sale crea SalesLineItem Scelta di chi ricerca una ProductDescription a partire da un itemid (Pattern Expert) Dall analisi del Modello di Dominio si vede che ProductCatalog contiene tutte le ProductDescription quindi Per LRG si introducono le classi software ProductCatalog e ProductDescription L Expert è ProductCatalog. A questo si aggiunge il metodo getproductdescription(id) Register deve poter chiamare il metodo getproductdescription Deve avere Visibilità di ProductCatalog quindi: Si aggiunge a Register una associazione con ProductCatalog 44

45 Caso di studio POS 4 Per Controller by Diagramma di comunicazione Per by Creator enteritem(id, qty) :Register 2: makelineitem(desc, qty) :Sale : desc = getproductdesc(id) 2.: create(desc, qty) Per by Expert :Product Catalog sl: SalesLineItem.: desc = get(id) 2.2: add(sl) : Map<ProductDescription> lineitems : List<SalesLineItem> Aggiunge SalesLineItem alla lista add the newly created SalesLineItem instance to the List DCD catalog... ProductCatalog getproductdesc(...) descriptions {Map}..* ProductDescription description : Text price : Money itemid: ItemID... description Sale... Register enteritem(...)... currentsale iscomplete : Boolean time : DateTime makelineitem(...)... lineitems {ordered}..* SalesLineItem quantity : Integer... 45

46 Caso di studio POS 5 Progettazione di endsale Scelta del controller (Pattern Controller) Si usa Register (Facade Controller) Scelta di chi assegna true a Sale.isComplete (Pattern Expert) Dall analisi del Modello di Dominio si vede che iscomplete è mantenuto da Sale Per Expert è Sale che deve modificare iscomplete quindi si aggiunge a Sale il metodo becomecomplete Scelta di chi calcola il totale della vendita Dall analisi del Modello di Dominio si vede che Sale contiene SalesLineItem quindi: Per Expert è Sale che deve restituire il totale quindi si aggiunge gettotal a Sale Contratto Operazione:endSale() Riferimenti: Casi d uso: ProcessSale Pre-condizioni: è in corso una vendita Post-condizioni:. Sale.isComplete = true Porzione di interesse del SSD Scelta di chi calcola il subtotale (totale di una SalesLineItem) Per il calcolo del subtotale è necessario conoscere SalesLineItem.quantity e ProductDescription.price Dall analisi del Modello di Dominio si vede che SalesLineItem ha come attributo quantity ed è associato a ProductDescription Per Expert è SalesLineItem che deve restituire il subtotale quindi si aggiunge il metodo getsubtotal 46

47 Caso di studio POS 6 endsale( :Register : becomecomplete s :Sale Per by Controller Per by Expert Expert Per Expert by Expert Per Expert by Expert UML: UML: la notazione note the selector indica l iesimo notation elemento to select della elements collezione from the lineitems collection tot = gettotal :Sale * [i =..n]: st = getsubtotal lineitems[ i ]: SalesLineItem.: pr = getprice :ProductDescription 47

48 Caso di studio POS 7 Contratto Operazione:makePayment(amount:Money) Riferimenti: caso d uso ProcessSale Pre-condizioni: è in corso una vendita Post-condizioni:. è stata creata una istanza p di Payment 2. p.amounttendered = amount 3. p è stata associata con la Sale (vendita) corrente 4. la Sale corrente è stata associata con lo Store Porzione di interesse del modello di dominio Progettazione di makepayment Scelta del controller (Pattern Controller) Si usa Register (Facade Controller) Scelta di chi crea una Payment Dall analisi del Modello di Dominio si vede che Register registra e Sale utilizza strettamente Payment 2 candidati: Register e Sale. Si valutano le alternative con Low Coupling e High Coesion Per Low Coupling la scelta è Sale Scelta di chi registra le vendite completate Dall analisi del Modello di Dominio si vede che può essere la classe Ledger Scelta di chi è il responsabile di conoscere il resto Per calcolare il resto è necessario conoscere il totale della vendita e l importo in contanti Gli Expert parziali sono Sale e Payment 2 alternative: Payment responsabile principale e Sale secondario o viceversa. Si valutano le alternative con Low Coupling e High Coesion Per Low Coupling la scelta è: Sale responsabile principale e Payment secondario (Sale è già accoppiato a Payment perchè lo crea) 48

49 Caso di studio POS 8 Registrazione vendita completa Per Controller note that the Sale instance is named 's' so that it can be referenced as a parameter in messages 2 and 2. Per Creator e Low Coupling makepayment(cashtendered) :Register : makepayment(cashtendered) s :Sale Per Expert by Expert 2: addsale(s) :Store.: create(cashtendered) :Payment Diagramma di interazione per calcola resto 2.: add(s) completedsales: List<Sale> { bal = pmt.amount - s.total } bal = getbalance s :Sale : amt = getamount pmt: Payment 2: t = gettotal Per Expert e Low Coupling 49

50 Caso di studio POS 9 DCD Store address : Address name : Text addcompletesale(...) catalog catalog ProductCatalog... getproductdesc(...) descriptions {Map}..* ProductDescription description : Text price : Money itemid: ItemID... register... Register endsale() enteritem(...) makenewsale() makepayment(...) currentsale completedsales {ordered} Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem(...) makepayment(...) gettotal() * lineitems {ordered} payment..* SalesLineItem quantity : Integer getsubtotal() Payment amount : Money... description 50

51 Caso di studio POS 0 Connessione dello strato UI allo strato di dominio presses button Cashier actionperformed( actionevent ) UI Layer Domain Layer :ProcessSale JFrame :Register : enteritem(id, qty) Nel Main si effettuano i seguenti step si crea l oggetto UI si crea il Facade Controller Register si system rende event visibile Register all oggetto UI Successivamente ogni azione sull UI viene trasformata in una chiamata a Register 5

52 Caso di studio POS Caso d uso di avviamento StartUp del sistema e creazione dell oggetto di dominio iniziale Un oggetto radice rispetto alla gerarchia di contenimento Viene pass passato a reference a to Register the ProductCatalog il riferimento to the a ProductCatalog Register, so that it in has modo permanent che abbia visibility visibilità to it permanente ad esso create :Store 2: create(pc) :Register Per by Creator : create Crea un oggetto create an empty collezione collection object vuoto.: create pc: ProductCatalog.2.2*: put(id, pd) descriptions: Map<ProductDescription>.2: loadprodspecs().2.*: create(id, price, description) l * nel numero di sequenza indica che il messaggio the * in sequence è ripetuto number indicates the message occurs in a repeating section pd: ProductDescription 52