JP6232145B2 - Screen specification analysis apparatus and method - Google Patents

Description

  The present invention relates to a screen specification analysis apparatus and method, and is suitable for application to a screen specification analysis apparatus that analyzes screen specifications of a web page (hereinafter referred to as a web screen) provided by a web server device, for example. .

  When a system is renewed, the specifications of the upstream design become ambiguous due to lack of understanding of the business content and the system to be renewed, resulting in a rework of system development, which increases the development cost and construction period. Yes. In order to prevent such rework of system development, it is important to investigate the current system in detail. A problem when investigating the current system is that the specification is often obsolete because a new specification was not added to the specification when the system was updated in the past.

  In view of such circumstances, a technique for directly grasping screen specifications (screen configuration and screen transition) from the current system has been proposed in Patent Document 1. According to the present technology, an operation procedure manual for a web application is generated based on information obtained by automatically circulating the web application.

  Patent Document 1 recursively acquires a web screen, captures a web screen, and extracts links included in the web screen, starting from a URL (Uniform Resource Locator) specified at the beginning. Thus, the transition of the web screen is comprehensively extracted. Next, the screen transitions of the web screen extracted as described above are manually grouped into business function units such as domestic travel expense application and domestic travel expense settlement, and a procedure manual is generated for each business function unit.

JP 2010-79342 A

  However, according to the technique disclosed in Patent Document 1, as described above, it is necessary to manually organize the screen transitions of the extracted web screens into business function units, and it takes time and effort to create a procedure manual. was there.

  On the other hand, when requesting a renewal of a system, the cost is determined based on the number of web screens provided by the system and the degree of complexity of each web screen (hereinafter referred to as complexity). Often done. Therefore, in order to estimate the cost with high accuracy, a contractor who has received a request for system renewal needs to accurately grasp the number of web screens in the current system and the complexity of each web screen. .

  In this case, among the web screens provided by the system, even if the URL is the same, it is counted as a separate item, as in the case of a specification in which a web screen with a different content is displayed even with the same URL depending on the presence or absence of login. There are web screens that should be counted as the same screen, even if they are different URLs, such as a web screen that should be used, “Diary 1”, “Diary 2”,.

  However, the technique disclosed in Patent Document 1 is based on the premise that URLs and web screens are statically corresponding one-to-one, and even if the same URL is to be counted as another web screen, or a different URL However, it cannot cope with the case where it should be counted as the same web screen.

  For this reason, even if the technique disclosed in Patent Document 1 is applied when performing such cost estimation, it is ultimately necessary to manually count the number of web screens and determine the complexity of the screen configuration. However, there was a problem that it took time and labor to prepare the cost estimate. In addition, when counting the number of web screens manually as described above, there is a problem that it is difficult to estimate costs with high accuracy because it is easy to cause duplicate count of the same screen and blurring of estimation accuracy due to forgetting to count the screen. there were.

  The present invention has been made in consideration of the above points, and facilitates the grasping of the specifications of the current system and the creation of the cost estimate at the time of system renewal etc., and the screen specification analysis that can improve the accuracy of the created cost estimate An apparatus and method is to be proposed.

  In order to solve such a problem, in the present invention, in the screen specification analysis device that analyzes the screen specification of the web screen provided by the server device, the operation log performed on the web screen is collected as an operation log, and A log collection unit that collects screen data of a web screen as a screen log, a scenario extraction unit that extracts a series of screen transitions as a scenario based on the operation log collected by the log collection unit, and the log collection unit Based on the screen log, the screen feature value calculation unit that calculates one or more feature values of each of the web screens, and the feature value of each of the web screens calculated by the screen feature value calculation unit A scenario merging unit that merges the similar scenarios, and a screen specification that outputs a screen specification that represents the screen transition specifications for each scenario after merging. It was to be provided and the specification output section.

  Further, in the present invention, in the screen specification analysis method executed by the screen specification analysis device that analyzes the screen specification of the web screen provided by the server device, the screen specification analysis device performs an operation performed on the web screen. A first step of collecting a log as an operation log and collecting screen data of the web screen as a screen log, and a series of screen transitions as scenarios based on the operation log collected by the screen specification analyzer A second step of extracting, and the screen specification analyzer calculates one or more feature quantities of each web screen based on the screen log, and based on the calculated feature quantities of each web screen A third step of merging the similar scenarios together, and the screen specification analyzing device determines a screen transition specification for each scenario after merging. It was provided and a fourth step of outputting to the screen specifications.

  According to this screen specification analysis apparatus and method, it is easy to grasp the specifications of the current system, and the user who uses the screen specification analysis apparatus counts the same web screen repeatedly or estimates accuracy due to forgetting to count the web screen. Therefore, it is possible to estimate the cost when the system is renewed with high accuracy.

  According to the present invention, it is possible to facilitate the work of grasping the specifications of the current system and creating a cost estimate at the time of system renewal, etc., and improving the accuracy of the created cost estimate.

It is a block diagram which shows the whole structure of the screen specification analysis system by this Embodiment. It is a block diagram which shows the logic structure of this screen specification analysis system. It is a conceptual diagram which shows an operation log table. It is a conceptual diagram which shows a screen log table. It is a conceptual diagram which shows the scenario table before merge. (A) is a conceptual diagram showing a first post-merging scenario table, and (B) is a conceptual diagram showing a second post-merging scenario table. It is a sequence diagram which shows the flow of a log collection process. It is a flowchart which shows the process sequence of a screen specification analysis process. It is a flowchart which shows the process sequence of a scenario extraction process. It is a table | surface used for description of a screen feature-value calculation process. It is a table | surface used for description of a screen feature-value calculation process. It is a flowchart which shows the process sequence of a scenario merge process. It is a basic diagram which shows the structural example of a start screen with which it uses for description of the specific example of the screen specification analysis process by this Embodiment. It is a basic diagram which shows the structural example of the main menu screen in which it uses for description of the specific example of the screen specification analysis process by this Embodiment. It is a basic diagram which shows the structural example of the day return adjustment report screen with which it uses for description of the specific example of the screen specification analysis process by this Embodiment. It is an approximate line figure showing an example of composition of a domestic day return settlement temporary storage list screen for explanation of a specific example of screen specification analysis processing by this embodiment. (A)-(D) are the conceptual diagrams which show the specific example of the scenario extracted by the scenario extraction process. (A)-(C) are the conceptual diagrams which show the specific example of the scenario merged by the scenario merge process. It is a basic diagram which shows the structural example of a screen specification screen. It is a basic diagram which shows the structural example of a screen specification screen. It is a basic diagram which shows the structural example of a screen list screen.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

