The definition of abstractness of a package p as

                     NumberOfAbstractClasses(p) + NumberOfInterfaces(p)
  Abstractness(p) := --------------------------------------------------
                                       NumberOfTypes(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.

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).

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( ---------------------------------- )
                                                                          NumberOfTypes(p)

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.

• Corresponding Story in Jira