1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu https://ase.cs.columbia.edu/ October 18, 2011COMS W41561

2. October 18, 2011COMS W41562 Topics covered in this lecture Software Quality Refactoring Verification and Validation

3. October 18, 2011COMS W41563 Software Quality

4. October 18, 2011COMS W41564 “Quality” is Hard to Pin Down Concise, clear definition is elusive Not easily quantifiable Many things to many people “You'll know it when you see it” Often defined as set of “ilities” (attributes)

5. October 18, 2011COMS W41565 High Quality Software Has… Understandability –The ability of a reader of the software to understand its function –Critical for maintenance Modifiability –The ability of the software to be changed by that reader –Almost defines "maintainability"

6. October 18, 2011COMS W41566 High Quality Software Has… Reliability –The ability of the software to perform as intended without failure –If it isn't reliable, the maintainer must fix it Efficiency –The ability of the software to operate with minimal use of time and space resources –If it isn't efficient, the maintainer must improve it

7. October 18, 2011COMS W41567 High Quality Software Has… Portability –The ease with which the software can be made useful in another environment –Porting is usually done by the maintainer Testability –The ability of the software to be tested easily –Finding/fixing bugs is part of maintenance –Enhancements/additions must also be tested

8. October 18, 2011COMS W41568 High Quality Software Has… Usability –The ability of the software to be easily used (human factors) –Not easily used implies more support calls, enhancements, corrections  Notice all related to maintenance - but these qualities need to be instilled during development

9. October 18, 2011COMS W41569 Approaches to Achieving Quality Continuous refactoring Verification and validation Software process and process improvement Buy rather than build Open source software …

10. October 18, 2011COMS W415610 Refactoring

11. October 18, 2011COMS W415611 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 requirements are maintained –But the internal structure of the system is improved

12. October 18, 2011COMS W415612 How improved? Maintainability! Easier to read and understand Easier to (further) modify Easier to integrate Easier to test

13. October 18, 2011COMS W415613 Simple Example: Consolidate Duplicate Conditional Fragments 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();

14. October 18, 2011COMS W415614 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

15. October 18, 2011COMS W415615 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 (via regression testing), reducing the chances that a system can get seriously broken during the restructuring

16. October 18, 2011COMS W415616 Example: Extract Method 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); } You have a code fragment that can be grouped together Turn the fragment into a method whose name explains the purpose of the fragment

17. October 18, 2011COMS W415617 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; }

18. October 18, 2011COMS W415618 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();

19. October 18, 2011COMS W415619 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 (subclasses)

20. October 18, 2011COMS W415620 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"); } UK Vehicle getBaseSpeed() Vehicle getBaseSpeed() EU Vehicle getBaseSpeed() US Vehicle getBaseSpeed()

21. October 18, 2011COMS W415621 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 aren’t gonna need it” – but what if later you do?You aren’t gonna need it Refactoring provides techniques for evolving the design in small incremental steps

22. October 18, 2011COMS W415622 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

23. October 18, 2011COMS W415623 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 Use profiling tools to determine the 10-20% of the code requiring 80-90% of the CPU cycles – optimize that code, refactor all the other code

24. October 18, 2011COMS W415624 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…

25. October 18, 2011COMS W415625 Why to Refactor? General goal is maintainability Enhance clarity, understandability, modifiability, integratability, testability Very often refactoring is about: –Increasing cohesion –Decreasing coupling

26. October 18, 2011COMS W415626 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 (component, class, method) to cause errors to ripple throughout your system –Make units highly cohesive, seek low coupling among units

27. October 18, 2011COMS W415627 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)

28. October 18, 2011COMS W415628 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

29. October 18, 2011COMS W415629 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

30. October 18, 2011COMS W415630 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?

31. October 18, 2011COMS W415631 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

32. October 18, 2011COMS W415632 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

33. October 18, 2011COMS W415633 What to Refactor? Feature Envy –A method requires lots of information from some other class Data Clumps –Attributes (e.g., method parameters) that clump together but are not part of the same class

34. October 18, 2011COMS W415634 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

35. October 18, 2011COMS W415635 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, e.g., entity beans) Refused Bequest –A subclass ignores most of the functionality provided by its superclass

36. October 18, 2011COMS W415636 What to Refactor? Incomplete Library Class –An infrastructure class doesn’t do everything you need Comments (!) –Comments are sometimes used to “decorate” bad code –/* This is a gross hack */

37. October 18, 2011COMS W415637 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

38. October 18, 2011COMS W415638 How to Make Refactoring Safe? Use refactoring “patterns” –Catalog at http://refactoring.com/catalog/index.htmlhttp://refactoring.com/catalog/index.html Use refactoring tools –E.g., Eclipse JDT supports refactoringsupports refactoring Test constantly! –Regression testing

39. October 18, 2011COMS W415639 Regression Testing After Changes  Can be unit tests or a combination of unit and integration tests 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

40. October 18, 2011COMS W415640 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)

41. October 18, 2011COMS W415641 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

42. October 18, 2011COMS W415642 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

43. October 18, 2011COMS W415643 Verification and Validation

