JP7719392B2 - Information processing device, information processing method, and program - Google Patents

Description

The present invention relates to an information processing device, information processing method, and program for generating applications.

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

In particular, screens and operating procedures differ from internal logic and operate exactly as the user desires, which increases customer satisfaction.

Patent Document 1 solves the above problem by listening to the user's requests, determining requirements that meet those requests, and simultaneously generating and completing source code for an application program that can be used on the actual device.

JP 2015-210639 A

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

An object of the present invention is to generate an application that allows a user to easily check the screen display corresponding to the user role by operating the application screen .

In order to solve the above-mentioned problems, the present invention provides an application that includes a generating means for generating the application to display screen display items associated with a user role whose selection has been accepted , based on displayability information that associates user roles in the application with screen display items and defines whether the screen display items can be displayed,
The application is characterized in that it displays a setting acceptance section for switching user roles on the application screen, and displays screen display items associated with the user role selected by the setting acceptance section .

According to the present invention, it is possible to generate an application that allows a user to easily check the display of a screen corresponding to a user role by operating the application screen .

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. 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; FIG. 2 is a block diagram showing an example of a software configuration according to an embodiment of the present invention. 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. FIG. 10 is a diagram illustrating an example of a flowchart for generating a prototype application according to an embodiment of the present invention. 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. 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. 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. 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. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 4 is a diagram showing an example of a screen definition 402 according to an embodiment of the present invention. FIG. 4 is a diagram showing an example of a screen definition 402 according to an embodiment of the present invention. FIG. 4 is a diagram showing an example of control of the screen size of a prototype application 442 according to the present invention. FIG. 4 is a diagram showing an example of a screen display of a prototype application 442 according to the present invention. 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. 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. 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. 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. 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. 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. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. FIG. 10 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment.

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.

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

In this embodiment, the application generated by the program development device 101 is a web application, but this is not limited to this. It may also 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.

The application server 102 executes applications developed by the program development device 101. It can also operate in connection with the database server 103.

The database server 103 is a database used by the developed application, and in the present invention may also be used during development for purposes such as checking operation. For example, the database server 103 for use by developers may be configured as the same device as the program development device 101 or application server 102, or may be located within a network 105 such as a LAN.

The application client 104 (information processing device) is an end user's input terminal that operates the application program developed by the program development device 101 in cooperation with the application server 102. This application client 104 may also be an information processing device such as a mobile terminal.

Note that 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 housed in a single housing.

Figure 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.

In Figure 2, the CPU 201 comprehensively controls each device connected to the system bus 204.

In addition, the ROM 203 or external memory 211 stores an operating system (OS), which is the control program for the CPU 201, and programs for realizing the various functions described below of information processing devices such as each server, client, and device.

RAM 202 functions as the CPU 201's main memory, work area, temporary storage area, etc.

The input controller 205 controls input from the input unit 209. In an information processing device, this input unit 209 may include a keyboard, a pointing device such as a mouse, or a touch panel.

If the input unit 209 is a touch panel, the user can issue various instructions by pressing (touching with a finger, etc.) icons, cursors, or buttons displayed on the touch panel.

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

The output controller 206 controls the display of the output unit 210. Examples of this output unit 210 include a CRT or LCD display. Note that this also includes the display of a notebook computer integrated into the main body. It may also be a projector.

The external memory controller 207 controls access to the external memory 211, which stores the boot program, various applications, font data, user files, edit files, printer drivers, etc. The external memory 211 stores various tables and parameters for implementing the 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) connected to a PCMCIA card slot via an adapter, and a SmartMedia card.

The CPU 201 enables display on the output unit 210 by, for example, executing an outline font expansion (rasterization) process in a display information area in the RAM 202. The CPU 201 also enables the developer to give instructions using a mouse cursor (not shown) on the output unit 210.

The communication I/F controller 208 executes communication control processing with external devices via a network. For example, communication using TCP/IP is possible.

The program 212 for implementing 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 needed.

Figure 3 is an example block diagram showing the software configuration of an embodiment of the present invention.

The program development device 101 has the following functional units:

