The Effects of Static Analysis for Dynamic Software Updating: An Exploratory Study

Dynamic software updating (DSU) is the act of modifying software without stopping its execution. DSU is employed to preserve the high availability in the deployed software systems. Although significant investigations have been conducted on static analysis (SA) to determine DSU errors, no particular study exists that explores the effects of SA for dynamic software updating. The objective of the study presented in this paper is to explore the effects of static analysis for DSU. In this exploration, four evaluation metrics were declared including the number of update operations, the number of violations, the cyclomatic complexity, and the patch size. Also, a novel framework was introduced and 18 versions of baseline target programs were employed to explore the effects of static analysis for DSU. The results have explained that static analysis can detect violations of DSU. It may affect the complexity of the new versions of the target programs and having optimization can further reduce those violations. In addition, the results show that the SA may change the number of update operations and the patch size for DSU. Overall, the results have proved that SA for dynamic software updating could affect the complexity of the target programs, the number of update operations, and the patch size. Furthermore, this exploration has offered a novel framework and four evaluation metrics for measuring the effects of static analysis for DSU.


I. INTRODUCTION
Dynamic software updating (DSU) is the act of modifying software systems without having to terminate its execution [1], [2]. Experts have always considered DSU among the mandatory techniques for supporting the high availability of software systems [3], [4]. Recently, multiple solutions demonstrate DSU approaches [8], including the ability to analyze DSU statically before the trigger of the actual dynamic update procedures [6].
Static analysis (SA) is a program analysis approach to find software flaws without executing the program code [7]. Conspicuously, most early studies show that the SA helps to prove the correctness of dynamic software updating [8] and to ensure the safety of DSU [9], [10].
Although extensive research has been carried out on static analysis for DSU [6], [8]- [10], the effects of SA for dynamic software updating remain an open question. It is not obvious which parameters will be affected when applying static analysis for DSU. In this investigation, an exploratory study has The associate editor coordinating the review of this manuscript and approving it for publication was Porfirio Tramontana . been conducted to explore the effects of static analysis for dynamic software updating.
For this study, a novel framework was presented and four evaluation metrics were demonstrated to measure the effects of static analysis for DSU. The evaluation metrics includes the number of update operations [62], the number of violations [11]- [13], the cyclomatic complexity [14]- [16], and the patch size [17]- [19].
For this study, 18 versions of baseline target programs [6], [20]- [23] were employed to explore the effects of static analysis for DSU. The inspected target programs were extracted from 6 versions of benchmarks software including Apache SSHD 0.3, Apache SSHD 0.4, Zt-zip 1.4, Zt-zip 1.5, Apache Tomcat 8.5.37, and Apache Tomcat 8.5.38.
It is apparent from the outcome of this exploration is that the SA can help to detect violations to DSU. It may affect the complexity of the new versions of the target programs and having optimization can further reduce those violations. In addition, the results show that the static analysis may change the number of update operations and the patch size for dynamic software updating.
In overall, this study explored the effects of static analysis for DSU and has the following contributions: VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see http://creativecommons.org/licenses/by/4.0/ • Demonstrate four evaluation metrics to measure the effects of static analysis for dynamic software updating.
• Introduce a novel framework for measuring the effects of static analysis for dynamic software updating.
• Measure the effects of static analysis for DSU. This paper is organized as follows. Section II highlights the background and related works. Section III demonstrates the exploratory study. Section IV presents the conducted experiments. Section V presents the results and discussion. Section VI declares the principal findings. Section VII discusses threats to the validity of this study. Section VIII presents conclusions and future work.

II. BACKGROUND AND RELATED WORK
This section presents the background of static analysis, static analysis for dynamic software updating, and the related work.

