Teoria Pattern Grasp - Domanda teorica all'esame

Pattern GRASP

martedì 28 maggio 2019

10:32

Cosa sono i pattern GRASP?

I pattern GRASP sono 9 pattern generali che ci guidano nella scelta per l'assegnazione delle responsabilità del software, poiché noi facciamo una progettazione guidata dalle responsabilità. Questi propongono soluzioni esemplari generali a problemi di progettazione comuni. Nello sviluppo iterativo, per garantire la modificabilità e comprensibilità, bisogna organizzare il codice in moduli debolmente accoppiati e fortemente coesi.

Questo perché necessitiamo di un meccanismo iterativo. (Flessibile e facilmente modificabile ---> caratteristiche del codice).

Per sostenere la modificabilità e la comprensibilità del codice è bene fare progetti modulabili, altamente coesi e debolmente accoppiati. Oltre a questi pattern valutativi(che permangono comunque i principi base per una buona progettazione per responsabilità degli oggetti), abbiamo bisogno di altre pattern.

CONTROLLER

Problema: qual è il primo oggetto oltre lo strato UI, dove può esserci lo strato application(che si occupa di gestire lo stato delle sessioni) o lo strato del dominio, che riceve e coordina le operazioni di sistema?

Soluzione: o scegliere un controller specifico per il caso d'uso entro cui avviene quella specifica operazione di sistema, quindi si chiamerà control di caso d'uso o di sessione, oppure un controller unico per tutti i casi d'uso e si chiama facade controller e infine la terza scelta che prevede che se abbiamo un'applicazione utilizzata da più tipologie di utente, ciascuno ha un proprio controller.Un oggetto della presentazione(il controller MVC) chiede al controller dello strato del dominio(controller GRASP) di eseguire le operazioni.

CREATOR

Problema: chi crea l'oggetto A? (attività comune e necessaria, svolgerla con un basso accoppiamento)

Soluzione: assegna alla classe B la responsabilità di creare un'istanza della classe A se una delle seguenti condizioni è vera(più sono vere e meglio è)

• B 'contiene' o aggrega una composizione oggetti di tipo A
• B registra A
• B utilizza strettamente A
• B deve essere direttamente partecolare tale oggetto, nel caso corso d'uso l'oggetto di tipo B deve chiedergli eseguire operazioni più volte
• B possiede i dati per l'inizializzazione di A

In questo modo troviamo diversi candidati per la creazione di A. Solitamente ne ha meglio quello che è legato tramite composizione (di tipo concettuale che poi può essere rispecchiata in una composizione di tipo software) all'elemento e lì abita quindi l'aggregazione tra dipendenti dal punto di coding.

Si applicano alla progettazione orientata agli oggetti. Si applicano dove A è un oggetto che ha per qualche motivo una necessità ancora: più conoscente e conoscerne un riferimento all'oggetto creato, ovvero ha un bisogno forte di conoscere e interagire con tale oggetto.Chi mi converrebbe usiamo? ma in che rapporto mi conviene?

INFORMATION EXPERT

Problema generale: qual è il principio di base per assegnare responsabilità agli oggetti?Esempio: chi è responsabile per memorizzare le informazioni trovate? o per rispondere a calcoli? Problemi generici di progettazione.

Soluzione: Assegna responsabilità a quella classe che ha informazioni necessarie per soddisfarle.Spesso negli use case abbiamo informazioni alternative da ottenere. A monte della progettazione, gli esperti delle informazioni possono cambiare dinamicamente.

Nei design information expert, il design info per trovare per soddisfare ricordiamo meglio come.

Se osservate chiaramente l'esempio delle classi Sale(L), Line Item e Product Description (più esperti parziali delle info). la linea guida dice assegna l'opportunità di ottenere il relativo identificatore ad un tipo dominio ente o indirettamente tutte le informazioni. In questo caso scelta la classe Sale, supportiamo la classe Sales con informazioni di price description separatamente e calcoliamo agire con altre classi come SalesItemLine per il calcolo del totale parziale di ciascuna riga di vendita. Alla creazione di una nuova istanza, le informazioni vengono integrate dal lato server.

Pattern GRASP

martedì 28 maggio 2019 10:32

Cosa sono i pattern GRASP?I pattern GRASP sono 9 pattern generali che ci guidano nella scelta per l'assegnazione delle responsabilità del software, poiché noi facciamo una progettazione guidata dalle responsabilità. Questi propongono soluzioni esemplari generali a problemi di progettazione comuni. Nello sviluppo iterativo, per garantire la modificabilità e comprensibilità, bisogna organizzare il codice in moduli debolmente accoppiati e fortemente coesi (* principio di progettazione fondamentale della modularità).Questo perché necessitiamo di un meccanismo iterativo. (Flessibile e facilmente modificabile ---> caratteristiche del codice).

