The quality of software design is largely affected by the relationship between system packages. The module is loosely coupled and the inside of the module maintains a high degree of consistency is one of the key to high quality design software. Therefore, one of the means of assessing the level of software design is to examine the relationship between its modules. An objective evaluation of the reusability and maintainability level of the system is an important part of the evaluation software structure. I am in this article, metrics can help you appruily assess your quality of your software design.
Although metrics can work back to our software design quality, you have to keep in mind that the metrics proposed in this article is not the only basis for software design. The high and low design quality score may not necessarily correspond to the high and low quality of real software, but it is less likely that the design level is high, but under our metrics, the scores are very low. We propose the purpose of software design quality metrics to help designers correctly assess their own design, more importantly, helping you detect whether the design level has achieved the expected goal.
Test stability
Stability refers to the difficulty of modifying a module in the software without affecting other modules. Let us see how dependence between the modules affect stability.
The more times a module reuses in software, then it is dependent on it. The stronger the input dependence of the module (more other modules depend on this module), the higher its stability score (ie, it is difficult to modify). In other words, the more other modules depend on this module, and the more difficult this module is modified without affecting other modules. The input dependence and output dependence of the module is an important aspect of evaluating the stability and instability of the module. The module has a strong output dependence, and the input is weak, and the stability is low (that is, it is easy to modify) because the change will not be expanded to many other aspects. On the other hand, the more the input amount of the module, the more difficult it is, the more stabilizes. Stability can be calculated by calculating the input amount and output.
The input coupling degree represents the number of other modules of this module, and the output coupling represents the number of other modules dependent on this module. The instability can be obtained by the ratio of the output coupling degree and the total coupling. The calculation formula is as follows: i = Ce / (CE CA)
I represents the instability CA of the module represents the input coupling of the module, that is, the input dependency CE represents the output coupling degree of this module, that is, the output dependence
If the value of i is close to zero, then the input dependence of the module is much greater than the output dependence, the more stable in the module. The more difficult the module is, the more difficult to modify it, because a change will derive a lot of new changes, and the wavefront is on other modules that depend on it. For I values close to one module, its output dependence is much greater than input dependence, and modules are unstable. Since there is not much module affected by this module, the unstable module is easy to modify. Seeing these, you may feel very confused, "I should make the stability of the module too good, or low?"
Some modules have input dependencies (referenced by other modules) due to a single module that makes up a software, and some modules are output dependent (reference other modules). We should not pursue complete stability or instability in the design module, but consider that a certain module needs stability or unstable and as far as possible. The module that enters a relatively strong module must have high resistance to extent. In object-oriented development methods, abstraction is improved by separating functions and functions. For Java, abstract classes and interfaces are obviously an abstract expression. Therefore, the more you need a stable module, the higher the abstraction level. Corresponding to this, the more unstable modules are more specific.
Measuring abstraction
You can measure the abstraction of the module by calculating the number of abstract classes (or interfaces) within the module. Abstract degree can be calculated using the following formula: a = NA / NC
A representing the abstraction of the module NA represents the number of abstract classes or interfaces in the module NC represents the number of specific classes in the module
Abstraction is equal to zero indicates that the module is a fully abstract module, and abstraction is equal to a representation it is a fully specific module.
Evaluation metrics
Compare abstract degree and stability, you can find some more interesting conclusions. A completely unstable abstract module is also completely abstract, and the input dependence is zero. Instead, completely stable, input-dependent modules means that it has more frequently used specific classes.
This is because abstraction is separated by transformation and implementation. The specific classes that change frequently use will derive a lot of new changes, which may affect the entire software. So, you should minimize the input dependence of the module in the specific class. In other words, it is necessary to ensure that abstraction and input dependence, specificity and output dependence.
Evaluation of effective aids for design quality
This assessment method can help you improve software strongness. Although a good metric method does not guarantee that high quality design will naturally be produced, it does help you strengthen your confidence. Under the right and flexible use, this method is to assess the valuable means of evaluating software design quality.
Author: BUILDER.COM
