Information processing device, 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 apparatus, an information processing method, and a program for generating an application.

Background Art

[0002] When creating an application for a customer, if the customer's needs are first grasped and the application is created, it is possible to reduce rework and improve development efficiency.

[0003] In particular, unlike internal logic, the screen and operation procedures, etc., operating as the user desires contributes to increasing customer satisfaction.

[0004] Patent Document 1 solves the above problems by listening to the user's needs, determining requirements along with the needs, and simultaneously generating and completing the source code of an application program that can be used for an actual machine on the spot.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] Patent Document 1 describes generating a mock-up file for an application and generating the source code of a mock-up application that realizes mock-up screen transitions, but does not consider the control of screen transitions due to differences in roles (job positions and jurisdictions) that can be considered in business.

[0007] An object of the present invention is to create a prototype (prototype) application that changes the screen depending on the user's role.

Means for Solving the Problems

[0008] 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 the 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 the setting of the roles of the screens 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] The present invention has the effect of enabling the creation of a prototype application that performs screen transitions depending on the user's role. [Brief explanation of the drawing]

[0010] [Figure 1] This is a system configuration diagram showing an example of the configuration of a program development device, application server, database server, and application client according to the present invention. [Figure 2] This block diagram shows examples of hardware configurations applicable to the program development device, application server, database server, and application client according to the present invention. [Figure 3] This is a block diagram showing an example of a software configuration according to an embodiment of the present invention. [Figure 4] This figure shows an example of the functional configuration of a first program development device according to an embodiment of the present invention. [Figure 5] This figure shows an example of a flowchart for generating a prototype application according to an embodiment of the present invention. [Figure 6] This figure shows an example of a flowchart for screen definition input reception processing according to an embodiment of the present invention. [Figure 7]It is a diagram showing an example of a flowchart of prototype data input reception processing according to an embodiment of the present invention. [Figure 8] It is a diagram showing an example of a flowchart of prototype application source code generation processing according to an embodiment of the present invention. [Figure 9] It is a diagram showing an example of a flowchart of processing when a prototype application is executed according to an embodiment of the present invention. [Figure 10] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 11] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 12] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 13] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 14] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 15] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [[ID=2**]] [Figure 16] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 17] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 18] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 19] It is a diagram showing an example of a screen image displayed on the output unit 21* according to an embodiment of the present invention. [Figure 20] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 21] It is a diagram showing an example of screen definition 402 according to an embodiment of the present invention. [Figure 22] It is a diagram showing an example of the screen definition 402 according to an embodiment of the present invention. [Figure 23] It is a diagram showing an example of controlling the screen size of the prototype application 442 according to the present invention. [Figure 24] It is a diagram showing an example of the screen display of the prototype application 442 according to the present invention. [Figure 25] It is a diagram for explaining the relationship between the prototype application screen and the prototype operation panel according to an embodiment of the present invention. [Figure 26] It is a diagram showing an example of a flowchart at the time of executing the prototype screen display application according to an embodiment of the present invention. [Figure 27] It is a diagram showing an example of a flowchart at the time of executing the prototype screen display application according to an embodiment of the present invention. [Figure 28] It is a diagram showing an example of a flowchart at the time of executing the prototype screen display application according to an embodiment of the present invention. [Figure 29] It is a diagram showing an example of a flowchart at the time of executing the prototype screen display application according to an embodiment of the present invention. [Figure 30] It is a diagram showing an example of a device that can be displayed on a browser according to an embodiment of the present invention. [Figure 31] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 32] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 33] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 34] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 35] It is a diagram showing an example of a screen image displayed on the output unit 210 according to an embodiment of the present invention. [Figure 36]This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 37] This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 38] This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 39] This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 40] This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 41] This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 42] This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 43] This figure shows an example of a screen image displayed in the output unit 210 according to an embodiment of the present invention. [Figure 44] This figure shows a partial example of the prototype application source code according to this embodiment. [Figure 45] This figure shows a partial example of the prototype application source code according to this embodiment. [Figure 46] This figure shows a partial example of the prototype application source code according to this embodiment. [Figure 47] This figure shows a partial example of the prototype application source code according to this embodiment. [Modes for carrying out the invention]

[0011] Embodiments of the present invention will be described in detail below with reference to the drawings. <First Embodiment> Figure 1 is a system (information processing system) configuration diagram showing an example of the configuration of a program development device (information processing device operated by a developer to generate a web application), application server, database server, and application client related to the present invention.

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

[0013] In this embodiment, the application generated by the program development device 101 is a web application, but it is not limited to this. It may also be an application that does not utilize web technology for communication, 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 on the program development device 101. It can also operate in connection with the database server 103.

[0015] The database server 103 is a database used by the developed application, and in this invention, it may also be used during development for operational verification, etc. For example, for use by developers, the database server 103 may be configured on the same device as the program development device 101 and the application server 102, or it may be located within a network 105 such as a LAN.

[0016] The application client 104 (information processing device) is an end-user input terminal that operates the application program developed on 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.

[0017] Furthermore, 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 enclosure.

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

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

[0020] Furthermore, the ROM 203 or external memory 211 stores the operating system (OS), which is the control program for the CPU 201, as well as programs for realizing various functions of the information processing devices, such as servers, clients, and other devices, as described later.

[0021] RAM202 functions as the main memory, work area, and temporary storage area for CPU201.

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

[0023] Furthermore, if the input unit 209 is a touch panel, the user can give various instructions by pressing (touching with a finger, etc.) the icons, cursors, or buttons displayed on the touch panel.

