Method for optimizing a computer program

Abstract

According to various embodiments, a method for optimizing a computer program is provided, the method having: for dividing the computer program into a plurality of program parts, for each program part, determining a respective metric value; ranking the program portions according to the criticality of the descending order of the program portions based on the metric values; and processing the program portions in an order given by the sorting by checking, for each program portion to be processed and each criticality score metric, whether a metric value of the criticality score metric is above a specified threshold assigned to the criticality score metric; and initiating an optimization measure assigned to the criticality score metric if the metric value of the criticality score metric is above the threshold value.

Description

Technical Field

[0001] The present disclosure relates to methods for optimizing computer programs. Background Art

[0002] An important part of software application development is testing and, if errors or other weaknesses (such as poor performance) are discovered, making corresponding revisions. However, for larger computer programs, it is not practically possible to accurately check or revise all program parts. Therefore, there is a need for effective methods for optimizing computer programs that can be used in practice. Summary of the invention

[0003] According to various embodiments, a method for optimizing a computer program is provided, the method comprising: dividing the computer program into a plurality of program parts;

[0004] For each program part, a corresponding metric value (also referred to as m in the embodiment) is determined based on one or more criteria for each of the multiple criticality scoring metrics. i ), where each criticality score metric is assigned an optimization measure (e.g. splitting a program part (e.g. splitting a large function into multiple small functions), changing the library function used (e.g. copy_n instead of copy), etc.);

[0005] Based on the metric values, sorting the program parts according to their decreasing criticality (e.g. by summing the metric values ​​of the program parts to determine a (total) criticality value for each program part and sorting the program parts (in descending order) according to these criticality values); and

[0006] The program parts are processed in the order given by the sorting in that, for each program part to be processed and for each criticality scoring metric, it is checked whether the metric value of the criticality scoring metric is above a specified threshold value assigned to the criticality scoring metric, and if the metric value of the criticality scoring metric is above the threshold value, the optimization measure assigned to the criticality scoring metric is initiated.

[0007] The above method can automatically improve program parts (e.g., program code locations or program code areas, such as certain functions, classes or methods or also program parts contained in certain files) which are most likely to contain implementation errors or architectural or design defects, especially with regard to the quality of their (program) code. This can especially improve the computer program efficiently in terms of effort and efficiency: Particularly important program parts are improved, for example because these program parts form the core of the functionality of the corresponding software and have a high probability of containing errors due to their complexity.

[0008] In this case, "optimization" should not be understood as: the computer program is necessarily optimal after executing the method. Rather, it means: the computer program performs better according to certain quality criteria (such as the number of errors, execution time (for example, by removing bottlenecks), etc.) after executing the method. Correspondingly, the "optimization measure" can also be regarded as an "improvement measure" or "correction measure" (or "correction action").

[0009] According to various embodiments, the program portion with the highest probability of quality problems is identified (based on the value of the criticality scoring metric). This is achieved by using multiple criticality scoring metrics, each of which is based on one or more corresponding criteria, i.e., for example, one or more combinations of the following criteria:

[0010] Key metrics based on developer behavior and code evolution (e.g., information from version control logs);

[0011] Key metrics based on experience (e.g., how much experience does developer A have with a certain type of code or task?);

[0012] Key metrics based on the structure and architecture of the codebase (e.g., which parts of the codebase handle user input? Where are the externally accessible APIs?); and

[0013] Key metrics based on program analysis (e.g., results from static code analysis tools or fuzz testing tools).

[0014] Program parts can be sorted according to their criticality based on the criticality scoring metric. Then, revision measures can be initiated accordingly (e.g., at the code level, the architecture level, and the process level), that is, for example, a revision of the code can be initiated for a subset of the most critical program parts (i.e., the subset that is most meaningful for correction, especially the most meaningful subset in terms of the benefit-to-effort ratio) (e.g., a revision tool can be initiated, which automatically rewrites the code or at least makes suggestions when necessary, or can also give general recommendations to one or more developers (such as outputting "split the function", "use other libraries", etc.) when necessary), so that a good benefit-to-effort ratio can be achieved. According to various embodiments, the recommendation or initiation (and, if necessary, at least part of the revision measures) occurs automatically.

