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）扇出

      扇出表示一個子產品調用多個子產品。