Corso di Ingegneria del Software a.a. 2009/2010 Refactoringinfocom.uniroma1.it/~cdainformazione/uploads/IngegneriaDelSoftware/... · Corso di Ingegneria del Software a.a. 2009/2010

Corso di Ingegneria del Software a.a. 2009/2010 Refactoring

Corso di Ingegneria del Softwarea.a. 2009/2010

Refactoring

Mario Vacca

[email protected]


Il problema

Refactoring

Sommario

I Il problema

I Il concetto di refactoring

I Database refactoring

I Bibliografia


Il problema

Concetti di base

Il problema

An intrinsic property of software in a real-world environment is its needto evolve. As the software is enhanced, modified, and adapted to newrequirements, the code becomes more complex and drifts away from itsoriginal design, thereby lowering the quality of the software. Because ofthis, the major part of the total software development cost is devoted tosoftware maintenance [1], [2], [3]. Better software development methodsand tools do not solve this problem because their increased capacity isused to implement more new requirements within the same time frame [4],making the software more complex again.

Tom Mens, Tom Tourwe, A Survey of Software Refactoring IEEE TSE 30(2) 2004, pag. 126


Il problema

Concetti di baseIl problema

Database and software systems are rarely stable following initialimplementation.

Although estimates differ, most agree that 50% or more of programmereffort arises as a result of system modifications after implementation(Lientz 1983) and facilitating those changes is complicated if large numbersof programs or large quantities of data are involved.

Moreover, system modifications that result in changes to database struc-ture are relatively frequent (Sjoberg 1992, 1993). As a result, modifyingthe database schema is a common, but often troublesome, occurrence indatabase administration.

These are significant industrial concerns, both from the viewpoint ofdatabase system manufacturers and information system users.

J.F. Roddick, A Survey of Schema Versioning Issues for Database Systems, Information and

Software Technology, Vol. 37(7):383-393, 1995.


Il problema

Concetti di base

Il problema

MediaWiki has seen, during its 4 years and 7 months of life, 171 differentDB schema versions released to the public by means of a CVS/- Subversionversioning system9.

As one can easily imagine, every schema change has a profound impacton the application queries and the code managing the results, whichmust thus be revised.

In the case of MediaWiki, we observed in our analysis that only a smallfraction (about 22%) of the queries designed to run on old schemaversions are still valid throughout the schema evolution

C. Curino, H. J. Moon, L. Tanca, C. Zaniolo, Schema Evolution in Wikipedia - Toward a Web

Information System Benchmark, ICEIS (1) 2008, Pag. 324


Il problema

Concetti di base

Il problema

Moreover, the evolving context of the web imposes challenges on accommo-dating new functionalities (e.g. an expansion of a corporationıs business)and new data types (e.g. RSS feed messages) in the database.

New schema versions may be released as frequently as twice amonth.

Managing applications that operate on XML documents from differentschema versions can be confusing. However, applications and their usersstill need to interact with XML data regardless of their schema evolution.

M. Moro et al. Preserving XML Queries during Schema Evolution, WWW 2007, pag. 1341


Il problema

Concetti di base

Esempio


Il problema

Concetti di base

Il problema

I Il software ha bisogno di evolvereL’evoluzione e una proprieta intrinseca del software in real-worldenvironment.“As the software is enhanced, modified, and adapted to new requirements, the code

becomes more complex and drifts away from its original design . . . ”

I La qualita del software decade con il tempo

I La parte piu significativa dei costi di sviluppo del softwaresono relativi alla sua manutenzione

I Metodi e tools non risolvono il problemabecause their increased capacity is used to implement more new requirements within the

same time frame [4], making the software more complex again.



Il problema

Concetti di base

L’idea

RIDURRE LA COMPLESSITA DEL SOFTWARE

To cope with this spiral of complexity, there is an urgent need for techniques that reduce softwarecomplexity by incrementally improving the internal software quality. The research domain thataddresses this problem is referred to as restructuring [5], [79] or, in the specific case of objectorientedsoftware development, refactoring [6], [7].



Il problema

Concetti di base

Restructuring e refactoring

To cope with this spiral of complexity, there is an urgent need for tech-niques that reduce software complexity by incrementally improving the in-ternal software quality. The research domain that addresses this problem isreferred to as restructuring [5], [79] or, in the specific case of objectorientedsoftware development, refactoring [6], [7].


Il concetto di refactoring

Refactoring

Sommario

I Il problema



I Bibliografia




Definizione

Il processo di modifica di un sistema software senza alterarne ilcomportamento esterno pur migliorandone la struttura interna

Un modo disciplinato di ripulire il codice minimizzando le possibilita diintrodurre nuovi bug




Restructuring

“the transformation from one representation form to another at the samerelative abstraction level, while preserving the subject system’s externalbehavior (functionality and semantics).”

