JP5066499B2 - Web application operation procedure manual generation system - Google Patents

Description

  The present invention relates to a Web application operation procedure manual generation system for generating an operation procedure manual for explaining to a user how to use a Web application.

  Web application systems are becoming increasingly important for companies to conduct business. In recent years, in order to make a difference with rival companies, it has become necessary to develop a high-quality system in a shorter period of time and at a lower cost. In order to develop a system in a short period of time and at a low cost, the development process becomes very important.

  Until now, the “waterfall type development method” has often been used in the field of system development. This is a development method in which requirements are defined first, external specifications and detailed specifications are defined, and actual programs are developed and tested when all specifications are completed. Since the detailed specifications of the program to be developed have already been determined at the time of program development, specification omissions and mistakes can be prevented and development can be performed efficiently.

  However, the waterfall development method is characterized in that the program cannot be implemented unless all the specifications are completed. It takes a lot of time and labor to create a specification, which makes it difficult to develop a system in a short time and at a low cost. Therefore, “Agile Software Development” has been attracting attention in recent years. This is a general term for development methods for developing software at a higher speed. For example, “extreme programming”, one of the specific methods of agile software development, designs, implements, tests, and releases in a short period of 2-4 weeks, and then repeats development many times. As a result, software that actually operates at an early stage can be provided to the user, and voices from the user can be immediately fed back to the development, so that higher quality software can be developed. In agile development, rather than writing a lot of specifications, there is a basic idea of making software that actually works and receiving feedback to improve it over and over again. For this reason, the number of documents such as specifications to be created is significantly reduced compared to the waterfall type development.

  However, it has been pointed out that the system maintenance becomes difficult because there are few documents to be created. For example, because there are few design documents, it may be difficult for a maintenance person to identify the cause of a problem when a failure occurs in the system. In addition, since there is no usage procedure manual (manual) describing how to use the system itself, the system user or administrator cannot use the system.

In order to solve such problems, it is important to reduce the developer's document creation load. As one of the solutions, a method has been proposed in which an operation procedure manual is automatically generated from a Web application that has already been completed, and the labor required for document creation is saved. Patent Document 1 describes a system having a function of automatically saving a screen shot of a Web application as an image file by manually registering a URL corresponding to the screen of the Web application in advance. As a result, it is possible to easily prepare a screen shot image of a Web application that is necessary when creating an operation procedure manual or the like.

JP 2008-9694 A

  However, the method referred to in Patent Document 1 specializes only in creating a screen shot image, and the operation procedure manual itself still needs to be created manually. In addition, since it is necessary to specify the URL of the screen for which a screen shot is to be taken in advance, if the number of Web application screens becomes enormous, the URL specifying operation will be very expensive.

  In view of the above-described situation, the present invention provides an operation procedure manual generation system for a Web application that can reduce the cost of developer document creation by automatically generating a template of an operation procedure manual from a completed Web application. For the purpose.

