Change Impact Analysis (Change Impact Analysis) Techniques

The section below depicts the different research studies conducted on Change Impact Analysis in contemporary literature. Most of the studies related to our research are presented below. The following sections in this chapter focus on describing proposed approaches, evaluating their regular procedures and also predicting them based on the capability of aiding multi-perspective Change Impact Analysis. This work focused on three primary requirements to execute an efficient Change Impact Analysis procedure:

  • • The ability to evaluate the diversified software artefacts
  • • Extending assistance to developers to identify the extent and areas affected by the change
  • • Assistance for multiple types of modification functions

Dependency Analysis

This chapter depicts numerous Change Impact Analysis techniques using dependency associations between artefacts for executing actual Change Impact Analysis. These techniques are further classified into five different groups, which are explained in the sections below.

Distance-Based Graph Analysis

Initial studies developed in the Change Impact Analysis concept relied on dependencies of the program and used the related dependency map for predicting the change proliferation to different artefacts on the basis of proximity factors. However, these proliferations among dependencies resulted in an impact of the total system [22]. Accordingly, the effect calculated for a specific modification was often over-predicted and was not usable for re-engineering or maintenance of projects. Hence, the concept of dependencies was redesigned to restrict change proliferation to a pre-fixed length in the graph. This extended concept of dependencies presumes that all modifications affect only locally, and therefore unnecessary extra change proliferation is removed after the pre-fix distance is reached [22].

However, these techniques face challenges regarding the selection of appropriate transmission distance, which remains an unanswered task

[23] . In case the distance is long, several false-positives can occur across the project as all the artefacts are regarded as being affected. On the contrary, a small distance can lead to several impacts being ignored as all potential artefacts could not be covered. The advantages and drawbacks of distance-based graph analysis are represented in Table 2.1.

Message Dependency Graphy

A unique type of dependency Change Impact Analysis method is proposed and designed for broadcast and event-driven systems. This approach analyzes the textual communication among the system’s remote components. Later, through maintaining track of transmitted messages and documenting the observed transmission routes, the related dependency graph will be created. This graph is used for further impact analysis. Instances related to this work are explained in

[24] . The advantages and drawbacks of message dependency graph analysis are represented in Table 2.2.

TABLE 2.1

Benefits and Drawbacks of the Distance-Based Graph Analysis Approach

Benefits Drawbacks

Multi-perspective analysis possible Difficult to define the correct distance Understand and implement easily No distinction among diverse modifications

TABLE 2.2

Benefits and Drawbacks of the Message Dependency

Graph Analysis Approach

Benefits

Distributed systems analysis

Event-based systems analysis

Drawbacks

Needs software execution

Needs message monitoring

TABLE 2.3

Benefits and Drawbacks of the Call Graph Analysis Approach

Benefits

Drawbacks

To extract the call graph easily

Only relevant on source code

No distinction among diverse changes Granularity restricted to methods

Call Graph

This method establishes the potential effects of system changes on already existing source codes through identifying call relationships of both functions and procedures/methods that build the code. Hence, specific calls of procedures and functions should be derived from source codes and are stored in a graphical representation called a “call graph”. With the completion of the calls extraction process, a call graph’s transitive closure is evaluated and used for further Change Impact Analysis tasks.

In this kind of Change Impact Analysis dependency analysis, methods are determined as affected if the methods call a modified method. In other dimensions, methods are often impacted when a modified method is called by other called methods repeatedly. Related instances are depicted in [25,26]. The advantages and drawbacks of the call graph analysis approach are represented in Table 2.3.

DETA Analysis

Call graph Change Impact Analysis techniques suffer from extremely low accuracy metrics [27]. This can be enhanced by considering the various procedures which are called during the software program implementation. Therefore, a proposal is made to monitor the execution process of software programs for Change Impact Analysis purposes. However, this proposed method needs specified software programs to be effectively adapted and implemented to determine respective call behaviours. Finally, the execution traces which are monitored can be used for Change Impact Analysis, where any tracing model consisting of a minimum of the single modified model is regarded as affected. Related instances regarding this approach are depicted in [27-29]. The advantages and drawbacks of the DETA approach are represented in Table 2.4.

Program Slicing Analysis

The approach is utilized for understanding the project and maintenance of tasks. In addition, this is often employed in the Change Impact Analysis procedure. Slicing “brushes away” any such code sentences which have no impact on the specific code parameter. This results in all those code sentences which are impacted by modifications to the particular parameter.

A slice is measured by analyzing both dependencies including data (such as value assignments) and control (like if-conditions) dependencies of software program statements, which alter a program variable. Therefore, it is applicable in both the forward and backward approaches [30]. Hence, when modifying a specified statement of a software program, the slicing technique is employed to identify statements which are highly impacted by the change. Diversified program slicing tools often exist for various programming languages and Integrated Development Environments (IDEs) like those mentioned in [31] or [32]. The advantages and drawbacks of the program slicing approach are represented in Table 2.5.

MSR (Mining Software Repositories) Techniques

Unlike other proposed techniques, MSR approaches do not involve retrieving dependencies from artefacts. Instead, these methods derive

TABLE 2.4

Benefits and Drawbacks of the DETA Approach

Benefits Drawbacks

More precise than call graphs Only relevant on source code

No distinction among diverse changes Requires code instrumentation

Granularity restricted to approaches

TABLE 2.5

Benefits and Drawbacks of the Program Slicing Approach

Benefits Drawbacks

Acceptance by programmers Only relevant on source code

Good tool support

artefacts from repositories of software. While maintaining track of the version history of artefacts, this approach examines efficient associations between various software artefacts which are only accessible from repositories. Few of the broadly used version control systems include CVS, SVN or Git.

