Fan-in and Fan-out Metrics Seem to be Swapped

[git-afsantos]

Hello,

The definitions for fan-in and fan-out in the CCCC User Guide are as follows.

For a given module A, the fan-out is the number of other modules which the module A uses, while the fan-in is the number of other modules which use A.

These definitions are very close to the common definitions for Afferent Coupling (fan-in) and Efferent Coupling (fan-out), and I was using CCCC (version 3.1.4) to gather such metrics.

In the top-level XML report (cccc.xml) it seems to me that, either I did not understand the metrics definitions correctly (and, if so, I would ask for some clarification), or the reported values are actually swapped.

Consider the following example code.

#include <string>

class A {
  std::string name;
  A(const std::string& _name) : name(_name) {}
};

class B {
  A a;
  B(const std::string& name) : a(name) {}
};

int main(int argc, char **argv) {
  B b1("1"), b2("2");
  return 0;
}

For class A the fan-in and fan-out are both 1, which is to be expected (A uses string and is used by B). For class B, however, I get a fan-out of 0 and a fan-in of 2, which is backwards.

The report for module B (B.xml) correctly reports class B as having two suppliers, A and string.

It seems to me that the problem is in the counting for fan-in and fan-out. Fan-in is being counted based on the suppliers and fan-out is being counted based on the clients. Since a supplier is used by the module, it should be fan-out, while a client uses the module, and thus should be fan-in.

If you agree with my assessment, and are still accepting bug fixes, I can even provide the pull request to swap these two values.

---

Also, I initially tried this example with the struct keyword, instead of class (which is more or less equivalent in C++), and in this case the classes are not counted as modules, even with the --lang=c++ option. But I understand that this is a separate issue.

[sarnold]

Sorry, another one lost in the notification flood... It's been a while since i looked at this code, but your assessment does sound valid; if you still want to submit a PR I'll give it a once (or twice) over. Thanks!

[sarnold]

bump I spent a little more time looking at this, and I still agree the definitions/code seem "swapped" from what they should be (mainly because of the human interpretation of client/supplier and uses/used-by). Hopefully @tim-littlefair can still chime in, but I'm inclined to test this and push a new release if things look good.

[tim-littlefair]

Steve Only just spotted this. It's late in the evening, so I probably won't have time to look at it this weekend. Happy for you to just push it out if you're happy and I'll take a look and catch up later. In all the emails I've had since I started the project, I think this is the first time I've seen anyone take an interest in the Henry/Kafura information flow metrics, which I found much more compelling that either the Chidamber/Kemerer OO metrics or the old-school LOC/COM/MVG stuff when I was working the project up. Do you believe that some people are paying attention to this as actionable information, or is it just that after all this time someone has read the code (or the results) and noticed that I got things the wrong way round. I hope it's all going well with you, thanks for keeping CCCC alive. regards Tim

…

On 4/26/19, Steve Arnold ***@***.***> wrote: *bump* I spent a little more time looking at this, and I still agree the definitions/code seem "swapped" from what they should be (mainly because of the human interpretation of client/supplier and uses/used-by). Hopefully @tim-littlefair can still chime in, but I'm inclined to test this and push a new release if things look good. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #16 (comment)

[tim-littlefair]

I've looked at the code, and gone back and refreshed the definitions of FI and FO on the web (not the original Henry/Kafura paper unfortunately, but enough places to check there is a consensus), and it's clear that this is a bug. Mine. More than 20 years old. I hope no-one was relying on this over all this time...

On the topic of this observation from André ...

Also, I initially tried this example with the struct keyword, instead of class (which is more or less equivalent in C++), and in this case the classes are not counted as modules, even with the --lang=c++ option. But I understand that this is a separate issue.

...
I accept that the implementation of a type declared using the struct keyword in C++ is similar to the implementation of a type declared using the class keyword, but the two keywords have history and designed purpose associated with them which changes our expectation of how they should be used. I remember thinking about this issue when I was writing this code all those years ago, and I decided (rightly or wrongly) that the class keyword was intended by the designers of C++ to define types which had both data content and operations, and which would normally conform to an OO convention of having a public interface and private implementation details, whereas struct was inherited from ANSI C, allowed to gain some extra syntax in C++ for consistency with classes, but was not intended to be used for types which were intended to conform to the OO paradigms (information hiding, data private by default etc).

André (or anyone else) has a body of code to analyze in which this decision is turning out to be inconvenient, I suspect that a small change to the CCCC_Module::is_trivial() method would change behaviour so that structs would be treated as if they were classes.

[git-afsantos]

Thanks for the reply, Tim.

this is the first time I've seen anyone take an interest in the Henry/Kafura information flow metrics

And CCCC is probably the only free tool measuring these, which I also find surprising, as they seem to convey useful information. Just so you know, I am contributing to a group that is making some efforts to improve quality of robotics software. These metrics belong to the set that the group has agreed upon.

the two keywords have history and designed purpose associated with them which changes our expectation of how they should be used

Agreed, and I understand your stance. It is a valid decision, just one that I was not expecting at first, so I figured I would report it as well.

I suspect that a small change to the CCCC_Module::is_trivial() method would change behaviour so that structs would be treated as if they were classes.

Thanks for the pointer. Might be useful if the need for this change arises. 👍