JP2008009674A - Circulating screen capture system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a circulating screen capture system which is capable of automatically collectively generating screen images by reducing the man-hour required for screen image generation and unifying images after generation in development of the web application system. <P>SOLUTION: The circulating screen capture system is characterized by including: a proxy server capable of temporarily preserving a screen image of HTML in the web application system as a cache; a URL circulating function for acquiring URLs of the web application system; an image capture for capturing screen images called in association with each URL acquired by the URL circulating function; and an image conversion tool for converting respective screen images acquired by the image capture. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a system that handles a screen image associated with development of a Web application system and manual creation thereof, and more particularly to a screen capture system.

  The Web application system is software for realizing each purpose such as creating a document, table, database, or the like using a computer connected to the Internet (Web), and a Web browser that is browsing software. It is a system that can be used via. This web application system has been developed and used in various fields regardless of whether it is large or small, or whether it is an individual or a corporation, and has spread to the general public with the rapid and worldwide spread of the web and higher functionality.

  There is HyperText Markup Language (HTML) as a language for describing Web pages that can be browsed on the Web. As is well known, this HTML language (hereinafter simply abbreviated as “HTML”) is used to describe the logical structure and appearance of a document, and it is also possible to embed images, sounds, moving images, etc. in a page. The HTML itself is a text file in which links to other documents, locations where image files are located, and the like are described by reserved words called tags specified in <>. The web browser is used to read and display the HTML file.

  The cache is a place where a personal computer (personal computer) that has been taken out is temporarily stored for the next use. The flow of data in and around the personal computer has a fast part and a relatively slow part, and a cache is used so that the fast part is not wasted.

  For example, the cache of the Web browser is used as follows. Although the processing in the personal computer is fast, the data from the web side will be slowed down via the telephone line, so put the “cache” in the meantime (between the browser and the web, physically the hard disk), the same for the second time When viewing a page, instead of going to the Web, the page is displayed with data in a cache (a substance is a file on a hard disk).

  Capturing refers to capturing a graphic (screen) image as a file or the like. For example, in Windows (registered trademark), a screen image at that moment can be transferred to the clipboard by pressing a “Print Screen” key in an arbitrary scene. Furthermore, if an expansion card called a capture card is additionally installed in a personal computer, it is possible to convert analog home video images to digital data and record them in a file in addition to still images.

  In addition, there is a large-scale system in which the number of screens exceeds 100 in corporate Web application systems. In that case, the man-hours and costs required for development naturally increase according to the scale. Therefore, in order to suppress an increase in development man-hours, a wide variety of comprehensive development environment tools that support large-scale Web application system development are widely used. However, when designing and developing the large-scale system, it is inevitable that unnecessary repetitive work occurs due to the large number of screens.

  Specifically, when developing a Web application system, when designing a screen for the screen in the design phase, which is a pure technical stage, and when creating a manual for the system almost before and after the completion of the design, Work to create a screen image may occur frequently. At that time, the entire screen in the system is stored in the personal computer by manual screen capture, and the size and / or file format is appropriately converted and used.

  FIG. 8 shows an actual screen image diagram (hereinafter simply referred to as “screen image”) and a simplified screen sample diagram (hereinafter simply referred to as “screen sample”). The screen image 801 shown in FIG. 8 includes colors and gray scales, and since the amount of data constituting the realistic screen image 801 is large, the processing burden on the system becomes heavy.

  If this real screen image 801 is used for manual creation or the like as it is, the processing load becomes heavy. Therefore, it is necessary to reduce the load, reduce man-hours, and reduce costs. Therefore, an appropriate method of substituting a sample of a pseudo screen simplified to black and white line drawing and text data by using draw software or the like, that is, a screen sample 802 is frequently used. The screen image 801 and the screen sample 802 are used in the following description in the meaning as defined in FIG.

  On the other hand, there is known a technique for adding a (World Wide Web) WWW content prefetch function to a personal information terminal such as a personal computer. According to the prefetch function addition technology, the requested WWW content is acquired from the WWW server apparatus by the WWW proxy unit.

  Incidentally, “Proxy” means “proxy”, WWW proxy unit means Proxy server (proxy server), and “WWW content” is a program including a moving picture of any size. This is used for Web distribution.

  As a processing procedure by the prefetch function addition technology, first, the content requested by the WWW browser unit in the personal information terminal is acquired from the WWW server device by the personal WWW proxy unit provided in the information terminal, and the WWW browser To the department.

  Next, the personal WWW proxy unit analyzes access requests to a plurality of contents, and measures user-specific access characteristic data indicating the access characteristics to the contents by the user.

  Based on the access characteristic data for each user, it is determined whether or not any link destination content specified by the link information included in the content acquired from the WWW server device is to be prefetched. When it is determined that the content should be prefetched, this includes a procedure of prefetching the linked content and storing it in the cache storage means provided in the personal WWW proxy unit (Patent Document 1).

  The WWW proxy unit is an application that relays communication between the internal network and the Web on behalf of a request from the internal client at a connection point between the internal network and the Web. Usually run on a firewall. While communication from the Web to the in-house network direction is blocked, access to the Web direction from the in-house network is specified by specifying a user or an application.

  “Caching” is another major function of the proxy server. In the HTTP (HyperText Transfer Protocol) proxy, the second and subsequent accesses are speeded up by storing pages accessed by the user. Note that HTTP is a communication protocol for transmitting and receiving a document described in HTML from a WWW server to a WWW client in an Internet WWW service.

  In addition, “patrolling” refers to sequentially referring to conference rooms and Web pages that are regularly accessed in BBS or Internet WWW access. The BBS access software and WWW access software have functions to register conference rooms and web pages that you want to refer to in advance, and automatically circulate them to save the latest information to a local hard disk. There are also things.

  The URL (Uniform Resource Locator) related to “tour” is a description format indicating the location of resources on the Internet. The root is a word representing the top portion of the hierarchical structure, and the “Web application root URL” is a URL for specifying a screen that is first displayed after a search.