[0015] Various embodiments are described below.

[0016] Embodiment 1 is a method for optimizing a computer program as described above.

[0017] Embodiment 2 is a method according to embodiment 1, wherein the one or more criteria are one or more of the following criteria: the frequency of changes to a program part; a score assigned to one or more programmers of the program part (i.e., indicating to the one or more programmers that the program part comes from the one or more programmers); the frequency of errors in the program part; the frequency of execution of the program part when executing the computer program; a score of the size of the circle of programmers to which the program part is exposed regarding possible changes (i.e., the degree of exposure of the program part); the degree of dependence of the program part on other parts of the computer program; and the complexity of the program part.

[0018] In particular, according to various embodiments, a rating of a respective programmer or multiple respective programmers is taken into account, such as their experience (generally or with regard to the characteristics of the program part (such as the programming language used for their programming or its functions (such as communication, data encryption, etc.))).

[0019] Embodiment 3 is a method according to embodiment 1 or 2, wherein the criticality scoring metric combines and / or weights the criteria differently.

[0020] Thus, different criticality indicators and scores may be implemented, for example, a high criticality may be indicated due to a program portion having a high complexity and a high exposure level of the program portion.

[0021] Embodiment 4 is a method according to any one of embodiments 1 to 3, wherein the optimization measures assigned to these criticality scoring metrics are one or more of the following optimization measures: revision and / or review at the implementation level (i.e., for example, at the code level); revision at the architecture level (i.e., for example, splitting a function into sub-functions); error analysis; replacement of the programming language used for the program portion; and verification of the program portion using specific testing processes, validation processes, and / or verification processes.

[0022] This allows a wide range of optimization options to be covered.

[0023] Embodiment 5 is a method according to any one of embodiments 1 to 4, wherein the computer program is a control program for a robotic device, and the robotic device is controlled using a version of the computer program that is generated by optimization measures initiated by processing these program parts.

[0024] Embodiment 6 is a data processing device configured to execute the method according to any one of embodiments 1 to 5.

[0025] Embodiment 7 is a computer program having instructions, which, when executed by a processor, cause the processor to execute the method according to any one of embodiments 1 to 5.

[0026] Embodiment 8 is a computer-readable medium storing instructions, which, when executed by a processor, cause the processor to execute the method according to any one of embodiments 1 to 5. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In the accompanying drawings, like reference numerals generally refer to the same parts in all the different views. These drawings are not necessarily to scale, with emphasis instead generally being placed on presenting the principles of the invention. In the description below, various aspects are described with reference to the following drawings.

[0028] Figure 1 A computer for developing and / or testing software applications is shown.

[0029] Figure 2 Clarifies the determination of revision measures for computer programs by means of revision tools.

[0030] Figure 3 A flow chart 300 is shown which presents a method for optimizing a computer program according to an embodiment. DETAILED DESCRIPTION

[0031] The detailed description below refers to the accompanying drawings, which show, for the purpose of illustration, the specific details and aspects of the present disclosure in which the present invention may be implemented. Other aspects may be used and structural changes, logical changes, and electrical changes may be performed without departing from the scope of protection of the present invention. Different aspects of the present disclosure are not necessarily mutually exclusive, as some aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects.

[0032] Various examples are described in more detail below.

[0033] Figure 1 A computer 100 is shown for use in developing and / or testing software applications.

[0034] The computer 100 has a CPU (Central Processing Unit) 101 and a working memory (RAM) 102. The working memory 102 is used to load a program code, for example, from a hard disk 103, and the CPU 101 executes the program code.

[0035] In the present example, it is assumed that the user intends to use computer 100 to develop and / or test a software application.

[0036] To this end, the user runs the software development environment 104 on the CPU 101 .

