Information processing apparatus, information processing method, and program

Abstract

To create a prototype application for changing screens depending on the role of a user.SOLUTION: A program development apparatus 101 includes: a definition unit which defines a screen definition for defining an item to be displayed on a screen of an application to be generated, and a screen transition definition for defining procedures to transition to the next screen; and an operation control file generation unit which generates an operation control file that reproduces the screen and the procedures for screen transition defined by the definition unit. The operation control file generation unit receives settings for the role of a screen to be reproduced using a generated operation control file, and generates an operation control file to execute transition of screens corresponding to the role received in the procedure.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to an information processing device, an information processing method, and a program for generating an application. [Background technology]

[0002] When creating an application for a customer, if you first understand the customer's requests and then create the application, you can reduce rework and increase development efficiency.

[0003] In particular, screens and operating procedures differ from internal logic and operate according to user wishes, which increases customer satisfaction.

[0004] Patent Document 1 solves the above problem by listening to the user's requests, determining requirements that meet those requests, and at the same time generating and completing source code for an application program that can be used on a real device on the spot. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2015-210639 Summary of the Invention [Problem to be solved by the invention]

[0006] Patent Document 1 describes the generation of application mockup files and the generation of source code for a mockup application that realizes mockup screen transitions, but does not take into consideration the control of screen transitions based on differences in roles (job titles and jurisdictions) that may occur in business.

[0007] The goal of this invention is to create a prototype application that changes screens depending on the user's role. [Means for solving the problem]

[0008] In order to solve the above problems, the present invention comprises a definition means for defining a screen definition that defines items to be displayed on the screen of an application to be generated, and a screen transition definition that defines the procedure for transitioning to the next screen, and an operation control file generation means for generating an operation control file that reproduces the screen defined by the definition means and the procedure for transitioning between screens, wherein the operation control file generation means accepts settings for the role of the screen to be reproduced using the generated operation control file, and generates an operation control file that executes the screen transition corresponding to the accepted role in the procedure. [Effects of the Invention]

[0009] According to the present invention, it is possible to create a prototype application that performs screen transitions depending on the user's role. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a system configuration diagram showing an example of the configuration of a program development device, an application server, a database server, and an application client according to the present invention. [Figure 2] 1 is a block diagram showing an example of a hardware configuration applicable to a program development device, an application server, a database server, and an application client according to the present invention; [Figure 3] FIG. 2 is a block diagram showing an example of a software configuration according to an embodiment of the present invention. [Figure 4] FIG. 1 is a diagram illustrating an example of a functional configuration of a first program development device according to an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram illustrating an example of a flowchart for generating a prototype application according to an embodiment of the present invention. [Figure 6] FIG. 10 is a diagram illustrating an example of a flowchart of a screen definition input reception process according to the embodiment of the present invention. [Figure 7]FIG. 10 is a diagram showing an example of a flowchart of a prototype data input reception process according to an embodiment of the present invention. [Figure 8] FIG. 10 is a diagram illustrating an example of a flowchart of a prototype application source code generation process according to an embodiment of the present invention. [Figure 9] FIG. 10 is a diagram illustrating an example of a flowchart of a process performed when a prototype application is executed according to an embodiment of the present invention. [Figure 10] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 11] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 12] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 13] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 14] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 15] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 16] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 17] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 18] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 19] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 20] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 21] FIG. 4 is a diagram showing an example of a screen definition 402 according to an embodiment of the present invention. [Figure 22] FIG. 4 is a diagram showing an example of a screen definition 402 according to an embodiment of the present invention. [Figure 23] FIG. 10 is a diagram showing an example of control of the screen size of a prototype application 442 according to the present invention. [Figure 24] FIG. 4 is a diagram showing an example of a screen display of a prototype application 442 according to the present invention. [Figure 25] 10A and 10B are diagrams illustrating the relationship between a prototype application screen and a prototype operation panel according to an embodiment of the present invention. [Figure 26] FIG. 10 is a diagram showing an example of a flowchart when a prototype screen display application is executed according to an embodiment of the present invention. [Figure 27] FIG. 10 is a diagram showing an example of a flowchart when a prototype screen display application is executed according to an embodiment of the present invention. [Figure 28] FIG. 10 is a diagram showing an example of a flowchart when a prototype screen display application is executed according to an embodiment of the present invention. [Figure 29] FIG. 10 is a diagram showing an example of a flowchart when a prototype screen display application is executed according to an embodiment of the present invention. [Figure 30] FIG. 10 is a diagram illustrating an example of a device that can be displayed on a browser according to an embodiment of the present invention. [Figure 31] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 32] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 33] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 34] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 35] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 36]FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 37] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 38] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 39] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 40] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 41] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 42] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 43] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 44] FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. [Figure 45] FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. [Figure 46] FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. [Figure 47] FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. First Embodiment FIG. 1 is a system (information processing system) configuration diagram showing an example of the configuration of a program development device (an information processing device operated by a developer to generate a Web application), an application server, a database server, and an application client according to the present invention.

[0012] The program development device 101 defines the screen layout, database search instructions, etc. according to the developer's operations. The program development device 101 generates programs and applications.

[0013] In this embodiment, the application generated by the program development device 101 is a web application, but this is not limited to this, and it may be an application that does not use communication via web technology, such as an application that runs on an information processing device such as a mobile phone, smartphone, or tablet, or embedded software.

[0014] The application server 102 executes applications developed by the program development device 101. It is also possible to operate in connection with a database server 103.

[0015] The database server 103 is a database used by the developed application, and may also be used during development to check operation, etc. For example, the database server 103 for use by the developer may be configured as the same device as the program development device 101 or the application server 102, or may be located within a network 105 such as a LAN.

[0016] The application client 104 (information processing device) is an input terminal of an end user that runs an application program developed by the program development device 101 in cooperation with the application server 102. This application client 104 may be an information processing device such as a mobile terminal.

[0017] Any of the program development device 101, application server 102, database server 103, and application client 104 may be located on the Internet, such as in the cloud, or several information processing devices may be integrated into one housing.

[0018] FIG. 2 is a block diagram showing an example of the hardware configuration applicable to the program development device 101, application server 102, database server 103, and application client 104 according to the present invention.

[0019] In FIG. 2, a CPU 201 controls all devices connected to a system bus 204 .

[0020] The ROM 203 or external memory 211 also stores an operating system (OS) that is a control program for the CPU 201, and programs for realizing various functions of the information processing device, such as each server, client, and device, which will be described later.

[0021] The RAM 202 functions as the main memory, work area, temporary save area, etc. for the CPU 201.

[0022] The input controller 205 controls input from the input unit 209. In the case of an information processing device, the input unit 209 may include a keyboard, a pointing device such as a mouse, and a touch panel.

[0023] If the input unit 209 is a touch panel, the user can give various instructions by pressing (touching with a finger or the like) an icon, cursor, or button displayed on the touch panel.

[0024] The touch panel may also be a touch panel capable of detecting positions touched by multiple fingers, such as a multi-touch screen.

[0025] The output controller 206 controls the display of the output unit 210. Examples of the output unit 210 include a CRT or a liquid crystal display. This also includes a display of a notebook computer integrated into the main body. It may also be a projector.

[0026] The external memory controller 207 controls access to an external memory 211 that stores a boot program, various applications, font data, user files, edit files, printer drivers, etc. The external memory 211 stores various tables and parameters for realizing various functions of each server, client, device, etc. Examples of this external memory 211 include a hard disk (HD), a flexible disk (FD), a CompactFlash (registered trademark) card connected to a PCMCIA card slot via an adapter, and a SmartMedia card.

