Information processing device, method and program for controlling information processing system
By incorporating a reception unit for error settings and a generating unit for error display in application prototypes, the system addresses the limitation of not reproducing error screens, thereby enhancing the development process and user satisfaction.
Patent Information
- Application Number
- JP2021007671
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2021-01-21
- Publication Date
- 2025-04-09
- Estimated Expiration
- 2041-01-21
AI Technical Summary
Existing technologies for generating application prototypes do not support the reproduction of error screens when communication errors occur, limiting their ability to simulate real-world application scenarios.
The system includes a reception unit for accepting settings to display error information in response to specific events and a generating unit that creates a prototype application with a display unit showing error information after a predetermined time from the event occurrence.
This solution enables the creation of prototype applications that can effectively simulate error scenarios, enhancing the development process by allowing for the reproduction of error screens and improving user satisfaction.
Smart Images

Figure 0007659164000001 
Figure 0007659164000002 
Figure 0007659164000003
Abstract
Description
[Technical field]
[0001] The present invention relates to an information processing device, an information processing method, and a program for generating an application. [Background technology]
[0002] When creating an application for a customer, if you first understand the customer's needs and then create the application, you can reduce rework and increase development efficiency.
[0003] In particular, screens and operating procedures differ from internal logic and operate according to user desires, which leads to increased customer satisfaction.
[0004] Patent Document 1 solves the above problem by listening to the user's requests, determining requirements that meet those requests, and at the same time generating and completing source code for an application program that can be used on an actual device on the spot. [Prior art documents] [Patent documents]
[0005] [Patent Document 1] JP 2015-210639 A Summary of the Invention [Problem to be solved by the invention]
[0006] Patent Document 1 describes the generation of a mockup file for an application and the generation of source code for a mockup application that realizes mockup screen transitions, but the mockup application can perform configured screen transitions but does not support other screen transitions. For example, there is a problem in that it cannot reproduce an error screen when a communication error occurs during communication with a server.
[0007] The object of the present invention is to Prescribed processingError if fails to information of display The goal is to create a prototype application that can be used to [Means for solving the problem]
[0008] In order to solve the above problems, the present invention provides a method for implementing an application prototype, comprising: a generating unit that generates a prototype having a first display unit that displays error information in response to the occurrence of the predetermined event based on the setting for displaying error information in the reception unit; 、 the receiving unit receives an input related to a time from the occurrence of the predetermined event to display the error information; The first display unit displays the error information when the time has elapsed since the occurrence of the predetermined event. It is characterized by the above. Effect of the Invention
[0009] According to the present invention, Prescribed processing Error if fails to information of display You can create prototype applications that can Kanade do. [Brief description of the drawings]
[0010] [Figure 1] 1 is a system configuration diagram showing an example of the configuration of a program development device, an application server, a database server, and an application client according to the present invention. [Diagram 2] 1 is a block diagram showing an example of a hardware configuration applicable to a program development device, an application server, a database server, and an application client according to the present invention; [Diagram 3] FIG. 2 is a block diagram showing an example of a software configuration according to an embodiment of the present invention. [Figure 4]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. [Diagram 5] FIG. 1 illustrates an example of a flowchart for generating a prototype application according to an embodiment of the present invention. [Figure 6] FIG. 11 is a diagram illustrating an example of a flowchart of a screen definition input receiving process according to the embodiment of the present invention. [Figure 7] FIG. 11 is a diagram illustrating an example of a flowchart of a prototype data input reception process according to an embodiment of the present invention. [Figure 8] FIG. 13 is a diagram illustrating an example of a flowchart of a prototype application source code generation process according to an embodiment of the present invention. [Figure 9] FIG. 11 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 [Figure 10] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 11] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 12] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 13] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 14] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 15] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 16] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 17] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 18] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 19] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 20] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Figure 21] FIG. 4 is a diagram showing an example of a screen definition 402 according to the embodiment of the present invention. [Figure 22] FIG. 4 is a diagram showing an example of a screen definition 402 according to the embodiment of the present invention. [Diagram 23] FIG. 4 is a diagram showing an example of control of the screen size of a prototype application 442 according to the present invention. [Figure 24] FIG. 4 is a diagram showing an example of a screen display of a prototype application 442 according to the present invention. [Diagram 25] 1A and 1B are diagrams illustrating the relationship between a prototype application screen and a prototype operation panel according to an embodiment of the present invention. [Figure 26] FIG. 11 is a diagram showing an example of a flowchart when a prototype screen display application is executed according to an embodiment of the present invention. [Figure 27] FIG. 11 is a diagram showing an example of a flowchart when a prototype screen display application is executed according to an embodiment of the present invention. [Figure 28] FIG. 11 is a diagram showing an example of a flowchart when a prototype screen display application is executed according to an embodiment of the present invention. [Figure 29] FIG. 11 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. [Diagram 30] FIG. 2 is a diagram showing an example of a device that can be displayed on a browser according to an embodiment of the present invention. [Diagram 31] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Diagram 32] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention. [Diagram 33]FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 34] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 35] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 36] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 37] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 38] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Figure 39] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 40] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 41] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 42] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 43] FIG. 2 is a diagram showing an example of a screen image displayed on an output unit 210 according to the embodiment of the present invention [Diagram 44] FIG. 13 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. [Diagram 45] FIG. 13 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. [Diagram 46] FIG. 13 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. [Figure 47] FIG. 13 is a diagram illustrating an example of a portion of a prototype application source code according to the present embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. First Embodiment FIG. 1 is a system (information processing system) configuration diagram showing an example of the configuration of a program development device (an information processing device operated by a developer to generate a Web application), an application server, a database server, and an application client according to the present invention.
[0012] The program development device 101 defines a screen layout, a database search instruction, etc. according to operations by a developer. The program development device 101 generates programs and applications.
[0013] In this embodiment, the application generated by the program development device 101 is a Web application, but this is not limited to this, and the application may not be an application that uses communication via Web technology, such as an application that runs on an information processing device such as a mobile phone, smartphone, or tablet, or embedded software.
[0014] The application server 102 executes an application developed by the program development device 101. Also, the application server 102 can be connected to a database server 103 for operation.
[0015] The database server 103 is a database used by the developed application, and may be used during development for checking operation, etc. For example, the database server 103 for use by a developer may be configured as the same device as the program development device 101 or the application server 102, or may be located within a network 105 such as a LAN.
[0016] The application client 104 (information processing device) is an input terminal of an end user that operates an application program developed by the program development device 101 in cooperation with the application server 102. This application client 104 may be an information processing device such as a mobile terminal.
[0017] Any of the program development device 101, application server 102, database server 103, and application client 104 may be located on the Internet, such as in the cloud, or several information processing devices may be integrated into one housing.
[0018] FIG. 2 is a block diagram showing an example of each hardware configuration applicable to the program development device 101, application server 102, database server 103, and application client 104 according to the present invention.
[0019] In FIG. 2, a CPU 201 comprehensively controls each device connected to a system bus 204 .
[0020] The ROM 203 or the external memory 211 also stores an operating system (OS) which is a control program for the CPU 201, and programs for implementing various functions of the information processing device, such as each server, client, and device, which will be described later.
[0021] The RAM 202 functions as a main memory, a work area, a temporary save area, and the like for the CPU 201.
[0022] The input controller 205 controls input from an input unit 209. In an information processing device, the input unit 209 may include a keyboard, a pointing device such as a mouse, and a touch panel.
[0023] When the input unit 209 is a touch panel, the user can give various instructions by pressing (touching with a finger or the like) an icon, cursor, or button displayed on the touch panel.
[0024] The touch panel may be a touch panel capable of detecting positions touched by multiple fingers, such as a multi-touch screen.
[0025] The output controller 206 controls the display of the output unit 210. Examples of the output unit 210 include a CRT or a liquid crystal display. The output unit 210 also includes a display of a notebook computer integrated with the main body. It may also be a projector.
[0026] The external memory controller 207 controls access to an external memory 211 that stores a boot program, various applications, font data, user files, edit files, printer drivers, etc. The external memory 211 stores various tables and parameters for implementing various functions of each server, client, device, etc. Examples of the external memory 211 include a hard disk (HD), a flexible disk (FD), a compact flash (registered trademark) connected to a PCMCIA card slot via an adapter, a smart media, etc.
[0027] The CPU 201 enables display on the output unit 210 by, for example, executing an outline font development (rasterization) process on a display information area in the RAM 202. The CPU 201 also enables the developer to give instructions using a mouse cursor (not shown) or the like on the output unit 210.
[0028] A communication I / F controller 208 executes a process for controlling communication with external devices via a network. For example, communication using TCP / IP is possible.
[0029] A 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 required.
[0030] FIG. 3 is a block diagram showing an example of a software configuration according to the embodiment of the present invention.
[0031] The program development device 101 has the following functional units.
[0032] The definition unit 301 is a functional unit that accepts from a developer screen definition information such as the screens and item (input / output items) arrangement displayed in the application, and screen transition definition information that defines the procedure for the 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) for reproducing the screens defined in the definition unit 301 and the procedures for transitioning between the screens; specifically, this corresponds to the processing of the flowchart in Figure 8.
[0034] The storage unit 303 is a functional unit that stores the screen size when the prototype application is displayed on the application client 104, and specifically corresponds to 2310 in FIG.
[0035] The data acquisition unit 304 is a functional unit that acquires data to be displayed in items (input / output items) on the prototype application from the user, and specifically corresponds to step S706 in FIG. 7 and the explanatory diagrams in FIGS.
[0036] The operation panel generation unit 305 is a functional unit that generates a prototype operation panel that controls the screen environment and transition method of the prototype application. Specifically, this is 810 in FIG. 8, and the generated prototype operation panel is 3102 in FIG.
[0037] FIG. 4 is a configuration diagram of the program development device 101, the application server 102, and the application client 104.
[0038] The program development device 101 includes a repository definition unit 400, a prototype application generation unit 410, and a repository definition editor unit 420. Note that the prototype application of the present invention is different from an application that searches for data from a database or creates diagrams from calculated data results as in a production environment, and is an application that serves as a mockup that displays preset values and diagrams created in advance and imitates screen transitions, display changes, and the like in an actual application.
[0039] The application server 102 corresponds to an application server unit 430 in FIG. 4, and the application client 104 includes an application client unit 435 .
[0040] Program development device 101 generates a prototype display screen (parent screen) 440 by prototype generation unit 410. In the present invention, a developer is not limited to a contracted developer of an application, but refers broadly to anyone who uses program development device 101, such as a business user or a sales representative.
[0041] The repository definition section 400 stores an application definition 401, a screen definition 402, a screen part definition 403, a screen transition definition 404, an action 405 linked to the screen part definition 402, and prototype data 406 linked to the action 405. The prototype data refers to data that is displayed on the application screen when the prototype application is executed, and does not refer to data searched from a database or drawings made from calculated data results as in the production environment, but refers to values and figures that are preset by a developer. These definitions 401 to 406 are input, set, or arranged by the developer via an application development tool.
[0042] The application definition 401 holds settings for the entire application that the developer is developing.
[0043] The screen definition 402 holds information on various screen part definitions 403 arranged on each screen included in the application and screen transition definitions 404. The screen definition 402 includes information on actions 405 set for various parts and prototype data 406 linked to the actions 405.
[0044] The prototype application generation unit 410 analyzes the repository definition unit 400 set by the developer, and generates a prototype display screen (parent screen) 440. After generating the prototype application, the prototype display screen (parent screen) 440 is deployed to the application server unit 430.
[0045] The repository definition analysis section 411 analyzes the repository definition section 400 set by the developer.
[0046] The prototype code generation unit 412 generates source code for the prototype application in accordance with the analysis results of the repository definition analysis unit 411 .
[0047] The source code compiling unit 413 compiles the source code generated by the prototype code generating unit 412, and deploys a prototype display screen (parent screen) 440 including compiled Java (registered trademark) code and HTML / JSP / JavaScript (registered trademark) to the application server unit 430.
[0048] The repository definition editor section 420 is an example of a procedure for a user to set the repository definition 400. The repository definition editor section 420 includes a screen definition editor section 421, a screen transition definition editor section 422, a parts palette section 423, an action selection section 424, and a prototype data input section 425.
[0049] The screen definition editor unit 421 is a graphical editor that enables a developer to intuitively create a desired screen layout.
[0050] The screen transition definition editor unit 422 is an editor for setting properties for each screen component placed by the developer.
[0051] The responsive component control unit 423 is a functional unit that allows a developer to control the display format of screen components (screen layout and component width) for each screen width of a client.
[0052] An example of the responsive component control unit 423 will be described with reference to FIGS.
[0053] FIG. 23 is a schematic diagram for explaining the control of the screen size of the prototype application 442 in the present invention.
[0054] For example, as shown in FIG. 23, an application generation screen 2300 displays buttons for switching between a plurality of 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, data 2310 (storage unit) stores the screen size displayed on the application client 104. For example, when the personal computer screen button 2301 is pressed, the displayed screen size is 1920×1080 (2311), when the tablet screen button 2302 is pressed, the displayed screen size is 1023×1366 (2312), and when the smartphone screen button 2303 is pressed, the displayed screen size is 414×896. Examples of the screens displayed when each button is pressed will be described with reference to FIG. 24.
[0056] FIG. 24 is a schematic diagram showing an example of a screen display of a prototype application 442 in the present invention.
[0057] For example, 2402 in FIG. 24 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 the respective parts, for example, part 2422 on the personal computer screen 2402 is 2423 on the tablet screen 2403, and 2424 on the smartphone screen 2404. The responsive part control unit 423 controls the same parts 2422, 2423, and 2424 to be displayed at a predetermined ratio of the width of the entire screen (2402, 2403, and 2404) as shown in FIG. 24. That is, the part 2402 is controlled to be displayed at a ratio of 2422 to 2 / 12 of 2402 (entire screen) on the personal computer screen, 2423 to 3 / 12 of 2403 (entire screen) on the tablet screen, and 2424 to 6 / 12 of 2404 (entire screen) on the smartphone screen. Return to the explanation of the configuration diagram in FIG. 4.
[0058] The action selection unit 424 is a functional unit that selects an action (action event) for selecting an action for which the developer sets the prototype data 406 .
[0059] The prototype data input section 425 is a graphical editor for intuitively setting prototype data 406 associated with a particular 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 generating unit 410 and transmits it to the application client 104 .
[0061] The prototype display screen (parent screen) 440 is an application generated by the prototype application generation unit 410. The prototype display screen (parent screen) 440 is an application for allowing a business user (a customer decision maker) or a sales representative who makes a proposal to a customer, etc., to control and display the display contents and operations of an application generated by the program development device 101 during application development. The prototype display screen (parent screen) 440 includes a prototype operation panel 441 and a prototype application 442.
[0062] The prototype operation panel 441 is a module of the prototype display screen (parent screen) 440 that has a user interface function, 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 the display image for each user authority, reproduction of the processing waiting time on the server, and reproduction of the display screen when an error occurs on the server.
[0063] The prototype application 442 is a mockup application that allows business users (customer decision makers) and sales representatives who make proposals to customers to reproduce the display content, operation, etc. of an application generated by the program development device 101 when developing the application.
[0064] The application client unit 435 downloads a prototype display screen (parent screen) 440 from the application server unit 430, and in a Web browser 450, launches the prototype display screen (parent screen) 440, which is configured as an SPA (single page application).
[0065] Although not shown, the system also has an application code generation unit that actually operates, not 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 by a repository definition analysis unit 411. The Web application code generation unit uses the code generation rules stored in the external memory 211 and the contents analyzed by the repository definition analysis unit 411 to generate a Web application module including compiled Java (registered trademark) code and HTML / JSP / JavaScript (registered trademark) via a source code compilation unit 413.
[0066] 5 is a diagram showing an example of a flowchart for generating a prototype application of a Web application. Note that each step of the following flowchart is executed by the CPU 201 of each device.
[0067] The flowchart in Fig. 5 shows the flow of processing started by program development device 101 when a developer attempts to generate a prototype application. The processing in steps S501 to S506 is information acquisition processing for generating prototype application 442. The processing in step S507 is processing for acquiring information for prototype operation panel 441 and generating source code for the prototype application including prototype display screen 440. The processing in each step will be specifically described below.
[0068] First, in step S501, the program development device 101 accepts a screen definition input. Details of the process in step S501 will be described later with reference to FIG.
[0069] Next, in step S502, the program development device 101 determines whether there has been a request to input the prototype data 443. Specifically, it determines whether 1201 and 1202 in Fig. 12, or 1203 and 1301 in Fig. 13, which are examples of the action selection unit 424, have been pressed.
[0070] The action control module 442 controls which data among multiple prototype data set by the developer is to be displayed at what timing when the prototype display screen (parent screen) 440 is executed. The action control module 442 also controls the operation associated with each action of the parts arranged on the screen. In other words, the prototype data is associated with an action (action event).
[0071] Program development device 101 accepts the press to allow the developer to specify which action the prototype data he or she is about to input is to be linked to.
[0072] If it is determined in step S502 that a prototype data input request has been made, the process proceeds to step S503.
[0073] On the other hand, if there is no request for input of prototype data in step S502, the process proceeds to step S504.
[0074] An example of the action selection section when 1201 is pressed is shown in 1202. Also, an example of the action selection section when 1203 is pressed is shown in 1301. In the example of 1301, a list of actions included in the currently displayed screen definition is displayed, but a list of actions included in the application definition may also be displayed.
[0075] When the process proceeds to step S503, the program development device 101 accepts an input of prototype data from the developer. Details of the process of step S503 will be described later with reference to Fig. 7. After that, the process proceeds to step S504.
[0076] In step S504, the program development device 101 determines whether or not a screen definition save request has been made. If it is determined that a screen definition save request has been made, the program development device 101 proceeds to step S505, and if a screen definition save request has not been made, the program development device 101 proceeds to step S506.
[0077] In step S505, the program development device 101 saves the screen definition in the repository definition unit 400. After that, the process proceeds to step S506.
[0078] In step S506, the program development device 101 determines whether a prototype generation request has been made. If it is determined that a prototype generation request has been made, the program development device 101 transitions to step S507. On the other hand, if a prototype generation request has not been made, the program development device 101 transitions to step S501.
[0079] When the process proceeds to step S507, the program development device 101 generates source code for the prototype application. Details of the process in step S507 will be described later with reference to FIG.
[0080] Next, in step S508, the program development device 101 compiles the source code generated in step S507.
[0081] In step S509, the program development device 101 deploys the prototype application compiled in step S508 to the application server 102 (430).
[0082] In the following, we will explain an example in which the program development device 101, application server 102, and application client 104 are implemented on the same information processing device. However, if each is a separate information processing device, each information processing device will launch each application (such as a prototype application or a web browser) and execute processing.
[0083] In step S510, the program development device 101 starts the prototype application deployed to the application server 102 (430).
[0084] In step S511, the program development device 101 starts a web browser and starts accessing the URL of the prototype application. Note that the processes in steps S510 and S511 are examples of the case where the program development device 101 uses both the application server 102 and the application client 104. In the case where they are separate devices, the process in step S510 is executed by the application server 102, and the process in step S511 is executed by the application client 104.
[0085] This concludes the explanation of Fig. 5. Subsequent processing will be described later with reference to Fig. 9. In the explanation of Fig. 9 and subsequent figures, the prototype application is assumed to be executed by application client 104 that has launched a Web browser, rather than by program development device 101. However, the prototype application may also be executed by program development device 101 that has launched a Web browser in the same manner as application client 104.
[0086] Next, the process of step S501 will be described in detail with reference to FIG.
[0087] 6 is a diagram showing an example of a flowchart for accepting input of a screen definition of a Web application. Note that each step of the following flowchart is executed by the CPU 201 of each device.
[0088] The flowchart in FIG. 6 shows the flow of processing that starts when the process transitions to step S501 in the flowchart in FIG.
[0089] First, in step S601, program development device 101 accepts the placement of screen components by the developer. Specifically, the placement of components by drag and drop 1003 from 1001 in FIG. 10, which is an example of component palette section 423, to 1002, which is an example of screen definition editor section 421, is accepted. FIG. 10 shows an example in which a button component is dragged and dropped from the component palette section to the screen definition editor section. The method of placing screen components is not limited to drag and drop from component palette section 423 to screen definition editor section 421, but may be a method of moving an already placed component or a method of duplicating an already placed component by copy and paste. Also, components that have been placed may be deleted.
[0090] In the case of FIG. 10, as shown in 1004, a screen image is created in which two text input fields (an ID input field and a name input field) and a registration button for registering an ID and a name are provided.
[0091] Next, in step S602, the program development device 101 determines whether a part including an action event has been placed. If it is determined that a part including an action event has been placed, the process proceeds to step S603, and if a part including an action event has not been placed, the process proceeds to step S604.
[0092] When the process proceeds to step S603, the program development device 101 registers an action set in a component including an action event. Specifically, the action is registered in the case of a component having an action called onClick in the source code of the component. In 2100 in FIG. 21, which is an example of the screen definition 402, a definition 2102 of "actions" corresponding to the production environment and a definition 2103 of "examples" corresponding to the prototype application are written out. In the example in FIG. 21, the data storage format is a json file as an example of the implementation means, but the data storage format may be other file formats or a database. Then, the process proceeds to step S604.
[0093] Next, in step S604, the program development device 101 determines whether or not a property input request has been made. Specifically, it determines whether or not 1101 in Fig. 11, which is an example of a property input request button for a selected part, has been pressed.
[0094] 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.
[0095] When the process proceeds to step S605, the program development device 101 accepts input of properties for the screen parts by the developer. Specifically, 1102 in Fig. 11, which is an example of a screen property editor, is displayed, and input of settings for the properties of the screen parts is accepted. In the example of Fig. 11, the screen property editor is displayed near the parts to realize intuitive operation by the developer, but a specific area within the screen may be reserved as the screen property editor. Also, the screen property editor may be displayed in a modal dialog.
[0096] This concludes the explanation of FIG.
[0097] Next, the process of step S503 will be described in detail with reference to FIG.
[0098] 7 is a diagram showing an example of a flowchart for accepting input of prototype data to be displayed on a screen when generating a prototype application for a Web application. Note that each step of the following flowchart is executed by the CPU 201 of each device.
[0099] The flowchart in FIG. 7 shows the flow of processing that starts when the process transitions to step S503 in the flowchart in FIG.
[0100] First, in step S701, the program development device 101 reads the settings of the action item specified by the developer in step S502 in Fig. 5. Specifically, the following two steps are performed. First, 2101 in Fig. 21, which is an example of 1004 in Fig. 10, which is an example of the screen component definition 403 of the screen component selected by the developer, is read. The data of 2101 is assumed to have been input from 1102 in Fig. 11 in step S605 of the flowchart in Fig. 6. Next, the "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.
[0101] Next, in step S702, the program development device 101 determines whether the setting of the action item read in step S701 involves a screen transition. Specifically, it determines whether a value is set in the "nextUi" property (next screen property in 1102), which is an example of the screen transition definition 404 of 2101, which is an example of the screen part definition 403. In this embodiment, the program development device 101 holds the screen transition definition 404 in the screen part definition 403, but it may also hold it in the action definition 405.
[0102] If it is determined that the setting of the action item read in step S701 involves a screen transition, the process proceeds to step S703, and if the setting of the action item read in step S701 does not involve a screen transition, the process proceeds to step S704.
[0103] When the process proceeds to step S703, the program development device 101 displays a destination screen for the screen transition associated with the setting of the action item read in step S701. Specifically, it displays 1300 in FIG. 13, which is the screen set in "nextUi" of 2101. It is assumed that the destination screen 1302 in FIG. 13 is also set in advance by the developer's operation (step S601). It is to be noted that a screen such as 1302 may be displayed in a manner that rewrites the currently displayed screen definition editor unit 421, or in a manner that starts a new screen definition editor unit 421.
[0104] The initial display action of the screen image (transition destination screen) displayed in screen definition editor section 421 is read and this is set as the action designated by the developer. After this processing, the process proceeds to step S704.
[0105] In step S704, the program development device 101 displays on the screen the prototype data already set for the action read in S701 or the action read in S703 (for example, if data such as 2201 in FIG. 22 has already been set, that data).
[0106] Next, in step S705, the program development device 101 accepts the selection of a prototype data display component by the developer. Here, the prototype data display component refers to a component that displays data (prototype data) in advance when a prototype application is operated. Specifically, this is an example in which prototype data is displayed in a list such as 1302 in FIG. 13 displayed on the screen definition editor unit 421. In the prototype data display component 1402 in the same figure, FIG. 14, for example, the selection of the prototype data display component can be accepted by right-clicking a mouse (not shown) in the "Name" column and pressing an edit button 1403. Also, after selecting the entire list as in 1701 in FIG. 17, when a table input button 1702 is pressed, the entire list of 1701 can be selected as the selection of the prototype data display component.
[0107] In the next step S706, the program development device 101 accepts the input of prototype data by the developer. Specifically, a prototype data input dialog 1501 in FIG. 15, which is an example of the prototype data input unit 425, is displayed. 1501 is the prototype data input dialog that is displayed when the edit button is pressed in the "Name" column in 1401 in FIG. 14. In the case of 1501, this is an example in which the developer has input prototype data "Tanigawa Noriyuki" in the "Name" column. After the developer has input the value, a determination is made as to whether the input in step S707 is confirmed by pressing the "OK" button in 1501.
[0108] As another example of step S706, an example of the prototype data input unit 425 will be described with reference to FIG.
[0109] A prototype data input dialog 1801 in FIG. 18 is a screen image displayed when the table input button 1702 in FIG. 17 is pressed. The text input field of 1801 accepts input of a group of data to be displayed in the list displayed in 1701. In the case of 1801, the following data is input: "(blank)", "Tanikawa Noriyuki", "(blank)" in the first line, "1001", "Hori Ai", "2019 / 10 / 10" in the second line, and "1002", "Yamamura Ruriko", "2019 / 09 / 18" in the third line. These data inputs may be adapted to the contents of a CSV file or spreadsheet file selected from a file selection screen (not shown) displayed by pressing the file selection button 1802.
[0110] After the developer inputs a value in the text input field, or after the data is reflected after the file is selected, by pressing the "OK" button 1803, it is determined in step S707 whether the input has been confirmed.
[0111] In step S706, a locale may be specified to switch the prototype data to be displayed depending on the language. Although a method of displaying a modal dialog is shown as a method of accepting prototype data input, the input may be directly input to the display component selected by the developer in S705, or may be input in bulk from an external file.
[0112] In the next step S707, the program development device 101 determines whether the prototype data input by the developer has been finalized. 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 reception method in step S706, if direct input to a component has been received, it is determined whether the focus has been removed from that component.
[0113] If it is determined that the prototype data input has been confirmed (the "OK" button has been pressed), the process proceeds to step S708, and if it is determined that the prototype data input has not been confirmed, the process proceeds to step S706.
[0114] In step S708, the program development device 101 writes the prototype data input by the developer to the screen definition 402. Specifically, the prototype data is written to 2201, which is an example of the prototype data 406 linked to the action 405 of the screen definition 402.
[0115] In this method, it is not possible to change the data displayed on the post-transition screen depending on the action to be executed. This is because the prototype data is stored in the initial display action of the post-transition screen. However, by storing the prototype data to be displayed on the post-transition screen on the side of the action to be executed, it may be possible to change the data to be displayed on the post-transition screen depending on the action to be executed. Specifically, by storing the objects under "onLoad" in 2201 under "onClick" in 2103, the original button that transitions the screen (for example, the "Register" button 1003 located at 1000 in FIG. 10) may have data to be displayed on the post-transition screen.
[0116] In this way, by displaying screen images showing prototype data on the prototype application and transitioning between screens for each action event, you can get an idea of how the mockup will work before creating an actual application that works (for example, searching a database or drawing from the extracted data). This is the end of the explanation of FIG.
[0117] Next, the process of step S507 will be described in detail with reference to FIG.
[0118] 8 is a flowchart illustrating an example of a process for generating source code for a prototype application of a Web application. Each step in the following flowchart is executed by the CPU 201 of each device.
[0119] The flowchart in FIG. 8 shows the flow of processing that starts when the process transitions to step S507 in the flowchart in FIG.
[0120] First, in step S801, the program development device 101 reads the application definition 401 specified by the developer from the repository definition unit 400. The repository definition analysis unit 411 analyzes the read definition and stores it in the ROM 203, and the analyzed definition is referred to by each generation unit as appropriate.
[0121] In step S802, the program development device 101 reads from the repository definition unit 400 the screen definition 402 included in the application definition 401 read in step S801.
[0122] In step S802, when the screen definition is read, information on the display authority defined for each of the screen display items (items) is also acquired. This will be described with reference to the example of FIG. 35. In FIG. 35, when the second line (3501) is defined as the line in which the display items (items) are changed according to the user's authority, information linking the user's authority name 821 with the corresponding input / output display permission item 822 is acquired. In the case of 820 in FIG. 8, the user authority depicted in FIG. 35 has the authority names of "User", "Admin", and "Guest", and the "Attendance confirmation" item in FIG. 35 is defined as the input / output display permission item. Note that this display item definition information may define input / output display permission or may define input / output display prohibited items, and the display items may be collectively defined as the display authority, or may be individually defined as in 820.
[0123] In step S803, the program development device 101 reads from the repository definition unit 400 the screen part definition 403 included in the screen definition 402 read in step S802.
[0124] In step S804, the program development device 101 reads from the repository definition unit 400 the screen transition definition 404 included in the screen definition 402 read in step S802.
[0125] In step S805, the program development device 101 collects the authorities (roles) associated with the display items acquired in step S802.
[0126] In step S806, the program development device 101 reads from the repository definition unit 400 the prototype data 406 contained in the screen definition 402 read in step S802. The data in the screen definition 402 read here is the "examples" data in Fig. 21 and Fig. 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 the application screen as it is.
[0127] In step S807, based on the information read in steps S801 to S806, program development device 101 generates source code for the prototype application in prototype code generation unit 412. The generated source code also includes source code for a prototype operation panel (such as 3102 in FIG. 31) that is displayed when the prototype application is started.
[0128] FIG. 31 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0129] The prototype operation panel will be described with reference to FIG. 31. The prototype operation panel is a panel screen that accepts from the developer instructions for display settings and settings at the time of transition when displaying a prototype (trial production) screen or when transitioning and displaying a prototype (trial production) screen. The prototype operation panel can set the reproduction of a display device (personal computer, tablet, smartphone, etc.) and the screen orientation of the display device, the reproduction of screen displays according to user access rights (Admin authority (administrator authority) or User authority (general user authority)), the reproduction of the display of the processing time on the server, the reproduction of the display when an error occurs, and the like. The display device settings can be set in 3111 of 3102, the user authority settings in 3121 of 3102, the processing wait time settings in 3131 of 3102, and the error display settings in 3141 of 3102.
[0130] The relationship between the prototype application screen and the prototype operation panel 3102 when the prototype operation panel 3102 is open will be described with reference to FIGS.
[0131] FIG. 25 is a diagram for explaining the relationship between the prototype application screen and the prototype operation panel.
[0132] A prototype display screen 2501, which serves as the base for the parent screen, is displayed on the browser, and within the parent screen, a prototype application screen 2502 is displayed in an iFrame. Furthermore, a prototype operation panel 2503 is displayed on top of the prototype application screen 2502, and is displayed on the parent screen 2501 so that part of the prototype application 2502 and the prototype operation panel 2503 can be confirmed at the same time.
[0133] When settings are received from a developer on the prototype operation panel 3102 as shown in Fig. 31, and an operation such as reducing the prototype operation panel 3102 (2503) as shown in 3103 is received from the developer, a prototype application screen 3201 (2522) as shown in Fig. 32 is displayed (display image of 2521). To return from the prototype application screen 3201 (2522) to the screen displaying the prototype operation panel 3102 (2503), the prototype operation panel display button 3202 (2523) is pressed to transition to the screen image 3101 of Fig. 31 displaying the prototype operation panel 3102. Returning to the explanation of the flowchart in Fig. 8.
[0134] An example of the source code generated in step S807 is shown in Fig. 44. Fig. 44 shows an example of TypeScript source code that is started when the prototype operation panel is operated and the browser's memory area (Web Storage and Cookie information) where the operation is stored is changed.
[0135] Next, in step S808, program development device 101 generates source code for changing the screen display for each user authority. An example of the generated source code is shown in Fig. 45. Fig. 45 is an example of source code executed when the user authority is changed, for example, in prototype operation panel 3521 in Fig. 35 or prototype operation panel 3721 in Fig. 37. When the user authority is changed, the source code in the first half of Fig. 45 judges the user authority, and the source code in the second half controls the display / non-display of screen components to which the user authority is applied. That is, step S808 is a procedure for generating a program for displaying a prototype (trial production) screen when the user authority is set.
[0136] In step S809, the program development device 101 generates source code for reproducing a screen display that occurs when connecting to the server. An example of the generated source code is shown in Fig. 46. Fig. 46 shows an example of source code that is executed when a value of a processing time (processing waiting time) is input in the option setting field 3131 or 3141 of the prototype operation panel 3102 as in 3931 in Fig. 39, or when an error setting is changed to ON as in 4241 in Fig. 42, and displays a prototype (trial) screen that reflects the processing setting of the pseudo server acquired from the storage area of the browser. That is, step S809 is a process of generating a program for reproducing pseudo communication and the state of the server when communicating with the server.
[0137] In step S810, the program development device 101 generates a program for reflecting the settings of the subordinate prototype application (iFrame) screen 2502 in the settings of the prototype operation panel 2503 (3102) after drawing the prototype operation panel screen 2503. An example of the generated source code is shown in Fig. 47. Fig. 47 shows TypeScript source code for reproducing the display of the prototype (trial production) screen by, for example, setting the device setting field 3111 of the prototype operation panel 3102 to a button 3112 for setting with an image of a PC (personal computer setting) or setting with a smartphone setting as in the image of 3311 in Fig. 33.
[0138] Once the above source code is generated, the processing of the flowchart in Fig. 8 is completed. Note that, although the source code (Figs. 44 to 47) for executing 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 or the like.
[0139] This is the end of the explanation of FIG.
[0140] Next, the flow of processing when executing the prototype application deployed in step S509 in 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 started in step S511 of the program development device 101 may start communication with the deployed prototype display screen application as shown in Fig. 5, or the Web browser started in the application client 104 may start communication with the deployed application server 102 as shown in Fig. 9.
[0141] 9 is a flowchart showing an example of an operation in which the prototype display screen (parent screen) 440 deployed in step S509 in FIG. 5 is downloaded to and executed by the application client 104. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.
[0142] The flowchart in FIG. 9 shows the flow of processing that starts when the prototype display screen (parent screen) 440 is deployed to the application server 102 (430) and accessed by a developer from a Web browser 450 of the application client 104.
[0143] In step S901, the application client 104 first reads the locale information of the browser. This locale information makes it possible to switch the display language of the prototype data.
[0144] In step S902, the application client 104 downloads from the application server 102 (430) an SPA (single page application) on which the prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs. Note that in the embodiment of the present invention, the prototype display screen (parent screen) 440 is described as an SPA, but it does not necessarily have to be an SPA and may be configured to communicate with the application server 102 by a screen transition command, in which case initial screen information of the prototype application is downloaded.
[0145] Also, in step S902, the application client 104 obtains user authority information in the prototype application.
[0146] Furthermore, in step S902, the application client 104 launches the prototype display screen 2501 (parent screen of the prototype application) from the program acquired from the application server 102 (430). That is, step S902 is a step for downloading and launching a program for displaying the prototype application with a screen image such as that shown in 3101 in Fig. 31.
[0147] In the next step S903, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. The launched screen image is 3201 in Fig. 32, but since the prototype operation panel 3102 displayed in the next step S904 onwards is displayed in the upper layer (the relationship is like that of 2502 and 2503 in Fig. 25), at the beginning of launch, the display screen is like that of 3101 in Fig. 31.
[0148] In the next step S904, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame portion of the prototype display screen 2501. The launched screen image is the image 3102 in Fig. 31. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application.
[0149] In the next step S905, the application client 104 changes the display screen or changes the transition screen of the prototype application 3201 (442) according to the respective settings input to the prototype operation panel 3102. The process of displaying the screen or transition screen of the prototype application 440 according to each setting will be described later with reference to Figs. 26 to 29, respectively.
[0150] Next, in step S906, the application client 104 waits for the developer's instructions as to whether to end the reproduction of the application using the prototype application. If the reproduction of the application is to be ended, this flowchart is terminated. If an instruction to reproduce the application again is received, the process returns to step S902.
[0151] Next, in step S905, the flow of processing for changing the display screen of the prototype application 3201 (442) or changing the transition screen according to each setting input to the prototype operation panel 3102 will be described with reference to Figures 26 to 29. Note that each setting is switching the display device, changing the user authority, replicating the processing time with the server, and replicating when an error occurs.
[0152] 26 is a flowchart showing the flow of processing when switching the display device. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.
[0153] The flowchart in Fig. 26 is a flowchart that starts when a developer accesses the Web browser 450 of the application client 104 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the Web browser 450. Note that some of the explanations in Figs. 26 to 29 overlap with the explanation in Fig. 9.
[0154] First, in step S2601, application client 104 downloads an SPA on which a prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs from application server 102 (430).
[0155] Also, in step S2601, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2601 is a step for downloading and launching a program for displaying a prototype application having a screen image such as that shown in 3101 in Fig. 31.
[0156] In the next step S2602, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. The launched screen image is 3201 in Fig. 32, but since the prototype operation panel 3102 displayed in the next step S2603 onwards is displayed in the upper layer (the relationship is like that of 2502 and 2503 in Fig. 25), at the beginning of launch, the display screen is like that of 3101 in Fig. 31.
[0157] In the next step S2603, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame portion of the prototype display screen 2501. The launched screen image is the image 3102 in Fig. 31. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application.
[0158] When the developer changes the device input field 3111 while the prototype operation panel 3102 is displayed, the process transitions to the next step S2604. A screen image when the developer changes the device input field 3111 will be described with reference to FIG. 33. The device input field 3111 is an input field for which the screen size of each terminal (personal computer, tablet, smartphone) is preset, and for tablets and smartphones, the display form can be changed between portrait and landscape. The reason why portrait and landscape display forms are displayed is because tablets and smartphones can be controlled to display in either portrait or landscape orientation.
[0159] FIG. 33 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0160] Unlike the prototype operation panel 3102 in FIG. 31, the device selection field 3311 of the prototype operation panel 3302 in FIG. 33 is an example in which the smartphone screen button 3312 is pressed.
[0161] Returning to the explanation of the flowchart in Fig. 26, when the process proceeds to the next step S2604, the application client 104 receives an instruction to change the screen size to that of the device changed on the prototype operation panel 3302. An example of source code for executing the processes of steps S2603 and S2604 after displaying 3101 in Fig. 31 is shown in Fig. 47.
[0162] In the next step S2605, the application client 104 displays the prototype application 2502 by adjusting the iFrame portion to the size of the device accepted in step S2604. An image of the prototype application screen when settings such as those of the prototype operation panel 3302 in Fig. 33 are accepted will be described with reference to Fig. 34.
[0163] FIG. 34 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0164] Prototype application screen 3401 in Fig. 34 is displayed at a smartphone size of 3402. Even on a screen displayed at smartphone size, the processing of the prototype application as a trial is executed, and for example, when a specific button is pressed, a transition screen reflecting prototype data corresponding to that action can be displayed.
[0165] The transition from the prototype display screen 3301 (2501 in FIG. 25) on which the prototype operation panel 3302 in FIG. 33 is displayed in the foreground to the screen (2521 in FIG. 25) on which the prototype application screen 3401 in FIG. 34 is displayed in the foreground may be performed, for example, by pressing the down arrow button 3103 in FIG. 31, or by using another button. The transition from the screen (2521 in FIG. 25) on which the prototype application screen 3401 in FIG. 34 is displayed in the foreground to the prototype display screen 3301 (2501 in FIG. 25) on which the prototype operation panel 3302 in FIG. 33 is displayed in the foreground (i.e., returning to the screen of the prototype operation panel 3302) may be performed, for example, by pressing the semi-transparent button 3202 in the lower right of FIG. 32.
[0166] By carrying out the above process, it is possible to easily create a prototype application with a different display format for each device.
[0167] Next, with reference to FIG. 27, a process flow for changing the screen display when the user authority is changed will be described.
[0168] 27 is a flowchart showing the flow of processing when the user authority is switched. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.
[0169] The flowchart in FIG. 27 is a flowchart that starts when a developer accesses the Web browser 450 of the application client 104 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the Web browser 450.
[0170] First, in step S2701, the application client 104 downloads from the application server 102 (430) an SPA on which the prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs.
[0171] In step S2701, the application client 104 acquires user authority information in the prototype application. An example of the acquired data is data such as 2710. This data is the same as the data 830 acquired in step S805 when the prototype display screen application was generated.
[0172] Furthermore, in step S2701, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2701 is a step for downloading and launching a program for displaying a prototype application having a screen image such as that shown in 3101 in Fig. 31.
[0173] In the next step S2702, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. The launched screen image is initially 3201 in Fig. 32, but since the prototype operation panel 3102 displayed in the next step S2703 onwards is displayed in the upper layer (the relationship is like that of 2502 and 2503 in Fig. 25), at the beginning of launch, the display screen will be like that of 3101 in Fig. 31.
[0174] In the next step S2703, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame portion of the prototype display screen 2501. The launched screen image is the image 3102 in Fig. 31. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application. As shown in the user authority setting field 3121 in Fig. 31, the check boxes for user authority setting are generated from the user authority data 830 acquired in step S805.
[0175] When the developer changes the user authority setting field 3121 while the prototype operation panel 3102 is displayed, the process proceeds to the next step S2704. A screen image when the developer changes the user authority setting field 3121 will be described with reference to FIG.
[0176] FIG. 35 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0177] A user authority setting field 3521 of a prototype operation panel 3502 in FIG. 35 is an example in which, unlike the prototype operation panel 3102 in FIG. 31, a check is placed in "user" instead of "guest" in the user authority setting field 3521.
[0178] Returning to the explanation of the flowchart in Fig. 27, when the process proceeds to the next step S2704, the application client 104 stores in the browser's local storage the value of the user authority setting field 3521 changed on the prototype operation panel 3502. Examples of source code for executing the processes of steps S2704 and S2705 when the user authority setting field is changed after 3101 in Fig. 31 is displayed are shown in Figs. 44 and 45.
[0179] In the next step S2705, the application client 104 displays the prototype application 2502 with the user authority setting stored in step S2704. An image of the prototype application screen when the user authority setting field 3521 of the prototype operation panel 3502 in Fig. 35 is accepted will be described with reference to Fig. 36.
[0180] FIG. 36 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0181] Unlike the prototype application screen 3201 in Fig. 32, the prototype application screen 3601 in Fig. 36 has a new attendance confirmation (User) additionally displayed in the underlined portion 3602. This is an image diagram reflecting the data 820 of input / output permission items for each user authority acquired 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 Fig. 36 displays the attendance confirmation (User) field and remarks field, as shown in the underlined portion 3602.
[0182] Another example will be described.
[0183] FIG. 37 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0184] Unlike the prototype operation panel 3102 in Fig. 31, the user authority setting field 3721 of the prototype operation panel 3702 in Fig. 37 is an example in which "guest," "user," and "admin" are all checked, as in the user authority setting field 3722. In this case, according to the data 820 of input / output permission items for each user authority and the user authority data 830 in Fig. 8, the "remarks" field, the attendance confirmation (User) field, the attendance confirmation (Admin) field, and the update button are the input / output permission items.
[0185] FIG. 38 is a schematic diagram for explaining an example of a prototype display screen in this embodiment, and is a screen image displayed in response to user authority setting on the prototype operation panel 3702 in FIG.
[0186] The prototype application screen 3801 in Figure 38 differs from the prototype application screen 3201 in Figure 32 in that the underlined portion 3802 has newly added Attendance Confirmation (Admin) and Attendance Confirmation (User) 3803, and an update button 3804 is also added to the right of the screen.
[0187] The above process has the effect of making it possible to create a prototype application that performs screen transitions depending on the user's role. In other words, if a prototype application that performs only normal screen transitions is generated, it will be a pattern in which only predetermined screen displays and predetermined screen transitions can be performed regardless of user authority, but the present invention has a prototype operation panel setting that switches user authority, and it is possible to reproduce the switching of the displayed screen image for each user authority by switching the user authority.
[0188] Next, the flow of processing for displaying a reproduction of the processing time in the server will be described with reference to FIG.
[0189] 28 is a flowchart showing the flow of processing when the processing time in a virtual server is changed. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.
[0190] The flowchart in FIG. 28 is a flowchart that starts when a developer accesses the Web browser 450 of the application client 104 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the Web browser 450.
[0191] First, in step S2801, application client 104 downloads an SPA on which a prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs from application server 102 (430).
[0192] Also, in step S2801, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2801 is a step for downloading and launching a program for displaying a prototype application having a screen image such as 3901 in Fig. 39. Examples of screens that display a reproduction of the server's processing time will be described with reference to Figs. 39 to 41 and 32.
[0193] FIG. 39 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0194] 39 shows a screen image after the prototype display screen is started, and is an example of the screen displayed when transitioning to step S2803. In step S2801, the parent screen (2501) of the prototype display screen of this screen is started.
[0195] In the next step S2802, the application client 104 launches the prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. A description will be given with reference to FIG.
[0196] FIG. 40 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0197] In step S2802, the prototype application screen 4001 is launched on top of the parent screen launched in step S2801, but since the prototype operation panel 3902, which will be displayed in the next step S2803 onwards, is displayed on top (as in the relationship between 2502 and 2503 in Figure 25), at the beginning of launch, the display screen will be something like 3901 in Figure 39.
[0198] In the next step S2803, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame portion of the prototype display screen 2501. The launched screen image is the image 3902 in Fig. 39. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application. The prototype operation panel 3902 in Fig. 39 has a setting field, such as a processing time setting field 3931, for reproducing the display of screen transitions of the prototype application 2502, taking into account the processing time on the server.
[0199] When the developer changes the processing time setting field 3931 while the prototype operation panel 3902 is displayed, the process moves to the next step S2804.
[0200] In the processing time setting field 3931, at the beginning of startup, the processing time setting field 3131 in FIG. 31 is set to "0.2 seconds", but in the processing time setting field 3931, this is changed to "2 seconds".
[0201] When the process proceeds to the next step S2804, the application client 104 stores in the browser's local storage the value of the server processing time setting field 3931 that was changed on the prototype operation panel 3902. An example of source code to be executed in the process of step S2804 when the processing time setting field is changed after 3901 in Fig. 39 is displayed is shown in Fig. 44.
[0202] In the next step S2805, the application client 104 changes the setting of the prototype application 2502 to wait for the processing time stored in step S2804, and changes the prototype application to one that is reproduced so as to transition to the next screen. Figure 46 shows a part of the source code executed in step S2805. The behavior of the prototype application after the change will be described with reference to Figure 41.
[0203] FIG. 41 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0204] For example, as in prototype display screen 3901 in Fig. 39, when processing time setting field 3931 is set to "2 seconds" in prototype operation panel 3902, pressing the transition button to the prototype application screen 3903, for example, displays a screen like 4001 in Fig. 40. Next, when the user presses search button 4002 to reproduce the operation, a display screen 4102 is displayed in the center as if processing was currently being performed on the server, as in the screen image in Fig. 41. The time displayed to indicate that processing is currently being performed is the time set in processing time setting field 3931. After display screen 4102 is displayed for the set time, the next screen transition, such as Fig. 32, is displayed.
[0205] The above process has an effect of creating a prototype application that reproduces the waiting time during screen transition. That is, the processing time that occurs on the server side when generating a production environment application (product application) can be reproduced. For example, when a business user or a sales representative demonstrates a prototype application to a general user, the processing time with the server that would actually take the processing time can be reproduced, and the screen that will be displayed during the processing time with the server can be reproduced. Since this prototype display screen application is composed of an SPA, communication with the actual server is not required. Therefore, if the prototype application is only executed (screen transition), no processing time is required, and the prototype application screen transitions one after another. Since the processing time on the server is not taken into account in the operation of the production environment application (product application), general users who are convinced by only seeing a demonstration that does not take into account the processing time on the server may feel a discrepancy in the performance of the development deliverable. With the demonstration of the present invention, the server processing time can be freely set, so the risk of discrepancies in the performance of the development deliverable is reduced.
[0206] Next, with reference to FIG. 29, a process flow for displaying the reproduction of an occurrence of an error in a server, a communication error, etc. will be described.
[0207] 29 is a flowchart showing the flow of processing when an error occurs in a virtual server. Note that each step of the following flowchart is executed by the CPU 201 of the application client 104.
[0208] The flowchart in FIG. 29 is a flowchart that starts when a developer accesses the Web browser 450 of the application client 104 and the SPA of the prototype display screen (parent screen) 440 is downloaded to the Web browser 450.
[0209] First, in step S2901, application client 104 downloads an SPA on which a prototype display screen (the application generated in steps S807 to S810 in FIG. 8) runs from application server 102 (430).
[0210] Also, in step S2901, the application client 104 launches the prototype display screen 2501 from the program acquired from the application server 102 (430). That is, step S2901 is a step for downloading and launching a program for displaying a prototype application with a screen image such as 4201 in Fig. 42. Examples of screens that display a reproduction when an error occurs on the server will be described with reference to Figs. 40, 42, and 43.
[0211] FIG. 42 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0212] 42 shows a screen image after the prototype display screen is started, and is an example of the screen displayed when transition is made to step S2903. In step S2901, the parent screen (2501) of the prototype display screen of this screen is started.
[0213] In the next step S2902, the application client 104 launches a prototype application (iFrame) 2502 in the iFrame portion of the prototype display screen 2501. An example of the launched prototype application screen is shown in FIG.
[0214] In step S2902, the prototype application screen 4001 is launched on top of the parent screen launched in step S2901, but since the prototype operation panel 4202, which is displayed in the next step S2903 onwards, is displayed on top (the relationship is like that of 2502 and 2503 in Figure 25), at the beginning of launch, the display screen will be like that of 4201 in Figure 42.
[0215] In the next step S2903, the application client 104 launches the prototype operation panel (iFrame) 2503 in the iFrame portion of the prototype display screen 2501. The launched screen image is the image 4202 in Fig. 42. By changing the settings displayed on this prototype operation panel, it is possible to control the display settings and screen transition settings of the prototype (trial production) application. The prototype operation panel 3902 in Fig. 42 has an error occurrence toggle button 4241 for causing a virtual error during communication with the server, and has a setting field for reproducing the display of the screen transition of the prototype application 2502 taking into account the occurrence of an error in the server.
[0216] When the developer turns the error occurrence toggle button 4241 "on" while the prototype operation panel 4202 is displayed, the process moves to the next step S2904.
[0217] At the beginning of startup, the error occurrence toggle button 4241 is set to "OFF" like the error occurrence toggle button 3141 in FIG. 31, but in this example, the error occurrence toggle button 4241 is changed to "ON."
[0218] When the process proceeds to the next step S2904, the application client 104 stores the "ON" value of the server error occurrence toggle button 4241 changed on the prototype operation panel 4202 as the error setting state in the browser's local storage. An example of source code to be executed in the process of step S2904 when the error setting state is changed after displaying 4201 in Fig. 42 is shown in Fig. 44.
[0219] The next step S2905 and subsequent steps are processes to be performed after the user presses the transition button 4203 to the prototype application in Fig. 42. The screen image after the transition button 4203 is pressed is 4001 in Fig. 40.
[0220] In step S2905, the application client 104 acquires the error setting state stored in step S2904 of the prototype application 2502. Figure 46 shows a portion of the source code executed in step S2905 and subsequent steps.
[0221] Next, a screen transition instruction from, for example, Fig. 40 is accepted from the user. In the case of Fig. 40, the search button 4002, which is a screen transition instruction, is pressed. When the screen transition instruction is accepted, the process proceeds to the next step S2806.
[0222] In the next step S2906, the application client 104 performs different processing depending on whether the acquired error setting state is on (enabled) or off (disabled). If the error setting state is on, the process transitions to step S2907, and if the error setting state is off, the process transitions to step S2908. When the process transitions to step S2908, since the error setting state is off, the application client 104 transitions to the normal transition screen of the prototype application, shown in FIG. 32.
[0223] On the other hand, when the process proceeds to step S2907, the application client 104 proceeds on the assumption that an error has occurred in the prototype application. Specifically, for example, a screen with an image like that shown in FIG.
[0224] FIG. 43 is a schematic diagram for explaining an example of a prototype display screen in this embodiment.
[0225] Specifically, in FIG. 43, when an error occurs in processing using the search button 4002, an error display item such as 4302 is displayed as an error display.
[0226] The above process makes it possible to create a prototype application that can reproduce an error screen 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 a production environment application (product application). Since this prototype display screen application is composed of SPA, communication with an actual server is not required. Therefore, if the prototype application is simply executed (screen transition), no errors will occur on the server or in communication. The SPA can meet the needs of developers and general users who want to reproduce the display screen when an error occurs. In addition, as a method of reproducing an error display more realistically, it may be combined with reproduction of a virtual processing time on the server in FIG. 28. In addition, by having a prototype operation panel, it is possible to reproduce a pattern in which an error occurs even while the prototype application is being executed.
[0227] Since the above-mentioned prototype display screen is composed of SPAs that can be launched in the browsers of various terminals, if the prototype display screen application generated as 2501 in FIG. 30 is downloaded to a personal computer (PC) or tablet, the prototype application 2502 can be reproduced on each terminal. For example, if the prototype display screen application is downloaded to a tablet 3001, the prototype operation panel 2503 and the prototype application 2502 can be operated on the tablet. Even if a salesperson does not bring a personal computer (PC), the prototype display screen application can be operated on the tablet. Since a prototype application that reproduces the processing time on the server can be operated on the tablet, and a smartphone-sized display (3003) can be reproduced on the tablet display (3002), it is possible to reproduce the screens and screen transition patterns to be displayed on various terminals by bringing one terminal when demonstrating to a customer.
[0228] As described above, it goes without saying that the object of the present invention can be achieved by supplying a recording medium on which a program that realizes the functions of the above-mentioned embodiments is recorded to a system or device, and having the computer (or CPU or MPU) of that system or device read and execute the program stored on the recording medium.
[0229] In this case, the program itself read out from the recording medium will realize the novel functions of the present invention, and the recording medium on which the program is recorded will constitute the present invention.
[0230] Examples of recording media for supplying the program include flexible disks, hard disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, DVD-ROMs, magnetic tapes, non-volatile memory cards, ROMs, EEPROMs, silicon disks, etc.
[0231] Furthermore, it goes without saying that the functions of the above-mentioned embodiments are not only realized by the computer executing a program it has read, but also includes cases where an OS (operating system) running on the computer performs some or all of the actual processing based on the instructions of the program, and the functions of the above-mentioned embodiments are realized through that processing.
[0232] Furthermore, it goes without saying that this also includes cases where a program read from a recording medium is written into a memory provided on a function expansion board inserted into a computer or a function expansion unit connected to a computer, and then a CPU or the like provided on the function expansion board or function expansion unit performs some or all of the actual processing based on the instructions of the program code, thereby realizing the functions of the above-mentioned embodiments.
[0233] The present invention may be applied to a system consisting of multiple devices, or to an apparatus consisting of a single device. Needless to say, the present invention can also be applied to a case where the object is achieved by supplying a program to a system or apparatus. In this case, the effect of the present invention can be enjoyed by the system or apparatus by reading a recording medium storing a program for achieving the present invention into the system or apparatus.
[0234] The program may be in the form of object code, program code executed by an interpreter, script data supplied to an OS (operating system), or the like.
[0235] Furthermore, by downloading and reading a program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or device can enjoy the effects of the present invention. Note that the present invention also includes configurations that combine the above-mentioned embodiments and their modified examples. [Explanation of symbols]
[0236] 101 Program Development Equipment 102 Application Server 103 Database Server 104 Application Client 105 Network
Claims
1. a reception unit that receives a setting for displaying error information in response to an occurrence of a predetermined event in a prototype of the application; a generating means for generating a prototype having a first display unit that displays error information in response to an occurrence of the predetermined event based on a setting for displaying error information in the receiving unit; the receiving unit receives an input related to a time from the occurrence of the predetermined event to display the error information; The information processing system according to claim 1, wherein the first display unit displays the error information when the time has elapsed since the occurrence of the predetermined event.
2. 2. The information processing system according to claim 1, wherein the reception unit receives the settings while a screen of a prototype generated by the generation means is displayed.
3. 3. The information processing system according to claim 1, wherein the prototype switches from a screen on which the predetermined event occurs to a screen on which the error information is displayed.
4. 4. The information processing system according to claim 1, wherein the reception unit controls display of the first display unit so as to be superimposed on the screen displayed by the first display unit.
5. 5. The information processing system according to claim 1, wherein the reception unit conceals the reception unit when a predetermined operation is received, and displays the screen displayed by the first display unit.
6. An information processing system as described in any one of claims 1 to 5, characterized in that the prototype is a single-page application and is an application downloaded from a server device to a client device.
7. An information processing system as described in any one of claims 1 to 6, characterized in that the screen displayed on the first display unit is a prototype screen for confirming the screen to be displayed in a production product application, and the prototype is a prototype application of the product application.
8. a generating step of generating a prototype having a receiving unit that receives a setting for displaying error information in response to occurrence of a predetermined event in a prototype of the application, and a first display unit that displays the error information in response to the occurrence of the predetermined event based on the setting for displaying the error information in the receiving unit; the receiving unit receives an input related to a time from the occurrence of the predetermined event to display the error information; The method for controlling an information processing system, wherein the first display unit displays the error information when the time has elapsed since the occurrence of the predetermined event.
9. 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 7.
Citation Information
Patent Citations
Screen design review system, screen design review display method and program
JP2013143087A
Application development system, data processing method for development device, and program
JP2015210639A
Test scenario generation support device and test scenario generation support method
JP2017041171A
Information processing device, information processing method, and program
JP2017220221A
Document preparation method for embedded software and document preparation device
WO2015019422A1