JP2005122398A - Dynamic document generating program, recording medium thereof, dynamic document generating device, and dynamic document generating method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently check a dynamic document generation system to be checked, after source configuration of the system has been added or altered, even for a system that dynamically generates an HTML document or an XML document and sends it back to a user's Web browser at according to the request that he puts out from the Web browser. <P>SOLUTION: The rule data for checking a dynamic document generation source file are divided into data which are applicable to all groups in common and data which are applicable by groups according to the purpose, and are stored in a storage device; and corresponding rules of the rule data are allocated by the groups by the purposes and a dynamic document generation source file to be checked is checked, according to the rule data allocated by groups according to the purpose of the dynamic document generation source file. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to dynamic document generation, and in particular, in a system that dynamically generates an HTML document or an XML document in response to a request issued by a user from a Web browser and sends it back to the user's Web browser. The present invention relates to a technique for inspecting a source file that generates a document or an XML document in a system development / maintenance phase.

In a business transaction system, an electronic catalog system, an information dispatch system, etc. that use a Web server, it is common to dynamically generate HTML and present it to the user according to the request that the user issues from the Web browser. . In that case, there are Java Server Pages (JSP), eXtensible Markup Language (XML), ColdFusion Markup Language (CFML), and the like as languages for creating a dynamic document generation source file. (Java is a registered trademark of Sun Microsystems, Inc., and ColdFusion is a registered trademark of Macromedia, Inc., USA)
Conventionally, in the dynamic document generation system as described above, the dynamic document generation source file and the dynamically generated document are dealt with by visual check. However, there are many cases in which check items are leaked only by visual check, so HTML that returns as a response when actually operating from a Web browser using Weblint's HTML grammar checker provided by WebFile, etc. It has also become possible to automate the checking of HTML generated for dynamic documents by performing the grammar check.

  However, in a conventional dynamic document generation system, only a syntax error in HTML as a result of executing a dynamic HTML source was known. Therefore, from the syntax error in the resulting HTML (for example, there is no tag that must be described or the tag description order is incorrect), to determine where the problem is in the original source description, Knowledge about the grammar of each source description language (for example, JSP, CFML) and the conversion procedure to HTML is required. Furthermore, the person in charge of the check must guarantee whether or not all conditions under which the dynamic document generation system operates are checked.

  On the other hand, even in the case of checking a program file, for example, a logical error that is not caught by a syntax check, for example, cannot be satisfactorily checked by a program after machine debugging. For this reason, the compiler can perform program checks according to externally input rules, so that logic checks other than syntax and format checks can be performed, and program checks can be performed using additional rules specified by the user. A program check method (see, for example, Patent Document 1) is disclosed.

  In addition, as a versatile source program check system that can check source programs efficiently, it analyzes the rule file that stores the necessary constraint conditions in a rule and the constraint conditions that are input from this rule file. And a means for expanding into the rule table, and a source program having means for checking the source program to be checked based on the constraint condition expanded in the previous rule table and outputting an error message for a portion that does not satisfy the constraint condition A technique related to the general-purpose check system is disclosed (for example, see Patent Document 2).

Therefore, when the compiler technology disclosed in Patent Document 1 and Patent Document 2 is applied to a conventional dynamic document generation system, several test patterns are prepared and a document generated by each test pattern is checked. Instead of checking the source for generating the document, it becomes possible to directly find the defective part in the document generation source from the check result. In addition, by preparing a rule that can check all assumed cases as a check rule, problems relating to completeness can be improved.
JP 63-263545 A JP-A-8-1017871

However, if the techniques disclosed in Patent Document 1 and Patent Document 2 are simply applied to a conventional dynamic document generation system, the following problems still occur.
(1) Since the same rule is applied to all source files, the efficiency of the rule application work is poor.

  Examples of check rules related to dynamic HTML sources include the following.

