Re: Measuring OO Reuse



Responding to Jasongorman...

Hi Folks

I've been tasked with designing metrics to help track progress on a
software process improvement program, and I'm getting bogged down in
measuring reuse.

So far, I've not found much in the way of useful literature that could
help me actually code the metric. I've been customising NDepend (it's a
.NET project), and my working definition of reuse at the moment is:

* A method is reused if it's called by MORE THAN ONE CLIENT in a
different assembly (since the unit of reuse is the unit of release, and
the .NET unit of release is an assembly).

Why the constraint of MORE THAN ONE CLIENT? If the same method is accessed in different assemblies, it is reused. I can only see clients being an issue within an assembly. However, if assembly granularity is fine enough (e.g., subsystems, deployable components, etc.), then I would not worry about reuse within that granularity. That is, reuse within a subsystem is just modularity to eliminate duplication; it is subject matter context that determines reuse value.



NDepend already counts the instructions in each method body, and the total number of instructions in each .NET assembly.

The percentage code reuse per assembly would therefore be:

percent reused = reused instructions / total instructions

Seems simple enough, until you consider that:

a. When a method is reused, it may use other methods (e.g., private
methods or methods on collaborators, or even methods on the reusing
client object), and therefore their instructions are also reused.

If one just counts methods used in different assemblies, then I don't think this is relevant. Those methods are going to be counted anyway individually simply because they are there.



b. NDepend can tell me when one method depends on another method, but if we're binding to an abstraction, how can I tell which implementation is actually being reused?

I don't understand why you care about dependencies at all. Just count concrete methods accessed in multiple contexts. How many times they are accessed within a context really doesn't matter (i.e., that's a code duplication issue, not a reuse issue). IOW, the value of the reuse is proportional to the number of relevant contexts, not how it is used within a specific context.



************* There is nothing wrong with me that could not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.



Relevant Pages

  • Re: Identical binaries from same source code
    ... I wouldn't set the GUIDs and times to zero - I'd choose ... appropriate values and always reuse those. ... We don't need to sign the assemblies. ... of the binaries, so long as you could explain that they don't affect ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: implementing roles in OOP......
    ... The only productivity benefits are gained in maintenance. ... I can only speak for myself, but in the context of software ... reuse - I obviously have no metrics - I was too busy writing software. ... > I'd want a lot of hard data before doing so. ...
    (comp.object)
  • Re: SoA Vs OO
    ... > One of the initial big ideas in OO was reuse. ... For example take a bank that develops a credit ... how can something tought in a local context be suitable without ... context and usage profile. ...
    (comp.object)
  • Re: SoA Vs OO
    ... > One of the initial big ideas in OO was reuse. ... For example take a bank that develops a credit ... how can something tought in a local context be suitable without ... context and usage profile. ...
    (comp.programming)
  • Re: MAKELANGID
    ... > How do you reuse C++ macros in C#? ... quoting helps keeping a post in context. ...
    (microsoft.public.dotnet.languages.csharp)