[0024] Furthermore, the touch panel may be a multi-touch screen or other touch panel capable of detecting the positions of multiple fingers touching it.

[0025] The output controller 206 controls the display of the output unit 210. Examples of the output unit 210 include CRTs and liquid crystal displays. It also includes the display of a notebook computer integrated with the main unit. Furthermore, a projector may also be used.

[0026] The external memory controller 207 controls access to the external memory 211, which stores boot programs, various applications, font data, user files, editing 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 hard disks (HDs), flexible disks (FDs), CompactFlash® cards connected to PCMCIA card slots via adapters, SmartMedia, etc.

[0027] The CPU 201 enables display on the output unit 210 by, for example, performing outline font expansion (rasterization) processing in the display information area of ​​RAM 202. The CPU 201 also enables developer instructions via a mouse cursor (not shown) on the output unit 210.

[0028] The communication interface controller 208 performs communication control processing with external devices via the network. For example, it can perform communication using TCP / IP.

[0029] The program 212 for realizing the present invention is stored in external memory 211 and is executed by the CPU 201 when loaded into RAM 202 as needed.

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

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

[0032] The definition unit 301 is a functional unit that receives screen definition information from the developer, such as the arrangement of screens and items (input / output items) displayed in the application, and screen transition definition information that defines the procedure for an application screen to transition 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) to reproduce the screens defined in the definition unit 301 and the procedures for transitioning between screens. Specifically, this corresponds to the processing in the flowchart shown in Figure 8.

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

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

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

[0037] Figure 4 is a diagram showing the configuration 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. The prototype application of this invention differs from applications that search for data from a database or create diagrams from calculated data results, as in a production environment. Instead, it displays pre-set values ​​and pre-drawn diagrams, and mimics screen transitions and display changes in the manner of an actual application, serving as a mock-up application.

[0039] The application server 102 corresponds to the application server unit 430 in Figure 4, and the application client 104 includes the 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 this invention, the term "developer" refers not only to contract developers of applications, but also to a wide range of users of the program development device 101, such as business users and sales representatives.

[0041] The repository definition section 400 stores the application definition 401, screen definition 402, screen component definition 403, screen transition definition 404, actions 405 associated with screen component definition 402, and prototype data 406 associated with action 405. Prototype data refers to the data displayed on the application screen when the prototype application is executed, and does not involve searching for data from a database or creating diagrams from calculated data results as in the production environment, but rather refers to values ​​and diagrams that have been pre-set by the developer. These definitions 401 to 406 are input and configured or placed by the developer via the application development tool.

[0042] Application definition 401 holds the settings for the entire application that the developer is developing.

[0043] The screen definition 402 holds information on 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 on actions 405 set for each component and prototype data 406 associated with 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, it deploys the prototype display screen (parent screen) 440 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 according to the analysis results of the repository definition analysis unit 411.

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

[0048] The repository definition editor section 420 is an example of a procedure for a user to configure 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 section 421 is a graphical editor that allows developers to intuitively create their desired screen layouts.

[0050] The screen transition definition editor section 422 is an editor that allows developers to set properties for each screen component they have placed.

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

[0052] An example of the responsive component control unit 423 will be explained with reference to Figures 23 and 24.

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

[0054] For example, as shown in Figure 23, button 2300 displays buttons on the application generation screen to switch between multiple types of client display screens, 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, the data stored in 2310 (storage unit) is 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 are explained with reference to Figure 24.

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

[0057] For example, in Figure 24, 2402 is a display image for a personal computer screen, 2403 is a display image for a tablet screen, and 2404 is a display image for a smartphone screen. The size of each component is different; for example, component 2422 on the personal computer screen 2402 is 2423 on the tablet screen 2403 and 2424 on the smartphone screen 2404. The responsive component control unit 423 controls the display of the same components 2422, 2423, and 2424 in a predetermined proportion of the width of the entire screen (2402, 2403, and 2404), as shown in Figure 24. That is, on the personal computer screen, component 2422 is displayed at 2 / 12 of 2402 (the entire screen), on the tablet screen, component 2423 is displayed at 3 / 12 of 2403 (the entire screen), and on the smartphone screen, component 2424 is displayed at 6 / 12 of 2404 (the entire screen). Returning to the explanation of the configuration diagram in Figure 4.

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

[0059] The prototype data input unit 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 sends 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 business users (customer decision-makers) and sales representatives who make proposals to customers to control and display the display content and operation of the application generated by the program development device 101 during application development. The prototype display screen (parent screen) 440 includes the prototype operation panel 441 and the prototype application 442.

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

[0063] The prototype application 442 is a mock-up application used by business users (customer decision-makers) and sales representatives who make proposals to customers to reproduce the display content and operation of the application generated by the program development device 101 during application development.

[0064] The application client unit 435 downloads the prototype display screen (parent screen) 440 from the application server unit 430, and in the web browser 450, launches the prototype display screen (parent screen) 440, which is composed of an SPA (Single Page Application).

[0065] Although not shown in the diagram, the system also includes an application code generation unit that generates actual working application code, not just a prototype application. The application code generation unit, using the repository definition analysis unit 411, 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. The web application code generation unit uses the code generation rules stored in external memory 211 and the content analyzed by the repository definition analysis unit 411 to generate a web application module including compiled Java® code and HTML / JSP / JavaScript® via the source code compilation unit 413.

[0066] Figure 5 shows an example flowchart for generating a prototype application for a web application. Note that each step in the flowchart below is executed by CPU 201 of each device.