A. STATIC ANALYSIS
Many works have recognized that program analysis plays an important role in finding software flaws [7], [26]- [28]. Program analysis can be implemented either statically, dynamically, or in a combination of both [24], [25]. Static analysis is (SA) is a program analysis approach useful in finding software errors without having to execute the program code [7], [24]. On the other hand, dynamic program analysis is performed during the program runtime [25].
The static analysis could be implemented in three ways: intraprocedural for analyzing the code of one method [25], interprocedural for analyzing a program with multiple methods [25], and local static analysis for analyzing a basic block code in a method [25].
To perform SA, the target source code should be converted into a directed graph [34], though some studies also suggested an undirected graph [35]. In a directed graph, the connections between vertices are one-way and can be visualized as arrows linking pairs of vertices [35].
In the light of reported SA, the control flow graph (CFG) [36]- [38] is utilized for the static analysis. A control flow graph (CFG) is a directed graph shows program control flows during the execution of the program [36]- [38]. Fig.1 shows an example of CFG [38].
In brief, the static analysis includes control flow analysis (CFA) [41] and data flow analysis (DFA) [39]. Moreover, some studies suggested applying optimization in the target programs is significant to ensure the correctness of the target programs [10] and for achieving high performance [10].

B. STATIC ANALYSIS FOR DYNAMIC SOFTWARE UPDATING
As shown in Fig.2, conceptually, dynamic software updating consists of two parts [42], the offline preparation part for preparing the code and the online updating part to handle the actual run time updating [42].
In the offline preprocessing part, where SA is utilized, a dynamic patch needs to be prepared to cover the transformation of the code and data between the old and the new versions of the target program. In the online updating part, patch processing will be implemented through data updating, code updating, and safety checks.
It was reported in the literature that the static analysis for dynamic software updating is anticipated to achieve the following objectives but not limited to: • Predict the exact requirements of an update by knowing what exactly has been changed in the new version of the target program [6].
• Prove the correctness of dynamic software updating [8].
• Predict which dynamic software updating solution might work better than others [6].

C. RELATED WORK
In recent years, various approaches have been proposed to utilize static analysis for dynamic software updating [6], [8], [10], [26]. In this section, we highlight several studies that are extremely relevant to this study. Šelajev et al. [6] formalized an approach for SA for dynamic software updating. The study [6] defined an approach for producing lists of the exact changes between versions of Java programs and examined if a given DSU system supports that update.
Also, Zhenxing et al. [8] proposed a static analysis method to guarantee the correctness of dynamic software updating and to make DSU easier and more flexible. In addition,  Li and Ogawa [26] presented and demonstrated an onthe-fly interprocedural program analysis algorithm called the sliding-window algorithm for efficiency and scalability in whole-program analysis on runtime [26].
Moreover, Sreedhar et al. [10] presented a novel framework called the extant analysis framework for interprocedural optimization. The study [10] described properties for DSU safety tests and provided algorithms for their generation and placement [10].
As presented in the related studies [6], [8], [10], [26], most studies in the static analysis for DSU are in the business of proposing a new approach [6], a method [8], an algorithm [26], and a framework [10]. To the best of our knowledge, no study to date has demonstrated evaluation metrics to measure the effect of static analysis for dynamic software updating. Respectfully, to highlight the effects of static analysis for DSU, the research domain requires exploration (such as this study) to understand more the effects of static analysis for dynamic software updating.

III. EXPLORATORY STUDY
This section declares the purpose of this exploration and presents measuring the effects of static analysis for dynamic software updating.

A. PURPOSE OF THE STUDY
This study aims to explore the effects of static analysis for dynamic software updating. The research questions (RQ) and the objective of each RQ are illustrated in Table 1.

B. MEASURING EFFECTS OF STATIC ANALYSIS FOR DYNAMIC SOFTWARE UPDATING
This sub-section highlights the proposed evaluation metrics to answer RQ 1 and demonstrates a suggested framework to respond to RQ 2.

1) EVALUATION METRICS
For this exploration, we borrow the idea of using the computed metrics for two versions of a system to assess the evolution [44] to measure the effects of static analysis for dynamic software updating. In addition, we propose to utilize four evaluation metrics, includes the number of update operations [62], the number of violations [11]- [13], Cyclomatic Complexity (CC) [14]- [16], and the patch size [17]- [19].

