tushartushar / designitejava Goto Github PK

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

Detection:
if (type.getNC() >= dto.WID_HIE_Threshold)

(getNC() gives number of children for a type)

Thresholds
WID_HIE_Threshold = 10;

This smell arises when an abstraction is left unused (either not directly used or not reachable).

Detection
if Fan-in of a type is zero and there is no superclass => detect the smell
if the type has any superclass and both the superclass as well as the type itself is not used (Fan-in=0), then we detect this smell.

If a statement is larger (in terms of no of characters whitespaces included) than a threshold, we detect this smell.

Threshold = 120 characters

This smell arises when a supertype in a hierarchy depends on any of its subtypes.

Detection
If a type accesses any of the sub-types then detects this smell.

This smell arises when a subtype inherits both directly as well as indirectly from a supertype leading to unnecessary inheritance paths in the hierarchy.

Detection:
a_list = Get the list of all direct parents of a type T.
b_list =Get the list of all the ancestors of all the parents of type T.
if a_list and b_list have anything in common, we detect this smell.

• Are we actually using 'ThresholdsParser'? I only see it is being used from tests!
• Also, we need to change the location of the threshold.txt and make sure that it is present in the target folder.
• Another thing is that if we don't find the file, we need to return the standard thresholds (and not throw an exception)

Implementation smells
Long Method - Done
Complex Method - Done
Long Parameter List - Done
Long Identifier - Done
Long Statement - Done
Complex Conditional - Done
Virtual Method Call from Constructor - Done
Empty Catch Block - Done
Magic Number - Done
Duplicate Code
Missing Default - Done

Design smells
Unnecessary Abstraction - Done
Imperative Abstraction - Done
Multifaceted Abstraction - Done
Unutilized Abstraction - Done
Duplicate Abstraction

Deficient Encapsulation - Done
Unexploited Encapsulation - Done

Broken Modularization - Done
Insufficient Modularization - Done
Hub-like Modularization - Done
Cyclically-dependent Modularization - Done

Wide Hierarchy - Done
Deep Hierarchy - Done
Multipath Hierarchy - Done
Cyclic Hierarchy - Done
Rebellious Hierarchy - Done
Unfactored Hierarchy
Missing Hierarchy - Done
Broken Hierarchy - Done

Architecture smells
Cyclic Dependency
Unstable Dependency
Ambiguous Interface
God Component
Feature Concentration
Scattered Functionality
Dense Structure

During some stress testing I noticed that the application fails to resolve the types of Generics. Specifically., it crashes when the .getPackage().getName() in the following line:

If a conditional statement has sub-expressions separated by logical operators, we detect this smell.

Threshold= 3 sub-expressions

If a method has parameters more than a threshold, we detect this smell.

Threshold = 5

If LOC of a method is more than a threshold, we detect this smell.

Threshold = 100 LOC

Export all the detected smells in csv format. The following fields are required:

Design smell | PackageName | TypeName | FilePath | Cause

For the time being, we may leave Cause.

If Cyclomatic Complexity of a method is more than a threshold, we detect this smell.

Threshold = 8

This smell arises when an abstraction has dependencies (both incoming and outgoing) with a large number of other abstractions.

Detection
if Fan-out of type >= threshold1 and Fan-in of the type >= threshold2
then detect the smell

Threshold
threshold1 = 20
threshold2= 20

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.

Detection:

• list1 = get all the types checked in a method (using instanceof).
• list2 = get a list of types from list1 which are not belonging to an inheritance hierarchy
• if list2.count > 2, we detect this smell.

If a method is a constructor and it calls atleast one virtual method, we detect this smell.

When we spot a number (except 0 and 1) in a statement, we detect this smell.

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.

Detection
Get all types that are being checked in a method. Find the number of checked types that belong to the same inheritance hierarchy. If the number is greater than a threshold (2), we detect this smell.

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.

Detection
If method count in a type = 0 and
(field count + property count) >= threshold
then we detect this smell.

Threshold
threshold = 5

Implement a source meta model and placeholder classes (such as Project, Package,...)

When a switch statement doesn't have a default case we detect this smell.

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.

Detection:
Form 1 - Large public (bloated) interface
if (getPublicMethods(type).Count >= dto.INS_MOD_Threshold)