[0027] The CPU 201 enables display on the output unit 210 by, for example, executing outline font development (rasterization) processing on a display information area in the RAM 202. The CPU 201 also enables the developer to give instructions using a mouse cursor (not shown) or the like on the output unit 210.

[0028] A communication I / F controller 208 controls communication with external devices via a network, for example, communication using TCP / IP.

[0029] A program 212 for realizing the present invention is recorded in the external memory 211, and is executed by the CPU 201 by being loaded into the RAM 202 as required.

[0030] FIG. 3 is a block diagram showing an example of a software configuration according to an embodiment of the present invention.

[0031] The program development device 101 has the following functional units.

[0032] The definition unit 301 is a functional unit that receives from the developer screen definition information such as the layout of screens and items (input / output items) displayed in the application, and screen transition definition information that defines the procedure for transitioning from the application screen to the next screen; specifically, this corresponds to the flowchart in Figure 6 and the explanatory diagrams in Figures 10 to 14.

[0033] The operation control file generation unit 302 is a functional unit that generates a prototype application (operation control file) for reproducing the screens defined in the definition unit 301 and the procedures for transitioning between the screens, and specifically corresponds to the processing of the flowchart in Figure 8.

[0034] The storage unit 303 is a functional unit that stores the screen size when the prototype application is displayed on the application client 104, and specifically corresponds to 2310 in FIG.

[0035] The data acquisition unit 304 is a functional unit that acquires data to be displayed in items (input / output items) on the prototype application from the user, and specifically corresponds to step S706 in FIG. 7 and the explanatory diagrams in FIGS.

[0036] The operation panel generation unit 305 is a functional unit that generates a prototype operation panel that controls the screen environment and transition method of the prototype application, specifically 810 in FIG. 8, and the generated prototype operation panel is 3102 in FIG. 31, etc.

[0037] FIG. 4 is a configuration diagram of the program development device 101, the application server 102, and the application client 104.

[0038] The program development device 101 includes a repository definition unit 400, a prototype application generation unit 410, and a repository definition editor unit 420. Note that the prototype application of the present invention is different from an application that searches for data from a database or creates diagrams from calculated data results, as in a production environment, and is an application that serves as a mockup that displays preset values ​​and pre-drawn diagrams, and imitates screen transitions and display changes, etc., in the same way as an actual application.

[0039] The application server 102 corresponds to the application server unit 430 in FIG. 4, and the application client 104 includes an application client unit 435 .

[0040] The program development device 101 generates a prototype display screen (parent screen) 440 using the prototype generation unit 410. In the present invention, the term "developer" is not limited to contracted application developers, but refers broadly to anyone who uses the program development device 101, such as business users or sales representatives.

[0041] The repository definition unit 400 stores an application definition 401, a screen definition 402, a screen component definition 403, a screen transition definition 404, an action 405 linked to the screen component definition 402, and prototype data 406 linked to the action 405. The prototype data refers to the data that is displayed on the application screen when the prototype application is executed, and refers to values ​​and diagrams that are preset by the developer, rather than data searched from a database or diagrams created from calculated data results as in the production environment. These definitions 401 to 406 are input, set, or arranged by the developer via an application development tool.

[0042] The application definition 401 holds the settings for the entire application developed by the developer.

[0043] The screen definition 402 holds information on various screen component definitions 403 arranged on each screen included in the application and screen transition definitions 404. The screen definition 402 includes information on actions 405 set for various components and prototype data 406 linked to the actions 405.

[0044] The prototype application generation unit 410 analyzes the repository definition unit 400 set by the developer and generates a prototype display screen (parent screen) 440. After generating the prototype application, the prototype display screen (parent screen) 440 is deployed to the application server unit 430.

[0045] The repository definition analysis unit 411 analyzes the repository definition unit 400 set by the developer.

[0046] The prototype code generation unit 412 generates source code for the prototype application in accordance with the analysis results of the repository definition analysis unit 411 .

[0047] The source code compiling unit 413 compiles the source code generated by the prototype code generating unit 412 and deploys a prototype display screen (parent screen) 440 including compiled Java (registered trademark) code and HTML / JSP / JavaScript (registered trademark) to the application server unit 430.

[0048] The repository definition editor section 420 is an example of a procedure for a user to set the repository definition 400. The repository definition editor section 420 includes a screen definition editor section 421, a screen transition definition editor section 422, a parts palette section 423, an action selection section 424, and a prototype data input section 425.

[0049] The screen definition editor unit 421 is a graphical editor that allows a developer to intuitively create a desired screen layout.

[0050] The screen transition definition editor unit 422 is an editor for setting properties for each screen component placed by the developer.

[0051] The responsive component control unit 423 is a functional unit that allows the developer to control the display format of screen components (screen layout and component width) for each screen width of the client.

[0052] An example of the responsive component control unit 423 will be described with reference to FIGS.

[0053] FIG. 23 is a schematic diagram for explaining the control of the screen size of the prototype application 442 in the present invention.

[0054] For example, as shown in 2300 in FIG. 23, the application generation screen displays buttons for switching between display screens of multiple types of clients, such as a personal computer screen button 2301, a tablet screen button 2302, and a smartphone screen button 2303.

[0055] When the switching button 2300 is pressed, data 2310 (storage unit) stores the screen size displayed on the application client 104. For example, when the personal computer screen button 2301 is pressed, the displayed screen size is 1920 x 1080 (2311), when the tablet screen button 2302 is pressed, the displayed screen size is 1023 x 1366 (2312), and when the smartphone screen button 2303 is pressed, the displayed screen size is 414 x 896. Examples of the screens displayed when each button is pressed will be described with reference to FIG. 24.

[0056] FIG. 24 is a schematic diagram showing an example of a screen display of the prototype application 442 in the present invention.

[0057] For example, in FIG. 24, 2402 is a display image on a personal computer screen, 2403 is a display image on a tablet screen, and 2404 is a display image on a smartphone screen. The sizes of the respective components, for example, component 2422 on personal computer screen 2402 is 2423 on tablet screen 2403 and 2424 on smartphone screen 2404. The responsive component control unit 423 controls the same components 2422, 2423, and 2424 to be displayed at a predetermined ratio of the width of the entire screen (2402, 2403, 2404) as shown in FIG. 24. That is, component 2402 is controlled so that 2422 is displayed at 2 / 12 of 2402 (the entire screen) on the personal computer screen, 2423 is displayed at 3 / 12 of 2403 (the entire screen) on the tablet screen, and 2424 is displayed at 6 / 12 of 2404 (the entire screen) on the smartphone screen. Returning to the description of the configuration diagram in FIG. 4,

[0058] The action selection unit 424 is a functional unit that selects an action (action event) for the developer to select an action for which the prototype data 406 is to be set.

[0059] The prototype data input section 425 is a graphical editor for intuitively setting prototype data 406 associated with a specific action 405 .

[0060] The application server unit 430 (102) is a functional unit that stores the prototype display screen (parent screen) 440 generated by the prototype application generation unit 410 and transmits it to the application client 104.

[0061] The prototype display screen (parent screen) 440 is an application generated by the prototype application generation unit 410. The prototype display screen (parent screen) 440 is an application that allows a business user (customer decision maker) or a sales representative who makes a proposal to a customer to control and display the display content, operation, etc. of an application generated by the program development device 101 during application development. The prototype display screen (parent screen) 440 includes a prototype operation panel 441 and a prototype application 442.