a: THE NUMBER OF UPDATE OPERATIONS
In this analysis, we propose to compare 2 versions of one target program for code similarities using the available Diff algorithms [62] and count the number of update operations (NOUO) as follows: Throughout this paper, we use the acronym NOUO to refer to the number of update operations.

b: THE METRIC OF THE NUMBER OF VIOLATIONS
In this analysis, we propose to utilize the metrics of the number of violations [11] due to the following: • Measuring the number of violations is a common practice in assessing coding standards that are strongly related to latent faults [11]- [13].
• Previous research has emphasized violation measures for DSU such as evaluating type safety violations 8]. Suppose we analyze the code of the target program which resulted from the update of old and the new code. The total number of violations (TNOV) can be calculated as follows: where VAL is a violation of a static analysis rule.

c: THE METRIC OF PATCH SIZE
The patch as a set of changes to a computer program or its supporting data designed to update, fix, or improve the program [45], [46]. The patch size is the sum of several contains including the size of the code being inserted [17], supplementary inserted codes, and annotations [17], [18].
In this analysis, we suggest to use the metric of the patch size [17]- [19] due to the following reasons: • A large number of existing studies in the broader literature have examined patches in to request and guide the dynamic updating [42], [47].
• Research has provided evidence for loading time in DSU is proportional to the patch size [18]. For the current assessment, the metric of the patch size (per byte) as is calculated as follows: where SP is the patch size.

d: CYCLOMATIC COMPLEXITY METRIC
For this examination, we suggest utilizing the cyclomatic or McCabe complexity (CC) [14]- [16] metric to the following reasons: • Cyclomatic complexity is considered to predict software components that likely have a high defect rate or that might be difficult to test and maintain [14], [44].
• The majority of prior research has applied complexity measures to help establish risk and stability estimations on an item of code [14].
• An increasing number of investigations have explained that CC is accomplished by measuring the control flow structure in a directed graph [8], [14], [48], [49]. Previous studies have shown that CC measures the number of linearly independent paths in a code [8], [14], [48], [49]. CC is defined as the number of edges minus the number of nodes plus 2 [17] as follows: where e is the number of edges, n is the number of nodes.
Furthermore, Fig.3 shows examples of CC.

2) FESAD: A FRAMEWORK FOR MEASURING EFFECTS OF STATIC ANALYSIS FOR DYNAMIC SOFTWARE UPDATING
For this study, we searched for literature to observe how SA for dynamic software updating is implemented. Our first set of analyses have examined the related studies [6], [8], [10], [26], and the second batch of investigations have inspected additional studies [42], [43], [50], [51] for more understanding of SA for dynamic software updating.
As an outcome, a novel framework was proposed for utilizing SA for measuring the effects of static analysis for DSU and illustrated in Fig. 4. As displayed in Fig. 4, the proposed framework is containing three phases as follows:   [52], [52]- [54], [56]. a) Phase 1: Dynamic software updating without SA In this phase, DSU will be applied without static analysis. Also, pole position (The start point) measurements [62] will be utilized to measure the following: 1) The patch size.
3) The cyclomatic complexity for the target program. b) Phase 2: Static analysis for dynamic software updating In this phase, the static analysis will be applied for DSU. Also, the final destination (The endpoint) measurements will be utilized to measure the following: A. The number of violations. B. The patch size. C. The number of update operations (NOUO). D. The cyclomatic complexity for the target program. Currently, a large number of existing studies have utilized the static analysis rules in static program analyzer tools such as the programmer mistake detection tool (PMD) [52]- [57]. For example, Table 2 highlights some of the available static analysis rules in PMD.
A number of authors have recognized static analysis including control flow analysis can be utilized for dynamic software updating in error prevention, detection, and removal [6], [8], [10], [26]. For example, recent research suggests that static analysis rules for DSU can be utilized for the following: • Detection and annotating of unsafe update points [59]. • Guarantees about which types will be updatable at runtime [5].
• Predicts which types are modifiable at each update point [5].
• Ensure when an item (method, identifiers) will be removed from a class, any access to the removed item through the old code after the update is forbidden because it will lead to a runtime error [59].
• Check the signature of a class constructor which has parameters to be changed, if there is no implicit type conversion between the type of the parameters of the old and new constructor, the update is said to be unsafe [59]. In addition, some authors have driven the further improvement through possible optimization in the target programs can be included to code smells [59] and to assist in errors prevention, detection, and removal for dynamic software updating, such as dead code elimination [58], Inlining [58], copy propagation [58], constant propagation [58], strength reduction-induction variable [58], tail recursion elimination [58], and software pipelining [58]. c) Phase 3: Compare the results of Phase (a) and Phase (b) To measure the effects of static analysis for dynamic software updating, in this investigation, we have suggested the following assessments: A. Compare the difference between the patch size in DSU without static analysis (Phase 1) against patch size in SA for dynamic software updating (Phase 2). B. Compare the difference between NOUO in DSU without static analysis (Phase 1) against NOUO in SA for dynamic software updating (Phase 2). C. Compare the difference between the CC of the target program in DSU without static analysis (Phase 1) against the CC of the same target program in SA for dynamic software updating (Phase 2). For this study, the suggested framework is utilized in the subsequent sections. Throughout this paper, we will use the acronym FESAD to refer to the proposed framework.

