Modern software systems are increasingly integrated into vital society areas, from managing critical infrastructure to piloting vehicles. That is why one of the most important priorities is the reduction of possible software defects. The speed of development of social processes and technologies determines the need for adaptation, which in turn requires software adjustments. Analysis of various definitions and aspects of maintainability, as well as established models and approaches to measuring object-oriented software, remains a relevant issue. This analysis makes it possible to determine the possibilities of improving the efficiency of the assessment by methods of statistical analysis. Predictive assumptions about object development include maintainability of object-oriented software. At the same time, the method of modifying Delta Maintainability Model (DMM) by expanding the measurable properties of the source code is used. It is important to demonstrate the stability and effectiveness of object-oriented software change measurement by conducting comparative analysis for source code changes, which makes it possible to measure maintainability in processes with continuous delivery and uninterrupted integration methodological approaches. At the same time, the interpretation of the assessment results makes it possible to establish a causal relationship and eliminate shortcomings.
Research by C. Jones shows a steady
increase in the involvement of engineers in
software support jobs, from 9.09% percent in
1950 to 72.73% in 2000 and a projected
involvement rate of 77.27% in 2025 [
Most of the research is based on the
importance of software maintainability,
emphasizing the relationship with adaptability,
and reducing the number of defects [
Scientific studies devoted to software
quality problems include publications of
authors: C. Jones [
Improving the quality and maintainability of object-oriented software by reducing the number of defects is important for any development.
Software quality models define maintainability as one of the main attributes. Most of the methods of measuring maintainability, consider not only maintainability itself, but are also part of quality models. Maintainability is a complex concept that has been repeatedly examined by studies offering different formulations and measurement approaches. However, most of the studied approaches, to some extents, have the following aspects: Ambiguity of terminology and definitions of quality criteria. Abstractness, absence of definitions of formulations and methods of measurement. Complexity or impossibility of interpretation. Conducting a causal analysis of measurement results.
McCall’s model [
It is offered to measure the properties by ranking from 1 (goal not achieved) to 10 (excellent implementation), without indicating specific metrics or methods of measurement. An example of the Fig. 1 according to the model, maintainability is determined by the levels of the hierarchy.
Quality Model for Object-oriented Design
(QMOOD), offered by Bansia and Davis in
2002 [
The connections between design properties
and quality attributes [
Design Size in Classes (DSC) is the number of all classes provided by the program design.
Number of Hierarchies (NOH) is the amount of class hierarchies of the program.
Average Number of Attributes (ANA) is the average of the number of classes inherited by a class and is calculated by counting the number of classes along all inheritance paths from the root class(es) to all classes of the inheritance structure.
Data Access Metric (DAM) is a value between 0 and 1 and is the ratio of the number of private (protected) attributes of a class to the total number of attributes defined by the class.
Direct Class Coupling (DCC) is the number of classes on which the class depends directly, either by defining an attribute or passing message (parameters) in methods.
Class Association Method (CAM) is a value
in the range from 0 to 1, and is a calculation of
the interdependence of class methods based on
the list of method parameters [
Measure of Aggregation (MOA) this metric measures the degree of part-to-whole connection implemented by attributes. The value is the sum of the number of declared data whose types are user-defined classes.
Measure of Functional Abstraction (MFA) ranges from 0 to 1 and is the ratio of the number of methods inherited by a class to the total number of methods accessed from other methods of the class.
Number of Polymorphic Methods (NOP) is the sum of the number of methods that can exhibit polymorphic behavior.
Class Interface Size (CIS) is a quantitative measure of the count of public methods of a class.
Number of Methods (NOM) is a quantifier of the count of all methods defined by a class.
The quality model ISO/IEC 25010:2016
“Systems and software engineering” defines the
Security Quality Requirements Engineering
(SQuaRE). System and software quality models
[
The standard also introduced changes to the maintainability structure. New sub-characteristics have been introduced: “modularity” and “reusability.” The subcharacteristics “variability” and “stability” were replaced by the new characteristic “modification.” The standard provides the following definitions of maintainability: Maintainability is defined as the degree of effectiveness and efficiency in which a product or system can be modified by designated service personnel. At the same time, maintainability can be construed as the inherent ability of a product or system to facilitate maintenance work or as quality during use; Modularity is the degree to which a system or computer program is composed of discrete components such that a change in one component has minimal impact on other components. Reusability is the degree to which an asset can be used in more than one system or in the construction of other assets. Analysability is defined as the degree of effectiveness and efficiency in which it is possible to assess the effect on the product or system of the intended change in one or more parts, or to diagnose non-completion, the causes of failures, or to identify the parts to be modified. Modification is the degree of effectiveness and efficiency in which a product or system can be modified without introducing defects or degrading the existing quality of the product. Modification is a combination of variability and stability. Testability is the degree of effectiveness and efficiency to which test criteria can be established for a system, product, or component, and tests must be performed to determine whether those criteria have been met.
The model is independent of the
programming language and software
architecture, has indicators that are easy to
understand and explain, and is based on defined
relationships of system-level quality
characteristics defined by the ISO 9126-1
standard [
The simple symbolic scale ++ / + / o / – / – – is used to rank the results of evaluating a particular property of the code.
The size of the program is one of the simple and direct indicators of maintainability, because the larger the size, the more effort is required for cognitive perception, making changes, testing.
The indicator is set for each language
separately on the basis of research [
For the purposes of the model under consideration, the size of the program is determined by the person-years required to create the program (Table 2).
Thus, a software product requiring 160 person-years is considered too large, and for systems implemented in Java is equal to 1.3 million lines of code or 2.6 for the COBOL language.
The complexity per unit of the program is a property of the source code and is defined as the degree of internal complexity of the units of the source code that it consists of (Table 3).
With further aggregation of complexity per program unit to determine the ratio of lines of code of each risk level as a percentage. That is, if the program consists of 20,000 lines of code, and at the same time the sum of the lines of code of the program units with a high risk of complexity is 1,000 lines of code, the aggregate value for the high risk category will be 5% (Table 4).
of lines of code (LOC), %
++ + o – ––
Thus, for example, if the rank of the program is defined as “+”, the amount of lines of code with high risk does not exceed 5%, with high risk 15% and 50% of lines of code are within the limits of moderate risk.
Duplication (or cloning of code) reduces the cognitive perception of the program, the possibility of making changes, and unmotivatedly increases the size of the program. And it is defined as the repetition of a block of code for more than 6 lines, while spaces at the beginning of the lines are not taken into account to determine the repetition (Table 5).
The size of the program unit is an important indicator, because large-sized program units require more costs to support, also, this indicator additionally indirectly displays the possible complexity. The indicator is defined as the number of lines of code (LOC) followed by size categorization and ranking similar to the definition of complexity per program unit.
Module testing is calculated as a relative indicator of program coverage by program unit tests. This practice is not static analysis and refers to dynamic code analysis.
The calculation of the overall assessment of the system is carried out by the average weighting of the indicators of each property of the source code.
For example: program size is rated as small “++”, with very high complexity per program unit “––”, high duplication and program unit size “–”, and moderate testing. Accordingly, the analyzability of such software as well as the stability are average, while variability and testability are low, which is averaged by a low “–” maintainability assessment. However, these results are more effective in determination of causal relationship. Thus, in order to increase maintainability, it is necessary to carry out refactoring aimed at program units of very high complexity with the aim of reducing it, and reducing the size of the program units, as well as removing duplications.
The Maintainability Model (SIG-MM) does not have certain disadvantages, but it is based on the measurement of the entire source code of the software product, which causes the weak representativeness of the measurement results with minor changes in the source code.
An example of this is entry #402331 in the
bug registration system of the Mozilla Rhino
software product [
There is a Delta Maintainability Model
(DMM), which does not contain the above
shortcomings, but does not take into account
the specifics of the object-oriented
programming paradigm. It is intended to
compare and analyze partial changes to the
source code, not the program as a whole. The
model integrates with version control systems,
allowing integration with DevOps tools for use
in analyzing ongoing source code assessments.
Risk ranking is based on the threshold values of
the Maintainability Model (SIG-MM) [
This article proposes a modification of the
delta Maintainability Model (DMM) by
expanding the measurable properties of the
source code, determining their relationship with
the sub-characteristics of maintainability
defined by ISO/IEC 25010:2016, and
determining measurement methods and
threshold values [
Further the basic model is denoted by DMM, the resulting indicator is DMMS. References to the proposed model are denoted as DMM+, the indicator, respectively, DMMS+
The calculation takes place taking into
account the order established for the Delta
Maintainability Model (DMM) [
RC = {low, high};
CP = {class Connectivity, class Difficulty, method Difficulty, the Number of methods, method Size, the Number of parameters, Dublication, module Dependency}.
Philo, Tarsio G.S., and M. Bigonya [
The practical validation of the proposed model was carried out by analyzing software products with open source code, implemented using an object-oriented programming paradigm, a development process using version control systems and a significant number of participants in the development process and a long history of code changes.
Because the analysis of the source code of software products requires the study of the abstract syntax tree (AST), therefore, in order to simplify the implementation of the application intended for analysis, all software products are selected with the requirement of implementing the object-oriented part with a common programming language.
For the comparative analysis, six software products of different functional purposes, with open source code, with the implementation of the object-oriented part in the Python programming language, were chosen.
The scope of analysis covers only changes in files (modules) that contain instructions in the Python programming language and have the extension “*.py”, while changes to files with instructions for unit testing are not taken into account.
In order to carry out research and measurements, a program was implemented with command line interface support and simultaneous measurement of DMM and DMM+ model indicators.
According to the results of the analysis, a
significant indicator of the Pearson correlation
coefficient ranging from 0.77 to 0.86
demonstrates a strong positive correlation
between DMMS and DMMS+ values. Thus,
DMMS+ metrics along with DMMS reflect the
relationship to source code changes that affect
maintainability. Values of DMMS indicators
and validation were confirmed [
Correlation of DMMS and DMMS+ indicators according to the analysis of 1000 changes made in the repository: 1. Tensorflow r = 0.86. 2. Sentry r = 0.8. 3. Django r = 0.82. 4. Odoo r = 0.84. 5. Saleor r = 0.77. 6. Zulip r = 0.77.
Despite the positive correlation, the indicators show fluctuation according to the indicator of the absolute average difference. It is important to show the changes in the indicator of the absolute average difference between the indicators of DMMS and DMMS+ based on the results of the analysis of 1000 changes made to each of the repositories (Fig. 3).
Summarizing the above considerations, it should be noted that in this work, the analysis of existing models and measurement metrics of object-oriented software was carried out, their advantages and disadvantages were determined.
A modified delta model of object-oriented software maintainability, by expanding the measurable properties of the source code, determining their relationship with the maintainability sub-characteristics defined by ISO/IEC 25010:2016. Measurement methods and threshold values are defined. Practical validation of the offered model was carried out by analyzing open source software products implemented using an object-oriented programming paradigm, a development process using version control systems and a significant number of participants in the development process and a long history of code changes.
The stability and effectiveness of measuring changes in object-oriented software has been demonstrated by means of a comparative analysis of changes made to the source code, which makes it possible to measure compliance in processes with methodological approaches of continuous delivery and uninterrupted integration. At the same time, the interpretation of the evaluation results makes it possible to establish a causal relationship and eliminate shortcomings.