[0062] The prototype operation panel 441 is a module of the prototype display screen (parent screen) 440 that has user interface functions, and is a panel (screen) that accepts settings from the developer, such as reproduction at the screen size of the application client 104, reproduction of display images for each user authority, reproduction of processing wait time on the server, and reproduction of the display screen when an error occurs on the server.

[0063] The prototype application 442 is a mockup application that allows business users (customer decision makers) and sales representatives who make proposals to customers to reproduce the display content and operation of applications generated by the program development device 101 when developing applications.

[0064] The application client unit 435 downloads the prototype display screen (parent screen) 440 from the application server unit 430, and launches the prototype display screen (parent screen) 440, which is configured as an SPA (single page application), in the web browser 450.

[0065] Although not shown, the system also has an application code generation unit that actually operates, rather than a prototype application. The application code generation unit reads and analyzes the application definition 401, screen definition 402, separately defined database definition, data model definition, and business process definition from the repository definition unit 400 using a repository definition analysis unit 411. The Web application code generation unit uses the code generation rules stored in the external memory 211 and the contents analyzed by the repository definition analysis unit 411 to generate a Web application module including compiled Java (registered trademark) code and HTML / JSP / JavaScript (registered trademark) via a source code compilation unit 413.

[0066] 5 is a diagram showing an example of a flowchart for generating a prototype application for a Web application. Note that each step in the following flowchart is executed by the CPU 201 of each device.

[0067] The flowchart in Fig. 5 shows the flow of processing initiated by program development device 101 when a developer attempts to generate a prototype application. The processing in steps S501 to S506 is information acquisition processing for generating prototype application 442. The processing in step S507 is processing for acquiring information for prototype operation panel 441 and generating source code for the prototype application including prototype display screen 440. The processing in each step will be specifically described below.

[0068] First, in step S501, the program development device 101 accepts a screen definition input. Details of the processing in step S501 will be described later with reference to FIG.

[0069] Next, in step S502, the program development device 101 determines whether there has been a request to input prototype data 443. Specifically, it determines whether 1201 and 1202 in Fig. 12, or 1203 and 1301 in Fig. 13, which are examples of the action selection unit 424, have been pressed.

[0070] The action control module 442 controls which data from multiple prototype data set by the developer is displayed at what timing when the prototype display screen (parent screen) 440 is executed. The action control module 442 also controls the behavior associated with each action of the components placed on the screen. In other words, the prototype data is associated with an action (action event).

[0071] The program development device 101 accepts the press to allow the developer to specify which action the prototype data he or she is about to input will be linked to.

[0072] If it is determined in step S502 that a prototype data input request has been made, the process proceeds to step S503.

[0073] On the other hand, if there is no prototype data input request in step S502, the process proceeds to step S504.

[0074] An example of the action selection section when 1201 is pressed is shown in 1202. Also, an example of the action selection section when 1203 is pressed is shown in 1301. In the example of 1301, a list of actions included in the currently displayed screen definition is displayed, but a list of actions included in the application definition may also be displayed.

[0075] When the process proceeds to step S503, the program development device 101 accepts input of prototype data from the developer. Details of the process of step S503 will be described later with reference to Fig. 7. After that, the process proceeds to step S504.

[0076] In step S504, the program development device 101 determines whether a screen definition save request has been made. If it is determined that a screen definition save request has been made, the process proceeds to step S505, and if a screen definition save request has not been made, the process proceeds to step S506.

[0077] When the process proceeds to step S505, the program development device 101 saves the screen definition in the repository definition unit 400. After that, the process proceeds to step S506.

[0078] In step S506, the program development device 101 determines whether a prototype generation request has been made. If it is determined that a prototype generation request has been made, the program development device 101 proceeds to step S507. On the other hand, if a prototype generation request has not been made, the program development device 101 proceeds to step S501.

[0079] When the process proceeds to step S507, the program development device 101 generates source code for the prototype application. Details of the process in step S507 will be described later with reference to FIG.

[0080] Next, in step S508, the program development device 101 compiles the source code generated in step S507.

[0081] In step S509, the program development device 101 deploys the prototype application compiled in step S508 to the application server 102 (430).

[0082] In the following, we will explain an example in which the program development device 101, application server 102, and application client 104 are implemented on the same information processing device, but if they are each implemented on a separate information processing device, each information processing device will launch each application (such as a prototype application or a web browser) and execute the processing.

[0083] In step S510, the program development device 101 starts the prototype application deployed on the application server 102 (430).

[0084] In step S511, the program development device 101 starts a web browser and starts accessing the URL of the prototype application. Note that the processes of steps S510 and S511 are an example of a case where the program development device 101 uses both the application server 102 and the application client 104. If they are in separate housings, the process of step S510 is executed by the application server 102, and the process of step S511 is executed by the application client 104.

[0085] This concludes the explanation of Fig. 5. The subsequent processing will be described later with reference to Fig. 9. In the explanation of Fig. 9 and subsequent figures, the prototype application is assumed to be executed by the application client 104 that has launched a web browser, rather than by the program development device 101. However, the prototype application may also be executed by the program development device 101 that has launched a web browser, just like the application client 104.

[0086] Next, the details of the process in step S501 will be described with reference to FIG.

[0087] 6 is a diagram showing an example of a flowchart for accepting input of a screen definition of a Web application. Note that each step of the following flowchart is executed by the CPU 201 of each device.

[0088] The flowchart in FIG. 6 shows the flow of processing that starts when the processing transitions to step S501 in the flowchart in FIG.

[0089] First, in step S601, the program development device 101 accepts the placement of screen components by the developer. Specifically, the placement of components by drag-and-drop 1003 from 1001 in FIG. 10, which is an example of the component palette unit 423, to 1002, which is an example of the screen definition editor unit 421, is accepted. FIG. 10 shows an example in which a button component is dragged and dropped from the component palette unit to the screen definition editor unit. The method of placing screen components is not limited to drag-and-drop from the component palette unit 423 to the screen definition editor unit 421, but may also be a method of moving an already placed component or a method of duplicating an already placed component by copy-and-paste. Furthermore, components that have been placed may be deleted.

[0090] In the case of FIG. 10, as shown in 1004, a screen image is created that has two text input fields (an ID input field and a name input field) and a registration button for registering an ID and a name.

[0091] Next, in step S602, the program development device 101 determines whether a component including an action event has been placed. If it is determined that a component including an action event has been placed, the process proceeds to step S603, and if a component including an action event has not been placed, the process proceeds to step S604.

[0092] When the process proceeds to step S603, the program development device 101 registers the action set for the component including the action event. Specifically, the action is registered for the component having an action called onClick in the source code of the component. In 2100 of FIG. 21, which is an example of the screen definition 402, a definition 2102 of "actions" corresponding to the production environment and a definition 2103 of "examples" corresponding to the prototype application are written. Note that in the example of FIG. 21, the data storage format is a JSON file as an example of implementation means, but the data storage format may be other file formats or a database. Then, the process proceeds to step S604.

[0093] Next, in step S604, the program development device 101 determines whether a property input request has been made. Specifically, it determines whether 1101 in Fig. 11, which is an example of a property input request button for the selected component, has been pressed.

[0094] If it is determined that a property input request has been made, the process proceeds to step S605, and if a property input request has not been made, the screen definition input acceptance process ends.

[0095] When the process proceeds to step S605, the program development device 101 accepts input of properties for the screen component by the developer. Specifically, an example of a screen property editor, 1102 in FIG. 11, is displayed, and input of settings for the properties of the screen component is accepted. In the example of FIG. 11, the screen property editor is displayed near the component to enable intuitive operation by the developer, but a specific area within the screen may be reserved as the screen property editor. The screen property editor may also be displayed in a modal dialog.