IV. EXPERIMENTS
This section presents the conducted experiments for measuring the effects of static analysis for DSU.
For this study, the experimental setup was prepared as follows: • The operating system is 64-bit Windows 10, with 8 GB RAM, Intel Core 3.40 GHz, and 8-core CPU.
• Java Development Kit (JDK) 1.8. For the selections of the experimental subject, the literature review shows the majority of prior research in DSU utilizing a group of baseline target programs as a benchmark for the research in the domain [6], [20]- [23]. Among them, the following subjects were selected for this study: 1) Apache SSHD [20], [21]: is a Java software supports SSH protocols on both client and server-side. For this investigation, 2 versions were selected including Apache SSHD version 0.3.0 and Apache SSHD version 0.4.0. 2) Zt-zip [6]: is a Java software for file compression. For this examination, 2 versions were selected including Zt-zip version1.4 and Zt-zip version 1.5.

3) Apache Tomcat [21], [23]
: is an open-source Java HTTP web server. For this exploration, 2 versions were selected including Apache Tomcat version 8.5.37 and Apache Tomcat version 8.5.38. For this exploration, official software releases from the package repositories of the selected software were copied. Also, a list of updated programs was identified from each of the selected subjects utilizing Algorithm 1. The results of applying Algorithm1 is illustrated in Fig.5. File f1 = (File) iter. Next

10:
Save f1 in the list of updated programs;    Table 3. Also, the FESAD framework was utilized and the results are presented and discussed in Section V.

V. RESULTS AND DISCUSSION
This section presents and discusses the experimental results of this exploration including pole position results, final destination results, data analysis, and comparison of the collected results.

A. POLE POSITION RESULTS
As illustrated in the FESAD framework, the initial set of analyses explorers applying DSU without static analysis in the given experimental subjects. Table 4 presents pole position results including NOUO (Number of update operations) and patch size when DSU was implemented in the selected target programs without static analysis.
Also, Table 5 presents the Cyclomatic Complexity (CC) for the selected target programs when DSU was implemented in the selected target programs without SA.

B. FINAL DESTINATION RESULTS
As represented in the FESAD framework, the second batch of the analyses explores applying SA for dynamic software 35166 VOLUME 8, 2020   updating. Therefore, we applied static analysis for DSU utilizing the PMD tool and the static analysis rules in Section III. As a result, Table 6 shows the number of violations when static analysis for DSU was implemented in the selected target programs.
In addition, we have implemented optimizations to fix the violations of dynamic software updating in the new versions of the selected target programs. Table 7 shows the number of violations after optimizations in the new versions of the selected target programs.
Moreover, Table 8 declares the results of the CC metrics after SA is utilized for dynamic software updating in the new versions of the selected target programs. Furthermore, Table 9 shows NOUO (Number of update operations) and the patch size when the static analysis for DSU was implemented in the selected target programs.

