1 / 33

CS428/9: Software Engineering II

CS428/9: Software Engineering II. Darko Marinov (slides from Ralph Johnson). Administrative info. ACP third revision due on Thursday, March 15 HW3 posted on Wiki: metrics, due March 27 Will be graded by March 29 and covered in Demo 2 Demo 2: Functionality (code), testing, metrics

iola
Download Presentation

CS428/9: Software Engineering II

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. CS428/9: Software Engineering II Darko Marinov (slides from Ralph Johnson)

  2. Administrative info • ACP third revision due on Thursday, March 15 • HW3 posted on Wiki: metrics, due March 27 • Will be graded by March 29 and covered in Demo 2 • Demo 2: Functionality (code), testing, metrics • Will look more than before into your code and tests • After Spring Break, around April 3 • Advisable to meet your TA before Spring Break 428-15

  3. Metrics • Non-technical metrics about process • Number of people on project, time taken, money spent • Stories implemented • Bugs found (by testers/developers, by users) • Bugs fixed, features added • … • Technical metrics about product 428-15

  4. Technical metrics • Size of code • Lines of code (LOC, SLOC, NCNB LOC) • Number of files, classes, processes • Function points • Complexity of code • Dependencies / coupling / cohesion • OO metrics 428-15

  5. Some ways to use metrics • Measure performance of programmers • Measure the amount of code produced each month by each programmer • Give high producers big raise • Prioritize programmers’ effort • Measure complexity of modules • Pick the most complex and rewrite it • Determine whether code is ready to ship 428-15

  6. Complexity • Complex systems are • Hard to understand • Hard to change • Hard to reuse Cyclomatic complexity (covered last lecture) Cohesion and coupling (this lecture) 428-15

  7. Cyclomatic complexity CC = E – N + 2, where E is the number of edges and N is the number of nodes def addInterest for if acc.balance = ... done 428-15

  8. Technical metrics for OO systems • Material from these readings • Bob Martin: OO Design Quality Metrics • Shyam R. Chidamber and Chris F. Kemerer:A Metrics Suite for Object Oriented Design 428-15

  9. Coupling and cohesion • Number and complexity of shared variables • Functions in a module should share variables • Functions in different modules should not • Number and complexity of parameters • Number of functions/modules that are called • Number of functions/modules that call me 428-15

  10. Dhama’s coupling metric Module coupling = 1 / (number of input parameters + number of output parameters + number of global variables used + number of modules called + number of modules calling) .5 is low coupling, .001 is high coupling. 428-15

  11. Martin’s coupling metric • Ca: Afferent coupling: the number of classes outside this module that depend on classes inside this module • Ce: Efferent coupling: the number of classes inside this module that depend on classes outside this module • Instability = Ce / (Ca + Ce) 428-15

  12. Main sequence • A: Abstractness (# abstract classes in module / # classes in module) (0,1) Abstractness (1,0) Instability 428-15

  13. Technical metrics • A Metrics Suite for Object Oriented Design, Shyam R. Chidamber and Chris F. Kemerer IEEE Transactions on Software Engineering, June 1994, pp 476-493 • Chapter 4 of Hamlet and Maybee, especially 4.3 428-15

  14. List of metrics • Weighted Methods per Class • Depth of Inheritance Tree • Number Of Children • Coupling Between Object classes • Response for a Class • Lack of Cohesion in Methods 428-15

  15. Weighted Methods per Class WMC: for each class, take the sum of the complexities of the methods in the class Possible method complexities • 1 (number of methods) • Lines of code • Number of method calls • Cyclomatic complexity 428-15

  16. Weighted Methods per Class • The number of methods and the complexity of methods predicts the time and effort required to develop and maintain a class • The larger the number of methods in a class, the greater the potential impact on children • Classes with large numbers of methods are more likely to be application specific and less reusable 428-15

  17. Weighted Methods per Class 428-15

  18. Depth of Inheritance Tree • DIT: Maximum length from a class to the root of the tree • The deeper a class is in the hierarchy, the more methods it inherits and so it is harder to predict its behavior • The deeper a class is in the hierarchy, the more methods it reuses • Deeper trees are more complex 428-15

  19. Depth of Inheritance Tree 428-15

  20. Number Of Children • NOC: Number of immediate subclasses • More children is more reuse • A class might have a lot of children because of misuse of subclassing • A class with a large number of children is probably very important and needs a lot of testing 428-15

  21. Number of Children • Almost all classes have 0 children • Only a handful of classes will have more than five children 428-15

  22. Coupling Between Object classes • CBO: Number of other classes to which a class is coupled • Class A is coupled to class B if there is a method in A that invokes a method of B • Want to be coupled only with abstract classes high in the inheritance hierarchy 428-15

  23. Coupling Between Object classes • Coupling makes designs hard to change • Coupling makes classes hard to reuse • Coupling is a measure of how hard a class is to test 428-15

  24. Coupling Between Object classes • C++ project: median 0, max 84 • Smalltalk project: median 9, max 234 428-15

  25. Response For a Class • RFC: Number of methods in a class or called by a class • The response set of a class is a set of methods that can potentially be executed in response to a message received by an object of that class 428-15

  26. Response For a Class • If a large number of methods can be invoked in response to a message, testing becomes more complicated • The more methods that can be invoked from a class, the greater the complexity of the class 428-15

  27. Response For a Class • C++: median 6, max 120 • Smalltalk: median 29, max 422 428-15

  28. Lack of COhesion in Methods • LCOM: Number of pairs of methods that don’t share instance variables - number of pairs of methods that share instance variables • Cohesiveness of methods is a sign of encapsulation. • Lack of cohesion implies classes should be split 428-15

  29. Lack of COhesion in Methods • C++: median 0, max 200 • Smalltalk: median 2, max 17 • Smalltalk system had only a few zero 428-15

  30. What is best? • WMC or list of long methods? • DIT or list of classes with depth over 6? • NOC or list of classes with more than 6 children? • CBO or list of classes with high coupling? 428-15

  31. Questions? • Who looks at these figures? • What is done with the results? • How do you get the figures? 428-15

  32. The goal of measurement • Software measurement is a means to an end, not an end in itself • What is causing poor quality? • Where are we spending all our time on software development? • How accurate are our estimates? • What is the most cost-effective way to improve our quality? 428-15

  33. Next time • Software Measurement Guidebook • http://swg.jpl.nasa.gov/resources/NASA-GB-001-94.pdf • Pages 1-20 and 30-49 428-15

More Related