Object-Oriented Metrics

1
Object-Oriented Metrics

• Renaat Verbruggen
• School of Computing,
• Dublin City University

2
Introduction and Welcome

• My Background
• Esprit Object-oriented Project 1986
• Lecturer in Software Engineering
• Research in formal OO
• Consultant to Industry on OO

3
Agenda

• What is different about Object-oriented projects?
• What is measurement in software development ?
• What are typical OO metrics ?
• What other guidelines exist?

4
Differences in OO projects 1

• The code produced.
• Encapsulation
• Data Abstraction (Classes)
• Inheritance
• Polymorphism
• Not just Lines of Code.

5
Differences in OO projects 2

• Reuse a priority
• Use (reuse) of libraries or Frameworks
• Reuse through Inheritance
• Reuse above code level
• Patterns
• Business objects

6
Differences in OO projects 3

• Reuse changes process
• Build reusable components
• Frameworks and libraries
• Abstraction, generalisation
• Cost ? Investment
• Find and reuse components
• Saving ? return on investment

7
Differences in OO projects 4

• Development process iterative
• Often the major difference !
• Growth of software over iterations
• Reuse-based
• Change considered explicitly
• Support for risk management
• ? Need for early and updated metrics

8
Reasoning 1

• Tom DeMarco
• ''You cannot control what you cannot measure.''
• Clerk Maxwell
• ''To measure is to know.''

9
Reasoning 2

• Lord Kelvin
• ''The degree to which you can express something
  in numbers is the degree to which you really
  understand it.''
• Louise Pasteur
• ''A science is as mature as its measurement
  tools.''

10
Experience 1

• Lowell Arthur
• ''Better a little caution than a great regret.''
• Victor Basili
• ''Measurement is an excellent abstraction
  mechanism for learning what works and what
  doesn't.''

11
Experience 2

• Frederick Brooks
• ''Adding manpower to a late software project
  makes it later.''
• Tom Gilb
• ''Project without clear goals will not achieve
  their goal clearly.''

12
Experience 3

• Law of Parkinson
• ''Work expands to fill the available time.''

13
Measurement

• What is measurement ?
• "Measurement is the process by which numbers or
  symbols are assigned to attributes of entities in
  the real world in such a way as to describe them
  according to clearly defined rules." (Norman
  Fenton)

14
Measurement

• Units of Measurement
• Measure a persons temperature
• Celsius
• Fahrenheit
• Feverish - too hot (analogy)
• Accuracy
• Replicability
• How do we measure software ?

15
Measurable Project Goals

• Are the following measurable goals ?
• The software will not fail
• The software will be easy to use
• The project will be completed by June 30
• The product will meet all requirements
• What makes a goal measurable ?

16
Setting Measurable Goals

• Metric Definition
• Clarity
• Non-ambiguous
• Common Understanding
• Replicability
• Accuracy ?
• Examples

17
Setting up Measures 1

• Establish why you are measuring
• Goal-Question-Metric(GQM)
• 1. define goal or purpose
• 2. Break down into questions
• 3. Pick suitable metrics
• Create a Metrics programme within company
• Choose metrics already developed

18
Setting up Measures 2

• Create your own metrics ?
• Define the metric as completely as possible
• Define the properties of attribute to be measured
• Define the object to be measured , the metrics
  domain
• Define the metric.
• Formality is essential

19
Setting up Measures 3

• Validate the metric theoretically
• Prove that the properties are met
• Prove that the dimensions of the metric are sound
• Determine the scale for the metric

20
Setting up Measures 4

• Validate the metric practically
• devise best means to measure
• level of automation
• minimum disruption for developers
• Use metric in several practical places.
• Promote metric

21
Setting up Measures 5

• Example
• Attribute to be measured product size
• Essential property positive, additive
• Metric domain set of lines ending with \n
• Metric Name LOC
• Theory
• LOC is an absolute scale type
• Fulfils essential property of product size

22
Setting up Measures 6

