il refactoring software come metodo di base

8/8/2019 Il refactoring software come metodo di base

1/19

1

Refactoring: la teoria in praticaIng. R. Turco


2/19

2

Introduzione

NellObject Oriented mi sono sempre sforzato di verificare lapplicabilit di ogni teoria appresa,cos da poter riusare, tutto o parte di essa, in modo ripetibile e tracciabile: teoria, analisi,

disegno, pattern, documentazione, etc.

In questo articolo mi propongo di esporre, miscelando insieme, teorie apprese, esperienzepersonali e riflessioni sullargomento.

Il refactoring: la giusta definizione

Il refactoring mi ha sempre notevolmente affascinato per le sue notevoli potenzialit. Tuttaviaquando parliamo di refactoring necessario definire bene cosa intendiamo.

In [DR2] si visto che per la fase di costruzione, sia per un Rational Unified Process o per altri

processi produttivi come Agile o Estreme Programming, le iterazioni sono incrementali per lefunzionalit; mentre sono iterative a riguardo del codice appena realizzato.

Il refactoring, quindi, potrebbe essere definito come la parte iterativa delliterazione diprocesso produttivo, finalizzata a migliorare il codice, a renderlo stabile, riusabile, manutenibilee flessibile, fermo restando il comportamento finale del codice stesso.

Di per s gi una grande definizione! Tuttavia questa definizione solo una vista di unamedaglia a due facce!!

Il refactoring , in realt, sia di natura preventiva che adeguativa, per cui parlereidellesistenza di due tipi di refactoring:

Il Design Refactoring; LImplementation Refactoring.

Design Refactoring

Il Disegn Refactoring finalizzato a migliorare il modello del disegno per ottenere stabilit,riusabilit, manutenibilit e flessibilit del sistema. E preventivo, perch, se il sistemasimplementa secondo le sue direttive, si ottiene un prodotto che ha gi in s delle bestpractices, grazie al disegno.

Il Design Refactoring, difatti, si basa essenzialmente su alcuni principi, che vedremo in seguito,e sulluso dei Pattern [DR5][DR6].

Lobiettivo del Design Refactoring di tendere a migliorare la qualit del prodotto poich lescelte vengono prese preventivamente nellarchitettura e nel disegno (Pattern architetturali,Design Pattern, etc) per cui si tende a ridurre il numero di errori del prodotto.

Io applico il Design Refactoring appena dopo la modellazione UML a colori [DR3], perch conquestultima tendo prima a capire il modello; poi col Design Refactoring, invece, tendo amigliorare il sistema, introducendo gli adeguati Pattern architetturali ed i vari Design Pattern.

Fermarsi solo alla modellazione UML a colori servirebbe solo ad individuare un modello cherispecchia la realt, conferendogli stabilit, ma non si ancora fatto nulla per problematiche diriusabilit e flessibilit, che sono quelle per cui lObject Oriented ritenuto estremamentevalido.


3/19

3

Booch ha, inoltre, affermato che un modo per vedere la qualit di un sistema ben strutturato quello di osservare come i suoi disegnatori e implementatori abbiano applicato i concetti deiPattern.

Implementation Refactoring

LImplementation Refactoring, invece, per natura adeguativo.

Se stato fatto un ottimo Design Refactoring, allora lImplementation Refactoring si limita arinominare classi, variabili e metodi, spostare le classi di package, cambiare la visibilit diclassi, variabili e metodi, costruttori, aggiungere assert, etc. Alcuni principi che vedremo diseguito sono prettamente tipici dellImplementation Refactoring e di, conseguenza,prettamente orientati alla manutenzione.

Design Refactoring o Implementation Refactoring?

La risposta : entrambi, nel loro giusto peso, secondo laccezione di cui sopra.

Occorre scrivere il software solo quando si ha una chiara visione del modello, e, comunque,solo dopo averne fatto del sano Design Refactoring; per cui un Implementation Refactoringdovrebbe essere di entit contenuta, al punto di poterlo sostenere facilmente nellambito diuniterazione!

Inoltre se gli sviluppatori hanno uno strumento, con cui sono sia in grado di disegnare chedimplementare (Vedi Together per Java o Rational Rose), lattivit possibile in manieraintegrata e secondo un continuo che porta dallOOA all OOD e allOOP.

