The impact of usage of post object-oriented technologies on defect reduction in software maintenance

The article is dedicated to software quality improvement research within the maintenance phase based on post-object-oriented technologies. An important problem of the maintenance phase is surveyed, namely, the crosscutting functionality problem. Mechanisms of post-object-oriented technologies have been reviewed and basic tasks to be resolved have been formulated in order to reach the final goal of the research: defect reduction during the maintenance phase. The post object-oriented technologies utilization framework for software quality improvement based on a collection of 4 heuristic assumptions has been introduced. The conceptual scheme of the framework has been presented. An applied 2-steps procedure for defect reduction assessment based on quantitative crosscutting-functionality and defect metrics has been described. Twelve results of the experiments concerning calculation of the residual defect number have been presented and analyzed.

During the last two decades post object-oriented technologies (POOT) have emerged and been intensively designed. The most known fully-fledged POOT are: aspect-oriented software design (AOSD) [4], feature-oriented software design (FOSD) [5] and context-oriented software development (COSD) [6]. These POOTs use core principles of the object-oriented software design but additionally include a complementary feature-set to resolve the crosscutting functionality problem. On the other hand, utilization of any of mentioned POOT for LSS maintenance results in extra time and efforts interconnecting software development. Hence most of researchers accentuate the necessity to elaborate approaches for the complex estimation of POOT's effectiveness usage in real-life software projects, see e.g. in [7; 8; 9]. Besides, the issues of relationship between specific features of different POOTs and software design defects caused by CF [10] as well as development of such sophisticated solutions as software product lines with FOSD [11] and evaluation of software quality with usage of AOSD [12] are presented and discussed intensively nowadays. Nevertheless a lack of applied researches related to the impact of POOTs on software defects behavior with respect to the factor of crosscutting functionality has to be emphasized.
Taking into account the above-mentioned issues the research goal of this paper is to assess the impact of different POOTs on defect reduction in software maintenance and to provide some methodological recommendations for choosing an appropriate POOT in real-life projects. In order to reach this research goal the following tasks are to be resolved: -to analyse some critical CF-issues in maintenance of LSS by utilizing traditional OOPmethodology; -to give a short review of the knowledge-oriented approach to the estimation of POOTs effectiveness; -to define metrics to estimate a CF level and a method to calculate a number of software defects in LSS; -to propose the conceptual scheme of quality improvement of software maintenance using POOTs; -to check the proposed approach experimentally, to analyse the results obtained and to formulate some praxis-oriented recommendation for usage of POOTs in maintenance of different LSS. The possible solutions for these tasks are presented below in more details, as well as, the outlook of the next steps concerning this research.

A framework for usage of post object-oriented technologies to improve a software quality in software maintenance.
A lot of studies investigate complexity of the maintenance process of OOP-based legacy software systems [13; 14], especially a crosscutting functionality (CF) problem. The crosscutting problem is a functionality which can't be modularized at the source code level, although represents a particular businesses feature from the requirement perspective. Some well-known representatives of the CF are: data validation, transaction management, logging, exception handling, etc. Complexity of the maintenance process of a software system which includes the CF increases dramatically [14]. There are some peculiarities which are common to those crosscutting features, namely: complication of software requirements traceability; decrease of readability and understandability of diverse design artifacts; source code redundancy; lack of modularity which prevents further reuse of such CF-solutions.
Separation of Concerns (SoC) [10] is a principle which resolves CF problem. It presents a decomposition phase and a non-invasive composition phase of the CF-source code and the LSS basic source code. At the decomposition phase the source code of the crosscutting functionality should be localized, extracted and isolated, from the rest of the LSS-code, into well-structured modules (CFmodules). The composition phase involves reassembling of well-structured CF-modules with the LSS CF-free modules. Realization of the SoC principle allows solving CF-peculiarities listed above and implementing software system configuration in order to add or remove functionality, if it is required.
As mentioned in Section 1, there are three fully-fledged approaches in POOT-domain, namely: AOSD, COSD, FOSD. To represent main features of these approaches an interaction between basic OO-components and POOT-components should be restated [15]. AOSD was proposed about two decades ago in Xerox PARC research center, and now it is implemented in vast majority of programming languages, like Java, .Net, C++, JavaScript and so on. CF-related source code should be isolated in a special module, which is called the aspect. Further composition of this module and noncrosscutting functionality source code is based on the idea of intersection pointthe point-cut and the injection. Schematically this interaction is shown in Fig. 1(a), where the white vertical rectangles C1, C2, C3 represent OOP-classes and gray horizontal rectangles A1, A2, A3 represent the aspects.  [15] A specific structure of the aspect is represented in Fig. 1(b). It includes point-cut, advice and innertype declarations. The core function of point-cut is to define a set of join points between the aspect and the basic methods in OO-classes in order to inject advice source code. Advice represents a piece of source code of former CF, in other words it is a special kind of function written in a OO-programming language (e.g. Java). There are three types of advice: beforeis invoked before target method execution, afteris invoked after target method execution, aroundis invoked instead of a target method execution. Also it is possible to declare additional members of a target class such as fields and methods via inner-type declarations. Two other technologies, FOSD and COSD can be represented and analyzed in the similar way (see [15] for more details).
Even a short overview of CF issues shows that to make a decision about the effectiveness of using an appropriate POOT to resolve CF-problem in a given LSS, we need to consider a number of factors, which have to be formalized and evaluated in the appropriate modeling approach. This approach is elaborated in [15] and its main idea is to use the 3-D modeling information space which is graphically shown in Fig. 2. According to this modeling framework the integrated effectiveness level of a POOT usage depends on two interplaying factors, namely: 1) what type of LSS (System Type) has to be modified with an appropriate POOT; 2) what kind of POOT is used to eliminate the CF in this LSS.