[0096] This concludes the description of FIG.

[0097] Next, the details of the process in step S503 will be described with reference to FIG.

[0098] 7 is a diagram showing an example of a flowchart for accepting input of prototype data to be displayed on the screen when generating a prototype application for a Web application. Note that each step of the following flowchart is executed by the CPU 201 of each device.

[0099] The flowchart in FIG. 7 shows the flow of processing that starts when the processing transitions to step S503 in the flowchart in FIG.

[0100] First, in step S701, the program development device 101 reads the settings of the action item specified by the developer in step S502 of Fig. 5. Specifically, the following two steps are performed. First, 2101 in Fig. 21, which is an example of 1004 in Fig. 10, which is an example of the screen component definition 403 of the screen component selected by the developer, is read. The data of 2101 is assumed to have been input from 1102 in Fig. 11 in step S605 of the flowchart in Fig. 6. Next, the program development device 101 reads the "actions" definition 2102 corresponding to the production environment of the screen component selected by the developer and the "examples" definition 2103 corresponding to the prototype application.

[0101] Next, in step S702, the program development device 101 determines whether the setting of the action item read in step S701 involves a screen transition. Specifically, it determines whether a value is set in the "nextUi" property (next screen property in 1102), which is an example of the screen transition definition 404 of 2101, which is an example of the screen component definition 403. In this embodiment, the program development device 101 holds the screen transition definition 404 in the screen component definition 403, but it may also hold it in the action definition 405.

[0102] If it is determined that the setting of the action item read in step S701 involves a screen transition, the process proceeds to step S703, and if the setting of the action item read in step S701 does not involve a screen transition, the process proceeds to step S704.

[0103] When the process proceeds to step S703, the program development device 101 displays a transition destination screen for the screen transition associated with the setting of the action item read in step S701. Specifically, 1300 in FIG. 13, which is the screen set in "nextUi" of 2101, is displayed. Note that the transition destination screen 1302 in FIG. 13 is also assumed to have been set in advance by the developer's operation (step S601). Note that a screen such as 1302 may be displayed in a manner that rewrites the currently displayed screen definition editor unit 421, or in a manner that launches a new screen definition editor unit 421.

[0104] The initial display action of the screen image (transition destination screen) displayed in screen definition editor section 421 is read and set as the action designated by the developer. After this processing, the process proceeds to step S704.

[0105] In step S704, the program development device 101 displays on the screen the prototype data already set for the action read in S701 or the action read in S703 (for example, if data such as 2201 in Figure 22 has already been set, that data).

[0106] Next, in step S705, the program development device 101 accepts the developer's selection of a prototype data display component. Here, a prototype data display component refers to a component that displays data (prototype data) before a prototype application is run. Specifically, this is an example in which prototype data is displayed in a list such as 1302 in FIG. 13 displayed in the screen definition editor unit 421. In the prototype data display component 1402 in FIG. 14, the developer can accept the selection of the prototype data display component by, for example, right-clicking the mouse (not shown) in the "Name" field and then pressing the edit button 1403. Furthermore, after selecting the entire list as shown in 1701 in FIG. 17, pressing the table input button 1702 selects the entire list of 1701 as the prototype data display component.

[0107] In the next step S706, the program development device 101 accepts prototype data input by the developer. Specifically, a prototype data input dialog 1501 in FIG. 15, which is an example of the prototype data input unit 425, is displayed. 1501 is the prototype data input dialog that is displayed when the edit button is pressed in the "Name" field in 1401 in FIG. 14. In the case of 1501, this is an example in which the developer has entered prototype data "Tanigawa Noriyuki" in the "Name" field. After the developer has entered the value, by pressing the "OK" button in 1501, a determination is made as to whether the input in step S707 has been confirmed.

[0108] As another example of step S706, an example of prototype data input section 425 will be described with reference to FIG.

[0109] Prototype data input dialog 1801 in FIG. 18 is a screen image displayed when table input button 1702 in FIG. 17 is pressed. The text input field of 1801 accepts input of a group of data to be displayed in the list displayed in 1701. In the case of 1801, the following data has been entered: "(blank)", "Tanigawa Noriyuki", "(blank)" on the first line; "1001", "Hori Ai", "2019 / 10 / 10" on the second line; and "1002", "Yamamura Ruriko", "2019 / 09 / 18" on the third line. This data entry may be adapted to the contents of a CSV file or spreadsheet file selected from a file selection screen (not shown) displayed by pressing file selection button 1802.

[0110] After the developer inputs a value into the text input field or after the data is reflected after selecting a file, by pressing the "OK" button 1803, it is determined in step S707 whether the input has been confirmed.

[0111] In step S706, a locale specification may be accepted to switch the prototype data to be displayed depending on the language. Also, although a method of displaying a modal dialog is shown as a method for accepting prototype data input, the input acceptance method may be a method of accepting input directly to the display component selected by the developer in S705, or a method of accepting input in bulk from an external file.

[0112] In the next step S707, the program development device 101 determines whether the prototype data input by the developer has been confirmed. Specifically, it determines whether the "OK" button in the prototype data input dialog 1501 in Fig. 15 or the "OK" button 1803 in Fig. 18 has been pressed. Note that in the input acceptance method in step S706, if direct input to a component has been accepted, it determines whether the focus has been removed from that component.

[0113] If it is determined that the prototype data input has been confirmed (the "OK" button has been pressed), the process proceeds to step S708, and if it is determined that the prototype data input has not been confirmed, the process proceeds to step S706.

[0114] In step S708, the program development device 101 writes the prototype data input by the developer to the screen definition 402. Specifically, the prototype data is written to 2201, which is an example of the prototype data 406 linked to the action 405 of the screen definition 402.

[0115] Note that with this method, it is not possible to change the data displayed on the post-transition screen depending on the action to be executed. This is because the prototype data is stored in the initial display action of the post-transition screen. However, by storing the prototype data to be displayed on the post-transition screen on the side of the action to be executed, it may be possible to change the data to be displayed on the post-transition screen depending on the action to be executed. Specifically, by storing the objects under "onLoad" in 2201 under "onClick" in 2103, the original button that transitions the screen (for example, the "Register" button 1003 located at 1000 in FIG. 10) may have data to be displayed on the post-transition screen.

[0116] In this way, by displaying the screen image showing the prototype data on the prototype application and transitioning the screen for each action event, you can get an idea of ​​how the mockup will work before creating an actual application (for example, searching a database or drawing from the extracted data). This concludes the description of FIG.

[0117] Next, the details of the process in step S507 will be described with reference to FIG.

[0118] 8 is an example of a flowchart illustrating the flow of processing for generating source code for a prototype application of a Web application. Note that each step in the following flowchart is executed by the CPU 201 of each device.

[0119] The flowchart in FIG. 8 shows the flow of processing that starts when the processing transitions to step S507 in the flowchart in FIG.

[0120] First, in step S801, the program development device 101 reads the application definition 401 specified by the developer from the repository definition unit 400. The repository definition analysis unit 411 analyzes the read definition and stores it in the ROM 203, and the analyzed definition is referenced by each generation unit as appropriate.

[0121] In step S802, the program development device 101 reads from the repository definition unit 400 the screen definition 402 included in the application definition 401 read in step S801.

