KR101970717B1 - Management method for java methods based on bytecode, development system and method for java software using the same - Google Patents

Abstract

A Java software development management system of the present invention is disclosed. More particularly, the present invention relates to a byte code-based Java method version management method for providing line coverage information in a test quality management tool in a Java environment, and a Java software development system and method using the same.
According to the embodiment of the present invention, in the Java-based software development system, by managing version-specific version information for execution line coverage management by version information according to version information extraction of methods using only class file information, Even if the class file is destroyed, the coverage information of the corresponding version can also be restored.

Description

TECHNICAL FIELD [0001] The present invention relates to a method of managing a version of a Java method based on bytecode, and a Java software development system and method using the same. [0002]

The present invention relates to a Java software development management system, and more particularly, to a bytecode-based Java method version management method for providing line coverage information in a test quality management tool in a Java environment, and a Java software development system and method using the same.

Generally, run line coverage information or code coverage information provided by a test quality management tool of commercialized software is used to determine how much the line or code of the source code is actually in the runtime test environment It is one of the important information that can quantitatively express the quality of the test with the ratio information of whether it is executed or not.

However, in order to provide the line coverage information to the user, it is necessary to record the actually executed line in the run-time test environment, and line information about the source code applied to the run-time test environment is essential.

In a Java-based software environment, an executable binary is managed as a class file composed of bytecodes. Since line information can be added according to a compile option, a class file The line information of the source code can be extracted. Therefore, Java-based software can be processed to provide line coverage information only by the class file that is distributed and executed.

Among the programming languages, Java provides the BCI (byte code instrumentation) function from version 1.5, indicating the ability to change information about the class file in advance at class loading time. With the BCI feature, you can modify the bytecode before the class file is executed, so you can inject the API call bytecode directly to write the execution line to the method specific bytecode. Also, line information of the method can be extracted together.

However, in order to calculate the execution line coverage through such a system configuration, the following problems arise.

The first is a method versioning problem for initializing the coverage information according to the modification and redistribution of the class file. If the version of the method is calculated based on the source file, it should not respond to changes not related to the actual execution logic It requires a very complicated parsing process. If this change is not ignored, unnecessary initialization of coverage information frequently occurs, which causes the reliability of the test quality management system to be reduced.

The second problem is that the currently executing process loads and executes the class file that is the same version as the class file existing in the file system. Even if the class change is detected and the coverage information of the related line is initialized, If run and recorded as a class file of the previous version, coverage information can be calculated with incorrect execution line information. Thereby, there is a restriction that the execution version information always has to be recorded together with the method version ID obtained from the currently executing class file.

Korean Registered Patent No. 10-0678912 (Publication Date: February 5, 2007) Korean Registered Patent No. 10-0967525 (Publication date: July 7, 2010)

SUMMARY OF THE INVENTION The present invention has been conceived to solve the above-mentioned problems, and it is an object of the present invention to provide a method and apparatus for managing version information of each method, which is essential for execution line coverage management, by extracting version information of a method using only class file information, A version control method of a Java method based on byte code, and a Java software development system and method using the same.

In order to solve the above problems, a Java software development system using a byte code-based Java method version management method according to an embodiment of the present invention includes an integrated development environment (IDE) for providing a development environment to a user, A developer terminal for providing a class file containing the class file; A configuration management system for managing a change history of the class file; A runtime system for updating information upon change by comparing execution line information for each class file and method information converted through a business process and line information for each current method version extracted from the class file through a class analyzer, ; A DBMS for storing execution line information for each method, line information for each method version, and line coverage information; And a test quality management system for calculating line coverage information for each method version by loading the method-specific execution line information and method version-specific line information through a statistical processing process, and updating information stored in the DBMS.