58
Серія «Математичне моделювання. Інформаційні технології. Автоматизовані системи управління», випуск 41 Fig. 2 The 3-D space for assessment of POOTs effectiveness [15] In turn, an appropriate System Type for any given LSS can be defined as a set of two interconnected factors, namely: 1) the target software system Structural Complexity which can be evaluated from an appropriate collection of object-oriented source code metrics; 2) the system's Requirement Rank which depicts the complex characteristics of functional requirements in the target software system (Fig. 3).

Fig. 3 The 2-D space to define the System Type for the target LSS
More details concerning the framework for estimation of effectiveness coefficient of POOTs usage in maintenance of different types of LSS can be found in [15].
In order to realize our research goal: to elaborate the approach to assessing an impact of POOT usage on defect reduction in software maintenance, we propose to formulate a collection of heuristic assumptions. Those assumptions are based on the study of modern information sources and on the generalization of our own experience of using different POOTS in software development and maintenance. Assumption 1. A set T of post object-oriented technologies for software development does exist. AOSD, FOSD, COSD belong to this set.
It should be mentioned that the functions  and  cannot be defined in an analytical way, because there are a lot of weakly-formalized and complicated factors which characterize software development process in general, and the LSS maintenance phase in particular. Therefore we have decided to construct the appropriate metrics and to elaborate a procedure of assessing the impact of POOTs on possible software defects reduction in maintenance of LSS. Taking into account the assumptions (1) -(4) mentioned above, we propose a conceptual scheme for usage an appropriate POOT in order to reduce a number of defects during maintenance of a given LSS. The elaborated conceptual scheme is shown on Fig. 4, and it can be described briefly as a set of the following steps: Fig. 4 The proposed conceptual scheme 1. Some User (presented as a role on the scheme) requires some additional/new features to be added to a target LSS. These user's requirements have to be transformed into a new version of a software requirement specifications (SRS).
2. A given version of SRS precipitates the development a new version of a target LSS which embraces a set of project artifacts: a system model (e.g. architectural model, information model, etc.) and its realization, namely: a set of target software components.
3. A set of developed software components (source code) can be divided into the following groups, namely: a) a subset of components which are "healthy", that is, they do not contain source code with CF; b) a subset of components "infected" with a CF-code which leads to code scattering and tangling with a source code of another functional concern; c) a collection of CF-focused metrics to be constructed in order to assess a level of CF, its negative factors, etc.; d) using this metrics an appropriate CF-status of a given LSS has to be defined. 4. A current CF-status in LSS leads to some software defects to be fixed by Developer/Quality Assurance (QA) shown in conceptual scheme (Fig. 4). 5. A Developer/QA takes a care of assessing the number of defects, namely a) Completion of a defect reports; b) Computing a number of defects. 6. Basing on a given defect report the appropriate changes can be done in the next SRS versions. The steps (1) -(6) in the real LSS maintenance cycle have to be repeated iteratively. Basing on the results obtained from 3.c (usage of a CF-metrics collection) and 5.b (assessing a number of defects), an effective POOT (from AOSD, COSD, and FOSD respectively) can be chosen within 2.a (see these logically interconnected icons shown in grey in Fig. 4).