The definition unit 301 is a functional unit that accepts 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, which defines the procedure for transitioning from one application screen to the next. Specifically, this corresponds to the flowchart in Figure 6 and the explanatory diagrams in Figures 10 to 14.

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 screens; specifically, this corresponds to the processing in the flowchart in Figure 8.

The storage unit 303 is a functional unit that stores the screen size when displaying the prototype application on the application client 104, and specifically corresponds to 2310 in Figure 23.

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

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, it is 810 in Figure 8, and the generated prototype operation panel is 3102 in Figure 31, etc.

Figure 4 is a configuration diagram of the program development device 101, application server 102, and application client 104.

The program development device 101 comprises 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. It is a mockup application that displays preset values and pre-drawn diagrams, and imitates screen transitions and display changes like an actual application.

The application server 102 corresponds to the application server unit 430 in Figure 4, and the application client 104 has an application client unit 435.

The program development device 101 generates a prototype display screen (parent screen) 440 using the prototype generation unit 410. In this invention, a developer is not limited to contracted application developers, but also refers to a wide range of people who use the program development device 101, such as business users and sales representatives.

The repository definition section 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. Prototype data refers to the data displayed on the application screen when the prototype application is executed. It does not involve searching for data from a database or creating diagrams from calculated data results as in a production environment, but refers to values and diagrams that are preset by the developer. These definitions 401 to 406 are input, configured, or placed by the developer via an application development tool.

Application definition 401 holds the overall settings for the application being developed by the developer.

The screen definition 402 holds information about various screen component definitions 403 and screen transition definitions 404 that are placed on each screen included in the application. The screen definition 402 also includes information about actions 405 set for various components and prototype data 406 linked to the actions 405.

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.

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

The prototype code generation unit 412 generates source code for the prototype application based on the analysis results of the repository definition analysis unit 411.

The source code compilation unit 413 compiles the source code generated by the prototype code generation unit 412 and deploys the prototype display screen (parent screen) 440, which includes compiled Java (registered trademark) code and HTML/JSP/JavaScript (registered trademark), to the application server unit 430.

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.

The screen definition editor section 421 is a graphical editor that allows developers to intuitively create the desired screen layout.

The screen transition definition editor section 422 is an editor that sets properties for each screen component placed by the developer.

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 client screen width.

An example of the responsive component control unit 423 is described with reference to Figures 23 and 24.

Figure 23 is a schematic diagram illustrating the control of the screen size of the prototype application 442 in the present invention.

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

Data 2310 (storage unit) stores the screen size displayed on the application client 104 when the switching button 2300 is pressed. 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 are described with reference to Figure 24.

Figure 24 is a schematic diagram showing an example of the screen display of the prototype application 442 in the present invention.

For example, in Figure 24, 2402 is a display image of a personal computer screen, 2403 is a display image of a tablet screen, and 2404 is a display image of a smartphone screen. The sizes of each component, 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 Figure 24. In other words, component 2402 is controlled so that on a personal computer screen, 2422 is displayed at 2/12 of 2402 (the entire screen), on a tablet screen, 2423 is displayed at 3/12 of 2403 (the entire screen), and on a smartphone screen, 2424 is displayed at 6/12 of 2404 (the entire screen). Returning to the explanation of the configuration diagram in Figure 4,

The action selection unit 424 is a functional unit that selects an action (action event) for the developer to select the target action for setting the prototype data 406.

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

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.

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 business users (customer decision makers) and sales representatives who make proposals to customers to control and display the display content and operation of applications 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.

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 times on the server, and reproduction of the display screen in the event of a server error.

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 during application development.

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.

Although not shown, the system also has an application code generation unit that actually runs, 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 the repository definition analysis unit 411. The web application code generation unit uses the code generation rules stored in the external memory 211 and the content 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 the source code compilation unit 413.

Figure 5 shows 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.

The flowchart in Figure 5 shows the flow of processing initiated by the 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 the prototype application 442. The processing in step S507 is processing for acquiring information for the prototype operation panel 441 and generating source code for the prototype application including the prototype display screen 440. The processing in each step is explained in detail below.