• Yet LOC has problems - why?
• Because it is modelled simplistically
• \n s are just one element to the product size.
• Used to try to capture too much about the
  software.

23
Software Metrics Validation

• "Validation of a software measure is the process
  of ensuring that the measure is a proper
  numerical characterisation of the claimed
  attribute this means showing that the
  representation condition is satisfied.
• Norman Fenton, City University London

24
Shyam R. Chidamber Chris F. Kemerer

• Suggested metrics for OO

25
Weighted Methods Per Class (as sum of the McCabe
numbers)

• The number of methods and the complexity of
  methods involved is an indicator of how much time
  and effort is required to develop and maintain a
  class.
• The larger the number of methods in a class the
  greater the potential impact on children, since
  children will inherit all the methods defined in
  the class.
• Classes with large numbers of methods are likely
  to be more application specific, limiting the
  possibility of reuse.''

26
McCabes Cyclomatic Complexity

• Based on the control graph of the program
• Can be used to decide on basis path testing etc.
• no. linearly independent paths
• no. of edges - no of nodes modules

27
Depth of Inheritance Tree

• The deeper a class is in the hierarchy, the
  greater the number of methods it is likely to
  inherit, making it more complex to predict its
  behaviour.
• Deeper trees constitute greater design
  complexity, since more methods and classes are
  involved.
• The deeper a particular class is in the
  hierarchy, the greater the potential reuse of
  inherited methods.

28
Number of Children(as number of immediate
sub-classes)

• Greater the number of children, greater the
  reuse, since inheritance promotes reuse.
• Greater the number of children, the greater the
  likelihood of improper abstraction of the parent
  class. If a class has a large number of children,
  it may be a case of misuse of sub-classing.
• The number of children gives an idea of the
  potential influence a class has on the design. If
  a class has a large number of children, it may
  require more testing of the methods in that
  class.

29
Response For a Class (as number of used methods)

• If a large number of methods can be invoked in
  response to a message, the testing and debugging
  of the class becomes more complicated since it
  requires a greater level of understanding
  required on the part of the tester.
• The larger the number of methods that can be
  invoked from a class, the greater the complexity
  of the class.
• A worst case value for possible responses will
  assist in appropriate allocation of testing time.

30
Coupling Between Objects 1

• Excessive coupling between objects is detrimental
  to modular design and prevents reuse. The more
  independent an object is, the easier it is to
  reuse it in another application.
• In order to improve modularity and promote
  encapsulation, inter-object couples should be
  kept to a minimum. The larger the number of
  couples, the higher the sensitivity to changes in
  other parts of the design and therefore
  maintenance is more difficult.

31
Coupling Between Objects 2

• A measure of coupling is useful to determine how
  complex the testing of various parts of a design
  are likely to be. The higher the inter-object
  coupling, the more rigorous the testing needs to
  be.''

32
Lack of Cohesion in Methods (disjunctive
instance variables)

• Cohesiveness of methods within a class is
  desirable, since it promotes encapsulation.
• Lack of cohesion implies classes should probably
  be split into two or more sub/classes.
• Any measure of disparateness of methods helps
  identify flaws in the design of classes.
• Low cohesion increases complexity, thereby
  increasing the likelihood of errors during the
  development process.

33
Design Metrics And Experience 1

• From Mark Lorenz
• 1. The average method size should be less than 8
  LOC for Smalltalk and 24 LOC for C. Bigger
  averages indicate O-O design problems (i.e.
  function-oriented coding).
• 2. The average number of methods per class should
  be less than 20. Bigger averages indicate too
  much responsibility in too few classes.

34
Design Metrics And Experience 2

• 3. The average number of instance variables per
  class should be less than 6. Similar in reasoning
  as the previous point - more instance variables
  indicate that one class is doing more than it
  should.
• 4. The class hierarchy nesting level should be
  less than 6. Start counting at the level of any
  framework classes that you use or the root class
  if you don't.
• 5. The number of subsystem-to-subsystem
  relationships should be less than the average
  number of class-to-class relationships within a
  subsystem.

