Design Pattern. Ingegneria del Software parte II. Andrea Bei

Transcript

1 Design Pattern Ingegneria del Software parte II 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 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 3

4 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 1977 nel campo delle architetture edili (Christopher Alexander) e si estendono alle architetture software nel 1994 con il testo di Gamma, Helm, Vlissides e Johnson Design Patterns, successivamente denominato Gang of Four (GoF) 4

5 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à 5

6 Design Pattern: classificazione (1/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) 6

7 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. 7

8 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 8

9 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 9

10 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 10

11 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 11

12 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) 12

13 Creator esempio 1 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 13

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

15 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 15

16 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 Si crea ex-novo dal modello di dominio 16

17 Information Expert: esempio 1 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 17

18 Information Expert: esempio 2 Studio di Caso Monopoly Chi ha la responsabilità di conoscere il totale della vendita? time Sale 1 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 1..* * Described-by 1 Product Description description price itemid Modello di progetto t = gettotal :Sale Sale NUOVO METODO New method time... gettotal() 18

19 Information Expert: esempio 2 Studio di Caso Monopoly time Sale Modello di dominio Chi ha la responsabilità di conoscere i totali parziali? 1 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 1..* t = gettotal : Sale 1 *: st = getsubtotal lineitems[ i ] : SalesLineItem * Described-by time... 1 Product Description description price itemid Modello di progetto Sale gettotal() SalesLineItem NUOVO METODO New method quantity getsubtotal() 19

20 Information Expert: esempio 2 Studio di Caso Monopoly Modello di progetto t = gettotal : Sale 1 *: 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 1 Contains Modello di dominio 1.1: p := getprice() :Product Description NUOVO METODO New method SalesLineItem quantity getsubtotal() Product Description description price itemid getprice() Sales LineItem quantity 1..* * Described-by 1 Product Description description price itemid 20

21 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 21

22 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 22

23 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 23

24 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 24

25 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 25

26 Low Coupling: esempio 1 Studio di Caso Monopoly Problema: dato un nome di una Square chi deve avere la responsabilità di restituire la Square corrispondente? 1 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 1 classe) 26

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

28 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) 28

29 Controller Problema: Qual è il primo oggetto oltre allo strato UI a ricevere e coordinare ( controllare ) una operazione di sistema? 1) 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 29

30 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 30

31 Controller: esempio 1 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 1 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 31

32 Controller: esempio 1 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 1 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 ) 32

33 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, 100 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, 10 metodi con un solo tipo di responsabilità (calcoli matematici) è molto coeso 33

34 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 34

35 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 35