[0067] The flowchart in Figure 5 shows the processing flow initiated by the program development device 101 when a developer attempts to generate a prototype application. Steps S501 to S506 are information acquisition processes for generating the prototype application 442. Step S507 is the process of acquiring information for the prototype operation panel 441 and generating the source code for the prototype application, including the prototype display screen 440. The processing of each step is described in detail below.

[0068] First, in step S501, the program development device 101 receives screen definition input. Details of the process in step S501 will be described later with reference to Figure 6.

[0069] Next, in step S502, the program development device 101 determines whether there has been a request for input of 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.

[0070] The action control module 442 controls which prototype data is displayed and at what timing during execution of the prototype display screen (parent screen) 440, from among multiple prototype data set by the developer. Furthermore, the action control module 442 controls the actions associated with each action of the components placed on the screen. In other words, prototype data is linked to actions (action events).

[0071] The program development device 101 accepts the press in order to have the developer specify which action the prototype data they are about to input is associated with.

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

[0073] On the other hand, if there is no request for prototype data input 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. Similarly, an example of the action selection section when 1203 is pressed is shown in 1301. In the example in 1301, a list of actions included in the currently displayed screen definition is shown, but a list of actions included in the application definition may also be displayed.

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

[0076] In step S504, the program development device 101 determines whether a screen definition save request has been made. If it determines that a screen definition save request has been made, it proceeds to step S505; otherwise, it proceeds to step S506.

[0077] When the process moves to step S505, the program development device 101 saves the screen definition to the repository definition unit 400. Then, the process moves to step S506.

[0078] When the process transitions to step S506, the program development device 101 determines whether a prototype generation request has been made. If it determines that a prototype generation request has been made, the process transitions to step S507. On the other hand, if there is no prototype generation request, the process transitions to step S501.

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

[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] From here on, the explanation will be based on an example where the program development device 101, application server 102, and application client 104 are all run on the same information processing device. However, if each is run on a separate information processing device, each information processing device will launch and execute its respective application (such as a prototype application or a web browser).

[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 launches a web browser and begins accessing the URL of the prototype application. Note that the processes in steps S510 and S511 are examples where the program development device 101 is using both an application server 102 and an application client 104. If they are in separate enclosures, the process in step S510 will be executed by the application server 102, and the process in step S511 will be executed by the application client 104.

[0085] This concludes the explanation of Figure 5. Subsequent processing will be described later with reference to Figure 9. In the explanation from Figure 9 onward, the prototype application is described as being executed on the application client 104 with a web browser launched, rather than on the program development device 101. However, it may also be executed on the program development device 101 with a web browser launched, similar to the application client 104.

[0086] Next, the details of the process in step S501 will be explained with reference to Figure 6.

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

[0088] The flowchart in Figure 6 shows the sequence of processes that begin when the process transitions to step S501 in the flowchart in Figure 5.

[0089] First, in step S601, the program development device 101 accepts the placement of screen components by the developer. Specifically, it accepts the placement of components by drag-and-drop 1003 from 1001 in Figure 10, which is an example of the component palette unit 423, to 1002, which is an example of the screen definition editor unit 421. Figure 10 shows an example of dragging and dropping a button component 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; it may also be by moving already placed components or by copying and pasting already placed components. Furthermore, it may be possible to delete components that have been placed once.

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

[0091] Next, in step S602, the program development device 101 determines whether a component containing an action event has been placed. If it determines that a component containing an action event has been placed, it proceeds to step S603; otherwise, it proceeds to step S604.

[0092] When the process transitions to step S603, the program development device 101 registers the actions set for the component that includes the action event. Specifically, it registers the action if the component has an action called onClick in its source code. In Figure 21, which is an example of screen definition 402, definition 2102 of “actions” corresponding to the production environment and definition 2103 of “examples” corresponding to the prototype application are written out. In the example in Figure 21, the data storage format is a JSON file as an example of the implementation method, but the data storage format may be a file in another format or a database. After that, the process transitions 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 button 1101 in Figure 11, which is an example of a property input request button for a selected component, has been pressed.

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

[0095] When the process transitions to step S605, the program development device 101 accepts input from the developer regarding properties for a screen component. Specifically, it displays 1102 in Figure 11, which is an example of a screen property editor, and accepts input for setting the properties of the screen component. In the example in Figure 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. Alternatively, the screen property editor may be displayed as a modal dialog.

[0096] This concludes the explanation of Figure 6.

[0097] Next, the details of the process in step S503 will be explained with reference to Figure 7.

[0098] Figure 7 shows an example of a flowchart for receiving input for 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.

[0099] The flowchart in Figure 7 shows the sequence of processes that begin when the process transitions to step S503 in the flowchart in Figure 5.

[0100] First, in step S701, the program development device 101 reads the settings for the action items specified by the developer in step S502 of Figure 5. Specifically, it performs the following two actions. First, it reads 2101 in Figure 21, which is an example of 1004 in Figure 10, which is an example of the screen component definition 403 of the screen component selected by the developer. 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, it reads the definition 2102 of “actions” corresponding to the production environment of the screen component selected by the developer, and the definition 2103 of “examples” 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 a screen transition definition 404 of 2101, which is an example of a 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.

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

[0103] When the program transitions to step S703, the program development device 101 displays the destination screen for 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 like 1302 may be displayed by either overwriting the currently displayed screen definition editor unit 421 or by launching a new screen definition editor unit 421.

[0104] The initial display action of 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 process, the process transitions 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 like 2201 in Figure 22 is already 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) in advance when running a prototype application. Specifically, this is an example of displaying prototype data in a list table like 1302 in Figure 13, which is displayed in the screen definition editor unit 421. In the prototype data display component 1402 in Figure 14, for example, by right-clicking with a mouse (not shown) in the "Name" column and pressing the edit button 1403, the selection of the prototype data display component can be accepted. Also, as shown in 1701 in Figure 17, if the entire list is selected and the table input button 1702 is pressed, the entire list 1701 can be selected as the prototype data display component.