In order to solve the above problems, the present invention provides the following configurations.
The invention according to claim 1 is an operation procedure manual for a web application mounted on a computer that is communicatively connected via a network to a web application server on which a web application for which an operation procedure manual is generated is operating. A generation system,
The operation procedure manual generation system for the Web application includes a screen information storage unit that stores screen information such as screen transitions and screen configurations,
A screen image storage unit for storing image files;
A scenario flow storage unit that stores scenario flow information for creating an operation procedure;
An operation procedure template storage unit for storing the operation procedure template;
When the user specifies the root URL of the web application, means for accessing the web application screen of the web application server indicated by the root URL;
Means to call the screen analysis process with the accessed screen as an argument,
Analyzing the HTML of the screen to be analyzed by screen analysis processing, obtaining information on all links and forms existing in the screen, and registering them in the screen information storage unit;
Means for capturing a screen to be analyzed, converting it into an image file, and storing it in the screen image storage unit;
For all the obtained links and forms, if the link, access the link destination, if it is a form, send the form, and a means to transition the screen,
As a result of performing screen transition, a means to determine whether an HTTP redirect response has been received,
When an HTTP redirect response is received, a redirect destination path is registered in the screen information storage unit, and further a transition to the redirect destination path is performed.
Means for checking whether screen information about the transition destination screen is registered in the screen information storage unit;
If the screen information about the transition destination screen is not registered in the screen information storage unit, the screen analysis processing is recursively called with the transition destination screen as the analysis target screen, and the link included in the screen is displayed. Tracing, means for acquiring all screen information and screen images constituting the Web application,
For link and form information registered in the screen information storage unit, creating an image that emphasizes those screen elements, and storing the image in the screen image storage unit,
Means for creating a screen transition diagram using the information accumulated in the screen information storage unit and the screen image storage unit by the screen analysis process;
Means for acquiring scenario flow information created in advance by a user operation with reference to the screen transition diagram, one record at a time from the scenario flow storage unit;
Means for embedding the scenario name of the scenario flow information in the operation procedure manual template acquired from the operation procedure manual template storage unit;
Means for embedding an item number of a scenario flow information record in the operation procedure manual template;
Means for embedding an operation procedure message in the operation procedure template;
Means for determining whether the acquired record is the last record of the scenario flow information;
If it is not the last record, means for embedding the screen shot image indicated by the “transition execution image” of the scenario flow record in the operation procedure manual template;
If it is the last record, means for embedding the screen shot image indicated by the “link source image” of the scenario flow record in the operation procedure manual template;
It is provided with a means for outputting the operation procedure manual template as an operation procedure manual.

According to the Web application operation procedure manual generation system of the present invention, the following effects are obtained.
(1)
On the screen transition diagram automatically generated by this system, just by selecting the range where you want to create the operation procedure manual, the operation procedure manual template is automatically generated, which can greatly reduce the cost of creating the operation procedure manual. it can.
(2)
The screen shot image inserted in the generated operation procedure manual is additionally drawn with a mark to indicate the operation procedure, so that the developer can save time and effort to edit the image, and the user can understand more. Easy operation procedure manual can be provided.

Hereinafter, embodiments of the present invention will be described with reference to the drawings showing examples.
The above means are means realized by reading and executing necessary computer programs by the CPU of the electronic computer, and the flowcharts thereof are shown in FIGS.
FIG. 1 shows the overall configuration of an operation procedure manual generation system proposed in the present invention and a related system for operating the operation procedure manual generation system. The operation procedure manual generation system (1-15) is a group of programs that are mounted and operated on a general electronic computer (1-14). The computer (1-14) is connected to an input / output device (1-10) such as a display and a keyboard, and is further connected to a network (1-13) such as a LAN / Internet. The electronic computer (1-14) is connected to the web application server (1-16) through the network (1-13). On the Web application server (1-16), a Web application (1-2) that is a target for generating an operation procedure manual is running. The application log (1-1) is a file in which the operation status of the Web application (1-2) is recorded. For example, when there is a request for the Web application (1-2), the time when the request is made, the requested URL, the transmitted request parameters, and the like are recorded in the application log (1-1). In the agile software development that the present invention is based on, release work is frequently performed in a short period of time as described above. The released web application (1-2) is actually used by customers. Therefore, it is assumed that a sufficient amount of log has been output to the application log (1-1).
Since the electronic computer (1-14) is connected to the web application server (1-16) through the network (1-13), access to the web application (1-2) and the application log (1-1) Reading is possible.
The electronic computer (1-14) includes a storage device, and the storage device stores storage units 1-4 to 1-7, which will be described later, formed of a database.

  In order to generate an operation procedure manual using this system, the screen transition diagram generation unit (1-3) first accesses the Web application (1-2), and information such as screen transition and screen configuration is displayed as screen information. Is acquired and stored in the screen information storage unit (1-4). The screen transition diagram generation unit (1-3) traces the links on the screen from the next to the next, and acquires information on all screens of the Web application (1-2). When acquiring screen information, the screen of the Web application (1-2) is simultaneously captured and stored in the screen image storage unit (1-5) as an image file. If there is a screen element (such as an HTML input tag) that accepts input from the user in the screen of the Web application (1-2), the application log (1-1) is read and information input in the past from there is read. Is used when acquiring screen information. A screen transition diagram (1-9) is created by combining the screen information and screen images collected in this manner, and displayed on the input / output device (1-10).

  Next, the user (1-11) sees the screen transition diagram and inputs a scenario flow for which an operation procedure manual is to be created. The entered scenario flow information is stored in the scenario flow storage unit (1-6). Then, the operation procedure manual generation unit (1-8) acquires the scenario flow information from the scenario flow storage unit (1-6) and the operation procedure manual template from the operation procedure template storage unit (1-7). A procedure manual (1-12) is generated. The generated procedure manual is displayed on the input / output device (1-10).