First, in step S501, the program development device 101 accepts screen definition input. Details of the processing in step S501 will be described later with reference to Figure 6.

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 Figure 12, or 1203 and 1301 in Figure 13, which are examples of the action selection unit 424, have been pressed.

The action control module 442 controls which data from multiple prototype data set by the developer is displayed and 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).

The program development device 101 accepts this press to allow the developer to specify which action the prototype data they are about to enter will be linked to.

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

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

Note that 1202 shows an example of the action selection section when 1201 is pressed. 1301 shows an example of the action selection section when 1203 is pressed. In the example of 1301, a list of actions included in the currently displayed screen definition is displayed, but it is also possible to display a list of actions included in the application definition.

When the process proceeds to step S503, the program development device 101 accepts prototype data input from the developer. Details of the process of step S503 will be described later with reference to Figure 7. Then, the process proceeds to step S504.

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

When the process proceeds to step S505, the program development device 101 saves the screen definition in the repository definition unit 400. Then, the process proceeds to step S506.

When the program development device 101 transitions to step S506, it determines whether a prototype generation request has been made. If it determines that a prototype generation request has been made, it transitions to step S507. On the other hand, if a prototype generation request has not been made, it transitions to step S501.

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

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

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

The following explanation will be given using 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 separate information processing devices, each information processing device will launch each application (such as a prototype application or web browser) and execute the processing.

In step S510, the program development device 101 launches the prototype application deployed to the application server 102 (430).

In step S511, the program development device 101 launches a web browser and begins URL access of the prototype application. Note that the processing of steps S510 and S511 is 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 processing of step S510 is executed by the application server 102, and the processing of step S511 is executed by the application client 104.

This concludes the explanation of Figure 5. The subsequent processing will be described later with reference to Figure 9. Note that in the explanation from Figure 9 onwards, 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, it may also be executed by the program development device 101 that has launched a web browser, just like the application client 104.

Next, the details of the processing in step S501 will be explained with reference to Figure 6.

Figure 6 shows an example of a flowchart for accepting input of a web application screen definition. Note that each step in the following flowchart is executed by the CPU 201 of each device.

The flowchart in Figure 6 shows the processing flow that begins when processing transitions to step S501 in the flowchart in Figure 5.

First, in step S601, the program development device 101 accepts the placement of screen components by the developer. Specifically, the placement of components is accepted by dragging and dropping 1003 from 1001 in FIG. 10, which is an example of the component palette section 423, to 1002, which is an example of the screen definition editor section 421. FIG. 10 shows an example of dragging and dropping a button component from the component palette section to the screen definition editor section. The method of placing screen components is not limited to dragging and dropping from the component palette section 423 to the screen definition editor section 421, but may also be a method of moving an already placed component or a method of duplicating an already placed component by copying and pasting. Furthermore, it may be possible to delete components that have been placed once.

In the case of Figure 10, as shown in 1004, a screen image has been created that includes two text input fields (ID input field and name input field) and a registration button for registering the ID and name.

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; if a component including an action event has not been placed, the process proceeds to step S604.

When the program proceeds to step S603, the program development device 101 registers the action set for the component that includes the action event. Specifically, the action is registered for the component that has an action called onClick in the component's source code. In 2100 in Figure 21, which is an example of a screen definition 402, an "actions" definition 2102 corresponding to the production environment and an "examples" definition 2103 corresponding to the prototype application are written out. Note that in the example in Figure 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 program proceeds to step S604.

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

If it is determined that a property input request has been made, the process proceeds to step S605; if no property input request has been made, the screen definition input acceptance process ends.

When the process proceeds to step S605, the program development device 101 accepts the developer's input of properties for the screen component. Specifically, it displays 1102 in Figure 11, which is an example of a screen property editor, and accepts input of settings for the properties of the screen component. In the example of Figure 11, the screen property editor is displayed near the component to enable intuitive operation by the developer, but a specific area on the screen may be reserved as the screen property editor. The screen property editor may also be displayed in a modal dialog.

This concludes the explanation of Figure 6.

Next, the details of the processing in step S503 will be explained with reference to Figure 7.