(1) Configuration of Screen Specification Analysis System According to this Embodiment In FIG. 1, 1 indicates the overall configuration of the screen specification analysis system according to this embodiment as a whole. The screen specification analysis system 1 includes one or a plurality of client devices 2, a web server device 3, and a screen specification analysis device 4, which are connected to each other via a network 5.

  The client device 2 is a computer device used by a user to access the web server device 3 to view and use a necessary web screen, and includes a processor 10, a memory 11, a network interface 12, and an input / output device 13. Composed.

  The processor 10 is hardware having a function for controlling operation of the entire client device 2. The memory 11 is composed of, for example, a semiconductor memory, and is used for storing and holding various programs such as the web browser program 14 and the script engine program 15, and is also used as a work memory for the processor 10. When the processor 10 executes various programs stored in the memory 11, various processes as the entire client apparatus 2 are executed.

  The network interface 12 is an interface for the client device 2 to communicate with the web server device 3 via the network 5, and is configured by, for example, a NIC (Network Interface Card). The input / output device 13 includes an input device that is used to input necessary instructions and information to the client device 2 by the user, and an output device that displays a web screen downloaded from the web server device 3 in response to a user operation. Composed. The input device is composed of, for example, a keyboard and a mouse, and the output device is composed of, for example, a liquid crystal display.

  The web server device 3 responds to a request from the client device 2 given via the network 5, for example, a start screen 60 described later with reference to FIG. 13, a main menu screen 70 described later with reference to FIG. 14, and a date described later with reference to FIG. 15. This is a server device having a function of transmitting screen data of various business web screens such as the home account settlement screen 80 or the domestic day return settlement temporary storage list screen 100 described later with reference to FIG.

  The web server device 3 includes a processor 20, a memory 21, a network interface 22, an input / output device 23, and a local disk 24. The processor 20, the memory 21, the network interface 22, and the input / output device 23 have the same functions and configurations as the corresponding parts (the processor 10, the memory 11, the network interface 12, or the input / output device 13) of the client device 2. Therefore, the description here is omitted. A web server program 25 and a web application program 26 are stored in the memory 21 of the web server device 3.

  The local disk 24 is composed of, for example, a hard disk device, SSD (Solid State Drive) or RAID (Redundant Arrays of Inexpensive Disks), etc., and HTML (Hypertext Markup Language) of various web screens provided by the web server device 3 to the client device 2. The screen data in the format is stored as an HTML file 27, respectively.

  The screen specification analysis device 4 is a server device having a function of generating a screen specification document to be described later and presenting it to the user of the screen specification analysis device 4, and includes a processor 30, a memory 31, a network interface 32, and an input / output device 33. And a local disk 34. Since the processor 30, the memory 31, the network interface 32, and the input / output device 33 have the same functions and configurations as the corresponding parts of the client device 2, description thereof is omitted here. The memory 31 of the screen specification analysis device 4 stores a log collection server program 35, a screen specification analysis program 36, and a screen specification output program 37.

  The local disk 34 includes, for example, a hard disk device, SSD, or RAID, and is used to store and hold an operation log table 38, a screen log table 39, a scenario table 40, and the like which will be described later.