As a specific example, the procedure for generating the operation procedure manual of the Web application having the screen transition shown in FIG. 2 will be described.
Fig. 2 shows the screen transition of a Web application for writing and displaying a diary. The “top page” screen (2-1) is a screen that is displayed first when using this Web application. This page has two links: “Write a diary” and “View the diary”. Clicking on the “Write Diary” link displays the “Write Diary” screen (2-2). Enter the title and body of the diary in the “Title” text field and “Body” text area on this screen and press the “Confirm” button. Then, a “confirmation” screen (2-3) is displayed, and the contents of the diary entered on the “write diary” screen are displayed again. The user confirms that this content is correct and presses the “Register” button. Then, the contents of the diary are saved, and a diary display screen (2-5) is displayed. When the “view diary” link on the “top page” screen is clicked, a “diary list” screen (2-4) is displayed. This screen displays the diaries registered so far in a list format. When a diary title is clicked from the list, a diary display screen (2-5) is displayed. Hereinafter, this Web application is referred to as a “diary application”.

  The screen transition from the confirmation screen (2-3) to the diary display screen (2-5) includes a transition by an HTTP redirect response. The HTTP redirect response is a kind of response from the server in HTTP, and is for notifying that the URL has been changed. In general Web browsers, when an HTTP redirect response is received, the screen automatically changes to the “redirect destination” URL included in the HTTP redirect response. In the diary application, when the “Register” button on the confirmation screen is pressed, an HTTP request for the path “/ submit” is issued. Then, an HTTP redirect response whose redirect destination is “/ view” is returned. The web browser recognizes this, and this time issues an HTTP request to “/ view”. This time, the HTML data of the diary display screen is returned as HTTP response information. As a result, a diary display screen is displayed on the Web browser.

FIG. 3 is a flowchart showing the processing contents of the screen transition diagram generation unit.
(3-1) First, the user of this system designates the root URL of the Web application to the screen transition diagram generation unit. The root URL is the URL of the Web application start screen or the base screen. This is the URL of the “top page” screen of the diary application.
(3-2) Next, the screen of the Web application indicated by the root URL is accessed. The screen transition diagram generation unit has a function as an HTTP client. An HTTP client is a program that accesses a Web page on the Internet or a LAN by HTTP communication and exchanges an HTML document or an image file referenced by the document. The web browser we normally use is also a kind of HTTP client.
(3-3) Call the screen analysis process using the screen accessed in the above process as an argument. The details of the screen analysis processing will be described with reference to FIG.
(3-4) Since information is stored in the screen information storage unit and the screen image storage unit by the screen analysis process, a screen transition diagram is created using the information. Details of the creation procedure will be described with reference to FIG.

FIG. 4 is a flowchart showing the processing contents of the screen analysis processing. This process takes the screen to be analyzed as an argument. For example, in the process of FIG. 3, this process is executed with the screen of the root URL as the analysis target screen.
(4-1) Analyzes the HTML of the screen to be analyzed, acquires information on all links and forms existing in the screen, and registers them in the screen information storage unit. As a technique for analyzing the HTML of the screen, there is a method of reading HTML as XML using an XML parser and handling it as DOM (Document Object Model). By acquiring link (A tag) elements and form (FORM tag) elements from the DOM tree, it is possible to acquire information on all links and forms that exist on the screen. Details of the process of registering the acquired information in the screen information storage unit will be described with reference to FIG.
(4-2) A screen to be analyzed is captured, converted into an image file, and stored in a screen image storage unit. For example, if you are using a personal computer with Windows (registered trademark), you can save the image currently displayed on the display as an image file by pressing the “PrintScreen” key. Screen capture.
(4-3) Further, the image captured by the above procedure is processed. In (4-1), all the links and form information existing in the screen are acquired, but an image that emphasizes those screen elements is created. For example, when a link exists on the screen, the link portion is surrounded by a red frame (for example, an operation mark) to create an emphasized screen image. The created image is stored in the screen image storage unit as in the previous procedure. Details of these processes will be described with reference to FIG.