Figure 7 shows 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 in the following flowchart is executed by the CPU 201 of each device.

The flowchart in Figure 7 shows the processing flow that begins when processing transitions to step S503 in the flowchart in Figure 5.

First, in step S701, the program development device 101 reads the settings for the action item specified by the developer in step S502 of Figure 5. Specifically, the following two steps are performed. First, 2101 in Figure 21, which is an example of 1004 in Figure 10, which is an example of the screen component definition 403 for the screen component selected by the developer, is read. The data for 2101 is assumed to have been input from 1102 in Figure 11 in step S605 of the flowchart in Figure 6. Next, 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 are read.

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 stores the screen transition definition 404 in the screen component definition 403, but it may also store it in the action definition 405.

If it is determined that the action item settings loaded in step S701 involve a screen transition, the process proceeds to step S703; if the action item settings loaded in step S701 do not involve a screen transition, the process proceeds to step S704.

When the program development device 101 proceeds to step S703, it displays the destination screen of the screen transition associated with the setting of the action item read in step S701. Specifically, it displays 1300 in Figure 13, which is the screen set in "nextUi" of 2101. Note that the destination screen 1302 in Figure 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 way that rewrites the currently displayed screen definition editor unit 421, or in a way that launches a new screen definition editor unit 421.

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

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

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) in advance when running a prototype application. Specifically, this is an example of displaying prototype data in a list such as 1302 in Figure 13, displayed in the screen definition editor unit 421. In the prototype data display component 1402 in the same figure, Figure 14, the selection of the prototype data display component can be accepted by, for example, right-clicking the mouse (not shown) in the "Name" column and pressing the edit button 1403. Furthermore, after selecting the entire list as shown in 1701 in Figure 17, pressing the table input button 1702 selects the entire list of 1701 as the prototype data display component.

In the next step S706, the program development device 101 accepts prototype data input by the developer. Specifically, it displays the prototype data input dialog 1501 in Figure 15, which is an example of the prototype data input unit 425. 1501 is the prototype data input dialog that is displayed when the edit button is pressed in the "Name" field in 1401 in Figure 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, a determination is made in step S707 as to whether the input has been confirmed by pressing the "OK" button in 1501.

As another example of step S706, an example of the prototype data input section 425 will be described with reference to Figure 18.

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

After the developer enters a value in the text input field or reflects the data after selecting a file, by pressing the "OK" button 1803, a determination is made in step S707 as to whether the input has been confirmed.

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

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 of step S706, if direct input to a component has been accepted, it determines whether the focus has been removed from that component.

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

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

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

In this way, by displaying the screen image showing the prototype data on the prototype application with screen transitions for each action event, you can get an idea of how the mockup will work before creating an application that actually works (for example, searching a database or drawing from the extracted data).This concludes the explanation of Figure 7.

Next, the details of the processing in step S507 will be explained with reference to Figure 8.

Figure 8 is an example flowchart illustrating the process of 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.

The flowchart in Figure 8 shows the processing flow that begins when processing transitions to step S507 in the flowchart in Figure 5.

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 ROM 203, and the analyzed definition is referenced by each generation unit as appropriate.

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

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

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

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

In step S805, the program development device 101 collects the permissions (roles) associated with the display items obtained in step S802.

In step S806, the program development device 101 reads the prototype data 406 contained 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.

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

Figure 31 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

The prototype operation panel will be described with reference to Figure 31. The prototype operation panel is a panel screen that accepts display settings and transition settings from the developer when displaying a prototype (prototype) screen or when transitioning between prototype (prototype) screens. The prototype operation panel can be used to set the display device (personal computer, tablet, smartphone, etc.) and the display device's screen orientation, the display of screens based on user access rights (Admin authority, User authority, etc.), the display of processing time on the server, and the display when an error occurs. Display device settings can be set in 3111 of 3102, user authority settings in 3121 of 3102, processing wait time settings in 3131 of 3102, and error display settings in 3141 of 3102.

The relationship between the prototype application screen and the prototype operation panel 3102 when it is open is explained with reference to Figures 25 and 31.

Figure 25 explains the relationship between the prototype application screen and the prototype operation panel.