(2) Screen specification analysis function according to this embodiment (2-1) Outline and table configuration of screen specification analysis function Next, the screen specification analysis function installed in the screen specification analysis device 4 of the screen specification analysis system 1 explain. The screen specification analysis device 4 includes a log of operations performed on the web screen by the user of the client device 2 (hereinafter referred to as an operation log) and screen data (when the web screen is loaded and unloaded) ( Hereinafter, these are collectively referred to as screen logs) from each client device 2, and based on these collected operation logs and screen logs, screen transitions of a series of web screens according to user operations, The screen specification analysis function that analyzes the complexity of the web screen is installed.

  In practice, the screen specification analysis device 4 collects such operation logs and screen logs from the respective client devices 2, and based on the collected operation logs and screen logs, a series of screen transitions corresponding to user operations are used as scenarios. Extract. Then, the screen specification analysis device 4 determines the similarity between the scenarios extracted in this way. The similar scenarios are merged as one scenario, and then the screen specification representing the screen transition state of the web screen is converted into the scenario. Each screen is generated and the generated screen specifications are displayed on the input / output device 33. Further, the screen specification analysis device 4 calculates the complexity of each web screen constituting each scenario based on the operation log and the screen log, and displays a list of the calculated complexity of each web screen.

  As a means for realizing such a screen specification analysis function, in the case of this screen specification analysis system 1, as shown in FIG. 2, the client device 2 is equipped with a web browser module 50 and a script engine module 51, A web server module 52 and a web application module 53 are mounted on the web server device 3, and a log collection server module 54, a screen specification analysis module 55 and a screen specification output module 56 are mounted on the screen specification analysis device 4. .

  These “modules” execute “programs” corresponding to the processor 10 (FIG. 1) of the client device 2, the processor 20 (FIG. 1) of the web server device 3, or the processor 30 (FIG. 1) of the screen specification analysis device 4. This is a function embodied by doing so. For example, the web browser module 50 and the script engine module 51 are functions embodied by the processor 10 of the client device 2 executing the web browser program 14 (FIG. 1) or the script engine program 15 (FIG. 1), respectively. The web server module 52 and the web application module 53 are functions realized by the processor 20 of the web server device 3 executing the web server program 25 (FIG. 1) or the web application program 26 (FIG. 1). Further, the log collection server module 54, the screen specification analysis module 55, and the screen specification output module 56 are respectively stored in the log collection server program 35 (FIG. 1), the screen specification analysis program 36 (FIG. 1), or the processor 30 of the screen specification analysis device 4. This is a function embodied by executing the screen specification output program 37 (FIG. 1).

  Then, the web browser module 50 of the client device 2 sends a request for displaying the web screen (hereinafter referred to as a page display request) to the network 5 when an operation input for displaying the web screen is given by the user. To the web server device 3.

  When the web application module 53 of the web server device 3 receives the page display request, the screen data of the web screen specified in the page display request is stored in the corresponding HTML file 27 (FIG. 1) stored in the local disk 24 (FIG. 1). After embedding a script code (hereinafter referred to as an operation log recording script code) for recording the operation performed by the user on the web screen as an operation log, the screen data read from FIG. 1) is embedded. The response is transmitted to the client apparatus 2 via the network 5.

  The web browser module 50 of the client device 2 that has received the response displays the web screen designated by the user on the input / output device 13 (FIG. 1) based on the screen data included in the received response, and the screen data. The operation log recording script code embedded in is extracted and output to the script engine module 51.

  The script engine module 51 executes the operation log recording script code given from the web browser module 50 to appropriately generate the operation log described above, and outputs the generated operation log to the web browser module 50. In addition to the operation log, the script engine module 51 stores screen data when the web screen is loaded and unloaded as a screen log, and outputs the stored screen log to the web browser module 50.

  Then, the web browser module 50 transmits the operation log and the screen log given from the script engine module 51 to the screen specification analyzing apparatus 4 via the network 5 at the timing when the corresponding web screen is unloaded.

  As described above, the technique disclosed in Japanese Patent Application Laid-Open No. 2009-104267 (US Patent Application Publication No. 2009-0106769) can be applied as a technique for embedding the recording script code in the screen data of the web screen. The technique disclosed in Japanese Patent Application Laid-Open No. 2011-060196 (US Patent Application Publication No. 2011-0066704) is applied as a technique for recording the operation performed by the user on the web screen as an operation log using a recording script. can do.

  The log collection server module 54 of the screen specification analysis apparatus 4 is a module having a function of collecting and managing operation logs and screen logs respectively given from the client apparatuses 2 and stores the collected operation logs in the operation log table 38. At the same time, the collected screen log is stored in the screen log table 39.

  The screen specification analysis module 55 of the screen specification analysis device 4 analyzes individual web screens provided by the web server device 3, extracts scenarios based on the analysis results, and calculates the complexity of individual web screens. A scenario extraction function 55A, a screen feature amount calculation function 55B, a scenario merge function 55C, and a screen complexity calculation function 55D.

  Then, the screen specification analysis module 55 uses the scenario extraction function 55A to perform a series of screen transitions according to user operations based on the operation log stored in the operation log table 38 and the screen log stored in the screen log table 39. Are extracted as scenarios. Further, the screen specification analysis module 55 calculates n types (n is a positive number of 1 or more) of each feature amount for each web screen constituting each scenario by the screen feature amount calculation function 55B, and calculates the calculated n types. An n-dimensional feature vector is generated from the feature quantity.

  The screen specification analysis module 55 determines the similarity between scenarios based on the feature vector of each web screen generated as described above by the scenario merging function 55C, and merges similar scenarios into one scenario. Generate screen specifications for each scenario. Further, the screen specification analysis module 55 calculates the complexity of each web screen by the screen complexity calculation function 55D.

  Furthermore, the screen specification output module 56 determines the screen specification for each scenario generated as described above and the complexity of each web screen according to the request from the user, according to the input / output device 33 (see FIG. Displayed in 1).

  A specific configuration of the operation log table 38 is shown in FIG. As is apparent from FIG. 3, the operation log table 38 includes a page ID column 38A, a time column 38B, an event column 38C, an object column 38D, and an attribute column 38E.

  The page ID column 38A stores a unique identifier (page ID) assigned to the web screen every time the client device 2 loads the web screen in response to a user operation. Stores the types of events and supplementary information that occurred between loading and unloading the web screen. As events, for example, reading of the web screen is completed (“load”), a value is input to a text box (“change”), input information is transmitted (“submit”), and the web screen is closed (“unload”). and so on. As supplementary information, for example, to track a URL (Uniform Resource Locator) (“url”) of a web screen, a URL (“referer”) of a web screen that is a transition source to the web screen, and a series of screen transitions of a user Identifier ("trackingid") and the screen name of the web screen ("pageTitle").

  In the object column 38D, the target of the event stored in the event column 38C is stored in the XPath (XML Path Language) format. For example, in the example of FIG. 3, the “change” event indicates that the first INPUT element in the first DIV element in HTML is the event generation source. In the case of an event for the entire web screen or supplementary information such as a “load” or “url” event, “HTML [0]” is stored as an object.

  Furthermore, the attribute column 38E stores the attribute information of the target of the corresponding event. For example, in the case of the example in FIG. 3, the URL of the web screen loaded at that time (“URL2”) is stored in the attribute field 38E for the event “url”, and the event “referer” is The URL (“URL1”) is stored in the attribute column 38E. In addition, for the event “pageTitle”, the screen name of the web screen “Nichiki Seicho” is stored in the attribute column 38E, and for the event “change”, the purpose entered in the business trip purpose column is stored. .

  Furthermore, the time column 38B stores the time when the corresponding event occurred. In FIG. 3, “load” to “trackingid” are actually events that occurred at the same time, but in this embodiment, the order of occurrence of events is also managed in the operation log table, and therefore, for convenience. These events are registered in the operation log table 38 as occurring at different times.

  As shown in FIG. 4, the screen log table 39 includes a page ID column 39A, a time column 39B, an HTML column 39C, and an event column 39D.

  The page ID column 39A stores the page ID assigned to each web screen in which the operation log is stored and held in the operation log table 38, and the event column 39D stores either the load or unload event name. ("Load" or "unload") is stored. The time column 39B stores the time when the corresponding event (“load” or “unload”) is executed.

  Further, in the HTML column 39C, when the corresponding event is “load” (“load”), the screen data in the HTML format at the time of loading the corresponding web screen is stored as it is, and the corresponding event is unloaded (“unload” "), The screen data in the HTML format when the corresponding web screen is unloaded is stored as it is.

  On the other hand, the scenario table 40 includes a pre-merging scenario table 41 shown in FIG. 5 and first and second post-merging scenario tables 42 and 43 shown in FIGS. 6A and 6B, respectively.

  Among these, the pre-merger scenario table 41 is a table used for managing individual scenarios extracted based on the operation log stored in the operation log table 38. As shown in FIG. 5, the scenario ID column 41A is used. , A transition list column 41B and a scenario name column 41C.

  The scenario ID column 41A stores an identifier (scenario ID) unique to the scenario assigned to the corresponding scenario, and the transition list column 41B stores the transition list of the scenario. The transition list is a list in which page IDs respectively assigned to a series of web screens constituting the scenario are arranged in the same order as the transition order of the corresponding web screens.

  The scenario name column 41C stores the name of the corresponding scenario (scenario name). In the case of this embodiment, in the corresponding scenario, the scenario name is a list of screen component (link or button) labels that have been triggered by the transition from one web screen to the next web screen in the order of transition of the web screen. The scenario name is stored in the scenario name column 41C.

  The first post-merging scenario table 42 is a table used for managing the feature vectors of the web screens constituting each scenario obtained by the merging process. As shown in FIG. It consists of an ID column 42A and a feature vector column column 42B. The scenario ID column 42A stores scenario IDs assigned to the respective scenarios after the merging process, and the feature vector column column 42B stores the web screen corresponding to the feature vector of each web screen constituting the corresponding scenario. A feature vector sequence arranged in the order of transition is stored. Details of the feature vector will be described later with reference to FIGS.

  Further, the second post-merging scenario table 43 is a table used for managing which scenario and which scenario are merged by the merging process. As shown in FIG. 6B, the scenario ID column 43A And the merged scenario column 43B. The scenario ID column 43A stores the scenario ID assigned to each scenario after the merge process, and the merged scenario column 43B stores the scenario IDs of all scenarios merged with the corresponding scenario. The

(2-2) Flow of Various Processes Related to This Screen Specification Analysis Function (2-2-1) Log Collection Process Flow FIG. 7 shows the operation log and screen log of each client device 2 by the screen specification analysis device 4. A series of log collection processing to be collected is shown.

  This log collection process is started when the web browser module 50 of the client device 2 transmits a page display request to the web server device 3 in response to a user operation (SP1). When the web server device 3 receives this page display request (SP2), the web server module 52 calls the web application module 53, and the called web application module 53 receives a necessary response (operation log of the designated web screen). The screen data embedded with the recording script code) is transmitted to the client apparatus 2 (SP3).

  In the client device 2, when the web browser module 50 receives the response (SP4), the web browser module 50 calls the script engine module 51. Then, the called script engine module 51 generates a page ID on the web screen to which the screen data is transmitted from the web server device 3 at that time, and also creates a DOM (Document Object Model) event handler for recording the operation log. Register in the web browser module 50 (SP5). The script engine module 51 acquires screen data of the web screen from the web browser module 50 (SP6). Such acquisition of screen data can be realized by traversing the DOM of the web screen and reconstructing it as HTML format screen data. By using the DOM data, the screen data can be acquired together with the data input by the user.

  Thereafter, the script engine module 51 generates an operation log each time an operation is performed on the web screen, and sequentially adds the generated operation log to the operation log array (SP7). Further, when the web screen is unloaded, the script engine module 51 obtains the screen data of the web screen at that time from the web browser module 50, the page ID of the web screen generated in step SP5, and step SP6. Is sent to the screen specification analyzer 4 and the screen data acquired in step SP6 and the screen data acquired when the web screen is unloaded are sent to the screen specification analyzer 4 as screen logs. (SP8).

  In the screen specification analysis apparatus 4, the log collection server module 54 receives these page ID, operation log array, and screen log, and additionally registers the received operation log array in the operation log table 38 in association with the received page ID. At the same time, the screen log received at that time is additionally registered in the screen log table 39 in association with the page ID received at that time (SP9).