(A) Whether there is a description required in the source (b) Whether there is a description that should not appear in the source (c) If a certain expression A appears in the source, it is necessary along with it (D) If a certain expression A appears in the source, whether or not there is a description that should not be described in the current Web browser, there is incompatibility by vendor and version / level In addition, with the diversification of Web terminals (for example, mobile phones and information appliances) and the advancement of Web technology, the number of these rules should increase further in the future. For this reason, when a check rule set composed of an enormous number of rules is applied to all source files, how to suppress an increase in the time required for checking becomes a problem.
(2) If a check rule is added for a system for a specific application, it becomes difficult to apply it to a system for another application. That is, the customizability deteriorates. For example, it is assumed that a check method for a system designed for a specific Web browser in a commercial transaction system is realized. Therefore, if the version of the Web browser that is the target of this commerce system is changed, the rule related to the Web browser that was originally targeted in the conventional technology is searched from a huge set of rules and replaced with the rule related to the new target Web browser. I have to work. The same problem occurs when a mechanism for dynamically generating HTML adopted in a commercial transaction system is partially changed, or when a service content provided by the commercial transaction system is partially added or changed.

  An object of the present invention is to make it possible to efficiently check a system after addition / change even if the source configuration of the dynamic document generation system to be checked is added / changed.

  FIG. 1 shows an overall configuration diagram of an embodiment of the present invention. The dynamic document generation program 10 of the present invention is executed on a computer that behaves as the dynamic document generation apparatus 1 and applies rule data for checking a dynamic document generation source file for each purpose group. A rule registration unit 121 that can be recorded in a storage device separately for a group that can be applied to a group, a rule assignment unit 122 that allocates a corresponding rule from the rule data for each purpose-specific group, and a dynamic to be checked A dynamic document generation system to be checked, which causes a computer to function as source check means 123 for checking a document generation source file based on rule data assigned to each purpose group of the dynamic document generation source file Even if the source configuration is added or changed, It is possible to perform a check for unloaded efficiently.

  Further, the source check unit 123 analyzes the check result of the dynamic document generation source file and stores it as quality information in the quality information file 24 on the external storage device 2, for example, for each group per source file unit line. It is possible to display quality information by counting the number of NG cases by cause. By analyzing this information, it is possible to determine which rule is violated for each group, and based on the determined information, it is possible to prioritize the application of rules for each group.

  Even if the source configuration of the dynamic document generation system to be checked is added or changed, it is possible to efficiently check the added or changed system.

  Since it is configured so that functions can be added to the existing dynamic document generator as a source check extension function, even when a new source check program is developed, functions can be added to the existing dynamic document generator. It becomes possible.

  FIG. 1 shows an overall configuration diagram of an embodiment of the present invention. The dynamic document generation program 10 of the present invention is executed on a computer that behaves as the dynamic document generation apparatus 1, and a source check extended function unit 12 is added to the conventional dynamic document generation program main body 11 so that the rule registration unit 121 The rule data for checking the dynamic document generation source file is divided into those that can be applied to all groups and those that can be applied to each purpose-specific group, and the common rule file 22 and the individual rule file on the external storage device 2. 23.

  Then, the rule allocating unit 122 performs the common rule file 22 and the individual rule file group stored in the external storage device 2 by the rule registering unit 121 with respect to the dynamic document generation source file stored in the source file 21. An individual rule file corresponding to the purpose-specific group of the dynamic document generation source file is selected from 23 and assigned.

  Further, the source check unit 123 becomes a check target by checking the dynamic document generation source file to be checked based on the rule data assigned for each purpose group of the dynamic document generation source file. Even if the source configuration of the dynamic document generation system is added or changed, it is possible to efficiently check the added or changed system.

  Further, the source check unit 123 analyzes the check result of the dynamic document generation source file and stores it as quality information in the quality information file 24 on the external storage device 2, for example, for each group per source file unit line. It is possible to display quality information by counting the number of NG cases by cause. By analyzing this information, it is possible to determine which rule is violated for each group, and based on the determined information, it is possible to prioritize the application of rules for each group.

  The external device 2 includes a source file 21 that stores grouped dynamic document generation source files, a common rule file 22 that stores rules that can be applied to all groups, and an individual rule that stores rules that can be applied to each purpose-specific group. A file group 23 and a quality information file 24 storing quality information are stored. In this embodiment, the quality information file is shared by the common rule file and the individual rule file. The data structure of each file will be described later.

  For grouping, for example, in the case of a document (screen) generation source (JSP) that constitutes an electronic commerce system, depending on the use of the document (screen), for the center administrator, for purchase management and sales management, for purchase application and sales staff Four groups for non-authenticated users who can view documents (screens) without authentication are possible. Examples of a document (screen) for the center administrator include editing a login message, setting an information expiration date, and registering a user. Examples of documents (screens) for purchase management and sales management include approval of slips and responses to slips, slip queries, and slip response queries. Documents for purchase applications and sales representatives include issuance of slips and response operations on slips. Documents (screens) for users without authentication include searching for product information.

  In addition to such a method of grouping documents (screens), there are a method of dividing them into an outer frame of the screen / contents of the screen, and a method of dividing them by a device (such as a Web browser) that displays the documents.

  FIG. 2 shows a rule description example when XML is used as a language for creating a dynamic document generation source file. <ruleset> to </ ruleset> are rule definitions, and <group> to </ group> are group definitions. <group-name> Container </ group-name> represents the definition of a rule for group container. <rule> to </ rule> represent the definition of one rule.

  The rule described by <type> must-exist </ type> and <expression> ”<uji: dispatch />” </ expression> indicates that <uji: dispatch /> is essential.

  The rule described by <type> mustnot-exist </ type> and <expression> ”<uji: bean>” </ expression> indicates that <uji: bean> must not exist.