According to another aspect of the present invention, there is provided a method for managing version of a method based on a byte code through a software development system, the method comprising: transferring a class file; (b) redistributing the approved and requested class files; (c) converting the class file and method information through a business process to generate execution line information for each method, extracting and collecting line information for each method version from the class file through a class analyzer; (d) calculating line coverage information for each method version by loading the method-specific execution line information and method version-specific line information through a statistical processing process; And (e) storing execution line information for each method, line information for each method version, and line coverage information.

According to the embodiment of the present invention, in the Java-based software development system, the line coverage information can be managed for each version according to method version information extraction using only class file information, Even if the class file is destroyed, the coverage information of the version can be recovered together with the effect of preventing unnecessary duplication tests from being performed by the developer.

1 is a diagram schematically showing the overall structure of a Java software development system according to an embodiment of the present invention.
2 is a diagram illustrating an entire structure and a process of a Java software development system according to an embodiment of the present invention.
3A is a diagram illustrating a structure of a class file that is a target of a Java software system according to an embodiment of the present invention.
FIG. 3B is a diagram illustrating a structure of an ID calculation process for implementing a byte code-based Java method version management method according to an embodiment of the present invention.
4 is a diagram illustrating a Java software development method according to an embodiment of the present invention.
FIG. 5 is a sequence diagram illustrating a procedure performed between systems of a Java software development system according to an embodiment of the present invention.

Prior to the description, when an element is referred to as being "comprising" or "including" an element throughout the specification, it is to be understood that the element may be further comprised of other elements . Also, terms such as " terminal " and " system " in the specification mean a unit for processing an operation in which one or more functions are combined, , A combination of hardware and software.

Furthermore, the term " embodiment " is used herein to mean serving as an example, instance, or illustration, but the subject matter of the invention is not limited by such example. It is also to be understood that the terms " including, " " having, " and other similar terms are used, but that they do not exclude any additional or different components when used in the claims, Quot; is < / RTI > used in a manner similar to the term " Comprising ".

The various techniques described herein may be implemented with hardware or software, or may be implemented with a combination of both, where appropriate. As used herein, terms such as " system " and the like can likewise be handled as computer-related entities, i.e., hardware, a combination of hardware and software, software or software at runtime. Further, in the present invention, both programs and hardware executed in a system including a terminal can be configured in units of modules, and can be recorded in one physical memory, or distributed among two or more memories and recording media.

Hereinafter, a byte code-based Java method version management method and a Java software development system and method using the same will be described with reference to the drawings.

1 is a diagram schematically showing the overall structure of a Java software development system according to an embodiment of the present invention.

1, the Java software development system 10 of the present invention includes a developer terminal 100, a configuration management system 200, a runtime system 300, a database management system (DBMS) 400, and a test quality management system (500).

The developer terminal 100 refers to a computing device in which an integrated development environment (IDE) tool is installed, and a developer, that is, a user, develops and compiles a predetermined source file using the same.

The configuration management system 200 provides a total management function for status, change, history, and the like of various documents related to the source code and development developed in the developer terminal 100.

The runtime system 300 plays a role of executing source files managed by the CM system and compilation through a business processor.

In particular, the runtime system 300 according to the embodiment of the present invention injects an API for giving a method-specific version ID and writing an execution line to the bytecode through the BCI.

The DBMS 400 stores execution line information for each method, line information for each method version, and line coverage information according to a business process processed in the runtime system 300.

The test quality management system 500 calculates the execution line coverage information for each version of the method using the execution line information for each method stored in the DBMS 400 through the statistical processing process and outputs the latest version of the line coverage information to the user Lt; / RTI > Here, since the line coverage information is managed according to the version of the method, even if the class file is rewritten by the configuration management system 200, the coverage information of the corresponding version can also be restored, so that the developer can prevent unnecessary duplication testing do.

Hereinafter, a method-by-method execution byte code structure in a Java software development system according to an embodiment of the present invention will be described in detail with reference to the drawings.

2 is a diagram illustrating an entire structure and a process of a Java software development system according to an embodiment of the present invention.