(2-2-2) Screen Specification Analysis Process (2-2-2-1) Screen Specification Analysis Process Flow On the other hand, FIG. The process procedure of the screen specification analysis process performed by the analysis module 55 is shown. The screen specification analysis module 55 analyzes the screen specification of the web screen provided by the web application module 53 of the web server device 3 in accordance with the processing procedure shown in FIG.

  In practice, the screen specification analysis module 55 refers to the operation log table 38 and extracts a series of screen transitions corresponding to user operations as scenarios (SP10). Further, the screen specification analysis module 55 calculates a feature vector of each web screen constituting the scenario for each extracted scenario, and generates a feature vector sequence by arranging the calculated feature vectors of each web screen in the order of transition. Then, the generated feature vector string is associated with the scenario ID of the scenario and registered in the first post-merger scenario table 42 (FIG. 6A) (SP11).

  Next, the screen specification analysis module 55 merges similar scenarios into one scenario based on the feature vector of each screen calculated in step SP11 (SP12), and thereafter, for each scenario after merging, the scenario The name of the scenario (scenario name) is generated based on the screen data of each web screen that transitions in (SP13). Then, the screen specification analysis module 55 thereafter ends this screen specification analysis processing.

(2-2-2-2) Scenario Extraction Processing FIG. 9 shows the specific processing contents of step SP10 (FIG. 8) of the screen specification analysis processing. The screen specification analysis module 55 uses the scenario extraction function 55A (FIG. 1) to extract a scenario according to the processing procedure shown in FIG.

  In this case, in the case of the present embodiment, the screen specification analysis device 4 preliminarily stores information for determining each web screen for the start and end of screen transition for each business function (hereinafter referred to as start or end screen determination). (Referred to as information). The screen specification analysis module 55 stores and manages the start or end screen determination information in the local disk 34, and determines the range from the start to the end of the screen transition recognized based on the start or end screen determination information. Extract as a scenario. As the start or end screen determination information, a URL or an identifier of a screen component that triggers screen transition (XPath or ID attribute such as a link or button) is applied. The start or end screen may be the first or last web screen of the screen transition, instead of defining the start or end screen determination information in advance.

  In the case of the present embodiment, the screen specification analysis apparatus 4 includes a specific screen transition pattern and a specific URL pattern of each web screen constituting the screen transition as conditions for not extracting the screen transition as a scenario. A pattern of a specific character string included in the web screen constituting the screen transition is given in advance. The screen specification analysis module 55 stores and manages these conditions in the local disk 34, and extracts a scenario by excluding screen transitions that satisfy any of these conditions. By applying this exclusion condition, it is possible to exclude screen transitions that are unnecessary as scenarios, such as repetition of the same screen and error screens.

  In practice, when the screen specification analysis module 55 proceeds to step SP10 of the screen specification analysis processing, the screen specification analysis module 55 starts the scenario extraction processing shown in FIG. 9 and first registers it in the page ID column 38A of the operation log table 38 (FIG. 3). One unprocessed page ID is acquired from the set page IDs (SP20).

  Subsequently, the screen specification analysis module 55 is a web screen at the start of screen transition in which the web screen to which the page ID acquired in step SP20 is assigned is recognized based on the start or end screen determination information. It is determined whether or not there is a web screen that is the last web screen of the screen transition recognized based on the start or end screen determination information (SP21). At this time, the screen specification analysis module 55 refers to the operation log table 38 (FIG. 3) to determine whether or not there is a web screen as a transition destination. This is done by determining whether or not there is an operation log for a link or a button for screen transition in the operation log.

  When the screen specification analysis module 55 obtains an affirmative result in this determination, the operation log table displays the label information of the labels attached to the screen parts such as links and buttons that have triggered the transition of the screen on the transition source web screen. 38 from the operation log table 38 (SP23), and then returns to step SP21.

  Thereafter, the screen specification analysis module 55 repeats the loop of step SP21 to step SP23 to step SP21 until a negative result is obtained in step SP21. Thereby, the screen specification analysis module 55 can extract a screen transition of a series of web screens according to a user operation as a scenario.

  When the screen specification analysis module 55 eventually obtains a negative result in step SP21 by reaching the last web screen of the screen transition recognized based on the start or end screen determination information, the scenario extracted at that time is shown in FIG. A new registration is made in the pre-merger scenario table 41 (SP24). Specifically, the screen specification analysis module 55 generates a transition list in which the page IDs of the web screens constituting the scenario are arranged in the transition order, and stores the generated transition list in the transition list column 41B of the pre-merger scenario table 41. To do. Further, the screen specification analysis module 55 assigns a scenario ID to the scenario and stores the scenario ID in the scenario ID column 41A. Further, the screen specification analysis module 55 generates a scenario name by arranging the label information of each web screen acquired in the loop of step SP21 to step SP23 to step SP21 in the order of acquisition, and the generated scenario name is stored in the scenario name column 41C. Store.

  Next, the screen specification analysis module 55 determines whether or not the processing of step SP21 to step SP24 has been completed for all page IDs registered in the operation log table 38 (SP25). When the screen specification analysis module 55 obtains a negative result in this determination, it returns to step SP21, and thereafter repeats the loop of step SP21 to step SP25 to step SP21. As a result, the screen specification analysis module 55 can extract the related scenarios for all the page IDs registered in the operation log table 38.

  Then, when the screen specification analysis module 55 eventually obtains a positive result in step SP25 by completing the processing of steps SP21 to SP24 for all the page IDs registered in the operation log table 38, it ends this scenario extraction processing. To do.