<type> must-coexist </ type> and <expression>”<html>”</expression>
In the rule described in <related>”</html”></related>, if there is a description of <html>, it means that </ html> must also exist.

<rule> mustnot-coexist </ type>, <custamizable />, <expression> ”exp1” </ expression>, <related>”<tag1 val = 1>” </ related>
<related>”<tag2 attr1 = val1 attr2 = val2>” </ related> rule has <tag1 val = 1> and <tag2 attr1 = val1 attr2 = val2> It means not to be. This rule is an example added by customization.

FIG. 3 shows an example of the internal expression of the rule in the present invention. First, the rules of the present invention will be described. What is called a rule in the present invention includes the following.
[1] A specific expression is described in the document generation source.
[2] No specific expression is described in the document generation source.
[3] If expression A is described in the document generation source, B must be described as a related expression.
[4] If expression A is described in the document generation source, expression B must not be described.
[5] If expressions A and B appear, expression A must be inside expression B.

In [3] and [4], the expression B may be a single expression or a plurality of expressions.
Examples of [1] include:

<@ Page errorPage => description must exist in the JSP source other than error messages.
Examples of [2] include the following conventions.

The source that generates the contents of the HTML document must not contain <html>, </ html>, <head>, </ head>, <body>, or <body>.
Examples of [3] include the following conventions.

If there is a JavaScript function call description, there must be a JavaScript function definition or JavaScript file declaration.
Examples of [4] include the following conventions.

Each tag must be described in pairs, such as <html>, </ html>.
Examples of [5] include the following conventions.

  <input> tag must be described inside <form> ~ </ form>.