Referring to FIG. 2, a Java software development system 10 according to an embodiment of the present invention is a Java software development system using a byte code-based Java method version management method, and includes an integrated development environment (IDE) a developer terminal 100 on which an integrated development environment 110 is installed and providing a class file 130 including method information 131, a configuration management system 100 for managing the change history of the class file 130 Extracted from the class file 130 through the class analyzer 340 and the execution line information 410 for each method for the class file 311 and the method information 312 converted through the business process 310 The runtime system 300, the method-specific execution line information 410, the method version-specific line information 420, and the method version information 420 are compared with the previous version by comparing the current method version- The DBMS 400 that stores the line coverage information 430 and the method execution line information 410 and method version line information 420 are loaded through the statistical processing process 510 to obtain line coverage information And a test quality management system 500 for updating the information stored in the DBMS 400. [

In detail, the developer terminal 100 is a client provided with the IDE 110 or the like, or a computing device providing a personal development environment provided in a cloud environment. For example, the IDE 110 may be an IDE tool such as Eclipse ( ^TM ) provided by an open source-based framework commonly used in SI projects. The IDE 110 automatically builds the source file 120 created by the developer in a background form to generate the class file 130. [

The configuration management system 200 is a system that manages resources distributed between the IDE 110 and the runtime system 300 that executes development and testing. A process management function for a history management, a request and an approval process for a distribution target resource, and the like. In the present invention, the class file 130 to be distributed is managed. .

The runtime system 300 drives a business process 310 for providing a service in the form of a WAS (web application server) or a Java application (JAVA application), and is a system to be developed by the project. The runtime system 300 may be classified into a development, test, and operating environment, and may be a system for testing before deployment in the Java software development system 10.

The runtime system 300 according to the embodiment of the present invention is applied with a byte code instrumentation (BCI) technique for directly modifying the bytecode of the class file 130 to give a desired function without modifying the source file . Accordingly, the business process 310 loads the class file 130 managed by the configuration management system 200 through the BCI process, and outputs the converted class file (for example, 311 and transformed method information 312, respectively.

Here, the bytecode of the converted method information 312 is stored as per-method execution line information 410 in the DBMS 400 by the injected API.

Meanwhile, although the execution line information of each method can be collected through the BCI process described above, if too much processing is included in the process, the operation performance of the business process may be greatly influenced, and a classical analyzer It is preferable to set it so as to collect the execution line information by the method.

That is, the class analyzer 340 may exist in a separate process form or may be included in the business process 310 and processed.

The class analyzer 340 collects execution line information for each method in the method information of the class distributed in the runtime system 300.

The DBMS 400 is a data management middle ware and stores the execution line information 410 for each method, the line information 420 for each method version, and the line coverage information 430.

The test quality management system 500 calculates execution line coverage information for each version of the method using the execution line information for each method stored in the DBMS 400 through the statistical processing process.

The test quality management system 500 may be installed together with the runtime system 300 according to the resource conditions, and may be installed separately and separately in a separate system. In the embodiment of the present invention, the line coverage information 430 is processed by using method-specific execution line information 410 and method version-specific line information 420 in the form of WAS. Process function.

In addition, the test quality management system 500 can provide the user with the latest version of the line coverage information among the line coverage information stored in the DBMS 400. [

FIG. 3A is a diagram illustrating a structure of a class file that is a target of a Java software system according to an embodiment of the present invention. FIG. 3B is an ID calculation process Fig.

Referring to FIG. 3A, in a Java software development system according to an embodiment of the present invention, a class file 130 includes method information 131 therein. Each of the code attributes 134, which is one of attributes of the method information 131, has a method-specific execution byte code {0 to N-1 (N is a natural number)}.

In the Java software development system according to the embodiment of the present invention, a hash ID is calculated by using a predetermined hash function on the execution bytecode, and is used as the version ID of the method. This feature is quite simple in comparison with the method of obtaining version information from a source file, but it can be efficiently produced without complicated processing such as parsing.

However, in the above-described method, there is a limitation that data up to 65,536 bytes (byte) can be read, and it is very susceptible to code changes. In order to overcome this limitation, The development system can further use not only the value of the code property 134 in the method information 131 of the class file 130 but also the source line number table information which is an index reference of the bytecode.

3A and 3B, the method information 131 stores a line number table attribute 135 as an attribute. The first line number of all the line numbers of the source line number table 135 is stored as the method start line number, and the relative value is obtained based on the start line number. As an example, in the case of "10, 12, 16, 18", the method starting line number is "10", and the values of the line number table are "0, 2, 6, 8" The method version information that is not susceptible to code change can be used by calculating the hash ID using the offset value thus calculated and using it as the version ID of the method.

As the ID calculation process 350 for this, the first line number is stored as the method start line number by referring to the line number table attribute of the method information 131, An offset calculator 357 for obtaining a line number table value which is a relative value and a hash generator 358 for calculating a hash ID inserted in the converted method information 312 corresponding to the line number table value. Accordingly, the version ID of the method information is designated by the hash ID.

The ID calculation process 350 described above may be included in the business process or class analyzer of the runtime system.

Hereinafter, a Java software development method according to an embodiment of the present invention will be described with reference to the drawings.

4 is a diagram illustrating a Java software development method according to an embodiment of the present invention.

Referring to FIG. 4, a Java software development method according to an embodiment of the present invention is a method of managing a method version based on byte code through the above-described software development system (10 in FIG. 2) S100), redistributing the approved and requested class file (S110), converting the class file and method information through the business process to generate execution line information for each method, Extracting and collecting information (S120), calculating line coverage information for each method version by loading execution line information for each method and line information for each method version through a statistical processing process (S130) Information, method-specific line information, and line coverage information (S140).

The step of transferring the class file (S100) is a step of transferring the class file in which the IDE of the developer terminal automatically builds in the background to the configuration management system.

The step of reissuing the approved and requested class file (S110) is a step of distributing the class file transferred back to the runtime system by the CM system upon approval and request.

The step (S120) of converting the class file and method information through the business process to generate execution line information for each method and extracting and collecting line information for each method version from the class file through the class analyzer (S120) And converting the method information included therein into a form capable of recording an execution line, generating execution line information for each method, and simultaneously extracting and collecting line information for each method version.

The step S130 of calculating line coverage information for each method version by loading the execution line information for each method and the line information for each method version through the statistical processing process can be performed by the test quality management system, It is a step of calculating line coverage information by method version by loading line information by method version.

Step S140 of storing the execution line information for each method, line information for each method version, and line coverage information includes executing line information for each method, line information for each method version, and line coverage information obtained by the runtime system and the test quality management system And storing it in a storage DBMS. Here, the execution line information for each method and the line information for each method version may be performed after step S130.

Hereinafter, a method of version-based method management based on the bytecode according to the present invention will be described in detail with reference to the accompanying drawings, illustrating a procedure performed between systems constituting a Java software development system according to an embodiment of the present invention.

FIG. 5 is a sequence diagram illustrating a procedure performed between systems of a Java software development system according to an embodiment of the present invention.

Referring to FIG. 5, a source file created in the IDE of the developer terminal 100 by the developer is automatically built in a background form and can be generated as a class file. In accordance with the distribution request of the IDE, The file is transferred to the configuration management system 200 (S200).

The configuration management system 200 distributes the approved class file 130 to the runtime system 300 through the request and approval process (S120).

The runtime system 300 performs the BCI processing procedure through the business process and converts the original class file and the execution line of the method information into the converted class file 311 and converted method information 312 (S230 ). At this time, the bytecode of the converted method information 312 is stored as per-method execution line information in the DBMS 400 by API call (S231).

The runtime system 300 analyzes the distributed class file through the class analyzer of the test quality management tool. The runtime system 300 loads the previous method version information stored in the DBMS 400 (S232) And compares it with the method version information (S233). If the method version is changed (S234), the runtime system 300 initializes the current line coverage information, and stores the line analysis information and the method version information in the DBMS 400 (S235).

Then, the test quality management system 500 loads line analysis information, execution line information for each method, and line information for each method version from the DBMS 400 by a statistical processing process (S240).

Next, the test quality management system 500 calculates line coverage information 430 for each method version (S241). At this time, whether or not the line coverage information is changed is determined (S242), and when changed, the line coverage information is updated and stored in the DBMS (S250).

Thereafter, the latest version information is provided to the user through the UI of the test quality management system 500, the line coverage information stored in the DBMS 400. [

While a great many are described in the foregoing description, it should be construed as an example of preferred embodiments rather than limiting the scope of the invention. Accordingly, the invention is not to be determined by the embodiments described, but should be determined by equivalents to the claims and the appended claims.

100: Developer terminal 110: IDE
200: CM system 300: Runtime system
400: DBMS 500: Test Quality Management System

Claims (11)

A Java software development system using byte code based Java method version management method,
A developer terminal equipped with an integrated development environment (IDE) for providing a development environment to a user and providing a class file including method information;
A configuration management system for managing a change history of the class file;
A runtime system for updating information upon change by comparing execution line information for each class file and method information converted through a business process and line information for each current method version extracted from the class file through a class analyzer, ;
A DBMS for storing execution line information for each method, line information for each method version, and line coverage information; And
And a test quality management system for calculating line coverage information for each method version by loading the method-specific execution line information and method version-specific line information through a statistical processing process, and updating the information stored in the DBMS,
Wherein the runtime system implements a class file distributed from the configuration management system to execute a WAS or Java application,
The business process converts the original class and method information into converted class file and method information that can record the execution line through BCI processing,
The converted class file and method information are stored in the DBMS as execution line information for each method by an API,
The business process and class analyzer,
A first line number is stored as a start line number of a method by referring to a line number table attribute that is an index reference of an bytecode in the method information, and a line number table value An offset calculator for obtaining an offset value; And
And a hash generator for calculating a hash ID corresponding to the line number table value,
And the version ID of the method information is specified by the hash ID. The method according to claim 1,
The developer terminal,
Wherein the compiler generates a class file by automatically building a source file created by the user in the background. The method according to claim 1,
The configuration management system includes:
A Java software development system that redistributes approved class files to the runtime system through a request and approval process. delete delete A method of Java software development based on byte code through a software development system according to claim 1,
(a) transferring a class file;
(b) redistributing the approved and requested class files;
(c) converting the class file and method information through a business process to generate execution line information for each method, extracting and collecting line information for each method version from the class file through a class analyzer;
(d) calculating line coverage information for each method version by loading the method-specific execution line information and method version-specific line information through a statistical processing process; And
(e) storing the execution line information for each method, line information for each method version, and line coverage information
Lt; / RTI >
The step (c)
Executing a WAS or Java application by implementing a distributed class file; And
Converting the original class and method information into converted class file and method information capable of writing an execution line through BCI processing,
The converted class file and method information are stored as execution line information for each method by an API,
The step (c)
Storing a first line number as a method start line number by referring to a line number table attribute that is an index reference of a byte code of the method information;
Obtaining a line number table value which is a relative value based on the start line number; And
And calculating a hash ID corresponding to the line number table value,
And the version ID of the method information is specified by the hash ID. The method according to claim 6,
Before the step (a)
The compiler generates a class file by automatically building a source file created by the user in the background
/ RTI > delete delete The method according to claim 6,
The step (c)
Comparing the line information of the current method version extracted from the class file with the previous version through the class analyzer and updating the line information of each method version stored at the time of the change
The method comprising the steps of: delete

Images