(2-2-2-3) Screen Feature Quantity Calculation Process The screen specification analysis module 55 uses the scenario extracted in step SP10 by the screen feature quantity calculation function 55B in step SP11 of the screen specification analysis process described above with reference to FIG. Each of the n types of feature values of the web screens constituting the scenario is calculated for each, and some or all of the calculated n types of feature values are weighted as necessary, and these weighted n types of features are calculated. An n-dimensional feature vector is generated based on the quantity.

  In the case of the present embodiment, as shown in FIG. 10, the feature amount of the web screen is the URL, HTML, link label, screen name, transition source web screen (hereinafter referred to as transition source). (Referred to as a screen) and input item names.

  For example, for a URL, HTML, and screen name, a hash value of a part or all of label information representing the URL, HTML, or screen name included in the web screen is set as one of the feature values of the web screen. As for the label of the link, the hash value of part or all of the label information indicating the label given to the screen component (button, link, etc.) that triggered the transition to the web screen on the transition source screen is displayed on the web. One of the screen feature values. Furthermore, for the link of the transition source screen, part or all of the screen structure of the screen component that triggered the transition to the web screen in the transition source screen (for example, XPath or ID attribute indicating the position on the HTML document structure). Is one of the feature values of the web screen. Furthermore, regarding input items, a combination of input items is set as one of the feature amounts for some or all of the items input by the user on the transition source screen.

  In the case of the present embodiment, as shown in FIG. 11, which feature value is weighted is set by the user of the screen specification analyzer according to the type of the web screen. For example, when the web screen is uniquely associated with a URL as in static content, the feature amount calculated based on the URL greatly affects (for example, the weight of the feature amount calculated based on the URL) If the URL is difficult to associate with a URL, such as when the web screen uses a framework, the weight is applied to some or all of the feature values. The weights of some or all of the feature quantities are weighted so that the feature quantities calculated based on (1) are greatly affected (for example, the weights of feature quantities calculated based on HTML are increased and the weights of other feature quantities are decreased).

(2-2-2-4) Scenario Merge Processing On the other hand, FIG. 12 shows specific processing contents of step SP12 of the screen specification analysis processing described above with reference to FIG. The screen specification analysis module 55 uses the scenario merging function 55C (FIG. 1) to merge similar scenarios among the scenarios extracted in step SP10 of the screen specification analysis process according to the processing procedure shown in FIG.

  In practice, when proceeding to step SP12 of the screen specification analysis process, the screen specification analysis module 55 starts the scenario merging process shown in FIG. 12, and first, an unprocessed scenario is selected from the pre-merger scenario table 41 (FIG. 5). One is selected (SP30).

  Subsequently, the screen specification analysis module 55 extracts all unprocessed scenarios similar to the scenario selected in step SP30 (hereinafter referred to as the selected scenario) from the pre-merger scenario table 41 (SP31).

  As a technique for extracting a scenario similar to the selected scenario, for example, cluster analysis can be used. When using cluster analysis, first, cluster analysis is performed on the feature vector of each web screen calculated by the screen feature amount calculation processing described above with reference to FIGS. 10 and 11, so that each web screen of each scenario is converted into a similar screen group. Classify. Thereafter, the corresponding screen group among the screen groups in which the page IDs of the transition lists respectively stored in the respective transition list fields 41B of the respective rows (records) of the pre-merger scenario table 41 described above with reference to FIG. 5 are classified as described above. Replace with the cluster number. Then, a scenario in which the cluster number column (cluster number column) obtained in this way matches the cluster number column of the selected scenario is extracted as a scenario similar to the selected scenario. Specific methods for cluster analysis include, for example, “BSEveritt: Cluster Analysis, Edward Arnold, third edition, ISBN 13: 9780340584798” and “Toshihiro Kamisu” clustering method in the data mining field (1)-using clustering. let's see! -The method disclosed in "Journal of the Japanese Society for Artificial Intelligence, vol.18, no.1, pp.59-65 (2003)" can be used.

  Next, the screen specification analysis module 55 determines whether there is a scenario that can be merged with the selected scenario from the scenarios extracted in step SP31 (SP32).

  If there is no scenario that can be merged, a negative result is obtained in step SP32. In this case, the process proceeds to step SP34.

  If there is a scenario that can be merged, a positive result is obtained in step SP32. In this case, the screen specification analysis module 55 registers the selected scenario in the first post-merging scenario table 42 (FIG. 6A) and can be merged with the selected scenario in association with the scenario ID of the selected scenario. The scenario ID of the scenario is registered in the second merged scenario table 43 (FIG. 6B) (SP33).

  Specifically, the screen specification analysis module 55 stores the scenario ID of the selected scenario in the scenario ID column (42A) of an unused line (record) in the first merged scenario table 42. . Further, the screen specification analysis module 55 generates a feature vector sequence in which the feature vectors of the web screens constituting the selected scenario are arranged in the order of transition of the corresponding web screen, and the generated feature vector sequence is the first post-merging scenario table 42. Are stored in the feature vector column column 42B of the above-described row.

  The screen specification analysis module 55 stores the scenario ID of the selected scenario in the scenario ID column 43A of the second post-merging scenario table 43, and all the scenarios that can be merged with the selected scenario extracted in step SP31 and step SP32. The scenario ID is stored in the corresponding merged scenario column 43B of the second merged scenario table 43, respectively. As described above, the selected scenario and the similar scenario are merged.

  By merging using the above feature vectors, it is possible to distinguish scenarios that should be recognized as different web screens, such as cases where web screens with different functions are displayed even with the same URL, and to extract scenarios. Examples of such a case include a case in which a different screen is displayed depending on whether or not the user has logged in, and a case in which information specifying the screen is not included in the URL using the application framework.

  Thereafter, the screen specification analysis module 55 determines whether there is a scenario that has not been processed in steps SP30 to SP33 among the scenarios registered in the pre-merger scenario table 41 (SP34).

  When the screen specification analysis module 55 obtains a negative result in this determination, it returns to step SP30, and thereafter repeats the processing of step SP30 to step SP34 until a positive result is obtained at step SP34. When the screen specification analysis module 55 eventually obtains a positive result in step SP34 by completing the merging process for all the scenarios registered in the pre-merger scenario table 41, it ends this scenario merging process.