The following patent document 1 is known as a known technical document related to the invention of the cyclic type screen capture.
JP 2003-323370 A

  However, the screen sample 802 by the draw software is simpler than the actual screen image 801 and has a completely different impression, which may cause the following problems.

(1) There is a high possibility that there will be a slight difference between the specifications required by the customer and the design recognized by the developer. This is because the actual screen image 801 is the screen itself provided to the customer, so that it is easy to understand from the accurate visual recognition of the screen design, layout, and functions, whereas the screen sample 802 This is because the shortage has to be supplemented by imagining the user without permission.

(2) The screen sample 802 naturally has a poor appearance. The actual screen image 801 represents the layout with high fidelity, and is not comparable in terms of appearance.
(3) It is necessary to confirm whether or not the screen sample 802 allows the customer. This is because if it becomes unacceptable, additional work for creating the screen image 801 occurs and the schedule goes wrong. For example, this corresponds to a case where a customer requests a real manual on which an actual screen image 801 is posted.

  In view of the above situation, the present invention solves the above-mentioned problems, and allows the cyclic screen capture system to be created in a batch manner without the trouble of duplicating operations in the screen image creation work of the system in the development of the Web application. The purpose is to provide.

  In order to achieve the above object, the invention according to claim 1 includes a proxy server capable of temporarily storing an HTML screen image in a web application system as a cache, a URL patrol function for acquiring the URL of the web application system, and the URL A patrol comprising: an image capture that captures a screen image called in association with each URL acquired by the patrol function; and an image conversion tool that converts each screen image acquired by the image capture. Type screen capture system.

The invention according to claim 1 has the following effects.
(1) With respect to the conventional manual screen image creation work that puts a heavy labor burden on the worker, the worker simply sets the “Web application root URL” and “creation image condition” and automatically The process is executed. Therefore, the man-hour required for the worker is reduced only to the setting work, and the man-hour and cost can be greatly reduced.

