JP4023803B2 - Web application development support apparatus, data processing method, and program - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a method and system for verifying consistency between a component call of a JSP used for a web application or the like and a component.
[0002]
[Prior art]
As a technique used in a web application that provides a service via a network such as the Internet, there is a technique in which a web server dynamically generates a web page using a script language (server-side script language) and transmits it to a client. JSP (JavaServer Pages: trademark of Sun Microsystems, Inc.) is one of these types of server-side script languages, and this function is realized by using Java (trademark of Sun Microsystems, Inc.) ( For example, see Patent Document 1 and Non-Patent Document 1). Specifically, in JSP, processing is described in a script (Java program) in an HTML (HyperText Markup Language) file, the script is executed in response to a client request, and only the processing result is transmitted to the client. .
[0003]
Therefore, a web page file (hereinafter referred to as a JSP page) containing dynamic content by JSP has many languages at the same time, such as a description portion by JSP and a description portion by HTML, regarding the language expressing the dynamic content. is doing. The HTML description realizes layout and control when a web page is displayed on a browser. On the other hand, the description of JSP is a script describing a predetermined process, and operates as a servlet at the time of execution. Then, necessary operations are performed on other components accessible according to the design of the script, and the result of this operation is transmitted to the browser as a response.
[0004]
Here, a component means an object, and a component related to JSP indicates a Java bean, a message resource, another JSP page or a web page on which a JSP page depends.
FIG. 25 is a diagram showing a main component group related to the JSP page.
[0005]
[Patent Document 1]
JP 2002-366514 A
[Non-Patent Document 1]
“JavaServer Pages ^TM DYNAMICALLY GENERATED WEB CONTENT ", [online], [Search May 21, 2003], Internet <URL: HYPERLINK" http://www.cs.hut.fi/~ctl/3dm/ "http: // java .sun.com / j2ee / ja / jsp / ＞
[0006]
[Problems to be solved by the invention]
As described above, a JSP used for a web application or the like accesses a predetermined component and performs a necessary operation at the time of execution. However, in the integration test and the operation test in the actual web application development, since the specification regarding the description contents of the JSP is not predetermined before the development, the component calling part of the JSP page and the component developed by other developers Inconsistency often occurs between the two.
Therefore, conventionally, when developing a web application, the consistency of the description of the JSP page must be confirmed manually by the developer, or an inconsistency can be detected one by one by actually performing an integration test on the application server. Has been done.
[0007]
However, when there are a large number of component call descriptions in the web application, it is not easy to completely detect inconsistencies between the component call of the JSP page and the component.
If such inconsistencies cannot be removed completely, a system may fail even after the web application is running due to inconsistencies that exist in the web application. And if a failure occurs, the entire development will incur extra costs.
[0008]
In addition, it is possible to analyze the consistency between JSP pages and components and automatically verify that tag script expressions freely created by users such as the program logic of Java scriptlets and JSP tag libraries are allowed. Made it difficult.
[0009]
In view of the above problems, an object of the present invention is to provide a method and tool for analyzing and automatically verifying consistency / inconsistency between a JSP page and its related components.
In addition to the above object, the present invention supports JSP page development work by automatically verifying inconsistencies between a JSP page and its related components, and improves and improves the quality of the JSP page. The purpose is to contribute to cost reduction.
[0010]
[Means for Solving the Problems]
The present invention that achieves the above object is realized as a web application development support device configured as follows. This web application development support apparatus monitors the execution of a component call on a web page on which content is dynamically generated, extracts information about the component call, and based on the information about the component call extracted by the monitor And a consistency verification unit that verifies the consistency between the component call and the target component.
[0011]
More preferably, the monitor extracts information related to the component call regardless of whether or not the component call is executed when it is not determined until execution whether or not the predetermined component call is actually executed. . In addition, the consistency verification unit verifies the consistency between the component call and the component by collating the specification information that summarizes information related to the component call preset for each web page with the information extracted by the monitor. To do.
[0012]
Further, this web application development support device analyzes a specification update unit that updates the specification information based on the verification result by the consistency verification unit and a library corresponding to the component call by analyzing information about the library used for the description of the component call. The monitor generation unit for generating the information can be further provided.
[0013]
The present invention can also be realized as a component call monitoring device configured as follows. That is, the component call monitoring device monitors the execution of a request control unit that issues an HTTP request for a web page on which content is dynamically generated, and the component call for generating content on the web page. And a monitor for extracting information related to the call. In addition, the component call monitoring device can further include a monitor generation unit that analyzes information related to the library used for description of the component call and generates a monitor corresponding to the component call.
[0014]
Here, more preferably, the monitor generation unit extracts a library definition file stored in a predetermined storage unit based on an analysis result of information on the library, and extracts information on the component call when executing the component call. By replacing it with a library definition file that includes
[0015]
Another aspect of the present invention that achieves the above object is realized as the following data processing method using a computer. The data processing method includes a first step of analyzing information related to a library used for description of a component call with respect to a component call for generating the content in a web page on which content is dynamically generated, A second step of replacing the library definition file stored in the predetermined storage means with a library definition file including a function of extracting information related to the component call when executing the component call based on the analysis result of the step And a third step of executing a component call using the library definition file replaced by the second step and extracting information on the executed component call.
[0016]
In addition, this data processing method is performed by collating specification information that is pre-set for each web page and storing information related to component invocation stored in a predetermined storage unit with the information extracted in the third step. A fourth step of verifying the consistency between the component call and the target component can be included. Furthermore, it is possible to include a fifth step of updating the specification information stored in the predetermined storage means based on the verification result in the fourth step.
[0017]
Furthermore, the present invention is also realized as a program that controls a computer to function as the above-described web application development support device or component call monitoring device, or a program that causes a computer to execute processing corresponding to each step of the data processing method. Is done. This program can be provided by being stored and distributed in a magnetic disk, an optical disk, a semiconductor memory, or other recording media, or distributed via a network.
[0018]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, the present invention will be described in detail based on embodiments shown in the accompanying drawings.
The present invention uses a method for dynamically verifying whether a developed JSP page is correctly developed by causing a JSP page to be verified to be test-executed. Regarding the JSP description expression, the expression based on the JSP tag library description is to be verified. The JSP tag library performs tag-based description for the description of the JSP page.
[0019]
In this embodiment, component call information corresponding to the specification for verification is defined for the JSP page to be developed.
FIG. 1 is a diagram showing a configuration of component call information defined in the present embodiment.
As shown in FIG. 1A, the component call information includes component name, component type, component attribute, and scope information regarding the component to be called. The component name is a name used when a component is called using the attribute of the JSP tag description. The component type is the type of the component to be called, such as a JSP bean, a message resource, or another JSP page. The component attribute is information used when an attribute is required for component invocation such as when the component is nested. The scope is information used to specify a session scope, a request scope, and the like.
[0020]
In the present embodiment, a component call information table as shown in FIG. 1A is generated for the JSP tag description in the JSP page, and the component call information is managed. For example,
<bean: message key = "title.welcome"/>
For the JSP tag description, a component call information table as shown in FIG. 1B is generated. Also,
<bean: write name = "user" property = "username" scope = "session" filter = "true"/>
For the JSP tag description, a component call information table as shown in FIG. 1C is generated.
[0021]
Incidentally, a plurality of JSP tag descriptions can exist in one JSP page. Therefore, the above component call information is managed collectively for each JSP page. A set of component call information tables for each JSP page is called a JSP page specification description.
FIG. 2 is a diagram illustrating an example of a JSP specification description.
As shown in the figure, each component call information of a JSP page has “inevitability” information indicating whether the description in the JSP page is essential (true if necessary, false if not essential).
[0022]
In this embodiment, the consistency between the description of the JSP page and the called component is verified using the component call information defined as described above. The above-mentioned JSP specification description is created in advance before executing verification according to the present embodiment. The component call information and the JSP specification description only need to include information effective for verifying the consistency between the JSP page and the related component in a certain format, and are not necessarily shown in FIGS. It is not limited to the configuration.
[0023]
FIG. 3 is a diagram schematically illustrating an example of a hardware configuration of a computer device that realizes the web application development support device according to the present embodiment.
The computer apparatus shown in FIG. 3 includes a CPU (Central Processing Unit) 101 which is a calculation means, a main memory 103 connected to the CPU 101 via an M / B (motherboard) chipset 102 and a CPU bus, Similarly, a video card 104 connected to the CPU 101 via the M / B chipset 102 and AGP (Accelerated Graphics Port), and a hard disk 105 connected to the M / B chipset 102 via a PCI (Peripheral Component Interconnect) bus, A network interface 106, a floppy disk drive 108 and a keyboard / mouse 109 connected to the M / B chipset 102 from the PCI bus through a low-speed bus such as a bridge circuit 107 and an ISA (Industry Standard Architecture) bus. Prepare
Note that FIG. 3 merely illustrates the hardware configuration of the computer apparatus that implements the present embodiment, and various other configurations can be employed as long as the present embodiment is applicable. For example, instead of providing the video card 104, only the video memory may be mounted and the image data may be processed by the CPU 101. As an external storage device, ATA (AT Attachment), SCSI (Small Computer System Interface), or the like may be used. A CD-R (Compact Disc Recordable) or DVD-RAM (Digital Versatile Disc Random Access Memory) drive may be provided via the interface.
[0024]
FIG. 4 is a diagram showing a functional configuration of the web application development support apparatus according to the present embodiment.
Referring to FIG. 4, the web application development support apparatus according to the present embodiment performs an HTTP (HyperText Transfer Protocol) request to perform a test execution of a JSP page, and a component of the executed JSP page. A monitor 20 that monitors the call, a consistency verification unit 30 that verifies the consistency between the description of the JSP page and the callee component based on the monitoring result by the monitor 20, and the JSP specification description of the JSP page that is the verification target A stored JSP specification description storage unit 40 and a monitor generation unit 50 that generates the monitor 20 are provided.
[0025]
The request control unit 10, the monitor 20, the consistency verification unit 30, and the monitor generation unit 50 shown in FIG. 4 are realized by the program-controlled CPU 101 in FIG. 3, for example. Function block It is. A program that controls the CPU 101 to realize these functions can be provided by being stored and distributed in a magnetic disk, optical disk, semiconductor memory, or other recording medium, or distributed via a network. The JSP specification description storage unit 40 is realized, for example, by the main memory 103 or the hard disk 105 in FIG. In the present embodiment, a JSP unit test web application for executing a test on a JSP page to be verified is prepared, and the JSP page is executed in response to an HTTP request from the request control unit 10. As shown in FIG. 4, among the above components, the monitor 20 and the consistency verification unit 30 are realized as functions of a JSP unit test web application for performing a test on a JSP page to be verified.
[0026]
In the present embodiment, the expression based on the JSP tag library description is to be verified. Some JSP tag libraries are disclosed as libraries, but can be freely developed by users. Therefore, in order to extract calls to all JSP tag libraries, it is necessary to generate a monitor 20 that can monitor component calls for unsupported JSP tag libraries. In the present embodiment, a monitor generation unit 50 is prepared to automatically generate a necessary monitor 20 prior to JSP verification.
[0027]
FIG. 5 is a diagram illustrating the function of the monitor generation unit 50, and FIGS. 6 and 7 are flowcharts illustrating the operation of the monitor generation unit 50.
Referring to FIG. 5, the monitor generation unit 50 inputs JSP tag library-related resources such as a tag library definition file and a tag handler class source code from predetermined storage means (for example, the main memory 103 and the hard disk 105 in FIG. 3), Analyzes the call target component and input parameters. Then, a resource related to the monitor 20 such as a source code of a tag handler class having a function of extracting an input parameter for operating a related component and a tag library definition file in which the monitor 20 is mounted is output. That is, the JSP tag library-related resource used for describing the component call in the JSP page is replaced with a JSP tag library-related resource including the function of the monitor 20 that extracts information related to the component call when the component call is executed.
[0028]
With reference to FIG. 6, a tag library analysis process by the monitor generation unit 50 for obtaining a component call type determination and related attributes will be described.
As shown in FIG. 6, the monitor generation unit 50 first designates a web application path including a tag library to be monitored by the monitor 20 (step 601). Then, from the specified web application path, WEB-INF / web. An xml file is input (step 602), and the paths of all tag library definition files are read to create a list (step 603). FIG. 8A shows an example of a list of paths to be created.
[0029]
Next, the monitor generation unit 50 inputs a predetermined tag library definition file (step 604), and reads a predetermined tag handler definition in the input tag library definition file (step 605). An example of the read tag handler definition is shown in FIG.
Next, the monitor generation unit 50 reads the tag handler class source file from the tag library definition file input in step 604 (step 606). Then, an attribute analysis process related to the component call type determination is performed (step 607). This process will be described later with reference to FIG.
[0030]
After the analysis process in step 607, the monitor generation unit 50 generates a source file of a tag handler class that implements the monitor function based on the result of the process (step 608). The processes in steps 605 to 608 are executed for all tag handler definitions included in the tag library definition file input in step 604 (loop 2).
[0031]
Next, the monitor generation unit 50 generates a tag library definition file that calls the monitor function tag library based on the tag library definition file that has been subjected to the above processing for all tag handler definitions (step 609). The processing in steps 604 to 609 is executed for all tag library definition files included in the list created in step 603 (loop 1).
[0032]
Next, the source code analysis of the JSP tag handler class in step 607 will be described with reference to FIG. In this analysis processing, which attribute is related to the component call is analyzed based on the attribute acquired from the tag library definition file.
The monitor generation unit 50 first acquires all the attributes in the tag handler to be analyzed (step 701). In the example shown in FIG. 8B, attributes {filter, ignore, name, property, scope} are acquired.
[0033]
Next, the monitor generation unit 50 acquires local variable names for all the attributes acquired in step 701 (step 702). This local variable name is usually the same as the attribute name. If the local variable name does not match the attribute name, it can be inferred from the getter method.
Next, the monitor generation unit 50 searches for a public int doStartTag () method based on the acquired local variable name (step 703), and further searches for a public int doEndTag () method (step 704).
[0034]
In JSP, component operations existing in various scopes are normally performed by calling a getAttribute (name, pageContext.APPLICATION_SCOPE) method and a pageContext.findAttribute (name) method as methods of the PageContext object. Therefore, the monitor generation unit 50 next searches for these method calls. If these method calls do not exist, the tag handler class does not generate a tag handler class that implements the monitor function, and ends the analysis process (steps 705 and 709).
[0035]
On the other hand, when the method call of the getAttribute (name, pageContext.APPLICATION_SCOPE) method and the pageContext.findAttribute (name) method exists in the tag handler, the monitor generation unit 50 uses the USE-DEF chain algorithm in the data flow analysis. Based on the definition reference relationship of the variable representing the attribute, the attribute corresponding to which attribute of the tag handler is used for the argument in the name variable part which is the method argument (steps 705 and 706). If a predetermined attribute can be derived, for example, the possibility of accessing a component can be found using the value of the attribute in the JSP tag description.
[0036]
Next, the monitor generation unit 50 determines the component type (step 707). The determination of the component type is determined by which type the object that is the return value of the above method has. The correspondence between the object type of the return value and the component type is represented by a component type determination table.
FIG. 9 is a diagram illustrating a configuration example of the component type determination table.
In the component type determination table shown in FIG. 9, the return value type of getAttribute () / findAttribute () is associated with the component type, the location of the attribute variable, and the attribute name defined in the Tld file. In the illustrated example, for example, when the return value type of the method is a message resource type, the component is determined to be a message component. As a specific example, in the case of the following description, the component type is determined to be a JSP bean.
Object object = pageContext.findAttribute (name);
In the case of the following description, the component type is determined to be a message resource.
MessageResources resource =
(MessageResources) pageContext.getAttribute (bundle, pageContext.APPLICATION_SCOPE);
String messageValue = resource.getMessage (key);
The correspondence between the object type and the component type shown in the component type determination table is determined by the target JSP tag library. Therefore, this correspondence needs to be given prior to the execution of the analysis process.
[0037]
Also, there may be branch logic in the tag handler that cannot be analyzed as to whether the component call is actually performed. In this case, it is impossible to determine whether or not the component is actually called unless the tag handler is executed. Therefore, a logic for extracting the component call information is added immediately after the component call part. Thus, the called component call information can be transmitted when the tag handler is executed.
FIG. 10 is a diagram illustrating an example in which the logic of component call information is added to the code of the branch logic in the tag handler.
[0038]
After the above analysis, the monitor generation unit 50 generates a tag handler that implements the monitor function based on the attribute name obtained by this analysis and the component type (step 708). Then, as described above, a class source file is generated from the tag handler which is the analysis result, and a tag library definition file for calling the monitor function tag library is generated (see steps 608 and 609 in FIG. 6).
FIG. 11 is a diagram illustrating an example of a source code of a tag handler class that implements a monitor function, and FIG. 12 is a diagram illustrating an example of a tag library definition file that calls a monitor function tag library.
[0039]
FIG. 13 is a diagram for explaining the difference between a normal tag handler call and a monitor 20 call in relation to the tag library definition file.
In the example of FIG. 13, the URL for calling the tag library declared in the JSP page
<bean: write name = "username"… />
From the description, web. When mapping the URL described in xml (web application) and the tag library definition file, in the case of a normal call, from the description of the tag rib
/WEB-INF/struts-bean.tld
Calls “struts-bean.tld” and “WriteTag” is called from the tag handler definition described in the tag library definition file.
On the other hand, after the monitor function is implemented, web. When mapping the URL described in xml to the tag library definition file,
/WEB-INF/monitor.tld
“Monitor.tld” is called, and “MonitorWriteTag” is called from the tag handler definition described in the tag library definition file.
As described above, the function of the monitor 20 is called by changing the operating environment of the web application (tag library definition file and web.xml) without changing the description of the JSP page.
[0040]
Incidentally, the monitor generation unit 50 associates the attribute received from the tag handler with the component call in order to generate the monitor 20, but the normal analysis described above cannot guarantee whether the component call itself is reliably executed. There is a case. Such cases are summarized below.
[0041]
1. When the appearance of a component call type is determined by branch logic.
The tag handler class can describe branch logic under various conditions as Java logic. For example, a component can be called by date or time, or a component can be called by the behavior of an object with business logic. Further, the tag library of the framework called Struts has a logic of extracting a component as a message resource if the component does not exist in the session scope. In this logic, the component type to be acquired changes depending on whether the component is a session scope or the message resource.
In order to determine such logic, it is necessary to operate on a test application in which resources capable of executing branch logic are individually prepared by the test environment.
[0042]
2. When a tag handler that cannot detect an operation on the PageContext object is used.
In the tag handler, the attribute value may not be used for the operation of the PageContext object, or the description of the PageContext object may not be analyzed. Such tag handlers often do not make component calls, but may be affected by component calls of nested tag handlers. For example, the Struts tag library has a logic tag handler, and a nested tag handler may not be called depending on the value of an attribute of a JSP tag description using logic.
[0043]
In the above two cases, even if the “necessity” for the component call information in the JSP specification description is true, it cannot be guaranteed by static analysis that the call is always made when the JSP page is executed. Therefore, it is necessary to dynamically execute the JSP page to make a component call.
[0044]
With the function of the monitor generation unit 50 described above, as shown in FIG. 4, the necessary monitor 20 is mounted in the JSP unit test web application. As described above, the generation of the monitor 20 by the monitor generation unit 50 is performed prior to verification of the JSP page. The JSP page verification itself is executed by the request control unit 10, the generated monitor 20, and the consistency verification unit 30. Further, in order to verify the JSP page, the JSP specification description shown in FIG. 2 for the JSP page to be verified is created in advance and stored in the JSP specification description storage unit 40.
[0045]
The request control unit 10 acquires a URL (Uniform Resource Locators) list for executing a JSP page, adds a parameter componentInvoke = true, and transmits the list to the JSP unit test web application. The URL list is a collection of URLs of JSP pages to be tested, and is prepared in advance by a developer of a JSP page (web application). It is also possible to automatically generate a URL list by selecting a JSP page group to be verified using a tool capable of editing a set of JSP pages.
[0046]
FIG. 14 is a flowchart for explaining the operation of the request control unit 10.
Referring to FIG. 14, the request control unit 10 reads the URL list prepared as described above (step 1401), and transmits an HTTP request to a predetermined URL in the URL list (step 1402). . At this time, a parameter “componentInvoke = true” is added to the HTTP request. When receiving an HTTP response that is a response to the HTTP request, the request control unit 10 checks whether or not there is a JSP compilation error in the HTTP response (steps 1403 and 1404). If a JSP compilation error has not occurred, the process for the URL ends.
[0047]
On the other hand, if a JSP compilation error occurs as a result of the HTTP request using this URL list and an error result is returned as an HTTP response, the request control unit 10 adds a parameter of componentInvoke = false and sends an HTTP request again. Transmit (step 1405). There is a high possibility that the JSP compilation error is inconsistent in the relation between the JSP tag description and the component. Therefore, by performing the transmission again, the JSP unit test application performs dummy execution that does not execute the component call but gives a dummy result to the call part, and receives an HTTP response (step 1406). The dummy execution will be described later.
The above steps 1402 to 1406 are executed for all URLs in the URL list read in step 1401 (loop).
[0048]
The JSP unit test web application has a JSP page developed by the developer and components that can be executed by the test. The tag library definition file and the program logic correspond to the HTTP request issued from the request control unit 10. JSP pages can be called via an HTTP servlet. In addition, a monitor 20 generated by the monitor generation unit 50 and a consistency verification unit 30 for verifying the consistency between the JSP page and the component are mounted. Further, as shown in FIG. 13, in the JSP tag description of the JSP page, the JSP tag handler call is replaced with a call to the monitor 20.
[0049]
The monitor 20 is called along with the test execution of the JSP page, and monitors component calls by the JSP.
FIG. 15 is a flowchart for explaining the operation of the monitor 20.
Referring to FIG. 15, the monitor 20 first extracts component call information in the JSP page that is the target of the HTTP request (step 1501). Then, the consistency verification unit 30 is called, and the component call information extracted in step 1501 is passed to the consistency verification unit 30 together with the JSP page name that can be acquired from the HTTP request name (step 1502).
[0050]
Next, the monitor 20 refers to the parameter componentInvoke in the HTTP request from the request control unit 10 (step 1503). When the value is true, the JSP tag handler in the original JSP tag description (in the call to the monitor 20) The component call is actually executed for the JSP tag handler before replacement (step 1504). Then, the component call information in the component call is sent to the consistency verification unit 30. Further, the result of the component call is returned to the JSP page as will be described later.
[0051]
On the other hand, when the value of the parameter componentInvoke is “false”, the monitor 20 performs dummy execution without calling the component, and returns the dummy result to the JSP page as the result of the component call (step 1505). In this case, a character string “dummy” is returned as the actual processing result in the JSP tag description part. In addition, when a branch process that cannot be determined unless the tag handler is actually executed is related to the component call, only the call information for all components is obtained by the logic added immediately after the component call part in the monitor generation unit 50. Are extracted and sent to the consistency verification unit 30.
[0052]
FIG. 16 is a diagram for explaining the operation of the monitor 20 in response to a component call. In the example of this figure, it is assumed that components A and B are called.
In FIG. 16, when the class in which the monitor 20 is implemented (hereinafter, the monitor implementation class) is called as the JSP page is executed, if the value of componentInvoke is true, the monitor implementation class changes to the tag handler class. The doStart () method call is returned. Then, the corresponding components A and B are called by the method call operation during the execution of the tag handler class. On the other hand, when the value of componentInvoke is false, components A and B are not called, only the component call information is extracted, and a character string “dummy” is used instead of a method call from the monitor implementation class to the tag handler class. returned.
[0053]
The consistency verification unit 30 verifies the consistency between the component call and the component based on the component call information obtained by the monitor 20 described above.
FIG. 17 is a diagram illustrating a configuration of the consistency verification unit 30.
Referring to FIG. 17, the consistency verification unit 30 includes a call information verification unit 31 that verifies component call information, a result description generation unit 32 that generates a component call verification result in a JSP page in a predetermined description format, and a result. A verification result log output unit 33 that outputs a log of the verification result created by the description creation unit 32, and a specification update unit 34 that updates the JSP page specification description as necessary.
[0054]
The call information verification unit 31 inputs the component call information extracted by the monitor 20, refers to and compares the specification description of the JSP page stored in the JSP specification description storage unit 40, and verifies the consistency.
18 and 19 are flowcharts illustrating the flow of processing by the call information verification unit 31.
As shown in FIG. 18, when the call information verification unit 31 obtains the JSP page name and component call information extracted from the test-executed JSP page by the monitor 20 (step 1801), first, the JSP specification description storage unit 40 is checked to see if there is a JSP specification description corresponding to the acquired JSP name (step 1802). If there is no corresponding JSP specification description, the component call in the JSP page and the component that is the call target are inconsistent, so the call information verification unit 31 displays the verification result of inconsistency as the result description creation unit 32. (Step 1803).
[0055]
When the JSP specification description corresponding to the acquired JSP name is stored in the JSP specification description storage unit 40, the call information verification unit 31 is then registered in the JSP specification description from the JSP specification description storage unit 40. A list of component call information (component name) is acquired (FIG. 19, step 1804). Then, it is checked whether or not the component name of the component call information extracted by the monitor 20 exists in the list (step 1805). If the same component name does not exist, since the component call in the JSP page and the component that is the call target are inconsistent, the call information verification unit 31 notifies the result description creation unit 32 of the verification result of inconsistency. (Step 1803).
[0056]
When the component call information in the JSP specification description has the same component name as the component call information extracted by the monitor 20, the call information verification unit 31 next reads the JSP specification from the JSP specification description storage unit 40. The component call information in the description is acquired (step 1806). Then, regarding the acquired component call information and the component call information extracted by the monitor 20, whether the component type is the same (step 1807), and if the attribute of the component is described, whether the attribute value is the same (step 1808, 1809), if scope information is described, it is checked whether the scopes are the same (steps 1810, 1811). If any of the component type, attribute value, or scope is different, the component call in the JSP page and the component that is the call target are inconsistent, so the call information verification unit 31 displays the verification result as inconsistency. The result description creating unit 32 is notified (step 1803).
[0057]
On the other hand, if the attribute value or scope when the component type, attribute, or scope information is described is the same, the call information verification unit 31 registers the component call in a description omission extraction list to be described later. (Step 1812). Then, the verification result of matching is notified to the result description creating unit 32 (step 1813).
[0058]
In addition, the call information verification unit 31 checks a description omission error item when the component call extraction is completed for each JSP page in the monitor 20.
FIG. 20 is a flowchart for explaining the flow of processing for detecting a description omission error item by the call information verification unit 31.
Referring to FIG. 20, the call information verification unit 31 first reads a JSP specification description from the JSP specification description storage unit 40, and reads the description omission extraction list created in step 1812 of FIG. 19 (steps 2001 and 2002). . Then, attention is sequentially paid to each component call information in the JSP specification description of the JSP page to be verified (that is, corresponding to the list) (step 2003), and the verification result corresponding to the component call information exists in the description omission extraction list. It is checked whether or not (step 2004).
[0059]
The processes in steps 2003 and 2004 are performed on all component call information in the JSP specification description of the JSP page to be verified (loop). If there is at least one component call information that does not exist in the description omission extraction list, the result description creating unit 32 is notified that there is an omission error in the JSP page to be verified at that time. Then, the process ends (step 2005).
[0060]
The result description creation unit 32 creates a call result description based on the verification result of the call information verification unit 31. The call result description is a summary of the component call information obtained as a result of verification in JSP page units, whether it is consistent or inconsistent and the reason for inconsistency (no JSP page exists, attributes are unknown, etc.), description Includes information such as leaks. FIG. 21 is a diagram illustrating an example of a call result description. In the example illustrated in FIG. 21, the component call information extracted by the monitor 20 and the verification result by the call information verification unit 31 are described in the call result description. Also, an identification number for this verification result is given.
[0061]
The verification result log output unit 33 outputs verification result log information based on the call result description created by the result description creation unit 32, displays the log information on a predetermined display device, for example, and displays a JSP page (Web Application developer). FIG. 22 is a diagram illustrating a display output example of log information of the verification result. In FIG. 22, a check box at the right end is used for designating which JSP page (JSP file) is to be updated in a specification update process described later.
[0062]
The developer can confirm the output verification result, and can correct the JSP tag description of the JSP page based on the verification result regarding the inconsistent portion. Furthermore, in this embodiment, the inconsistent part obtained from the verification result can be reflected in the JSP page specification description as a correct JSP tag description. In this case, the developer specifies the identification number of the verification result of the JSP page that is inconsistent and the information on the necessity (true or false), and requests the specification update unit 34 to update the JSP specification description.
[0063]
The specification update unit 34 receives the above update request and updates the JSP specification description of the JSP page that is the target of the request.
FIG. 23 is a flowchart for explaining the operation of the specification update unit 34.
Referring to FIG. 23, upon receiving the update request (step 2301), the specification update unit 34 specifies component call information to be updated based on the identification number included in the update request (step 2302). Then, the JSP specification description of the corresponding JSP page is read from the JSP specification description storage unit 40 (step 2303).
[0064]
Next, the specification update unit 34 deletes or adds a description of a desired item in the JSP specification description according to the content of the update request (steps 2304, 2305, and 2306). Then, the JSP specification description whose description content has been changed is stored in the JSP specification description storage unit 40 (step 2307).
As described above, the contents of the component call information extracted by the monitor 20 are reflected in the JSP specification description of the corresponding JSP page.
[0065]
Next, a JSP page verification process by the web application development support apparatus of the present embodiment configured as described above will be described.
FIG. 24 is a flowchart for explaining the overall flow of JSP page verification processing by the web application development support apparatus of this embodiment.
As shown in FIG. 24, first, an HTTP request is issued by the request control unit 10 using a URL prepared in advance (step 2401). This HTTP request is processed by the tag library definition file and the program logic in the JSP unit test web application, and the JSP page corresponding to the HTTP request is called (step 2402). Then, the content dynamically generated by the JSP page is returned to the request control unit 10 as an HTTP response.
[0066]
On the other hand, when the JSP page is called, the monitor 20 extracts component call information related to the component call executed by the tag handler based on the tag description of the JSP page (step 2403). Then, the extracted component call information is collated with the JSP specification description that is set in advance and stored in the JSP specification description storage unit 40 by the consistency verifying unit 30, so that the component call and its target are obtained. Consistency with the component is verified (step 2404).
[0067]
The developer of the JSP page (web application) can refer to the verification result and select whether to correct the mismatched portion of the JSP page that is the verification target or to update the JSP specification description as a countermeasure. . When updating the JSP specification description, the specification update unit 34 of the consistency verification unit 30 updates the description content of the JSP specification description to the content of the component call information extracted by the monitor 20 on condition that the update request is input. (Steps 2405 and 2406).
[0068]
【The invention's effect】
As described above, according to the present invention, it is possible to analyze and automatically verify consistency / inconsistency between a JSP page and its related components.
In addition, according to the present invention, by verifying consistency / inconsistency between a JSP page and its related components, the JSP page development work is supported, contributing to improvement in the quality of the JSP page and reduction in development cost. can do.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of component call information defined in the present embodiment.
FIG. 2 is a diagram showing an example of a JSP specification description used in the present embodiment.
FIG. 3 is a diagram schematically illustrating an example of a hardware configuration of a computer device that realizes a web application development support device according to the present embodiment;
FIG. 4 is a diagram showing a functional configuration of a web application development support apparatus according to the present embodiment.
FIG. 5 is a diagram for explaining functions of a monitor generation unit according to the present embodiment.
FIG. 6 is a flowchart illustrating an operation of a monitor generation unit according to the present embodiment.
FIG. 7 is a flowchart for explaining the operation of the monitor generation unit in the present embodiment, and is a flowchart for explaining tag library analysis processing for obtaining a component call type determination and related attributes.
8 is a diagram showing information used in the processing of FIG. 7. FIG. 8A is a diagram showing a list of tag library definition file paths, and FIG. 8B is a diagram showing tag handler definitions. is there.
FIG. 9 is a diagram showing a configuration example of a component type determination table used in the present embodiment.
FIG. 10 is a diagram illustrating an example in which component call information logic is added to a branch logic code in a tag handler.
FIG. 11 is a diagram illustrating an example of a source code of a tag handler class that implements a monitor function.
FIG. 12 is a diagram showing an example of a tag library definition file for calling a monitor function tag library.
FIG. 13 is a diagram for explaining a difference between a normal tag handler call and a monitor call in relation to a tag library definition file.
FIG. 14 is a flowchart illustrating an operation of a request control unit in the present embodiment.
FIG. 15 is a flowchart illustrating the operation of the monitor in the present embodiment.
FIG. 16 is a diagram for explaining an operation of a monitor for a component call.
FIG. 17 is a diagram showing a configuration of a consistency verification unit in the present embodiment.
FIG. 18 is a flowchart illustrating a process flow by a call information verification unit according to the present embodiment.
FIG. 19 is a flowchart illustrating a processing flow by a call information verification unit according to the present embodiment.
FIG. 20 is a flowchart for explaining a flow of processing for detecting a description omission error item by a call information verification unit according to the present embodiment;
FIG. 21 is a diagram illustrating an example of a call result description generated by a result description creation unit of a call information verification unit;
FIG. 22 is a diagram illustrating a display output example of verification result log information by a verification result log output unit of a call information verification unit;
FIG. 23 is a flowchart for explaining the operation of the specification updating unit in the present embodiment.
FIG. 24 is a flowchart for explaining the overall flow of JSP page verification processing by the web application development support apparatus of the embodiment;
FIG. 25 is a diagram showing a main component group related to a JSP page.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 10 ... Request control part, 20 ... Monitor, 30 ... Consistency verification part, 31 ... Call information verification part, 32 ... Result description creation part, 33 ... Verification result log output part, 34 ... Specification update part, 40 ... JSP specification description Storage unit, 50 ... monitor generation unit, 101 ... CPU, 103 ... main memory, 105 ... hard disk

