Code metrics: Instability index

[zbeekman]

As defined by Martin in Agile Software Development ... and cited by Rouson in Scientific Software Design it is possible to quantify coupling in a software package via and instability index, I

Here Ca is the number of afferent couplings and Ce is the number of efferent couplings. (Afferent couplings are things which depend on the thing in question, e.g., number of children, efferent couplings are the number of things upon which the thing it question depends, e.g., number of parents.)

It seems that this principle is most commonly applied to abstract data types (i.e., abstract derived types) but I think it could be applied to modules, and even procedures.

Due to the call graph and module/type dependency graph information, I think FORD already has all the necessary information to compute these code metrics. For abstract derived types: Ca is the number of derived types that extend it or list it as a component. Ca is the number of abstract types it extends.

For modules, Ca is the number of modules, procedures, and programs that use the module in question. Ce is the number of modules it uses (even indirectly due to the transitive nature of module use association... of course with private this is less of an issue, but I still think it would make sense to count all transitive uses too. For example A uses B uses C, therefore A uses C).

Just a thought, and if it's not prohibitively a PITA to implement, a feature request.

[cmacmackin]

This should be quite easy for the modules and derived types. The issue with procedure calls is the same one which currently afflicts the call-tree graphs: type-bound procedures are not recognized. That is something on my todo list, but it will not be a fun thing to implement, so it is quite a long way down.

On Wed, Jan 13, 2016 at 5:36 PM, Izaak Beekman notifications@github.com wrote:

As defined by Martin in Agile Software Development ... http://amzn.to/1mVPolj and cited by Rouson in Scientific Software Design http://amzn.to/1Q5zccX it is possible to quantify coupling in a software package via and instability index, I

[image: equation] https://camo.githubusercontent.com/83f57ca5a5cba1b8f829701571d483c6f5f4676f/687474703a2f2f7777772e736369776561766572732e6f72672f75706c6f61642f54657832496d675f313435323730353836382f65716e2e706e67

Here Ca is the number of afferent couplings and Ce is the number of efferent couplings. (Afferent couplings are things which depend on the thing in question, e.g., number of children, efferent couplings are the number of things upon which the thing it question depends, e.g., number of parents.)

It seems that this principle is most commonly applied to abstract data types (i.e., abstract derived types) but I think it could be applied to modules, and even procedures.

Due to the call graph and module/type dependency graph information, I think FORD already has all the necessary information to compute these code metrics. For abstract derived types: Ca is the number of derived types that extend it or list it as a component. Ca is the number of abstract types it extends.

For modules, Ca is the number of modules, procedures, and programs that use the module in question. Ce is the number of modules it uses (even indirectly due to the transitive nature of module use association... of course with private this is less of an issue, but I still think it would make sense to count all transitive uses too. For example A uses B uses C, therefore A uses C).

Just a thought, and if it's not prohibitively a PITA to implement, a feature request.

— Reply to this email directly or view it on GitHub https://github.com/cmacmackin/ford/issues/99.

Chris MacMackin

[zbeekman]

sure, I'd be very happy with modules and procedures. BTW, I vaguely remember discussing it at some point in the past, but can FORD generate file dependency graphs? (To aid in understanding the required compilation order.) If so computing this metric for files would also be great.

[cmacmackin]

Should be able to. What would be even easier, actually, would be to create a list of files in the order they'd need to be compiled.

On 16-01-13 05:52 PM, Izaak Beekman wrote:

sure, I'd be very happy with modules and procedures. BTW, I vaguely remember discussing it at some point in the past, but can FORD generate file dependency graphs? (To aid in understanding the required compilation order.) If so computing this metric for files would also be great.

— Reply to this email directly or view it on GitHub https://github.com/cmacmackin/ford/issues/99#issuecomment-171378490.

Chris MacMackin cmacmackin.github.io http://cmacmackin.github.io

[szaghi]

@cmacmackin FoBiS create the dependency hierarchy very easy, you can grab it from FoBiS, evrn if I think FORD already has all the nrcessary info.

I vote for this feature request :+1:

[zbeekman]

Should be able to. What would be even easier, actually, would be to create a list of files in the order they'd need to be compiled.

That would be a great feature too, but the dependency graph and the file instability index would be great.

[cmacmackin]

Due to the call graph and module/type dependency graph information, I think FORD already has all the necessary information to compute these code metrics. For abstract derived types: Ca is the number of derived types that extend it or list it as a component. Ca is the number of abstract types it extends.

For modules, Ca is the number of modules, procedures, and programs that use the module in question. Ce is the number of modules it uses (even indirectly due to the transitive nature of module use association... of course with private this is less of an issue, but I still think it would make sense to count all transitive uses too. For example A uses B uses C, therefore A uses C).

I don't have my copy of Rouson's book with me at the moment (I'm away visiting family) so my memory of the instability index is a bit hazy, but I'm not entirely sure you're approach here makes sense. Why should coupling be transitive for types but not for modules? Furthermore, surely a routine taking a type as an argument or returning an instance would count as afferent coupling for that type? Where do we draw the line? I'm wondering if the stability index is well-enough defined to be worth calculating.