[0122] In step S802, when the screen definition is read, information on the display authority defined for each of the screen display items (items) is also obtained. This will be described with reference to the example of FIG. 35. In FIG. 35, if the second line (3501) is defined as the line in which the display items (items) are changed depending on the user's authority, information linking the user's authority name 821 with the corresponding input / output display permission items 822 is obtained. In the case of 820 in FIG. 8, the user authorities depicted in FIG. 35 have the authority names "User," "Admin," and "Guest," and the "Attendance Confirmation" item in FIG. 35 is defined as the input / output display permission item. Note that this display item definition information may define input / output display permission or may define input / output display prohibition items. Furthermore, the display items may be collectively defined as display authority, or may be defined individually as in 820.

[0123] In step S803, the program development device 101 reads from the repository definition unit 400 the screen component definition 403 included in the screen definition 402 read in step S802.

[0124] In step S804, the program development device 101 reads from the repository definition unit 400 the screen transition definition 404 included in the screen definition 402 read in step S802.

[0125] In step S805, the program development device 101 collects the authorities (roles) associated with the display items acquired in step S802.

[0126] In step S806, the program development device 101 reads the prototype data 406 included in the screen definition 402 read in step S802 from the repository definition unit 400. The data in the screen definition 402 read here is the "examples" data in Figures 21 and 22 that corresponds to the prototype data, and "actions," i.e., the data for the production environment, is not used. By having these two pieces of data, it becomes possible to create a common screen definition for the prototype data and a screen definition for the production environment, and the application screen created for the mockup can be defined as an application screen as is.

[0127] In step S807, based on the information read in steps S801 to S806, the program development device 101 generates source code for the prototype application in the prototype code generation unit 412. The generated source code also includes source code for the prototype operation panel (such as 3102 in FIG. 31) that is displayed when the prototype application is started.

[0128] FIG. 31 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0129] The prototype operation panel will be described with reference to FIG. 31. The prototype operation panel is a panel screen that receives instructions from the developer regarding display settings and transition settings when displaying a prototype (prototype) screen or when transitioning between prototype (prototype) screens. The prototype operation panel can set the display device (personal computer, tablet, smartphone, etc.) and the screen orientation of the display device, the screen display for each user's access rights (Administrator rights, User rights, general user rights, etc.), the display of the processing time on the server, and the display when an error occurs. The display device settings can be set in 3111 of 3102, the user rights settings in 3121 of 3102, the processing wait time settings in 3131 of 3102, and the error display settings in 3141 of 3102.

[0130] The relationship between the prototype application screen and the prototype operation panel 3102 when the prototype operation panel 3102 is open will be described with reference to FIGS.

[0131] FIG. 25 is a diagram for explaining the relationship between the prototype application screen and the prototype operation panel.

[0132] A prototype display screen 2501, which serves as the base for the parent screen, is displayed on the browser, and within the parent screen, a prototype application screen 2502 is displayed in an iFrame. Furthermore, a prototype operation panel 2503 is displayed on top of the prototype application screen 2502, and is displayed on the parent screen 2501 so that part of the prototype application 2502 and the prototype operation panel 2503 can be confirmed at the same time.

[0133] When settings are received from a developer on the prototype operation panel 3102 as shown in Figure 31, and an operation is received from the developer to reduce the prototype operation panel 3102 (2503), for example, as shown in 3103, a prototype application screen 3201 (2522) as shown in Figure 32 is displayed (display image of 2521). To return from the prototype application screen 3201 (2522) to the screen displaying the prototype operation panel 3102 (2503), the prototype operation panel display button 3202 (2523) is pressed to transition to the screen image 3101 of Figure 31 displaying the prototype operation panel 3102. Returning to the explanation of the flowchart in Figure 8.

[0134] An example of the source code generated in step S807 is shown in Fig. 44. Fig. 44 shows an example of TypeScript source code that is started when the prototype operation panel is operated and the browser's memory area (Web Storage and Cookie information) where the operation is stored is changed.

[0135] Next, in step S808, the program development device 101 generates source code for changing the screen display for each user authority. An example of the generated source code is shown in FIG. 45. FIG. 45 is an example of source code that is executed when the user authority is changed, for example, for the prototype operation panel 3521 in FIG. 35 or the prototype operation panel 3721 in FIG. 37. When the user authority is changed, the source code in FIG. 45 determines the user authority in the first half of the source code, and controls the display / hide of screen components to which the user authority is applied in the second half of the source code. In other words, step S808 is a procedure for generating a program for displaying a prototype (trial) screen when the user authority is set.

[0136] In step S809, the program development device 101 generates source code for reproducing the screen display that occurs when connecting to the server. An example of the generated source code is shown in Fig. 46. Fig. 46 shows an example of source code that is executed when, for example, a value for processing time (processing wait time) is entered in option setting field 3131 or 3141 of prototype operation panel 3102, as in 3931 in Fig. 39, or when the error setting is changed to ON, as in 4241 in Fig. 42, and displays a prototype (trial) screen that reflects the processing settings of the pseudo server obtained from the browser's memory area. In other words, step S809 is processing that generates a program for reproducing pseudo communication and the server status when communicating with the server.

[0137] In step S810, the program development device 101 generates a program for reflecting the screen settings of the subordinate prototype application (iFrame) screen 2502 in the settings of the prototype operation panel 2503 (3102) after drawing the prototype operation panel screen 2503. An example of the generated source code is shown in Fig. 47. Fig. 47 shows TypeScript source code that reproduces the display of the prototype (prototype) screen by, for example, setting the device setting field 3111 of the prototype operation panel 3102 to button 3112 for setting with an image of a PC (personal computer setting), or by setting with a smartphone as in the image 3311 of Fig. 33.

[0138] Once the above source code is generated, the processing of the flowchart in Fig. 8 is completed. Note that although the source code (Figs. 44 to 47) that executes the prototype operation panel screen 3102 and the processing after operating the prototype operation panel screen is written in TypeScript, it may be source code in another language, or may be source code written in JavaScript, for example.

[0139] This concludes the description of FIG.

[0140] Next, the processing flow when executing the prototype application deployed in step S509 of Fig. 5 and starting communication with the Web browser (450) of the application client 104 will be described with reference to Fig. 9. Note that the Web browser launched in step S511 of the program development device 101 may start communication with the deployed prototype display screen application, as shown in Fig. 5, or the Web browser launched in the application client 104 may start communication with the deployed application server 102, as shown in Fig. 9.

[0141] 9 is a flowchart showing an example of the operation in which the prototype display screen (parent screen) 440 deployed in step S509 of FIG. 5 is downloaded to and executed by the application client 104. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.

[0142] The flowchart in FIG. 9 shows the flow of processing that starts when the prototype display screen (parent screen) 440 is deployed to the application server 102 (430) and accessed by a developer from a web browser 450 of the application client 104.

[0143] In step S901, the application client 104 first reads the locale information of the browser, which allows the display language of the prototype data to be switched.

[0144] In step S902, the application client 104 downloads from the application server 102 (430) an SPA (single page application) on which the prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs. Note that in the embodiment of the present invention, the prototype display screen (parent screen) 440 is described as an SPA, but it does not necessarily have to be an SPA and may be configured to communicate with the application server 102 using a screen transition command, in which case initial screen information for the prototype application is downloaded.

[0145] In step S902, the application client 104 also acquires user authority information for the prototype application.

[0146] Furthermore, in step S902, the application client 104 launches the prototype display screen 2501 (parent screen of the prototype application) from the program acquired from the application server 102 (430). That is, step S902 is a step for downloading and launching a program for displaying the prototype application with a screen image such as 3101 in Figure 31.

[0147] In the next step S903, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. The launched screen image is 3201 in Fig. 32, but because the prototype operation panel 3102, which will be displayed in the next step S904 and onwards, is displayed in the upper layer (the relationship between 2502 and 2503 in Fig. 25), the initial display screen at launch will be like 3101 in Fig. 31.