Claims (6)

A component that extracts information related to the component call when a component call for generating the content is executed on a web page where the content is dynamically generated , and whether or not the component call is actually executed is not determined until runtime A monitor implemented by a program-controlled CPU that extracts information regarding the component call as dummy data is called instead of the component to be called when the component call is not executed with respect to the call ;
By reading out the specification information that summarizes the information related to the component call preset for each web page from a predetermined storage unit, the specification information and the information related to the component call extracted by the monitor are collated, A consistency verification unit realized by a program-controlled CPU that verifies the consistency between the component call and the component that is the target of the component call, and outputs a verification result by a predetermined output device ;
An update request for updating information related to a specific component call out of the specification information input by a user using a predetermined input device according to the output verification result is received and stored in the storage unit A specification update unit realized by a program-controlled CPU that updates the content of information related to the component call specified in the update request in the specification information to the content of the information extracted by the corresponding monitor; A web application development support device comprising: When the consistency verification unit collates the information related to the component call based on the dummy data extracted by the monitor with the specification information, the information related to the component call other than the type of the component to be called The web application development support apparatus according to claim 1 , wherein the web application is collated with the specification information. When a component call for generating the content in a web page on which content is dynamically generated is executed, the computer extracts information about the component call and whether it is actually executed or not until execution time. For the component call that is not determined, extracting the information about the component call as dummy data is called instead of the component to be called when the component call is not executed ;
The computer reads specification information that summarizes information related to the component call preset for each web page from a predetermined storage unit, and collates the specification information with the extracted information related to the component call. Verifying the consistency between the component call and the component that is the target of the component call, and outputting a verification result by a predetermined output device ;
The computer receives an update request for updating information related to a specific component call out of the specification information input by a user using a predetermined input device in accordance with the output verification result, and the storage unit Updating the content of the information related to the component invocation specified in the update request in the specification information stored in the specification information to the content of the corresponding information in the extracted information. Method. On the computer,
A component that extracts information related to the component call when a component call for generating the content is executed on a web page where the content is dynamically generated , and whether or not the component call is actually executed is not determined until runtime Regarding the call, when the component call is not executed , a process of extracting information about the component call as dummy data is called instead of the component to be called ; and
The computer reads specification information that summarizes information related to the component call preset for each web page from a predetermined storage unit, and collates the specification information with the extracted information related to the component call. Processing for verifying the consistency between the component call and the component that is the target of the component call, and outputting a verification result by a predetermined output device ;
The computer receives an update request for updating information related to a specific component call out of the specification information input by a user using a predetermined input device in accordance with the output verification result, and the storage unit A program for executing processing for updating the content of the information related to the component call specified in the update request in the specification information stored in the specification information to the content of the corresponding information in the extracted information . Computer
Means for executing a component call to generate the content in a web page on which the content is dynamically generated;
When a component call is executed, information related to the component call is extracted, and regarding a component call whose execution is not determined until execution time, if the component call is not executed, Instead , means for extracting information about the component invocation as dummy data has been invoked ,
By reading out the specification information that summarizes the information related to the component call set in advance for each web page from a predetermined storage unit, by comparing the specification information with the extracted information related to the component call, Means for verifying consistency with the component that is the target of the component call, and outputting a verification result by a predetermined output device ;
An update request for updating information related to a specific component call out of the specification information input by a user using a predetermined input device according to the output verification result is received and stored in the storage unit As means for updating the content of the information related to the component call specified in the update request in the specification information to the content of the corresponding information in the extracted information,
A program characterized by functioning. In the means for verifying the consistency between the component call and the component, when the information on the component call based on the dummy data is compared with the specification information, the type of the component to be called out of the information on the component call 6. The program according to claim 5 , which causes the computer to execute a process of collating information other than the above with the specification information.

Images