Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools

Improved Abstractness Metric

Current Definition of Abstractness

The definition of abstractness of a package p as

                     NumberOfAbstractClasses(p) + NumberOfInterfaces(p)
  Abstractness(p) := --------------------------------------------------

interprets classes like java.lang.String as concrete although they a clearly meant to be used in many different applications (i.e. they are abstract). On the other hand classes deep in the inheritance tree that are still marked as abstract are considered as abstract in the sense of this metric although they might carry already a lot of concrete behavior.

Improved Definition of Abstractness

We see different bases to improve this metric:

  1. Depth of Inheritance Tree (DIT)
  2. Generality as expressed by type names (not yet defined, challenge: concrete names are often used as metaphors for abstract ideas)
  3. Abstractness of the packages my package depends on (not yet defined, challenge: interferes with definition of Stability)
  4. Topological sort order of the dependency graph (cycles would get the same abstractness level, unfortunately ADP would become tautological then).

Reinterpreted Average Depth of Inheritance Tree

For now we want to go with the first option and suggest a definition of abstractness parametrized by the values PureAbstractDIT, PureConcreteDIT (default PureAbstractDIT = 1, PureConcreteDIT = 5). We define a function to rescale the values of DepthOfInheritanceTree:

                                                           PureConcreteDIT -       d
   DepthOfInterheritanceAsAbstractness(d) := min(1, max(0, --------------------------------- ) )
                                                           PureConcreteDIT - PureAbstractDIT

With this definition DepthOfInterheritanceAsAbstractness(DepthOfInheritance(t)), where t is a type (i.e. a class or an interface), is 1 for all types with DepthOfInheritance(t) =< PureAbstractDIT and 0 for all types with DepthOfInheritance(t) >= PureConcreteDIT.

Based on this the definition of our ImprovedAbstractness is almost straight forward:

                                                                   Sum(t in p; DepthOfInheritance(t))
   ImprovedAbstractness(p) := DepthOfInterheritanceAsAbstractness( ---------------------------------- )

In this definition there was one choice made: We rescale after calculating the average DepthOfInheritance. This is to allow types with a very high (or very low) DepthOfInheritance still to influence the result. This corresponds to our intuition that a package with some abstract types and one concrete gets more concrete if this one concrete type moves to a lower position in the inheritance tree.

teaching/labs/xp/2009a/improved_abstractness_metric.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2024