44. October 18, 2011COMS W415644 Quality Assurance: Verification and Validation Validation: Are we building the right product? –QA at requirements and design level concentrates on validation – ensures that the product will actually meet the users’ needs Verification: Are we building the product right? –QA at code level concentrates on verification – ensures that the product has been built according to the requirements and design specifications (only useful if the specifications were correct in the first place)

45. October 18, 2011COMS W415645 V&V Techniques Standards (ISO 9001, SEI CMMI)ISO 9001SEI CMMI Metrics (six sigma)six sigma Reviews (inspections, static analysis) Testing and model checking  Whole lifecycle process applied at each stage

46. October 18, 2011COMS W415646 Inspection Overview Also known as walkthrough An approach to testing that does not actually execute the code Formal process for reading through the software product as a group and identifying defects Potentially applied to all project documents including but not limited to source code Used to increase software quality and improve productivity and manageability of the development process

47. October 18, 2011COMS W415647 Static Analysis Overview Software tools parse the program text and try to discover potentially erroneous conditions Control flow analysis: Checks for loops with multiple exit or entry points, finds unreachable code, etc. Data use analysis: Detects uninitialized variables, variables written twice without an intervening use, variables that are declared but never used, etc. Interface analysis: Checks the consistency of type, method, etc. declarations and their use Should occur prior to inspection or testing

48. October 18, 2011COMS W415648 Why Test? No matter how well software has been designed and coded, it will inevitably still contain defects Testing is the process of executing a program with the intent of finding faults (bugs) A “successful” test is one that finds errors, not one that doesn’t find errors Testing can “prove” the presence of faults, but can not “prove” their absence (unless the program is so trivial that it can be exhaustively tested) But can increase confidence that a program “works”

49. October 18, 2011COMS W415649 What to Test? Unit test – test of small code unit: start with individual methods, build up to class (and class hierarchy if applicable), then component Integration test – test of several units combined to form a (sub)system, preferably adding one unit at a time System (alpha) test – test of a system release by “independent” system testers Acceptance (beta) test – test of a release by end-users or their representatives

50. October 18, 2011COMS W415650 When to Test? Early “Agile programming” developers write unit test cases before coding each unit (test-driven development) Many software processes involve writing system/acceptance tests in parallel with development Often Regression testing: rerun unit, integration and system/acceptance tests –After refactoring –Throughout integration –Before each release

51. October 18, 2011COMS W415651 Who should Test? Argument: Software authors should not test their own code because –Testers who don’t believe they will find faults generally don’t find many faults (cognitive dissonance) –Testers who have to fix any faults they find don’t tend to find very many (avoidance behavior) –Coders want code to be fault free, but effective testers must want to find faults (conflict of interest) However, in practice code authors usually do unit tests and often integration tests Separate “independent” team usually does system tests and/or acceptance tests

52. October 18, 2011COMS W415652 Defining a Test Goal – the aspect of the system being tested Input – specify the actions and conditions that lead up to the test as well as the input (state of the world, not just parameters) that actually constitutes the test Outcome – specify how the system should respond or what it should compute, according to its requirements

53. October 18, 2011COMS W415653 Test Harness (Scaffolding) test driver - supporting code and data used to provide an environment for invoking part of a system in isolation stub - dummy procedure, module or unit that stands in for another portion of a system, intended to be invoked by that isolated part of the system –May consist of nothing more than a function header with no body –If a stub needs to return values, it may read and return test data from a file, return hard-coded values, or obtain data from a user (the tester) and return it –The stub should cover every possible error code and exception that can arise

54. October 18, 2011COMS W415654 Unit Testing Overview Unit testing is testing some program unit in isolation from the rest of the system (which may not exist yet) Usually the programmer is responsible for testing a unit during its implementation (even though this violates the rule about a programmer not testing own software) Easier to debug when a test finds a bug (compared to full-system testing)

55. October 18, 2011COMS W415655 Integration Testing Overview Motivation: Units that worked in isolate may not work in combination Performed after all units to be integrated have passed all unit tests Reuse unit test cases that cross unit boundaries (that previously required stub(s) and/or driver standing in for another unit)

56. October 18, 2011COMS W415656 System/Acceptance Testing Overview Full system, from end-user (or other external role) input/output perspective Lab testing vs. field testing Consider interoperability with customer software and hardware configurations Additional factors: security, performance, usability

57. October 18, 2011COMS W415657 How do you know when you are “done” testing? Adequacy criteria (coverage metrics): all statements, all branches, all control flow paths, all data flow paths All programmed error messages and exceptions have been produced Have reached “tail” of defect density curve Confidence established that the software is fit for its purpose, “good enough”

58. October 18, 2011COMS W415658 Defect Density Curve

59. Upcoming Assignments October 18, 2011COMS W415659

60. Upcoming Assignments First Iteration First Progress Report due Thursday 20 October, 10am First Iteration First Progress Report First Iteration Second Progress Report due Thursday 27 October, 10am First Iteration Second Progress Report Demo Week November 1-10 – Seeking in-class demos for Tue Nov 1 and Thu Nov 3 – Sliding scale extra credit for early demos First Iteration Final Report due Friday 11 November, 5pm First Iteration Final Report October 18, 2011COMS W415660

61. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu https://ase.cs.columbia.edu/ October 18, 2011COMS W415661