(4-4) For all links and forms acquired in (4-1), if a link, the link destination is accessed, and if it is a form, form transmission is performed and screen transition is performed. Do this for all links and forms on the screen. This process will be described in detail with reference to FIG.
(4-5) It is determined whether an HTTP redirect response has been received as a result of the screen transition.
(4-6) When an HTTP redirect response is received, the redirect destination path is registered in the screen information storage unit, and further the transition is made to the redirect destination path. Details of this processing will be described with reference to FIG.
(4-7) It is checked whether or not the screen information about the transition destination screen is registered in the screen information storage unit.
(4-8) If the screen information about the transition destination screen is not registered in the screen information storage unit, the screen analysis processing is recursively called with the transition destination screen as the analysis target screen.
As described above, by following the links included in the screen one after another and recursively calling the screen analysis processing, all screen information and screen images constituting the Web application can be acquired.

FIG. 5 shows information registered in the screen information storage unit when the screen transition diagram generation unit analyzes and completes the diary application. The screen information storage unit stores information about transition from one screen to the screen, information about the operation content when performing the transition, and a pointer (described later) of the screen capture image. The “link source” column (5-1) stores the path of each screen. The “link destination” column (5-2) stores the path of the transition destination when transitioning from each screen to another screen. The “redirect destination” column (5-3) stores the redirect destination path when there is an HTTP redirect response at the time of screen transition. In the “operation” column (5-10), contents to be operated at the time of screen transition are stored.
As an example, a process for analyzing the top page screen (2-1) of FIG. 2 will be described. First, since the path of the top page screen is “/”, “/” is registered in (5-4). Further, as described in FIG. 4 (4-1), when the top page screen is analyzed, two link elements (A tag) “write diary” and “view diary” are found. Therefore, the “/ add” and “/ list” values of the href attribute of the A tag that is the link destination path are registered in (5-5) and (5-6). Since the result of the determination process (4-5) in FIG. 4 is false, nothing is registered in the “redirect destination”. Furthermore, when the screen transitions, it is only necessary to click the “write diary” and “view diary” links, so in (5-11) and (5-12), “click the“ write diary ”link”, “ Register “Click to view” link.
As another example, a process for analyzing the confirmation screen (2-3) in FIG. 2 will be described. As described in the description of FIG. 2, the screen transition from the confirmation screen to the diary display screen (2-5) is due to redirection. First, “/ confirm” which is the path of the confirmation screen is registered in (5-7). Further, since the request destination path of the form included in the confirmation screen is “/ submit”, it is registered in (5-8). Next, “/ view”, which is a redirect destination path included in the HTTP redirect response, is registered in (5-9) by the determination process of (4-5) in FIG. Further, since it is necessary to click the “Confirm” button to perform the screen transition, “Click the“ Confirm ”button” is registered in (5-13).
In this way, information on all screens is registered in the screen information storage unit.

FIG. 6 explains the details of the process (4-4) of FIG. In (4-4), all the link destinations in the screen are accessed or the form is transmitted to perform screen transition. In the case of a link, simply access the link destination URL using the HTTP GET method. However, in the case of a form, it is necessary to send HTTP POST after entering the value of the text field or text area. It is not necessary to input an appropriate value in the text field or text area. For example, in the case of diary registration processing of a diary application, it is necessary to set meaningful data such as a diary title and a diary text. Therefore, the information is acquired from the application log output by the Web application.
For example, (6-1) is a “write diary” screen, in which a “title” text field, a “body” text area, and a “confirm” button are displayed. Part (6-2) shows a part of HTML constituting this screen.
The screen transition diagram generation unit analyzes the HTML of (6-2), the <input> tag (6-4) corresponding to the “title” text field, and the <textarea> tag ( 6-5) is specified. Then, it is specified that the name attribute values of these tags are “title” and “body”, respectively. Further, it is specified that the transmission destination path of this form is “/ confirm” (6-3).