form 2 - large number of methods
if (type.getMethodList().Count >= dto.INS_MOD_Threshold2)

form 3 - high complexity
if (type.getWMC() >= dto.INS_MOD_Threshold3)

Default values of thresholds:
INS_MOD_Threshold = 20;
INS_MOD_Threshold2 = 30;
INS_MOD_Threshold3 = 100;

I use a dto (data class) object to store all the currently used thresholds. These thresholds can be customizable by the user; hence, a user can view and change thresholds in a config file.

This smell arises when an abstraction has more than one responsibility assigned to it.

Detection
if LCOM of a type >= threshold1 &&
no of fields in the type >= threshold2 &&
no of methods in the type >= threshold3
then detect the smell

Thresholds
threshold1 = 0.80
threshold2 = 7
threshold3 = 7

The current implementation stops the smell identification after identifying the 1st smell in a method.

For some reason it cannot resolve class hierarchy properly.

This smell arises when two or more abstractions depend on each other directly or indirectly (creating a tight coupling between the abstractions).

Detection
Prepare a dependency graph of types from Fan-in/Fan-out information. use this dependency graph to detect cycles.

This smell arises when a subtype rejects the methods provided by its supertype(s).

Detection:
For a class, check all the methods. If

1. a method is overridden, and
2. either the method is empty, or has only one statement which is a throw statement (throw exception),
   we detect this smell.

If a catch block is empty (without any statement), we detect this smell.

This smell arises when a supertype and its subtype conceptually do not share an “IS-A” relationship resulting in broken substitutability.

Detection
we do not detect this smell if

1. the type has no super classes,
2. the type is an interface, or
3. there are no public methods in the supertype.

For a type, check all its methods. If atleast one of its methods is overridden or "leniently" overridden, we do not detect this smell.
A method is leniently overridden when the method name matches with any of the methods in the super classes.

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

Detection
If a type has at least one public field or global field (declared as public static), we detect this smell.

If an identifier (local variable, parameter name, or even a field) length is greater than a threshold we detect this smell.

Threshold = 30 characters

This smell arises when an operation is turned into a class.

Detection
if no of public methods in a type = 1 &
LOC >= threshold1
then detect the smell

Threshold
threshold1 = 100

Eventually, there will be many options to set apart from specifying input and output paths. So, it is better to have a configuration file to specify all inputs for the application.

This smell arises when an inheritance hierarchy is “excessively” deep.

Detection
if (type.getDIT() >= dto.DEE_HIE_Threshold)

getDIT() returns the depth of inheritance tree for the type.

Threshold
DEE_HIE_Threshold = 6;

Start with these metrics one at a time:

1. NOF (Number Of Fields) - Class
2. NOM (Number Of Methods) - Class
3. NOPF (Number of Public Fields) - Class
4. NOPM (Number of Public Methods) - Class
5. LOC (Lines of Code) - Class
6. LOC (Lines Of Code) - Method
7. PC (Parameter Count) - Method
8. LCOM (Lack of Cohesion of Methods) - Class
9. CC (Cyclomatic Complexity) - Method
10. WMC (Weighted Methods per Class) - Class
11. NC (Number of Children (sub-classes)) - Class
12. DIT (Depth of Inheritance Tree) - Class
13. FANIN (Fan-in) - Class
14. FANOUT (Fan-out) - Class

Parameter tests in SM_ParameterTest.java failing. I added a method to select an appropriate method from a list of methods. That makes one test passing. However, other tests are failing. The reason is that typeinfo of the selected parameters are never get initialized (leading to NullPointerException).

Set up unit tests mechanism

I run the tests and all four tests in "DesigniteTests.metrics.MethodMetricsTest" are failing. When I looked into these tests, I observed that dir.mkdir() is failing on my machine (Mac). It could be due to relative path we are passing.

This smell occurs when an abstraction that is actually not needed (and thus could have been avoided) gets introduced in a software design.

Detection:
if no of methods in a type = 0 &
no of fields and properties <= threshold1
then identify the smells

Threshold
threshold1 = 5

Resolve binding for custom types not resolving on all the machines. It is machine specific, so probably it is related with some machine specific setting/configuration.
It is working on Theodoris's machine (Linux) but not on my machine (Mac). I checked it using the jar generated on Theodoris's machine but no luck.