[0037] The software development environment 104 enables users to develop and test applications 105 for various devices 106, i.e. target hardware, such as embedded systems for controlling robotic devices including robot arms and autonomous vehicles, or also for mobile (communication) devices. For this purpose, the CPU 101 can run an emulator as part of the software development environment 104 in order to simulate the behavior of the corresponding device 106 for which the application is being or has been developed. If the software development environment is only used to test software from other sources, the software development environment 104 can also be regarded as or designed as a software testing environment.

[0038] The user can distribute the finished application to the corresponding devices 106 via the communication network 107. Instead of via the communication network 107, this can also be done in another way, for example by means of a USB memory stick.

[0039] However, before doing so, the user should test the application 105 in order to avoid distributing an application that does not function properly to the device 106 , that is, the code quality of the application 105 should be ensured.

[0040] Ensuring code quality at both the implementation level (i.e., code without bugs) and the architectural level (i.e., code without errors) is an important task and will become increasingly important in the future, as value-added functionality is increasingly implemented in software. Software manufacturers may even have contractual obligations to support the software for a long period of time, making high code quality very interesting to developers.

[0041] Code quality can be checked with the help of program analysis techniques. Examples of such techniques are static code analysis, fuzz testing, symbolic execution, and hybrid execution. While all of these techniques will find errors, they are usually applied to the entire code base of a software project (these techniques could also be applied to individual classes or modules, but then the question is how to decide which classes or modules should be checked). This is ineffective because quality issues are usually unevenly distributed within the code base: the probability of quality issues is much higher for complex code or code that changes frequently than for simple, well-understood, and rarely changed code. Moreover, this is not feasible in practice for large software projects.

[0042] Therefore, according to various embodiments, a method is provided for automatically identifying the most important program parts with respect to quality improvement. To this end, according to various embodiments, different data (i.e., a wide selection of data) is used for this identification. This allows improving code quality at both the implementation level and the architectural level.

[0043] Various embodiments are based on the observation that in most software projects, the most effective - in terms of effort-to-benefit ratio - quality improvements are those that focus on a small number of selected program parts that have the highest complexity or the highest rate of change, or that developers at least trust (or a combination of these factors). Such program parts are called "hot spots" (i.e., considered critical program parts) because they are most likely to contain errors.

[0044] Based on this observation, a computer program (eg, application 105) is revised (ie, improved, for example, automatically improved by software development environment 104, for example, a corresponding revision tool 108 of software development environment 104), for example, by:

[0045] 1. Collect information about the code base to be checked, such as collecting logs from the version control system of the corresponding application.

[0046] 2. Scoring the program parts in a given code base based on the collected information, in the manner of: determining the scores by one or more scoring routines (hereinafter referred to as evaluators) and deriving the criticality scoring metric values ​​of multiple criticality scoring metrics from these scores. These scores are performed so that these scores (or the criticality scoring metric values ​​derived therefrom) are effective for determining whether the program part is a hotspot. For example, these criticality scoring metric values ​​provide a (total) criticality value (e.g., by summing these criticality scoring metric values), which can be regarded as evidence of whether the program part is a hotspot, for example, in the manner of comparing the (total) criticality value with a limit value; however, these criticality scoring metric values ​​can also only be used in a relative manner, that is, the program part for which the corresponding criticality scoring metric provides a higher criticality value is regarded as more critical than the program part for which the corresponding criticality scoring metric value provides a lower criticality value, see also the sorting described below.

[0047] 3. These program parts are then sorted according to their criticality. In other words: a list of the program parts is generated according to the descending order of their criticality, wherein the most critical program part is the first element in the list.

[0048] 4. Based on the generated program part list, derive measures for improving code quality.

[0049] 5. Start (i.e. trigger) or automatically use one or more of the derived measures. An example of a triggered measure is the creation of a new task in a task tracking tool (Task Tracker) of the corresponding software project to perform a code check (by a specific developer) on the corresponding program part, e.g. within a specific class or method. An example of an automatically provided measure is the automatic addition of (e.g. high-quality) static code analysis, e.g. using a tool such as Astree, to a CI / CD pipeline for a specific program part of the project, which can be, for example, code in a specific file, a specific class or a specific method.

