1 / 51

COMS W4156: Advanced Software Engineering

COMS W4156: Advanced Software Engineering. Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/. What is Refactoring?. The process of changing the source code of a software system such that:

blade
Download Presentation

COMS W4156: Advanced Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ Kaiser: COMS W4156 Fall 2007

  2. What is Refactoring? • The process of changing the source code of a software system such that: • The external (observable) behavior of the system does not change - e.g., functional and extra-functional requirements are maintained • But the internal structure of the system is improved Kaiser: COMS W4156 Fall 2007

  3. How improved? • Maintainability! • Easier to read and understand • Easier to (further) modify • Easier to integrate • Easier to test Kaiser: COMS W4156 Fall 2007

  4. This if (isSpecialDeal()) { total = price * 0.95; send() } else { total = price * 0.98; send() } Becomes this if (isSpecialDeal()) { total = price * 0.95; } else { total = price * 0.98; } send(); Simple Example: Consolidate Duplicate Conditional Fragments Kaiser: COMS W4156 Fall 2007

  5. Why is it called Refactoring? • By analogy to the factorization of polynomials • For example, x2 − x − 2 can be factored as (x + 1)(x − 2) revealing an internal structure that was previously not visible (two roots at −1 and +2) • Similarly, in software refactoring, the change in visible structure can often reveal the "hidden“ internal structure of the original code Kaiser: COMS W4156 Fall 2007

  6. Refactoring Process • A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior • Series of small behavior-preserving transformations • Each transformation does little, but a sequence of transformations can produce a significant restructuring • Since each refactoring is small, it's less likely to go wrong • The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring Kaiser: COMS W4156 Fall 2007

  7. void printOwing(double amount) { printBanner() //print details System.out.println(“name: ” + _name); System.out.println(“amount: ” + amount); } void printOwing(double amount) { printBanner() printDetails(amount) } void printDetails(double amount) { System.out.println(“name: ” + _name); System.out.println(“amount: ” + amount); } Example: Extract Method • You have a code fragment that can be grouped together • Turn the fragment into a method whose name explains the purpose of the fragment Kaiser: COMS W4156 Fall 2007

  8. Example: Replace Temp with Query • You are using a temporary variable to hold the result of an expression • Extract the expression into a method • Replace all references to the temp with the method call • The new method can then be used in other methods double basePrice = _quantity * _itemPrice if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98; if (basePrice() > 1000) return basePrice() * 0.95; else return basePrice() * 0.98; … double basePrice() { return _quantity * _itemPrice; } Kaiser: COMS W4156 Fall 2007

  9. Example: Introduce Null Object • Repeated checks for a null value • Replace the null value with a null object if (customer == null) { name = “occupant” } else { name = customer.getName() } if (customer == null) { … public class nullCustomer { public String getName() { return “occupant”; } } customer.getName(); Kaiser: COMS W4156 Fall 2007

  10. Example: Exploit Polymorphism • Generally, polymorphism is the ability to appear in many forms • In OO, polymorphism refers to a programming language's ability to process objects differently depending on their data type or class • More specifically, it is the ability to redefine methods for derived classes(orsubclasses) Kaiser: COMS W4156 Fall 2007

  11. Vehicle EU Vehicle US Vehicle UK Vehicle getBaseSpeed() getBaseSpeed() getBaseSpeed() getBaseSpeed() Example double getSpeed() { switch (_type) { case EUROPEAN: return getBaseSpeed(); case US: return getBaseSpeed() / 1.6; case BRITISH: if (getDate() < new Year(1990)) return getBaseSpeed() / 1.6 else return getBaseSpeed(); } throw new RuntimeException ("Should be unreachable"); } Kaiser: COMS W4156 Fall 2007

  12. Refactoring is Incremental Redesign • The idea behind refactoring is to acknowledge that it will be difficult to get a design right the first time • And as a program’s requirements change, the design may need to change • It is notoriously difficult (impossible?) to design for all possible changes a priori • And as agile programming proponents say, “You ain’t gonna need it” – but what if later you do? • Refactoring provides techniques for evolving the design in small incremental steps Kaiser: COMS W4156 Fall 2007

  13. Refactoring Benefits • Often code size is reduced after refactoring • Confusing structures are transformed into simpler structures - which are easier to maintain (and often easier to unit test) • Promotes a deeper understanding of the code - which aids in finding bugs and anticipating potential bugs Kaiser: COMS W4156 Fall 2007

  14. Contrast with Performance Optimization • Again functionality is not changed, only internal structure • However, performance optimizations often involve making code harder to understand (but faster!) • Use more efficient but more complicated algorithms and data structures • Lose generality to address specific issues of the implemented solution Kaiser: COMS W4156 Fall 2007

  15. When to Refactor? • When you add new functionality • Do it before you add the new function, to make it easier to add the function • Or do it after you add the function, to clean up the code including that function • When you need to fix a bug • As you do a code review • Whenever… Kaiser: COMS W4156 Fall 2007

  16. Why to Refactor? • General goal is maintainability • Enhance clarity, understandability, modifiability, integratability, testability • Very often refactoring is about: • Increasing cohesion • Decreasing coupling Kaiser: COMS W4156 Fall 2007

  17. Cohesion and Coupling • Cohesion is a property or characteristic of an individual unit • Coupling is a property of a collection of units • High cohesion GOOD, high coupling BAD • Design for change • You don't want a change in one unit (module, class, method) to cause errors to ripple throughout your system • Make units highly cohesive, seek low coupling among units Kaiser: COMS W4156 Fall 2007

  18. What to Refactor? • Duplicated Code • Bad because if you modify one instance of duplicated code but not all the others, you (may) have introduced a bug! • Switch Statements • Often duplicated in code, can typically be replaced by use of polymorphism (in OO languages) Kaiser: COMS W4156 Fall 2007

  19. What to Refactor? • Long Method • More difficult to understand • Performance concerns with respect to lots of short methods are largely obsolete • Long Parameter List • Hard to understand, can become inconsistent • Large Class • Trying to do too much, which reduces cohesion Kaiser: COMS W4156 Fall 2007

  20. What to Refactor? • Divergent Change • One type of change requires changing one subset of methods in the module, another type of change requires changing another subset • Shotgun Surgery • A change requires lots of little changes in a lot of different classes • Parallel Inheritance Hierarchies • Each time you add a subclass to one hierarchy, you need to do it for all related hierarchies Kaiser: COMS W4156 Fall 2007

  21. What to Refactor? • Lazy Class • A class that no longer “pays its way”, e.g., a class that was downsized by previous refactoring, or represented planned functionality that did not pan out • Middle Man • If a class is delegating more than half of its responsibilities to another class, do you really need it? Kaiser: COMS W4156 Fall 2007

  22. What to Refactor? • Speculative Generality • “Oh I think we need the ability to do this kind of thing someday” • Alternative Classes with Different Interfaces • Two or more methods do the same thing but have different signature for what they do Kaiser: COMS W4156 Fall 2007

  23. What to Refactor? • Primitive Obsession • Characterized by a reluctance to use classes instead of primitive data types • Temporary Field • An attribute of an object is only set in certain circumstances - but an object should need all of its attributes Kaiser: COMS W4156 Fall 2007

  24. What to Refactor? • Feature Envy • A method requires lots of information from some other class • Data Clumps • Attributes that clump together but are not part of the same class Kaiser: COMS W4156 Fall 2007

  25. What to Refactor? • Message Chains • A client asks an object for another object and then asks that object for another object, etc. getA().getB().getC().getD().getE().doSomething(); • Bad because client depends on the structure of the navigation • Inappropriate Intimacy • Pairs of classes that know too much about each other’s private details Kaiser: COMS W4156 Fall 2007

  26. What to Refactor? • Data Class • Classes that have fields, getting and setting methods for the fields, and nothing else • They are data holders, but objects should be about data and behavior (with some exceptions) • Refused Bequest • A subclass ignores most of the functionality provided by its superclass Kaiser: COMS W4156 Fall 2007

  27. What to Refactor? • Incomplete Library Class • A framework class doesn’t do everything you need • Comments (!) • Comments are sometimes used to “decorate” bad code • /* This is a gross hack */ Kaiser: COMS W4156 Fall 2007

  28. But Refactoring can be Dangerous • If programmers spend time “cleaning up the code”, then that’s less time spent implementing required functionality - and the schedule is slipping as it is! • Refactoring can break code that previously worked • Refactoring needs to be systematic, incremental, and safe Kaiser: COMS W4156 Fall 2007

  29. How to Make Refactoring Safe? • Use refactoring “patterns” • Catalog at http://www.refactoring.com/catalog/index.html • Mostly taken from Fowler’s book http://martinfowler.com/books.html#refactoring • Use refactoring tools • Long list at http://www.refactoring.com/tools.html • Test constantly! • Regression testing Kaiser: COMS W4156 Fall 2007

  30. Regression Testing After Changes • Can be a unit test or a combination of unit and integration test • Change is successful, and no new errors are introduced • Change does not work as intended, and no new errors are introduced • Change is successful, but at least one new error is introduced • Change does not work, and at least one new error is introduced Kaiser: COMS W4156 Fall 2007

  31. Other Difficulties with Refactoring • Some refactorings require that interfaces be changed • If you own all the calling code, need to change everywhere the interface is used • If not, the interface is “published” and can’t change (or shouldn’t) • Business applications are often tightly coupled to underlying database schemas • Virtually impossible to reorganize a database schema unless the underlying database automates the corresponding table/row/column transformations (or your database is empty) Kaiser: COMS W4156 Fall 2007

  32. Other Difficulties with Refactoring • Dealing with hardware devices is worse than databases and other external software interfaces • Software can change, the hardware (usually) cannot • Real-time or other timing-dependent applications • Refactored code will not necessarily run within previous time bounds Kaiser: COMS W4156 Fall 2007

  33. Summary • Refactor often • Refactor as you go • Simplest version of refactoring: add comments, rename local variables and parameters more intuitively • Regression test after every refactoring Kaiser: COMS W4156 Fall 2007

  34. First Iteration Final Report Due! • First iteration final report due Friday November 9th • Must respond to any “issues” that arose during demo Kaiser: COMS W4156 Fall 2007

  35. Upcoming Deadlines • Midterm Individual Assessment posted Friday November 9th • Midterm Individual Assessment due Friday November 16th • 2nd iteration starts November 16th Kaiser: COMS W4156 Fall 2007

  36. Second Iteration • Add extensive error checking and exception handling, refactor • Black box unit testing and white box statement coverage • Semi-formal code inspection • Security and stress testing • Seeking volunteer teams to do code inspections (Tue 27 Nov and Thu 29 Nov) and final demos (Tue 4 Dec and Thu 6 Dec) in class [CVN video] Kaiser: COMS W4156 Fall 2007

  37. MIA • 15% of final grade • INDIVIDUAL • Two parts graded, two parts not graded but still required (evaluate teammates and TA) • Submit via Kaiser dropbox on CourseWorks • Follow file naming convention: yourfullname-MIA.ext • All parts of submission must be directly readable using MS Office 2003, Adobe Acrobat 8 and/or Firefox 2 on Windows XP sp2, NO extra “plugins” or “downloads” Kaiser: COMS W4156 Fall 2007

  38. MIA Part One - Graded • The purpose of this assignment is to learn (part of) UML. • First, diagram as UML use cases the requirements for your team project as actually implemented in time for the first demo (including extra "planned" addons is ok).  • The UML use cases should be detailed, e.g., show associations (with multiplicity), extensions and/or inclusions as warranted, not just ovals and stick people.  • Use as many separate diagrams as needed, but make clear if and where any "connect", if germane. • Label the subparts of your diagrams, and explain all your diagrams in prose with appropriate references to those labels. Kaiser: COMS W4156 Fall 2007

  39. MIA Part One - Graded • Second, diagram as UML class diagrams the design of your team project as actually implemented in time for the first demo (including extra "planned" addons is ok).  • The class diagrams should be detailed, e.g., show attributes and operations, and indicate generalization, associations, aggregations, etc. as warranted. • You do not need to include any structural model diagrams other than class diagrams, i.e., omit object, package, deployment, etc. diagrams. • Use as many separate diagrams as needed, but make clear if and where any "connect", if germane. • Label the subparts of your diagrams, and explain all your diagrams in prose with appropriate references to those labels. Kaiser: COMS W4156 Fall 2007

  40. MIA Part One - Graded • Optional extra credit: diagram UML sequence diagrams and/or UML statechart diagrams corresponding to the above, also with appropriate labels and prose explanations. • If your team included UML in any of your prior team submissions, it is acceptable to "reuse" any or all of those diagrams provided that you state excruciatingly clearly any and all such "reuse".  • Prior collaboration towards previously submitted team assignments is the only collaboration permitted. Kaiser: COMS W4156 Fall 2007

  41. MIA Part One - Graded • Include a bibliography of any external materials used, e.g., to learn more about UML  (articles, books, websites, etc.); note that the lectures alone generally provide insufficient detail to complete this question.  • If you already "know" UML from previous experience, state so and briefly describe that experience. • You may optionally employ a UML modeling tool, but this is not required; the figures do not have to perfectly match UML graphical syntax as long as any deviations are clear.  Kaiser: COMS W4156 Fall 2007

  42. MIA Part Two - Graded • The purpose of this assignment is to learn the gist of a second component model framework, beyond the framework used in your team project. You are not expected to learn the corresponding programming language(s). • Choose any major component framework (whether or not covered in class) that is differentfrom the component framework used for your team project; make sure to state which framework you have selected. • Note CORBA alone, without CCM, nor COM alone, without COM+, does not constitute a component model framework for this purpose. Kaiser: COMS W4156 Fall 2007

  43. MIA Part Two - Graded • Sketch a redesign of your entire system (as implemented in time for the first demo, including "planned" addons is ok) to be re-implemented using the chosen component framework. • What are the major components and interfaces? • How do they interact with each other? • Most significantly, which services provided by the framework are to be leveraged, and how? • Assume that you would be developing from scratch, that is, you are not bound by any design or implementation decisions your team has already made with respect to your actual project, and you can choose some other way to implement the functionality outlined in part One. Kaiser: COMS W4156 Fall 2007

  44. MIA Part Two - Graded • Optional extra credit: do the same for a third component model framework. • If your team previously documented use of a different component model framework in any of your prior team submissions other than actually used for implementation, it is acceptable to "reuse" any or all of that material provided that you state excruciatingly clearly any and all such "reuse".  • Prior collaboration towards previously submitted team assignments is the only collaboration permitted. Kaiser: COMS W4156 Fall 2007

  45. MIA Part Two - Graded • Include a bibliography of any external materials used, e.g., to learn more about the selected framework (articles, books, websites, etc.); note that the lectures alone generally provide insufficient detail to complete this question.  • If you already "know" a second component framework from previous experience, state so and briefly describe that experience. • You are not required to do any coding for this assignment, but may do so if desired; however, do not submit your code, the instructor will not read it nor consider it in grading. Kaiser: COMS W4156 Fall 2007

  46. MIA Part Three – Ungraded (but Required) • Evaluate your experience with your pair and your team to date. If your team consists of a single pair, or a "triplet", state so. • If there are any "problems", e.g., some team member (including yourself) where quantity and/or quality is significantly lower than the rest of the team, discuss how do plan to deal with this during the rest of the semester. Kaiser: COMS W4156 Fall 2007

  47. MIA Part Three – Ungraded (but Required) • Grant yourself 100% for both quality (successful output, considering coding/testing/debugging, milestone documentation and requirements/design brainstorming) and quantity (effort, whether successful or otherwise) of your own work done to date. • Rate each of your other team members with respect to both quality and quantity. • For instance, if Alice works only about 1/5th as hard as you do but produces 5 times better results, you should grant her 20% for quantity and 500% for quality.  • If you are not aware of the breakdown in quality/quantity with respect to the other pair in your team, state so, and treat them as a unit. • You must explain each of your ratings, do not just give numbers. Kaiser: COMS W4156 Fall 2007

  48. MIA Part Four – Ungraded (but Required) • Discuss your experience so far with your team's teaching assistant, Aaron Fernandes or Jayesh Kataria. • You may also optionally comment on and/or "grade" the other TA, but please make clear which of the two you are talking about. Kaiser: COMS W4156 Fall 2007

  49. MIA Part Four – Ungraded (but Required) • Have you (not just someone else on your team) met with your TA in person and, if so, how many meetings for how much time? • Has there been any email, IM, phone, etc. contact? • Has the TA been extremely useful to you, "ok", or you didn't really notice he existed? • Is there anything you think the TA could or should do differently, or in addition, which would make the TA more valuable to you and/or to your team? • Have there been any "issues" over TA office hours or responsiveness outside office hours? • "Grade" your TA, e.g., A+, B, D-, F and justify the grade you assigned. Kaiser: COMS W4156 Fall 2007

  50. MIA Out NOW Due Friday November 16th 5pm NO extensions Submit via Kaiser dropbox in CourseWorks If I can’t read it (without hassle), I won’t grade it! Kaiser: COMS W4156 Fall 2007

More Related