[0148] In the next step S904, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame section of the prototype display screen 2501. The launched screen image is image 3102 in Figure 31. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (prototype) application.

[0149] In the next step S905, the application client 104 changes the display screen or transition screen of the prototype application 3201 (442) according to the settings entered into the prototype operation panel 3102. The process of displaying the screen or transition screen of the prototype application 440 according to the settings will be described later with reference to FIGS.

[0150] Next, in step S906, the application client 104 waits for instructions from the developer as to whether to end the reproduction of the application using the prototype application. If the reproduction of the application is to be ended, this flowchart is terminated. If an instruction to reproduce the application again is received, the process returns to step S902.

[0151] Next, in step S905, the process flow for changing the display screen of the prototype application 3201 (442) or changing the transition screen according to the settings entered into the prototype operation panel 3102 will be described with reference to Figures 26 to 29. The settings include switching the display device, changing user authority, replicating the processing time with the server, and replicating when an error occurs.

[0152] 26 is a flowchart showing the flow of processing when switching the display device. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.

[0153] 26 is a flowchart that starts when a developer accesses the application client 104 from a web browser 450 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the web browser 450. Note that some of the explanations in FIGS. 26 to 29 overlap with the explanation in FIG. 9.

[0154] First, in step S2601, the application client 104 downloads from the application server 102 (430) an SPA on which the prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs.

[0155] In step S2601, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2601 is a step for downloading and launching a program for displaying a prototype application with a screen image such as that shown in 3101 in Figure 31.

[0156] In the next step S2602, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame section of the prototype display screen 2501. The launched screen image is 3201 in Fig. 32, but because the prototype operation panel 3102, which will be displayed in the next step S2603 and onwards, is displayed in the upper layer (the relationship between 2502 and 2503 in Fig. 25), the initial display screen at launch will be like 3101 in Fig. 31.

[0157] In the next step S2603, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame section of the prototype display screen 2501. The launched screen image is image 3102 in Figure 31. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (prototype) application.

[0158] If the developer changes the device input field 3111 while the prototype operation panel 3102 is displayed, the process proceeds to the next step S2604. A screen image when the developer changes the device input field 3111 will be described with reference to FIG. 33. The device input field 3111 is an input field for which the screen size of each terminal (personal computer, tablet, smartphone) is preset, and for tablets and smartphones, the display format can be changed between portrait and landscape orientations. The reason why portrait and landscape display formats are displayed is because tablets and smartphones can be controlled to display in either portrait or landscape orientation.

[0159] FIG. 33 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0160] Unlike the prototype operation panel 3102 in FIG. 31, the device selection field 3311 of the prototype operation panel 3302 in FIG. 33 is an example in which the smartphone screen button 3312 is pressed.

[0161] Returning to the explanation of the flowchart in Fig. 26, when the process proceeds to the next step S2604, the application client 104 receives an instruction to change the screen size to that of the device changed on the prototype operation panel 3302. An example of source code that executes the processing of steps S2603 and S2604 after displaying 3101 in Fig. 31 is shown in Fig. 47.

[0162] In the next step S2605, the application client 104 displays the prototype application 2502 by adjusting the iFrame portion to the size of the device accepted in step S2604. An image of the prototype application screen when settings such as those of the prototype operation panel 3302 in Fig. 33 are accepted will be described with reference to Fig. 34.

[0163] FIG. 34 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0164] Prototype application screen 3401 in Fig. 34 is displayed in the smartphone size of 3402. Even on a screen displayed in smartphone size, the processing of the prototype application as a trial is executed, and for example, when a specific button is pressed, a transition screen that reflects the prototype data corresponding to that action can be displayed.

[0165] The transition from the prototype display screen 3301 (2501 in FIG. 25) on which the prototype operation panel 3302 in FIG. 33 is displayed in the foreground to the screen (2521 in FIG. 25) on which the prototype application screen 3401 in FIG. 34 is displayed in the foreground may be performed, for example, by pressing the down arrow button 3103 in FIG. 31, or by using another button. The transition from the screen (2521 in FIG. 25) on which the prototype application screen 3401 in FIG. 34 is displayed in the foreground to the prototype display screen 3301 (2501 in FIG. 25) on which the prototype operation panel 3302 in FIG. 33 is displayed in the foreground (i.e., returning to the screen of the prototype operation panel 3302) may be performed, for example, by pressing the translucent button 3202 in the lower right of FIG. 32.

[0166] By performing the above process, it is possible to easily create a prototype application with different display formats for each device.

[0167] Next, with reference to FIG. 27, a process flow for changing the screen display when the user authority is changed will be described.

[0168] 27 is a flowchart showing the flow of processing when the user authority is switched. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.

[0169] The flowchart in FIG. 27 is a flowchart that starts when a developer accesses the Web browser 450 of the application client 104 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the Web browser 450.

[0170] First, in step S2701, the application client 104 downloads from the application server 102 (430) an SPA on which the prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs.

[0171] In step S2701, the application client 104 acquires user authority information for the prototype application. An example of the acquired data is data such as 2710. This data is the same as data 830 acquired in step S805 when the prototype display screen application was generated.

[0172] Furthermore, in step S2701, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2701 is a step for downloading and launching a program for displaying a prototype application with a screen image such as that shown in 3101 in Figure 31.

[0173] In the next step S2702, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. The launched screen image is initially 3201 in Fig. 32, but because the prototype operation panel 3102, which is displayed in the next step S2703 and onwards, is displayed in the upper layer (the relationship between 2502 and 2503 in Fig. 25), the initial display screen is like 3101 in Fig. 31.

[0174] In the next step S2703, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame section of the prototype display screen 2501. The launched screen image is image 3102 in Figure 31. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application. As shown in user authority setting field 3121 in Figure 31, the check boxes for user authority setting are generated from the user authority data 830 acquired in step S805.

[0175] When the developer changes the user authority setting field 3121 while the prototype operation panel 3102 is displayed, the process proceeds to the next step S2704. The screen image when the developer changes the user authority setting field 3121 will be described with reference to Fig. 35.

[0176] FIG. 35 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0177] The user authority setting field 3521 of the prototype operation panel 3502 in FIG. 35 is an example in which, unlike the prototype operation panel 3102 in FIG. 31, the user authority setting field 3521 is checked "user" instead of "guest."

[0178] Returning to the explanation of the flowchart in Fig. 27, when the process proceeds to the next step S2704, the application client 104 stores in the browser's local storage the value of the user authority setting field 3521 that was changed on the prototype operation panel 3502. Examples of source code for executing the processes of steps S2704 and S2705 when the user authority setting field is changed after displaying 3101 in Fig. 31 are shown in Figs. 44 and 45.

[0179] In the next step S2705, the application client 104 displays the prototype application 2502 with the user authority settings stored in step S2704. An image of the prototype application screen when the user authority setting field 3521 of the prototype operation panel 3502 in Fig. 35 is accepted will be described with reference to Fig. 36.

[0180] FIG. 36 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0181] Unlike the prototype application screen 3201 in Figure 32, the prototype application screen 3601 in Figure 36 has a new "Attendance Confirmation (User)" field added to the underlined portion 3602. This is an image diagram that reflects the data 820 of input / output permission items for each user authority obtained in step S802 when the prototype display screen was generated. That is, because the user authority setting field 3521 has been changed to "user," the authority name (Name) corresponding to "user" in 830 is "User," and the input / output permission items for the "User" authority are "Attendance Confirmation (User)" and "Remarks." Therefore, the prototype application screen 3601 in Figure 36 displays the "Attendance Confirmation (User)" field and "Remarks" field, as shown in the underlined portion 3602.