The prototype display screen 2501, which serves as the base parent screen, is the parent screen displayed on the browser, and within the parent screen, a prototype application screen 2502 is displayed in 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 viewed simultaneously.

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, the 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), press the prototype operation panel display button 3202 (2523) to transition to the screen image 3101 of Figure 31, where the prototype operation panel 3102 is displayed. Return to the explanation of the flowchart in Figure 8.

An example of the source code generated in step S807 is shown in Figure 44. Figure 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.

Next, in step S808, the program development device 101 generates source code for changing the screen display for each user's authority. An example of the generated source code is shown in Figure 45. Figure 45 is an example of source code that is executed when user authority is changed, for example, for prototype operation panel 3521 in Figure 35 or prototype operation panel 3721 in Figure 37. When user authority is changed, the source code in Figure 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 user authority is set.

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 Figure 46. Figure 46 is an example of source code that is executed when, for example, a processing time (processing wait time) value is entered in the option setting field 3131 or 3141 of the prototype operation panel 3102, as in 3931 in Figure 39, or when the error setting is changed to on, as in 4241 in Figure 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 a process for generating a program for reproducing pseudo communications and server status when communicating with the server.

In step S810, after drawing the prototype operation panel screen 2503, 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). An example of the generated source code is shown in Figure 47. Figure 47 is 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, which sets it to a PC (personal computer setting) image, or to a smartphone setting as in the image 3311 of Figure 33.

Once the above source code is generated, the processing of the flowchart in Figure 8 is completed. Note that although the source code (Figures 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.

This concludes the explanation of Figure 8.

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 in FIG. 5, or the web browser launched in the application client 104 may start communication with the deployed application server 102, as in FIG. 9.

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

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

In step S901, the application client 104 first reads the browser's locale information. This locale information allows the display language of the prototype data to be switched.

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 Figure 8) runs. Note that in this 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 the initial screen information for the prototype application is downloaded.

Also, in step S902, the application client 104 obtains user permission information for the prototype application.

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). In other words, step S902 is a step in which a program for displaying the prototype application with a screen image such as 3101 in Figure 31 is downloaded and launched.

In the next step S903, 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 Figure 32, but because the prototype operation panel 3102, which will be displayed from the next step S904 onwards, is displayed on top (the relationship is similar to that between 2502 and 2503 in Figure 25), the initial display screen upon launch is similar to that shown in 3101 in Figure 31.

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.

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 on the prototype operation panel 3102. The screen display or transition screen display process of the prototype application 440 according to the settings will be described later with reference to Figures 26 to 29.

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.

Next, in step S905, the process flow for changing the display screen of the prototype application 3201 (442) or changing the transition screen based on 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 permissions, replicating processing time with the server, and replicating when an error occurs.

Figure 26 is a flowchart showing the processing flow when switching display devices. Note that each step in the following flowchart is executed by the CPU 201 of the application client 104.

The flowchart in Figure 26 is a flowchart that starts when a developer accesses the application client 104's 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 Figures 26 to 29 overlap with the explanation in Figure 9.

First, in step S2601, the application client 104 downloads the SPA running the prototype display screen (the application generated in steps S807 to S810 in Figure 8) from the application server 102 (430).

Also, in step S2601, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). In other words, step S2601 is a step in which a program for displaying a prototype application with a screen image such as 3101 in Figure 31 is downloaded and launched.

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 Figure 32, but because the prototype operation panel 3102, which will be displayed from the next step S2603 onwards, is displayed on top (the relationship is similar to that between 2502 and 2503 in Figure 25), the initial display screen upon launch will be similar to that of 3101 in Figure 31.

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.

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. The screen image when the developer changes the device input field 3111 will be explained with reference to Figure 33. The device input field 3111 is an input field for which the screen size of each terminal (personal computer, tablet, smartphone) is pre-set, 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.

Figure 33 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

The device selection field 3311 of the prototype operation panel 3302 in Figure 33 is an example in which the smartphone screen button 3312 has been pressed, unlike the prototype operation panel 3102 in Figure 31.