Next, the screen transition diagram generation unit reads the application log output by the Web application. (6-6) is an example of an application log. For this log, search for a log record in which the HTTP method name is POST, the request destination path is "/ confirm", and the POST transmission parameters include "title" and "body".
Then, the log record shown in (6-7) is found. According to this log record, the value of the “title” parameter is “Diary 1” and the value of the “body” parameter is “This is Diary 1”. .
As described above, the screen transition diagram generation unit can determine what character string should be set in the text field and text area on the “write diary” screen.

  Moreover, since it is understood that it is necessary to input in a text area or the like when sending a form by the above processing, it is necessary to additionally register it in the screen information. For example, the analysis of HTML in FIG. 6 shows that it is necessary to input the “title” text field and the “body” text area. Next, identifiers for identifying these tags are acquired. In this example, since the name attribute of each tag can be used as an identifier from (6-4) and (6-5), “title” and “body” are used as identifiers for each tag. As a result, information “input in the title text field” and “input in the body text area” are set in (5-14) and (5-15).

FIG. 7 explains the details of the process (4-3). Generally, in the operation procedure manual of a Web application, for example, when explaining "Please click the" Write a diary "link" on the top page screen, the relevant screen shot image is also posted. In order to make it easy to understand where to click, a portion to be clicked in the screen shot image may be highlighted and surrounded by a red frame. This processing is performed in (4-3). For example, in the case of the “top page” screen shown in (7-1), to explain that the “write diary” link or the “view diary” link is clicked, it is shown in (7-2) and (7-3). Such an image may be created and posted in the operation procedure manual.
Since the position of the HTML element constituting the link or form in the screen is known by the process of (4-1) in FIG. 4, the screen transition diagram generation unit adds style information to the style attribute of the HTML element. The part to be clicked is highlighted with a red frame. (7-4) is an example. Screen capture processing is performed on the screen to which highlighting is added in this manner, similarly to (4-2) of FIG. 4, and is stored in the screen image storage unit as a screen shot image file.

(7-5) shows a part of the screen information stored in the screen information storage unit. Here, the screen information is associated with the screen shot image. Association is performed by registering the pointer of the image file created by the processes (4-2) and (4-3) in “link source image” and “transition operation image” of the screen information.
For example, the image of (7-1) is associated with (7-6) (7-7). The image (7-2) is associated with (7-8), and the image (7-3) is associated with (7-9).
The above association process is performed for all image files.

FIG. 8 shows how a screen transition diagram is generated from screen information and screen images accumulated by the screen transition diagram generation unit. The screen transition diagram generation unit first reconstructs the entire screen transition of the Web application from the information stored in the screen information storage unit (8-1).
For example, from the relationship (8-3) (8-4) (8-5) of the screen information storage unit, from the “top page” screen (8-2), the “write diary” screen (8-6) and “ It can be seen that the “Diary List” screen (8-7) is linked. Therefore, the image file indicated by the pointers (8-18) and (8-19) is acquired from the screen image storage unit (8-8), and each is drawn on the screen transition diagram. Next, the arrow lines as shown in (8-9) and (8-10) are drawn on the screen transition diagram from the “top page” screen to the “write diary” screen and the “diary list” screen.
Further, since it is understood from the relationship of (8-13), (8-14), and (8-15) that the screen transition is caused by the redirect process, the pointers of (8-21) and (8-20) indicate The images on the “confirmation” screen (8-11), the diary display screen (8-12) screen, and the arrow line (8-16) connecting them are respectively drawn on the screen transition diagram.
As a result of performing such processing on all information registered in the screen information storage unit, a diagram as shown in (8-17) is completed.
The details up to this point are the details of the processing of the screen transition diagram generation unit.

  FIG. 9 shows how the screen transition diagram is displayed on the input / output device. The user can check the screen transition of the Web application by looking at this screen. The user operates the pointer (9-1) displayed on the screen using the input / output device, selects each screen on the screen transition diagram, and specifies the order and range of screen transitions for which the operation procedure manual is to be generated. To do.

  FIG. 10 shows a state in which the user uses the pointer to specify the order and range of screen transitions for which an operation procedure manual is to be generated. In this example, the user thinks “I want to generate a procedure manual for writing a diary”, and the “top page” screen (10-1), the “write diary” screen (10-2), the “confirmation” screen (10 3) and the diary display screen (10-4) are selected in this order. Then, as shown in the figure, the arrow between the selected screen and each screen is highlighted.