(2) In the conventional manual screen image creation where the screen image was created manually, a plurality of workers share the work, so “display browser, image size, file format, file It is difficult to unify display settings such as name, font, font size, etc. it can.

  In other words, the system 201 does not require a plurality of workers or tools, and screen images can be created by one user and one tool at a time.・ Unification of size becomes easy.

  In addition, the time required to create the necessary screen image can be reduced compared to the conventional work, reducing the man-hours and improving the productivity. That is, it is possible to create a screen image with only operations related to screen transition and slight setting work among screen transition, screen capture work, and image conversion work that have been conventionally required.

  In short, according to the present system 201, significant man-hour reduction and productivity improvement effects can be obtained. Especially in a large-scale system, further effects can be exhibited.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, general matters related to the present invention will be described in advance with reference to FIGS. 1 and 3, and the essence of the present invention will be described in detail with reference to FIGS. However, the following description will be made in the order of the numbers in the figure.

  FIG. 1 is a sequence diagram of a general (conventional) screen image creation operation. That is, in general Web application development, a screen image is created by the processing procedure shown in FIG. Note that the process numbers in (Process 104), (Process 106), (Process 108), (Process 111), and (Process 113) shown in FIG. 1 do not necessarily include serial numbers but also missing numbers. Further, the processes indicated by these (process codes) are executed by executing a corresponding program on a computer.

  In (Process 104), a system developer (hereinafter abbreviated as “developer”) 101 accesses the Web application system 103 via the browser 102. Then, the Web application system 103 creates an HTML file 105 in response to a request from the developer 101 and returns a response.

  In (Process 106), the HTML file 105 returned from the Web application system 103 is rendered by the browser 102 and displayed on the browser 102 window. Rendering refers to automatically generating a finally required image according to an instruction. In order to generate a realistic image by this rendering, a very large amount of CPU power and time are required.

  In (Process 108), the screen 107 displayed in the browser window is screen-captured to obtain the screen image 109 of the browser window.

  In (Process 111), image processing such as resizing and format conversion is performed on the screen image 109 captured on the screen by using the image conversion tool 110.

  In (Process 113), the converted screen image 112 is stored in an arbitrary image storage directory 114 designated by the developer 101 with an arbitrary file name. FIG. 1 illustrates still image data using a jpg file.

  In each process in the screen image creation work shown in FIG. 1, even if a rational and latest tool is used, the developer 101 needs to repeat the procedure for creating the screen image as many times as the number of screens to be captured. . Therefore, a web application with a large number of screens must be repeatedly operated.

  That is, when creating the screen image 801 of the Web application system 103, screen images are manually created for all screens on the system. Summarizing the main points of the repetitive work, the actual work is roughly divided into the following three work.