Next, a data structure related to rules will be described. In the present invention, rules are common to all source groups and common to specific source groups. For this reason, the source check extended function unit 12 according to the present invention has a correspondence table of a source group and a list of rules applied to the source group. Each rule has the following information.
-Description tree is information that expresses the expression checked by the rule in a tree structure.
-The contract type indicates which type the rule is among [1] to [5] described above.
-Check flag is a flag that specifies whether or not to perform the check.
-Presence / absence of check target expression indicates whether there is an expression to be checked.
-The result indicates whether the check by this rule is OK or NG.
The related description tree represents an expression associated with the expression represented by the description tree when the rules are [3] to [5] described above.

  At the end of the related description tree, there is linked a tree structure representation information of an expression associated with the expression to be checked and a list of appearance flag pairs indicating whether or not the expression has appeared. In addition, when the source file to be checked refers to another file (resource) such as an image file, the group to which the source file belongs, the type of resource to which the group refers (image, script file, style sheet, etc.), It has information on the storage location of the file corresponding to the resource (relative position from the directory storing the source file).

  FIG. 4 shows an example of a description tree for a source file checked by a rule. FIG. 4 shows an example of an HTML image tag. In the end node of the tree structure, “img” indicating the start of the image tag and attributes appearing in the image tag and their values (eg, src, width, height, alt attributes and their values) are set. When the terminal node is an attribute name, information indicating whether the attribute is essential is given as constraint information. When the end node is an attribute value, information indicating whether to check the constraint information with a rule or whether to check with a specific constraint condition (for example, a fixed constraint condition where the value is greater than 0 for width or height) is given Is done. When checking with a fixed constraint condition, the constraint condition used for the check is included as information.

  FIG. 5 shows a method of checking an expression appearing in a source file using the rules of FIG. 3 and the tree structure expression of FIG. The tree structure generated by expanding the tree structure of the expression appearing in the source file (the left tree structure in FIG. 5) and the tree structure associated with the rule (the right tree structure in FIG. 5) If the structure matches, the tree structure appearing in the source file is considered to be checked by that rule. Before applying the rule to the expression that is considered to be checked, check the constraints associated with each end node of the tree structure in order, and whether the expression that appears in the source file alone satisfies the rule Check it out.

  FIG. 6 shows an example of quality information in which, for example, the number of NGs per source file unit line is tabulated by cause. Here, the source file is divided into four groups: outer frame, center management, member-only, and public, and the number of NG of each rule is displayed for each group. By analyzing this information, it is possible to determine which rule is frequently violated for each group. Based on the calculated information, it is possible to set the priority of application of rules for each group. As a method of assigning priorities, for example, a method of preferentially applying rules having a large number of violations can be considered.

  FIG. 7 shows an example in which quality information is added to the data structure related to the rule shown in FIG. 3 in order to collect quality information. In FIG. 7, as the appearance line information, information on the line in which the expression subject to the rule appears and the result of rule application (OK or NG) for each line is accumulated, and the number of NGs is totaled later. Output aggregate information as shown on the bottom.

  FIG. 8 is a flowchart showing a processing flow of the dynamic document generation source file check extension function unit according to the present invention. First, it is determined whether or not the corresponding source file group is a check target (S801). For example, the source file to be checked is stored in a folder that represents group identification information, or information that identifies a group is stored in the control information of the source file. It is checked which group it belongs to, and it is determined whether there is a group identifier corresponding to the data related to the rule as shown in FIG.

  If it is a check target, the rule specific to the target group is read from the individual rule file group 23 (S802). Next, the rules common to all the groups stored in the common rule file 22 are read out, the rules read in S802 are added, and a check list is generated (S803). Next, the check result output file is opened for the source file to be checked (S804), and the source file is read and checked (S805). Refer to FIG. 9 for details of this processing. When the check ends, the result is output to the check result output file (S806), the check result output file is closed (S807), and the processing of the dynamic document generation source file check extended function unit ends.

  FIG. 9 is a flowchart showing the flow of the source file reading process and the check process of the dynamic document generation source file check extension function unit according to the present invention. Open the source file (S901), and repeat the following until the source file ends.

  One description unit of the source file is read (S902), and the read description unit is expanded into a tree structure as shown in FIG. 4 (S903). Next, as shown in FIG. 5, the tree pattern representation that matches the development pattern on the rule list created in S803 and the source file is searched (S904). Next, it is checked whether or not the corresponding terminal node of the tree structure expanded from the source satisfies the constraint condition of each terminal node of the tree structure having the same expanded pattern (S905). If the check result does not satisfy the constraints, the check column is set to false in order to make the check NG (S906). It is determined whether or not the source file is finished (S907). If not finished, the process returns to S902.

  If the constraint condition is satisfied, the type of the check rule corresponding to the tree structure is determined by the contract type (S908), and the following processing is performed. If the rule is mandatory [1] and the rule is applied, set the presence column that is the “description presence flag” of the rule to true, and set the result column to true to make the rule check result OK. (S909). When the rule is “prohibition of description [2]” and the rule is applied, the presence / absence column of the “description presence flag” of the rule is set to true, and the result column is set to false in order to set the rule check result to NG (S910). ). When applying a rule of type [3] where another description must exist in relation to this description, the presence / absence field which is a tree structure existence flag is set to true, and one or more related description trees are provided for this description. If the appearance flag is false, the check result for this description is set to false (S911).

  In addition, when applying a rule of type [4] in which another description should not exist in relation to this description, the presence / absence field that is a tree structure presence flag is set to true, and one or more If the appearance flag of the related description tree is true, the check result for this description is set to false (S912).

  When applying a rule of type [5] where this description must exist in another description B, a flag is set when the start expression of description B comes out, and the end of description B appears. Then reset the flag. If the file ends before the flag is reset, the result column is set to false in order to set the check result for the description to NG (S913).

  FIG. 10 is a flowchart showing a processing flow of the dynamic document generation source file check extension function unit according to the present invention when quality information is collected. Detailed description of the same processing as in FIG. 8 is omitted. First, it is determined whether or not the corresponding group is a check target (S1001). If the corresponding group is a check target, the quality information file is opened (S1002) and then a rule specific to the group is read (S1003). The check list is generated by adding the rule read in S1003 to the rule (S1004).

  Next, the check result output file is opened (S1005), the source file is read and checked (S1006), the result is output to the check result output file (S1007), and the check result output file is closed (S1008). Then, the quality information file is closed (S1009), and the process is terminated.

  FIG. 11 is a flowchart showing the flow of the source file reading process and the check process of the dynamic document generation source file check extended function unit according to the present invention when collecting quality information. Detailed description of the same processing as in FIG. 9 is omitted. Open the source file (S1101), and repeat the following until the source file ends.

  First, one description unit of the source file is read (S1102), the read description unit is expanded into a tree structure, and the appearance line of the description is recorded in the work area (S1103). Next, a tree structure expression having the same expanded pattern is searched (S1104), and whether the corresponding terminal node of the tree structure expanded from the source satisfies the constraint condition of each terminal node of the tree structure having the matched expanded pattern. A check is made (S1105). If the check result does not satisfy the constraints, the check is NG (S1106), and it is determined whether the source file is finished (S1107).

  The type of the check rule corresponding to the tree structure is determined (S1108), and the following processing is executed according to the type. If the description is mandatory [1] and the rule is applied, the “description presence flag” of the rule is set to true, the rule check result is set to OK, and an OK record is added to the quality information data (S1109). ). When the rule is “prohibition of description [2]” and the rule is applied, the “description presence flag” of the rule is set to true, the rule check result is set to NG, and an NG record is added to the quality information data (S1110).

  When applying a rule of type [3] where another description must exist in relation to this description, the tree structure existence flag is set to true, and one or more related description tree appearance flags are set for this description. If false, the check result for this description is set to false, and the check result is added to the quality information data (S1111).

  When applying a type [4] rule in which no other description should exist in relation to this description, the existence flag of the tree structure is set to true, and the existence flag of one or more related descriptors for this description If true, the check result for this description is set to false, and the check result is added to the quality information data (S1112).

 When applying a rule of type [5] where this description must exist in another description B, a flag is set when the start expression of description B comes out, and the end of description B appears. Then reset the flag. If the file ends before the flag is reset, the check result for the description is NG, and the check result is added to the quality information data (S1113). The above results are aggregated, and the aggregation results are added to the quality information file (S1114).