Note that the screen information corresponding to the screen transition specified here is copied to the scenario flow storage unit. For example, when screen transition is designated as shown in FIG. 10, records (5-16), (5-17), (5-18), and (5-19) are registered in the scenario flow storage unit. Details of the information registered in the scenario flow storage unit will be described with reference to FIG.
When the selection of the screen is completed, the user presses the “Generate” button (8-5). Then, the “Specify Scenario Name” dialog box is displayed.

FIG. 11 shows how the “Specify Scenario Name” dialog box (11-1) is displayed. The user assigns a scenario name to the designated screen transition and inputs it in the input field (11-2) of the dialog box. The scenario name specified here is used as the heading character string of the generated operation procedure manual. In the figure, the scenario name “Create / Register Diary” is entered. This scenario name is stored in the scenario flow storage unit.
Finally, by pressing the “OK” button (11-3), an operation procedure manual is generated.
The operation procedure manual is generated by embedding information stored in the scenario flow storage unit in a template stored in the operation procedure template storage unit.

  FIG. 12 shows information registered in the scenario flow storage unit by the operations in FIGS. 10 and 11. Each record is a copy of a record registered in the screen information storage unit with an item number added. An operation procedure manual is generated along with this information.

FIG. 13 shows an example of the operation procedure manual template. The template generation method is not particularly limited in the present invention. The template illustrated in FIG. 13 is {
} Is replaced by an arbitrary character string by the program.

FIG. 14 shows the procedure for generating the operation procedure manual template.
(14-1) The scenario flow information created by the user operation is acquired one record at a time.
(14-2) Embed the scenario name of the scenario flow in the template. For example, the character string indicated by (12-1) is embedded in the location (13-1).
(14-3) The scenario flow record number is embedded in the template. For example, the number registered in the column (12-2) is embedded in the location (13-2).
(14-4) An operation procedure message is embedded in the template. The operation procedure message will be described with reference to FIG. For example, an operation procedure message is embedded at a location (13-3).
(14-5) It is determined whether the record acquired in (14-1) is the last record in the scenario flow. For example, it is determined whether the record acquired in (14-1) is equal to the record in (12-3).
(14-6) When the determination result of (14-5) is false, the screen shot image indicated by the “transition execution image” of the scenario flow record is embedded in the template. For example, the image indicated by the pointer registered in the (12-4) column is embedded in the location (13-4).
(14-7) When the determination result of (14-5) is true, the screen shot image indicated by the “link source image” of the scenario flow record is embedded in the template. For example, the image indicated by the pointer registered in the (12-5) column is embedded in the location (13-4).
(14-8) Finally, the template is output as an operation procedure manual. 16 to 19 are examples of the output.

  FIG. 15 is a diagram for explaining the operation procedure message embedding process (14-4). As the operation procedure message, a message corresponding to the content described in the “operation” column of the scenario flow information is acquired from the table shown in (15-1). For example, (12-6) corresponds to the message (15-2). The “{anchor text}” part is replaced with “write diary”. As a result, it is displayed as (16-1). The messages (15-3), (15-4), and (15-5) correspond to (12-7), (12-8), and (12-9), respectively. “{Button name}” and “{id}” are replaced with “confirm”, “title”, and “body”, respectively. As a result, it is displayed as (17-1) (17-2) (17-3). A list of these messages is embedded in the template as an operation procedure message.