[0107] In the next step, S706, the program development device 101 accepts prototype data input from the developer. Specifically, it displays the prototype data input dialog 1501 shown in Figure 15, which is an example of the prototype data input unit 425. 1501 is the prototype data input dialog displayed when the edit button is pressed in the "Name" field in 1401 in Figure 14. In the case of 1501, the developer has entered the prototype data "Noriyuki Tanikawa" in the "Name" field. After the developer enters the value, pressing the "OK" button in 1501 determines whether or not to confirm the input in step S707.

[0108] Furthermore, as another example of step S706, an example of the prototype data input unit 425 will be described with reference to Figure 18.

[0109] The prototype data input dialog 1801 in Figure 18 is a screen image that appears when the table input button 1702 in Figure 17 is pressed. The text input field in 1801 accepts input of the data set to be displayed in the list shown in 1701. In the case of 1801, the first row contains "(blank)", "Noriyuki Tanikawa", "(blank)", the second row contains "1001", "Ai Hori", "2019 / 10 / 10", and the third row contains "1002", "Ruriko Yamamura", "2019 / 09 / 18". This data input can also be applied by selecting a CSV file or spreadsheet file from a file selection screen (not shown) that appears when the file selection button 1802 is pressed, and then applying the contents of that file.

[0110] After the developer enters a value into the text input field, or after the data is reflected following file selection, pressing the "OK" button (1803) determines whether or not the input in step S707 is confirmed.

[0111] In step S706, the system may accept a locale specification in order to switch the prototype data displayed depending on the language. Furthermore, while the system shows a modal dialog as a method for accepting prototype data input, this input method may also involve directly accepting input for the display components selected by the developer in S705, or it may involve batch input via an external file.

[0112] In the next step, S707, the program development device 101 determines whether the developer has confirmed the input of prototype data. Specifically, it determines whether the "OK" button in the prototype data input dialog 1501 in Figure 15 or the "OK" button 1803 in Figure 18 has been pressed. If direct input to a component is received in the input acceptance method in step S706, the determination is made by 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 is 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.

[0114] 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 action 405 in the screen definition 402.

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

[0116] In this way, by displaying screen images showing prototype data and transitioning between screens for each action event within the prototype application, it is possible to grasp how the application will function as a mockup before actually creating a working application (for example, searching from a database or creating diagrams from retrieved data). This concludes the explanation of Figure 7.

[0117] Next, the details of the process in step S507 will be explained with reference to Figure 8.

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

[0119] The flowchart in Figure 8 shows the sequence of processes that begin when the process transitions to step S507 in the flowchart in Figure 5.