[0050] In the following, reference Figure 2 The methods according to 1 to 5 described above are described in more detail.

[0051] Figure 2 The determination of revision measures for a computer program by a revision tool (eg, revision tool 108) is explained.

[0052] First, the revision tool 108 accepts the following inputs for the computer program (e.g., from a particular software project):

[0053] Source code metadata M (e.g. Git logs or log data from other version control systems such as SVN or Mercury);

[0054] Optionally, source code C;

[0055] Optionally, additional information, such as historical information about which developers developed which code parts or functions in previous software projects (e.g., "Developer A developed encryption modules in three previous software projects P1, P2, P3").

[0056] Revision tool 108 includes extractors e1 to e k The revision tool inputs these input data M, (optionally) C and (optionally) A to these extractors e1 to e2 k These extractors e1 to e k Using specific code features, developer features, or auxiliary data to determine a score indicative of potential code hotspots based on this information. For example, the score determined by an extractor for a program portion is a value, and the safer the extractor is from the perspective of the program portion being a code hotspot (i.e., the more critical the program portion is), the higher the value. i For example, the grading of a program section may be based on one or more of the following information:

[0057] The frequency of changes to a program part (e.g., code of a source code file or source code construct, such as a class or function). The extractor may obtain this frequency from data from a version control system, such as from a Git log. The higher this frequency, the higher the score the extractor sets for the program part.

[0058] Frequency of errors in a program part. The extractor can obtain this information, for example, from historical data of unit tests (or other regression tests, which have a scope corresponding to the program part (e.g. one or more source code files)), i.e., for example, information about which unit tests fail most frequently. The motivation in this case is that tests that fail frequently may test error-prone code. The higher the frequency, the higher the score the extractor sets for the program part.

[0059] The frequency of calls of a program code portion (e.g. a specific function), i.e. how often the program portion is executed when the computer program is executed. This information can be obtained from data on the call frequencies of individual functions in a specific software project, which data can be determined, for example, by means of software analysis. The motivation for this is that quality problems in rarely used functions may not be as critical as quality problems in frequently used functions. The higher the frequency, the higher the score the extractor will set for the program portion.

[0060] The degree of exposure, i.e. the score of the degree to which the program part is publicly accessible, i.e. the score of the size of the programmer circle to which the program part is exposed regarding possible changes. This degree can be determined, for example, based on information about which functions, class methods, APIs, etc. are internal and which are public. The motivation in this case is that functions accessible from outside the software project may be called by (malicious) users with arbitrary values ​​for their arguments, and thus become a higher risk when these functions contain quality issues. The higher the exposure of the program part, the higher the score the extractor will set for the program part.

[0061] The number of errors that the code analysis tool showed for the program section (this can also be considered as part of the information about the frequency of errors in the program section). Static code analysis tools, for example, show code that is likely to contain errors. In practice, most of these findings are false positives, but the presence of multiple findings usually indicates that there is a higher probability that the code contains quality issues. The higher the number, the higher the score that the extractor sets for the program section.

[0062] A quality score (e.g., experience) of one or more software developers who wrote the program portion. For example, have these developers previously developed projects written in the same programming language (then the extractor sets the score lower, otherwise higher); have these developers used the same libraries in the past (then the extractor sets the score lower, otherwise higher); have these developers programmed for the same runtime environment or operating system (then the extractor sets the score lower, otherwise higher); have these developers previously worked in the same domain, such as embedded programming (then the extractor sets the score lower, otherwise higher).

[0063] The extractor may also be used to determine the dependencies of the program part (on other parts of the computer program, in particular on library routines used in the computer program). The motivation in this case is that certain dependencies on certain libraries are riskier because these libraries are known to contain (more) bugs or contain functions that may make the software externally accessible, e.g. via a computer network. The stronger the dependency on libraries classified as high risk (which may depend on the extent of the respective risk scores of these libraries), the higher the score that the extractor will set for the program part.

