SDA SE Wiki

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

User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
teaching:labs:xp:2009a:improved_abstractness_metric [2009/03/26 22:35]
Daniel Speicher
teaching:labs:xp:2009a:improved_abstractness_metric [2018/05/09 01:59] (current)
Line 1: Line 1:
 +====== Improved Abstractness Metric ======
  
 +===== Current Definition of Abstractness =====
 +
 +
 +The definition of abstractness of a package ''​p''​ as 
 +
 +<​Code>​
 +                     ​NumberOfAbstractClasses(p) + NumberOfInterfaces(p)
 +  Abstractness(p) := --------------------------------------------------
 +                                       ​NumberOfTypes(p)
 +
 +</​Code>​
 +
 +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:
 +  - Depth of Inheritance Tree (DIT)
 +  - Generality as expressed by type names (not yet defined, challenge: concrete names are often used as metaphors for abstract ideas)
 +  - Abstractness of the packages my package depends on (not yet defined, challenge: interferes with definition of Stability)
 +  - 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'':​
 +
 +<​Code>​
 +
 +                                                           ​PureConcreteDIT -       d
 +   ​DepthOfInterheritanceAsAbstractness(d) := min(1, max(0, --------------------------------- ) )
 +                                                           ​PureConcreteDIT - PureAbstractDIT
 +
 +
 +</​Code>​
 +
 +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:
 +
 +<​Code>​
 +                                                                   Sum(t in p; DepthOfInheritance(t))
 +   ​ImprovedAbstractness(p) := DepthOfInterheritanceAsAbstractness( ---------------------------------- )
 +                                                                          NumberOfTypes(p)
 +
 +</​Code>​
 +
 +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.
 +
 +  * [[http://​fingon01.iai.uni-bonn.de:​8080/​jira/​browse/​CV-563|Corresponding Story in Jira]]
teaching/labs/xp/2009a/improved_abstractness_metric.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019