Fig. 1

Anche se si dovessero ricevere dei requisiti imprevisti che possono impattare sullarchitettura,il consiglio prima di modellare: indispensabile! [DR3].

LImplementation Refactoring assume maggiore peso solo per software non noto, ma anchequi possibile con degli strumenti fare il reverse engineering ed ottenerne il modello; poilavorare su esso, fare il forward engineering e limplementazione di dettaglio. E un processocontinuo (fig. 1).

Modellazione e Design

Refactoring

Forward Engineering

e Implementation

Refactoring

Prodotto

Reverse Engineering

del Modello o

generazione del

Modello


4/19

4

Refactoring: le best practicesIn [DR3] si parla di Guidelines, Pattern e anti-Pattern (Pattern sconsigliati).

Anche per il refactoring non sarebbe difficile snocciolare una serie di Guidilines, di ci che

non bisogna fare e cosa, invece, occorre fare.

Tuttavia in [DR3] si dimostra che le Guidelines sono spesso incomplete, prive di contesto, diformulazione del problema e non forniscono alcuna soluzione ed esempi. Al contrario i Pattern[DR5][DR6] e gli anti-Pattern.

Il refactoring influenzato da molti concetti: stabilit del software, riuso, manutenibilit,flessibilit, viscosit, etc. Tutti concetti che riguardano anche settori e tipologie di personediverse: sviluppo, manutenzione, versioning, metriche, deploying etc.

Per cui esiste un modo completo ed originale per parlare di refactoring in modo rigoroso, comein [DR4]. Si pu partire da alcuni principi di base dimostrabili fino ad arrivare alle bestpractices del Design Refactoring o dellImplementation Refactoring.

I sintomi della degradazione del softwareNel seguito vedremo i sintomi, le cause e la prevenzione del fenomeno degrado del software.

Il Design Refactoring costituisce, proprio, la prevenzione al degrado del software.

Occorre innanzitutto capire quali sono i sintomi che possono segnalare che un sistema softwaresi sta guastando.

Rigidit

E la tendenza da parte del software ad essere difficilmente cambiabile. Una modifica anchesemplice comporta un innesco a catena di cambiamenti.

FragilitE la tendenza del software a spezzarsi in molti pezzi ad ogni modifica, fino a diventareimmanutenibile.

ImmobilitE la tendenza ad una difficile riusabilit del software per altri progetti o per altri parti dellostesso software.

Viscosit del disegnoQuando occorre fare una modifica, i software engineers cercano sempre la strada pi semplice.Alcune di queste vie preservano il disegno, altre no.

Se la viscosit del disegno alta, ovvero per preservare il disegno occorre fare una modificaabbastanza difficile, altamente probabile che gli sviluppatori non seguiranno tale strada ed ildisegno non sar preservato.

Viscosit dellambienteSe lambiente di compilazione o quello di versioning lento e inefficiente gli sviluppatoriprenderanno decisioni di sviluppo che riducono limpatto dellambiente; questo per spessoanche a discapito della necessit di preservare il disegno.

Cambiamento dei requisitiNon si pu pretendere che i requisiti non cambino. Hanno una natura volatile che fa parte delladinamicit del business in gioco.


5/19

5

LImportante gestire correttamente i rischi correlati alla variazione di una parte dei requisiti emantenere un minimo di flessibilit del software in modo che possa essere aperto aicambiamenti facilmente.

Le cause della degradazioneUn sistema software perch degrada? In realt la causa da ricercarsi in una dipendenzaarchitetturale impropria tra i moduli del software. In altri termini degrada la dipendenzaarchitetturale e, di conseguenza, anche le possibilit di mantenere il software.

I principi ed i rimediNel seguito esamineremo dei principi che costituiscono un rimedio al degrado dovuto alladipendenza tra i moduli software.

Open Closed Principle (OCP)Un modulo deve essere aperto allestensione e chiuso alle modifiche.

Il principio OCP tipico dellObject Oriented: un nostro modulo deve poter essere esteso perereditariet senza che sia necessario modificarlo internamente. La chiave dellOCP lastrazione object oriented.

Un esempio C++.

Supponiamo di avere del software di Logon che, purtroppo, richiede di essere modificato ognivolta a causa dellaggiunta di un nuovo tipo di modem.