[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 as appropriate by each generation unit.

[0121] 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.

[0122] In step S802, when reading the screen definition, information on the display permissions defined for each screen display item is also obtained. This will be explained with reference to the example in Figure 35. In Figure 35, if the row that changes the display item depending on the user's permission is defined as the second row (3501), then information linking the user's permission name 821 and the corresponding input / output display permission item 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 input / output display permission item is defined as the "Attendance Confirmation" item in Figure 35. Note that this display item definition information may define input / output display permissions, or it may define input / output display prohibition items, and the display items may have their display permissions defined collectively, or they may be defined individually as in 820.

[0123] 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.

[0124] 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.

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

[0126] 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 read here in the screen definition 402 is the "examples" data in Figures 21 and 22, which corresponds to the prototype data, and the "actions" data, i.e., the data for the production environment, is not used. Having these two sets of data makes it possible to create screen definitions for both prototype data and the production environment in a common way, and application screens created for mockups can be defined directly as application screens.

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

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

[0129] Referring to Figure 31, the prototype operation panel will be explained. The prototype operation panel is a panel screen that receives instructions from the developer regarding display settings and transition settings when displaying a prototype screen or transitioning between prototype screens. The prototype operation panel can be configured to reproduce the display device (personal computer, tablet, smartphone, etc.), the orientation of the display device's screen, the reproduction of screen displays based on user access rights (admin privileges (administrator privileges) and user privileges (general user privileges), the display of server processing time, and the display when an error occurs. Display device settings can be configured in 3102-3111, user privilege settings in 3102-3121, processing waiting time settings in 3102-3131, and error display settings in 3102-3141.

[0130] The relationship between the prototype application screen and the prototype operation panel 3102 when the prototype operation panel 3102 is open will be explained with reference to Figures 25 and 31.

[0131] Figure 25 illustrates the relationship between the prototype application screen and the prototype operation panel.

[0132] The base prototype display screen 2501 is the parent screen, which is displayed in the browser. The prototype application screen 2502 is displayed within the parent screen using an iframe. Furthermore, the prototype operation panel 2503 is displayed on top of the prototype application screen 2502, and both a portion of the prototype application 2502 and the prototype operation panel 2503 are displayed on the parent screen 2501 so that they can be viewed simultaneously.

[0133] The prototype operation panel 3102, as shown in Figure 31, accepts settings from the developer. When the developer performs an operation such as shrinking the prototype operation panel 3102 (2503), as shown in 3103, the prototype application screen 3201 (2522), as shown in Figure 32, is displayed (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, transitioning to the screen image 3101 in Figure 31, where the prototype operation panel 3102 is displayed. Return to the explanation of the flowchart in Figure 8.

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

[0135] Next, in step S808, the program development device 101 generates source code to change the screen display according to the user's privileges. 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 privileges are changed, such as the prototype operation panel 3521 in Figure 35 or the prototype operation panel 3721 in Figure 37. In the source code of Figure 45, when user privileges are changed, the first half of the source code determines the user privileges, and the second half of the source code controls the display and hiding of screen components to which the user privileges are applied. In other words, step S808 is the process of generating a program to display the prototype screen when user privileges are set.

[0136] In step S809, the program development device 101 generates source code to reproduce 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, for example, when a value for processing time (processing waiting time) is entered in the option setting fields 3131 or 3141 of the prototype operation panel 3102, as shown in 3931 of Figure 39, or when the error setting is changed to ON, as shown in 4241 of Figure 42. It displays a prototype screen that reflects the processing settings of the simulated server obtained from the browser's memory. In other words, step S809 is the process of generating a program to reproduce the simulated communication and server status when communicating with the server.

[0137] In step S810, the program development device 101, after rendering the prototype operation panel screen 2503, generates a program to reflect the settings of the subordinate prototype application (iFrame) screen 2502 to 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 screen, for example, by setting the device setting field 3111 of the prototype operation panel 3102 to the button 3112 which is set to the image of a PC (personal computer setting), or to the smartphone setting as shown in the image of 3311 in Figure 33.

[0138] After generating the source code described above, the processing of the flowchart in Figure 8 is completed. Note that the source code for executing the prototype operation panel screen 3102 and the processing after the operation of the prototype operation panel screen (Figures 44 to 47) uses TypeScript as an example, but source code in other languages ​​is also acceptable, including source code written in JavaScript.

[0139] This concludes the explanation of Figure 8.

[0140] Next, the process flow when executing the prototype application deployed in step S509 of Figure 5 and initiating communication with the web browser (450) of the application client 104 will be explained with reference to Figure 9. Note that, as shown in Figure 5, the web browser launched in step S511 of the program development device 101 may begin communicating with the deployed prototype display screen application, or, as shown in Figure 9, the web browser launched in the application client 104 may begin communicating with the deployed application server 102.

[0141] Figure 9 is a flowchart illustrating 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.

[0142] The flowchart in Figure 9 shows the process that begins when the prototype display screen (parent screen) 440 is deployed to the application server 102 (430) and a developer accesses it from the application client 104's web browser 450.

[0143] 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.

[0144] In step S902, the application client 104 downloads an SPA (Single Page Application) from the application server 102 (430) on which the prototype display screen (the application generated in steps S807 to S810 in Figure 8) will run. 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. It may also be a specification that communicates with the application server 102 by screen transition commands, in which case the initial screen information of the prototype application is downloaded.

[0145] Furthermore, in step S902, the application client 104 obtains user permission information from the prototype application.

[0146] Furthermore, in step S902, the application client 104 launches the prototype display screen 2501 (the parent screen of the prototype application) from the program obtained from the application server 102 (430). In other words, step S902 is a step in which the application client downloads and launches a program for displaying a prototype application with a screen image like 3101 in Figure 31.

[0147] 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 screen image being launched is 3201 in Figure 32, but because the prototype operation panel 3102, which will be displayed in the next step, S904 and beyond, is displayed on top (similar to the relationship between 2502 and 2503 in Figure 25), the initial display screen will look like 3101 in Figure 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 the image 3102 in Figure 31. By changing the settings displayed on this prototype operation panel, the display settings and screen transition settings of the prototype application can be controlled.

[0149] In the next step S905, the application client 104 displays a change to the display screen or transition screen of the prototype application 3201 (442) based on the settings entered into the prototype operation panel 3102. The process of displaying the screen or transition screen of the prototype application 440 based on each setting will be described later in Figures 26 to 29.

[0150] Next, in step S906, the application client 104 waits for instructions from the developer to either finish reproducing the application using the prototype application. If it decides to finish reproducing the application, it exits this flowchart. If it receives instructions to reproduce it again, it returns to step S902.

[0151] Next, in step S905, the process of changing the display screen or transition screen of the prototype application 3201 (442) based on the respective settings entered into the prototype operation panel 3102 will be explained with reference to Figures 26 to 29. The respective settings are switching the display device, changing user permissions, reproducing the processing time with the server, and reproducing the occurrence of an error.

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

[0153] The flowchart in Figure 26 shows the process that begins when a developer accesses the application client 104 from its web browser 450, and the SPA on 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.

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

[0155] Furthermore, in step S2601, the application client 104 starts the prototype display screen 2501 from the program obtained 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 like 3101 in Figure 31 is downloaded and started.

[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 screen image being launched is 3201 in Figure 32, but because the prototype operation panel 3102, which will be displayed in the next step, S2603 and beyond, is displayed on top (similar to the relationship between 2502 and 2503 in Figure 25), the initial display screen will look like 3101 in Figure 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 the image 3102 in Figure 31. By changing the settings displayed on this prototype operation panel, the display settings and screen transition settings of the prototype application can be controlled.

[0158] When the prototype operation panel 3102 is displayed, if the device input field 3111 is changed by the developer, the process proceeds to the next step, S2604. The screen image when the device input field 3111 is changed by the developer is explained with reference to Figure 33. Note that the device input field 3111 has pre-set screen sizes for each terminal (personal computer, tablet, smartphone), and for tablets and smartphones, it is an input field that can change the display format between portrait and landscape. The reason for displaying both portrait and landscape formats is that tablets and smartphones can be controlled to display in either portrait or landscape orientation.

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

[0160] Unlike the prototype operation panel 3102 in Figure 31, the device selection field 3311 on the prototype operation panel 3302 in Figure 33 shows an example where the smartphone screen button 3312 is pressed.

[0161] Returning to the flowchart in Figure 26, when the process transitions to the next step S2604, the application client 104 receives an instruction on the prototype operation panel 3302 to change the screen size of the modified device. Figure 47 shows an example of source code that executes steps S2603 and S2604 after displaying 3101 in Figure 31.

[0162] In the next step, S2605, the application client 104 displays the prototype application 2502, adjusting the iFrame portion to the size of the device received in step S2604. An image of the prototype application screen when a setting like that of the prototype operation panel 3302 in Figure 33 is received will be explained with reference to Figure 34.

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

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

[0165] The transition from the prototype display screen 3301 (2501 in Figure 25) where the prototype operation panel 3302 shown in Figure 33 is displayed in the foreground, to the screen where the prototype application screen 3401 shown in Figure 34 is displayed in the foreground (2521 in Figure 25), can be performed, for example, by pressing the down arrow button 3103 in Figure 31, or by using other buttons. Also, the transition from the screen where the prototype application screen 3401 shown in Figure 34 is displayed in the foreground (2521 in Figure 25) to the prototype display screen 3301 (2501 in Figure 25) where the prototype operation panel 3302 shown in Figure 33 is displayed in the foreground (i.e., returning to the screen of the prototype operation panel 3302), can be performed, for example, by pressing the semi-transparent button 3202 in the lower right of Figure 32.

[0166] Through the above process, it is possible to easily create prototype applications with different display formats for each device.

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

[0168] Figure 27 is a flowchart showing the processing flow when user privileges are switched. Note that each step in the flowchart below is executed by the CPU 201 of application client 104.

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

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

[0171] Furthermore, in step S2701, the application client 104 obtains user permission information for the prototype application. An example of the data obtained is data like 2710. This data is the same as the data 830 obtained in step S805 when the prototype display screen application is generated.

[0172] Furthermore, in step S2701, the application client 104 starts the prototype display screen 2501 from the program obtained 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 like 3101 in Figure 31 is downloaded and started.

[0173] 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 screen image that is launched is initially 3201 in Figure 32, but because the prototype operation panel 3102, which will be displayed in the next step, S2703 and beyond, is displayed on top (similar to the relationship between 2502 and 2503 in Figure 25), the initial display screen will look like 3101 in Figure 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 the image 3102 in Figure 31. By changing the settings displayed on this prototype operation panel, the display settings and screen transition settings of the prototype application can be controlled. As shown in the user permission setting section 3121 in Figure 31, the user permission setting checkboxes are generated from the user permission data 830 obtained in step S805.

[0175] If the user permission settings field 3121 is changed by the developer while the prototype operation panel 3102 is displayed, the process proceeds to the next step, S2704. Figure 35 illustrates the screen image when the user permission settings field 3121 is changed by the developer.

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

[0177] Unlike the prototype operation panel 3102 in Figure 31, the user permission setting field 3521 of the prototype operation panel 3502 in Figure 35 has "user" checked instead of "guest" in the user permission setting field 3521.

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

[0179] In the next step, S2705, the application client 104 displays the prototype application 2502 with the user permission settings stored in step S2704. The image of the prototype application screen when the user permission setting field 3521 of the prototype operation panel 3502 in Figure 35 is received will be explained with reference to Figure 36.

[0180] Figure 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 displays a newly added "Attendance Confirmation (User)" field in the underlined section 3602. This is an image diagram that reflects the input / output permission item data 820 for each user permission obtained in step S802 when the prototype display screen was generated. In other words, since the user permission setting field 3521 has been changed to "user", the permission name (Name) corresponding to "user" in 830 is "User", and the input / output permission items for the "User" permission are "Attendance Confirmation (User)" and "Remarks". Therefore, the prototype application screen 3601 in Figure 36 displays the "Attendance Confirmation (User)" field and the "Remarks" field, as shown in the underlined section 3602.

[0182] Another example is also explained.

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

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

[0185] Figure 38 is a schematic diagram illustrating an example of a prototype display screen in this embodiment, and is a screen image displayed after the user permission settings of the prototype operation panel 3702 in Figure 37.

[0186] Unlike the prototype application screen 3201 in Figure 32, the prototype application screen 3801 in Figure 38 has newly added Attendance Confirmation (Admin) and Attendance Confirmation (User) 3803 in the underlined section 3802, and an update button 3804 is also displayed on the right side of the screen.

[0187] The above process has the effect of creating 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 generated, it will only be able to display predetermined screens or perform predetermined screen transitions, regardless of user privileges. However, the present invention has a setting for a prototype operation panel that switches user privileges, and by switching user privileges, it is possible to reproduce the fact that the displayed screen image switches according to the user privileges. Furthermore, by having a prototype operation panel, it is possible to change user privileges and check other screen images even while the prototype application is running.

[0188] Next, referring to Figure 28, we will explain the process flow for displaying the reproduction of the processing time on the server.

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

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

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

[0192] Furthermore, in step S2801, the application client 104 launches the prototype display screen 2501 from the program obtained from the application server 102 (430). In other words, step S2801 is a step in which the application client downloads and launches a program for displaying a prototype application with a screen image like 3901 in Figure 39. An example of a screen that displays the reproduction of the server's processing time will be explained with reference to Figures 39 to 41 and Figure 32.

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

[0194] Figure 39 shows an image of the screen 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 this prototype display screen is launched.

[0195] 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.

[0196] Figure 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. However, the prototype operation panel 3902, which will be displayed in the next step S2803 and beyond, is displayed on top of it (similar to the relationship between 2502 and 2503 in Figure 25). Therefore, at the start of the application, the display screen will look 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 the image 3902 in Figure 39. By changing the settings displayed on this prototype operation panel, the display settings and screen transition settings of the prototype application can be controlled. The prototype operation panel 3902 in Figure 39 has a setting field, such as the processing time setting field 3931, which reproduces the display of screen transitions of the prototype application 2502, taking into account the processing time on the server.

[0199] If the prototype operation panel 3902 is displayed and the processing time setting field 3931 is changed by the developer, the process will proceed to the next step, S2804.

[0200] The processing time setting field 3931 is initially set to "0.2 seconds" as shown in processing time setting field 3131 in Figure 31, but in processing time setting field 3931 it has been changed to "2 seconds".

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

[0202] In the next step, S2805, the application client 104 modifies the prototype application 2502 to a state where it waits for the processing time stored in step S2804, and then proceeds to the next screen. Figure 46 shows a portion of the source code executed in step S2805. The behavior of the modified prototype application will be explained with reference to Figure 41.

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

[0204] For example, as shown in the prototype display screen 3901 in Figure 39, if the processing time setting field 3931 is set to "2 seconds" in the prototype operation panel 3902, then pressing the button to transition to the prototype application screen 3903 will display a screen like 4001 in Figure 40. Next, when the user presses the search button 4002 to reproduce the operation, a display screen 4102 will be displayed in the center, as shown in the screen image in Figure 41, giving the impression that the server is processing the request. The time displayed indicating that processing is in progress is the time set in the processing time setting field 3931. After displaying the display screen 4102 for the set time, the next screen transition, such as Figure 32, is displayed.

[0205] The above process has the effect of creating a prototype application that reproduces the waiting time during screen transitions. In other words, it can reproduce the processing time that occurs on the server side when generating a production environment application (product application). For example, when business users or sales representatives demonstrate a prototype application to general users, they can reproduce the processing time with the server that would actually take time, and reproduce what screens are displayed during that processing time with the server. Since this prototype display screen application is composed of an SPA, actual communication with the server is not required. Therefore, if you simply run the prototype application (screen transitions), there is no processing time, and the prototype application will transition screen after screen. Because the operation of the production environment application (product application) does not take into account the processing time on the server, general users who are convinced by a demonstration that does not take into account the processing time on the server may feel a discrepancy regarding the performance of the developed deliverable. With the demonstration of the present invention, the server processing time can be freely set, so the risk of discrepancies regarding the performance of the developed deliverable is reduced.

[0206] Next, referring to Figure 29, we will explain the process flow for displaying the reproduction of errors that occur on the server or communication errors.

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

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

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

[0210] Furthermore, in step S2901, the application client 104 launches the prototype display screen 2501 from the program obtained from the application server 102 (430). In other words, step S2901 is a step in which a program for displaying a prototype application with a screen image like 4201 in Figure 42 is downloaded and launched. Examples of screens that display the reproduction of errors that occur on the server will be explained with reference to Figures 40, 42, and 43.

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

[0212] Figure 42 shows an image of the screen 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 this prototype display screen is launched.

[0213] 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. An example of the launched prototype application screen is shown in Figure 40.

[0214] In step S2902, the prototype application screen 4001 is launched on top of the parent screen launched in step S2901. However, the prototype operation panel 4202, which will be displayed in the next step S2903 and beyond, is displayed on top of it (similar to the relationship between 2502 and 2503 in Figure 25). Therefore, at the start of the application, the display screen will look 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 the image 4202 in Figure 42. By changing the settings displayed on this prototype operation panel, the display settings and screen transition settings of the prototype application can be controlled. The prototype operation panel 3902 in Figure 42 has an error generation toggle button 4241 that generates a virtual error during communication with the server, and has a setting field that reproduces the display of screen transitions of the prototype application 2502, taking into account the case when an error occurs on the server.

[0216] If the prototype control panel 4202 is displayed and the error toggle button 4241 is turned "on" by the developer, the process proceeds to the next step, S2904.

[0217] The error detection toggle button 4241 is initially "off" at startup, as shown by the error detection toggle button 3141 in Figure 31, but in the case of the error detection toggle button 4241, it has been changed to "on".

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

[0219] The next step, S2905 onwards, is the processing that occurs after the user presses the transition button 4203 to the prototype application shown in Figure 42. The screen image after the transition button 4203 is pressed is shown in Figure 40, 4001.

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

[0221] Next, the system receives a screen transition instruction from the user, for example, from Figure 40. In the case of Figure 40, the search button 4002, which is a screen transition instruction, is pressed. Upon receiving the screen transition instruction, the system proceeds to the next step, S2806.

[0222] In the next step, S2906, the application client 104 divides its processing depending on whether the acquired error setting status is on (enabled) or off (disabled). If the error setting status is on, the process transitions to step S2907; if the error setting status is off, the process transitions to step S2908. Upon transitioning to step S2908, since the error setting status was off, the application client 104 transitions to Figure 32, which is the normal transition screen of the prototype application.

[0223] On the other hand, when the process transitions to step S2907, the application client 104 proceeds with processing assuming that an error has occurred in the prototype application. Specifically, it may display a screen similar to the one shown in Figure 43.

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

[0225] Figure 43 specifically shows an error message, such as 4302, displayed when an error occurs during processing using the search button 4002.

[0226] Through the above process, it is possible to create a prototype application that can reproduce the error screen that appears when a screen transition fails. In other words, it is possible to reproduce errors that occur on the server side or during communication when generating the production environment application (product application). Since this prototype display screen application is composed of a Single Page Application (SPA), actual communication with the server is not required. Therefore, if you simply run the prototype application (screen transition), no server errors or communication errors will occur. The need of developers and general users to reproduce the display screen when an error occurs can be met with an SPA. Furthermore, as a way to reproduce the error display more realistically, it may be combined with the reproduction of a virtual processing time on the server as shown in Figure 28.

[0227] As the prototype display screen described above is composed of a Single Page Application (SPA) that can be launched within the browser of various devices, by downloading the generated prototype display screen application, as shown in Figure 30, 2501, to a personal computer (PC) or tablet, the 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). Since it is possible to run the prototype application that reproduces the processing time on the server on a tablet, and to reproduce the smartphone-sized display (3003) on the tablet display (3002), when demonstrating to customers, one device can be brought along to reproduce the screens displayed on any device and the screen transition patterns.

[0228] 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 embodiments described above to a system or device, and by 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 read from the recording medium itself realizes the novel function of the present invention, and the recording medium on which that program is recorded constitutes the present invention.

[0230] For recording media used to supply programs, examples include 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, and the like.

[0231] Furthermore, it goes without saying that the functions of the aforementioned embodiments are realized not only by the computer executing the program it has read, but also by the operating system (OS) running on the computer performing some or all of the actual processing based on the instructions of that program, thereby realizing the functions of the aforementioned embodiments.

[0232] Furthermore, it goes without saying that this also includes cases where, after a program read from a recording medium is written to the memory of a function expansion board inserted into a computer or a function expansion unit connected to a computer, the CPU or other components of the function expansion board or function expansion unit perform some or all of the actual processing based on the instructions of the program code, and the functions of the aforementioned embodiments are realized through that processing.

[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 when the results are achieved by supplying a program to a system or device. In this case, by reading a recording medium containing a program for achieving the present invention into the system or device, the system or device can enjoy the effects of the present invention.

[0234] The above program may consist of object code, program code executed by an interpreter, script data supplied to the OS (operating system), and the like.

[0235] Furthermore, by downloading and reading the 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. It should be noted that configurations combining the above-described embodiments and their variations are all included in the present invention. [Explanation of Symbols]

[0236] 101 Program Development Equipment 102 Application Server 103 Database Server 104 Application Clients 105 Network

Claims

1. A generation means for generating an application that generates an application that displays a screen display item associated with a user role that has been selected, based on display permission information that associates a user role with a screen display item in an application and defines whether or not the screen display item can be displayed, Without deploying the aforementioned application, a display control means displays multiple options corresponding to the user role in the setting reception unit for switching the user role, and displays screen display items associated with the user role selected by the setting reception unit. An information processing system characterized by comprising the following features.

2. The user role whose selection has been accepted is the user role selected by the operator. The information processing system according to claim 1, characterized by the following:

3. The setting reception unit is displayed together with the screen display items displayed by the display control means. An information processing system according to claim 1 or 2, characterized by the above.

4. The setting reception unit is displayed superimposed on the screen display items displayed by the display control means. An information processing system according to any one of claims 1 to 3, characterized by the above.

5. The display control means, in switching the user role of the setting reception unit, displays the screen display items associated with the selected user role without going through the application's user authentication process. An information processing system according to any one of claims 1 to 4, characterized by the above.

6. Acquisition means for acquiring definition information for generating the application, The generation means generates the application using the definition information, The definition information includes the display availability information. An information processing system according to any one of claims 1 to 5, characterized by the following:

7. The definition information includes screen definition information to be displayed on the screen of the application, The aforementioned screen definition information includes the display availability information. The information processing system according to claim 6, characterized by the following:

8. The screen displayed by the display control means is the screen of the prototype application. An information processing system according to any one of claims 1 to 7, characterized by the above.

9. The application is an application that operates in a production environment. An information processing system according to any one of claims 1 to 8, characterized by the above.

10. The display control means is Without deploying the aforementioned application to the production environment, the setting reception unit for switching user roles displays multiple options corresponding to the user role, and the setting reception unit displays screen display items associated with the user role selected. An information processing system according to any one of claims 1 to 9, characterized by the above.

11. A method for controlling an information processing system, The generation means of the information processing system includes a generation step of generating an application that displays the screen display items associated with the selected user role, based on display permission information that associates user roles in an application with screen display items and defines whether or not the screen display items can be displayed, The display control means of the information processing system includes a display control step of displaying a plurality of options corresponding to the user role in a setting reception unit for switching user roles without deploying the application, and displaying screen display items associated with the user role selected by the setting reception unit, A control method for an information processing system, characterized by comprising the following:

12. At least one computer is used for information processing according to any one of claims 1 to 10. Programs to make each component of the system function as a means to an end.

Images