(2-2-3) Screen Complexity Calculation Processing On the other hand, the screen specification analysis module 55 includes the number of items that can be input on each web screen (hereinafter referred to as the number of items that can be input), the number of output items, and the web One or more of the number of items actually input on the screen (hereinafter referred to as the number of input items) is acquired based on the operation log and the screen log, and each web is acquired based on the acquired information. Calculate the complexity of each screen.

  Note that the number of items that can be input can be obtained as the total number of portions that can be input or selected by the user, such as text boxes, check marks, and pull-down buttons. The number of output items can be obtained as the total number of locations where the output content of the web screen changes depending on the user or transaction. The determination of the location where the output content of the web screen changes can be realized by comparing the screen data of the screen log table 39. Further, the number of input items can be obtained as the total number of locations that the user has input or selected on the web screen.

As a specific calculation method of the complexity of the web screen, the complexity of the web screen is C, and the average value of the number of items that can be input, the number of output items, and the number of input items on the target web screen is xave, yave, zave, the maximum number of items that can be input, the number of output items, and the number of input items through all the web screens, xmax, ymax, zmax Can be applied by the following equation, where α is β, β, and γ, respectively.

  According to this method, normalization can be performed so that the maximum value of the complexity is α + β + γ regardless of the type of web application that displays the web screen.

  The screen specification analysis module 55 registers the screen data in the screen log table 39 when the input / output device 33 of the screen specification analysis device 4 is operated and an instruction to display the complexity of the web screen is input. With respect to all the web screens, the complexity of the screen at the time of loading is calculated, and the obtained complexity of each web screen is compiled into a list and displayed on the input / output device 33 of the screen specification analyzer 4.