struct Modem {typedef enum Type { hayes, courrier, ernie } type;

};

struct Hayes {Modem::Type type;

// etc};

struct Courrier {Modem::Type type;

// etc};

struct Ernie {Modem::Type type;// etc

};

void Logon( Modem& m, string& pno, string& user, string& password){if( m.type == Modem::hayes)

DialHayes((Hayes&)m, pno);else if(m.type == Modem::courrier)

DialCourrier((Courrier&)m, pno);else if(m.type == Modem::ernie)

DialErnie((Ernie&)m,pno);}

Qui lOCP aiuta a capire che sin dallinizio occorreva progettare il tutto secondo il diagramma infig. 1.


6/19

6

Fig. 2

La soluzione di fig. 2 sfrutta il Polimorfismo dinamico; la cui implementazione sarebbe:

class Modem{public:

virtual void Dial( const string& pno) = 0;virtual void Send( char ) = 0;virtual char Recv() = 0;virtual void Hungup() = 0;

}

Il metodo della classe Logon si ridurr a:

void Logon( Modem& m, string& usr, string& pwd){m.Dial(pno);

}

Esiste in C++ anche una soluzione di Polimorfismo statico, tramite i template:template void Logon(MODEM& m, string& pno, string& usr, string& pwd){

m.Dial(pno);}

Personalmente preferisco la prima soluzione, che da un maggior controllo sui tipi in gioco.

Lereditariet permette di aggiungere altri tipi di modem, lastrazione permette di mettereinsieme la classe del Logon e linterface Modem, ai fini della compilazione, senza pi modificareil metodo Logon ma aggiungendo solo nuovo codice.

Liskov Substitution Principle (LSP)Ogni sottoclasse dovrebbe essere sostituibile con la classe base.

Il principio LSP coinvolge anche il principio Design by Contract (DBC).

Il principio DBC insiste sul fatto che pre-condizioni e post-condizioni devono essere rispettatedal disegno per contratto. Il contratto fra chi ha implementato le classi e chi le usa!


7/19

7

Vediamo perch.

Di per s un programmatore sa che il principio LSP facile a realizzarsi.

Es:void User(Base&);

Derived d ;User(d) ;

Ma sempre possibile farlo? Esiste sempre un modo corretto per ottenerlo?

Vediamo il famoso dilemma Ellisse/Cerchio.

In matematica ricordiamo tutti che un cerchio un caso particolare di ellisse. Per cuiconcettualmente vale il diagramma di fig. 3

Fig. 3

Ma corretto?

Pensiamo agli attributi ed ai metodi di Ellisse. Vediamo la fig. 4.

Fig. 4

La circonferenza erediterebbe un bel po di cose inutili!

Ma soprattutto una circonferenza caratterizzata solo dal centro del cerchio e dalla maggioreascissa (il raggio).

Anche se i due fuochi si fanno coincidere come centro del cerchio, forse qualche problemarimane.


8/19

8

Una prima implementazione difettosa di metodo sarebbe la seguente:

void Cerchio::setFocus( const Point& a, const Point& b){itsFocusA = a;itsFocusB = a;

}

Apparentemente uso un solo punto, ma se applico il DBC scopriamo che c un errore tale cheil principio LCP non rispettato:

void f( Ellisse& e ){Point a (-1, 0);Point b (1,0) ;e.setfocus(a,b) ;e.setMajorAxis(3);assert(e.getFocusA() == a);assert(e.getFocusB() == b);assert(e.getMajorAxis() == 3);

}

Se nellesempio al metodo f passiamo Cerchio anzicch Ellisse, la seconda assert non verificata (DBC) e, quindi, lLCP violato!!

Per far s che lLCP sia valido, ovvero che sia possibile la sostituibilit, occorre che il contrattodelle classe base sia onorato anche dalle classi derivate.

Le violazioni LCP sono una delle cause di errori che vengono rivelate troppo tardi, quando si costruito molto software ed il costo per porvi riparo potrebbe essere elevato.

Lunico modo per evitare un tale errore di segnalare in fase di disegno le pre-condizioni e le

post-condizioni e poi farle implementare con delle assert, nei metodi a cui vengono passatiparametri.

Una pezza implementativa per arginare il danno di una violazione del LCP di inserire, poi,degli if-else nel metodo per testare che loggetto di input sia effettivamente la classe attesa,altrimenti viene alzata uneccezione.

Per cui una violazione LCP conduce, come pezza, ad una latente violazione OCP.

Dependency Inversion Principle (DIP)Dipendere dalle astrazioni e non da concetti concreti.

LOCP un obiettivo architetturale dellObject Oriented, il DIP il concetto base che consentelOCP.

Ci sono alcune considerazioni da fare. Usando tale tecnica possibile anche creare degli hot-spot o degli hinge-points che permettono di agganciare altro software (rispetto dellOCP);quindi si possono creare dei framework.

Se usiamo una interfaccia e, poi, deriviamo le altre classi, non possiamo istanziareuninterfaccia. Sembrerebbe che questo ci metta KO definitivamente!

Fortunatamente i Design Pattern ci forniscono molti meccanismi tra cui la ABSTRACT FACTORYo il FACTORY METHOD, etc.

Per cui astrarre possibile ed utile, ma poi dobbiamo usare i Design Pattern [DR5][DR6].


9/19

9

Il DIP ci suggerisce, cio, che un sano Design Refactoring che porti a vantaggi di stabilit,flessibilit e riusabilit passa inevitabilmente attraverso luso e la scelta di Design Pattern.

Interface Segregation Principle (ISP)Molte interfacce, una per client, meglio di avereununica interfaccia general purpose pertutti i client.

In fig. 5 si vedono due client che dipendono dai metodi di ununica classe Service o interfacciache li serve tutti.

Fig. 5

Una tale situazione da evitare.

Se un cambiamento fatto ad un metodo del Client A, ci pu essere uninfluenza sul Client B.

La soluzione al problema la fig. 6, che rispetta lISP.

Fig. 6


10/19

10

Principi di Package ArchitectureFinora abbiamo visto principi generali dellobject oriented, che insistono sullastrazione.

Nellorganizzazione di unarchitettura le classi da sole non sono sufficienti. Esistono i package, i

pacchetti applicativi riusabili.

Per i package esistono tre principi architetturali.

Release Reuse Equivalency Principle (REP)La granularit del riuso la granularit della release

In generale un componente, una classe, un package, un applicativo sottoposto ad unostrumento di versioning del software e di tracciamento anomalie.

Se un cliente usasse un componente che continuamente un autore modifica e non vi fosseversionamento e garanzia del supporto della versione di componente precedente, allora nessuncliente accetterebbe di usare tale componente. Per cliente sintende sia un cliente interno uncliente esterno.

Questo vuol dire che un cliente usa (o riusa) il componente allinterno di una release diprodotto; per cui la granularit del riuso pari a quella della release del prodotto o del gruppoclassi in un package.

Common Closure Principle (CCP)Le classi che cambiano insieme,vivono insieme

I grandi progetti hanno una rete di package e la loro manutenzione, test, gestione non banale.

Pi alto il numero di classi e package da cambiare pi alto il lavoro da fare per fare larebuild ed i test.

Unidea potrebbe essere di raggruppare insieme in un package le classi che pensiamo cambinoinsieme. Questo porta a ridurre limpatto del cambiamento nel sistema.

Alcune considerazioni sul CCP.

Questa tecnica per va ponderata attentamente, perch potrebbe essere a discapito dellalogica di mettere insieme le classi correlate. Va bene, invece, quando la cosa riguardacomunque classi correlate logicamente.

Tale tecnica orientata soprattutto a chi fa manutenzione.

Potrebbe essere una tecnica adottata momentaneamente, cio nella fase di movimentazionedel prodotto; mentre nella fase matura del prodotto si riportano le classi in package diversiusando un Implementation Refactoring.

Common Reuse Principle (CRP)Classi non riusate insieme non dovrebbero essere raggruppate insieme

Ci capitato nella vita di fare sicuramente un upgrade di sistema operativo e poi, a volte, un

applicativo di nostro interesse non funzionava pi AS IS; ma occorreva fare un porting.

Ebbene se fossero raccolte insieme delle classi che non sono riusate insieme potrebbesuccedere che facendo un cambiamento a parte di esse devo fare uno sforzo a testarle tutte e


11/19

11

riverificarle tutte anche per la parte che non dinteresse per il funzionamento di un certoapplicativo.

Va evitata una situazione del genere.

I tre principi REP, CCP, CRP sono mutuamente esclusivi: non possono essere soddisfatti

contemporaneamente, perch diretti a figure professionali diverse. REP e CRP interessano a chifa riuso, CCP interessa a chi fa manutenzione.

Il CCP tende a fare i package quanto pi grandi possibile, almeno fino a comprendere tutte leclassi che variano insieme. Il CRP tende a fare package piccoli.

I tre principi interessano solo lImplementation Refactoring.

Principi di Package Coupling

Acyclic Dependencies Principle (ADP)Le dipendenze tra packages non devono essere cicliche

Vediamo il caso di fig. 7 per comprendere il principio.

Fig. 7

Supponiamo che per inviare un errore a video dal package CommErr decido di chiamare unoggetto della GUI. In questo caso le dipendenze dei package si trasformano come quelle in fig.8.


12/19

12

Fig. 8

In questo caso si introdotto un ciclo. Ma soprattutto un extra-lavoro! Infatti chi sta lavorandocon Protocol per ricostruire la sua test suite ha bisogno di:

- CommErr- GUI- ModemControl- Analysis

Mentre in fig. 7 chi lavorava su Protocol avrebbe avuto bisogno solo di CommErr!!!

Le soluzioni sono:- introdurre un altro package e cambiare il verso della dipendenza, per spezzare il ciclo

(fig. 9);- usare il DIP e lISP


13/19

13

Fig. 9

Stable Dependencies Principle (SDP)Dipendere nella direzione della stabilit

Il concetto di stabilit non ha niente a che vedere con la frequenza dei cambiamenti.

Un package X da cui dipendono altri package detto stabile, perch un suo cambiamentoinfluenza i package sottostanti. O dicendola in altro modo X ha dei buoni motivi per noncambiare. Il package X detto anche indipendente ma una sua eventuale variazione influenzagli altri package.

Un package Y che dipende da tre package sopra alquanto instabile.

Per capire la stabilit possono essere introdotte delle metriche semplici.

Metrica: Stabilit

Indichiamo con:

Ca incomming dependenciesCe outgoing dependenciesI Instability

I = Ce/(Ca+Ce)

Linstabilit ha un range [0,1].

Se non vi sono dipendenze uscenti (Ce = 0 ) allora I = 0.Se non vi sono dipendenze entranti (Ca = 0 ) allora I = 1.


14/19

14

Riformulando SDP conviene Dipendere sopra package dove I pi basso del proprio

Ma flessibilit e stabilit vanno daccordo? In realt no in termini di dipendenza, s in termini diastrazione. Vediamo perch.

Supponiamo che un package Y sia flessibile ai cambiamenti e dipenda da X; mentre X dipendada A, B, C.

Sebbene tra Y ed X abbiamo rispettato lSDP, una variazione di Y porta cambiamenti in X, maanche in A,B,C. Quindi c una violazione dellSDP!!

La flessibilit difatti non va ottenuta attraverso le dipendenze ma sfruttando lastrazione comevedremo nel prossimo principio.

Stable Abstraction Principle (SAP)I Pacchetti stabili devono essere astratti.

E una conclusione a cui siamo arrivati dimostrando una violazione del SDP e che discendedallOCP.

Metrica: Astrattezza

Indichiamo con:

Nc numero di classi nel packageNa numero di classi astratte nel packageA astrattezza

A = Na/Nc

La metrica A ha un range [0,1].

A=0 quando non ci sono classi astratte.A=1 quando ogni classe del package una classe astratta.

Il grafico I-A

Fig. 10

Dal grafico Instabilit-Astrattezza di fig. 10 si vede che al diminuire di A aumenta I. Aldiminuire di I, invece A aumenta.

Nel grafico I-A il punto in alto a destra indica la massima astrattezza e nessuna dipendenzaentrante (A=1, I=1) ed una zona inutile.


15/19

15

Il punto in basso a sinistra di nessuna astrattezza (package concreti) e vi sono dipendenzeentranti (A=0, I=0). E il caso peggiore per un package.

E importante, quindi, massimizzare la distanza tra le due zone (A=1, I=1) e (A=0, I=0) con lalinea chiamata Main sequence

Metrica: Distanza

Se conosciamo A ed I del nostro package possiamo sapere quanto il nostro package lontanodalla Main Sequence:

D = | A+I-1|/2 con range [0, 0.707].

D la distanza normalizzata = | A + I 1|.

D = 0 significa che il package sulla Main Sequence.

Metriche di un modello

Abbiamo precedentemente individuate alcune metriche: Stabilit; Astrattezza; Distanza.

Questo significa che dato un modello possibile valutarne tali metriche.

E possibile utilizzare, quindi, un add-in per Rational Rose, facilmente reperibile su Internet,che permette di valutare le metriche definite da Robert Martin. E, quindi valutare il modello

realizzato, sia dopo la modellazione a colori, sia dopo il Design Refactoring.

Ladd-in scaricabile anche cliccando sul presente link.

Pattern

I Pattern, in generale, servono, quindi, nella fase di Design Refactoring e sono dei buildingblock precostituiti e gi ampiamente collaudati in molti progetti nel mondo.

Riusare un pattern , quindi, garanzia di una corretta soluzione al nostro contesto e problema.

I Pattern sono ampiamente classificati e forniscono idee su vari aspetti architetturali e didisegno (fig. 11); alcuni pattern utili sono:

- Layer (architetturale)- Pipe and Filters (architetturale)- Abstract Server (architetturale)- Adapter (strutturale)- Observer (comportamentale)- Bridge (strutturale)- Abstract Factory (creazionale)- etc

E consigliata vivamente la lettura di [DR5][DR6], ma, possibilmente, di tutti i riferimenti

indicati al termine dellarticolo.
http://www.geocities.com/SiliconValley/Port/3264/corsi/refactoring/addin.ebshttp://www.geocities.com/SiliconValley/Port/3264/corsi/refactoring/addin.ebshttp://www.geocities.com/SiliconValley/Port/3264/corsi/refactoring/addin.ebshttp://www.geocities.com/SiliconValley/Port/3264/corsi/refactoring/addin.ebs


16/19

16

Fig. 11

Under Engineering e Over Engineering

Abbiamo appreso che il refactoring fondamentale perch dovrebbe consentirci ad arrivare adun modello ed ad un sistema ingegnerizzato, riusabile e aperto ai cambiamenti.

Il non farlo (under engeneering) ovviamente sconsigliato. Il farlo troppo (over engineering) un costo aggiuntivo inutile.

LOver Engineering si verifica quando il sistema lo si vuole rendere troppo flessibile o pisofisticato del necessario.

Il tentare di rendere flessibile il codice possibile solo se conosciamo perfettamente comeevolveranno i requisiti, negli altri casi rendiamo flessibile le parti che pi probabilmenteprevediamo verranno intaccate.

Introdurre codice in pi del necessario o pi sofisticato o complesso porta a manutenzione ecosti maggiori.


17/19

17

ConclusioniLa teoria e lesperienza sul campo mi hanno condotto ad assemblare un mio metodo di lavoroper la modellazione dei sistemi:

cerco di ridurre i rischi dei requisiti [DR2]; eseguo la modellazione del dominio con UML a colori, per comprendere il dominio e tutti

gli oggetti in gioco; eseguo un Design Refactoring, applicando i concetti dei Pattern; consiglio gli implementatori, quando necessario, su come comportarsi con i package, la

scelta degli algoritmi necessari, lintroduzione del Design by Contract nel codice elImplementation Refactoring in generale.

Lesperienza mi ha dimostrato che, in questomodo, avviene una crescita culturale dellinteroteam, un aumento della qualit prodotta, un maggior riuso, un minor rifacimento, una minorequantit di lavoro implementativi, un minor numero di errori, un team meno stressato.

La tecnica valida per ogni processo produttivo: Rational Unified Process, Agile, Estreme

Programmino (XP).


18/19


19/19

Riferimenti[DR1] Martin Fowler UML Distilled Prima edizione italiana[DR2] Rosario Turco Usabilit e ripetibilit dei processi produttivi software[DR3] Rosario Turco Modellare con lUML ed i colori

[DR4] Robert C. Martin Design Principles and Design Patterns[DR5] Gamma, Helm, Johnson,Vlissides Design Patterns Elementi per il riuso di software aoggetti Prima edizione italiana[DR6] Rosario Turco - Pattern e la GRASP Oriented Analysis

il refactoring software come metodo di base

Documents