Article Preview
Top1. Introduction
Java language is considered as one of the languages that has various advantages, these advantages include s its simplicity, safety, strength, impact, high level object-oriented ability, and many other advantages (Arnold, Gosling, Holmes & Holmes, 2000). Complexity can here be defined as, the relationship between the internal parts of the program and how these parts can be interacted with each other, some of these parts will be connected to other parts of the program to make the program more complex and difficult to be analyzed or maintained. However, if these parts are less cohesive then the program will be less complex, in this case, the analysis would be easier to be analyzed and maintained (Sanchez & Lucas, 2002). The benefits of complexity measurement can be summarized as follows:
- 1.
Complexity analysis of code can even be estimated from a design (whenever the design is easy and simple then the code will be less complex, in contrast, if the design is more complex and unclear, then the program will be more complex).
- 2.
The ability to distinguish between the simple and more complex program (allow the programmers to write a program in a way that has the following features: high quality, easy to understand, has few mistakes, easy to use and re-use, easy to maintain, easy to test, saves time and lower cost).
- 3.
Good Complexity Measure provides continuous feedback (allowing us to follow the program continuously and to avoid most of the expected mistakes or problems).
The main reason for analyzing the complexity of the code is to measure the complexity ratio of the code, it is possible that can be helpful for reducing the complexity, for this reason the following case should be discussed: 1) A simple module without much risk, 2) A more complex module with moderate risk, 3) A complex module of high risk, and 4) An un-testable program of very high risk. Table (1) shows the difference between good complexity and bad complexity.
Table 1. Level of complexity by McCabe measure
| Complexity | Risk Evaluation |
| 1-10 | A simple module without much risk |
| 11-20 | A more complex module with moderate risk |
| 21-50 | A complex module of high risk |
| 51 or more | An untestable program of very high risk |
Categorizing any source code complexity into good or bad will be helpful for code maintenance and evolution. Typically, the source code with good complexity is more maintainable, testable, understandable, and have less errors. On the other hand, any source code with bad complexity will be complex to be maintained, tested, understood by developers, and it will have a lot of errors.
Shrivastava (2008) presented a measurement to provide a single ordinal number to be used to compare the program’s complexity with other programs. This measurement used McCabe Complexity measures to analyze the system and find the complexity of the program, as follows:
CC=E – N+ PWhereCC = Cyclomatic ComplexityE = Number of edges of the graphN = Number of nodes of the graph