CS4723 Software Engineering Lecture 12 Software Design Quality

2 Four Approaches to Quality Assurance  Testing  Verification  Static Bug Detection  Review

3 Review  Once the major approach when testing is expensive  Design Review  Code Review

4 Software Design  Software design usually consist of two aspects  Architecture design  Detail design (component-level design)  Design patterns  Design classes  Other design issues  Refactoring  UI Design

5 Factors Affecting Software Design Quality  Fundamental software design factors  Modularity  Abstraction  Information hiding  Component independence  Fault prevention and fault tolerance

6 Modularity and Abstraction  When we consider modular solutions to any problems, many levels of abstraction can be posed At the highest level of abstraction, a solution is stated in broad terms of problem domain: architecture At the lower levels of abstraction, a more detailed description of the solution is provided: class diagrams  Modularity hides details and facilitates evolvement Each component hides a design decision from the others

7 Component Independent  We strive in most designs to make the components independent of one another, why?  We measure the degree of component independence using two concepts Low coupling High cohesion

8 Coupling and Cohesion  Coupling Two components are highly coupled when there is a great deal of dependence between them Two components are loosely coupled when they have some dependence, but the interconnections among them are weak Two components are uncoupled when they have no interconnections at all  Cohesion A component is cohesive if the internal parts of the component are related to each other and to its overall purpose

9 Decoupling  Most difficult part in design: Need tradeoff  Consider the following case:  Online and offline bookstore components  Both need shopping cart checkout  Should we have a shopping cart checkout module for both of them? Or have one, and let the two components to call the module?  Consider potential changes on overall book discount policy and specific book discount policy?  Potential solution for the dilemma: break the checkout module, still not perfect 

10 Fault defense & tolerance  Defensive design anticipates situations the might lead to problems Network Failure Data corruption Invalid user inputs  Tolerate runtime errors Exception handling Redundant components (distributed system or critical software) Timely error reporting

11 Criteria for Good Software Design  High-quality designs should have characteristics that lead to quality products Correct translation from the requirements specification Ease of understanding Ease of implementation Ease of testing Ease of modification

12 Criteria for Good Software Design  Architecture  Using suitable architectural styles or patterns  Loose-coupled components  Can be implemented in an evolutionary fashion  Classes at a suitable abstract level  Interfaces are clear and minimize the data transfer  Design using a effective notation

13 Software Design Evaluation and Validation  We check a design in two different ways Validation: the design satisfies all requirements specified by the customer Verification: the characteristics (quality) of a good design are incorporated  We use some techniques for helping us to perform verification and validation Measuring design quality

14 Measuring Software Design Quality  We check a design using a set of measures Coupling Cohesion Complexity Basic metrics: size Depths of relations Cyclomatic complexity

15 Coupling  Factors: couple (A, B)  c: number of fields of B type in A  d: number of methods in B called by A  e: number of methods refer to B  f: shared fields and methods (if A is subclass of B or vice versa)

16 Cohesion  Coupling between classes in the same module  Highest value: 1 for each pair of classes  We can measure cohesion by how far it goes to the highest possible value

17 Complexity  Cyclomatic Complexity  Measuring the complexity of a graph  M = E – N + 2P  E: edges, N: nodes, P: number of connected components  Can apply to Control flow graph, Dependence graph, Class Diagram…

18 Design Patterns  Become popular due to a book  Design Patterns: Elements of Reusable Object- Oriented Software  Gang of Four: Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides  Provide solutions for common problems in micro-design

19 Software Refactoring: keep the design quality  So far we talked about issues to be considered during design  Principles  Measurements  Patterns  Considering these, you can try to find a best implementation for the current requirements  But requirements change quickly…

20 Software Refactoring  Definition:  Software refactoring the process of restructuring a software to improve its readability or extensibility, while keeping its behavior  Restructuring  Keeping its behavior  book  Refactoring- Improving the Design of Existing Code, Addison Wesley, Martin Fowler et al.

21 When to apply refactorings  Bad smells  Code duplication  Long method / Huge Class  Long parameter list  ….  As the software evolve, these smells automatically appears  Especially when you do extreme programming, which tries to ignore design issues at the beginning

22 Types of refactorings  Add/Remove methods / fields  Move methods / fields  Extract methods / interface  Rename  Replace temp with query  Pull up / Push down methods / fields  …

23 An example from Martin Fowler’s book  A program to calculate the bill of a video-store customer  The total amount depends on the movie renting prices, the number of movies rented and the renting dates  Class diagram