C. DATA ANALYSIS
Before proceeding to compare the pole position results against the final destination results, it will be necessary to  analyze the data. The analysis includes the obtained data of NOUO, patches size, the number of violations, and CC. Table 4, the average of the number of update operations (NOUO) is approximately 19 in the pole position results. On the other hand, as presented in Table 9, the average of NOUO is relatively increased to 25 in the final destination results. In addition, as shown in Fig.6, we exhibited the results in a Clustered Column Chart.

As illustrated in
As displayed in Fig.6, X-axis presents the selected target programs. Y-axis displays the NOUO. The clustered columns show the pole position and the final destination results. The results show that the NOUO numbers are changed in most of the selected target programs in the final destination results.

2) THE PATCH SIZE
As depicted in Table 4, the max patch size is 1845 bytes and the minimum patch size is 550 bytes in the pole position results. On the other hand, as displayed in Table 9, the max patch size is 4285 bytes and the minimum patch size is 619 bytes in the final destination results. Moreover, as illustrated in Fig.7, we presented the results in a Clustered Bar Chart.
As demonstrated in Fig.7, Y-axis presents the selected target programs. X-axis presents the patch size (per byte). The clustered columns show the pole position and the final destination results. The results show that the patch size is VOLUME 8, 2020  amended in most of the selected target programs in the final destination results.

3) THE NUMBER OF VIOLATIONS
As illustrated in Table 6, the average of the number of violations is 9 when applying SA before optimizations. On the other hand, as presented in Table 7, the average is relatively decreased to 2 when applying static analysis with optimizations. In addition, as presented in Fig.8, we demonstrated the results in a Clustered Column Chart.
As displayed in Fig.8, X-axis presents the selected target programs. Y-axis displays the number of violations. The clustered columns show the number of violations before and after SA and optimizations. The results show that the number of violations is decreased in all the selected new target programs after optimizations.

4) CYCLOMATIC COMPLEXITY
As depicted in Table 5, the max number of cyclomatic complexity (CC) in the new versions of the target programs is 277 and the minimum value is 14 in the pole position results. On the other hand, as shown in Table 8, the max number of CC in the new versions of the target programs is 275 and the

D. COMPARE THE POLE POSITION RESULTS AND THE FINAL DESTINATION RESULTS
As demonstrated in the FESAD framework, the third batch of the analyses compares the results of pole position results against the final destination results. As an outcome, we observed the following: • As shown in Table 4, Table 9 and Fig.7, the sizes of patches are changed after SA for most of the selected target programs except for WsServerContainer and WsHttpUpgradeHandler. Overall, out of 9 patches, only 2 remains in the same size. Thus, the data supports the premise that the static analysis may change the patch size for dynamic software updating.
• As presented in Table 6, Table 7, and Fig.8, the number of violations for the same target programs were changed which determines that the static analysis is identifying violations ( Table 6) to DSU and having optimization (Table 7) can further reduce those violations.
• As presented in Table 4, Table 9 and Fig.6, the NOUO are changed after SA was implemented for most of the selected target programs except for WsServerContainer and WsHttpUpgradeHandler. From the results, it is clear that the static analysis may change the number of update operations for dynamic software updating.
• As displayed in Table 5, Table 8, and Fig.9, the CC values were not modified after static analysis for DSU was implemented for 4 new versions of target programs including, ZipUtil, ClientSessionImpl, Chan-nelSession, and, JNDIRealm. The most striking result to emerge from the data is that the SA for dynamic software updating may change the complexity of the new versions of the target programs.