Tom Mens, Tom Tourwe A Survey of Software Refactoring IEEE TRANSACTIONS ON

SOFTWARE ENGINEERING, VOL. 30, NO. 2, FEBRUARY 2004, pag. 126




Refactoring

Refactoring is basically the object-oriented variant of restructuring: “theprocess of changing a [object-oriented] software system in such a way thatit does not alter the external behavior of the code, yet improves its internalstructure”.

The key idea here is to redistribute classes, variables, and methods acrossthe class hierarchy in order to facilitate future adaptations and extensions.


SOFTWARE ENGINEERING, VOL. 30, NO. 2, FEBRUARY 2004, pag. 126-127




Contesti applicativi

I Software evolutionrestructuring e refactoring sono usati per migliorare la qualita delsoftware (e.g., extensibility, modularity, reusability, complexity,maintainability, efficiency).

I Reengineeringrestructuring e usato per convertire legacy code o per migrare codicein un differente linguaggio di programmazione.


SOFTWARE ENGINEERING, VOL. 30, NO. 2, FEBRUARY 2004, pag. 126-127



Concetti di base

Esempio

T. Mens, T. Tourwe A Survey of Software Refactoring IEEE TRANSACTIONS ON SOFTWARE

ENGINEERING, VOL. 30, NO. 2, FEBRUARY 2004, pag. 127



Concetti di base

Esempio

Il progetto non e ottimale:

I differenti funzionalita della classe Document sono distribuite lungo lesottoclassi

T. Mens, T. Tourwe A Survey of Software Refactoring IEEE TRANSACTIONS ON SOFTWARE

ENGINEERING, VOL. 30, NO. 2, FEBRUARY 2004, pag. 127



Concetti di base

Bad Smells nel codice

Fowler ha introdotto il concetto di “code smell,” una categoria di problemiche indicano il bisogno di refactoring.

I Duplicated CodeMissing inheritance or delegation

I Long MethodInadequate decomposition

I Large ClassToo many responsibilities

I Long Parameter ListObject is missing



Concetti di base

Esempi di passi di refactoring

I spostamento di un metodo da un classe ad un’altra

I sostituzione di condizionali tramite polimorfismo

I sostituzione di ereditarieta con composizione



Refactoring

Sommario

I Il problema



I Bibliografia



Database Refactoring

Definizione

“A database refactoring is a simple change to a database schema thatimproves its design while retaining both its behavioral and informationalsemantics.”

structural aspects: definizioni di tabelle e viste.

functional aspects: procedure.

http://www.agiledata.org/essays/databaseRefactoring.html





Esempio di refactoring

Catalog of Database RefactoringsSplit Column una singola colonna e sostituita da due o piu colonneFirstDateBirthDate e HireDateAggiornare lo schema + il codice che vi accede






Motivazione per il database refactoring

1. To safely fix existing legacy databases2. To support evolutionary development






Database Refactoring – Evolutionary data modeling

I Database refactoringEvolve an existing database schema a small bit at a time to improvethe quality of its design without changing its semantics.

I Evolutionary data modelingModel the data aspects of a system iteratively and incrementally,just like all other aspects of a system, to ensure that the databaseschema evolves in step with the application code.






Database Refactoring vs Code Refactoring

I Code refactoringdeve solo preservare la semantica comportamentale

I Database refactoringdeve anche preservare la semantica informazionale.

Database refactoring e reso ancora piu difficile dal coupling(Coupling = misura della dipendenza tra due “oggetti”).



Database RefactoringEsempio

S. W. Ambler, P.J. Sadalage, Refactoring Databases: Evolutionary Database Design, 2006




Esempio




Database Smells

I Multipurpose column

I Multipurpose tableCustomer table sia per persone che per aziende

I Redundant data

I Tables with too many columns

I Tables with too many rows

I “Smart” columnsEsempio: le prime quattro cifre dell’ID di un cliente indicano il ramodi appartenenza.

I Fear of change“If you are afraid to change your database schema because you areafraid to break somethingfor example, the 50 applications that accessitthat is the surest sign that you need to refactor your schema.”

S. W. Ambler, P.J. Sadalage, Refactoring Databases: Evolutionary Database Design, 2006




The Process of Database Refactoring

1. Verify that a database refactoring is appropriate

2. Choose the most appropriate database refactoring

3. Deprecate the original database schema

4. Test before, during, and after

5. Modify the database schema

6. Migrate the source data

7. Modify external access program(s)

8. Run regression tests

9. Version control your work

10. Announce the refactoring





1. Verify that a database refactoring is appropriate1. Does the refactoring make sense?2. Is the change actually needed now?3. Is it worth the effort?





2. Choose the most appropriate database refactoring



Database RefactoringStructural refactorings

Structural refactoring cambiano la struttura di una tabella change t

I Drop Column

I Drop Table

I Drop View

I Merge Columns

I Merge Tables

