Java代码度量分析工具：DesigniteJava简介

前言

在Java面向对象课程的学习过程中，我们需要使用度量工具来分析自己程序的代码结构。受OO课程组以及前辈们博客提醒，笔者找到了DesigniteJava这款软件，现对此软件进行简单的说明。

一、DesigniteJava的下载与使用

Designite是一款程序设计的质量评估工具。这款工具可以用于分析Java的代码，并且识别其中存在的质量问题。Designite会检测程序的架构(architecture)，设计(design)和代码异味(code smell)并且给出详细的度量分析(metrics analysis）。

Designite for Java：http://www.designite-tools.com/DesigniteJava/

最近刚和IDEA互动：https://plugins.jetbrains.com/plugin/13380-designitejava/versions

进入官网Designite for Java，下载会得到一个jar包，默认名为DesigniteJava.jar。将其放在方便使用的位置，打开命令行窗口，输入以下代码即可运行：

java -jar DesigniteJava.jar -i <源码路径> -o <分析数据输出路径>

输出之后，会得到以下文件。

二、度量指标介绍

以下截取自这里

许多翻译十分抽象，笔者没有找到好的解释，欢迎作注。

• Detects 20 design smells 能检测20种设计异味命令抽象

  • Duplicate Abstraction:

    重复抽象，This smell arises when two or more abstractions have identical names or identical implementation or both.

  • Feature Envy:

    This smell occurs when a method seems more interested in an abstraction other than the one it actually is in.

  • Imperative Abstraction

    命令抽象，This smell arises when an operation is turned into a class.

  • Multifaceted Abstraction

    多方面抽象，This smell arises when an abstraction has more than one responsibility assigned to it.

  • Unnecessary Abstraction

    不必要的抽象，This smell occurs when an abstraction that is actually not needed (and thus could have been avoided) gets introduced in a software design.

  • Unutilized Abstraction

    未使用的抽象，This smell arises when an abstraction is left unused (either not directly used or not reachable).

  • Deficient Encapsulation

    封装不足，This smell occurs when the declared accessibility of one or more members of an abstraction is more permissive than actually required.

  • Unexploited Encapsulation

    未开发封装，This smell arises when client code uses explicit type checks (using chained if-else or switch statements that check for the type of the object) instead of exploiting the variation in types already encapsulated within a hierarchy.

  • Broken Modularization

    模块化中断，This smell arises when data and/or methods that ideally should have been localized into a single abstraction are separated and spread across multiple abstractions.

  • Cyclic-Dependent Modularization

    循环相关模块化， This smell arises when two or more abstractions depend on each other directly or indirectly (creating a tight coupling between the abstractions).

  • Insufficient Modularization

    模块化不足 ，This smell arises when an abstraction exists that has not been completely decomposed, and a further decomposition could reduce its size, implementation complexity, or both.

  • Hub-like Modularization

    轮毂式模块化，This smell arises when an abstraction has dependencies (both incoming and outgoing) with a large number of other abstractions.

  • Broken Hierarchy

    断裂的层次结构，This smell arises when a supertype and its subtype conceptually do not share an “IS-A” relationship resulting in broken substitutability.

  • Cyclic Hierarchy

    循环层次结构，This smell arises when a supertype in a hierarchy depends on any of its subtypes.

  • Deep Hierarchy

    层次过深，This smell arises when an inheritance hierarchy is “excessively” deep.

  • Missing Hierarchy

    缺少层次结构，This smell arises when a code segment uses conditional logic (typically in conjunction with “tagged types”) to explicitly manage variation in behavior where a hierarchy could have been created and used to encapsulate those variations.

  • Multipath Hierarchy

    多路径层次结构，This smell arises when a subtype inherits both directly as well as indirectly from a supertype leading to unnecessary inheritance paths in the hierarchy.

  • Rebellious Hierarchy

    叛逆性层次结构，This smell arises when a subtype rejects the methods provided by its supertype(s).

  • Wide Hierarchy

    层次过宽，This smell arises when an inheritance hierarchy is “too” wide indicating that intermediate types may be missing.

  • Unfactored Hierarchy:

    This smell arises when there is unnecessary duplication among types in a hierarchy.

• Detects 10 implementation smells 检测10种实现异味

  • Abstract Function Call From Constructor

    构造函数调用抽象函数

  • Complex Conditional

    复杂条件

  • Complex Method

    复杂的方法

  • Empty catch clause

    空catch子句

  • Long Identifier

    长标识符

  • Long Method

    长方法

  • Long Parameter List

    长参数列表

  • Long Statement

    长语句

  • Magic Number

    魔法数字，在编程领域指的是莫名其妙出现的数字。数字的意义必须通过详细阅读才能推断出来。

    一般魔法数字都是需要使用枚举变量来替换的。

  • Missing default

    缺少默认值

• Computes following object-oriented metrics 能计算以下面向对象的度量

  • LOC (Lines Of Code - at method and class granularity)

    代码行数

  • CC (Cyclomatic Complexity - Method)

    圈复杂度，用于衡量一个模块判定结构的复杂程度，圈复杂度越大说明程序代码质量低，且难以测试和维护。

  • PC (Parameter Count - Method)

    方法中传入的参数个数。

  • NOF (Number of Fields - Class)

    类的字段个数。

  • NOPF (Number of Public Fields - Class)

    类的公共字段个数。

  • NOM (Number of Methods - Class)

    类的方法个数。

  • NOPM (Number of Public Methods - Class)

    类的公共方法个数。

  • WMC (Weighted Methods per Class - Class)

    类的加权方法个数。

  • NC (Number of Children - Class)

    类的子类个数。

  • DIT (Depth of Inheritance Tree - Class)

    类的继承树深度。

  • LCOM (Lack of Cohesion in Methods - Class)

    方法的内聚缺乏度。

  • FANIN (Fan-in - Class)

    类调用的上级模块的个数。

  • FANOUT (Fan-out - Class)

    类直接调用的下级模块的个数。

  稍微解释一下最后三个值：

  • 秉承着高内聚低耦合的思想，LCOM的值越小越好，FANIN和FANOUT与复用性和复杂度有关，视情况判断好坏

  • FANIN和FANOUT

    • （A）FANIN(扇入)

      扇入表示一个模块被多个模块调用。
      
      

    • （B）扇出

      扇出表示一个模块调用多个模块。