(2-3) Specific Example Next, a specific example of the screen specification analysis function according to the present embodiment as described above will be described with reference to FIGS.

  13 to 16 show an example of a scenario displayed on the input / output device 13 (FIG. 1) of the client device 2 by a user operation. FIG. 13 shows a start screen 60 in which a user ID text box 61, a password text box 62, and a login button 63 are displayed.

  Then, the user operates the input / output device 13 to input the user ID into the user ID text box 61, and after inputting the password into the password text box 62, the user clicks the login button 63. The menu screen 70 can be displayed on the input / output device 13 of the client device 2.

  The main menu screen 70 is divided into a general menu field 71 in which menus for general users are displayed and an administrator menu field 72 in which menus for administrators are displayed.

  In the general menu field 71, character strings “application (prior)”, “one-day settlement” and “accounting for accommodation” are displayed as a menu for “domestic business trip”, and as a menu for “overseas business trip”, The strings “Application (advance)” and “Checkout” are displayed.

  In the administrator menu field 72, character strings “application” and “settlement” are displayed as a menu for “approval / return processing”, and a menu for “approval history search / approval cancellation” is also displayed. Character strings “Application” and “Payment” are displayed.

  Each of these character strings has a link to the corresponding web screen, and thus the user or the administrator clicks on the desired character string to proceed to the web screen corresponding to the character string. be able to.

  FIG. 15 shows a one-day adjustment account screen 80 displayed by clicking the character string “Nichi-Jo adjustment” displayed as the “domestic business trip” menu in the general menu on the main menu screen 70. In this one-day settlement report screen 80, a plurality of text boxes 81 to 85 for inputting a business trip date, a business trip purpose, and transportation costs (departure place, arrival place, summary and boarding amount), and travel expenses are divided into a plurality of departments. When the apportionment is made, the burden apportioning check box 87 to be checked, the text box 86 for inputting the apportioning department when the travel expenses are apportioned by a plurality of departments, the approval request button 89, and the temporary save button 90 And a delete button 91 are displayed.

  On the Nichi-Jo report screen 80, necessary information such as the date of business trip, purpose of business trip, transportation cost (departure place, destination, summary and boarding amount) is entered in the required text boxes 81-87, and then an approval request button By clicking 89, it is possible to return to the main menu screen 70 (FIG. 14) after transferring the information entered on the one-day settlement account screen 80 to the user having the authorization authority. In addition, on the one-time adjustment report screen 80, when the approval request button 89 is clicked in a state where a check mark is displayed in the burden apportioning check box 87, the apportioning setting screen (not shown) can be transitioned to.

  Further, on the one-day settlement account screen 80, by clicking the delete button 91, it is possible to return to the main menu screen 70 after discarding the information input in the text boxes 81-87. Further, on the day return statement screen 80, by inputting necessary information in the necessary text boxes 81 to 87 and clicking the temporary save button 90, the information entered on the day return statement screen 80 is temporarily saved. The main menu screen 70 can be returned to above.

  In the case where the information input on the day trip statement screen 80 is temporarily saved as described above, the “day trip settlement” displayed as the “domestic business trip” menu in the general menu on the main menu screen 70 is then displayed. When the character string “is clicked, the display screen changes to the domestic day return adjustment temporary saving list screen 100 shown in FIG. 16 instead of the day return adjustment report screen 80 described above.

  In this domestic day return adjustment temporary saving list screen 100, an identification number (hereinafter referred to as a processing number) assigned to the information that has been input and temporarily saved in the day return adjustment screen 80 and corresponds to the information. The departure date and return date of the domestic day trip to be displayed are displayed as a list 101. Then, on the domestic day balance adjustment temporary saving list screen 100, by clicking the processing number displayed in the list 101, the day return statement screen 80 in a state where the information is input can be displayed.

  Thus, by clicking the approval request button 89 in this state, the user can return the information input on the day return statement screen 80 to the user having the approval authority and then return to the main menu screen 70. it can.

  FIG. 17 shows an example of a scenario extracted in association with FIGS. 13 to 16 when the screen specification analysis module 55 of the screen specification analysis device 4 executes the scenario extraction process described above with reference to FIG.

  In FIG. 17A, the start screen 60 (FIG. 13) is used as a starting point screen, and when the “login” button 63 on the start screen 60 is clicked, the display screen changes to the main menu screen 70 (FIG. 14). Clicking on the character string (link) of “day trip adjustment” on the main menu screen 70 changes the display screen to the day trip adjustment screen 80 (FIG. 15). This is a scenario in which the display screen transitions to the main menu screen 70 by clicking the “approval request” button 89 after input.

  17B, with the start screen 60 as a starting point screen, when the “login” button 63 on the start screen 60 is clicked, the display screen transitions to the main menu screen 70. By clicking on the character string (link) of “repatriation”, the display screen transits to the domestic daily reimbursement temporary storage list screen 100, and the processing number “67JP676625 (01)” of the domestic repatriation temporary storage list screen 100 concerned. By clicking (link), the display screen transitions to the day return statement screen 80, and by clicking the “approval request” button 89 on the day trip statement screen 80, the display screen transits to the main menu screen 70. It is a scenario to do.

  Further, in FIG. 17C, with the start screen 60 as a starting point screen, when the “login” button 63 on the start screen 60 is clicked, the display screen transitions to the main menu screen 70, and “ By clicking on the character string (link) of “repatriation”, the display screen transits to the domestic daily reimbursement temporary storage list screen 100, and the processing number “67JP676789 (01)” of the domestic repatriation temporary storage list screen 100 concerned. By clicking (link), the display screen transitions to the day return statement screen 80, and by clicking the “approval request” button 89 on the day trip statement screen 80, the display screen transits to the main menu screen 70. It is a scenario to do.

  Further, FIG. 17D shows that the start screen 60 is used as a starting point screen, and when the “login” button 63 on the start screen 60 is clicked, the display screen transitions to the main menu screen 70. Clicking on the character string (link) of “repatriation” causes the display screen to transition to the reimbursement report screen 80, and a check mark is displayed in the share apportionment check box 87 in the repatriation report screen 80. When the “approval request” button 89 is clicked, the display screen changes to the apportioning setting screen described above, and when the “complete” button on the apportioning setting screen is clicked, the display screen changes to the main menu screen 70. It is a scenario.

  18 shows the screen feature amount calculation process described above with reference to FIGS. 10 and 11 by the screen specification analysis module 55 of the screen specification analysis apparatus 4 and the above-described FIG. 12 with respect to the scenarios shown in FIGS. A state after executing the scenario merging process is shown. As shown in FIG. 18, the scenario of FIG. 17B and the scenario of FIG. 17C are determined as similar scenarios and merged.

  19 and 20 show a configuration example of the screen specification screen 110 displayed on the input / output device 33 of the screen specification analysis device 4. 19 is a screen specification screen 110 for the scenario of FIG. 18A, and FIG. 20 is a screen specification screen 110 for FIG. 18B.

  As shown in FIG. 19 and FIG. 20, on the screen specification screen 110 of the present embodiment, the screen name of each web screen constituting the corresponding scenario has a large frame (hereinafter referred to as a screen name display frame). Called) 111 is displayed. These screen name display frames 111 are arranged in the order of transition of the corresponding web screens, and these screen name display frames 111 are connected by an arrow 112 indicating the transition direction.

  In addition, between the screen name display frames 111 on the screen specification screen 110, the screen name display frames in which the labels of the screen parts that triggered the transition from the transition source web screen to the transition destination web screen are described. A frame body without corners smaller than 111 (hereinafter referred to as a label display frame body) 113 is displayed. It should be noted that the display frame body 113 such as a label is displayed in a double frame when there is a branch to different web screens depending on the input contents of the user, that is, when another scenario exists. On the other hand, a single frame is a case where it always changes to the same web screen irrespective of the input content. The branching condition can be extracted based on the user input contents (change event in FIG. 3) of the operation log table 38.

  Further, on the screen specification screen 110, the condition for branching the screen transition is displayed on the right side of the display frame 113 such as a double-framed label. For example, in FIG. 19 and FIG. 20, “divide is false” represents that it is a condition that the share apportionment check box 87 is not checked in the day return statement screen 80 described above with reference to FIG. 15. In addition, when there are many branch conditions, a link of a character string “detailed display” is displayed, and the screen transition condition can be displayed on another screen.

  On the other hand, FIG. 21 shows a screen list screen 120 that can be displayed on the input / output device 33 by a predetermined operation of the screen specification analysis device 4. On this screen list screen 120, the complexity of each web screen calculated by the above-described screen complexity calculation processing is displayed in a list. As a method of displaying the complexity of each web screen, the web screens may be sorted by the complexity and displayed in that order.

  On the screen list screen 120, a link to the screen specification screen 110 (FIGS. 19 and 20) including the web screen is also displayed in correspondence with each web screen. Thus, the user can switch the display screen to the screen specification screen 110 including the web screen by clicking the link of the desired web screen on the screen list screen 120.

(3) Effects of this Embodiment As described above, in the screen specification analysis system 1 according to this embodiment, a series of screen transitions corresponding to user operations are extracted as scenarios. No need to assemble web screens in business function units.

  Moreover, in this screen specification analysis system 1, since the similarity of scenarios is determined based on one or more feature quantities of each web screen and similar scenarios are merged, the correspondence between URLs and web screens is static and a pair. Even if it is not one, depending on the setting of “similarity” (that is, selection of feature amount and setting of weight for each feature amount), for example, web screens that are different from each other even with the same URL are recognized as different web screens. The screen specification recognition device 4 causes the screen specification recognition device 4 to recognize the web screens that are to be recognized by the device 4 or to be the same even in different URLs as the same web screen. Can do.

  Therefore, according to this screen specification analysis system 1, it is easy to grasp the specifications of the current system. In addition, the user of the screen specification analysis apparatus 4 hardly duplicates the same web screen or blurs the estimation accuracy due to forgetting to count the web screen, and can estimate the cost at the time of system renewal with high accuracy. In this way, according to the screen specification analysis system 1, it is possible to facilitate the creation of a cost estimate at the time of system renewal and to improve the accuracy of the created cost estimate.