Example: Movie class public class Movie { private String title; private int priceCode; public Movie(String title, int priceCode) { this.title=title; this.priceCode = priceCode; } public String getTitle() { return this.title; } public int getPriceCode() { return this.priceCode; } public void setPriceCode(int priceCode) { this.priceCode = priceCode; }

Example: Rental class Rental public class Rental { private Movie movie; private int rentDay; public Rental(Movie movie, int rentDay) { this.movie = movie; this.rentDay = rentDay; } public int getDaysRented() { return Util.getCurrentDay() – this.rentDay ; } public Movie getMovie() { return this.movie; }

Example: Customer class Customer public class Customer { private String name; private List rentals =new ArrayList (); public Customer(String name) { this.name = name; } public void addRental(Rental rental) { this.rentals.addElement(rental); } public String getName() { return this.name; }

Example: Customer class(2) Customer public class Customer... public String statement() { double totalAmount = 0; String result = “ Rental Record for “ + getName() + “ \n ” ; for (Rental each : this.rentals) { double thisAmount = 0; // determine amounts for each line thisAmount = each.getMovie.getPriceCode() * each.getDaysRented(); totalAmount = totalAmount + thisAmount; result = result + each.getMovie.getName() + “ ” + each.getDaysRented() + “ ” + thisAmount + “ \n ” ; } // add footer lines result += “Amount owed is “+ totalAmount + “\n”; return result; }

28 Here comes the change  Add discount code for movies  Old – 80% price  Regular – 90% price  Popular – 100% price  Add a html statement for sending online bills

29 What to do?  Add conditional statements… for (Rental each : this.rentals) { double thisAmount = 0; // determine amounts for each line double discount = 1.0 if(each.getMovie().getDiscountCode() == DISCOUNT_OLD){ discount = 0.8; }else if(each.getMovie().getDiscountCode() == DISCOUNT_REG){ discount = 0.9 } thisAmount = each.getMovie().getPriceCode() * each.getDaysRented() * discount; totalAmount = totalAmount + thisAmount; result = result + each.getMovie.getName() + “ ” + each.getDaysRented() + “ ” + thisAmount + “\n”; }

30 What to do?  Copy and paste statement() and revise it to generate a htmlStatement() method  The code looks much worse now compared with the start point  Long statement method  Duplicate code

31 So after adding the two features, you plan to do refactoring  The main reason of the ugly code is ?  Statement() method is doing too many things (which are actually not parts of printing a statement)  Split it to three  Calculation of the amount on each line  Calculation of the amount sum  Print lines

32 Refactoring 1  1a: Extract method to getItemAmount()  It is actually something related to a rental  So 1b: Move it to rental, to reduce duty of Customer  1c: Rename it to getAmount() double discount = 1.0 if(each.getMovie().getDiscountCode() == DISCOUNT_OLD){ discount = 0.8; }else if(each.getMovie().getDiscountCode() == DISCOUNT_REG){ discount = 0.9 } thisAmount = each.getMovie().getPriceCode() * each.getDaysRented() * discount;

33 Refactoring 2  Extract method to getSumAmount()  It is relatively small, but since we need to copy the statement(), we should still extract this part to reduce duplication double totalAmount = 0;... totalAmount = totalAmount + thisAmount;

34 Results  So statement() becomes  Looks much cleaner, less harmful to copy  May do some further refactoring by extract the header, footer, but may cause more complexity  No perfect solutions, just trade off public String statement() { String result = “Rental Record for “ + getName() + “\n”; for (Rental each : this.rentals) { result = result + each.getMovie.getName() + “ ” + each.getDaysRented() + “ ” + each.getAmount() + “\n”; } // add footer lines result = result + “Amount owed is “+ getSumAmount() + “\n”; return result; }

35 Before applying refactoring  Finish the work at your hand  Usually bad smells come after you added a new feature or fixed a bug  Have a test suite  Make sure your code pass all test cases  Find out to what extent you can use automatic refactoring tools (which guarantees perserving behaviors)

36 Automatic refactoring  Refactoring involves lots of changes  Any change may cause bugs in the software  So, Most IDEs provide automatic refactoring tools  Make sure that the program behavior does not change after the refactoring  Use automatic refactoring whenever possible  Don’t do it by yourself

37 Behind automatic software refactoring tools  Automatic refactoring  Pre-conditions  e.g., the class you rename does not have a main method  e.g, the method you move should not have a side- effect on the class’s fields, otherwise the field must be visible by the moving destination  The transform  When pre-conditions are not satisfied, tools may refuse refactoring or give you choices

38 Review of Design Quality  Principles of Design  Measurements of Design Quality  Design Patterns  Software Refactorings