1 is an overall configuration diagram including a Web application operation procedure manual generation system according to the present invention and a related system for operating the operation procedure manual generation system. It is a screen transition diagram of the diary application used as an example of the present invention. It is a flowchart of a process of the screen transition diagram production | generation part of this invention. It is a figure which shows the flow of the screen analysis process of this invention. It is a figure which shows the example of the screen information of this invention. It is a figure which shows the procedure which acquires the sample of form transmission data from the application log of this invention. It is explanatory drawing of creation of the screen capture image of this invention, and correlation with screen information. It is explanatory drawing of construction | assembly of the screen transition diagram of this invention. It is a screen transition diagram displayed on the output device of the present invention. It is a screen figure which displays the state where the scenario flow was designated by the user of this invention. It is a screen figure which displays the state where the scenario flow name was designated by the user of this invention. It is a figure which shows the example of the scenario flow information of this invention. It is a figure which shows the example of the template of the operation procedure manual of this invention. It is a figure which shows the flow of a process of the operation procedure manual production | generation part of this invention. It is explanatory drawing of the process of the operation procedure message of this invention. It is a figure which shows the example (1) of the operation procedure manual produced | generated by this invention. It is a figure which shows the example (2) of the operation procedure manual produced | generated by this invention. It is a figure which shows the example (3) of the operation procedure manual produced | generated by this invention. It is a figure which shows the example (4) of the operation procedure manual produced | generated by this invention.

Explanation of symbols

1-2 Web Application 1-4 Screen Information Storage Unit 1-5 Screen Image Storage Unit 1-6 Scenario Flow Storage Unit 1-7 Operation Procedure Template Storage Unit 1-9 Screen Transition Diagram 1-11 User 1-12 Operation Procedure Manual 1-13 Network 1-14 Computer 1-15 Operation Procedure Generation System 1-16 Web Application Server

Claims (1)

An operation procedure manual generation system for a web application installed in an electronic computer that is connected to a web application server on which a web application for which an operation procedure manual is generated is connected via a network.
The operation procedure manual generation system for the Web application includes a screen information storage unit that stores screen information such as screen transition and screen configuration,
A screen image storage unit for storing image files;
A scenario flow storage unit that stores scenario flow information for creating an operation procedure;
An operation procedure template storage unit for storing the operation procedure template;
When the user specifies the root URL of the web application, means for accessing the web application screen of the web application server indicated by the root URL;
Means to call the screen analysis process with the accessed screen as an argument,
Analyzing the HTML of the screen to be analyzed by screen analysis processing, obtaining information on all links and forms existing in the screen, and registering them in the screen information storage unit;
Means for capturing a screen to be analyzed, converting it into an image file, and storing it in the screen image storage unit;
For all the obtained links and forms, if the link, access the link destination, if it is a form, send the form, and a means to transition the screen,
As a result of performing screen transition, a means to determine whether an HTTP redirect response has been received,
When an HTTP redirect response is received, a redirect destination path is registered in the screen information storage unit, and further a transition to the redirect destination path is performed.
Means for checking whether screen information about the transition destination screen is registered in the screen information storage unit;
If the screen information about the transition destination screen is not registered in the screen information storage unit, the screen analysis processing is recursively called with the transition destination screen as the analysis target screen, and the link included in the screen is displayed. Tracing, means for acquiring all screen information and screen images constituting the Web application,
For link and form information registered in the screen information storage unit, creating an image that emphasizes those screen elements, and storing the image in the screen image storage unit,
Means for creating a screen transition diagram using the information accumulated in the screen information storage unit and the screen image storage unit by the screen analysis process;
Means for acquiring scenario flow information created in advance by a user operation with reference to the screen transition diagram, one record at a time from the scenario flow storage unit;
Means for embedding the scenario name of the scenario flow information in the operation procedure manual template acquired from the operation procedure manual template storage unit;
Means for embedding an item number of a scenario flow information record in the operation procedure manual template;
Means for embedding an operation procedure message in the operation procedure template;
Means for determining whether the acquired record is the last record of the scenario flow information;
If it is not the last record, means for embedding the screen shot image indicated by the “transition execution image” of the scenario flow record in the operation procedure manual template;
If it is the last record, means for embedding the screen shot image indicated by the “link source image” of the scenario flow record in the operation procedure manual template;
An operation procedure manual generation system for a Web application, comprising: means for outputting the operation procedure manual template as an operation procedure manual.

Images