[0182] Another example will be described.

[0183] FIG. 37 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0184] Unlike the prototype operation panel 3102 in Fig. 31, the user authority setting field 3721 of the prototype operation panel 3702 in Fig. 37 is an example in which "guest," "user," and "admin" are all checked, as in the user authority setting field 3722. In this case, according to the data 820 of input / output permission items for each user authority and the user authority data 830 in Fig. 8, the "remarks" field, the attendance confirmation (User) field, the attendance confirmation (Admin) field, and the update button are the input / output permission items.

[0185] FIG. 38 is a schematic diagram for explaining an example of a prototype display screen in this embodiment, and is a screen image displayed in response to user authority setting on the prototype operation panel 3702 in FIG.

[0186] The prototype application screen 3801 in Figure 38 differs from the prototype application screen 3201 in Figure 32 in that the underlined portion 3802 is now displayed with new Attendance Confirmation (Admin) and Attendance Confirmation (User) 3803, and an update button 3804 is also displayed on the right side of the screen.

[0187] The above process has the effect of enabling the creation of a prototype application that performs screen transitions depending on the user's role. In other words, if a prototype application that only performs normal screen transitions is created, it will only be able to display certain screens and perform certain screen transitions regardless of user authority. However, the present invention has a prototype operation panel that allows the user authority to be switched, and it is possible to reproduce the situation where the displayed screen image changes for each user authority by switching the user authority. Furthermore, by having the prototype operation panel, it is possible to change the user authority and check other screen images even while the prototype application is running.

[0188] Next, the flow of processing for displaying a reproduction of the processing time at the server will be described with reference to FIG.

[0189] 28 is a flowchart showing the flow of processing when the processing time in a virtual server is changed. Note that each step in the following flowchart is executed by the CPU 201 of the application client 104.

[0190] The flowchart in FIG. 28 is a flowchart that starts when a developer accesses the application client 104 from the web browser 450 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the web browser 450.

[0191] First, in step S2801, the application client 104 downloads from the application server 102 (430) an SPA on which the prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs.

[0192] Also, in step S2801, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2801 is a step for downloading and launching a program for displaying a prototype application with a screen image such as 3901 in Fig. 39. Examples of screens that display a reproduction of the server processing time will be described with reference to Figs. 39 to 41 and 32.

[0193] FIG. 39 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0194] 39 shows a screen image after the prototype display screen is launched, and is an example of the screen displayed when transitioning to step S2803. In step S2801, the parent screen (2501) of the prototype display screen for this screen is launched.

[0195] In the next step S2802, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. This will be described with reference to FIG.

[0196] FIG. 40 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0197] In step S2802, the prototype application screen 4001 is launched on top of the parent screen launched in step S2801, but since the prototype operation panel 3902, which will be displayed in the next step S2803 and onwards, is displayed on top (as in the relationship between 2502 and 2503 in Figure 25), the initial display screen will be something like 3901 in Figure 39.

[0198] In the next step S2803, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame section of the prototype display screen 2501. The launched screen image is image 3902 in Figure 39. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application. The prototype operation panel 3902 in Figure 39 has a setting field, such as processing time setting field 3931, for reproducing the display of screen transitions of the prototype application 2502, taking into account the processing time on the server.

[0199] When the developer changes the processing time setting field 3931 while the prototype operation panel 3902 is displayed, the process proceeds to the next step S2804.

[0200] In this example, the processing time setting field 3931 is initially set to "0.2 seconds" as in the processing time setting field 3131 of FIG. 31 upon startup, but has been changed to "2 seconds" in the processing time setting field 3931.

[0201] When the process proceeds to the next step S2804, the application client 104 stores in the browser's local storage the value of the server processing time setting field 3931 that was changed on the prototype operation panel 3902. An example of source code to be executed in the process of step S2804 when the processing time setting field is changed after 3901 in Figure 39 is displayed is shown in Figure 44.

[0202] In the next step S2805, the application client 104 changes the setting of the prototype application 2502 to wait for the processing time stored in step S2804, and changes it to a prototype application that is reproduced so as to transition to the next screen. Figure 46 shows a portion of the source code executed in step S2805. The behavior of the prototype application after the change will be described with reference to Figure 41.

[0203] FIG. 41 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0204] For example, as in prototype display screen 3901 in Fig. 39, if processing time setting field 3931 is set to "2 seconds" on prototype operation panel 3902, pressing the transition button to the prototype application screen 3903, for example, will display a screen like 4001 in Fig. 40. Next, when the user presses search button 4002 to reproduce the operation, display screen 4102 is displayed in the center as if processing is currently being performed on the server, as in the screen image in Fig. 41. The time displayed to indicate that processing is currently being performed is the time set in processing time setting field 3931. After display screen 4102 is displayed for the set time, the next screen transition, such as Fig. 32, is displayed.

[0205] The above process has the effect of enabling the creation of a prototype application that reproduces the wait time during screen transitions. In other words, it is possible to reproduce the processing time that occurs on the server side when generating a production environment application (product application). For example, when a business user or sales representative demonstrates a prototype application to a general user, they can reproduce the actual processing time with the server and the screen that will be displayed during the server processing time. Because this prototype display screen application is composed of an SPA, communication with the actual server is not required. Therefore, simply executing the prototype application (screen transition) does not require processing time, and the prototype application transitions screens one after another. Because the operation of the production environment application (product application) does not take into account server processing time, general users who are convinced only by demonstrations that do not take server processing time into account may experience discrepancies in the performance of the development deliverable. With the demonstration of the present invention, the server processing time can be freely set, reducing the risk of discrepancies in the performance of the development deliverable.

[0206] Next, with reference to FIG. 29, the flow of processing for displaying a reproduction of an error that occurs in a server or a communication error will be described.

[0207] 29 is a flowchart showing the flow of processing when an error occurs in a virtual server. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.

[0208] The flowchart in FIG. 29 is a flowchart that starts when a developer accesses the Web browser 450 of the application client 104 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the Web browser 450.

[0209] First, in step S2901, the application client 104 downloads from the application server 102 (430) an SPA on which the prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs.

[0210] Also, in step S2901, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2901 is a step for downloading and launching a program for displaying a prototype application with a screen image such as 4201 in Fig. 42. Examples of screens that display a reproduction when an error occurs on the server will be described with reference to Figs. 40, 42, and 43.

[0211] FIG. 42 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0212] 42 shows a screen image after the prototype display screen is launched, and is an example of the screen displayed when transitioning to step S2903. In step S2901, the parent screen (2501) of the prototype display screen of this screen is launched.

[0213] In the next step S2902, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. An example of the launched prototype application screen is shown in FIG.

[0214] In step S2902, the prototype application screen 4001 is launched on top of the parent screen launched in step S2901, but since the prototype operation panel 4202, which is displayed in the next step S2903 and onwards, is displayed on top (as in the relationship between 2502 and 2503 in Figure 25), the display screen at the beginning of launch will be something like 4201 in Figure 42.

[0215] In the next step S2903, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame section of the prototype display screen 2501. The launched screen image is image 4202 in Figure 42. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application. The prototype operation panel 3902 in Figure 42 has an error occurrence toggle button 4241 for causing a virtual error during communication with the server, and a setting field for reproducing the screen transition display of the prototype application 2502 taking into account the occurrence of an error on the server.

