Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Advertisements

Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
REFACTORING & SOFTWARE TESTING. Refactoring  Refactoring is the process of altering source code so as to leave its existing functionality unchanged.
© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 
You want me to do what??? Refactoring legacy applications aka : fixing someone else’s “bad” code Niel Zeeman Team Foundation Consulting
Gregor Gisler-Merz BrownBag Session Refactoring.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Lectures 17 and 18 A Refactoring Micro-Example FOR0383 Software Quality Assurance 5/16/20151Dr Andy Brooks Refactoring is really easy using this tool.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 4 Big Refactorings Steve Chenoweth Office Phone: (812) Cell: (937)
1 Software Maintenance and Evolution CSSE 575: Session 1, Part 4 Even more Bad Smells in Code Steve Chenoweth Office Phone: (812) Cell: (937)
Slide 1 Systems Analysis & Design CS183 Spring Semester 2008 Dr. Jonathan Y. Clark Course Website:
Introduction to Refactoring Excerpted from ‘What is Refactoring?’ by William C. Wake and Refactoring: Improving the Design of Existing Code by Martin Fowler.
XP and Refactoring David Talby. Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
Object Oriented Concepts in Java Objects Inheritance Encapsulation Polymorphism.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Software Engineering Modern Approaches
CISC6795: Spring Object-Oriented Programming: Polymorphism.
Chapter 5 Design Principles II: Flexibility, Reusability, and Efficiency.
1 v1.6 08/02/2006 Overview of Eclipse Lectures 1.Overview 2.Installing and Running 3.Building and Running Java Classes 4.Refactoring 5.Debugging 6.Testing.
Chapter 5 Design Principles II: Flexibility, Reusability, and Efficiency.
What is Refactoring? CSE301 University of Sunderland Harry R. Erwin, PhD.
An Introduction to Java Chapter 11 Object-Oriented Application Development: Part I.
Refactoring. Mathematics: Factor ● fac·tor – One of two or more quantities that divides a given quantity without a remainder, e.g., 2 and 3 are factors.
Refactoring - A disciplined approach to rework for better design.
Refactoring Improving the structure of existing code Refactoring1.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
Small changes to code to improve it. Refactoring Defined A change made to the internal structure of software to make it easier to understand and cheaper.
Refactoring (continued) Source: "Refactoring: Improving the Design of Existing Code", Martin Fowler.
SWE 316: Software Design and Architecture Objectives Lecture # 20 Improving the existing design: Refactoring SWE 316: Software Design and Architecture.
Refactoring1 Improving the structure of existing code.
The effectiveness of refactoring based on a compatibility testing taxonomy and a dependency graph Steve Counsell and Robert Hierons, Brunel University,
Refactoring Deciding what to make a superclass or interface is difficult. Some of these refactorings are helpful. Some research items include Inheritance.
1 CSC/ECE 517 Fall 2010 Lec. 3 Overview of Eclipse Lectures Lecture 2 “Lecture 0” Lecture 3 1.Overview 2.Installing and Running 3.Building and Running.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
Refactoring and such ● (Side note) Specialization ● Key terms ● Abstraction, state, persistence and association and their relationship to software development.
Refactoring. Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative.
Today’s Agenda  More refactoring patterns Software Testing and Maintenance 1.
Refactoring 2. Admin Blackboard Quiz Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
Object Oriented Analysis and Design Class and Object Diagrams.
Module 3. Smells Between Classes Course: Refactoring.
Design Patterns Software Engineering CS 561. Last Time Introduced design patterns Abstraction-Occurrence General Hierarchy Player-Role.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 3 Dealing with Generalization Steve Chenoweth Office Phone: (812) Cell: (937)
© 2010 John Wiley & Sons Ltd. Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Refactoring. Mathematics: Factor ● fac·tor – One of two or more quantities that divides a given quantity without a remainder, e.g., 2 and 3 are factors.
CS 325: Software Engineering March 19, 2015 Applying Patterns (Part B) Code Smells The Decorator Pattern The Observer Pattern The Template Method Pattern.
CSSE 375 Organizing Data – Part 2 Shawn and Steve Continue the same quiz!
Refactoring1 Improving the structure of existing code.
Pertemuan 12 Refactoring Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
Refactoring. 2 Process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal.
CET203 SOFTWARE DEVELOPMENT Session 2A Inheritance (programming in C#)
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
Software Construction and Evolution - CSSE 375 Dealing with Generalization Steve and Shawn Left – In the 1990 movie “The Freshman,” Matthew Broderick,
Refactoring. DCS – SWC 2 Refactoring ”A change made to the internal structure of software to make it easier to understand and cheaper to modify without.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
Module 9. Dealing with Generalization Course: Refactoring.
Principles and examples
Catalog of Refactoring
Steve Chenoweth Office Phone: (812) Cell: (937)
Catalog of Refactoring
Module Road Map Refactoring Why Refactoring? Examples
Software Engineering Modern Approaches Chapter 24. Refactoring.
Overview of Eclipse Lectures
OBJECT ORIENTED PROGRAMMING II LECTURE 8 GEORGE KOUTSOGIANNAKIS
Code Smells 1.
Improving the structure of existing code
Refactoring.
Presentation transcript:

Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1

Chapter 24. Refactoring © 2010 John Wiley & Sons Ltd. 2

Learning Goals for This Chapter What is refactoring? How does refactorings work at large scales? How do you refactor at the method level? Can you reorganize classes using refactoring? Reorganize data? Can you refactor at the module/package level? In what way is refactoring essential for agile projects? How is refactoring used in non-agile projects? How does refactoring relate to design patterns? Requirements analysis Design Implementation Testing Maintenance Planning The Software Development Lifecycle Phase most relevant to this chapter is shown in bold © 2010 John Wiley & Sons Ltd. 3

Using a Refactoring Wizard Shift/Alt/R © 2010 John Wiley & Sons Ltd. 4

Fowler’s Refactoring Taxonomy 1.Big Refactorings 2.Composing Methods 3.Moving Features Between Objects 4.Organizing Data 5.Dealing With Generalization 6.Simplifying Conditional Expressions 7.Making Method Calls Simpler © 2010 John Wiley & Sons Ltd. 5

Big Refactorings 1: Tease Apart Inheritance * Employee SoftwareEmpClericalEmp FulltimeSoftwareEmp RetiredSoftwareEmp *Fowlers’ taxonomy MaintceEmp ParttimeSoftwareEmp FulltimeMaintceEmp RetiredMaintceEmp ParttimeMaintceEmp FulltimeClericalEmp RetiredClericalEmp ParttimeClericalEmp before © 2010 John Wiley & Sons Ltd. 6

Big Refactorings 1: Tease Apart Inheritance *  Employee SoftwareEmpClericalEmp FulltimeSoftwareEmp Employee SoftwareEmpClericalEmp Status Fulltime Retired RetiredSoftwareEmp *Fowlers’ taxonomy ParttimeMaintceEmp ParttimeSoftwareEmp FulltimeMaintceEmp RetiredMaintceEmp ParttimeMaintceEmp FulltimeClericalEmp RetiredClericalEmp ParttimeClericalEmp before after © 2010 John Wiley & Sons Ltd. 7

Big Refactorings 2*: Convert Procedural Design to Objects Control startGame() displayCharacter() moveCharacter() VideoGame GameCharacter *Fowlers’ taxonomy before © 2010 John Wiley & Sons Ltd. 8

Big Refactorings 2*: Convert Procedural Design to Objects  Control startGame() displayCharacter() moveCharacter() VideoGame GameCharacter VideoGame start() GameCharacter display() move() *Fowlers’ taxonomy before after © 2010 John Wiley & Sons Ltd. 9

Big Refactorings 3*: Separate Domain from Presentation Account name balance … displayStandard() displayHTML() *Fowlers’ taxonomy before © 2010 John Wiley & Sons Ltd. 10

Big Refactorings 3*: Separate Domain from Presentation  Account name balance … displayStandard() displayHTML() Account name balance … StandardAccountGUI display () HTMLAccountGUI display () *Fowlers’ taxonomy before after © 2010 John Wiley & Sons Ltd. 11

Big Refactorings 4*: Extract Hierarchy Project *Fowlers’ taxonomy before © 2010 John Wiley & Sons Ltd. 12

Big Refactorings 4*: Extract Hierarchy  Project SoftwareEngineeringProject CustomerEntertainmentProject *Fowlers’ taxonomy MobileApplication DesktopApplication before after © 2010 John Wiley & Sons Ltd. 13

Composing Methods* Extract method Inline method Inline temp (remove a temporary variable) Replace temp with query (i.e., a function) Introduce explaining variable (to replace complicated expression) Split temporary variable (i.e., used more than once) Remove assignment to parameters Replace method with method object *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 14

Moving Features Between Objects 1* Move Method –Trades off method holding vs. usage Move Field –Trades off holding vs. usage Extract Class –Encapsulate a set of attributes and methods of a class Inline Class –Opposite of Extract Class *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 15

Moving Features Between Objects 2* Hide Delegate –Hide class dependencies from client classes** Remove Middle Man –Opposite of Hide Delegate ** See below *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 16

Hide Delegates Client Class1 Class2 method2 () © 2010 John Wiley & Sons Ltd. 17

Hide Delegates Client Class1 Class2 method2 () Client Class1 method1() Class2 method2() delegate delegate.method2() Key: = changed  © 2010 John Wiley & Sons Ltd. 18

Organizing Data 1* Self Encapsulate Field –Change direct access of an attribute to accessor use Replace Data Value with Object Change Value to Reference class Order { Customer customer;…. class Order { private Customer getCustomer( String ….) Change Reference to Value Replace Array with Object *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 19

Change Unidirectional Association to Bidirectional –(Only if necessary.) Install backpointer. Change Bidirectional Association to Unidirectional –Find a way to drop; consider third party Replace “Magic Number” with Constant Encapsulate Field –public attribute to private/accessor Organizing Data 2* *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 20

Organizing Data 3* Replace Record with Data Class –Simplest object with private data field, accessor Replace Type Code with Class Account … type *Fowlers’ taxonomy before © 2010 John Wiley & Sons Ltd. 21

Organizing Data 3* Replace Record with Data Class –Simplest object with private data field, accessor Replace Type Code with Class Account … type Account … AccountType REGULAR: AccountType BIG_DISCOUNT: AccountType SMALL_DISCOUNT: AccountType *Fowlers’ taxonomy before after © 2010 John Wiley & Sons Ltd. 22

Organizing Data 4* Replace Type Code with Subclass Replace Type Code with State/Strategy Account … type Account … type *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 23

Organizing Data 4* Replace Type Code with Subclass Replace Type Code with State/Strategy Account … type RegularAccount  Account … WholesaleAccount RegularAccountType AccountType … WholesaleAccountType  Account … type Account … *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 24

Dealing with Generalization 1* *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 25

Extract Subclass Extract Superclass Dealing with Generalization 2* Order quantity discount minimum type Manager name salary numSupervisees Engineer name salary skillSet  *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 26

Extract Subclass Extract Superclass Dealing with Generalization 2* Order quantity WholesaleOrder discount minimum Order quantity discount minimum type  Manager name salary numSupervisees Engineer name salary skillSet  Manager numSupervisees Engineer skillSet Employee name salary *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 27

Extract Interface Collapse Hierarchy –Inherited class not special enough Dealing with Generalization 3* Manager name salary numSupervisees billRate Engineer name salary skillSet billRate *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 28

Extract Interface Collapse Hierarchy –Inherited class not special enough Dealing with Generalization 3* Manager name salary numSupervisees billRate Engineer name salary skillSet billRate  Manager numSupervisees Engineer skillSet Employee getName() getSalary() Billable getRate() *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 29

Dealing with Generalization 4*: Form Template Method TricycleAssemblyInstructions writeTrikeInstructions() BicycleAssemblyInstructions writeBikeInstructions() *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 30

Dealing with Generalization 4*: Form Template Method  AssemblyInstructions writePrep() writeSafety() writeWrapUp() writeManual() TricycleAssemblyInstructions writePrep() writeSafety() writeWrapUp() BicycleAssemblyInstructions writePrep() writeSafety() writeWrapUp() TricycleAssemblyInstructions writeTrikeInstructions() BicycleAssemblyInstructions writeBikeInstructions() *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 31

Replace Inheritance with Delegation Replace Delegation with Inheritance Fowler: Dealing with Generalization* Record lastChanged() Account *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 32

Replace Inheritance with Delegation Replace Delegation with Inheritance Fowler: Dealing with Generalization*  Record lastChanged() Account lastChanged() Record lastChanged() record record.lastChanged() *Fowlers’ taxonomy © 2010 John Wiley & Sons Ltd. 33

Introducing Façade U V W © 2010 John Wiley & Sons Ltd. 34

Introducing Façade U V W V W package © 2010 John Wiley & Sons Ltd. 35 U F

Introduce Module Refactoring UV © 2010 John Wiley & Sons Ltd. 36

Introduce Module Refactoring UV UV VI 1 © 2010 John Wiley & Sons Ltd. 37

Modularize Refactoring Applied 2: Transaction/Customer TrnsctnCust Trnsctn CustFaç  TrnsctnCust ICust  Cust © 2010 John Wiley & Sons Ltd. 38

Reference Types Trnsctn has attribute of type Cust –Replacing Cust cust; with ICust cust; OK if … Cust has only private attributes (i.e., use via methods only) Trnsctn does not instantiate Cust instances Trnsctn has method with parameter of type Cust –Replacing myMethod(Cust ) with myMethod(ICust ) OK if … Cust has only private attributes (i.e., use via methods only) Trnsctn has method returning type Cust –Replacing Cust myMethod(); with ICust myMethod(); OK Trnsctn has method with variable of type Cust –Replacing Cust cust; with ICust cust; Unresolved as a general matter Trnsctn Cust © 2010 John Wiley & Sons Ltd. 39

Modify code and test code base to handle additional requirements Agile Methods Obtain requirements for next period’s* segment * Typically 1-6 weeks Refactor to accommodate new requirements Obtain high-level requirements Refactor to clean up © 2010 John Wiley & Sons Ltd. 40