I Move Column

I Rename Column

I Rename Table

I Rename View

I Replace Column

I Split Column

I Split Table





3. Deprecate the original database schema

transition period (deprecation period)





4. Test before, during, and after

(Test-Driven Development (TDD) approach)

I Database Schema TestVincoli di integritaView definitionsDefault values.

I Test delle applicazioniI Validazione del data migrationI Test dei programmi esterni





5. Modify the database schemaDDLSQL–99




Modify the database schema – SQL–99

I Schema di una tabella e Tabella Nome della tabellanome di ciascuna colonnadomini associati con le colonne (INTEGER, REAL, NUMERIC,CHAR, DATE)Istanza di uno schma di tabella (tabella)




Modify the database schema – SQL–99

I Un database schema evolveaddingalteringremovingdefinizioni di elementi dello schema.




Modify the database schema con SQL–99

CREATE TABLE impiegato (id INT,cognome CHAR(15),nome CHAR(15),indirizzo CHAR(40),hiredate DATE );





DROP TABLE impiegato

DROP TABLE impiegato RESTRICT

DROP TABLE impiegato CASCADE





ALTER TABLE PHONEADD PHONE PRIMARY S CHAR(1) DEFAULT ’Y’CHECK (PHONE PRIMARY S IN (’Y’, ’N’))ADD PHONE CATEGORY S CHAR(15);





ALTER TABLE PHONEDROP (PHONE PRIMARY S, PHONE CATEGORY S);





ALTER TABLE PHONEMODIFY PHONE PRIMARY S CHAR(1) NOT NULLMODIFY PHONE CATEGORY S VARCHAR2(20) DEFAULT ’BUSI-NESS’;





ALTER TABLE PHONEDROP (PHONE PRIMARY S, PHONE CATEGORY S);





ALTER TABLE SALESMANRENAME TO SALESPERSON;





ALTER TABLE SALESPERSONRENAME TO SALESMAN;





6. Migrate the source data.DML




Data Migration con SQL–99

INSERTUPDATEDELETE





INSERT INTO product (prod id n,prod num s,prod description s,prod status s,prod brand s,prod pltwid n,prod pltlen n )VALUES ( 990,’990’,’SPRUCE LUMBER 30X40X50’,’N’,’SPRUCE LUMBER’,4,6 )





UPDATE nome tabellaSET nome campo1 = ’valore1 nuovo’,nome campo2 = ’valore2 nuovo’,. . . ;Update con condizione:UPDATE nome tabellaSET nome campo1 = ’valore1 nuovo’,nome campo2 = ’valore2 nuovo’WHERE nome campo3 = ’valore’;




Data Migration

UPDATE Account SET Balance =(SELECT Balance FROM CustomerWHERE CustomerID = Account.CustomerID);




Data Migration

CREATE TABLE NewCities ( Name char(30), Prov char(30) );

UPDATE NewCitiesSET Name = (SELECT NameFROM Cities);





7. Modify external access program(s)





8. Run regression tests





9. Version control your work





10. Announce the refactoring


Bibliografia

Refactoring

Sommario

I Il problema



I Bibliografia


Bibliografia

Bibliografia

Riferimenti bibliografici

1. R. Pressman “Ingegneria del software” Mc Graw Hill Italia, 5aedizione, 2007, par. 133.

2. M. Fowler (et al.) Refactoring: Improving the Design of ExistingCode, Addison-Wesley,1999

3. T. Mens, T. Tourwe Tom Mens, Tom TourwE: A Survey of SoftwareRefactoring. IEEE Trans. Software Eng. 30(2): 126-139 (2004)

4. T. Mens, S. Demeyer, B. Du Bois, H. Stenten, Pieter Van Gorp:Refactoring: Current Research and Future Trends. Electr. NotesTheor. Comput. Sci. 82(3): (2003)

5. T. Mens, Introduction and Roadmap: History and Challenges ofSoftware Evolution. Software Evolution 2008: 1-11

6. Catalogo di Refactoringshttp://www.refactoring.com/catalog/index.html

http://www.refactoring.com/catalog/index.html


Bibliografia

Bibliografia

Riferimenti bibliografici

1. S. W. Ambler, P. J. Sadalage Refactoring Databases: EvolutionaryDatabase Design Addison-Wesley Professional, 2006

2. Agile Data Home Pagehttp://www.agiledata.org/essays/databaseRefactoring.html

3. C. Turker, Schema Evolution in SQL-99 and Commercial(Object-)Relational DBMS. FMLDO 2000: 1-32

4. A. Kriegel, B. M. Trukhnov, SQL Bible, Wiley 2003



Documents

Corso di Ingegneria del Software a.a. 2009/2010 Refactoringinfocom.uniroma1.it/~cdainformazione/uploads/IngegneriaDelSoftware/... · Corso di Ingegneria del Software a.a. 2009/2010