35
Design Metrics And Experience 3

• 6. The number of class-to-class relationships
  within a subsystem should be relatively high.
• 7. The instance variable usage by the methods
  within a class can be used to look for possible
  design problems.
• 8. The average number of comment lines should be
  greater than 1. Smaller averages indicate too
  little documentation with the (small) methods.
• 9. The number of problem reports per class should
  be low.

36
Design Metrics And Experience 4

• 10. The number of times a class is reused across
  the original application and in other
  applications might indicate a need to redesign
  it.
• 11. The number of classes and methods thrown away
  should occur at a steady rate throughout most of
  the development process.

37
Other Experience 1

• 1. A prototype class has 10 to 15 methods, each
  with 5 to 10 lines of code, and takes 1
  person-week to develop.
• 2. A production class has 20 to 30 methods, each
  with 10 to 20 lines of code, and takes 8
  person-weeks to develop. In both these cases,
  development includes documentation and testing.
• 3. C will have 2 to 3 times the lines of code
  of Smalltalk.
• 4. Code volume will expand in the first half of
  the project and decline in the second half, as
  review clean up the system.

38
Other Experience 2

• 5. Deeply nested classes are more complex, due to
  inheritance.
• 6. A class or group of classes (e.g., a
  framework) with a low amount of coupling to other
  classes will be more reusable.
• 7. A class has higher cohesion if its methods
  utilise similar sets of instance variables.

39
Project Completion Metrics And Experience 1

• 1.The average number of support classes per key
  class ... will help you to estimate the total
  number of classes in the final system.
• 2. The average man-days per application class ...
  to estimate the amount of human resources you
  need to complete the project.
• 3. The average number of classes per developer
  ... will help you decide what staffing level
  needed to develop the application.

40
Project Completion Metrics And Experience 2

• 4. The number of major iterations ... will help
  you schedule times when early-release drivers can
  be given to customers and human factors staff to
  verify requirements and usability.
• 5. The number of subsystems should relate to
  major functionally-related portions of the total
  business' system.

41
Establishing A Metrication Programme 1

• Barbara Kitchenham
• 1. Define your goals (which are likely to include
  requirements for measurements to support basic
  management activities).
• 2. Identify measures that will support the
  monitoring and achievement of those goals.
• 3. Define and plan the metrication programme.

42
Establishing A Metrication Programme 2

• 4. Establish a data collection system to support
  the metrication programme.
• 5. Analyse your collected data to support your
  management activities and monitor achievement of
  your goals.
• 6. Review and update your goals in the light of
  your achievements.

43
Establishing A Metrication Programme 3

• 7. Update your data collection in the light of
  your changing goals and management requirements."

44
Software Metrics Application 1

• "What do the successful companies do
• They have 'decriminalized' errors. People talk
  openly about what they have done wrong as a means
  of self-improvement. There is no need to hide
  failure management is not allowed to, or simply
  does not, use it against you.

45
Software Metrics Application 2

• Measurement is part of 'how we do business.' That
  is, there is no management mandate or policy that
  causes measurement to happen, but rather a common
  understanding that it is the only reasonable way
  to build product."

46
Software Metrics Application 3

• They tend to have achieved an SEI process level
  of 4 or 5 (very good) without ever having passed
  through level 3. That is, they measure and use
  feedback to improve their software process
  without ever having invoked a defined process!
  (That is, of course, the epitome of
  technologist/experimentation vs.
  management/control.)

47
Object Oriented Metrics

• Process of development tends to be different.
• Project should not be penalised for this
• Or allowed too much free rein !
• Metrics are a very useful addition to an
  object-oriented project.

48
New Guidelines

• Warning Signs
• RFC gt 100
• RFC gt 5 NMC
• CBO gt 5
• WMC gt 100
• NMC gt 40

49
Overall

• Far more important to validate current metrics
  empirically than propose new ones
• Aim to make link to productivity, quality and
  project management