(1) Specifying a URL and obtaining an HTML file. In other words, the task of specifying which screen to get.
(2) Work to acquire an image of the display screen of the acquired HTML file.
(3) Work to edit the acquired screen image as appropriate.

  Since the three operations required for image creation are factors that increase the development man-hours, it will be described that these three operations can be automated by the cyclic screen capture system according to the present invention.

  FIG. 2 is a system configuration diagram showing an embodiment of the present invention. That is, FIG. 2 shows an overall combination including a cyclic screen capture system (hereinafter referred to as “this system”) 201. This system 201, a Web application system 202 that is a screen image acquisition destination, And an image storage destination directory 203.

  The system 201 includes a URL patrol function 204, a proxy server 205, an image capture 206, and an image conversion tool 207. The outline of the overall processing of the system 201 will be described later with reference to FIG.

  The detailed configuration of the Web application system 202 shown in FIG. 2 is linked from the root URL to each page, as will be described later with reference to FIG. The root URL is the top page of the system, and since the top page is linked to the child and grandchild pages, each of these pages can be browsed. A link is to connect to various Web servers using a browser on the Internet, and a connection destination is specified using hypertext described in HTML, and is also called a hyperlink.

  2 (process 208), the Web application system 202 sequentially transitions screen images 801 (FIG. 8) to be acquired, and caches the HTML corresponding to each screen image 801 in the proxy server 205.

  Next, a process for acquiring a URL specifying the cached HTML in the Web application system 202 will be described. This URL acquisition process is executed by the URL patrol function 204.

  FIG. 3 is a configuration diagram of a general Web application system. As shown in FIG. 3, the Web application is linked to each function from a root URL 301 that is the top page of the system (process 302 to process 304).

  Then, transition from the transition destination 305 to the transition destination 307 from the root URL 301 further transitions to the details of the function and a page for using the function. That is, the system is configured in a tree structure with the root URL 301 as a parent page.

  As described above, as a characteristic of the system in the Web application, the link spreads from the root URL 301 in a tree structure. Therefore, the user first selects the route URL 301 and then clicks a link to perform an operation for transitioning to a necessary screen.

  Here, if it is necessary to put a setting value or the like in each form, a series of screen transitions are performed while inputting a value to be acquired as the screen image 801. At that time, the program is executed so that the screen cache is automatically left in the proxy server 209 (FIG. 2).

  After the necessary transition of the screen image 801 is completed, after the user designates only the root URL 301, it is temporarily stored in the proxy server 209 as a cache and is called in association with the root URL 301 (hereinafter referred to as "link"). It is possible to automatically enumerate URL screens.

  Next, URL enumeration associated with each page of the enumerated URLs is repeated to acquire HTML of the entire system. Furthermore, a screen image of each HTML is automatically acquired, edited, and stored. It is programmed so that these processes can be executed as a unit. A recursive screen capture system according to the present invention has been established so that a computer can execute the program.

  FIG. 4 is a data structure diagram according to the URL list used in the embodiment. As shown in FIG. 4, each URL list is associated with indexes 0, 1, 2 to 11... For the purpose of URL management.

  FIG. 5 is a flowchart showing an outline of the overall processing of the embodiment. That is, the outline of the processing procedure of the present system 201 is shown, and includes four processes of a cache acquisition process (501), a URL acquisition process (502), a screen image capture process (503), and a screen image conversion process (504). A program including processing is executed by the computer.

  In FIG. 5, the cache acquisition process (501) is performed by transferring the HTML of the Web application system 202 to the proxy server 205 that can temporarily store the HTML screen image 801 (FIG. 5) in the Web application system 202 (FIG. 2) as a cache. This is a process of temporarily saving as a cache.

  The URL acquisition process (502) is a process of specifying the root URL of the Web application system 202 to circulate the linked URL linked to the root URL and listing the URLs that have been circulated.

  The screen image capture process (503) is a process of acquiring HTML for a plurality of pages from the URL list listed by the URL acquisition process (502) and capturing each screen image 801 corresponding to the acquired HTML. is there.

  The screen image conversion process (504) is a process for appropriately converting and saving the acquired screen image.

  Through a series of these processes, each screen image 801 corresponding to the URL list can be quickly searched and used.

  FIG. 6 is a flowchart illustrating details of the URL acquisition process according to the embodiment. The procedure of URL acquisition processing will be described with reference to other drawings as appropriate.

  As shown in FIG. 6, the size and file format of the image of the screen 801 to be acquired in advance are designated by (Processing 601). Next, in (Process 602), the root URL of the Web application system 202 to be acquired is designated.

  Then, in (Process 603), the root URL is stored in the 0th element of the URL list 210. Next (step 604), the HTML of the root URL stored in the 0th element is acquired, and the link destination URL on the HTML is acquired.

  In (Process 605), it is determined whether or not the HTML of the acquired URL is cached in the proxy server 205. If the result of the determination is that it has been cached (procedure 606), it is determined whether or not the acquired URL has been registered in the URL list 210.

In (Process 606), when it is determined that the URL has already been registered, the process proceeds to (Process 607), and the acquired URL is added to the end of the list.

If HTML is not cached in the proxy server 205 in (Process 605), or if it is determined that the URL is not registered in (Process 606), the process proceeds to (Process 608).

In (Process 608), it is determined whether or not a link still exists in the HTML of the URL of the element currently designated by the user. If there is a link, the process proceeds to (Process 609) and the URL of the next link destination is determined. Is acquired (processing 605). Then, (processing 605) to (processing 608) are repeated.

  In the above (Process 608), when there is no link, the process proceeds to (Process 610), and it is determined whether or not the next element of the currently specified URL list element exists. Here, if it is determined that it exists, the process proceeds to (Process 611) and (Process 609).