The 2-steps procedure to assess the defect reduction with usage of different POOTs in software maintenance
According to the proposed conceptual scheme (Fig. 4), and taking into account formulas (3) and (4) in Section 2, it is possible to construct the quantitative metrics and to elaborate the appropriate procedure to 1) assess a crosscutting functionality level in a given LSS; 2) compute a number of software defects in this system before and after the usage of an chosen POOT.
To perform these 2 steps we have to localize source code which includes a particular CF in a given LSS, and for this purpose we could use some already existing source code analysis tools for CF localization, CIDE, for example [16]. After that it is possible to define a specific crosscutting coefficient of a particular CF in the system indicated as CF ratio . This coefficient shows a ratio between OOP-classes "damaged" by a particular CF and all other OOP-classes in the given LSS, e.g. business logic realization without subordinate classes of a framework. This coefficient can be represented as: After obtaining ratio CF it is possible to calculate a residual crosscutting ratio (RCR) indicated as RCR ratio . This metric, based on DOS (Degree of Scattering) value is proposed in [15]. But this metric actually does not allow assessing a "damage" degree caused by a particular CF, therefore we propose to refine DOS-metric in the following way  (5) and (6) give to an expert a possibility to assess a distribution nature of a CF and to estimate a "CF-damage" for a whole given LSS.
As a next step we need to compute a number of defects (NoD) in a given LSS, and this can be done directly by using a special function known as a DefectCount (), namely  .
This function can be realized by defect tracking focused on corresponding features of the target software system before and after POOT-modification of the source code.
In our research we have used one of existent defect-tracking system as a defect collector for POOTmodified source code of features in the target LSS. Then direct observation and calculation of a number of defects have been applied to get the final result.

Experimental results and their analysis
Taking into account the workflow in the proposed conceptual scheme (Fig. 4) and using the quantitative metrics given in formulas (5)-(7) the appropriate computerized experiments have been performed [17]. The final results are presented briefly in Table 1 and in Fig. 5 -6. The number of software defects has been computed basing on the project reports obtained from the defect-tracking system and grouped according to the 4 system types: I, II, III and IV.  I  II  III  IV  I  II  III  IV  I  II  III  IV  COSD 28  68  46  83  6  The first group of table columns shows NoD for LSS of corresponding types where maintenance is based on OOP approach. It is evident that when the System Type becomes more and more complex NoD increases dramatically. For further calculations this defect quantity is considered as 100%. The second group of columns represents NoD for the same LSS after their modification with usage of appropriate POOTs: COSD, FOSD and AOSD. Fig. 5 shows the data presented in the first two groups of columns from Table 1 as a histogram, and it is obvious that NoD is decreasing with usage of any POOT for all system types (I, II, III and IV).

Fig. 5 Number of defects with POOTs impact
The values from the third group of columns in Table 1 are presented graphically in Fig. 5. It is possible to draw the following conclusions: 1. For LSS of the (I) and the (II) system types, all POOTs presents practically the same defect reduction. A low structural complexity of LSS could be a reason.
2. For LSS of type (III) the FOSD presents the lower defect reduction in comparison with AOSD and COSD. A difference between CF-weaving mechanisms in the corresponding POOTs is a reason.
3. For LSS of type (IV), the COSD provides the lowest level of residual number of defects, namely, about 20%.


To sum it up, COSD approach to CF-problem management has the strongest impact on a defect reduction for all System Types.

Conclusion and future work
This paper presents a framework for assessing the impact of post object-oriented technologies (POOT) usage on defect reduction in legacy software systems (LSS) maintenance. Some specific features of all existing POOTs, namely, AOSD, FOSD and COSD are considered. Particular attention is given to the crosscutting functionality (CF) problem. The heuristic assumptions to elaborate the assessment procedure for defects reduction are formulated. The collection of quantitative metrics to estimate of CF-level in LSS is provided. The conceptual scheme of the LSS maintenance process in respect to eliminating CF-problem by using POOTs is proposed. The scheme allows decreasing a number of software defects. The performed experiments show the impact of POOTs usage on defects reduction in real-life LSS maintenance projects.
Our future work will include advanced analysis of different defect types in LSS maintenance and detailed research of influence of each POOT on those defect types.