The MSR-based analysis is engaged in exploring the patterns of co-modification or co-evolution of various software artefacts if there exist any regular alterations between those artefacts. Thus, by analyzing the probability of frequent co-changes, MSR methods will be able to identify the correlated artefacts. Instances of this approach are explained in [23,33-36]. The advantages and drawbacks of the MSR-based approach are represented in Table 2.6.

Information Retrieval (IR)

IR-based techniques are used for name scanning, detectors and text modules of software artefacts to extract the patterns with a similar text. If any textual matches between two software artefacts are observed, the IR approach estimates that change in one artefact will obviously affect the other. As in MSR methods, IR-based techniques are effectively involved in analyzing various types of artefacts, considering the

TABLE 2.6

Benefits and Drawbacks of the MSR-Based Approach

Benefits Drawbacks

Multi-perspective analysis possible Requires history availability

Artefacts should evolve in a similar repository

Dependent on commit behaviour

Selection of sliding window critical

No distinction among diverse changes

Not applicable in the early stages

TABLE 2.7

Benefits and Drawbacks of the IR-Based Approach

Benefits Drawbacks

Multi-perspective analysis possible n0 distinction among diverse modifications

Only lexical similarities deliberated

textual components of artefacts. IR-based impact analysis methods are broadly classified into two phases: pre-processing analysis and original text analysis. On the pre-processing analysis front, essential techniques like remove-stop-word and stemming-word are utilized to minimize the possible space for search [37]. Later, the actual text phase is initiated by utilizing N-gram-based [38] or Latent Semantic Indexing [39] text comparison methods. However, these techniques neither describe a difference between diversified types of change activities nor identify the resulting effects. Instances related to these approaches are depicted in [40,41]. The advantages and drawbacks of the IR-based approach are represented in Table 2.7.

Probabilistic Approaches

Some of the studies that incorporated probabilistic techniques are introduced to represent and analyze a specified software system when a change is observed in the system. These approaches utilize different probabilistic models, including Markov chains to analyze the affected system. With the completion of system modelling, the probabilistic Change Impact Analysis approach is initiated for executing Change Impact Analysis functions like Granger causality tests or Bayesian inference. Hence, as per the computed probabilities, if a change in software artefact is noted then related information is sent to the software developer. Instances related to this research work are explained in [36,42,43]. The advantages and drawbacks of the probabilistic approaches are represented in Table 2.8.

Rule-Based Techniques

A unique Change Impact Analysis procedure is proposed through rule-based methods. According to this approach, a definite set of rules are used to predict the various effects of a system change.

TABLE 2.8

Benefits and Drawbacks of Probabilistic Approaches

Benefits

Drawbacks

Multi-perspective analysis possible

Difficult to understand the computed change propagation

Hard to model the interplay of heterogeneous software artefacts

No distinction among diverse changes

The primary objective of this method is to detect an impact through established rules when specific modification activity is carried out in a given software system.

The process of establishing an essential set of rules varies from method to method. Few researchers advise using the information of a developer, domain and design methodologies to generate the most appropriate Change Impact Analysis rules. With the dependency on software artefacts types, multiple query languages are employed to execute these set of rules, including those given in [44-46]. The case studies which relate to this approach are depicted in [47,48]. The advantages and drawbacks of the rule-based approach are represented in Table 2.9.

Hybrid Approaches

Hybrid approaches include a combination of numerous above-mentioned techniques to execute an efficient Change Impact Analysis. For instance, in [49], the researcher makes use of diversified analyses

TABLE 2.9

Benefits and Drawbacks of the Rule-Based Approach

Benefits Drawbacks

Multi-perspective analysis possible Can be enhanced with repair plans

Can address different changes

Allows addition/change of rules

Rules creation is time consuming

Rules creation is not addressed by the present research

Rules need maintenance

Hard to address ambiguous impacts

Rules require validationincluding IR approaches, MSR techniques and DETA approach. Despite being involved in identifying the significant effects of a system change in different artefacts of software, this approach is unable to classify the accurate impact types. In addition, as it is combined with other methods, it also experiences the drawbacks of those approaches.

Multi-Perspective Approaches

One of the main challenges of the review of literature is to check whether there are any methods present for the multi-perspective impact of change analysis that are meeting our pre-requisites. Therefore, in this segment, we represent outcomes of review with respect to perspectives and software artefact types covered by contemporary researches. As per our taxonomy of impact analysis, here, we deliberate three important software artefact types and their relevant perspectives like architectures of software, pre-requisites and source code. Further, some contributions also examine documentation files and configuration that are referred to as other artefacts because of inhomogeneous reasons and architecture. Figures 2.1 and

2.2 summarize the results of our literature review.

Also, we examined how many distinct software artefacts and perspectives were covered by some of the current multi-perspective methods. Moreover, distinct perspective distribution summarization is shown in Figure 2.2, among some of the available multi-perspective methods.

DISTRIBUTION OF LITERATURE SCOPE

Distribution of scopes among the studied approaches

Figure 2.1 Distribution of scopes among the studied approaches.

MULTI-PERSPECTIVE APPROACHES

Scopes supported by multi-perspective approaches

Figure 2.2 Scopes supported by multi-perspective approaches.

The huge majority of current multi-perspective methods are concentrated in two perspectives exactly, where only three methods are truly capable of addressing heterogeneous software artefacts types (Figure 2.2). Further, most of the methods are confined strictly in their assistance of distinct kinds of varying operations.

 
Source
< Prev   CONTENTS   Source   Next >