[0216] When the developer turns on the error occurrence toggle button 4241 while the prototype operation panel 4202 is displayed, the process proceeds to the next step S2904.

[0217] At the start of startup, the error occurrence toggle button 4241 is set to "off" like the error occurrence toggle button 3141 in FIG. 31, but in this example, the error occurrence toggle button 4241 is changed to "on."

[0218] When the process proceeds to the next step S2904, the application client 104 stores the "ON" value of the server error occurrence toggle button 4241 changed on the prototype operation panel 4202 as the error setting state in the browser's local storage. An example of source code to be executed in the process of step S2904 when the error setting state is changed after displaying 4201 in Figure 42 is shown in Figure 44.

[0219] The next step S2905 and subsequent steps are the processes to be performed after the user presses the transition button 4203 to the prototype application in Fig. 42. The screen image after the transition button 4203 is pressed is 4001 in Fig. 40.

[0220] In step S2905, the application client 104 acquires the error setting state stored in step S2904 of the prototype application 2502. Figure 46 shows a portion of the source code executed from step S2905 onwards.

[0221] Next, a screen transition instruction from, for example, Fig. 40 is accepted from the user. In the case of Fig. 40, the search button 4002, which is a screen transition instruction, is pressed. When the screen transition instruction is accepted, the process proceeds to the next step S2806.

[0222] In the next step S2906, the application client 104 performs different processing depending on whether the acquired error setting status is on (enabled) or off (disabled). If the error setting status is on, the processing transitions to step S2907, and if the error setting status is off, the processing transitions to step S2908. When the processing transitions to step S2908, since the error setting status is off, the application client 104 transitions to the normal transition screen of the prototype application, shown in Figure 32.

[0223] On the other hand, when the process proceeds to step S2907, the application client 104 proceeds under the assumption that an error has occurred in the prototype application. Specifically, a screen similar to the image shown in FIG. 43 may be displayed.

[0224] FIG. 43 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

[0225] In FIG. 43, specifically, an error display item such as 4302 is displayed as an error display when an error occurs in processing using the search button 4002.

[0226] The above process makes it possible to create a prototype application that can reproduce error screens that occur when a screen transition fails. In other words, it is possible to reproduce errors that occur on the server or during communication when generating a production application (product application). Because this prototype display screen application is configured as an SPA, communication with an actual server is not required. Therefore, simply executing the prototype application (screen transition) will not cause server or communication errors. SPA can meet the needs of developers and general users who want to reproduce the display screen when an error occurs. Furthermore, as a way to more realistically reproduce error displays, it can be combined with reproducing virtual processing time on the server as shown in Figure 28.

[0227] Because the prototype display screen described above is configured as an SPA that can be launched within the browsers of various devices, by downloading the prototype display screen application generated as shown in 2501 in Figure 30 to a personal computer (PC) or tablet, prototype application 2502 can be reproduced on each device. For example, by downloading the prototype display screen application to tablet 3001, the prototype operation panel 2503 and prototype application 2502 can be operated on the tablet. Sales representatives can run the prototype display screen application on a tablet without having to bring their own personal computer (PC). It is possible to run a prototype application that reproduces the processing time of a server on a tablet, and to reproduce a smartphone-sized display (3003) on the tablet display (3002). Therefore, even when demonstrating to customers, by bringing a single device, it is possible to reproduce the screens and screen transition patterns that will be displayed on various devices.

[0228] As described above, it goes without saying that the object of the present invention can also be achieved by supplying a recording medium on which a program that realizes the functions of the above-mentioned embodiments is recorded to a system or device, and having the computer (or CPU or MPU) of that system or device read and execute the program stored on the recording medium.

[0229] In this case, the program itself read from the recording medium will realize the novel functions of the present invention, and the recording medium on which the program is recorded will constitute the present invention.

[0230] Examples of recording media for supplying the program include flexible disks, hard disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, DVD-ROMs, magnetic tapes, non-volatile memory cards, ROMs, EEPROMs, and silicon disks.

[0231] Furthermore, it goes without saying that not only are the functions of the above-mentioned embodiments realized by the computer executing a program it has read, but also cases are included in which an OS (operating system) running on the computer performs some or all of the actual processing based on the instructions of the program, and the functions of the above-mentioned embodiments are realized through that processing.

[0232] Furthermore, it goes without saying that this also includes cases where a program read from a recording medium is written into a memory provided on a function expansion board inserted into a computer or a function expansion unit connected to the computer, and then a CPU or the like provided on the function expansion board or function expansion unit performs some or all of the actual processing based on the instructions of the program code, thereby realizing the functions of the above-mentioned embodiments.

[0233] Furthermore, the present invention may be applied to a system consisting of multiple devices, or to a device consisting of a single device. It goes without saying that the present invention can also be applied to a case where the present invention is achieved by supplying a program to a system or device. In this case, the system or device can enjoy the effects of the present invention by reading a recording medium containing a program for achieving the present invention into the system or device.

[0234] The program may be in the form of object code, program code executed by an interpreter, script data supplied to an OS (operating system), or the like.

[0235] Furthermore, by downloading and reading a program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or device can enjoy the effects of the present invention. Note that the present invention also includes configurations that combine the above-mentioned embodiments and their modified examples. [Explanation of symbols]

[0236] 101 Program Development Device 102 Application Server 103 Database Server 104 Application Client 105 Network

Claims

1. A definition means for defining a screen definition that defines items to be displayed on a screen of the application to be generated and a screen transition definition that defines a procedure for transitioning to the next screen; a screen defined by the definition means and an operation control file generation means for generating an operation control file that reproduces a procedure for transitioning between the screens; The information processing device is characterized in that the operation control file generation means accepts settings for the role of the screen to be reproduced using the generated operation control file, and generates an operation control file that executes the screen transition corresponding to the accepted role in the procedure.

2. The screen definition defined by the definition means defines items to be displayed in a predetermined role, The information processing device according to claim 1, characterized in that the operation control file generation means has a plurality of settings for the role of the screen to be reproduced, accepts a selection from the plurality of settings, and generates an operation control file that executes a screen transition corresponding to the accepted role in the procedure.

3. The method further comprises: a data acquisition means for acquiring data to be reflected in the items of the screen defined by the definition means, which is displayed when a screen is reproduced using the action control file generated by the action control file generation means; 3. The information processing apparatus according to claim 1, wherein the operation control file generated by the operation control file generating means is executed so as to reflect the data acquired by the data acquiring means in the items and reproduce the display on the screen.

4. an operation panel generating means for changing the setting of the role executed by the operation control file while the operation control file is being executed; 4. The information processing apparatus according to claim 1, further comprising:

5. Information processing device A definition step that defines a screen definition that defines items to be displayed on the screen of the application to be generated and a screen transition definition that defines the procedure for transitioning to the next screen; an operation control file generation step for generating an operation control file that reproduces the screen defined in the definition step and the procedure for transitioning between the screens; An information processing method characterized in that the operation control file generation step accepts settings for the role of the screen to be reproduced using the generated operation control file, and generates an operation control file that executes the screen transition corresponding to the role accepted in the procedure.

6. In the information processing device, A definition means for defining a screen definition that defines items to be displayed on a screen of the application to be generated and a screen transition definition that defines a procedure for transitioning to the next screen; functioning as an operation control file generating means for generating an operation control file that reproduces the screen defined by the definition means and the procedure for transitioning between the screens; The program is characterized in that the operation control file generation means accepts settings for the role of the screen to be reproduced using the generated operation control file, and generates an operation control file that executes the screen transition corresponding to the accepted role in the procedure.

Images