Returning to the explanation of the flowchart in Figure 26, when processing transitions to the next step S2604, the application client 104 accepts an instruction to change the screen size to match the device changed on the prototype operation panel 3302. Figure 47 shows an example of source code that executes the processing of steps S2603 and S2604 after displaying 3101 in Figure 31.

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 Figure 33 are accepted will be explained with reference to Figure 34.

Figure 34 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

The prototype application screen 3401 in Figure 34 is displayed at the smartphone size of 3402. Even when the screen is displayed at the smartphone size, the processing of the prototype application as a prototype is executed, and for example, when a specific button is pressed, a transition screen reflecting the prototype data corresponding to that action can be displayed.

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 on which the prototype application screen 3401 in FIG. 34 is displayed in the foreground (2521 in FIG. 25) 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 on which the prototype application screen 3401 in FIG. 34 is displayed in the foreground (2521 in FIG. 25) 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 prototype operation panel 3302 screen) may be performed, for example, by pressing the translucent button 3202 in the lower right of FIG. 32.

The above process makes it easy to create prototype applications with different display formats for each device.

Next, referring to Figure 27, we will explain the process for changing the screen display when user permissions are changed.

Figure 27 is a flowchart showing the processing flow when switching user privileges. Note that each step in the following flowchart is executed by the CPU 201 of the application client 104.

The flowchart in Figure 27 is initiated when a developer accesses the application client 104's web browser 450 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the web browser 450.

First, in step S2701, the application client 104 downloads the SPA running the prototype display screen (the application generated in steps S807 to S810 in Figure 8) from the application server 102 (430).

Also, 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 generating the prototype display screen application.

Furthermore, in step S2701, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). In other words, step S2701 is a step in which a program for displaying a prototype application with a screen image such as 3101 in Figure 31 is downloaded and launched.

In the next step S2702, 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 initially 3201 in Figure 32, but because the prototype operation panel 3102, which is displayed in the next step S2703 onwards, is displayed on top (the relationship is similar to that of 2502 and 2503 in Figure 25), the initial display screen upon launch is similar to that of 3101 in Figure 31.

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 (prototype) application. As shown in the user authority setting field 3121 in Figure 31, the check boxes for user authority settings are generated from the user authority data 830 acquired in step S805.

If 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 is explained with reference to Figure 35.

Figure 35 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

The user authority setting field 3521 of the prototype operation panel 3502 in Figure 35 differs from the prototype operation panel 3102 in Figure 31 in that "user" is checked instead of "guest" in the user authority setting field 3521.

Returning to the explanation of the flowchart in Figure 27, when processing proceeds to the next step S2704, the application client 104 stores the value of the user authority setting field 3521 changed on the prototype operation panel 3502 in the browser's local storage. Figures 44 and 45 show examples of source code that executes the processing of steps S2704 and S2705 when the user authority setting field is changed after displaying 3101 in Figure 31.

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 Figure 35 is accepted will be described with reference to Figure 36.

Figure 36 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

The prototype application screen 3601 in Figure 36 differs from the prototype application screen 3201 in Figure 32 in that a new "Attendance Confirmation (User)" field has been added and displayed in the underlined portion 3602. This is an image 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.

Here's another example:

Figure 37 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

The user authority setting field 3721 of the prototype operation panel 3702 in Figure 37 differs from the prototype operation panel 3102 in Figure 31 in that "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 Figure 8, the input/output permission items are the "Remarks" field, the attendance confirmation (User) field, the attendance confirmation (Admin) field, and the update button.

Figure 38 is a schematic diagram illustrating an example of a prototype display screen in this embodiment, and is a screen image displayed in response to user authority settings on the prototype operation panel 3702 in Figure 37.

The prototype application screen 3801 in Figure 38 differs from the prototype application screen 3201 in Figure 32 in that the underlined portion 3802 now includes new Attendance Confirmation (Admin) and Attendance Confirmation (User) 3803, and an update button 3804 has also been added to the right of the screen.

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 permissions. However, the present invention includes a prototype operation panel that allows you to switch user permissions, so that the displayed screen image changes for each user permission. Furthermore, the prototype operation panel makes it possible to change user permissions and check other screen images even while the prototype application is running.