(4) Other Embodiments In the above-described embodiments, the screen specification analyzing apparatus 4 according to the present invention is used for the client apparatus 2 and web screens for various businesses in response to requests from the client apparatus 2. Although the case where the present invention is applied to the screen specification analysis system 1 constituted by the web server device 3 that transmits data to the client device 2 has been described, the present invention is not limited to this, and screen specifications of various other configurations are also provided. Can be widely applied to analysis system.

  In the above-described embodiment, a log collection unit that collects a log of operations performed on the web screen in the screen specification analyzer 4 as an operation log and collects screen data of the web screen as a screen log; Based on the operation log collected by the collection unit, a scenario extraction unit that extracts a series of screen transitions as a scenario, and one or more feature amounts of each web screen are calculated based on the screen log collected by the log collection unit. Based on the screen feature value calculation unit, the feature value of each web screen calculated by the screen feature value calculation unit, the scenario merging unit that merges similar scenarios, and the screen transition specifications for each scenario after merging are output The screen specification output unit that performs the software configuration (log collection server module 54, screen specification analysis module 55, or screen specification output respectively) However, the present invention is not limited to this, but a part of these log collection unit, scenario extraction unit, screen feature amount calculation unit, scenario merge unit, and screen specification output unit or All may be configured by dedicated hardware.

  Furthermore, in the above-described embodiment, the case where the feature amount described above with reference to FIG. 10 is applied as the feature amount of the web screen has been described. However, the present invention is not limited to this, and various other feature amounts are widely used. Can be applied.

  Furthermore, in the above-described embodiment, the case where the complexity of the web screen is calculated by the above-described equation (1) has been described. However, the present invention is not limited to this, and various other calculation methods are widely applied. can do.

  The present invention can be widely applied to a screen specification analysis system including a client device and a web server device that provides the client device with a web screen requested in response to a request from the client device.

  DESCRIPTION OF SYMBOLS 1 ... Screen specification analysis system, 2 ... Client device, 3 ... Web server device, 4 ... Screen specification analysis device, 10, 20, 30 ... Processor, 11, 21, 31 ... Memory, 13, 23 , 33 ... I / O device, 35 ... Log collection server program, 36 ... Screen specification analysis program, 37 ... Screen specification output program, 38 ... Operation log table, 39 ... Screen log table, 40 ... Scenario Table ... 41 ... Scenario table before merging, 42 ... First scenario table after merging, 43 ... Second scenario table after merging, 54 ... Log collection server module, 55 ... Screen specification analysis module, 55A ... ... scenario extraction function, 55B ... screen feature amount calculation function, 55C ... scenario merge function, 55D ... screen complexity calculation function, 56 ... Surface specification output module, 110 ...... screen specification screen, 120 ...... screen list screen.

Claims (12)

In the screen specification analysis device that analyzes the screen specification of the web screen provided by the server device,
A log collection unit for collecting a log of operations performed on the web screen as an operation log, and collecting screen data of the web screen as a screen log;
A scenario extraction unit that extracts a series of screen transitions as a scenario based on the operation log collected by the log collection unit;
A screen feature amount calculation unit that calculates one or more feature amounts of each of the web screens based on the screen log collected by the log collection unit;
Based on the feature amount of each of the web screens calculated by the screen feature amount calculation unit, a scenario merging unit that merges similar scenarios together,
A screen specification output unit that outputs a screen transition specification for each scenario after the merge. The screen feature amount calculation unit
Label information indicating the screen name included in the web screen, label information of the screen component that triggered the screen transition included in the web screen of the transition source, and a trigger of screen transition included in the web screen of the transition source The at least one or more of the values based on the position of the screen component on the document structure and the item input on the web screen of the transition source is calculated as the feature amount of the web screen. Item 2. The screen specification analyzer according to Item 1. The scenario extraction unit
Manage one or more conditions of screen transition pattern, URL (Uniform Resource Locator) pattern of the web screen, and character string pattern included in the web screen, which are given in advance as a condition not to be extracted as the scenario The screen specification analyzing apparatus according to claim 2, wherein the scenario is extracted by excluding screen transitions that satisfy the managed condition. The server device executes processing in units of business functions,
The scenario extraction unit
Managing information for determining each of the web screens at the start and end of screen transition for each business function given in advance,
The screen specification analysis apparatus according to claim 2, wherein a range from the start to the end of the screen transition recognized based on the managed information is extracted as the scenario. The scenario extraction unit
Based on the operation log, for each screen transition, respectively extract the label information of the screen components that triggered the transition of the screen on the web screen of the transition source,
The screen specification output unit
As the specification of the screen transition, for each transition of the web screen, the label information of the screen component that triggered the transition of the screen on the web screen of the transition source extracted by the scenario extraction unit is displayed. The screen specification analyzer according to claim 2. Any one or more of the number of items that can be input on the web screen, the number of output items on the web screen, and the number of input items that are actually input on the web screen are stored in the operation log and the screen log. A screen complexity calculator that calculates the complexity of each web screen based on the acquired information,
The screen specification analysis apparatus according to claim 2, wherein the screen specification output unit displays the complexity of each web screen calculated by the screen complexity calculation unit when necessary. In the screen specification analysis method executed by the screen specification analysis device that analyzes the screen specification of the web screen provided by the server device,
The screen specification analysis apparatus collects a log of operations performed on the web screen as an operation log, and collects screen data of the web screen as a screen log;
A second step in which the screen specification analyzer extracts a series of screen transitions as a scenario based on the collected operation logs;
The screen specification analyzer calculates one or more feature quantities of the web screens based on the screen log, and merges similar scenarios based on the calculated feature quantities of the web screens. A third step,
The screen specification analysis method comprising: a fourth step of outputting a screen transition specification for each scenario after the merger. In the third step, the screen specification analyzer
Label information indicating the screen name included in the web screen, label information of the screen component that triggered the screen transition included in the web screen of the transition source, and a trigger of screen transition included in the web screen of the transition source The at least one or more of the values based on the position of the screen component on the document structure and the item input on the web screen of the transition source is calculated as the feature amount of the web screen. Item 8. The screen specification analysis method according to Item 7. The screen specification analyzer is
Manage one or more conditions of screen transition pattern, URL (Uniform Resource Locator) pattern of the web screen, and character string pattern included in the web screen, which are given in advance as a condition not to be extracted as the scenario And
In the second step,
The screen specification analysis method according to claim 8, wherein the scenario is extracted by excluding screen transitions that satisfy the managed condition. The server device executes processing in units of business functions,
The screen specification analyzer is
Managing information for determining each of the web screens at the start and end of screen transition for each business function given in advance,
The screen specification analysis method according to claim 8, wherein in the second step, a range from the start to the end of the screen transition recognized based on the managed information is extracted as the scenario. In the second step, the screen specification analyzer is
Based on the operation log, for each screen transition, respectively extract the label information of the screen components that triggered the transition of the screen on the web screen of the transition source,
In the fourth step, the screen specification analyzer is
As the specification of the screen transition, for each transition of the web screen, the label information of the screen component that triggers the transition of the screen in the web screen of the transition source extracted in the second step is displayed. The screen specification analysis method according to claim 8. In the fourth step, the screen specification analyzer is
Based on the operation log and the screen log, one or more of the number of input items on the web screen, the number of output items on the web screen, and the number of input items that are actually input on the web screen The screen specification analysis method according to claim 8, further comprising: calculating the complexity of each web screen based on the acquired information, and displaying the calculated complexity of each web screen when necessary. .