Overall configuration diagram of the embodiment Example of rule description Data structure for rules Internal representation of the source file Check against source file Quality information example Data structure for quality information Dynamic document generation source file check extension function flow Source file reading process and check process flow Flow of processing of the extended function part of dynamic document generation source file check when collecting quality information Flow of source file read processing and check processing when collecting quality information

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Dynamic document production | generation apparatus 2 External storage device 3 Input / output device 10 Dynamic document production | generation program 11 Dynamic document production | generation program main body 12 Soso check extended function part 21 Source file 22 Common rule file 23 Individual rule file 24 Quality information file 121 Rule registration means 122 Rule assignment means 123 Source check means

Claims (5)

Rules that allow the storage device to record rule data for checking dynamic document generation source files separately for those that apply to each group of dynamic document generation source by purpose and those that can be applied to all groups. Registration means;
Rule allocating means for allocating a corresponding rule from the rule data for each purpose group;
Dynamic document generation source file check for causing a computer to function as a source check means for checking a dynamic document generation source file to be checked based on rule data assigned to each purpose group of the dynamic document generation source file program.   2. The dynamic document generation source file check program according to claim 1, wherein the source check unit analyzes a check result of the dynamic document generation source file and records the result as quality information in a storage device.   The dynamic document generation source file check program according to claim 1, wherein the groups are grouped based on document usage or display device type. Rules that allow the storage device to record rule data for checking dynamic document generation source files separately for those that apply to each group of dynamic document generation source by purpose and those that can be applied to all groups. Registration means;
Rule allocating means for allocating a corresponding rule from the rule data for each purpose group;
Dynamic document generation, comprising: source check means for checking a dynamic document generation source file to be checked based on rule data assigned to each purpose group of the dynamic document generation source file. Source file check device. The step of recording the rule data for checking the dynamic document generation source file on the storage device separately for those that are applied to each purpose-specific group of the dynamic document generation source and those that can be applied to all groups. When,
Assigning a corresponding rule from the rule data for each purpose group;
Checking a dynamic document generation source file to be checked based on rule data assigned to each purpose group of the dynamic document generation source file. Method for checking.

Images