[0064] The complexity of the program part. The more complex the program part, the higher the score is set by the extractor. The complexity can be scored based on various criteria such as nesting, the number of specific operations and / or the number of variables used, the types of library functions used, etc.

[0065] From extractor e1 to e k The determined scores are collected by the main extractor E of the revision tool 108. The main extractor E obtains the scores of the various extractors e1 to e2. k and calculates a (total) criticality value, i.e. a total score for each considered program part (e.g. file, class or function), and outputs a (possibly ordered) list H of program parts H, where each program part is assigned a classification value or a numerical value m1 to m2 with a (scoring) metric l The vector (m1; ...; m l ).

[0066] The criticality score metric m calculated by E i For example it could be

[0067] The output value of the extractor is e i ;

[0068] Extractors e1 to e k The weighted sum of the outputs of

[0069] The selected extractors, for example extractors e1, e5 and e 10The weighted sum of

[0070] A combination of logical predicates and sums, e.g. if e5>2:5 and e9<5:0, then output the weighted sum of e3 and e4, otherwise output another value, and so on.

[0071] The list H can, for example, be in the form of a matrix having n rows, ie one row for each considered program part (of the n considered program parts), and l columns, ie one row for each criticality scoring measure m. i There is a column. For each program part, you can start from m i For example, through m i The (total) criticality value is calculated by summing the values ​​of . These program parts can then be sorted according to descending criticality values ​​(i.e. the rows in H can be sorted in this way), and H can also be truncated, e.g. discarding rows whose criticality values ​​are below a certain threshold (these rows are then e.g. not considered "hotspots", i.e. H in this case only contains hotspots).

[0072] List H is used as the list for recommenders r1 to r j These recommenders output various measures o1 to o j to improve the quality of the computer program. The output of the recommender may be, for example, a (possibly ordered) list of program parts that:

[0073] should be revised at the implementation level, as these procedures partially contain technical weaknesses;

[0074] should be revised at the architectural level;

[0075] Should be subject to code review;

[0076] The relevant errors should be analyzed;

[0077] Should be rewritten in another programming language to ensure that certain quality issues do not occur;

[0078] Should be verified using testing, validation or verification strategies (or procedures) / special testing, validation or verification strategies (or procedures) / other testing, validation or verification strategies (or procedures), such as using other methods such as static code analysis or other tools;

[0079] It should be validated with the help of other testing strategies, such as using formal verification.

[0080] For example, each criticality scoring metric is assigned a corresponding measure, and when the value m of the criticality scoring metric is iWhen t is above the corresponding threshold, the recommender (e.g., also assigned to the measure) recommends the measure. For example, the criticality score metric may indicate for a program part that the program part

[0081] is both complex and long, and the corresponding recommender then recommends splitting the program into parts (e.g., dividing a function into sub-functions);

[0082] becomes a bottleneck, and the corresponding recommender then recommends revisions to the architecture of the computer program;

[0083] is severely exposed, and the corresponding recommender then recommends testing this program part (eg a subroutine) by means of fuzz testing.

[0084] In summary, according to various embodiments, there is provided a method for Figure 3 The method shown in .

[0085] Figure 3 A flow chart 300 is shown which presents a method for optimizing a computer program according to an embodiment.

[0086] At 301, for dividing the computer program into a plurality of program parts (for example, the method may include: determining the division), for each program part, for each of the plurality of criticality scoring metrics, determining a corresponding metric value (also referred to as m in the embodiment) based on one or more criteria. i Each criticality scoring metric is assigned an optimization measure (e.g. splitting the program part (e.g. splitting a large function into multiple small functions), changing the library functions used (e.g. copy_n instead of copy), etc.).