Per sostenere la modificabilità e la comprensibilità del codice è bene fare progetti modulari, altamente coesi e debolmente accoppiati. Oltre a questi pattern valutativi( che permangono comunque i principi base per una buona progettazione per responsabilità degli oggetti), abbiamo bisogno di altre pattern.

CONTROLLER

Problema: qual è il primo oggetto oltre lo strato UI, dove posso esercire lo strato application(che si occupa di gestire lo stato delle sessioni) o lo strato del dominio, che riceve e coordina le operazioni di sistema?

Soluzione: o scegliere un controller specifico per il caso d'uso entro cui avviene quella specifica operazione di sistema, quindi si chiamerà control di caso d'uso o di sessione, oppure un controller unico per tutti i casi d'uso e si chiama facdde controller e infine la terza scelta che prevede che se abbiamo un'applicazione utilizzata da più tipologie di utente, ciascuno ha un proprio controller.Un oggetto della presentazione(il controller MVC) chiede al controller dello strato del dominio(controller GRASP) di eseguire le operazioni.

CREATOR

Problema: chi crea l'oggetto A? (attività comune e necessaria, svolgerla con un basso accoppiamento)

Soluzione: assegna alla classe B la responsabilità di creare un'istanza della classe A se una delle seguenti condizioni è vera(più sono vere e meglio è)

• B 'contiene' o aggrega una composizione oggetti di tipo A
• B registra A
• B utilizza strettamente A
• B deve saper inizializzarne tale parte

In questo modo troviamo diversi candidati per la creazione di A. Solitamente ha la meglio quello che è legato tramite composizione (di tipo concettuale che poi può essere rispecchiata in una composizione di tipo software) all'elemento pattern del creator, il prossimo è quello con un punto di aggancio minori.

L'interfaccia di registrazione, creazione (e distrugge) di quest'oggetto è creata.

INFORMATION EXPERT

Problema generale: qual è il principio di base per assegnare responsabilità agli oggetti?E: bisogna sapere chi deve avere determinata responabilità. E chi possiede queste informazioni? Problemi generici di progettazione.

Soluzione: assegna una responsabilità a quella classe che ha le informazioni necessarie per soddisfare la responsabilità.

Bella contropartita si ha per gli oggetti che hanno molto agevolmente attraverso le strategie la progettazione, gli esperti delle informazioni possono cambiare dinamicamente.

Esempio: il caso delle classi Sale, Customer e Product Description (più esperti parziali delle info). La linea guida dice assegna responsabilità all'informazione più importante a una classe che contiene o indirettamente tutte le informazioni. In questo caso scelta la classe Sale, perché essa contiene o riferisce tutte le informazioni per agire con altre classi come SalesLineItem per il calcolo del totale parziale di ciascuna riga di vendita. Dobbiamo definire bene le responsabilità per progettare.

Esempio: chi deve essere responsabile del calcolo del totale di una vendita? (interrogazione di sistema) Chi sono gli oggetti che hanno informazioni riguardo il totale della vendita? In questo caso sono distribuite tra Sale, SalesLineItem e Product Description (più esperti parziali delle info).

La linea guida dice assegna all’oggetto dominante nella conoscenza di queste info, ovvero che conosce o la maggior parte delle info o che conosce direttamente o indirettamente tutte le informazioni. In questo caso viene scelta la classe Sale, considerata come la radice dell’albero delle info considerando i collegamenti nel progetto. Poi successivamente Sale dovrà interagire con altre classi come SalesLineItem per il calcolo del totale parziale di ciascuna riga di vendita (collaborazione con altri oggetti , metodologia CRC - CLASSI, RESPONSABILITA’ E COLLABORAZIONI).

Domande principali: Quale info servono? Chi sono gli esperti di tale info? Quali potrebbero essere le collaborazioni?

Tale pattern può essere letto in due modi:

• Uno puramente software, inibizione causato sul fatto che le classi hanno variabili di distanza private e quindi solo le classi stesse posso accedere a tali oggetti. Ragionamento compatibile con l’incapsulamento delle informazioni, favoriscono un basso livello di coesione, in quanto due operazioni coabitano in una stessa classe, accoppiamento basso perché un oggetto non deve andare a chiedere le variabili d’istanza di uno altro oggetto. Ciascuno oggetto fa cose relative alle info che gestisce.
• Congelamento e segregazione delle responsabilità e il rientramento di tipo conoscitivista. Nella maggior parte delle volte sono obbligati da un punto di vista software. Assegnazione di responsabilità a oggetti software che non agiscono a livello concettuale. Mon mondo reale le vendite iniziali da parte dei clienti, ma nel nostro progetto radi sono i controllori.
• Chic * non negare i suggerimenti. Nel mondo reale se vendiamo un articolo qualsiasi ci sarà un bd in cui relazionare. Second IE è la versione nel bd nel, tuttavia è un suggerimento pessimo, in quanto da un punto di vista dell’’accoppiamento la classe Sale è nello strato del dominio e dovremmo scriverci istruzioni SQL che appartengono invece allo strato più basso. Inoltre anche a livelli di coesione, conterrebbe info sul dominio della vendita che aspetti relativi alla persistenza della vendita che sono responsabilità completamente separate.
• Vantaggi: incapsulamento dell’informazione e per questo sostiene un accoppiamento basso e distribuisce il comportamento tra le diverse classi che partecipano alla soluzione, perché normalmente non è una sola classe che esegue l’algoritmo ma c’è una collaborazione con altre classi.

Premesse generali a low coupling e high coesion:

ACCOUPPIAMENTO:

È una misura (potrebbe essere espresso con un numero) di quanto fortemente un elemento è connesso ad altri elementi ,il conosce o dipende da essi. Tale numero viene calcolato da strumenti appositi costosi. Tale misura non ha un valore assoluto, ma serve come confronto , bisogna sempre vedere il livello di riferimento che si ha nel progetto, sulla base di questo si può dire che l’accoppiamento è basso o alto. Misura la connessione tra gli elementi, è diversa dalla sola dipendenza, poiché bisogna considerare il “fortemente”(devo ridurre la loro forza e non le dipendenze). Per esempio andare a cedere una variabile d’istanza di B e peggio che andare ad invocare un metodo dell’oggetto di B, in UML la dipendenza è la stessa ma il solo livello di ispezione diverso. Si possono anche fare ragionamenti intuitivi senza calcolare un vero e proprio numero.

Accoppiamento fra una coppia di elementi può essere:

• ebase/ debase : dipende in modo debole da un altro elemento, per esempio dipende dalle Sale e non dai membri delle variabili d’istanza
• forte: aspetti concettuali relativi alla gestione di altri elementi

Esistono diversi tipi di accoppiamento:

• Tre forma di accoppiamento autodisciplinato: due oggetti dipendono dai dati interni, qualcosa che accade all’interno della classe, ovvero quando si viola il principio dell’incapsulamento dell’informazione.
• Un’altra forma di accoppiamento internazionale : quello che è per dati globali, ovvero oggetti di altro cui (in Java). Considerate in questo modo, perché una classe dovrebbe essere libera di riusare i suoi propri parametri.
• Un’altra forma di accoppiamento non necessario a quello che è una propensione ad un elemento, ovvero un oggetto che si associa ad un oggetto, ognuno potrebbe avere una variabile di riferimento alla suddetta classe.
• Un’altra forma di accoppiamento esterno ovvero , solo per formare dove funziona attraverso un’interfaccia, affidano comportamenti informatici senza dover riferimenti specificati;
• Un altro accoppiamento stampato invece, per i concetti di base, più importante è una revisione di classi o costruire operazioni di sistema senza essere ibride di alcune operazioni;

Considerate che il tipo specifico è quello ciclico.

*Per tale concetti resta il problema complesso

Se abbiamo la necessità di comunicazione multidirezionale lo accoppiamento è temporaneo però il metodemi più basso possibile resta sincronizzato tra tutte le classi della catena chiusa , deve essere in ogni variabile di interfaccia.

Corrisponde a non motosoabbhe dove aggrego e formano dell’accoppiamento che sono sempre tutte una funzione diversa che gestisce interfaccia di grosse quantità

Note: Normalmente l’accoppiamento è alto, se nel design ordinario è alto dopo anche si ritorce in due test, è quindi sempre più vicino al presente (devo farlo tutti i metodi ,dovrà tutti i relativi test). Quindi è più piacevole la classe, meno forte presentare più informazioni congiutatene, ad avere tanto.

La coesione, invece, spesso devia che a fronte della necessità di accoppiamento è forte, visto che è probabile l’accoppiamento e quindi sarebbe anche debba formare più cose, più è alto più è alta la probabilità che debba formare tutti gli oggetti che richiedono il calcolo.

Analisi e Progettazione Software - Teoria

L'accoppiamento è una misura della probabilità della propagazione dei cambiamenti più l'accoppiamento è basso più è bassa la probabilità che debba modificare più cose, più è alto più è alta la probabilità che debba modificare l'elemento e gli elementi che dipendono da esso.