Next, we will explain the process flow for displaying a reproduction of the processing time on the server, with reference to Figure 28.

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

The flowchart in Figure 28 is a flowchart that starts when a developer accesses the application client 104's web browser 450 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the web browser 450.

First, in step S2801, the application client 104 downloads the SPA running the prototype display screen (the application generated in steps S807 to S810 in Figure 8) from the application server 102 (430).

Furthermore, in step S2801, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). In other words, step S2801 is a step in which a program for displaying a prototype application with a screen image such as 3901 in Figure 39 is downloaded and launched. Examples of screens that display a reproduction of the server's processing time are described with reference to Figures 39 to 41 and 32.

Figure 39 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

Figure 39 shows a screen image after the prototype display screen is launched, and is an example of the screen that is displayed when transitioning to step S2803. In step S2801, the parent screen (2501) of this screen's prototype display screen is launched.

In the next step S2802, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame section of the prototype display screen 2501. This will be explained with reference to Figure 40.

Figure 40 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

In step S2802, the prototype application screen 4001 is launched on top of the parent screen launched in step S2801, but the prototype operation panel 3902, which is displayed in the next step S2803 onwards, is displayed on top (the relationship is similar to that between 2502 and 2503 in Figure 25), so at initial launch the display screen will be similar to that shown in 3901 in Figure 39.

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 (prototype) 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.

If the developer changes the processing time setting field 3931 while the prototype operation panel 3902 is displayed, the process transitions to the next step S2804.

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

When processing proceeds to the next step S2804, the application client 104 stores the value of the server processing time setting field 3931 changed on the prototype operation panel 3902 in the browser's local storage. Figure 44 shows an example of source code executed in step S2804 when the processing time setting field is changed after displaying 3901 in Figure 39.

In the next step S2805, the application client 104 changes the prototype application 2502 to a setting that waits for the processing time stored in step S2804, and changes the prototype application to one 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 explained with reference to Figure 41.

Figure 41 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

For example, as in prototype display screen 3901 in Figure 39, if the processing time setting field 3931 is set to "2 seconds" on prototype operation panel 3902, pressing the transition button to the prototype application screen, for example, 3903, will display a screen like 4001 in Figure 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 Figure 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 Figure 32, is displayed.

The above process has the effect of enabling the creation of a prototype application that reproduces the wait times 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 see what screens will be displayed during that 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 transitions) requires no 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, server processing time can be freely set, reducing the risk of discrepancies in the performance of the development deliverable.

Next, referring to Figure 29, we will explain the process for displaying a replay of server errors, communication errors, and other errors that occur.

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

The flowchart in Figure 29 is initiated when a developer accesses the application client 104's web browser 450 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the web browser 450.

First, in step S2901, the application client 104 downloads the SPA running the prototype display screen (the application generated in steps S807 to S810 in Figure 8) from the application server 102 (430).

Furthermore, 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 in which a program for displaying a prototype application with a screen image such as 4201 in Figure 42 is downloaded and launched. Examples of screens that display a reproduction when an error occurs on the server will be described with reference to Figures 40, 42, and 43.

Figure 42 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

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

In the next step S2902, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame section of the prototype display screen 2501. Figure 40 shows an example of the launched prototype application screen.

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

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 (prototype) application. The prototype operation panel 3902 in Figure 42 has an error occurrence toggle button 4241 for causing a virtual error when communicating 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.

When the prototype operation panel 4202 is displayed and the error occurrence toggle button 4241 is turned "on" by the developer, processing transitions to the next step S2904.

When the error occurrence toggle button 4241 is first launched, it is set to "off" like the error occurrence toggle button 3141 in Figure 31, but in this example, it has been changed to "on."

When processing transitions 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. Figure 44 shows an example of source code executed in the processing of step S2904 when the error setting state is changed after displaying 4201 in Figure 42.

The next step S2905 and onwards is the processing that occurs after the user presses the transition button 4203 to the prototype application in Figure 42. The screen image that appears after pressing the transition button 4203 is 4001 in Figure 40.