VI. PRINCIPAL FINDINGS
Our results cast a new light on static analysis for dynamic software updating through an exploratory study where four evaluation metrics were declared, a novel framework was introduced, and 18 versions of baseline target programs were employed to explore the effects of static analysis for DSU. Based on our results, we declare the main findings of our exploration as follows: • The results verified that static analysis for dynamic software updating determines violations of DSU. This key conclusion validates the usefulness of investigating and fixing errors early to reduce violations when applying DSU. The present finding seems to be consistent with other research that found that static analysis will help to prove the correctness of DSU [8] and to ensure the safety of DSU [9], [10].
• The most remarkable finding was that SA for dynamic software updating may change the patch size. As a consequence, this finding is in accordance with findings that measure the update loading time based on the size of the patch [18].
• The most interesting finding was that SA for dynamic software updating may affect the complexity of the target programs. The present findings are directly in line with previous findings that found the changes in the complexity of the program will affect the maintainability of the program [16], and will directly affect the eligibility and the reliability of the software [16]. Also, this finding can be compared with an argument made by Bierman et al. [60] that updatable programs must be reliable, yet updating itself introduces further complexity, also, Bierman et al. [60] reveals that to prevent total confusion, techniques are required for ensuring that the dynamic updates are in some sense safe [60].

VII. THREATS TO VALIDITY
Although this study shows the core of our exploration of the effects of static analysis for dynamic software updating, there are threats to the validity of the results that readers should take into account when interpreting the outcome. The threats include the conclusion, internal and external validity. This section clarifies threats to the validity of this study.

A. INTERNAL VALIDITY
Internal validity takes place when it implies that we proposed a framework based on our experience in dynamic software updating. To mitigate this threat, we introduced our framework (FESAD) based on several investigations [6], [8], [10], [26] , [42], [43], [50], [51] to identify how static analysis for DSU was demonstrated in those studies.

B. EXTERNAL VALIDITY
External validity takes place when it implies the validity of our target programs, the way the target programs were updated, and the code patches utilized, whereby the results might be dissimilar if different parameters are used and limit the generalization of our results. We cannot claim that the results presented in Java programs are valid for other target programs than Java. To minimize those threats, in our exploratory study, we used 18 real target programs with a real update that was used before in other dynamic software updating studies [6], [20]- [23].

C. CONCLUSION VALIDITY
For conclusion validity, we are not aware of biases we may have had when interpreting the results. The reader should be aware of the impact of our interests on the study. To mitigate this threat, four evaluation metrics were demonstrated to draw the conclusion utilizing well-known metrics including the number of violations [11]- [13], the cyclomatic complexity [14]- [16], and the patch size [17]- [19].

VIII. CONCLUSION AND FUTURE WORK
In recent years, there has been increasing interest in modifying software systems without termination, i.e. dynamic software updating (DSU) [1], [2]. One of the respected examinations in this domain is the static analysis for DSU [5], [6], [8], [10], [26]. Experts have always considered DSU among the mandatory techniques for supporting the high availability of software systems [3], [4].
Although significant investigations have been conducted on static analysis (SA) to determine DSU errors, no particular study exists that explores the effects of SA for dynamic software updating. Respectfully, this study explored the effects of static analysis for dynamic software updating.
Static analysis (SA) is a program analysis approach to find software flaws without executing the program code [7]. Conspicuously, most early studies show that the SA helps to prove the correctness of dynamic software updating [8] and to ensure the safety of DSU [9], [10].
In this study, a novel framework was presented and four evaluation metrics were demonstrated to measure the effects of static analysis for DSU. The evaluation metrics includes VOLUME 8, 2020 the number of update operations [62], the number of violations [11]- [13], the cyclomatic complexity [14]- [16], and the patch size [17]- [19].
It is apparent from the outcome is that the SA can help to detect violations to DSU. It may affect the complexity of the new versions of the target programs and having optimization can further reduce those violations. In addition, the results show that the static analysis may change the number of update operations and the patch size for dynamic software updating.
Looking forward, further attempts could prove quite beneficial to search to reduce the potential effects of static analysis for dynamic software updating. Overall, the results of this study will help the researchers and practitioners in carrying out static analysis for dynamic software updating with more understanding of its effects.