Per ridurre i costi bisogna ridurre la probabilità di propagazione dei cambiamenti.

COESIONE FUNZIONALE: è una misura della forza delle correlazioni delle responsabilità assegnate ad un elemento software

in particolare ad una classe (per esempio della lunghezza di una classe, numeri di metodi di una classe, lunghezza media o max di un metodo ecc...), ovvero risponde alla domanda " Con che criterio hai assegnato questa responsabilità a questo elemento?". Diversi criteri, diverse coesioni. Se le responsabilità sono fortemente cose tra loro ovvero se i dati e le operazioni sono correlate tra loro, abbiamo una coesione alta, altrimenti se abbiamo nella classe metodi che operano su dati che non c'entrano niente con la class o si stanno operazioni correlate diremo che la coesione è bassa.

Potremmo dire che la coesione è una misura di quanto lavoro esegue un elemento software, tale lavoro non va inteso come quante volte invoco iterazioni e metodi ma i metodi e quanto sono lunghi. - Coesione alta: se i dati e le operazioni correlate sono tra le stesse. relativiamente poche operazioni - Coesione bassa: se e ci sono operazioni scollegate che invocano relativanemte pochi metodi.

La coesione in generale risponde alla domanda " Con che criterio hai assegnato questa responsabilità a questo elemento?". Diversi criteri, diverse coesioni, ne analizziamo quattro. Associazione di dati: se metto due classi di clienti una con A, ma non è un buon criterio per assegnare responsabilità'. Inoltre abbiamo la coesione "temporale" ovvero metto in una classe delle operazioni che devono essere utilizzate più o meno nello stesso tempo. E' una buona forma di coesione per un controller. Per gli oggetti dello strato del dominio non è un buon criterio, più per quelli dello strato di presentazione.

Due criteri di buona coesione per lo strato del dominio sono quella funzionale e quella dei dati, quest'ultima comporta che una classe che rappresenta un tipo di dato come per esempio una classe che rappresenta un importo monetario, mentre quella funzionale quando una classe rappresenta funzionalità correlate, per esempio una classe che gestisce le operazione della vendita o la gestione degli sconti.

Accoppiamento e Coesione sono misure utilizzare per il confronto di progetti alternativi. Solitamente quando l'accoppiamento migliora, migliora anche la coesione.

Inoltre in accoppiamento basso e una coesione alta agevola una migliore comprensione del codice. Un fattore che sicuramente non agevola è la duplicazione del codice, in quanto genera elementi fortemente accoppiati tra di loro. CASI LIMITE: Perché non mettere l'accoppiamento a zero? Perché poi le dipendenze diminuiscono e arriviamo ad un caso un cui un oggetto deve fare tutto e non vi è più coesione. Coesione massima: Classe che ha solo un metodo, non c'è solo una istruzione, un caso scarso ho creato un oggetto di tanti collegamenti , di conseguenza avremo un accoppiamento alto.

LOW COUPLING:

Problema: sostenere delle dipendenze basse e cambiamenti bassi. L'impatto del cambiamento deve essere più basso: ogni volta che devo effettuare una modifica non devo modificare altri elementi. Come sostengo la propagatione dei cambiamenti eliminare o ridurre la possibilità di propagazione di cambiamenti?

Soluzione: Assegnare responsabilità che sono connesse non necessariamente rimangano basse. Elementi non forti, ovvero aiuto e affronteremo delle varie attività.

Rispondo altre, quando prendo una classe, de finisco questa o quella classe deve far riferimento ai dati.

Accoppiamento residevo: nel caso una sala fallisce l'attività allora vedi metodi per eseguire insieme mysql e Sale. Accorpare entrambi i progetti. Nel caso di Register ci sta un accoppiamento non eccessivo (diciamo che il metodo "GetCashPayment" debba per forza calcolare le dipendenze per ricevere class Payment , per la classe Register che sono dipende da CP. Nel primo accoppiamento alto sono educativi) se vi è fisica e coesione.

HIGH COESION:

Problema: avere degli oggetti focalizzati, comprensibili e gestibili. Come effetto sostenere low coupling, ovvero sostenere classi che sono facilmente modificabili.

Soluzione: assegnare responsabilità affinchè le classi siano sia testasibili che proposte ad altri pattern.

I controlli che praticamente globali i dettagli di quadratura non sono di un controllore il primo esempio trovato che generalmente ha funzionalità multipla, però in questo caso leggeremo tutte nazione, però il primo elemento firstprint cui produce sulla video, generalmente più o nella, inferiore, nel caso, quindi una struttura sufficientemente aggiornata scrivete in classi Register ha già la responsabilità di essere il Console e Project, in molti Gel efficienti un particolare che nel CAP.