In step S2905, the application client 104 retrieves the error setting status of the prototype application 2502 stored in step S2904. Figure 46 shows part of the source code executed from step S2905 onwards.

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

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, processing transitions to step S2907; if the error setting status is off, processing transitions to step S2908. When processing transitions to step S2908, because the error setting status is off, the application client 104 transitions to Figure 32, which is the normal transition screen for the prototype application.

On the other hand, when processing transitions 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 one shown in Figure 43 may be displayed.

Figure 43 is a schematic diagram illustrating an example of a prototype display screen in this embodiment.

In Figure 43, specifically, an error display item such as 4302 is displayed as an error display when an error occurs during processing using the search button 4002.

The above process makes it possible to create a prototype application that can reproduce error screens 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 composed of an SPA, communication with an actual server is not required. Therefore, simply executing the prototype application (screen transition) will not result in 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. Additionally, 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.

Since the prototype display screen described above is composed of 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 a personal computer (PC). It is possible to run a prototype application that reproduces the processing time on 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.

As described above, it goes without saying that the object of the present invention can also be achieved by supplying a recording medium containing a program that realizes the functions of the above-mentioned embodiments 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.

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

Storage media for supplying the program include, for example, flexible disks, hard disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, DVD-ROMs, magnetic tapes, non-volatile memory cards, ROMs, EEPROMs, silicon disks, etc.

It goes without saying that the functions of the above-mentioned embodiments are not only realized by the computer executing a program read by the computer, but also include cases where the 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.

Furthermore, it goes without saying that this also includes cases where a program read from a recording medium is written into memory on a function expansion board inserted into a computer or on a function expansion unit connected to a computer, and then a CPU or the like 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.

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 cases where the 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 invention into the system or device.

The program may take the form of object code, program code executed by an interpreter, script data supplied to an OS (operating system), etc.

Furthermore, by downloading and reading the program for achieving the present invention from a server, database, etc. on a network using a communications program, the system or device can enjoy the effects of the present invention. Note that configurations that combine the above-mentioned embodiments and their variations are all included in the present invention.

101 Program development device 102 Application server 103 Database server 104 Application client 105 Network

Claims (12)

a generating means for generating the application that displays the screen display items associated with the user role whose selection has been accepted, based on displayability information that associates the user role in the application with the screen display items and defines whether the screen display items can be displayed;
The information processing system is characterized in that the application displays a plurality of options corresponding to the user role in a setting reception unit for switching the user role displayed on the screen of the application, and displays screen display items associated with the user role selected by the setting reception unit. The information processing system described in claim 1, characterized in that the user role whose selection has been accepted is a user role whose selection has been accepted by an operator. 3. The information processing system according to claim 1 , wherein the setting acceptance section is displayed together with a screen of the application. 4. The information processing system according to claim 1 , wherein the setting reception section is displayed superimposed on a screen of the application. An information processing system according to any one of claims 1 to 4 , characterized in that, when switching the user role of the setting reception unit, the application displays screen display items associated with the user role selected without going through user authentication processing of the application. an acquisition means for acquiring definition information for generating the application;
the generating means generates the application using the definition information;
6. The information processing system according to claim 1 , wherein the definition information includes the display availability information. the definition information includes screen definition information to be displayed on a screen of the application,
7. The information processing system according to claim 6 , wherein the screen definition information includes the display availability information. 8. The information processing system according to claim 1, wherein the application is a prototype application. 9. The information processing system according to claim 8 , wherein the application screen is a prototype application screen for confirming a product application screen. 10. The information processing system according to claim 8 , wherein the generating means generates the prototype application using prototype data that is a value preset by a developer of the application. A control method for an information processing system, comprising:
a generation step in which a generation means of the information processing system generates the application that displays the screen display items associated with the user role whose selection has been accepted, based on displayability information that associates the user roles in the application with the screen display items and defines whether the screen display items can be displayed;
The application displays a plurality of options corresponding to the user role in a setting reception unit for switching the user role displayed on the screen of the application, and displays screen display items associated with the user role selected by the setting reception unit. A program for causing at least one computer to function as each of the means of the information processing system according to any one of claims 1 to 10 .