Table of contents

At first, it is necessary to get the analysis result file of Aries.

You will find the label named "get refactoring-oriented code clone" in the below screen. Push its next button.

Then, the following screen appears. If you have a list file which includes target files, push "Load List" button. If you don't, push "Select File or Directory" button to specify target files. The following dialog box appears after pushing those buttons. You need to select file or directory using this dialog box to specify target files.

If target files are listed in Aries like a following screen, push next button.

Here, you set several options of analysis.

Following options are available.

Minimum Clone Length

This is the minimum length of code clones which Aries detects.(mandatory)

Memory Resource Limit

This is maximum memory size that java MV uses.(mandatory)

Analysis Result File...

This is the file path which Aries writes analysis result to.(mandatory)

parameterize variable names

This specifies whether or not Aries parameterizes field names in detecting code clones.

parameterize method names

This specifies whether or not Aries parameterizes method names in detecting code clones.

parameterize type keywords

This specifies whether or not Aries parameterizes type keywords in detecting code clones.

parameterize literals

This specifies whether or not Aries parameterizes literals in detecting code clones.

parameterize package name

This specifies whether or not Aries parameterizes package names in detecting code clones.

parameterize the other names

This specifies other names defined by users(programmers).

CCFinder Other Options

This is other options of CCFinder.(optonal)

Aries Other Options

This is other options of Aries.(optional)

After setting options, push "Run Aries Analysis" button. Then, after outputing log of detection, "Successfully Finished" dialog box appears. Using this process, you can get the analysis result file of Aries. In next phase, you analysis detected clone sets using Aries GUI. Push "OK" button of "Successfully Finished" dialog box, and return the initial screen.

Memory Resource Limit

This is the maximum memory size that Java VM uses(mandatory)

Analysis Result File...

This is the file path which Aries write analysis result to(mandatory)

Other Options

This is others options field of Aries(optional)

Declaration

Class declaration, Interface declaration.

Method

Method body, Constructor, Static initializer.

Statement

Do statement, For statement, If statement, Switch statement, Synchronized statement, Try statement, While statement

POP(S)(Declaration, Method, Statement)

POP(S) means the number of code fragments which are included in the clone set S.

LEN(S)(Declaration, Method, Statement)

LEN(S) means the average of token number that the clone set S includes.

DFL(S)(Declaration, Method, Statement)

DFL(S) indicates how many tokens would be removed from source codes if all code fragments in the clone set S are merged.

NRV(S)(Declaration, Method, Statement)

NRV(S) means the average number of externally defined variables referred in the fragments of the clone set S.

NSV(S)(Declaration, Method, Statement)

NSV(S) means the average number of externally defined variables assigned to in the fragments of the clone set S.

DCH(S)(Declaration, Method, Statement)

DCH(S) means the position and distance between each fragment of the clone set S. The more spread clone set S are, the bigger values DCH(S) becomes.

DOC(S)(Declaration, Method, Statement)

DOC(S) means how fragments included in the clone set S are distributed in classes. If all fragments are in a same class, the value of DOC(S) becomes 0. In other case, if each fragment is in different classes, the value of DOC(S) becomes 1.

KMC(S)(Method, Statement)

KMC(S) means the coupling between methods. Here, the value of coupling of methods is calculated based on the proposal of [1]. the coupling is calcaulated by the following three factors.

• The parameters of invoking method
• The return value from invoked method
• The shared variables between methods

RFC(S)(Class)

RFC(S) means the average of the value of all RFC(C)s, where C is the class included in the clone set S. If you are not familier with RFC(C), please read here.

TCC(S)(Class)

RFC(S) means the average of the value of all TCC(C)s, where C is the class included in the clone set S. If you are not familier with TCC(C), please read here.

LCOM(S)(Class)

LCOM(S) means the average of the value of all LCOM(C)s, where C is the class included in the clone set S. If you are not familier with LCOM(C), please read here.

WMC(S)(Class)

WMC(S) means the average of the value of all WMC(C)s, where C is the class included in the clone set S. If you are not familier with WMC(C), please read here.