[0087] At 302 , based on the metric values, the program parts are sorted according to their descending criticality (eg, by summing the metric values ​​of the program parts to determine a (total) criticality value for each program part and sorting the program parts (in descending order) according to the criticality values).

[0088] At 303, the program parts are processed in the order given by the sorting in the following manner:

[0089] At 304, for each program portion to be processed and each criticality scoring metric, checking whether the metric value of the criticality scoring metric is above a specified threshold value assigned to the criticality scoring metric; and

[0090] At 305 , if the metric value of the criticality scoring metric is above the threshold, an optimization measure assigned to the criticality scoring metric is initiated.

[0091] Before considering the next program part, the optimization measures for these program parts do not need to be fully executed, but these program parts can also be combined into groups (for example, for the range of critical values), and these optimization measures can be performed together for each group. Alternatively, these optimization measures can also be performed separately for each program part.

[0092] Figure 3 The method can be executed automatically and iteratively.

[0093] Figure 3 The method can be performed (especially automatically) by one or more computers with one or more data processing units, for example. The term "data processing unit" can be understood as any type of entity capable of processing data or signals. For example, these data or signals can be processed according to at least one (that is, one or more than one) specific function, which is performed by the data processing unit. The data processing unit may include an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, an integrated circuit of a central unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array (FPGA), or any combination thereof or be constructed by these. Any other means for implementing the corresponding functions described in more detail herein can also be understood as a data processing unit or a logic circuit device. One or more of the method steps described in detail here can be implemented (e.g., realized) by a data processing unit through one or more specific functions, which are performed by the data processing unit.

[0094] Thus, according to various embodiments, the method is particularly computer-implemented.

[0095] The computer program may be, for example, a computer program which processes sensor data and generates control signals for a robotic device as a function of the results of the processing. The term "robotic device" may be understood to refer to any technical system (having mechanical parts whose movement is controlled), such as a computer-controlled machine, vehicle, household appliance, power tool, manufacturing machine, personal assistant or access control system.

Claims

1. A method for optimizing a computer program (105), comprising: dividing the computer program (105) into a plurality of program parts, For each program part, for each criticality scoring metric in a plurality of criticality scoring metrics, a corresponding metric value is determined (301) based on one or more criteria, wherein: Each criticality scoring metric is assigned an optimization measure; Based on the metric value, sorting the program parts according to descending criticality of the program parts (302); The program parts are processed (303) in the order given by the sorting by checking (304) for each program part to be processed and for each criticality scoring metric whether the metric value of the criticality scoring metric is above a specified threshold value assigned to the criticality scoring metric; and If the metric value of the criticality scoring metric is above the threshold, an optimization measure assigned to the criticality scoring metric is initiated (305).

2. The method according to claim 1, wherein: The one or more criteria are one or more of the following: the frequency of changes to said program parts; a rating of one or more programmers assigned to said portion of the program; frequency of errors in said program portion; the frequency of execution of said program parts when executing said computer program (105); a rating of the size of the community of programmers to which the program portion is exposed with respect to possible changes; and the degree of dependency of said program part on other parts of said computer program (105); and The complexity of the program part.

3. The method according to claim 1 or 2, wherein: The criticality scoring metric combines and / or weights the criteria differently.

4. The method according to any one of claims 1 to 3, wherein: The optimization measures assigned to the criticality scoring metric are one or more of the following optimization measures: Revision and / or review at the implementation level; Revisions at the architectural level; Error analysis; Change of programming language used for the program part; Verification of the program parts using specific testing procedures, validation procedures and / or verification procedures.

5. The method according to any one of claims 1 to 4, wherein: The computer program (105) is a control program for a robotic device, and the robotic device is controlled using a version of the computer program (105) which is generated by optimization measures initiated by processing of the program parts.

6. A data processing device (100) configured to carry out the method according to any one of claims 1 to 5. 7 . A computer program comprising instructions which, when executed by a processor, cause the processor to execute the method according to claim 1 .

8. A computer-readable medium storing instructions, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 5.

Images