After (Process 611), the HTML of the URL of the element next to the element currently designated by the user is acquired, (Process 608) is executed, and after acquiring the URL of the next link destination by (Process 609) ( Return to step 605). Then, (processing 605) to (processing 608) are repeated.

  In (Processing 610), if it is determined that the next element does not exist as a result of determining whether or not the element next to the currently specified URL list element exists, the program of the URL acquisition process End execution.

  Through the URL acquisition processing so far, a URL having the root URL specified in (Process 602) as a parent is acquired. That is, all HTML URLs of the Web application system 202 cached in the proxy server 205 associated with the root URL are acquired.

  Next, a function for capturing the image of the URL destination screen and a function for appropriately converting the acquired screen image 801 and storing it are required. Hereinafter, a process for capturing a screen corresponding to each of the acquired URL lists 210 and a process for converting the screen image 801 will be described.

  FIG. 7 is a diagram showing details of screen image capture processing and screen image conversion processing. In (Process 701) shown in FIG. 7, the cyclic screen capture process is executed by the image capture function 206 and the image conversion tool 207. These are also processed by executing the program. First, URLs are acquired in ascending order from the 0th element to the last element in the URL list 210.

In (Process 702), HTML is acquired from the acquired URL, and the screen image capture function 206 captures the screen image 801.

In (Process 703), the captured screen image 801 is transferred to the image conversion tool 207.

In (Process 704), the screen image conversion tool 207 converts the size and file format of the transferred screen image 801 according to the information set in Process 601 (see Process 213 in FIG. 2).

In (Process 705), the converted file is stored in the image storage directory 203 arbitrarily determined by the user as the HTML file name as the image file name (see Process 214 in FIG. 2).

In (Process 706), (Process 701 to Process 705) is repeated until the URL extracted from the URL list 210 (see FIG. 4) becomes the last element.

As can be seen from the above description, the present system 201 has the following effects.
(1) With respect to the conventional manual screen image creation work that puts a heavy labor burden on the worker, the worker simply sets the “Web application root URL” and “creation image condition” and automatically The process is executed. Therefore, the man-hour required for the worker is reduced only to the setting, and the man-hour and cost can be greatly reduced.

(2) In the conventional manual screen image creation where the screen image was created manually, a plurality of workers share the work, so “display browser, image size, file format, file It is difficult to unify display settings such as name, font, font size, etc. it can.

  In other words, the system 201 does not require a plurality of workers or tools, and screen images can be created by one user and one tool at a time.・ Unification of size becomes easy.

  In addition, the time required to create the necessary screen image can be reduced compared to the conventional work, reducing the man-hours and improving the productivity. That is, it is possible to create a screen image with only operations related to screen transition and slight setting work among screen transition, screen capture work, and image conversion work that have been conventionally required.

  In short, according to the present system 201, significant man-hour reduction and productivity improvement effects can be obtained. Especially in a large-scale system, further effects can be exhibited.

It is a sequence diagram of general screen image creation work. It is a system configuration figure showing an embodiment. It is a block diagram of a general web application system. The data structure figure by URL list used by embodiment. It is a flowchart which shows the outline of the whole process of embodiment. It is a flowchart which shows the detail of the URL acquisition process in embodiment. It is a flowchart which shows the detail of the screen capture process in embodiment, and a screen image conversion process. It is an actual screen image diagram and a simplified screen sample diagram.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Developer 102 Browser 103 Web application system 110 Image conversion tool 114 Image saving directory 201 Recursive screen capture system (this system)
202 Web application system 203 Image storage directory 204 URL patrol function 205 Proxy server 206 Image capture 207 Image conversion tool 301 Root URL
305, 306, 307 Transition destination 801 (actual) screen image 802 screen sample (drawn with draw software)

Claims (1)

A proxy server that can temporarily store an HTML screen image in a Web application system as a cache;
A URL patrol function for acquiring the URL of the Web application system;
An image capture for capturing a screen image called in association with each URL acquired by the URL patrol function;
An image conversion tool for converting each screen image acquired by the image capture, and a recursive screen capture system.