SMT(S)(Method)

SMT(S) means how the types of arguments and return value fit in. If the type is primitive, identical types means fitting in. If the type is class, classes inheriting a same class means fitting in. For example, there are two cloned methods that have two arguments. In this case, SMT(S) checks two arguments and a return type. If all there types fit in, the value of SMT(S) is 1. If two types fit in, the value is 0.67. If only one type fits in, the value is 0.33. If no type fits in, the value is 0.

CYC(S)(Statement)

CYC(S) is the cyclomatic number proposed by Maccabe[2].

variable "this"

This determines whether or not NRV(S) and NSV(S) count variable "this".

variable "super"

This determines whether or not NRV(S) and NSV(S) count variable "super".

local variables

This determines whether or not NRV(S) and NSV(S) count local variables.

this class fields

This determines whether or not NRV(S) and NSV(S) count variable this class's fields.

super class fields

This determines whether or not NRV(S) and NSV(S) count super class's fields.

interface fields

This determines whether or not NRV(S) and NSV(S) count interface's fields.

outer variables

This determines whether or not NRV(S) and NSV(S) count variables defined in outer class.

• Extract Class
• Extract Method
• Extract Super Class
• Move Method
• Parameterize Method
• Pull Up Constructor Body
• Pull Up Method
• Form Template Method

Name

This is the name of the variable.

Type

This is the type of the variable

Declared Location

This represents the kind of the variable(this, super, local, this, this_class_field, super_class_field, interface_field, outer)

Referred

This is the number of reference.

Assigned

This is the number of assignment.

NOC(C)(Number Of Clones)

NOC(C) means the number of code clones included in the class C.

ROC(C)(Ratio Of Clones)

ROC(C) means how much the tokens of the class C are cloned.
ROC(C) = (the number of cloned tokens) / (the number of all tokens) * 100.

NOM(C)(Number Of Methods)

NOM(C) means the number of methods defined in the class C. This metric doesn't count override methods.

NOA(C)(Number of Atrributes)

NOA(C) means the number of attributes defined in the class C. This metric doesn't count attributes inherited from super classes.

RFC(C)(Response For a Class)[3]

RFC(C) means the sum of the number of methods defined in the class C and the number of methods called in the class C. The bigger this metric is, the more complex the class C is.

TCC(C)(Tight Class Cohesion)[4]

TCC(C) means the cohesion of the class C.
TCC(C) = (the number of method pairs sharing some fields in the class C) / (the number of method pairs defined in the class C).
The smaller this metric is, the less cohesive the class C is.

LCOM(C)(Lack of Cohesion Of Method)[5]

LCOM(C) means the lack of cohesion between method in the class C. The bigger this metric is, the less cohesive the class C is.(the maximum value is 2)． The definition is followings.

Here, "a" is the number of attributes defined in the class C,
"m" is the number of methods defined in the class C,
"A_j" is the j-th field,
"μ(A_j)" is the number of method using "A_j".

WMC(Weighted Methods per Class)

WMC(C) means the complexity of the class C. The value of WMC(S) is the sum of the cyclomatic number of all methods defined in class C. The cyclomatic number is proposed in [2]

1. Y. Kataoka, T. Imai, H. Andou, T. Fukaya, "A Quantitative Evaluation of Maintainability Enhancement by Refactoring". Proceedings of the International Conference of Software Maintenance 2002 pp.576-585.
   
2. McCabe, "Complexity Measure", IEEE Transacions on Software Engineering, Volume 2, No 4, pp 308-320, December 1976.
3. S.R. Chidamber and C.F. Kemerer, "A Metrics Suite for Object Oriented Design", IEEE Transactions on Software Engineering, Vol.20, No.6, pp.476-493, 1994
4. J.M. Bieman and B.K. Kang, "Cohesion and reuse in an object-oriented system", Proceedings of the Symposium on Software Reusability (SSR’95), Seattle, WA, pp. 259-262, April 1995.
5. Henderson-Sellers, B., "Object-oriented metrics : measures of complexity", Prentice-Hall, pp.142-147, 1996.