文档名称：功能单元最大扇入扇出工具分析
作 者: 日 期：
1. 概念
由于度量的目标是C 源代码，所以“功能单元的最大扇入扇出”的含义如下： 功能单元：c 语言的函数。
扇入：有多少其他函数调用了A 函数。
扇出：A 函数调用了多少其他函数。
2 cFlow
2.1 工具简介
GNU 计划，又称革奴计划，是由Richard Stallman在1983年9月27日公开发起的。它的目标是创建一套完全自由的操作系统。Richard Stallman 最早是在net.unix-wizards 新闻组上公布该消息，并附带一份《GNU 宣言》等解释为何发起该计划的文章，其中一个理由就是 要“重现当年软件界合作互助的团结精神”。为保证GNU 软件可以自由地“使用、复制、修改和发布”，所有GNU 软件都在一份在禁止其他人添加任何限制的情 况下授权所有权利给任何人的协议条款，GNU 通用公共许可证（GNU General Public License，GPL ）。即“反版权”（或称Copyleft ）概念。
2.2 工具优缺点总结
cflow 程序会输出一个函数调用树，这是一个显示函数调用关系的图表。这对于查看程序结构来了解他是如何操作的以及了解对于一个函数有哪些影响是十分有用的。一些版本的cflow 可以同时作用于目标文件与源代码。查看手册页我们可以了解更为详细的操作。
GNU 官方的一个工具，最大的优点是成熟、可靠。
但源代码比较难读懂。GNU 的东西，封装性、技巧性比较强。
2.3 使用例程
1. 下载源代码
2. 解压
3. ./configure
4. make
5. make install
6. cflow tes.c
main() :
printf()
do_something_firstly() : malloc()
free()
do_something_finally() : printf()
7. 输出结果
2.4 核心代码抽取
通过此工具的源代码，可以获取匹配函数定义语句的功能，函数调用关系的功能，从来实现fan-in ，fan-out 度量。
3 C and C++ Code Counter
3.1 工具简介
3.2 工具优缺点总结
功能强大，基本能够进行所有的静态度量。支持c 语言。 缺点：源代码比较复杂，研读需要时间。
并不支持函数的扇入扇出。
4.3 实例
1. 实例代码：
#include
/*test example*/
int f1()
{
int a=1,b=2;
if (a==1)
a=4;
else
{
if (b==2)
{
a=4;
}
}
return 1;
}
int f2()
{
return 1;
}
int f3()
{
f1();
f2();
return 1;
}
main()
{
int a=10;
f1();
f2();
f3();
}
2. 安装cccc
官方网站下载安装文件
3. 执行度量
4. 查看结果
F3调用了f1,f2，但度量结果，并没有反应出来。
4.4 分析
扇出扇出的分析：
Fan-In, Fan-Out (FI,FIc,FIv,FO,FOc,FOv)
Traditionally, use relationships between modules were identified by counting function invocations or access to module data in procedural code. CCCC identifies relationships only through
structures apparent in the definitions of the interfaces of C++ classes or Java classes or interfaces. The specific relationships which can be detected are inheritance of a supplier class by a client, containment of an instance of a supplier class in a client, and the
existence of member functions of the client class which accept or return an instance of the supplier.
While these relationships may seem unrelated to the
invocation and module data counts, they are likely to show
a strong corelation because of the fact that in an object
oriented environment, it is likely (but not inevitable) that
the low-level use relationships of invocation and direct
access to data structures require an object of the class of
the supplier module to be available. This availability can
be through instantiation of an instance of the supplier class
within procedural code, but will often be due to the existence
of one of the higher level relationships described above.
The counts of Fan-In and Fan-Out are regarded as a measure
of the structural quality of a program, with high values of
either (and particularly high values of both within the same
module) indicating increased risk of changes required in one
module requiring changes across other modules. CCCC chooses
to define the relationship counts in such a way that each
supplier or client module is counted only once, however many
separate ways the relationship is detected. CCCC applies
filtering to the relationships identified to distinguish
between different kinds of uses which may carry with them
different levels of structural risk. There are two filters:
visibility and concreteness.
The visibility filter removes from consideration
relationships which are known to be only accessible from the
private interface of a module. Relationships which are
defined in the visible part of the interface can be exploited
by clients of the current module, thus forcing those clients
also to be clients of the current module's supplier. Visible
relationships also increase the range of operations
available on an object, thus increasing the cognitive
complexity of the interface from the point of view of a
programmer required to use a module.
The concreteness filter removes from consideration
relationships which do not create a dependency of the
implementation of the client module on the implementation of
the supplier class. Dependency-creating relationships
increase risk because they may not be cyclical, and thus
inhibit the creation of other relationships. They also
inhibit the ability of modules to be built separately,
requiring recompilation of the client module when the
supplier changes. The test for this filter in C++ is whether
a forward declaration of the supplier class is adequate to
allow the client module definition to be compiled:
containment and parameter passing where the client module is
modified by a referential operator are allowed in this case,
containment or passing by value or inheritance are all
dependency-creating. In Java, relationships except
inheritance are treated as non-dependency creating.
通过上述cccc 的原文，可以得知，cccc 中的扇入扇出是关于类之间的。 4 结论
计算java 语言的圈复杂度工具有很多，例如Analysis(eclipse的一个插件) 。
计算扇入扇出的主要技术点：
1．确定函数定义部分
2．确定函数调用fanout
3．确定被调次数fanin
可以通过cFlow 和Cccc 的源代码，尽量抽取出来。 CherryPick , Lachesis
文档名称：功能单元最大扇入扇出工具分析
作 者: 日 期：
1. 概念
由于度量的目标是C 源代码，所以“功能单元的最大扇入扇出”的含义如下： 功能单元：c 语言的函数。
扇入：有多少其他函数调用了A 函数。
扇出：A 函数调用了多少其他函数。
2 cFlow
2.1 工具简介
GNU 计划，又称革奴计划，是由Richard Stallman在1983年9月27日公开发起的。它的目标是创建一套完全自由的操作系统。Richard Stallman 最早是在net.unix-wizards 新闻组上公布该消息，并附带一份《GNU 宣言》等解释为何发起该计划的文章，其中一个理由就是 要“重现当年软件界合作互助的团结精神”。为保证GNU 软件可以自由地“使用、复制、修改和发布”，所有GNU 软件都在一份在禁止其他人添加任何限制的情 况下授权所有权利给任何人的协议条款，GNU 通用公共许可证（GNU General Public License，GPL ）。即“反版权”（或称Copyleft ）概念。
2.2 工具优缺点总结
cflow 程序会输出一个函数调用树，这是一个显示函数调用关系的图表。这对于查看程序结构来了解他是如何操作的以及了解对于一个函数有哪些影响是十分有用的。一些版本的cflow 可以同时作用于目标文件与源代码。查看手册页我们可以了解更为详细的操作。
GNU 官方的一个工具，最大的优点是成熟、可靠。
但源代码比较难读懂。GNU 的东西，封装性、技巧性比较强。
2.3 使用例程
1. 下载源代码
2. 解压
3. ./configure
4. make
5. make install
6. cflow tes.c
main() :
printf()
do_something_firstly() : malloc()
free()
do_something_finally() : printf()
7. 输出结果
2.4 核心代码抽取
通过此工具的源代码，可以获取匹配函数定义语句的功能，函数调用关系的功能，从来实现fan-in ，fan-out 度量。
3 C and C++ Code Counter
3.1 工具简介
3.2 工具优缺点总结
功能强大，基本能够进行所有的静态度量。支持c 语言。 缺点：源代码比较复杂，研读需要时间。
并不支持函数的扇入扇出。
4.3 实例
1. 实例代码：
#include
/*test example*/
int f1()
{
int a=1,b=2;
if (a==1)
a=4;
else
{
if (b==2)
{
a=4;
}
}
return 1;
}
int f2()
{
return 1;
}
int f3()
{
f1();
f2();
return 1;
}
main()
{
int a=10;
f1();
f2();
f3();
}
2. 安装cccc
官方网站下载安装文件
3. 执行度量
4. 查看结果
F3调用了f1,f2，但度量结果，并没有反应出来。
4.4 分析
扇出扇出的分析：
Fan-In, Fan-Out (FI,FIc,FIv,FO,FOc,FOv)
Traditionally, use relationships between modules were identified by counting function invocations or access to module data in procedural code. CCCC identifies relationships only through
structures apparent in the definitions of the interfaces of C++ classes or Java classes or interfaces. The specific relationships which can be detected are inheritance of a supplier class by a client, containment of an instance of a supplier class in a client, and the
existence of member functions of the client class which accept or return an instance of the supplier.
While these relationships may seem unrelated to the
invocation and module data counts, they are likely to show
a strong corelation because of the fact that in an object
oriented environment, it is likely (but not inevitable) that
the low-level use relationships of invocation and direct
access to data structures require an object of the class of
the supplier module to be available. This availability can
be through instantiation of an instance of the supplier class
within procedural code, but will often be due to the existence
of one of the higher level relationships described above.
The counts of Fan-In and Fan-Out are regarded as a measure
of the structural quality of a program, with high values of
either (and particularly high values of both within the same
module) indicating increased risk of changes required in one
module requiring changes across other modules. CCCC chooses
to define the relationship counts in such a way that each
supplier or client module is counted only once, however many
separate ways the relationship is detected. CCCC applies
filtering to the relationships identified to distinguish
between different kinds of uses which may carry with them
different levels of structural risk. There are two filters:
visibility and concreteness.
The visibility filter removes from consideration
relationships which are known to be only accessible from the
private interface of a module. Relationships which are
defined in the visible part of the interface can be exploited
by clients of the current module, thus forcing those clients
also to be clients of the current module's supplier. Visible
relationships also increase the range of operations
available on an object, thus increasing the cognitive
complexity of the interface from the point of view of a
programmer required to use a module.
The concreteness filter removes from consideration
relationships which do not create a dependency of the
implementation of the client module on the implementation of
the supplier class. Dependency-creating relationships
increase risk because they may not be cyclical, and thus
inhibit the creation of other relationships. They also
inhibit the ability of modules to be built separately,
requiring recompilation of the client module when the
supplier changes. The test for this filter in C++ is whether
a forward declaration of the supplier class is adequate to
allow the client module definition to be compiled:
containment and parameter passing where the client module is
modified by a referential operator are allowed in this case,
containment or passing by value or inheritance are all
dependency-creating. In Java, relationships except
inheritance are treated as non-dependency creating.
通过上述cccc 的原文，可以得知，cccc 中的扇入扇出是关于类之间的。 4 结论
计算java 语言的圈复杂度工具有很多，例如Analysis(eclipse的一个插件) 。
计算扇入扇出的主要技术点：
1．确定函数定义部分
2．确定函数调用fanout
3．确定被调次数fanin
可以通过cFlow 和Cccc 的源代码，尽量抽取出来。 CherryPick , Lachesis