Information processing system, control method thereof, and program

Abstract

To provide an information processing system, a control method thereof, and a program, which can flexibly modify and utilize a defined action without describing it in a programming language.SOLUTION: An information processing system includes: control means for controlling, on the basis of a group of operations including an operation of selecting from options and not including an operation of writing a source code in a programming language, to define an action for a screen of application software to be constructed or to arrange an automatically generated component for which the action is defined as a component to be displayed on a screen of application software to be constructed; and display control means for controlling the display of an action defined for the selected object as a character string in the programming language in response to selection of either the screen on which an action is defined or an automatically generated component by the control means, and in response to an instruction to display the action. The display control means displays, when the control is performed again, the character string in a commented-out state.SELECTED DRAWING: Figure 38

Description

Technical Field

[0001] The present invention relates to an information processing system, a control method for an information processing system, and a program, and more particularly to a technique suitable for use in constructing application software.

Background Art

[0002] Conventionally, as a no-code development tool / low-code development tool that requires little or no code description in a programming language, there is an application construction tool for constructing application software (hereinafter referred to as an application) according to a definition.

[0003] Patent Document 1 proposes creating a Web application screen having four functions of registering / searching / updating / deleting records in a customer master based on input to an input form for setting which input / output items to use for each of the four functions of Create (register) / Read (search) / Update (update) / Delete (delete). Patent Document 2 proposes generating program code from a business specification (input / output table) input in an input mode.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] The functions required for the applications to be constructed are diversified. In contrast, scratch development for constructing applications from scratch requires a great deal of effort and high skills and knowledge for developers. Therefore, for functions generated according to the content input into an input form as in Patent Document 1, for example, it is preferable that instead of using them as they are, some are used and some are modified and customized. However, Patent Document 1 does not consider customizing functions created based on the input to the input form. Neither does Patent Document 2 consider these issues.

[0006] Therefore, in view of the above problems, an object of the present invention is to provide a mechanism that can more flexibly modify and use actions defined without the user having to describe them in a programming language.

Means for Solving the Problems

[0007] The information processing system of the present invention defines an action for the screen of application software to be constructed based on an operation group including an operation of selecting from options without including an operation of describing source code in a programming language, or controls to arrange an automatically generated component in which an action is defined as a component displayed on the screen of the application software to be constructed, and has display control means for controlling to display, as a character string in a programming language, the action defined for the selected target in response to a selection of either the screen for which an action is defined by the control means or the automatically generated component and an instruction to display the action. The display control means is characterized in that when the control means performs control again, the display control means controls to comment out and display the character string in the programming language representing the action that was displayed by the display control means.

Effects of the Invention

[0008] According to the present invention, actions defined without the user having to write in a programming language can be modified and utilized more flexibly.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Embodiments for Carrying Out the Invention

[0010] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the invention according to the claims, and not all combinations of the features described in the embodiments are essential for the invention. Two or more of the features described in the embodiments may be arbitrarily combined. Also, the same or similar configurations are assigned the same reference numerals, and redundant descriptions are omitted.

[0011] The various feature items shown in the embodiments described below can be combined with each other. Hereinafter, "application" and "app" both mean application software.

[0012] <System Configuration> FIG. 1 shows a system configuration diagram of an information processing system as an embodiment of the present invention. FIG. 1 shows a system for software development and a system for using the developed software.

[0013] The developer terminal 100 is an information processing device (information processing terminal) operated by a developer user that can be configured by a personal computer (hereinafter, PC) or a smartphone. That is, it is the user terminal of the developer user. The developer terminal 100 receives a design operation of an application to be developed from the developer and transmits various definition information of the application, which is the designed content, to the development environment 300.

[0014] The development environment 300 is an environment that uses at least one hardware resource constructed on a network (on the cloud, on the Internet). The development environment 300 is a multi-tenant environment and an environment in which multiple developer users can log in. The development environment 300 includes developer information 301, an execution engine 302, and a storage 320. The development environment 300 is constructed by combining a plurality of Web services (cloud services).

[0015] The developer information 301 is information that records the accounts of developers who can log in to the development environment 300, such as the email address (user ID) that serves as the developer's account ID and the password. The developer information 301 is recorded on at least one recording medium included in the development environment 300. Details of the developer information 301 will be described later with reference to FIG. 14(a).

[0016] The execution engine 302 is at least one hardware resource for executing the processes to be executed in the development environment 300, and includes a processor 303 and a memory 304. The processor 303 consists of at least one processor, which may be one processor on the cloud or a group of processors combined from a plurality of processors. The memory 304 is at least one recording medium that records the programs to be executed by the processor 303. Among the various flowcharts described later, those described as being executed by the development environment 300 are executed by the execution engine 302. That is, it is realized by the processor 303 expanding and executing the program recorded in the memory 304 in the area that serves as the work memory in the development environment 300.

[0017] The distribution engine 305 transmits a client program 322 (such as HTML source code or JavaScript source code) to be executed on the developer terminal 100 to the developer terminal 100 that has accessed the development environment 300. The client program 322 is pre-recorded in the storage 320 included in the development environment 300.

[0018] The storage 320 is a storage area of at least one recording medium, and stores at least a client program 322 that is common to each developer. It also has a developer area which is a storage area for each developer's account. For example, when there are developers A, B, and C who can log in, it includes a developer A area 323 which is an area for developer A, a developer B area 324 which is an area for developer B, and a developer C area 325 which is an area for developer C. Each developer area stores the definition information of the applications developed by each developer. For example, the application definition 323a (including the UI definition information of the application and the program for the application execution environment, which will be described later in FIG. 34) is recorded in the developer A area 323.

[0019] The developer accesses the development environment 300 by accessing the URL for accessing the development environment 300 from the browser software of the developer terminal 100, and logs in to the development environment. When logging in to the development environment, the client program 322 and the application definition (UI definition information), which is the content saved by performing development work in the past, are received from the development environment. Then, an operation of newly designing an application or an operation of updating and designing an existing (in-progress) application is performed, and the resulting application definition information (application definition, UI definition information) is sent to the development environment 300. The development environment 300 saves the received application definition in the developer area for that developer. In this way, in this embodiment, any terminal that can access the development environment 300 on the cloud can be used as the developer terminal 100 to design an application. Therefore, as long as the terminal can be connected to the Internet, the developer can develop an application regardless of the location.

[0020] The execution environment 400 is an environment that uses at least one hardware resource built on a network (on the cloud, on the Internet). The execution environment 400 includes a multi-tenant execution environment 410 and a plurality of single-tenant execution environments (for example, single-tenant execution environments 450, 460, 470). The execution environment 400 is constructed by combining a plurality of web services (cloud services). The execution environment 400 is an environment for deploying definition information (app definition) of an application developed using the developer terminal 100 and the development environment 300. Then, the app user terminals 200, 201 used by the users who use the application access the execution environment 400 by accessing the URL for executing the application. Then, by the execution environment 400 executing various actions according to the operations performed on the app user terminals 200, 201, the developed application is executed, and the functions of the application are provided to the app users. The application constructed in the execution environment 400 on the network is a so-called web application.

[0021] The multi-tenant execution environment 410 is an execution environment of a multi-tenant environment shared by a plurality of developers, and applications developed by a plurality of developers are deployed. That is, it is an environment shared by a plurality of developers and an environment in which a plurality of apps of a plurality of developers can be constructed. The multi-tenant execution environment 410 includes user information 411, an execution engine 412, a delivery engine 415, a storage 420, and a DB set 433.

[0022] The user information 411 is information that records the accounts of app users who can log in to the application, such as the email address (username) that serves as the user account ID of the deployed application (constructed application) and the password. The user information 411 is recorded on at least one recording medium included in the multi-tenant execution environment 410.

[0023] The execution engine 412 is at least one hardware resource for executing the processes to be executed in the multi-tenant execution environment 410, and includes a processor 413 and a memory 414. The processor 413 consists of at least one processor, which may be one processor on the cloud or a group of processors combined with multiple processors. The memory 414 is at least one recording medium that records the programs to be executed by the processor 413. Among the various flowcharts described later, those described as being executed by the multi-tenant execution environment 410 are executed by the execution engine 412. That is, it is realized by the processor 413 expanding and executing the program recorded in the memory 414 in the area that serves as the working memory in the multi-tenant execution environment 410. The programs executed here include programs that execute the actions of the application.

[0024] The distribution engine 415 transmits the client programs 422 (such as HTML source code and JavaScript source code) to be executed on the application user terminals 200 and 201 to the application user terminals 200 and 201 that have accessed the multi-tenant execution environment 410. The client programs 422 are pre-recorded in the storage 420 included in the execution environment 410.

[0025] Storage 420 is a storage area of at least one recording medium, and stores at least a client program 422 that is common to a plurality of applications. Also, in a predetermined area (predetermined folder, predetermined bucket, under a predetermined hierarchy) of the storage 420, access destination information 421 for accessing the execution environment (multi-tenant execution environment 410) is recorded. Further, it has a developer area which is a storage area for each developer's account. For example, it includes a developer A area 423 which is an area for developer A, a developer B area 424 which is an area for developer B, and a developer C area 425 which is an area for developer C. Each developer area stores definition information of an application developed by each developer and deployed from the development environment 300. For example, an application definition 423a is recorded in the developer A area 423.

[0026] The DB set 430 is a group of information regarding databases used by applications deployed in the execution environment 410. The DB set 430 is stored in a storage area of at least one recording medium. Details of the DB set 430 will be described later with reference to FIG. 23.

[0027] The single-tenant execution environments 1 (450), 2 (460), and 3 (470) are execution environments dedicated to one developer (one developer account) each, and applications developed using the development environment 300 by the owning developer are deployed. In this embodiment, as an example, the owner of the single-tenant execution environment 1 (450) is Developer A, the owner of the single-tenant execution environment 2 (460) is also Developer A, and the owner of the single-tenant execution environment 3 (470) is Developer B. Thus, one developer can own multiple single-tenant execution environments. The single-tenant execution environments 1 (450), 2 (460), and 3 (470) each include user information 451, 461, 471, execution engines 452, 462, 472, distribution engines 455, 465, 475, storage 456, 466, 476, and DB sets 457, 467, 477. These have the same functions as the user information 411, execution engine 412, distribution engine 415, storage 420, and DB set 433 of the multi-tenant execution environment 410 described above, except that they are dedicated to one developer, so detailed description is omitted. There can be more than just the three illustrated single-tenant execution environments, and it is possible to construct even more.

[0028] Using the system of FIG. 1, for example, it can be considered that an operator provides the multi-tenant execution environment 410 to developers for free and provides the single-tenant execution environment for a fee. The operator of this system needs to pay maintenance costs to the provider of resources and services (cloud service provider) for both the multi-tenant execution environment 410 and each single-tenant execution environment. By the operator bearing the maintenance cost of the multi-tenant execution environment 410 and providing it to multiple developers for free, developers do not need to bear the cost for trying out this system, so it is easy for many developers to use, and the spread of this system can be promoted. The operator recovers costs by charging developers for the single-tenant execution environment.

[0029] There is an upper limit to the number of processing requests that can be processed per unit time in one execution environment, and when many applications are built in a multi-tenant execution environment and many app users access the environment simultaneously, the requests cannot be processed, which may result in the applications running slowly. In addition, there are some limitations on the number of applications developed by many developers that can be deployed and executed in a multi-tenant execution environment, and these limitations may prevent the applications from performing satisfactorily. If a developer pays to own a dedicated single-tenant execution environment, the problems caused by the limitations of such a multi-tenant execution environment can be avoided (or reduced). In other words, by building an application in a single-tenant execution environment, it is possible to build an application that performs satisfactorily.

[0030] Considering the characteristics of both the multi-tenant single environment and the single-tenant execution environment, the developer can use the system as follows. For example, when using the system for the first time, the developer can build an application developed using the system in the multi-tenant execution environment 410 and test it, and then, if the developer determines that the system is useful for the developer's software development, introduce the single-tenant execution environment for a fee. When developing a specific application X, the developer builds an alpha version of the application X in the multi-tenant execution environment 410 for a limited number of test users to test before releasing it to general users. The developer tests the application X, modifies the application X, and further develops it. After the development is completed to a level where it can be released to general users, the developer builds a production version of the application X in the single-tenant execution environment and releases it to general users. By using the system in this way, the developer can reduce development costs during the development period and operate an application without problems even when used by a large number of general users.

[0031] FIG. 2 shows a hardware block diagram of an information processing apparatus as an example of an apparatus (electronic device) applicable as the developer terminal 100, the app user terminal 200, and the app user terminal 201. In FIG. 2, a CPU 101, a memory 102, a non-volatile memory 103, an image processing unit 104, a display 105, an operation unit 106, a recording medium I / F 107, an external I / F 109, and a communication I / F 110 are connected to an internal bus 150. Each unit connected to the internal bus 150 is configured to be able to exchange data with each other via the internal bus 150.

[0032] The memory 102 is composed of, for example, a RAM (volatile memory using semiconductor elements, etc.). The CPU 101 controls each part of the information processing apparatus using the memory 102 as a work memory according to a program stored in the non-volatile memory 103, for example. The non-volatile memory 103 stores image data, audio data, other data, various programs for the CPU 101 to operate, etc. The non-volatile memory 103 is composed of, for example, a hard disk (HD) or a ROM, etc.

[0033] Based on the control of the CPU 101, the image processing unit 104 performs various image processes on the image data stored in the non-volatile memory 103 or the recording medium 108, the video signal acquired via the external I / F 109, the image data acquired via the communication I / F 110, the captured image, etc. The image processes performed by the image processing unit 104 include A / D conversion processing, D / A conversion processing, encoding processing of image data, compression processing, decoding processing, enlargement / reduction processing (resizing), noise reduction processing, color conversion processing, etc. The image processing unit 104 may be composed of dedicated circuit blocks for performing specific image processes. Also, depending on the type of image process, it is also possible for the CPU 101 to perform image processing according to a program without using the image processing unit 104.

[0034] The display 105 displays an image, a GUI screen constituting a GUI (Graphical User Interface), etc. based on the control of the CPU 101. The CPU 101 generates a display control signal according to a program, generates a video signal for display on the display 105, and controls each part of the information processing device to output it to the display 105. The display 105 displays a video based on the output video signal. Note that the configuration of the information processing device itself includes up to an interface for outputting a video signal for display on the display 105, and the display 105 may be configured by an external monitor (such as a TV). Hereinafter, unless otherwise specified, the display destination in the processes executed by the developer terminal 100, the application user terminal 200, and the application user terminal 201 is the display 105 of each operator.

[0035] The operation unit 106 is an input device for receiving user operations, including a character information input device such as a keyboard, a pointing device such as a mouse or a touch panel, buttons, dials, joysticks, touch sensors, touch pads, etc. Note that the touch panel is an input device configured flatly by overlapping it with the display 105 so that coordinate information corresponding to the touched position is output.

[0036] The recording medium I / F 107 is capable of mounting a recording medium 108 such as a memory card, CD, or DVD, and based on the control of the CPU 101, reads data from the mounted recording medium 108 and writes data to the recording medium 108. The external I / F 109 is an interface for connecting to an external device via a wired cable or wirelessly and performing input / output of video signals and audio signals. The communication I / F 110 is an interface for communicating with an external device, the Internet 111, etc. and performing transmission and reception of various data such as files and commands. The developer terminal 100 can communicate (send and receive information) with the development environment 300 on the Internet 111 using the communication I / F 110. The application user terminals 200, 201 can communicate (send and receive information) with the execution environment 400 on the Internet 111 using the communication I / F 110.

[0037] <Login process> Figures 3(a) and (b) show the flowchart of the login process. This process is the process from logging in to the development environment 300 from the developer terminal 100 until the UI editor is displayed. In the developer terminal 100, when there is an instruction to start the Internet browser software and specify and access the URL of the development system (application development platform) of this embodiment, the process of Figure 3(a) starts. The process of Figure 3(a) is realized by the CPU 101 of the developer terminal 100 expanding and executing the program recorded in the non-volatile memory 103 for executing the Internet browser software and the client program 322 received from the development environment 300 in the memory 102. Hereinafter, what is simply described as the process executed by the developer terminal 100 is assumed to be the process of the CPU 101 of the developer terminal 100 expanding and executing the program recorded in the non-volatile memory 103 for executing the Internet browser software and the client program 322 received from the development environment 300 in the memory 102.

[0038] When the developer's terminal 100 launches Internet browser software and accesses by specifying the URL of the development system (application development platform) of this embodiment, the distribution engine 305 of the development environment 300 detects the access and transmits the client program 322 to the developer's terminal 100 that is the access source.

[0039] In S301, the developer's terminal 100 determines whether it has received the client program 322 transmitted from the development environment 300. If not received, it waits for reception in S301, and if received, proceeds to S302.

[0040] In S302, the developer's terminal 100 records the client program 322 received from the development environment 300 in the memory 102.

[0041] In S303, the developer's terminal 100 displays a login screen on the display 105 according to the client program 322. On the login screen, it is indicated that it is a login screen to the development system of this embodiment, and input fields for the developer ID and password, a new registration button (icon), and a login button (icon) are displayed.

[0042] In S304, the developer's terminal 100 accepts an input operation to the input fields for the developer ID and password on the login screen. The user's input operation is performed using the operation unit 106. The developer ID is user identification information for identifying (specifying) the developer user. In this embodiment, it is assumed that the developer ID (username) is an email address. Also, the password used as authentication information is assumed to be an arbitrary character string, but other authentication information such as biometric authentication information (fingerprint authentication or face authentication information) or pattern authentication information (information on the trajectory pattern input on the screen) may also be used.

[0043] In S305, the developer terminal 100 determines whether an operation (such as a click) instructing the new registration button on the login screen has been performed. Hereinafter, for a display item (a displayed object such as a button or an icon, a display item), an operation of instructing by a method such as clicking with the mouse included in the operation unit 106 or touching the touch panel is simply described as "pressed". If the new registration button is pressed, the process proceeds to S306; otherwise, it proceeds to S307.

[0044] In S306, the developer terminal 100 performs developer account registration processing. The details of the developer account registration processing will be described later with reference to FIG. 22(a).

[0045] In S307, the developer terminal 100 determines whether the login button on the login screen has been pressed. If the login button is pressed, the process proceeds to S308; otherwise, it returns to S304.

[0046] In S308, the developer terminal 100 transmits, as login information, the information (the entered developer ID and password) entered in the developer ID and password input fields on the login screen to the development environment 300. After the transmission, since authentication processing is performed in the development environment 300, wait for the result.

[0047] In S309, the developer terminal 100 determines whether it has received information indicating a login error from the development environment 300. If it has received information indicating a login error, it returns to S304 to accept the input of login information again; otherwise, it proceeds to S310.

[0048] In S310, the developer terminal 100 determines whether it has received an execution environment list from the development environment 300. Since the development environment 300 transmits the execution environment list to the developer terminal 100 if the login authentication is successful, receiving the execution environment list means that the login authentication has been successful (able to log in). If the execution environment list is received, the process proceeds to S311; otherwise, it returns to S309.

[0049] In S311, the developer terminal 100 records the execution environment list received in S310 in the memory 102 as the development screen of the application after login, and displays options for the execution environment on the display 105 based on the received execution environment list. The execution environment list indicates the execution environments accessible to the logged-in developer. Hereinafter, the screens displayed on the developer terminal 100 after S311 and different from the screens of the built application are collectively referred to as development screens.

[0050] Fig. 5(a) shows an example of the display of options for the execution environment in S311. In the display example of Fig. 5(a), two options are displayed: an option 551 corresponding to the multi-tenant execution environment 410 and an option 552 corresponding to the single-tenant execution environment, which are the execution environments accessible to the logged-in developer. The developer user can select one of these options by pressing any of them, and confirm the selection by pressing the SAVE button 553. What is selected here is the destination where the application updated in the subsequent work in this login will be deployed. It does not access the execution environment at this point. Also, the execution environment selected here can be changed by the operations described later.

[0051] In S312, the developer terminal 100 determines whether the execution environment has been selected. If any of the options for the execution environment is pressed and the SAVE button 553 is pressed, it proceeds to S313; otherwise, it waits for the selection of the execution environment in S312.

[0052] In S313, the developer terminal 100 records the information (such as the execution environment ID) identifying the execution environment selected in S312 in the memory 102 as the "selected execution environment" and transmits it to the development environment 300. In the development environment 300, in response to receiving the information identifying the selected execution environment (selected environment), as application information, it transmits the information (such as the application ID and application name) identifying all the applications owned by the logged-in developer (applications generated in the past and recorded in the storage 320).

[0053] In S314, the developer terminal 100 determines whether it has received application information from the development environment 300. If it has received the application information, it proceeds to S315; otherwise, it waits for the reception of the application information in S314.

[0054] In S315, the developer terminal 100 records the received application information in the memory 102 and, based on the application information, displays a list of (in-development) applications owned by the logged-in user (application list) on the display 105.

[0055] In S316, the developer terminal 100 determines whether any application has been selected from the list of applications displayed in the application list. If any application has been selected, it proceeds to S317; otherwise, it proceeds to S320.

[0056] In S317, the developer terminal 100 designates the application selected from the application list as the "selected application" and records information (such as the application ID and application name) for identifying the selected application in the memory 102 and transmits it to the development environment 300. In the development environment 300, when it receives the information for identifying the selected application, it acquires the definition information (application definition) of the selected application from the area of the logged-in developer in the storage 320 and transmits it to the developer terminal 100.

[0057] In S318, the developer terminal 100 determines whether it has received the definition information (UI definition information) of the selected application from the development environment 300. If it has received the definition information of the selected application, it records the received definition information of the selected application in the memory 102 and proceeds to S319. Otherwise, it waits for the reception of the definition information in S318. In this embodiment, this definition information is assumed to be a Json file in which various definitions regarding the application are described in Json format. Thereafter, when displaying on the display 105 regarding the selected application, the display is performed based on the definition information recorded in the memory 102. When an operation to update the selected application (for example, changing the arrangement of UI components) is performed in UI editor processing or the like described later, the definition information in this memory 102 is updated to define the updated content. Then, when there is an instruction to save, the latest definition information recorded in the memory 102 is transmitted to the development environment 300 and saved in the area of the logged-in developer in the storage 320. By doing so, it is possible to suppress an increase in the communication frequency with the development environment 300, suppress a decrease in the response due to communication, and perform a comfortable update operation.

[0058] In S319, the developer terminal 100 displays a UI editor screen on the display 105 and performs a display based on the received definition information. For example, it displays a canvas (editing area of the UI screen) in a shape corresponding to whether the selected app is for the desktop or for mobile (i.e., a shape corresponding to the type of device on which the app is used). If it is for the desktop, a 16:9 rectangular canvas is displayed, and if it is for mobile, a canvas with a portrait aspect ratio imitating a smartphone is displayed. In the sub-menu area (described later), a list of UI screens that the selected app has (belongs to the selected app) is displayed (this process is strictly performed in S401 of FIG. 4 described later). Also, on the canvas, components (UI parts arranged on the UI screen) arranged on the UI screen that is selected by default (initial UI or the UI screen being edited when saved last) are displayed. Note that instead of selecting the UI screen to be edited by default, it may be set to display nothing on the canvas at this point. The process of S319 ends the login process, and then proceeds to S401 of FIG. 4.

[0059] On the other hand, in S320, the developer terminal 100 determines whether an icon (+ mark, not shown) for creating a new application, which is displayed on the screen where the app list is displayed, has been pressed and a new application creation has been instructed. If it is determined that a new application creation has been instructed, it proceeds to S321; otherwise, it returns to S316.

[0060] In S321, the developer terminal 100 displays a selection screen for whether the application to be newly created is for the desktop (PC) or for mobile, and accepts an operation to select one of them. A desktop application is an application assumed to be accessed and operated from an app user terminal 200 such as a desktop PC or a notebook PC. A mobile application is an application assumed to be accessed and operated from an app user terminal 201 such as a smartphone.

[0061] In S322, the developer terminal 100 displays a screen for receiving input of basic app information (at least the app name and app ID) regarding the newly created application, and receives an input operation for setting the app information. When receiving the input of the app information, the developer terminal 100 transmits the information on whether it is for desktop (PC) or mobile received in S321 and the app information received in S322 to the development environment 300. Thus, as the definition information of the newly created application, the definition information of the new application is created in the storage 320 of the development environment 300, and the information on whether it is for desktop (PC) or mobile, the app name, and the app ID are recorded. The information on whether it is for desktop (PC) or mobile, the app name, and the app ID are also recorded in this way in the definition information of the applications created in the past.

[0062] In S323, the developer terminal 100 displays a UI editor screen as the editing screen of the newly created application. In this case, the canvas is displayed in a shape corresponding to whether it is for desktop or mobile selected in S321. Also, the canvas is displayed with blank information where no components are arranged. The login process in the process of S323 is terminated, and then the process proceeds to S401 in FIG. 4.

[0063] FIG. 3(b) shows the login process on the development environment 300 side that cooperates with the login process on the developer terminal 100 side in FIG. 3(a). The process in FIG. 3(b) is realized by the processor 303 of the development environment 300 expanding and executing the program recorded in the memory 304 in the area that serves as the work memory in the development environment 300. Hereinafter, what is simply described as the process executed by the development environment 300 is assumed to be the process executed by the execution engine 302 of the development environment 300, and more specifically, the process executed by the processor 303.

[0064] In S331, the development environment 300 determines whether it has received the login information transmitted from the developer terminal 100 in S308. If it has received the login information, the process proceeds to S332; otherwise, it waits for the reception of the login information.

[0065] In S332, the development environment 300 compares the received login information with the developer information 301 to perform login authentication (user authentication). More specifically, it determines whether information that matches the combination of the developer ID and password included in the received login information is included in the developer information 301 (user information). If it is included, the authentication is successful.

[0066] In S333, the development environment 300 determines whether, as a result of the authentication process in S332, the login is successful (the authentication has succeeded, the user has been authenticated, the authentication is okay). If the login is successful, it proceeds to S335. If the login is not successful, it proceeds to S334 and sends information indicating that a login error has occurred to the developer terminal 100.

[0067] In S335, the development environment 300 transmits to the developer terminal 100 the list of execution environments of the developer (logged-in developer) for whom login is successful, which is included in the developer information 301. As shown in FIG. 14(a), in the developer information 301, for each developer, in addition to the email address (username, developer ID) and password, the accessible execution environment ID is recorded. Each execution environment ID is an account ID in the cloud service (Web service), and in this embodiment, it is assumed to be a 12-digit ID. In the case of a developer who can access multiple execution environments, the 12-digit execution environment IDs are recorded separated by commas. In S335, this accessible execution environment ID (one or more execution environment IDs separated by commas) for the logged-in developer is transmitted to the developer terminal 100. That is, in S335, by referring to the developer information 301, the execution environments accessible to the logged-in developer are identified. In this way, the accessible execution environments (execution environments available to each developer) of each developer are recorded in the developer information 301 recorded in the development environment 300. And this executable login environment can only be obtained by a developer who has successfully logged in. Also, only the accessible execution environments of the developer who has successfully logged in can be obtained. By doing so, it is not necessary for the developer to separately manage the information for accessing his / her accessible execution environment and the information for logging in to the development environment 300. Also, it is possible to prevent other users from illegally accessing the execution environment.

[0068] In S336, the development environment 300 determines whether it has received the information (environment identification information) for identifying the selected execution environment transmitted from the developer terminal 100 in S313. If it has received the information for identifying the selected execution environment, it proceeds to S337; otherwise, it waits for the reception of the information for identifying the selected execution environment.

[0069] In S337, the development environment 300 records the selected execution environment in the configuration management file stored in the area for the logged-in developer in the storage 320 based on the information for identifying the selected execution environment received in S336.

[0070] In S338, the development environment 300 acquires, from the area of the logged-in developer in the storage 320, application information indicating all applications owned by (created by) the logged-in developer, and transmits it to the developer terminal 100. The application information to be transmitted here is up to the information necessary for displaying the application list described above in S315 among the definition information of the application, and does not include detailed definition information regarding each application (such as component arrangement and information indicating actions described later).

[0071] In S339, the development environment 300 determines whether it has received information regarding a new application (information including whether it is for desktop (PC) or mobile, the application name, and the application ID) transmitted from the developer terminal 100 in S322. If it has received the information regarding the new application, it proceeds to S340; otherwise, it proceeds to S341.

[0072] In S340, the development environment 300 creates and records, in the area of the logged-in developer in the storage 320, definition information of a new application based on the information regarding the new application received in S339. The definition information recorded here includes information indicating whether it is for desktop (PC) or mobile, the application name, and the application ID. In the development environment 300, in order to distinguish it from the applications of other users in the multi-tenant execution environment 410, as the application ID, an 8-digit developer code uniquely corresponding to the developer ID of the developer who owns the application is appended immediately before the ID input by the developer in S322 and recorded. Then, the login process is terminated. Thereafter, when performing internal processing and when displaying in the programming language on the action board, if the application ID is used, the process is performed using the ID with the developer code of the logged-in developer appended. Also, when displaying as the application ID in the UI editor or the like, only the ID part input by the developer in S322 excluding the developer code is displayed.

[0073] In S341, the development environment 300 determines whether it has received information identifying the selected app transmitted from the developer terminal 100 in S317. If it has received the information identifying the selected app, it proceeds to S342; otherwise, it returns to S339.

[0074] In S342, based on the information identifying the selected app received in S341, the development environment 300 acquires the definition information (app definition) of the selected app from the area of the logged-in developer in the storage 320 and transmits it to the developer terminal 100. The definition information transmitted here includes detailed definition information regarding the selected app (such as the arrangement of components and information indicating actions described later). Then, the login process ends.

[0075] <UI Editor Process> The UI editor process will be described with reference to FIGS. 4 and 5(b). The UI editor process is a process of performing various definitions (UI component definitions, action definitions) of the application to be constructed in response to operations from the developer (user) on the UI editor screen (application development screen).

[0076] FIG. 5(b) shows an example display of the layout editing screen displayed in the UI editor process on the display 105. The screen in FIG. 5(b) includes a header menu area 500, a main menu area 510, a sub-menu area 520, and a canvas 530 (the editing reception area for the UI screen).

[0077] In the header menu area 500, a selected execution environment box 501, a selected app box 502, a selected UI screen box 503, a save button 504, a preview button 505, and a deploy button 506 are displayed.

[0078] In the selected execution environment box 501, the selected execution environment ID is displayed as information representing the selected execution environment. By pressing the arrow icon at the right end of the selected execution environment box 501, a pull-down menu is displayed with a list of execution environments accessible to the logged-in developer obtained in S310. By selecting an arbitrary execution environment from the list, it is possible to change the selected execution environment. Even if the selected execution environment is changed, the selected application remains unchanged, and the content displayed in the main menu area 510, sub-menu area 520, and canvas 530 does not change. In this way, by changing the selected execution environment to which the same application is deployed, it is possible to deploy the same application to an arbitrary plurality of execution environments.

[0079] In the selected application box 502, the application name of the selected application is displayed as information representing the selected application. By pressing the arrow icon at the right end of the selected application box 502, a pull-down menu is displayed with a list of applications owned by the logged-in developer obtained in S314. By selecting an arbitrary application from the list, it is possible to change the selected application. When the selected application is changed, the content to be displayed in the sub-menu area 520 and canvas 530 changes.

[0080] In the selected UI screen box 503, the name of the UI screen being edited is displayed as information representing the UI screen being edited on the canvas 530. By pressing the arrow icon in the selected UI screen box 504, a pull-down menu is displayed with a list of UI screens belonging to the selected application based on the definition information of the selected application obtained in S318. By selecting an arbitrary UI screen from the list, it is possible to change the UI screen to be edited and displayed on the canvas 530.

[0081] In the main menu area 510, as selection icons for menu items of the main menu, an application list button 511, a UI screen button 512, a workflow button 513, a settings button 514, an environment list button 515, a database button 516, a file manager button 517, a user management button 518, and a snapshot button 519 are displayed. The processing in response to pressing these selections will be described later in the screen switching processing of FIG. 12.

[0082] In the sub-menu area 520, a sub-menu corresponding to the item selected in the main menu is displayed. In the example of FIG. 5(b), an example is shown in which a UI component list (UI parts list) is displayed as a lower-level menu of the UI screen button 512.

[0083] The canvas 530 is the layout editing area of the UI screen being selected (the UI screen with the UI screen name displayed in the selected UI screen box 503) of the application being selected. The canvas 530 in Fig. 5(b) is an example of the display of the canvas of a desktop application, and it is displayed in a desktop shape. The user can select any UI component (UI component) from the list of UI components displayed in the sub-menu area 520 and drag and drop it onto the canvas area 530. The UI component placed in the canvas area 530 can be selected to adjust its size and position. Also, by selecting the properties included in the right-click menu (context menu) that is displayed when the UI component placed in the canvas area 530 is selected and right-clicked, more detailed settings such as color matching can be made. Furthermore, by selecting the action included in the context menu as well, an action board is displayed, and the action to be executed when the UI component is operated can be set. By right-clicking with the cursor in the blank area of the canvas 530, the context menu of the canvas can be displayed, and by selecting the action included therein, the action to be executed (executed when the UI screen of the canvas is displayed) when the UI screen of the canvas is loaded in the constructed application can be set.

[0084] Fig. 5(b) is an example in which a pie chart 531 (pie chart, circular graph), button 532, text fields 533, 534, output field 535 (Output Field), and tab component 536 are arranged as UI components on the canvas 530 with the UI screen name "ui1" of the application with the application name "UI1". The operation path 531a is a selection frame indicating the selected UI component and an operation path (operation handle) that accepts instructions for enlargement and reduction, and it indicates that the pie chart 531 is selected.

[0085] Fig. 4 shows a flowchart of the UI editor process. This process is executed by the developer terminal 100 and follows S319 or S323 in Fig. 3.

[0086] In S401, based on the definition information of the selected app, the developer terminal 100 displays a list of UI screens of the selected app as options in the sub-menu area 520. Each screen displayed in this UI screen list is designed as a screen to be displayed when the selected app is deployed and constructed in the execution environment and accessed from the app user terminals 200 and 201 to execute the app. In this UI screen list, operations such as adding a new UI screen and deleting a UI screen are also acceptable.

[0087] In S402, the developer terminal 100 determines whether an operation to select any of the UI screens displayed in S401 has occurred. If any of the UI screens is selected, the process proceeds to S404; otherwise, it proceeds to S403.

[0088] In S403, it is determined whether an operation to select any of the options displayed in the main menu area 510 has occurred. If an option displayed in the main menu area 510 is selected, the UI editor process ends and the process proceeds to the screen switching process described later in 112. Otherwise, the process returns to S402.

[0089] In S404, the developer terminal 100 displays the UI screen selected in S402 on the canvas 530 based on the definition information of the selected app recorded in the memory 102. If it is a UI screen on which UI components have been arranged in the past, the UI components arranged in the past are displayed on the canvas 530 according to the definition information. That is, if it is a UI screen that has been created halfway in the past, development can continue from where it left off. If the UI screen selected in S402 is a newly created UI screen, the canvas 530 is displayed in a blank state where no UI components are arranged. If the UI screen selected in S402 is a UI screen (template screen) prepared in advance as a template, even if the user has not arranged UI components on the UI screen in the past, prototype components with predefined actions defined are displayed at predetermined positions on the canvas 530.

[0090] In S405, the developer terminal 100 displays a list of UI components in the sub-menu area 520. That is, it switches from the list of UI screens of the selected app to the display of the UI component list. The UI components that can be arranged on the canvas 530 include INPUT, Button, Display, Navigation, Layout, and Chart as types, and a plurality of UI components are classified into each type. In the UI component list, first, as shown in FIG. 5(c), a list of UI component types is displayed, and in response to an operation of selecting any of the displayed types, the UI components classified into the selected type are expanded and displayed. FIG. 5(b) described above is an example in which the option 522 of the type corresponding to INPUT is selected and a list of UI components classified into INPUT is displayed. The UI components classified into INPUT include, for example, a text field 523 and a text area 524. The sub-menu area 520 is scrollable, and options that cannot be fully displayed (options of UI components of the expanded type or options of other types) can be scrolled and displayed. When the option 522 of the expanded type as shown in FIG. 5(b) is operated, the list of UI components of the expanded type is collapsed, and the list of UI component types is displayed.

[0091] In S406, the developer terminal 100 determines whether a UI component displayed in the sub-menu area 520 has been selected. More specifically, it determines whether an operation of dragging a UI component displayed in the sub-menu area 520 has been performed. If a UI component displayed in the sub-menu area 520 is selected, the process proceeds to S407; otherwise, it proceeds to S411.

[0092] In S407, the developer terminal 100 determines whether there has been an operation to specify a position on the canvas 530. More specifically, it determines whether an operation of dropping the dragged UI component onto the canvas 530 has been performed. If there has been an operation to specify a position on the canvas 530, the process proceeds to S408; otherwise, it waits for the position on the canvas 530 to be specified in S407. In this embodiment, an example of drag and drop is described, but the operation method is not limited to this as long as it is an operation for selecting a UI component from the sub-menu area 520 and placing it at a specified position on the canvas 530.

[0093] In S408, the developer terminal 100 determines whether the position on the canvas specified in S407 is included in the area of a tab component (a type of UI component) that has already been placed. If it is not included in the area of the tab component, the process proceeds to S409; if it is included in the area of the tab component, the process proceeds to S410. The tab component is, for example, the tab component 536 shown in FIG. 5(b). The tab component has a plurality of tabs (in the example of FIG. 5(b), three tabs labeled ITEM1, ITEM2, and ITEM3), and in response to any one of the tabs being selected, the display content displayed by the tab component is switched to the element screen corresponding to the selected tab.

[0094] The tab component will be described with reference to FIGS. 6(a) and 6(b). FIG. 6(a) is an example of the display on the display 105 when the tab component 601 is arranged on the canvas 530 that displays a UI screen different from that in FIG. 5(b). The range indicated by the operation bar 601a of the tab component 601 is the occupied area of the tab component 601. By operating the operation bar 601a, the entire display position and the entire display size of the tab component 601 including the element screen can be changed. The tab component 601 has three tabs: tab 610, tab 620, and tab 630. Each tab has a label that can be set by the developer in the property settings of the tab component, which is displayed as the tab name. In the illustrated example, they are displayed as Tab0, Tab1, and Tab2, respectively. The number and order of the tabs can be changed from the property settings of the tab component. The property settings of the tabs are performed by an operation of opening the tab property box from the context menu of the tab in S706 of the context menu process described later in FIG. 7, and by setting operations on the tab property box (settings screen) that is displayed accordingly. The element screen area 602 indicated by the dashed line (shown for explanation purposes and not actually displayed) is an area where the display content changes according to the selected tab. The display content corresponding to each tab displayed in the element screen area 602 is referred to as the element screen corresponding to each tab. Different UI components can be arranged on the element screen corresponding to each tab. The example in FIG. 6(a) is an example where tab 610 is selected and the element screen corresponding to tab 610 is displayed. In the illustrated example, UI component 611 and UI component 612 are arranged on the element screen corresponding to tab 610. The example in FIG. 6(b) is an example of the display when tab 620 is clicked and the selected tab is changed from tab 610 to tab 620 from the state in FIG. 6(a). In FIG. 6(b), the element screen corresponding to the selected tab 620 is displayed in the element screen area 602. In the illustrated example, UI component 621 is arranged on the element screen corresponding to tab 620. In the examples of FIGS. 6(a) and 6(b), at least the UI component ID (identification information of the UI component) of the tab component 601 and the position of the tab component 601 in the UI screen are recorded in the definition information in association with the ID of the UI screen being edited on the canvas 530 (identification information of the UI screen).Also, in association with the ID of the tab 610 of the tab component 601 (identification information of the element screen), the IDs of the UI components 611 and 612 and the respective positions of the UI components 611 and 612 in the element screen of the tab 610 are recorded. Also, in association with the ID of the tab 620 of the tab component 601, the ID of the UI component 621 and the position of the UI component 621 in the element screen of the tab 620 are recorded. Return to the description of FIG. 4.

[0095] In S409, the developer terminal 100 arranges the UI component selected in S406 from the sub-menu area 520 at a specified position on the canvas 530 with a default size, and records the information defining this in the definition information recorded in the memory 102. That is, in the definition information, the type of the UI component arranged in S410, the UI component ID, the arrangement coordinates, the arrangement size, etc. are associated with and recorded in the ID of the destination UI screen (the UI screen being edited).

[0096] In S410, the developer terminal 100 arranges the UI component selected in S406 from the sub-menu area 520 at a default size in the element screen corresponding to the selected tab among the tab components at the specified position on the canvas 530, and records the information defining this in the definition information recorded in the memory 102. That is, in the definition information, the type of the UI component arranged in S410, the ID of the tab component as the UI component ID, and the ID of the tab that was selected in that tab component, the arrangement coordinates and the arrangement size in the element screen corresponding to the selected tab are associated with and recorded in the ID of the destination UI screen (the UI screen being edited). By doing this, in this embodiment, it is possible to arrange and layout different UI components on each element screen corresponding to each tab of the tab component. Also, at this time, there is no need to perform a complicated operation to define the tab of the element screen where the UI component is to be arranged. Simply, when arranging the UI component to be arranged by drag and drop, the destination element screen may be selected and displayed.

[0097] In S411, the developer terminal 100 determines whether a UI component already placed on the canvas 530 has been selected by a click or the like. If the placed UI component has been clicked (selected), the process proceeds to S412; otherwise, the process proceeds to S415.

[0098] In S412, the developer terminal 100 displays an operation path for the UI component clicked in S411. Examples of the displayed operation path are the aforementioned operation path 531a and operation path 601a.

[0099] In S413, the developer terminal 100 determines whether the position specified by the click in S411 is within the area of the tab portion of the tab component. If it is not the tab portion, the process proceeds to S431; if it is the tab portion, the process proceeds to S414. The tab portion is an instruction area for instructing switching to the corresponding element screen.

[0100] In S414, the developer terminal 100 switches the display of the element screen area of the tab component to the element screen corresponding to the tab at the position specified by the click in S411. For example, in S411, if any of the positions of the three tabs displayed as ITEM1, ITEM2, and ITEM3 in the tab component 536 is clicked, an operation path is displayed for the tab component 536 in S412, and the display content of the element screen area 436a is switched to that of the element screen corresponding to the clicked tab. Also, for example, when displayed as in Fig. 6(a), if the tab 620 is specified, the display is switched to that of Fig. 6(b). That is, the UI components 611 and 612 arranged on the element screen displayed before the click become non-displayed, and instead, the UI component 621 arranged on the element screen corresponding to the clicked tab 620 is displayed. Such control is to simplify the operation of defining the element screen of the desired tab as the placement destination when the developer wants to place other UI components on the element screen of the desired tab of the tab component. When the developer wants to place other UI components on the element screen of the desired tab of the tab component, before dragging and dropping the UI component to be placed, the developer only needs to simply click the desired tab to display the desired element screen.

[0101] In addition, for the sake of simplifying the description in this embodiment, the processing of S409, S410, S413, and S414 has been described by taking the tab component as an example. However, the present invention is not limited to this. Even for components other than the tab component, after the construction of the application, if it is a predetermined type of UI component in which some display contents within the UI component are switched according to the operation on the UI component, the processing of S409, S410, S413, and S414 can be applied in the same manner as the tab component.

[0102] On the other hand, in the case of other UI components that are not of a predetermined type such as the tab component, the display contents within the UI component are not switched in response to the selection of the UI component on the canvas 530. What is performed in response to the selection of the UI component is only the processing related to the display of the operation path, and no other actions are taken. For example, when the button 532 is selected on the canvas 530 in FIG. 5(b), only the operation path is displayed, and the action of the button 532 (the processing executed when the button 532 is pressed in the constructed application) is not executed. Also, when the text field 533 is selected on the canvas 530, only the operation path is displayed, and no processing such as displaying a text input cursor within the text field 533 is performed.

[0103] Using FIGS. 6(c), 6(d), and 6(e), an example of an AppBar will be described as an example of a type of UI component to which the processes of S409, S410, S413, and S414 can be applied in the same manner as the tab component. FIG. 6(c) is an example of a case where an AppBar 650, a TextField 661, and a Button 662, which are UI components, are arranged on a canvas 530. The AppBar 650 is one UI component, and an element icon 651 and an element icon 652 are included in the AppBar 650. The element icon 651 is a display item that receives an instruction to display a drawer menu in the constructed application. The element icon 652 is a display item that receives an instruction to display a pop-up menu in the constructed application. Even when the positions of the element icon 651 and the element icon 652 in the arranged AppBar 650 on the canvas 530 are clicked, control is performed in the same manner as the tab portion of the tab component. More specifically, the control is as follows.

[0104] When the position of the element icon 651 in the arranged AppBar 650 is clicked (Yes in S411), an operation path for the AppBar 650 is displayed (S412), and when it is determined to be Yes in S413, a drawer menu as an element screen is displayed (S414). As a result, the display state transitions from the state shown in FIG. 6(c) to the state shown in FIG. 6(d). In FIG. 6(d), an operation path 650a for the AppBar 650 is displayed, and a drawer menu 651a, which is an element screen corresponding to the element icon 651, is displayed. The drawer menu 651a is a region that is displayed so as to be pulled out from the left end of the screen to the right side, and one or more menu items are displayed. With the drawer menu 651a displayed, by dragging another UI component from the sub-menu area 520 and dropping it onto the drawer menu 651a, another UI component can be arranged on the drawer menu 651a in the same manner as the processes described in S408 and S410 using the tab component as an example.

[0105] When the position of the element icon 652 among the configured AppBar 650 is clicked (Yes in S411), an operation path for the AppBar 650 is displayed (S412), and when it is determined to be Yes in S413, a pop-up menu as an element screen is displayed (S414). As a result, the display state changes from that in Fig. 6(c) to that in Fig. 6(e). In Fig. 6(e), an operation path 650a for the AppBar 650 is displayed, and a pop-up menu 652a which is an element screen corresponding to the element icon 652 is displayed. The pop-up menu 652a is an area displayed near the element icon 652, and one or more menu items (options) are displayed. With the pop-up menu 652a displayed, by dragging another UI component from the sub-menu area 520 and dropping it onto the pop-up menu 652a, similar to the processes described in S408 and S410 using the tab component as an example, another UI component can be arranged on the pop-up menu 652a. Return to the description of Fig. 4.

[0106] In S415, the developer terminal 100 determines whether there has been an operation of dragging a UI component already arranged on the canvas 530. If there has been an operation of dragging a UI component already arranged, the process proceeds to S416; otherwise, it proceeds to S417. In S416, the developer terminal 100 changes the position where the UI component (selected component) dragged in response to the drag operation is to be arranged. Specifically, it is arranged at the dropped position. When the arrangement is changed, the definition information recorded in the memory 102 is also updated to represent the changed position.

[0107] In S417, the developer terminal 100 determines whether there has been an operation on the operation path of a UI component already arranged on the canvas 530. If there has been an operation on the operation path, the process proceeds to S418; otherwise, it proceeds to S419. In S418, the developer terminal 100 changes the size of the UI component (selected component) with the operation path attached in response to the operation on the operation path. When the size is changed, the definition information recorded in the memory 102 is also updated to represent the changed size.

[0108] In S419, the developer terminal 100 determines whether there is an instruction operation (right click of the mouse in this embodiment) to display a context menu in any area of the canvas 530. If there is a right click, it proceeds to S420; otherwise, it proceeds to S421. In S420, a context menu (right click menu) is displayed according to the position of the mouse cursor when there is a right click, and context menu processing is performed to carry out processing according to the operation on the context menu. For example, when a right click is performed with the mouse cursor on the button 532 in FIG. 5(b), a context menu 540 regarding the button 532 (designated UI component) as shown in FIG. 5(d) is displayed. In the context menu 540, property 541, action 542, and delete 543 are displayed as selectable menu items. When property 541 is selected, a property box (detailed setting dialog) regarding the button 532 is displayed, and detailed settings such as the button name (label) to be displayed on the button 532, the color of the button 532, and the size in numerical specification can be made. When action 542 is selected, an action board regarding the button 532 is displayed, and an action can be input in JavaScript, which is a programming language, for the action board. The action input here is the processing to be executed when the button 532 (designated UI component) is pressed in the constructed application. When delete 543 is selected, the button 532 is deleted (removed) from the canvas 530. Details of the context menu processing will be described later with reference to FIG. 7.

[0109] In S421, the developer terminal 100 determines whether the save button 504 has been pressed. If the save button 504 has been pressed, it proceeds to S422; otherwise, it proceeds to S423. In S422, the developer terminal 100 transmits the definition information of the application being edited recorded in the memory 102 to the development environment 300. When receiving the definition information, the development environment 300 performs the save processing described later in FIG. 33(a) or FIG. 35(a).

[0110] In S423, the developer terminal 100 determines whether the preview button 505 has been pressed. If it is determined that the preview button 505 has been pressed, the process proceeds to S424; otherwise, it proceeds to S425. In S424, the developer terminal 100 performs preview processing. In the preview processing, the canvas 503 is made invisible, and based on the definition information recorded in the memory 102 or the definition information recorded in the development environment 300, a preview is displayed for the UI screen being edited on the canvas 503 so that it has the same appearance as when viewed in the constructed application. In the preview, the operation paths for operating the UI components are not displayed. Also, for some operations that are not executed on the UI editor screen (operations on the canvas 530), they are executed in the preview. For example, when operating on UI components for screen transition or link parts, the screen transition or transition to the link destination is executed. Also, operations such as moving the selection frame for an item by operating the tab key on the keyboard are executed. Note that operations such as actions input by the developer to the action boat and references to the database are not performed. Accordingly, the preview processing can be displayed faster than when actually deploying and checking.

[0111] In S425, the developer terminal 100 determines whether the deployment button 506 has been pressed. If the deployment button 506 has been pressed, the process proceeds to S426; otherwise, it proceeds to S427. In S426, the developer terminal 100 executes a deployment process. The deployment process will be described later with reference to FIG. 24(a). When the deployment button 506 is pressed to perform the deployment process, the developer does not need to perform an operation to select the execution environment for the deployment destination. Instead, it is pre-selected and the deployment is performed on the selected execution environment displayed in the selected execution environment box 501. Developers often work to collectively update the content to be deployed to a specific execution environment. Therefore, in this system, the execution environment for the deployment destination is selected before the selection of the application to be updated (S311 in FIG. 3), and the execution environment does not need to be selected each time the application is deployed. Therefore, it is possible to prevent operational errors such as accidentally deploying to an unintended execution environment and to improve work efficiency. Also, although an operation for authentication processing is performed when logging in to the development environment 300, there is no need to perform an operation for account authentication processing separately for the execution environment to be deployed. Therefore, it is possible to prevent an increase in the number of work steps and work efficiently. That is, the developer terminal 100 does not obtain authentication information regarding the execution environment for the deployment destination from the developer user.

[0112] In S427, the developer terminal 100 determines whether there has been an operation to change the currently selected execution environment. Specifically, it determines whether there has been an operation to change the currently selected execution environment with respect to the currently selected execution environment box 501. If there has been an operation to change the currently selected execution environment, the process proceeds to S428; otherwise, it proceeds to S429. In S428, the developer terminal 100 records the information (such as the execution environment ID) specifying the selected execution environment in the memory 102 as the "currently selected execution environment" and transmits it to the development environment 300. Also, the display content of the currently selected execution environment box 501 is updated to represent the changed currently selected execution environment. In the development environment 300, when receiving the information specifying the currently selected execution environment, based on it, the currently selected execution environment is recorded in the configuration management file stored in the area for the logged-in developer in the storage 320.

[0113] In S429, the developer terminal 100 determines whether there has been an operation to change the application to be edited. Specifically, it determines whether there has been an operation to change the currently selected application with respect to the currently selected application box 502. If there has been an operation to change the currently selected application, the process proceeds to S317 in FIG. 3, and the processing after S317 is executed based on the changed currently selected application. That is, the display content of the sub-menu area 520 and the canvas 530 is updated. If there has been no operation to change the currently selected application, the process proceeds to S430.

[0114] In S430, the developer terminal 100 determines whether there has been an operation to change the UI screen to be edited. Specifically, it determines whether there has been an operation to change the currently selected UI screen with respect to the currently selected UI screen box 503. If there has been an operation to change the currently selected UI screen, the process proceeds to S404, and the processing is performed based on the changed currently selected UI screen. That is, the display content of the canvas 530 is updated (switched) to the content of the changed currently selected UI screen. If there has been no operation to change the currently selected UI screen, the process proceeds to S431.

[0115] In S431, the developer's terminal 100 determines whether there is an operation to select any of the options displayed in the main menu area 510. If an option displayed in the main menu area 510 is selected, the UI editor process ends, and the process proceeds to the screen switching process described later with reference to FIG. 12. Otherwise, the process returns to S406.

[0116] <Context menu process> FIG. 7 shows a flowchart of the context menu process. This process is the detailed flowchart of S420 in FIG. 4.

[0117] In S701, the developer's terminal 100 determines whether the context menu to be displayed is related to a UI component of the Button type. More specifically, it determines whether the type of the UI component (designated UI component) specified by the mouse when a right click was received in S419 is a button. If it is a button, the process proceeds to S710; otherwise, the process proceeds to S702.

[0118] In S702, the developer's terminal 100 determines whether the context menu to be displayed is related to the canvas. More specifically, it determines whether the position specified by the mouse when a right click was received in S419 is a blank area of the canvas 530 where no UI component is arranged. If it is a blank area (if the context menu to be displayed is related to the canvas), the process proceeds to S703; otherwise, the process proceeds to S704.

[0119] In S703, the developer's terminal 100 performs the context menu process for the canvas. The context menu process for the canvas will be described later with reference to FIG. 19.

[0120] In S704, the developer terminal 100 determines whether the context menu to be displayed is related to a UI component of the data grid (table) type. More specifically, it determines whether the type of the UI component (designated UI component) specified by the mouse when a right click was received in S419 is a data grid. If it is a data grid, the process proceeds to S705; otherwise, it proceeds to S706.

[0121] In S705, the developer terminal 100 performs context menu processing for the data grid. The context menu processing for the data grid will be described later with reference to FIG. 30.

[0122] In S706, as other processing, the developer terminal 100 displays a context menu for the designated target corresponding to the designated position and performs processing according to the operation. Details are omitted.

[0123] In S710, the developer terminal 100 determines whether the UI screen to be edited (selected UI screen) is a template screen. If it is a template screen, the process proceeds to S721; otherwise, it proceeds to S711.

[0124] In S711, as the context menu for the designated UI component, the developer terminal 100 superimposes and displays the context menu for the button shown in FIG. 5(d) in the vicinity of the designated position (mouse cursor position).

[0125] In S712, the developer terminal 100 determines whether the property (property 541 in FIG. 5(d)) among the options included in the context menu has been selected. If the property has been selected, the process proceeds to S713; otherwise, it proceeds to S714.

[0126] In S713, the developer terminal 100 overlays and displays a property box for buttons as a property box (detailed settings dialog) for the specified UI component on the canvas 530. Then, it accepts various setting operations on the property box. Here, for example, detailed settings such as the button name (label) to be displayed on the button, which is the specified UI component, the color of the button, and the size in numerical specification can be performed. When a setting is made and a reflection operation is performed, on the canvas 530, the specified UI component is displayed in a display form reflecting the setting.

[0127] In S714, the developer terminal 100 determines whether an action (property 542 in FIG. 5(d)) among the options included in the context menu is selected. If an action is selected, it proceeds to S715; otherwise, it proceeds to S716.

[0128] In S715, the developer terminal 100 performs action board processing for the button, which is the specified UI component. The action board processing will be described later with reference to FIG. 8.

[0129] In S716, the developer terminal 100 determines whether deletion (deletion 543 in FIG. 5(d)) among the options included in the context menu is selected. If deletion is selected, it proceeds to S717; otherwise, it proceeds to S718.

[0130] In S717, the developer terminal 100 deletes the specified UI component and deletes the information related to the specified UI component (definitions such as position and size, properties and actions, etc.) among the definition information recorded in the memory 102. As a result, on the canvas 530, the specified UI component is deleted (removed) and becomes non-displayed.

[0131] In S718, the developer terminal 100 determines whether another option among the options included in the context menu is selected. If another option is selected, it proceeds to S719 and performs processing according to the selected option. Otherwise, it proceeds to S720.

[0132] In S720, the developer's terminal 100 determines whether there is an operation to close the context menu (for example, an operation of clicking outside the area where the context menu is displayed). If there is an operation to close the context menu, the context menu is made invisible and the process of FIG. 7 ends. If there is no closing operation, the process returns to S712.

[0133] On the other hand, in S721, the developer's terminal 100 superimposes and displays, as a context menu for the specified UI component, the context menu for the template screen and for the button shown in FIG. 26(d) in the vicinity of the specified position (mouse cursor position). In the context menu for the template screen (the prototype component 2634 in FIG. 26(d)), unlike the context menu for the normal UI screen (the context menu 540 shown in FIG. 5(d)), actions and deletions are not displayed as options, and only properties are displayed. That is, for the UI components arranged on the template screen among the UI screens, the developer is prevented from setting the actions when the UI components are operated. The reason for this will be described later.

[0134] In S722, the developer's terminal 100 determines whether a property has been selected among the options included in the context menu. If a property has been selected, the process proceeds to S723; otherwise, the process proceeds to S724. The process of S723 is the same as that of S713.

[0135] In S724, the developer's terminal 100 determines whether there is an operation to close the context menu (for example, an operation of clicking outside the area where the context menu is displayed). If there is an operation to close the context menu, the context menu is made invisible and the process of FIG. 7 ends. If there is no closing operation, the process returns to S722.

[0136] <Action Board Processing> The processing related to the action board will be described. When an action is selected from the context menu by specifying a UI component placed on the canvas, an action board for setting an action related to the specified UI component is displayed. For example, consider the case where a UI screen as shown in Fig. 9(a) is being edited. Fig. 9(a) is a diagram showing a part of the UI editor screen on the display 105. In Fig. 9(a), a list of UI components is displayed in the sub-menu area 520, and the UI screen to be edited is displayed on the canvas 900. On the canvas 900, a UI component 901 which is a button and other UI components are arranged. When the UI component 901 is specified and an action option is selected from the context menu, an action board as shown in Fig. 9(b) is displayed.

[0137] Fig. 9(b) is an example of the display of the action board related to the UI component 901. The action board 910 is displayed in the area where the canvas 900 was displayed, replacing the canvas. If it is not a prototype component (prototype component) pre-arranged on the template screen and the developer has not set an action for the specified UI component in the past, the action board 910 is displayed blank as shown in Fig. 9(b). Note that the "1" displayed on the action board 910 is a guide display indicating the number of lines and is not the content of the action. The developer can set an arbitrary action on this action board 910 by operating the keyboard included in the operation unit 106 and inputting an arbitrary character string in JavaScript which is a programming language. The trigger for executing the content set on the action board is predetermined and is that the specified UI component is operated. Therefore, the developer does not need to set what the trigger for executing the action is (does not need to be described in JavaScript). For example, when the specified UI component is a button, in the built application, the fact that the button is pressed is the trigger, and in response to the occurrence of the trigger, the action set on the action board of the button is executed.

[0138] Also, together with the action board 910, in the sub-menu area, instead of the UI component list or the UI screen list as shown in FIG. 9(a) displayed on the UI editor screen, a function list 920 is displayed. The function list 920 displays an option 922 for instructing the display of the action board 910 and options for functions for instructing the display of each function. Note that functions created (added) by the developer (user) by pressing the function addition button 921 described later, rather than pre-prepared functions, are referred to as creative functions (created functions, added functions, self-made functions). If there are no automatically created functions or pre-prepared functions and the developer has not created a creative function for the specified UI component in the past, as shown in FIG. 9(b), no function options are displayed in the function list 920, and only the option 922 and the function addition button 921 are displayed.

[0139] When the function addition button 921 is pressed, a dialog box for adding a creative function (referred to as the addition dialog 930) is displayed. FIG. 9(c) shows an example of the display of the addition dialog 930. The addition dialog 930 displays a type selection field 931 for accepting the selection of the function type, a function name input field 932 for accepting the input of the function name, and a SAVE button 933. When an input is made to the addition dialog and the SAVE button 933 is pressed, a function setting screen corresponding to the type selected in the type selection field 931 is displayed, and the function name entered in the function name input field 932 is additionally displayed in the function list 920.

[0140] FIG. 9(d) is a display example of a REST function setting screen that is displayed when REST is selected in the type selection field 931. Instead of the action board 910, a REST function setting screen 940 for receiving various settings necessary for creating a function (REST function) using REST (Representational State Transfer) is displayed. Also, in the function list 920, as a function option, a function 923 with the function name "rest01" entered in the function name input field 932 is displayed. Note that the icon displayed before "rest01" indicates that the type of the function 923 is a REST function. When not all required setting items are set in the function setting screen (when there is insufficient information to be set), an incomplete mark 929 indicating that the function is incomplete is displayed, and it is displayed in an identifiable manner that the corresponding function 923 is in an incomplete state.

[0141] In the REST function setting screen 940 of FIG. 9(d), setting columns 941 to 944 are displayed. The setting column 941 is a setting screen for the function name, and in the initial state, the function name entered in the function name input field 932 is displayed, but it can be changed according to an input operation by the developer. The setting column 942 is a setting column for setting the variable name for setting arguments (parameters). In this embodiment, param is set by default and cannot be changed. It is displayed in a grayed-out state to indicate that it cannot be changed. The setting column 943 is a setting column for setting the type of the REST function. By operating the triangular icon at the right end of this area, GET, POST, PUT, and DELETE are displayed as options in a pull-down menu, and any option can be selected and set. The type set here is the type of request that this function makes. The setting column 944 is a setting column for the URL to which the request made by this function is sent. Thus, when creating a REST function on the REST function setting screen 940, the developer does not need to describe a source code string in a programming language.

[0142] FIG. 10(a) to (d) further show display examples of the creation function setting screen and the action board. In FIG. 10, the same components as those in FIG. 9 are denoted by the same reference numerals as in FIG. 10, and the description thereof is omitted.

[0143] FIG. 10(a) is a display example of an SQL function setting screen displayed when SQL is selected in the type selection column 931. Instead of the action board 910, an SQL function setting screen 950 for receiving various settings necessary for creating a function using SQL (Structured Query Language) (SQL function) is displayed. Further, in the function list 920, as a function option, a function 924 with the function name "sql01" entered in the function name input column 932 is displayed together with an incomplete mark 929. Note that the icon displayed before "sql01" indicates that the type of the function 924 is an SQL function. The setting column 951 is a setting screen for the function name, and in the initial state, the function name entered in the function name input column 932 is displayed, but it can be changed according to an input operation by the developer. The setting column 952 is a setting column for setting a variable name for setting arguments (parameters). In the present embodiment, param is set as the default and cannot be changed. It is displayed in gray to indicate that it cannot be changed. The setting column 953 is for inputting a character string (SQL statement, SQL statement) for instructing the database in SQL, which is a type of computer language (a database language, not a programming language). The developer can input an arbitrary SQL statement into the setting column 953 from a keyboard or the like included in the operation unit 106. Thus, when creating an SQL function on the SQL function setting screen 950, the developer does not need to describe the source code string in a programming language.

[0144] Figure 10(b) shows an example of the display at the stage when the developer inputs (describes) code (string) in JavaScript to some extent on the action board 910 after creating functions 923 to 925 which are creative functions, and then inputs "sq". In this embodiment, when the developer user inputs a string, if the input string matches the function name (identification information) of the already created creative function at the beginning, the function name that matches at the beginning is displayed in the code assist column 911 as an option for input candidates. In the illustrated example, since the input "sq" matches the function name "sql01" of function 924 which is an already created creative function, "sql01" is displayed as an option. When the user performs an operation to select "sql01" displayed in the code assist column 911, as shown in Figure 10(c), "sql01" is input to the action board 910 without performing the operation of inputting "l01". With this code assist function, the developer (user) can input the function name (identification information) of the creative function without typing all the characters of the function name of the creative function on the keyboard, contributing to the reduction of the operation steps. Also, if it matches the function name of the already created creative function at the beginning, the full name is displayed in the code assist column 911, and if it does not match (that is, if there is no function starting with that string), the code assist column 911 is not displayed. Therefore, the developer can confirm that it is not incorrect as the function name of the creative function he / she has created and then input it, preventing input mistakes of the function name. In addition, when there are multiple creative functions that match at the beginning, multiple options are displayed in the code assist column 911. Also, the function name of the creative function displayed in the code assist column 911 is a function created for the specified UI part (UI part 901 in the illustrated example) targeted by the action board 910, and the creative functions created for other UI parts are not displayed. Therefore, it is also possible to prevent the mistake of accidentally describing in the action board 910 the function name that is the function name of the creative function created for other UI parts and does not exist as the creative function of the specified UI part.

[0145] Also, as shown in FIG. 10(c), together with the action board 910, in the function list 920, for each of the functions 923 to 925 of the creative functions created by the developer, the type of the function (the icon before the character string) and the name of the function are displayed. Therefore, the developer user can confirm what type of what name of creative function has been created while inputting (describing) the action code (character string in JavaScript) to the action board 910. Therefore, it is possible to reduce the labor (for example, the labor of taking notes by hand, opening another screen to check, etc.) for confirming and managing valid creative functions that can be described on the action board 910. It also contributes to preventing input mistakes in the function name. The functions displayed in the function list 920 are functions created for the designated UI component (UI component 901 in the illustrated example) targeted by the action board 910, and creative functions created for other UI components are not displayed. Therefore, it is also possible to prevent the mistake of describing, on the action board 910, a function name that is the function name of a creative function created for another UI component by mistake and does not exist as a creative function for the designated UI component. Also, the creative function is valid only when defining the action of the designated UI component and does not affect the definition of the action of other UI components. Therefore, when the function name of the creative function created for the designated UI component is the same as the function name of the creative function created for another UI component, even if the function name is described on the action board 910, only the function setting set for the designated UI component is reflected, and the function setting set for other UI components is not reflected. Therefore, even if the same function name as the function name of the creative function already created for another UI component is used, it does not result in an error. Therefore, the user can determine the function name of the creative function without worrying about duplication of the function name with the creative function already created for another UI component and input it to the action board 910. That is, although a large number of creative functions will be created in the overall development of the application, they are automatically managed and organized in association with the designated UI component and are displayed in the code assist bar 911 and the function list 920, so it becomes very easy for the developer to manage a large number of creative functions. Therefore, the labor and time related to confirming the function name can be reduced.In addition, it is possible to suppress input errors in function names. Therefore, it is also possible to suppress the debugging work (bug-fixing work) when an input error in the function name is made. Thus, the load and man-hours required for software development (application development) can be reduced, and more efficient software development (application development) can be performed.

[0146] FIG. 10(d) is a display example when the action code has been input in a programming language on the action board 910. In the illustrated example, the creative function "rest01" (function 923 in the function list 920) is used in the portion indicated by the dotted line 960 in the third line. In the code string shown on the action board 910 of FIG. 10(d), the details of the creative function rest01 are not defined. Also, when the developer sets rest01 on the REST function setting screen 940, the details of rest01 in the programming language are not defined. When the definition information including the definition of the action in this state is uploaded and saved to the development environment 300, the development environment 300, in the save process of FIG. 33(a) or FIG. 35(a) described later, as an execution environment program, based on the function setting content and the character string described on the action board 910 from the uploaded definition information, creates a source code in a programming language including the definition of the function in the programming language. In this way, when the development environment 300 acquires a character string including the identification information (function name) of the creative function described in the programming language, it performs control to make the function (action) indicated by the character string (action described on the action board) including the function of the creative function executable based on the information set on the function setting screen.

[0147] FIG. 11 shows an example of source code in a programming language generated by the development environment 300 based on the character string described in the action board 910 of FIG. 10(d) and the setting content of rest01 set on the REST function setting screen 940. In the illustrated example, the numbers 1 to 75 described at the left end are shown for indicating the line numbers and are not part of the source code. The example of FIG. 11 is 75 lines of source code including the detailed definition of rest01 in the programming language. However, the developer himself / herself does not need to input 75 lines. By making settings on the REST function setting screen 940 and describing the character string of the component (7 lines) illustrated in the action board 910 of FIG. 10(d), the content of the source code shown in FIG. 11 can be defined. That is, low-code and efficient development can be performed.

[0148] FIG. 8 shows a flowchart of the action board process. This process is the detailed flowchart of the action board process described above in S715 of FIG. 7, and is a process for controlling so as to perform the operations described using the display examples of FIGS. 9(b) to (d) and FIGS. 10(a) to (d).

[0149] In S801, the developer terminal 100 displays an action board on the display 105. If no action is defined for the specified UI component, a screen including the blank action board 910 as described in FIG. 9(b) is displayed. If an action has already been defined for the specified UI component, a screen including the action board 910 with the action character string input as described in FIG. 10(d) is displayed.

[0150] In S802, the developer terminal 100 determines whether there is an operation (description operation) for describing an action on the action board 910. The operation for describing an action is, for example, a text input operation performed by operating the keyboard included in the operation unit 106 in a state where the action board 910 is selected, or by touching the soft keyboard displayed on the touch panel. If there is an operation for describing an action, the process proceeds to S803; otherwise, the process proceeds to S810.

[0151] In S803, the developer terminal 100 receives an input operation of an action by an operation for describing the action, and displays the input characters on the action board 910.

[0152] In S804, the developer terminal 100 determines whether a character string formed by the characters input in S803 and the characters input before that matches (i.e., partially matches) the function name of the creation function. If there is a forward match, the process proceeds to S805; otherwise, it proceeds to S808.

[0153] In S805, the developer terminal 100 displays the function name of the creation function determined to match in S804 as an option in the code assist field. As a result, the code assist field 911 is displayed as described in FIG. 10(b). Note that in the code assist field 911, not only creation functions but also function names generally available in programming languages that match the input character string may be displayed.

[0154] In S806, the developer terminal 100 determines whether any of the options displayed in the code assist field has been selected. If any of the options is selected, the process proceeds to S807, and the function name of the selected option is displayed in the code assist field 911. For example, in response to the option in the code assist field 911 being selected from the state of FIG. 10(b), as shown in the fifth line of the action board 910, "sql01" is input and displayed. If none of the options is selected, the process proceeds to S808.

[0155] In S808, the developer terminal 100 determines whether an operation for describing an action is continuously performed. If an operation for describing an action is continuously performed, the process proceeds to S803; otherwise, it proceeds to S802.

[0156] In S810, the developer terminal 100 determines whether an operation to instruct adding a function has been performed. Specifically, it determines whether the function addition button 921 has been pressed. If the function addition button 921 has been pressed, it proceeds to S811; otherwise, it proceeds to S820.

[0157] In S811, the developer terminal 100 displays an additional dialog 930 for adding a creation function and accepts input for the additional dialog 930. The content accepted as input in the additional dialog is as described above with reference to FIG. 9(c). When input to the additional dialog is performed and the SAVE button 933 is pressed, it proceeds to S812.

[0158] In S812, the developer terminal 100 adds the function name entered in the function name input field 932 of the additional dialog to the function list 920 in the sub-menu area and displays it with an incomplete mark 929 attached.

[0159] In S813, the developer terminal 100 determines whether the type selected in the type selection field 931 of the additional dialog is a script. If it is a script, it proceeds to S814; otherwise, it proceeds to S815. In S814, the developer terminal 100 displays a script function setting screen (not shown) and accepts a setting operation from the developer user.

[0160] In S815, the developer terminal 100 determines whether the type selected in the type selection field 931 of the additional dialog is SQL. If it is SQL, it proceeds to S816; otherwise (i.e., when the type selected in the type selection field 931 of the additional dialog is REST), it proceeds to S817. In S816, the developer terminal 100 displays an SQL function setting screen and accepts a setting operation from the developer user. The setting content accepted in the SQL function setting screen is as described above with reference to FIG. 10(a).

[0161] In S817, the developer terminal 100 displays a REST function setting screen and accepts setting operations from the developer user. The setting contents accepted on the REST function setting screen are as described above with reference to FIG. 9(d).

[0162] In S818, the developer terminal 100 determines whether the input to the preset setting items as mandatory items has been completed (whether the settings have been completed) on the function setting screen for each type. If the input to the mandatory items has been completed, the process proceeds to S819; otherwise, it proceeds to S802.

[0163] In S819, the developer terminal 100 makes the incomplete mark that was displayed in association with the function name shown in the function list 920 for the creative function being set disappear. As a result, the user (developer) can recognize that the creative function being set is in a valid set state that can be used on the action board 910.

[0164] In S820, the developer terminal 100 determines whether any of the creative functions displayed in the function list 920 has been selected (pressed). If a creative function is selected in the function list 920, the process proceeds to S813, and in any of S814, S816, and S817, a setting screen corresponding to the type of the selected creative function is displayed reflecting the already set contents. The user (developer) can change or add settings to the setting screen (that is, can edit the creative function).

[0165] In S821, the developer terminal 100 determines whether there has been an instruction operation to save (for example, pressing the save button 915). If there has been an instruction operation to save, the process proceeds to S822; otherwise, it proceeds to S823.

[0166] In S822, the developer terminal 100 records the contents performed in the action board process so far in the definition information held in the memory 102 and transmits it to the development environment 300.

[0167] In S823, the developer's terminal 100 determines whether or not an option 922 for instructing the display of the action board 910, which is displayed in the function list 920, has been pressed. If the option 922 has been pressed, the process proceeds to S801 to display the action board of the specified UI component. As a result, when the function setting screen is being displayed, the display switches to the display of the action board. If the option 922 has not been pressed, the process proceeds to S824.

[0168] In S824, the developer's terminal 100 determines whether or not there has been an operation to close the action board (an operation to end the action board process). If there has been no operation to close the action board, the process proceeds to S802 to repeat the process. If there has been an operation to close the action board, the action board is made non-displayed, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor process.

[0169] <Screen switching process> Fig. 12 shows a flowchart of the screen switching process. This process is a process corresponding to the selection of an option displayed in the main menu area 510 described above in the display example of Fig. 5(b).

[0170] In S1201, the developer's terminal 100 determines whether or not the app list button 511 has been pressed. If the app list button 511 has been pressed, the process proceeds to S315 in Fig. 3; otherwise, the process proceeds to S1202.

[0171] In S1202, the developer's terminal 100 determines whether or not the UI screen button 512 has been pressed. If the UI screen button 512 has been pressed, the process proceeds to S1203; otherwise, the process proceeds to S1204. In S1203, the UI editor process in Fig. 4 is performed.

[0172] In S1204, the developer's terminal 100 determines whether or not the workflow button 513 has been pressed. If it is determined that the workflow button 513 has been pressed, the process proceeds to S1205; otherwise, the process proceeds to S1206.

[0173] In S1205, the developer terminal 100 performs a workflow creation process. The workflow creation process will be described later with reference to FIG. 16.

[0174] In S1206, the developer terminal 100 determines whether the setting button 514 has been pressed. If the setting button 514 has been pressed, the process proceeds to S1207; otherwise, it proceeds to S1209.

[0175] In S1207, the developer terminal 100 displays an app settings screen. The app settings screen is a screen for receiving setting operations related to the selected app. In S1208, the developer terminal 100 receives a setting operation on the app settings screen and updates the definition information recorded in the memory 102 based on the setting. Settings that can be received in S1208 include, for example, a setting for the display language and a setting for whether to build an app that can be used as a PWA (Progressive Web Apps). Also, among the multiple UI screens belonging to the app, there is a setting for which UI screen is to be the initial UI. The initial UI is the screen that is first displayed when accessing the built app deployed in the execution environment, or the screen that is first displayed after authentication is successful on the app's authentication screen after accessing the built app.

[0176] In S1209, the developer terminal 100 determines whether the environment list button 515 has been pressed. If the environment list button 515 has been pressed, the process proceeds to S311 in FIG. 3; otherwise, it proceeds to S1210.

[0177] In S1210, the developer terminal 100 determines whether the database button 516 has been pressed. If the database button 516 has been pressed, the process proceeds to S1211; otherwise, it proceeds to S1215. Pressing the database button 516 is a request to connect to the database.

[0178] In S1211, the developer terminal 100 determines whether the currently selected execution environment is the multi-tenant execution environment 410. If it is the multi-tenant execution environment 410, the process proceeds to S1213; otherwise (if it is a single-tenant execution environment), the process proceeds to S1212.

[0179] In S1212, the developer terminal 100 acquires the database information that the development environment 300 has obtained from the currently selected execution environment. More specifically, the development environment 300 determines whether the currently selected execution environment is a multi-tenant execution environment or a single-tenant execution environment. If it is a single-tenant execution environment, the development environment 300 accesses the DB set (any one of DB sets 457, 467, 477, etc.) of the single-tenant execution environment that is the currently selected execution environment, and acquires the content recorded in the database. Then, the development environment 300 transmits the database information obtained from the currently selected execution environment to the developer terminal 100. The developer terminal 100 does not access the single-tenant execution environment without going through the development environment 300.

[0180] In S1213, the developer terminal 100 refers to the DB instance name recorded in the developer information of the logged-in developer (the information registered for the logged-in developer among the developer information 301). Then, the developer terminal 100 acquires the content recorded in the database of the DB instance indicated by the DB instance name obtained by referring to the developer information of the logged-in developer from among the DB sets 430 included in the multi-tenant execution environment 410 that is the currently selected execution environment. Then, the development environment 300 transmits the database information obtained from the currently selected execution environment to the developer terminal 100. The developer terminal 100 does not access the multi-tenant execution environment 410 without going through the development environment 300.

[0181] In S1214, the developer terminal 100 displays the database management screen and displays the database information acquired in S1212 or S1213. Then, the developer terminal 100 accepts DB management operations for performing various settings related to the database of the currently selected execution environment and instructions for updating the content.

[0182] In S1215, the developer terminal 100 determines whether the file manager button 517 has been pressed. If the file manager button 517 has been pressed, the process proceeds to S1216; otherwise, it proceeds to S1218.

[0183] In S1216, the developer terminal 100 displays a file management screen for managing the files to be saved in the selected execution environment, and in S1217, it accepts operations for managing the files to be saved in the selected execution environment. For example, an image file to be displayed on the screen of the constructed application can be uploaded and saved in the developer area of the selected execution environment. When a file to be saved in the selected execution environment is selected from the local storage area (such as the recording medium 108) of the developer terminal 100 and a save instruction is given, the developer terminal 100 transmits the selected file to the development environment 300. When the development environment 300 receives the selected file, it transmits it to the developer area of the selected execution environment to save it in the selected execution environment. Each execution environment only accepts access from the development environment 300. Therefore, for file management, access is made to various execution environments from the developer terminal 100 via the development environment 300. The developer terminal 100 does not access the multi-tenant execution environment 410 without going through the development environment 300. As described in the above login process, the developer needs to authenticate and log in to the development environment 300. Therefore, by making it impossible to access various executions without going through the development environment 300, other users who cannot log in to the development environment 300 cannot illegally access the execution environment, improving security accordingly.

[0184] Also, the developer user only needs to perform the operations required for authentication to log in to the development environment 300, and does not need to perform the operations required for authentication to log in for each execution environment. Therefore, an increase in the number of operation steps can be suppressed.

[0185] In S1218, the developer terminal 100 determines whether the user management button 518 has been pressed. If it is determined that the user management button 518 has been pressed, the process proceeds to S1219; otherwise, it proceeds to S1220.

[0186] In S1219, the developer terminal 100 performs user information display processing. The user information display processing is a process of displaying user information (user information 411, 451, 461, 471, etc. in each execution environment shown in FIG. 1), which is information of application users (information managed separately from developers) who can log in to the application constructed in the selected execution environment, and accepting management operations from the developer. The user information display processing will be described later with reference to FIG. 14.

[0187] In S1220, the developer terminal 100 determines whether the snapshot button 519 has been pressed. If the snapshot button 519 has been pressed, the process proceeds to S1221 to perform snapshot processing; otherwise, it proceeds to S1222.

[0188] In S1222, the developer terminal 100 determines whether an end operation has been performed. If no end operation has been performed, the process proceeds to S1201 to repeat the processing; if there has been an end operation, the screen switching processing ends.

[0189] <User Information Display Processing> Fig. 14(a) shows a specific example of the developer information 301 held in the development environment 300. In the developer information 301, as shown in each row of the figure, the following information is recorded in association with each developer as account information for each developer. The email address (username) that serves as the developer's account ID (developer ID), password, surname, given name, accessible execution environment ID, Verify, and the name of the accessible DB instance in the multi-tenant execution environment. The accessible execution environment ID shall be the account ID of the cloud service in this embodiment. When one developer can access multiple execution environments, the accessible execution environment ID records a string in which multiple execution environment IDs are continuously listed separated by commas. Verify is information indicating whether the account is valid. Note that the information recorded in association with one account may be other than the information shown in Fig. 14(a).

[0190] Fig. 14(b) shows a specific example of the user information 411 held in the multi-tenant execution environment 410. In the user information 411, as shown in each row of the figure, the following information is recorded in association with each app user as account information for each app user. The account information for each app user includes the email address (username) that serves as the app user's account ID, password, surname, given name, information on whether the email has been approved, and the owner ID. In the multi-tenant execution environment, multiple applications owned by multiple developers are deployed in a mixed manner. Therefore, in order to identify which developer (owner)'s app each app user is a user of, the developer ID is also recorded as the owner ID. Note that the information recorded in association with one account may be other than the information shown in Fig. 14(b). For example, the generation date and time, update date and time, etc. may be recorded.

[0191] FIG. 14(c) shows specific examples of user information (such as user information 451, 461, 471, etc.) held in a single-tenant execution environment. The user information in the single-tenant execution environment records two types of information: user-specific information shown in FIG. 14(c1) and group information shown in FIG. 14(c2).

[0192] As shown in FIG. 14(c1), for the user-specific information, the following information is recorded in association with each application user as account information for each row in the figure. The account information for each application user includes the email address (username) that serves as the account ID of the application user, the password, the surname, the given name, and information on whether the email has been approved. On the other hand, in the single-tenant execution environment, since there are no multiple applications owned by multiple developers mixed together, the owner ID is not recorded. Note that the information recorded in association with one account may be other than the information shown in FIG. 14(c1). For example, the generation date and time, the update date and time, etc. may be recorded.

[0193] As shown in FIG. 14(c2), for the group information, for each of the multiple group IDs, the usernames of one or more belonging users are recorded in association as shown in each row in the figure.

[0194] FIG. 13(a) shows a flowchart of user information display processing on the developer terminal 100. This processing is the detailed flowchart of S1218 in FIG. 12 described above.

[0195] In S130, the developer terminal 100 transmits a user information acquisition instruction for the development environment 300 (information instructing the acquisition of user information in the selected execution environment).

[0196] In S1302, the developer terminal 100 determines whether it has received user information that is the information corresponding to the user information acquisition instruction transmitted in S1301 and is transmitted from the development environment 300. If the user information has not been received, it waits for the reception of the user information in S1302, and if the user information has been received, it proceeds to S1303. The user information to be acquired is the information as shown in FIG. 14(b) if the selected execution environment is a multi-tenant execution environment, and is the information as shown in FIGS. 14(c1) and 14(c2) if the selected execution environment is a single-tenant execution environment.

[0197] In S1303, the developer terminal 100 displays the user information on the display 105 based on the user information received in S1302. FIG. 15 shows an example of the display of user information on the developer terminal 100, which is displayed in S1303. In FIG. 15, the same reference numerals are given to the same display items as those in the display example of FIG. 5(b) described above, and the description thereof is omitted. The display item 1501 is an instruction item for instructing a display based on the user-specific information shown in FIG. 14(c1). The display item 1502 is an instruction item for instructing a display based on the group information shown in FIG. 14(c2). Either of the display items 1501 and 1502 can be switched and selected. Also, when the execution environment during selection is a multi-tenant execution environment, the display items 1501 and 1502 are not displayed, and it is not possible to switch to the display of group information. The group information 1505 is the user information received in S1302 (in the illustrated example, it is an example of displaying user information based on the user-specific information shown in FIG. 14(c1). In the group information 1505, the columns of Username and Email Verified respectively correspond to the information of the columns of the email address (username) and whether the email is approved or not in the user-specific information shown in FIG. 14(c1). In the Delete column, a button icon for receiving an instruction to delete the user account of each row is displayed. The user addition button 1503 is an operation icon for instructing the registration of information of a new application user by adding one row to the group information 1505. The save button 1504 is an operation icon for instructing to save the group information 1505 with the content edited on the screen of FIG. 15 to the execution environment during selection.

[0198] In S1304, the developer terminal 100 accepts an editing operation of the user information displayed in S1303. For example, it includes adding a user account by pressing the user addition button 1503, deleting the user account by pressing the button icon displayed in the Delete column, and editing the content of the editable items by operating the keyboard.

[0199] In S1305, the developer terminal 100 determines whether the save button 1504 has been pressed. If the save button 1504 has been pressed, the process proceeds to S1306; otherwise, it proceeds to S1307.

[0200] In S1306, the developer terminal 100 sends an update instruction for user information to the development environment 300 with the content reflecting the editing operation received in S1304.

[0201] In S1307, the developer terminal 100 determines whether there has been an execution environment change operation. If there has been an execution environment change operation (i.e., an operation on the selected execution environment box 501), the process proceeds to S1308; otherwise, it proceeds to S1309.

[0202] In S1308, the developer terminal 100 records the changed selected execution environment in the memory 102 and sends it to the development environment 300. Since the user information to be displayed changes when the selected execution environment changes, the process returns to S1301 to perform the processing again.

[0203] In S1309, the developer terminal 100 determines whether there has been a screen switching operation, which is an operation of selecting any option displayed in the main menu area 510. If there is no screen switching operation, the process returns to S1304; if there is a screen switching operation, the user information display process ends and the process proceeds to the aforementioned screen switching process.

[0204] Figure 13(b) shows a flowchart of the user information acquisition process in the development environment 300, which is a process in response to the user information display process in Figure 13(a).

[0205] In S1311, the development environment 300 determines whether it has received the user information acquisition instruction sent from the developer terminal 100 in S1301. If it has received the user information acquisition instruction, the process proceeds to S1312; otherwise, it proceeds to S1316.

[0206] In S1312, the development environment 300 acquires access destination information (connection destination information) from the selected execution environment. The access destination information acquired here is access destination information 421 if the selected execution environment is the multi-tenant execution environment 410 in FIG. 1, and among access destination information 456b, 466b, 476b... etc., it is the one of the selected execution environment if the selected execution environment is the single-tenant execution environment in FIG. 1. More specifically, as the selected execution environment, the development environment 300 acquires the execution environment ID of the selected execution environment (specific environment) from the account information of the developer who is logged in among the developer information 301 and stores it in the memory 304. Among the selected execution environments, it accesses the file recorded in a predetermined path (a path that can be determined if the execution environment ID is known), and acquires the URL of the access destination stored in the file as the access destination information. The predetermined path consists of, for example, the name of a predetermined area (folder, bucket, directory) and a predetermined file name. The name of the predetermined area is, for example, "fixed string + execution environment ID". The predetermined file name is, for example, a predetermined common file name common to all execution environments. In this case, the predetermined path is "fixed string + execution environment ID / common file name.json". That is, it acquires the predetermined file (access destination information file) in the predetermined area that can be determined if the execution environment ID is known, acquires the access destination information from that file, and records it in the memory 304. The URL of the access destination information indicates the address in the execution environment and is the URL of the request destination for requesting the acquisition and update of the user information stored in the execution environment. If a request is not made to this URL, the acquisition and update of the user information stored in the execution environment cannot be performed. Thus, if the execution environment ID is not known, the access destination information for acquiring and updating the user information cannot be acquired. The execution environment ID is information that can only be obtained after the developer has performed an authentication process on the development environment 300 and logged in. Also, a developer who can log in to the development environment 300 can only acquire the execution environment IDs that are accessible to himself / herself. Therefore, it is suppressed that a person who cannot log in to the development environment 300 or a person who can log in to the development environment 300 but has a different accessible execution environment accesses the execution environment illegally and the user information is leaked.That is, security is improved.

[0207] In S1313, the development environment 300 sends a user information acquisition request (a request to execute a process of sending user information to the development environment 300) and developer information to the access destination indicated by the access destination information acquired in S1312 (transmission control). The developer information to be sent to the access destination is obtained from the developer information 301, and the encrypted account information of the logged-in developer is acquired. The account information to be acquired is the information for one row of the logged-in developer in the table of the developer information 301 shown in FIG. 14(a). That is, it includes information such as the email address, password, surname, name, and accessible execution environment ID. Information in which these are encrypted into one data string is acquired. Even if only this encrypted information is leaked, since it is encrypted, the email address, password, surname, name, and accessible execution environment ID will not be leaked.

[0208] In S1314, the development environment 300 determines whether it has received user information corresponding to the user information acquisition request sent in S1313 from the selected execution environment. This user information is sent from the execution environment in S1325 or S1326 described later. If the user information is received, the process proceeds to S1315; otherwise, it waits for the reception of the user information in S1314.

[0209] In S1315, the development environment 300 sends the user information received in S1314 to the developer terminal 100. The user information sent here is received in S1302 described above.

[0210] In S1316, the development environment 300 determines whether it has received a user information update instruction from the developer terminal 100. The user information update instruction received here is sent from the developer terminal 100 in S1306 described above. If the user information update instruction is received, the process proceeds to S1317; otherwise, it proceeds to 1318.

[0211] In S1317, the development environment 300 transmits a user information update request (a request to execute the update process of user information) and developer information to the access destination indicated by the access destination information acquired in S1312. The developer information to be transmitted to the access destination is the same as that described in S1313, and is the encrypted account information of the logged-in developer acquired from the developer information 301.

[0212] In S1318, the development environment 300 determines whether it has received an instruction to change the currently selected execution environment from the developer terminal 100. This change instruction is the one transmitted from the developer terminal 100 in S1308 described above. If an instruction to change the currently selected execution environment is received, the process proceeds to S1319; otherwise, the process proceeds to S1311 and the process is repeated.

[0213] In S1319, the development environment 300 stores the execution environment ID of the changed currently selected execution environment in the memory 304 as the changed currently selected execution environment.

[0214] FIG. 13(c) shows a flowchart of the user information management process in the currently selected execution environment among the execution environments 400, which is a process in response to the user information acquisition process in FIG. 13(b). Regarding the actor of this process, hereinafter, it will be simply described as the execution environment 400, but in reality, it is assumed that the execution engine in the currently selected execution environment among the execution environments 400 executes it. That is, for example, if the currently selected execution environment is the multi-tenant execution environment 410, the actor is the execution engine 412, and the processor 413 included in the execution engine 412 realizes it by executing a program using the memory 414 as a work memory. Also, for example, if the currently selected execution environment is the single-tenant execution environment 450, the actor is the execution engine 452, and the processor 453 included in the execution engine 452 realizes it by executing a program using the memory 454 as a work memory.

[0215] In S1321, the execution environment 400 determines whether it has received a user information acquisition request sent from the development environment 300. Here, the user information acquisition request to be received is the one sent from the development environment 300 in S1313 described above. If the user information acquisition request is received, the process proceeds to S1322; otherwise, it proceeds to S1327.

[0216] In S1322, the execution environment 400 performs an access right confirmation process. This process is for determining whether the sender of the user information acquisition request is an access from a developer with legitimate access rights. Through this process, the possibility of user information leakage to developers without legitimate access rights is reduced, and security is improved. The access right confirmation process will be described later with reference to FIG. 13(d).

[0217] In S1323, the execution environment 400 determines whether the result of the access right confirmation process is an error. If it is an error, without sending the user information held in its own environment to the requester of the user information acquisition request, the process proceeds to S1321. If it is not an error, the process proceeds to S1324.

[0218] In S1324, the execution environment 400 determines whether it is a multi-tenant execution environment 410. If it is a multi-tenant execution environment 410, the process proceeds to S1326; if it is not a multi-tenant execution environment but a single-tenant execution environment, the process proceeds to S1325.

[0219] In S1325, the execution environment 400 transmits the user information held in its own execution environment to the development environment 300. In the case of a single-tenant execution environment, since the owner of the environment itself is a single developer, the user information belongs only to the application whose owner is the single developer. Therefore, instead of transmitting a part of the user information whose owner is the logged-in developer as in the processing in the multi-tenant execution environment of S1326 described later, the whole is transmitted. For example, if the currently selected execution environment is the single-tenant execution environment 450, the user information 451 is transmitted to the development environment 300. The user information transmitted here is received by the development environment 300 in S1314 and transmitted to the developer terminal 100 in S1315.

[0220] In S1326, the execution environment 400 transmits to the development environment 300 the part of the user information held in its own execution environment whose owner ID matches the received developer information. The encrypted developer information is transmitted from the development environment 300, received in S1341 described later, decoded (decrypted) in S1343, and stored in the memory 414. This is the received developer information. Among the user information 411 of the multi-tenant execution environment 410 shown in FIG. 14(b), the information of the row having the same owner ID as the developer ID (email address) included in the received developer information is acquired and transmitted to the development environment 300. The information of the row that does not have the same owner ID as the developer ID (email address) included in the received developer information among the user information 411 of the multi-tenant execution environment 410 is not transmitted to the development environment 300. In the case of a multi-tenant execution environment, since user information owned by multiple developers is mixed and recorded, a part of the user information whose owner is the logged-in developer is transmitted. The user information transmitted here is received by the development environment 300 in S1314 and transmitted to the developer terminal 100 in S1315.

[0221] In S1327, the execution environment 400 determines whether it has received a user information update request. Here, the user information update request received is the one sent from the development environment 300 in S1317 described above. If the user information update request is received, the process proceeds to S1328; otherwise, it proceeds to S1321.

[0222] In S1328, the execution environment 400 performs an access right confirmation process. This process is for determining whether the sender of the user information update request is an access from a developer with legitimate access rights. Through this process, the possibility that user information is rewritten (updated) by requests from developers other than those with legitimate access rights is reduced, and security is improved. The access right confirmation process will be described later with reference to FIG. 13(d).

[0223] In S1329, the execution environment 400 determines whether the result of the access right confirmation process is an error. If it is an error, without performing the update according to the user information update request, the process proceeds to S1321. If it is not an error, the process proceeds to S1330.

[0224] In S1330, the execution environment 400 updates the user information stored in the confidence environment according to the user information update request. At this time, when registering a new user, in the case of a multi-tenant execution environment, the developer ID of the logged-in developer is registered as the owner ID and associated with the account information of the new user.

[0225] FIG. 13(d) shows the flowchart of the access right confirmation process. This process is the detailed flowchart of S1322 and S1328 in FIG. 13(c) described above.

[0226] In S1341, the execution environment 400 determines whether it has received encrypted developer information from the development environment 300. Here, the developer information received is the one sent from the development environment 300 in S1313 or S1317 described above. If the encrypted developer information is received, the process proceeds to S1343; otherwise, the process proceeds to S1342.

[0227] In S1342, the execution environment 400 records (outputs) that it is an error as a result of the access right confirmation process. In this case, it is determined to be an error in the aforementioned S1323 or S1329. Thus, even if a user information acquisition request or a user information update request is received, if the encrypted developer information is not received, request control is performed such that the process corresponding to the request is not performed (the request is not permitted), treating it as an error. Therefore, it is possible to suppress the process corresponding to unauthorized access.

[0228] In S1343, the execution environment 400 decodes (decrypts, decrypts) the developer information received in S1341 using the decryption key held in advance. Since the decrypted developer information is not transmitted outside the execution environment, the possibility of leakage is low.

[0229] In S1344, the execution environment 400 determines whether the execution environment ID of its own execution environment (the said execution environment) is included in the part indicating the accessible execution environment among the developer information decoded in S1342. If it is included, the process ends (this case is regarded as a legitimate access), and if it is not included, it proceeds to S1342 and records (outputs) that it is an error as a result of the access right confirmation process. This prevents performing the process corresponding to a user information acquisition request or a user information update request from a developer who does not have the access right to the said execution environment. Therefore, it is possible to suppress the process corresponding to unauthorized access.

[0230] Note that the execution environment 400 does not accept access from outside the development environment 300, and controls so that even if there is a user information acquisition request or a user information update request with a source other than the development environment 300, the process corresponding to the request is not performed. This prevents performing the process corresponding to the case where the developer information encrypted by a device other than the development environment 300 and the user information acquisition request or the user information update request are fabricated and transmitted. Therefore, security is improved.

[0231] According to the user information display process described above, it is possible to suppress unauthorized processing due to unauthorized access to the execution environment 400, reduce the risk of information leakage, and improve security. In the above-described user information display process, the process regarding the user information held in the execution environment was described, but the same applies to other processes regarding the execution environment other than the process regarding the user information. For example, the same process can be applied during processing related to databases and files held in the execution environment 400 to improve security.

[0232] For example, it is applicable to the process related to the display and update of the database described in S1210 to S1214 of FIG. 12. In this case, in response to a DB operation instruction from the developer terminal 100, the development environment 300 acquires an access destination information file from the currently selected execution environment in the same manner as S1312. Since the access destination information file records the DB operation request reception URL that is the request destination for receiving the DB operation request, the DB operation request and the developer information are transmitted thereto in the same manner as S1313. The execution environment 400 performs a process of determining whether the transmission source of the DB operation request is legitimate in the same manner as the processes described in FIGS. 13(c) and 13(d), and only when it is legitimate, performs a process related to the DB set held in its own execution environment in response to the DB operation request.

[0233] Also, for example, it is applicable to the process related to file management described in S1215 to S1217 of FIG. 12. In this case, in response to a file management instruction from the developer terminal 100, the development environment 300 acquires an access destination information file from the currently selected execution environment in the same manner as S1312. Since the access destination information file records the file management request reception URL that is the request destination for receiving the file management request, the file management request and the developer information are transmitted thereto in the same manner as S1313. The execution environment 400 performs a process of determining whether the transmission source of the file management request is legitimate in the same manner as the processes described in FIGS. 13(c) and 13(d), and only when it is legitimate, performs a process related to the files held in its own execution environment in response to the file management request.

[0234] <Workflow processing> FIG. 16 shows a flowchart of the workflow processing. This processing is the detailed flowchart of S1205 in FIG. 12. This processing is executed by the developer terminal 100.

[0235] In S1601, the developer terminal 100 displays a workflow (WF) creation screen on the display 105. FIG. 17(a) shows a display example of the WF creation screen. A node list 1710 is displayed in the sub-menu area 510. The node list 1710 includes, as node options, a start 1711 that is a starting point, an end 1712 that is an ending point, and a status 1713 that is an intermediate point. In the area where the canvas 530 was displayed, a WF placement area 1700 is displayed instead of the canvas 530. The WF placement area 1700 is an area that is blank before placement. Any one of the plurality of options (node options) displayed in the node list 1710 can be selected and placed in the WF placement area 1700. In this embodiment, it is assumed that placement is performed by drag and drop. That is, any one of the plurality of options displayed in the node list 1710 can be dragged and dropped into the WF placement area 1700 for placement.

[0236] In S1602, the developer terminal 100 determines whether there has been an operation to place a node. Specifically, it determines whether there has been an operation to place a node by dragging any one of the plurality of options displayed in the node list 1710 and dropping it into the WF placement area 1700. If there has been an operation to place a node, the process proceeds to S1603; otherwise, the process proceeds to S1604.

[0237] In S1603, the developer terminal 100 places the selected node in the WF placement area 1700 according to the operation of placing the node.

[0238] In S1604, the developer terminal 100 determines whether there is an operation to draw an arrow. The arrow is an arrow that connects arranged nodes, and indicates the processing content when transitioning from the original node of the arrow to the subsequent node. When an arranged node is selected, an operation path is displayed for the selected node. When dragging starts with the mouse cursor on the operation path (that is, when the left button of the mouse is pressed and the movement of the mouse starts), and dropping it on another node (that is, releasing the pressing of the left button), an arrow can be drawn. The node where the dragging starts becomes the origin of the arrow, and the node at the dropped position becomes the destination of the arrow. If there is an operation to draw an arrow, the process proceeds to S1605; otherwise, it proceeds to S1606.

[0239] In S1605, the developer terminal 100 draws an arrow object between two arranged nodes in the WF arrangement area 1700 in response to the operation of drawing an arrow.

[0240] Fig. 17(b) shows an example of the display after nodes and arrows are arranged in the WF arrangement area 1700. In the WF arrangement area 1700, nodes 1701 to 1705 are arranged. Node 1701 is the starting node. Nodes 1702, 1703, and 1704 are intermediate point (status) nodes. Node 1705 is the ending node. Arrow 1706 is an arrow from node 1701 to node 1702. Arrow 1707 is an arrow from node 1702 to node 1703. Arrow 1708 is an arrow from node 1703 to node 1704. Arrow 1709 is an arrow from node 1704 to node 1705. Each node indicates one step of a workflow including a plurality of steps, and the arrow indicates the sequence of steps. That is, in the illustrated example, it is shown that nodes 1701 to 1705 are the 1st to 5th steps respectively.

[0241] In S1606, the developer terminal 100 determines whether there has been an operation to set the properties of a node. Specifically, it determines whether there has been an operation of selecting a node already placed in the WF placement area 1700 and right-clicking. If there has been an operation to set the properties of a node, it proceeds to S1607; otherwise, it proceeds to S1608.

[0242] In S1607, the developer terminal 100 displays a property box for setting the properties of a node and accepts an operation to set the properties of the node. FIG. 17(c) shows an example of the display of the property box for a node. In the property box of the node, the ID of the node (an initial value that does not overlap with other nodes is set and can be changed), the label (the displayed name), and the setting of the ID of the UI screen where the generated workflow is placed are accepted. The setting of the ID of the UI screen is such that a list of the IDs of the UI screens is displayed as options, and it can be selected and set from among those options.

[0243] In S1608, the developer terminal 100 determines whether there has been an operation to set the properties of an arrow. Specifically, it determines whether there has been an operation of selecting an arrow already drawn in the WF placement area 1700 and right-clicking. If there has been an operation to set the properties of an arrow, it proceeds to S1609; otherwise, it proceeds to S1610.

[0244] In S1609, a property box for setting properties for the arrow is displayed, and an operation for setting the operation property, which is the property of the arrow, is accepted. Fig. 17(e) shows an example of the display of the property box for the arrow. In the property box for the arrow, the ID of the arrow (an initial value that does not overlap with other arrows is set and can be changed), the label (the displayed name), the type, and user settings are accepted. The type can be set by selecting any one of the options corresponding to approval (Update), application (Creat), and remand (Remand), respectively. The user can set it by selecting any one of the options corresponding to SelectUser and CurrentUser, respectively. The type indicates the type of action when transitioning from the original procedure of the arrow to the subsequent procedure. Based on this type, the actions of the UI components automatically arranged as described later are automatically set.

[0245] In S1610, the developer terminal 100 determines whether the workflow generation button 1730 has been pressed. If the workflow generation button 1730 has been pressed, the process proceeds to S1611; otherwise, it proceeds to S1615.

[0246] In S1611, the developer terminal 100 displays the selection acceptance form (dialog box) shown in Fig. 17(e) as a wizard and accepts the selection of the status to be created. At least one of start, in application, approved, and unapplied can be selected as the status to be created.

[0247] In S1612, the developer terminal 100 displays the selection acceptance form (dialog box) shown in Fig. 17(f) as a wizard and accepts the selection of whether to additionally create a task table. Here, it is possible to select whether to generate a task table and the ID of the UI screen to be added. The selection of the ID of the UI screen is such that a list of the IDs of the UI screens is displayed as options, and selection can be made from among those options.

[0248] In S1613, the developer terminal 100 displays the specified reception form (dialog box) shown in Fig. 17(g) as a wizard and accepts the specification (selection) of the database. The specification of the database can be made by selecting from the displayed options.

[0249] In S1614, the developer terminal 100 creates a workflow definition based on the nodes, arrows, and their respective properties arranged in the WF arrangement area 1700, and the content set by making selections from the options in S1611 to S1614, and records it in the definition information of the memory 102. As a result, UI components (UI components) based on the workflow are automatically arranged on the UI screen. The automatically arranged UI components have actions automatically set corresponding to the workflow. In this way, without the developer user having to describe in a programming language, UI components with actions automatically defined based on the workflow generated by the operation of selecting options are generated. Also, a table used in the workflow is created in the database specified in the specified reception form shown in Fig. 17(g). Also, an action is set (defined) on the canvas of the UI screen according to the set content. The action set on the canvas is the process to be performed when the UI screen is loaded (read) in the constructed application. That is, it is the process to be performed as an initial operation when the screen is displayed.

[0250] In S1615, the developer terminal 100 determines whether there has been a screen switching operation. More specifically, it determines whether any option included in the main menu area 510 has been selected. If any option included in the main menu area 510 has been selected, the process of Fig. 16 ends and the process proceeds to the screen switching process described above in Fig. 12. Otherwise, it proceeds to S1602.

[0251] Fig. 18(a) shows an example of the display when the database table added in S1614 of Fig. 16 is displayed by pressing the database button 516 in the main menu area. That is, Fig. 18(a) is one of the screens related to the database displayed in S1214 of Fig. 12. Among the table lists displayed in the sub-menu area, Table 1801 and Table 1802 are the tables automatically added in response to the generation of the workflow. They are added (generated) as the tables included in (subordinate to, lower-level) the database accepted for designation in S1613.

[0252] Fig. 18(b) shows an example of the display of the canvas of the UI screen where UI components are automatically arranged in S1614 of Fig. 16. The UI components 1811 to 1813 arranged on the canvas 530 are the UI components automatically arranged in response to the generation of the workflow. That is, the UI components 1811 to 1813 are not arranged by the developer by dragging and dropping from the UI component list in the sub-menu area. An action is automatically set (defined) for the UI component 1813. The UI component 1813 is an automatically generated component with an action defined for transitioning to the next step in the workflow. Also, the UI screen where the UI component 1813 is arranged is the source screen in the transition to the next step of the workflow by the execution of the action automatically defined for the UI component 1813.

[0253] FIG. 18(c) shows a display example when an action board is displayed with the UI component 1813, which is a button, as the specified UI component. That is, this action board is the one displayed in S801 described above with reference to FIG. 8 when the specified UI component is the UI component 1813. In the action board 910, in a state where the developer has not described an action in a programming language, an action string as shown in FIG. 18(c) is displayed in a state where it is described in a programming language as an initial value. In other words, in the action board 910, in a state where the developer has not described source code in a programming language regarding the action, source code in a programming language that defines an action as shown in FIG. 18(c) is displayed as an initial value. In the action displayed in the action board 910 of FIG. 18(c), at least a database (third line) and the UI screen to be displayed next (sixth line) are defined based on the group of operations received from the user in the workflow creation process of FIG. 16. The user can edit the action automatically defined in this way by the processes of S802 to S808 described above. That is, based on the automatically defined action string, a programming language can be input so as to partially reuse it, partially modify it, or add a string. That is, a correction operation on the automatically defined action string can be received. In this way, by using the programming language of the action automatically generated and displayed as a basis, the developer can easily set an action with fewer operation steps (amount of text input) than when describing an action in a programming language from scratch. In addition, since the automatically generated action can be customized by adding corrections without using it as it is, an action that meets more detailed requirements can be generated.

[0254] FIG. 18(d) shows an example of a display when an action board on the canvas of a UI screen with actions automatically set according to the generation of a workflow is displayed. This action board is displayed when context menu processing is performed by designating a blank area on the canvas to instruct the display of the action board. It is displayed in S1903 of FIG. 19 described later. On the action board, in a state where the developer has not described the action in a programming language, the action string as shown in FIG. 18(d) is displayed in the programming language as an initial value. In other words, on the action board, in a state where the developer has not described the source code in a programming language regarding the action, the source code in the programming language that defines the action as shown in FIG. 18(d) is displayed as an initial value. The user can edit the automatically defined action by the process of S1904 described later. That is, similar to the action automatically set for the UI component described in FIG. 18(c), the action can be easily set with a small number of operation steps (amount of text input), and an action that meets more detailed requirements can be generated.

[0255] For the UI components and actions automatically generated according to the generation of the workflow described above, for example, the following customizations can be made. · Set an action to display the name of the current procedure (step) in the workflow on the action board of the canvas. · Arrange an input field (UI component) for the reason for application, and modify the action board of UI component 1813 so that the data input there is sent to the next step. · Modify the action board of component 1813 so that data is saved in a different table. For example, customize it so that the reason for application and case ID, etc. are also recorded in another DB. · Set the user who initially inputs into the UI component 1812 (combobox) on the campus action board to the person who applied last time by writing an action within the programming limit. Alternatively, write an action to display selectable approvable persons as options.

[0256] Thus, according to this embodiment, the basic part of the workflow can be quickly created with simple operations according to the operations on the workflow creation screen and the input content to the wizard (that is, based on an operation group including operations of selecting from options without including the operation of writing source code in a programming language). Moreover, by presenting the actions set on the automatically created UI components and the canvas of the UI screen in a modifiable manner in a programming language, a more flexible design becomes possible.

[0257] <CRUD generation process> FIG. 19 shows a flowchart of the canvas context menu process. This process is the detailed flowchart of S703 in FIG. 7 described above. This process is executed by the developer terminal 100. The canvas context menu includes options for generating CRUD.

[0258] In this embodiment, as an example for the explanation of CRUD generation, before the generation of CRUD (before the arrangement of CRUD buttons), when the canvas of the selected UI screen as shown in Fig. 20(a) was displayed, an example will be described where the blank area of the canvas was right-clicked and the context menu of the canvas was displayed. CRUD is an acronym formed by connecting the initial letters of the four basic functions required of software: Create, Read, Update, and Delete. On the canvas of Fig. 20(a), UI components 2001 to 2003 arranged by the developer in the UI editor process are displayed. All of the UI components 2001 to 2003 are UI components of the type Input. UI component 2001 is displayed as "ID" as a label, UI component 2002 is displayed as "Name" as an initial Value, and UI component 2003 is displayed as "age" as a label. That is, the canvas of Fig. 20(a) is the canvas of a UI screen designed assuming a screen for some user registration. UI component 2001 is an input field for having the developer enter the ID of the newly registered user, UI component 2002 is an input field for having the developer enter the name of the newly registered user, and UI component 2003 of the UI is an input field for having the developer enter the age of the newly registered user. Assume that the UI component IDs of UI components 2001 to 2003 are "number_field_ID", "text_field_Name", and "number_field_age", respectively.

[0259] In S1901, the developer terminal 100 superimposes and displays the context menu of the canvas in the vicinity of the mouse cursor. Fig. 20(b) shows an example of the display of the context menu of the canvas. In the context menu of the canvas, options 2011 to 2015, which are menu items, are displayed.

[0260] In S1902, the developer terminal 100 determines whether a menu item (option 2013) that instructs the display of the action board in the context menu of the canvas has been pressed. If the menu item (option 2013) that instructs the display of the action board has been pressed, the process proceeds to S1903; otherwise, it proceeds to S1906.

[0261] In S1903, the developer terminal 100 displays the action board of the canvas based on the definition information held in the memory 102. An example of the display of the action board of the canvas is, for example, that shown in FIG. 18(d) described above. FIG. 18(d) is an example in which actions are automatically set. If no actions are set, the action board is displayed in a blank state. If the developer has previously input (set) an action to the action board and the content is recorded in the definition information, a programming language string indicating the set action is displayed on the action board.

[0262] In S1904, the developer terminal 100 accepts input operations, editing operations, and function setting operations in the programming language from the developer user for the action board (editing acceptance). Since this process is the same as the process of S802 to S823 in FIG. 8 described above, the details are omitted.

[0263] In S1905, the developer terminal 100 determines whether there is an operation to close the action board (an operation to end the action board process). If there is no operation to close the action board, the process proceeds to S1904 to repeat the process. If there is an operation to close the action board, the action board is made invisible, the process of FIG. 19 ends, the display is switched to the canvas of the selected UI screen, and the process returns to the UI editor process.

[0264] In S1906, it is determined whether or not a menu item (option 2015) that instructs the generation of CRUD in the context menu of the developer terminal 100 and the canvas is pressed. If the menu item (option 2015) that instructs the generation of CRUD is pressed, the process proceeds to S1907; otherwise, it proceeds to S1914.

[0265] In S1907, the developer terminal 100 displays the CRUD input form 1 (which is a dialog box) as a wizard and accepts an operation to select a UI component for which data is to be acquired in the CRUD. Fig. 20(c) shows an example of the display of the CRUD input form 1. In the area 2021, the UI component IDs of all the UI components arranged on the selected UI screen are displayed as options. The user (developer) makes a selection by selecting an option that the user wants to be the target of data acquisition from among the options displayed in the area 2021 and displaying it in the selected area 2022.

[0266] In S1908, the developer terminal 100 determines whether or not a selection operation in the input form 1 is performed and the NEXT icon 2023 is pressed. If the NEXT icon 2023 is pressed, the process proceeds to S1909; otherwise, it waits for the NEXT icon 2023 to be pressed in S1908.

[0267] In S1909, the developer terminal 100 displays the CRUD input form 2 (which is a dialog box) and accepts a selection of columns to be prepared in the database table that is the target of the CRUD. Fig. 20(d) shows an example of the display of the CRUD input form 2. In the area 2031, the UI component ID of the UI component selected in the input form 1 is displayed as an option. The user (developer) makes a selection by selecting an option that the user wants to be the target column of the CRUD from among the options displayed in the area 2031 and displaying it in the selected area 2032.

[0268] In S1910, the developer terminal 100 determines whether a selection operation is performed in the input form 2 and whether the NEXT icon 2033 is pressed. If the NEXT icon 2033 is pressed, the process proceeds to S1911; otherwise, it waits for the NEXT icon 2033 to be pressed in S1910.

[0269] In S1911, the developer terminal 100 displays the CRUD input form 3 (a dialog box) and accepts a selection operation for the database and table to be subject to CRUD. FIG. 20(e) shows an example of the display of the CRUD input form 3. Region 2041 is a region for accepting the selection of a database. The selection of a database can be made from the options displayed by pressing the icon at the right end. Region 2042 is a region for accepting the input of the table name.

[0270] In S1912, the developer terminal 100 determines whether a selection / input operation is performed in the input form 3 and whether the FINISH icon 2043 is pressed. If the FINISH icon 2043 is pressed, the process proceeds to S1913; otherwise, it waits for the FINISH icon 2043 to be pressed in S1912.

[0271] In S1913, the developer terminal 100 generates CRUD buttons based on the content (selected content) input in the input forms 1 to 3 and automatically arranges them on the currently selected UI screen. Also, it generates a UI screen, namely NextUI, which is the screen to be transitioned and displayed in response to the pressing of the CRUD buttons. That is, a UI screen is automatically generated for the currently selected application. Also, it automatically generates a table of the database with the content input in the input form 3 in the DB set of the execution environment being selected.

[0272] In S1914, the developer terminal 100 determines whether any of the other menu items (any of the options 2011, 2012, 2014) in the context menu of the canvas is pressed. If any of the other menu items is pressed, the process proceeds to S1915; otherwise, it proceeds to S1916.

[0273] In S1915, the developer terminal 100 performs other processing, which is processing according to the pressed menu item.

[0274] In S1916, the developer terminal 100 determines whether there is an operation to close the context menu of the canvas (for example, an operation of clicking outside the area where the context menu is displayed). If there is an operation to close the context menu, in S1917, the context menu is made invisible and the processing of FIG. 19 is terminated. If there is no closing operation, the process returns to S1902.

[0275] FIG. 20(f) shows a display example of the CRUD buttons (automatically generated components) automatically arranged by the processing of S1913. FIG. 20(f) is a display example of the canvas of the same UI screen as FIG. 20(a), and the same reference numerals are assigned to the same UI components as in FIG. 20(a). In FIG. 20(f), UI components 2051 to 2053 are added to FIG. 20(a). These UI components 2051 to 2053 are CRUD buttons. Actions are automatically set for the UI components 2051 to 2053 that are CRUD buttons. The action of the UI component 2051 that is a CRUD button is to save (update or add) the value input to the UI component selected in the input form 1 to the table of the database set in the input form 3 in response to the pressing of the UI component 2051, and then perform a process of transitioning to the NextUI. The action of the UI component 2052 that is a CRUD button is to delete the data having the value input to the UI component selected in the input form 1 from the table of the database set in the input form 3 in response to the pressing of the UI component 2052, and then perform a process of transitioning to the NextUI. The action of the UI component 2053 that is a CRUD button is to obtain the data that matches the value input to the UI component selected in the input form 1 from the table of the database selected in the input form 3 in response to the pressing of the UI component 2052, and perform a process of transitioning to the NextUI and displaying the obtained data.

[0276] Figure 20(g) shows an example of the display of the UI screen (UI screen ID: crud - newui - UI01) automatically generated by the process of S1913. Figure 20(g) is an example of the display of the canvas of a UI screen different from that of Figure 20(a), and the data grid 2061, which is a UI component, is arranged. The data grid 2061 has four columns: "ID", "number_field_ID", "text_field_Name", and "number_field_age". Among these, the columns other than "ID" correspond to the UI components selected in Input Form 2. Also, the UI component 2062, which is a button, is automatically arranged. For this UI screen (crud - newui - UI01), the actions of the canvas are also automatically set. The automatically set actions of the canvas are actions that control to display the data of the row targeted for CRUD in the data grid 2061 when various CRUD buttons on the source screen are pressed among the database tables set in Input Form 3. This action of the canvas can also be customized by the developer (user) based on the automatically set actions by the process of S1904 mentioned above.

[0277] In addition, the automatically generated data grid 2061 can also be edited in various ways using the grid property box and action board described later. For example, the decoration of the grid can be changed, or the label displayed as the column name can be changed from "text_field_Name" to "Name". Also, for example, it is possible to modify the display so that some columns are not shown. After the application is deployed and operation starts, there may be cases where, due to certain circumstances (such as changes in regulations or operation methods), it is desired to increase or decrease columns. For example, in the future, there may be a case where it is desired to change the display so that the column "number_field_age" in the data grid 2061 is not shown. In this case, it can be deleted simply by deleting the column to be deleted from the column properties in the UI editor. Therefore, it is not necessary to re-enter and regenerate the CRUD input forms 1 to 3. In this way, by being able to edit the UI components and screens automatically generated according to the input to the CRUD input form (wizard), it is possible to easily and flexibly respond to changes in the future operation of the application with few operation steps.

[0278] FIG. 21(a) shows an example of a database table automatically added by the process of S1913. This display example is the display example when the database button 516 in the main menu area is pressed and displayed. That is, FIG. 21(a) is one of the screens related to the database displayed in S1214 of FIG. 12. Among the table list (TABLES) included in the database "sample" displayed in the sub-menu area, the table 2101 (CRUD_T01) is a table automatically added in response to the generation of CRUD. It can be seen that the table 2102 shows the details of the table 2101 (CRUD_T01), and in addition to the ID as a column, there is a column with the UI component ID of the UI component selected in the input form 2 as the column name. For these columns, properties such as the data type are also automatically set according to the properties of the UI components selected in the input form 2.

[0279] Fig. 21(b) shows a display example when the action board of the UI component 2051, which is a CRUD button automatically arranged in the process of S1913 in Fig. 19, is displayed. That is, this action board is the one displayed in S801 described above with reference to Fig. 8 when the specified UI component is the UI component 2051. In the action board 910, in a state where the developer has not described the action in the programming language, the action string as shown in Fig. 21(b) is displayed in the programming language (JavaScript) as the initial value. In other words, in the action board 910, in a state where the developer has not described the source code in the programming language regarding the action, the source code in the programming language that defines the action as shown in Fig. 21(b) is displayed as the initial value. The user can edit the automatically defined action by the processes of S802 to S808 described above. That is, based on the automatically defined action string, the programming language can be input to partially reuse it, partially modify it, or add a string. That is, a correction operation for the automatically defined action string can be accepted. In this way, by using the programming language of the automatically generated and displayed action as a basis, the developer can easily set the action with fewer operation steps (amount of text input) than describing the action in the programming language from scratch. In addition, since the automatically generated action can be customized by adding corrections without using it as it is, it is possible to generate an action that meets more detailed requirements.

[0280] Also, in Fig. 21(b), in the function list 920 in the sub-menu area, function 2121 and function 2122 are displayed as selectable options for the functions prepared in advance. Function 2121 and function 2122 are functions automatically generated in the process of S1913 in Fig. 19.

[0281] Fig. 21(c) shows a display example when function 2121 is selected from the function list 920 to display the function setting screen. Function 2121 is an SQL function, and the SQL function setting screen is displayed. Since the SQL function setting screen has the same configuration as that described above in Fig. 10(a), in Fig. 21(c), the same symbols are attached to the same setting columns / input columns as in Fig. 10(a), and the description is omitted. In the setting column 951, "SQL_Save" is automatically set as the function name. Also, in the setting column 953, an SQL statement is pre-entered. Among this SQL statement, the character string "INSERT INTO" indicates that the processing type to the database is "INSERT", which is a process of adding a new row to the table. Also, the character string "sample.CRUD_T01" indicates that the database to be processed is "sample" and the table is "CRUD_T01". This is a reflection of the content input in the input form 3. Also, the subsequent character strings indicate the values of the columns included in the row to be added, which is a reflection of the content input in the input form 1. The contents of the setting columns 951 and 953 can be edited (modified, deleted, added to, customized) by the developer by the processing of S813 to S820 in Fig. 8 based on the automatically generated ones.

[0282] Fig. 21(d) shows an example display when function 2122 is selected from the function list 920 to display the function setting screen. Function 2122 is an SQL function, and the SQL function setting screen is displayed. Since the SQL function setting screen has the same configuration as that described above in Fig. 10(a), in Fig. 21(d), the same symbols are attached to the same setting fields / input fields as in Fig. 10(a), and the description is omitted. In the setting field 951, "SQL_Update" is automatically set as the function name. Also, in the setting field 953, an SQL statement is pre-entered. Among this SQL statement, the character string "UPDATE" indicates that the processing type for the database is "UPDATE", which is a process of updating the values of existing rows in the table. Also, the character string "sample.CRUD_T01" indicates that the database to be processed is "sample" and the table is "CRUD_T01". This is what reflects the content input in the input form 3. Also, the subsequent character strings indicate the values of the columns to be updated, which are what reflect the content input in the input form 1. The contents of the setting fields 951 and 953 can be edited (modified, deleted, added to, customized) by the developer through the processing of S813 to S820 in Fig. 8 based on the automatically generated ones.

[0283] The content of the automatically generated actions shown in the action board 910 of Fig. 21(b) will be described in detail. Each line of the JavaScript character string described in the action board 910 of Fig. 21(b) has the following meaning. The first line... Defines a set of values including the values of the 2nd to 5th lines with the variable name params. The second line... Defines the number that will be the ID. It serves as a serial number. The 3rd to 5th lines... Obtain the values entered in the UI component selected in the input form 1. Note that in the sense of obtaining values, on the right side of "=", "$ui.UI component ID. type of information to be targeted" is described, but this description method itself is not the standard description method of JavaScript and is unique to this system. Details of this will be described later. Line 6: Execute the function SQLUpdate with the params defined in lines 2 - 5 as arguments. That is, update the table in the database set in input form 3 with the values entered in the UI components selected in input form 1. Line 7: Retrieve the rows affected by the Update. Line 8: Determine if there are any rows obtained in line 7. That is, determine if there are any rows that could be updated. Line 9: If line 8 is true, display "Successfully Updated". Line 10: Transition to the UI screen with UI screen ID "crud - newui - UI01" as NextUI. Line 12: Determine if the number of rows obtained in line 7 is 0. If this is true, it means there was no existing row corresponding to the params retrieved this time, so a new row will be added for new registration. Line 13: If line 12 is true, execute the function SQLSave with the params defined in lines 2 - 5 as arguments. That is, add a row to the table in the database set in input form 3 with the values entered in the UI components selected in input form 1 for new saving. Line 14: Retrieve the rows affected by the new saving in line 13 (i.e., the added row). Line 15: Determine if there are any rows obtained in line 14. That is, determine if the new registration by adding a row was successful. Line 16: If line 15 is true, display "Successfully Inserted". Line 17: Transition to the UI screen with UI screen ID "crud - newui - UI01" as NextUI. Lines 19 and 20: If both line 8 and line 12 are false, display "Insertion Failed".

[0284] For the content automatically generated in this way and presented to the action board in a programming language so that developers (users) can modify it, developers (users) can perform customizations such as the following. · Since you want to change the content of the message (the message displayed in response to the execution of the action), rewrite only the message content on lines 9, 16, and 20. · Since you want to use your own created screen (the screen displayed in response to the execution of the action) when the SAVE button is pressed, rewrite only the part of the NextUI UI screen ID (crud - newui - UI01) on lines 10 and 17. · Since you want to change to an operation that does not register age, delete line 5. That is, change the component that acquires and / or outputs information when the action is executed. · Since you want to register in multiple databases, newly create (add) and add an SQL function (creation function). When newly creating an SQL function, copy and paste the automatically created SQL statements such as "SQLSave" and "SQLUpdate" into the setting column 953, and only modify the part of the target database and table.

[0285] In this way, rather than creating the actions of the CRUD buttons desired by the developer from a state where there is no description of the actions in the programming language, customizing from the automatically generated ones can greatly reduce the operation steps. Also, since it can be freely customized, the degree of freedom of the content of the actions that can be created is large. According to this embodiment, the actions (actions defined based on the operation groups input to input forms 1 to 3) defined without the developer (user) writing in the program language can be modified and used more flexibly.

[0286] <Developer Account Registration Process> Figure 22(a) shows a flowchart of the developer account registration process on the developer terminal 100. This process is the detailed flowchart of S306 in FIG. 3 described above.

[0287] In S2201, the developer terminal 100 displays, on the display 105, input fields for receiving the input of an email address, surname, and given name as account information to be newly registered, and receives the input from the user (developer) to each input field.

[0288] In S2202, the developer terminal 100 transmits the account information input in S2201 and a registration request, which is a request to newly register the account information, to the development environment 300.

[0289] In S2203, the developer terminal 100 displays, on the display 105, a reception screen for receiving the input of a one-time password, and receives the input of the one-time password from the user (developer). When a registration request for the account information is transmitted to the development environment 300, a one-time password is sent from the development environment 300 to the email address included in the account information to confirm that the email address is valid. Since the developer is the owner of the email address, the developer looks at the one-time password sent to the email address and inputs it into the one-time password reception screen displayed on the display 105.

[0290] In S2204, the developer terminal 100 transmits the one-time password input in S2203 to the development environment 300.

[0291] In S2205, the developer terminal 100 determines whether or not it has received a login OK notification from the development environment 300. If it has received a login OK notification, it proceeds to S2209; otherwise, it proceeds to S2206.

[0292] In S2206, the developer terminal 100 displays a retransmission instruction screen for requesting the development environment 300 to retransmit the one-time password.

[0293] In S2207, the developer terminal 100 determines whether there has been an operation to resend the one-time password from the developer (user). If there has been an operation to resend, it proceeds to S2208. If there has been no operation to resend, the developer terminal 100 waits until there is an operation to resend.

[0294] In S2208, the developer terminal 100 sends a request to resend the one-time password to the development environment 300.

[0295] In S2209, the developer terminal 100 sends the password registration screen to the developer terminal 100 and accepts password registration (input of data to be used as the password).

[0296] In S2210, on the developer terminal 100, the data to be used as the password received in S2209 is sent to the development environment 300.

[0297] Fig. 22(b) shows a flowchart of the developer account registration process in the development environment 300. This process is the process on the development environment 300 side that is linked to the developer account registration process on the developer terminal 100 in Fig. 22(a).

[0298] In S2221, the development environment 300 determines whether it has received the account information and a registration request (registration instruction), which is a request to newly register the account information, from the developer terminal 100. This account information and registration request were sent from the developer terminal 100 in S2202 of Fig. 22(a). If the development environment 300 has received the account information and a registration request, which is a request to newly register the account information, from the developer terminal 100, it proceeds to S2222. Otherwise, it waits until it receives them.

[0299] In S2222, the development environment 300 adds a row to the developer information 301 and records the account information received in S2221. Also, the value of the "Verify" column in this row is recorded as "unconfirmed". The columns in the developer information 301 are those shown in FIG. 14(a). One row of the developer information 301 corresponds to the account information of one person, and the information in each column (row) recorded in the same row is recorded in association as the account information of the same developer.

[0300] In S2223, the development environment 300 instructs an external one-time password issuance system (not shown) to issue and send a one-time password with the email address included in the account information received in S2221 as the destination. As a result, a one-time password is sent to the developer's email address from the external one-time password issuance system. In this embodiment, it is assumed that the one-time password is instructed to be sent to the external one-time password issuance system, but the development environment 300 itself may send the one-time password.

[0301] In S2224, the development environment 300 determines whether a one-time password has been received from the developer terminal 100. The one-time password received here is the one sent from the developer terminal 100 in S2204 of FIG. 22(a). If a one-time password is received, the process proceeds to S2225; otherwise, it waits in S2224.

[0302] In S2225, the development environment 300 sends the one-time password received in S2225 to the external one-time password issuance system and sends a confirmation instruction to check whether it matches the issued one-time password. That is, it instructs the verification of the one-time password.

[0303] In S2226, the development environment 300 determines whether it has received a notification from an external one-time password issuance system that the one-time password is correct (i.e., the verification is successful). If it is positive (i.e., the verification is successful), it proceeds to S2228; otherwise, it proceeds to S227.

[0304] In S2227, the development environment 300 determines whether it has received a request for resending the one-time password from the developer terminal 100. The request received here is the one sent from the developer terminal 100 in S2208 of FIG. 22(a). If it has received a request for resending the one-time password, it proceeds to S2223; otherwise, it waits in S2227.

[0305] In S2228, the development environment 300 activates the account added to the developer information 301 in S2222. Specifically, among the account information added to the developer information 301 in S2222, the value of the column "Verify" is changed to "confirmed". The account information with the value of the column "Verify" being "confirmed" is the one for which it has been confirmed that the registered email address is valid by the verification of the one-time password, and is regarded as a registered valid account. In this embodiment, authentication is performed using the email address, but when other contact information for the developer such as a phone number or an SNS account is registered as account information, authentication using other contact information may also be used.

[0306] In S2229, the development environment 300 determines whether the number of valid accounts registered in the developer information 301 (i.e., the number of accounts with the value of "Verify" being "confirmed") is greater than a predetermined threshold 2 (e.g., 9000). If the number of valid accounts is greater than the threshold 2, it proceeds to S2230; if the number of valid accounts is less than or equal to the threshold 2, it proceeds to S2232.

[0307] S2230 determines whether the development environment 300 has already added a DB instance to the multi-tenant execution environment 410. If a DB instance has been added, it proceeds to S2232; otherwise, it proceeds to S2231.

[0308] In S2231, the development environment 300 adds a new DB instance to the DB set 430 of the multi-tenant execution environment 410. Since it takes several tens of minutes to newly add (create) a DB instance, before changing the destination DB instance when the number of valid accounts exceeds a threshold 1 ( > threshold 2) described later, it is prepared in advance when the threshold 1 is exceeded. By doing so, when there is a change in the destination DB instance, it can be immediately connected to the new DB instance without delay.

[0309] In S2232, the development environment 300 determines whether the number of valid accounts registered in the developer information 301 (the number of accounts with the value of "Verify" being "confirmed") is greater than a predetermined threshold 1 (a value greater than threshold 2, for example, 10000 for the developer terminal). If the number of valid accounts is greater than threshold 1, it proceeds to S2233; if the number of valid accounts is less than or equal to threshold 1, it proceeds to S2236.

[0310] In S2233, the development environment 300 determines whether the DB instance name held in the memory 304 as the DB instance name to be assigned to the newly added account information has been updated to the DB instance name of the new DB instance added in S2231. If it has been updated, it proceeds to S2236; otherwise, it proceeds to S2234.

[0311] In S2234, the development environment 300 updates the database instance name held in the memory 304 as the database instance name of the multi-tenant execution environment assigned to the newly added account information to the database instance name of the new database instance added in S2231. The database instance name is an identifier for the database environment. As a result, for example, an account added previously may have been assigned "Database Instance Name 1", while an account added later will be assigned "Database Instance Name 2". When the number of accounts connected to one database instance (database environment) increases, the number of accesses to the database at one time increases, and if the accesses become concentrated, it may cause a performance degradation such as a decrease in response. In contrast, by the process of S2233, when the number of accounts exceeds threshold 1, accounts registered thereafter are set to connect to a new database instance (database environment) different from the previous one, so it is possible to reduce the possibility that the number of developers using one database instance becomes excessive and access becomes concentrated. Therefore, it is possible to reduce the possibility of performance degradation such as a decrease in response regarding access to the database.

[0312] In S2235, the development environment 300 updates threshold 1 = threshold 1 + threshold 1. Also, threshold 2 = threshold 2 + threshold 1 is updated. As a result, for example, if the previous threshold 1 was 10000 for the developer terminal and the previous threshold 2 was 9000, then threshold 1 = 20000 and threshold 2 = 19000. That is, every time the number of accounts on the developer terminal 10000 increases further (every time the number of valid accounts increases by the amount of threshold 1), the processes of S2231 and S2234 are performed.

[0313] In S2236, the development environment 300 assigns the database instance name held in the memory 304 as the connection destination database instance of the account information (the newly added account) added in S2222. More specifically, in the developer information 301, the database instance name held in the memory 304 as the connection destination database instance is recorded in the column indicating the connection destination database instance name (the rightmost column in Fig. 14(a)) of the row of the newly added account. By the processes described in S2232 to S2235, for example, if the threshold 1 is on the developer terminal 10000 and the newly added account is the 9999th valid account, "Database Instance Name 1" is recorded. If the newly added account is the valid account of the 10001st developer terminal, "Database Instance Name 2" is recorded.

[0314] In S2237, the development environment 300 sends a login OK notification to the developer terminal 100. The login OK notification sent here is received by the developer terminal 100 in S2205 described above.

[0315] In S2238, the development environment 300 receives the data to be used as the password sent from the developer terminal 100 in S2210 described above, and registers it as the password of the newly added account information. More specifically, it is recorded in the password column of the row of the newly added account in the developer information 301.

[0316] Figure 23(a) shows the details of the DB set 430 in the multi-tenant execution environment 410. In the DB set 430, initially, a fixed number (one or more) of DB environments (DB instances) are prepared. In this embodiment, assume the fixed number = 1, that is, initially only DB instance 1 (2310) is prepared. Inside DB instance 1, there are a developer information DB 2311 and a DB for each developer. The developer information DB 2311 indicates which database is prepared for each developer (each account). For example, the DB information 2312 of developer A shows the association that the DB of developer A is DB1. In the DB for each developer, there are DB1 (2314), DB2 (2315), DB3 (2316)..., and it increases every time a valid account is registered in the developer information 301. However, the upper limit is the same as the number of threshold 1. When the threshold 1 is for 10,000 developer terminals, DBmax (2317) is the DB for the 10,000th developer terminal, and after that, DBs are created in another DB instance. Inside the DB for each inventor, there are further one or more tables. For example, DB1 (2314) contains multiple tables such as table 1, table 2,.... Note that each DB instance (database environment) is a writable database instance.

[0317] By the process of S2231, before the number of DBs in DB instance 1 reaches the upper limit (threshold 1), the next DB instance 2 is generated. Then, when a valid developer account is additionally registered in the developer information 301 from the state where DBmax (2317) has been generated in DB instance 1, it becomes Yes in S2232, and the additionally registered developer is registered in the developer information 301 to connect to DB instance 2 (2320). Then, DBs for the accounts (developers) added thereafter are generated in DB instance 2 (2320). Note that the number of DBs entering DB instance 2 (2320) is also up to the threshold 1 (cumulatively, up to threshold 1×2), and the accounts registered thereafter are controlled to connect to the next DB instance in the same way.

[0318] Fig. 23(b) shows the details of the DB set 457 in the single-tenant execution environment. Since the single-tenant execution environment is dedicated to one account (one developer), the DB set 457 is also dedicated to one account (one developer). Therefore, it is less likely that there will be an increase in the DB or a concentration of access that would cause a decrease in response. Accordingly, only one DB instance 1 (2350) is prepared as the DB environment for the DB set 457. Also, only the information for one account (for example, the DB information 2352 of developer A) is recorded in the developer information DB 2351. There is no threshold limit for the number of stored DBs. Also, as described in Fig. 22(b), the control for determining the database environment of the single-tenant execution environment to be connected in association with the registered account information is not performed when registering (adding) a new account of the developer.

[0319] <Deployment process> Fig. 24(a) shows a flowchart of the deployment process on the developer terminal 100. This process is a process executed by the developer terminal 100 and is a detailed flowchart of S426 in Fig. 4.

[0320] Fig. 25(a) shows an example display of the UI editor screen when the selected app is a mobile app. The canvas 2501 is a canvas in the shape of a mobile device and is shaped like a smartphone. When the deploy button 506 is pressed, the process in Fig. 24(a) is started.

[0321] In S2401, the developer terminal 100 transmits information instructing the deployment of the selected app to the development environment 300. Note that a save process may be performed to save the latest definition information held in the memory 102 of the developer terminal 100 to the development environment 300 before giving the deployment instruction, and then the deployment instruction may be given.

[0322] In S2402, the developer terminal 100 displays a waiting screen. On the waiting screen, guide information indicating that the deployment is in progress is displayed.

[0323] In S2403, the developer terminal 100 determines whether it has received a deployment failure notification from the development environment 300. If it has received the failure notification, it proceeds to S2404; otherwise, it proceeds to S2405.

[0324] In S2404, the developer terminal 100 displays an error indicating that the deployment has failed. If the deployment fails, the processes of S2407 and S2409 described later are not performed.

[0325] In S2405, the developer terminal 100 determines whether it has received a deployment success notification from the development environment 300. The success notification includes information (URL) of the access destination for accessing the deployed application. If it has received the success notification, it proceeds to S2406; otherwise, it proceeds to S2403.

[0326] In S2406, the developer terminal 100 determines whether the selected application (the deployed application) is for mobile use. If it is for mobile use, it proceeds to S2408; otherwise (i.e., if it is for desktop use), it proceeds to S2407. If it is not for mobile use, the display of the QR code (registered trademark) in S2409 described later is not performed.

[0327] In S2407, the developer terminal 100 displays, in a new tab of the browser software different from the screen (for example, a UI editor screen including a canvas) displayed by the browser software before receiving the deployment instruction, the screen accessed to the URL of the deployed app (the URL for accessing the execution environment) included in the success notification. Thereby, the developer can immediately recognize that the deployment has succeeded. Also, an authentication screen or an initial UI of the deployed app is displayed in the new tab, and by operating on the new tab, the display content and operation of the actual app deployed (already built in the execution environment) can be immediately confirmed and verified. By the process of S2407, the app execution process performed by accessing the URL of the deployed app (the URL for accessing the execution environment) is carried out. The details of the app execution process will be described using the flowchart of FIG. 33(c) or FIG. 35(c).

[0328] In S2408, the developer terminal 100 performs a process of encoding the app URL included in the success notification into a QR code. That is, a QR code (two-dimensional code) including the information of the app URL is generated.

[0329] In S2409, the developer terminal 100 displays the QR code generated in S2409. Since the QR code is displayed in response to the completion (success) of the deployment, the developer can recognize the timing when the deployment is successful. FIG. 25(b) shows an example of the display of the QR code in S2409. FIG. 25(b) is an example of the display of a screen that transitions when the deployment button 506 is pressed from the state of FIG. 25(a) to give a deployment instruction and the deployment is successful. The QR code dialog 2510 is displayed superimposed on the mobile canvas. The QR code dialog 2510 displays the QR code 2511 generated in S2408, a close button 2512, and a button 2513 to open in a new tab. Note that the URL of the app, which is the information contained in the QR code 2511, is different from the URL 2504 displayed in the address bar of the browser displaying the UI editor screen (the URL of the development system (application development platform) of the present embodiment, which is the URL for accessing the developer terminal 100). The QR code 2511 is displayed when the deployment is completed, and is an address for executing the deployed app, and is access destination information indicating the location (execution environment) where the deployment was made.

[0330] The developer (user) can, by photographing and reading the QR code 2511 displayed on the display 105 of the developer terminal 100 with a handheld smartphone (mobile terminal), cause a screen accessing the URL of the deployed app (the URL for accessing the execution environment) to be displayed on the handheld smartphone. Therefore, it is possible to easily access the deployed URL with a small number of operation steps. In this case, the handheld smartphone functions as the app user terminal 201. As a result, an authentication screen or an initial UI of the deployed app is displayed on the handheld smartphone, and by operating the handheld smartphone, it is possible to immediately check and verify the display content and operation of the actual app that has been deployed (configured in the execution environment). Since the operation of the mobile app can be checked and verified on the mobile terminal instead of the developer terminal 100, it is easier to check whether the mobile app is more suitable than when checking and verifying on the developer terminal 100. In addition to or instead of the QR code 2511, a code image other than the QR code, such as a barcode, a Chameleon Code (registered trademark), etc., may be displayed as a code image that can read the URL of the app included in the success notification. Further, the URL itself of the app included in the success notification may be displayed as a character string in the QR code dialog 2510.

[0331] In S2410, the developer terminal 100 determines whether the button 2513 to open in a new tab has been pressed. If the button 2513 to open in a new tab has been pressed, the process proceeds to S2407, and if not, the process proceeds to S2411.

[0332] In S2411, the developer terminal 100 determines whether the close button 2512 has been pressed. If the close button 2512 has been pressed, the process proceeds to S2412, and if not, the process proceeds to S2410. In S2412, the developer terminal 100 hides the QR code dialog 2510 and returns to the screen that was displayed before the deployment instruction.

[0333] Figure 24(b) shows a flowchart of the deployment process. This process is executed by the development environment 300 and starts when the development environment 300 receives a deployment instruction sent from the developer terminal 100 in S2401 of Figure 24(a).

[0334] In S2421, the development environment 300 obtains the definition information of the selected app to be deployed from the definition information of the apps stored in the developer area of the logged-in developer in the storage 320 of the development environment 300. The definition information obtained here includes UI definition information (uiDef.json) and a program for the execution environment (JavaScript), which will be described later.

[0335] In S2422, the development environment 300 determines whether the selected execution environment is a multi-tenant execution environment. If it is a multi-tenant execution environment, the process proceeds to S2423; otherwise (if it is a single-tenant execution environment), the process proceeds to S2424.

[0336] In S2423, the development environment 300 stores the definition information of the selected app obtained in S2421 in the developer area (dedicated folder) of the logged-in developer in the storage 420 of the multi-tenant execution environment 410. More specifically, the development environment 300 sends the definition information of the selected app obtained in S2421 to the multi-tenant execution environment 410 and instructs the multi-tenant execution environment 410 to record it in the developer area (folder for each developer) of the logged-in developer. When this recording is completed without problems, the deployment is successful.

[0337] In S2424, the development environment 300 stores the definition information of the selected app obtained in S2421 in the storage of the single-tenant execution environment that is the selected execution environment (the folder directly under the bucket of the single-tenant execution environment). More specifically, the development environment 300 sends the definition information of the selected app obtained in S2421 to the single-tenant execution environment that is the selected execution environment and instructs the multi-tenant execution environment 410 to record it in the folder directly under the bucket. When this recording is completed without problems, the deployment is successful.

[0338] In S2425, the development environment 300 determines whether the deployment has failed. If the deployment has failed, it proceeds to S2426; otherwise, it proceeds to S2427. The deployment may fail if the definition information cannot be transmitted to and recorded in the execution environment due to a communication failure or the like.

[0339] In S2426, the development environment 300 sends a failure notice indicating that the deployment has failed to the developer's terminal 100.

[0340] In S2427, the development environment 300 determines whether the deployment has been completed (successfully). If the deployment has been completed, it proceeds to S2428; otherwise, it proceeds to S2425.

[0341] In S2428, the development environment 300 sends a success notice of the deployment including the URL information of the deployed app (the access destination information for accessing the app deployed in the execution environment) to the developer's terminal 100. The success notice sent here is received by the developer's terminal 100 in S2405 of FIG. 24(a) described above.

[0342] <UI screen template> The UI screen template will be described. In addition to the UI screen created by the user, there is a UI screen (template screen) prepared in advance as a template on the UI screen. The template screen is a screen in which at least one prototype component with a predefined action defined is arranged at a predefined position even if the user has not arranged UI components on the UI screen in the past. The template screen can be customized for the pre-prepared information. More specifically, the template screen can be displayed on the canvas in the UI editor and edited by the UI editor process described in FIG. 4.

[0343] FIG. 26(a) shows an example of the display of the options of the template screen when the UI screen list is displayed as an option in the sub-menu area 520. This display is performed by the process of S401 in FIG. 4 described above. FIG. 26(a) is an example of expanding and displaying a list of options of the UI screens classified into a plurality of types and belonging to the group of AuthenticationUI (UI screen for authentication, authentication screen). The group name 2610 indicates that the expanded group is AuthenticationUI. When the group name 2610 is pressed, the expansion of the options of AuthenticationUI is folded, and the group names of other groups are displayed in the sub-menu area 520. The options 2611 to 2622 are each an option of one UI screen, and all are prepared in advance as template screens.

[0344] FIG. 26(b) shows an example of the display when the option 2611 is selected and the "Sign in ID", which is the template screen (UI screen) corresponding to the option 2611, is displayed on the canvas 2630. The screen in FIG. 26(b) is displayed in S404 in FIG. 4 described above in response to the option 2611 being pressed. On the canvas 2630, the prototype parts 2631 to 2634 are displayed. The prototype parts 2631 to 2634 are not the ones that the user (developer) drags and drops from the UI part list in the sub-menu area 520, but are prototype UI parts whose display positions (arrangements), colors, sizes, and display contents are defined in advance. The prototype parts 2631 to 2634 are UI parts as follows. · Prototype part 2631: An Output Field, which is a UI part for displaying "Sign In". · Prototype part 2632: A TextField of the Input type, which is a UI part for accepting the input of the email address, which is the username (user ID) of the app. That is, it is a UI part for accepting the input of user-specific information. · Prototype part 2633: It is a UI part of a button and is set (labeled) to display "CREATE ACCOUNT?". An action is preset (pre - defined) to transition to a screen of "Sign Up form", which is a kind of template screen (the screen shown in Fig. 27(c), the UI screen corresponding to option 2614) in response to being pressed. · Prototype part 2634: It is a UI part of a button and is set (labeled) to display "NEXT". An action is predefined to obtain the value (email address) entered in prototype part 2632 and transition to a screen of "Sign in Password", which is a kind of template screen (the screen shown in Fig. 27(a), the UI screen corresponding to option 2612) in response to being pressed.

[0345] Fig. 27(a) shows an example of the display on the canvas of the "Sign in Password" screen. Note that Figs. 27(a) to 27(k) are each partial display examples showing only the part of the canvas when the template screen is displayed on the canvas. The prototype parts 2711 to 2715 arranged on the "Sign in Password" screen are UI parts as follows. · Prototype part 2711: A TextField of the Input type, which is a UI part for accepting the input of the user password of the application. · Prototype part 2712: It is a UI part of a button and is set to display "Forget Password?". An action is predefined to transition to a screen of "Reset Password Step1", which is a kind of template screen (the screen shown in Fig. 27(g), the UI screen corresponding to option 2618) in response to being pressed. · Prototype part 2713: A checkbox that displays "Trust this device for 14 days". · Prototype part 2714: A button labeled "CHANGE EMAIL" is predefined (predefined) to perform an action of returning to the "Sign in ID" screen when pressed. · Prototype part 2715: A button labeled "SIGN IN" is predefined (predefined) to perform an action of sending the value (email address) entered in prototype part 2632, the value (password) entered in prototype part 2711, and the checked state of the checkbox in prototype part 2713 to the execution environment in which the app is built when pressed.

[0346] In the actually built app, in response to pressing the button corresponding to prototype part 2715 displayed on app user terminal 201, the email address serving as the username, the password, and the checked state are sent from app user terminal 201 to the execution environment. In the execution environment, it is verified whether the received combination of email address and password matches the user information 411 of the multi-tenant execution environment (shown in Fig. 14(b)) or the per-user information of the single-tenant execution environment (shown in Fig. 14(c1)). If the verification result is OK for authentication, the user logs in to the app, and the initial UI is displayed on app user terminal 201.

[0347] Similarly, the following shows display examples on the canvas of the template screen. All are screens related to user authentication of the app. · Fig. 27(b): The UI screen corresponding to option 2613. · Fig. 27(c): The UI screen corresponding to option 2614. · Fig. 27(d): The UI screen corresponding to option 2615. · Fig. 27(e): The UI screen corresponding to option 2616. · Fig. 27(f): The UI screen corresponding to option 2617. · Fig. 27(g): The UI screen corresponding to option 2618. · Fig. 27(h): The UI screen corresponding to option 2619. · Figure 27(i): The UI screen corresponding to option 2620. · Figure 27(j): The UI screen corresponding to option 2621. · Figure 27(k): The UI screen corresponding to option 2622.

[0348] Each of the above-described template screens can be customized and, as described in the processing after S405 in FIG. 4, can be edited by the developer using the UI editor. The editable content includes addition of other UI components different from the prototype components, arrangement position of the prototype components, change of the display size, and change of the setting of the properties of the prototype components (change of the display form such as the displayed characters and colors). Also, the actions of the canvas of the template screen can be set and changed. On the other hand, it is assumed that the actions of the prototype components cannot be changed or deleted, and the prototype components cannot be deleted. Also, regarding the normal UI components (UI components that are not prototype components) added to the template screen, it is assumed that the actions cannot be changed or deleted. By doing so, it is possible to prevent an unintended error from occurring due to the modification of the actions required for the authentication process using the cloud service, which may cause the authentication process to malfunction. That is, in the template screen, the actions required for error-free authentication are predetermined for the prototype components and cannot be modified. Therefore, even if the developer customizes the template screen, the authentication process using the cloud service will surely operate properly. The reason for disabling the setting of actions for the normal UI components added to the template screen is to prevent the setting of actions that may cause the authentication to malfunction. For example, if a new button is added to the template screen of "Sign in ID" in FIG. 26(b) and an action is set for the button to transition to a UI screen not related to authentication, the email address and password required for authentication cannot be sent to the execution environment, and the authentication will stop working. Since the destination UI screen is not displayed when the authentication is not OK, the application will not operate properly. Such a problem can be prevented by disabling the setting of actions for the normal UI components added to the template screen.

[0349] FIG. 26(c) shows a display example in which a context menu 2655 of a button 2654 arranged on the canvas of a UI screen that is not a template screen is displayed. Thus, normally, the context menu of a button includes options for actions and deletion. This is the same as what was described in the display example of FIG. 5(d). Therefore, as described in S711 to S720 of FIG. 7, editing such as property editing, action editing, and component deletion is possible.

[0350] FIG. 26(d) shows a display example in which a context menu 2635 of a button 2634 arranged on the canvas of a template screen is displayed. Thus, options for actions and deletion are not displayed in the context menu of the prototype component arranged on the template screen. By this, it is controlled so that action setting and deletion of the prototype component cannot be performed. That is, the action board is not displayed either. Therefore, as described in S721 to S724 of FIG. 7, only property editing (changing the display form) can be performed on the prototype component.

[0351] Figure 26(e) shows an example of the display after editing (customizing) the canvas of the template screen shown in Figure 26(b). The same UI components in Figures 26(b) and 26(e) are labeled with the same reference numerals. UI component 2641 is a UI component of the output type added by the developer, and it is displayed by specifying the image file uploaded by the file management operation of S1217 in Figure 12. If this image is set as the icon or image representing the app, it will be easier for the user to understand which app's authentication screen this is. UI component 2642 is a UI component of the type that outputs a text message added by the developer. Also, as an action for the canvas of this screen, an action of obtaining today's date and displaying the string "Since it is the end of the month, please do not forget to apply" in UI component 2642 if it is the end of the month is set by the developer by opening the action board of the canvas. In this way, it is also possible to arrange UI components (components) whose display content is changed according to the conditions when displaying this authentication screen. The prototype component 2631 is the same UI component (UI component with the same ID) as the prototype component 2631 in Figure 25(b), but the content (label) to be displayed is changed by the developer's property editing operation and is displayed as "Login". In this way, there is a high degree of freedom in screen design for actions other than those essential for authentication. Therefore, for example, it is possible to make the screen easily recognizable by the app user as to which app's authentication screen (login screen) it is, to make the design conform to the in-house standard design determined within the company, or to make a more suitable design screen according to the nature of the app.

[0352] <Example of display of property box> The property box displayed by selecting a property from the context menu of the UI component placed on the canvas will be described.

[0353] FIG. 28(a) shows an example of the display of the property box of the pie chart. FIG. 28 is a screen displayed by selecting properties from among the context menus displayed by right-clicking on the pie chart 531, which is a UI component arranged on the canvas 530, from the display state shown in FIG. 5(b). The process of displaying this screen and the acceptance of the editing process for the displayed property box are performed in S706 of FIG. 7 described above. The property box 2810 is the property box of the pie chart 531. The property box 2810 is displayed together with the pie chart 531 displayed on the canvas 530. The display form such as the ratio and color separation of the circular graph, which is the content displayed on the pie chart 531, is displayed based on the content set in the property box 2810. When the setting content is changed in the property box 2801 and the apply button 2811 is pressed, the display form of the pie chart 531 is updated based on the latest set value (changed set value) of the property box 2801. That is, the developer can perform the setting operation on the property box 2810 while confirming how the display form of the pie chart 531 changes.

[0354] When the pie chart is dragged and dropped from the UI component list onto the canvas and no values are set, the areas for each ratio of the circular graph are not displayed, resulting in a display like just a circle. In this case, the developer cannot intuitively recognize that the placed UI component is a pie chart (circular graph) just by looking at it. To solve this, initial values (default set values that are not set by the developer) predetermined as properties of the pie chart shall be set. By doing so, when the pie chart is dragged and dropped from the UI component list onto the canvas, a circular graph divided into areas by ratio is displayed from the beginning, so that the developer can quickly and intuitively grasp that the placed UI component is a circular graph.

[0355] Among the property boxes 2810, the Value input area 2812 is an area for inputting the ID, numerical value, color, and label (display string) of each area shown in the pie chart 531. If the developer has not set anything, the initial values will be displayed as shown in the figure. In the example shown in the figure, only a part of the initial values is displayed, and by scrolling, it is possible to view from the beginning to the end. Assume that the full text of the initial values displayed in the Value input area 2812 is as follows. Note that "″" is a double quotation mark

[0356] [{"id":"Jan","value":Developer's terminal 100.33,"color":"#394E79","month":"Jan"},{"id":"Feb","value":22.12,"color":"#5E83BA","month":"Feb"},{"id":"Mar","value":53.21,"color":"#C2D2E9","month":"Mar"},{"id":"Apr","value":34.25,"color":"#9A8BA5","month":"Apr"},{"id":"May","value":24.65,"color":"#E3C5D5","month":"May"}] The initial value displayed in the Value input area 2810 is presented in a structure when described in a programming language. Among the full text of the above initial value, the part enclosed by "{" and "}" is one data set corresponding to one area in the pie chart. A set of character strings enclosed by '"' and associated with ":" is a pair of a key name and a key value. For example, in '"id":"Jan"', the key name is "id" and the key value is "Jan". "," is the delimiter between the previous key and the next key. That is, among the full text of the above initial value, the part including multiple sets such as {"id":"Jan","value":developer terminal 100.33,"color":"#394E79","month":"Jan"} is one data set (one set), which contains four pairs of key names and values of id, value, color, and month. It can be seen that there are a total of five similar data sets. Thus, the initial value of the pie chart is a set of settings that includes multiple data sets each containing a default set of settings values.

[0357] The developer can freely edit the initial value displayed in the Value input area 2812 of the Property box 2810 by selecting the Value input area 2812 and entering input from the keyboard. However, since the structure is displayed as described above as the initial value, it is easy to understand where and how to edit. Also, when the Apply button 2811 is pressed, the edited content is reflected in the pie chart 531, so it is possible to confirm how the pie chart 531 changes when the value of a certain structure is changed. Therefore, it is also easy to understand what each part means among the character strings displayed in a structure that can be described in a programming language.

[0358] If all that is required is to be able to set the values for the pie chart, one possible setting method would be to divide the setting items in the property box 2810, such as "ID of Area 1", "Value of Area 1", "Color of Area 1", "Display Label of Area 1", etc., and let the developer input or select values for each. However, in this embodiment, this is not the case. Instead, the initial values are displayed in the structure used when writing in a programming language, and when the developer makes edits, the input is made in a description that follows the structure used when writing in a programming language. This is because the values for the pie chart can be changed by an action that inputs JavaScript into another UI component or the action board of the canvas. If the initial values are displayed in a structure that can be described in a programming language as a copyable text (string), the developer can copy this string to the clipboard using a known copy operation and paste it onto the action board (i.e., perform a copy and paste operation). Then, by simply modifying only the characters in the part where changes are desired on the action board, it becomes possible to easily describe an action to change the display content of the pie chart. By doing so, when a developer wants to describe an action to change the display form of the pie chart, it is possible to prevent the situation where the developer does not know how to describe it and thus cannot describe the intended action, or spends a great deal of time researching how to describe it. That is, more efficient software development can be achieved. Since it is a programming language, it can also be edited with a high degree of freedom when other edits are desired.

[0359] Fig. 29 shows an example of the display of an action board when an action to change (specify) the display form (display content) of the pie chart 531 is input by the developer to an action board of another UI component (button) different from the pie chart 531 arranged by the developer. The illustrated action board 2900 is a description area (input area) for describing in a programming language the actions to be executed when a button is pressed in the built application. Among the character strings (character strings in JavaScript) displayed on the action board 2900, the second to the 32nd lines are based on the initial values displayed in the Value input area 2812 of the property box 2810, with line breaks added for readability, and only the numerical values 2901 to 2951 are edited (changed). Of course, other parts may be changed, or addition or deletion of the data set (the part enclosed by "{}") may be performed. In this way, input of actions in a programming language becomes very easy. When the button corresponding to this action board is pressed in the built application, the pie chart is displayed in a display form based on the content described in this action board instead of the initial value.

[0360] Similar to the pie chart, an initial value (default setting value) is set for the list among the UI components, and it is displayed in accordance with the structure when the initial value is described in a programming language in the property box. Fig. 28(b) shows an example of the display of the property box 2820 of the list 2802. As shown in the figure, the initial value is displayed in the Value input area 2821 in accordance with the structure when it is described in a programming language.

[0361] Similar to the pie chart, an initial value (default setting value) is also set for the LINE CHART (line chart) among the UI components, and in the property box, it is displayed in accordance with the structure when the initial value is described in a programming language. Fig. 28(c) shows an example of the display of the property box 2830 of the LINE CHART 2803. In the input areas 2831 to 2834, as shown in the figure, it is displayed in accordance with the structure when the initial value is described in a programming language.

[0362] Similar to the pie chart, an initial value (default setting value) is also set for the data grid (table), combo box, tab component, stepper, and breadcrumbs among the UI components, and in the property box, it is displayed in accordance with the structure when the initial value is described in a programming language. Fig. 28(d) shows an example of the display of the property box 2840 of the data grid 2804. In the input area 2841, as shown in the figure, it is displayed in accordance with the structure when the initial value is described in a programming language. The initial value of the data grid includes data sets for multiple rows, with the values of each column for each row of the data grid regarded as one set of data.

[0363] <Settings of Data Grid Properties and Actions> Fig. 30 shows a flowchart of the context menu processing of the data grid on the developer's terminal 100. This process is the detailed flowchart of S705 in Fig. 7 described above. This process is executed by the developer's terminal 100.

[0364] In S3001, the developer terminal 100 displays a context menu for the data grid. Fig. 31(a) shows an example of the display of the context menu for the data grid. The data grid 3110, which is a UI component arranged on the canvas 530, has six columns, namely columns 3111 to 3116. Note that the dotted line surrounding the data grid 3110 is an auxiliary line on the drawing shown for the purpose of indicating the whole of the data grid 3110 and is not something that is actually displayed. A context menu 3120 for the data grid is displayed in the vicinity of the mouse cursor. At least a property 3121 and an action 3122 are displayed as options that are menu items in the context menu 3120.

[0365] In S3002, the developer terminal 100 determines whether or not the property 3121 among the options included in the context menu 3120 has been pressed (selected). If the property 3121 has been pressed (selected), the process proceeds to S3010; otherwise, it proceeds to S3003.

[0366] In S3003, the developer terminal 100 determines whether or not the action 3122 among the options included in the context menu 3120 has been pressed (selected). If the action 3122 has been pressed (selected), the process proceeds to S3020; otherwise, it proceeds to S3004.

[0367] In S3004, the developer terminal 100 determines whether or not other options among the options included in the context menu 3120 have been pressed (selected). If other options have been pressed (selected), the process proceeds to S3005; otherwise, it proceeds to S3006.

[0368] In S3005, the developer terminal 100 performs other processing according to the pressing (selection) of other options. For example, if the option to delete is selected, the data grid, which is the specified UI component, is deleted (removed) from the canvas.

[0369] In S3006, the developer terminal 100 determines whether there is an operation to close the context menu (for example, an operation of clicking outside the area where the context menu is displayed). If there is an operation to close the context menu, in S3007, the context menu is hidden and the process of FIG. 30 ends. If there is no closing operation, the process returns to S3002.

[0370] In S3010, the developer terminal 100 displays the property box of the data grid which is the specified UI component. FIGS. 31(b) to 31(f) show display examples of the property box of the data grid. In FIGS. 31(b) to 31(f), the same display items are given the same reference numerals. The apply button 3131 in FIG. 31(b) is a button icon that instructs to reflect the content input in the property box (the changed setting content). When the apply button 3131 is pressed, based on the latest setting content of the property box, the display form of the data grid which is the specified UI component arranged on the canvas displayed together with the property box is changed. The column selection bar 3132 is a selection tab for selecting the column for which the setting is to be changed. In the property box of the data grid, a screen for accepting settings for each column is displayed, and the settings of the properties for each column are accepted. The column addition button 3133 is a display item that instructs to add a column to the data grid which is the specified UI component.

[0371] In S3011, the developer terminal 100 determines whether a tab corresponding to any column in the column selection bar 3132 in the property box has been pressed. That is, it determines whether any column has been selected as the setting target. If a tab corresponding to any column has been pressed, the process proceeds to S3012; otherwise, it proceeds to S3013. Among the tabs (options) displayed in the column selection bar 3132, the leftmost tab (not shown) is a tab labeled "DataGrid" and is used to display a setting screen for performing settings related to the entire data grid, which is a specified UI component. Only this "DataGrid" tab is not related to a specific column (does not select a specific column).

[0372] In S3012, the developer terminal 100 switches the display content of the area below the column selection bar 3132 in the property box to the setting screen (element screen) related to the selected column. Fig. 31(c) shows a display example when the tab 3132E (the tab labeled "CompanyE") in the column selection bar 3132 is selected. In the area below the column selection bar 3132 in the property box, the upper area 3134t of the setting screen for tab 3132E is displayed as a screen for accepting the settings of the column corresponding to tab 3132E. For example, it includes a type setting column 3135 for selecting the component type of the column. The setting screen of tab 3132E continues further downward, and by scrolling, the lower part can be further displayed. Fig. 31(d) shows a display example when scrolled to display the lower area 3134d of the setting screen of tab 3132E. The lower area 3134d includes a column deletion button 3136 for instructing the deletion of the column corresponding to tab 3132E itself, and an apply button 3137 for instructing to apply the content set in the setting screen of tab 3132E and reflect it on the data grid displayed on the canvas. The column selection bar 3132 moves upward with the scrolling and disappears within the property box, but it will be displayed again if the scrolling is reversed so that the upper area 3134t is displayed. Note that when the "DataGrid" tab is selected in S3011, the display content of the area below the column selection bar 3132 in the property box is switched to the setting screen for making settings related to the entire data grid.

[0373] In S3013, the developer terminal 100 determines whether the column addition button 3133 in the property box has been pressed. If the column addition button 3133 has been pressed, it proceeds to S3014; otherwise, it proceeds to S3015.

[0374] In S3014, the developer terminal 100 performs column addition processing. In the column addition processing, first, the column addition form 3138 shown in FIG. 31(e) is displayed, and the developer (user) is prompted to set the ID and label (name of the column to be displayed) of the column (column of the table) to be added. Then, when the ADD TO Value button is pressed, a new column is added, and a tab corresponding to the new column is added to the column selection bar 3132.

[0375] FIG. 31(f) shows an example of the display of the property box when a column is added. Compared with FIG. 31(c), a tab 3032F (tab labeled "CompanyF") corresponding to the new column is added to the column selection bar 3132. Immediately after the addition, the added column is selected, and the upper area 3139t of the setting screen of the tab 3032F corresponding to the added column is displayed in the area below the column selection bar 3132. Thus, in this embodiment, the addition of a column to the data grid (table) is performed by an operation on the property box which is the setting screen of the data grid.

[0376] In S3015, the developer terminal 100 determines whether there has been a setting operation for the selected column. Specifically, it determines whether there has been an input operation to the various setting fields in the setting screen displayed in the area below the column selection bar 3132. If there has been an input operation to the setting field, the process proceeds to S3016; otherwise, it proceeds to S3017.

[0377] In S3016, the developer terminal 100 receives a setting operation and reflects it in the display. For example, it receives the setting of the type for the type setting field 3135. In this way, for each column, the data grid can select the type as a component (part). As options for the type of component that can be set for a column, TextInput, NumberInput, ComboBox, Multi-Select, CheckBox, DataPicker, Link, Button, and IconButton are displayed, and the developer can select and set any one of them. Also, at least a part of the other configurable items (setting items) changes according to the type of the selected component. For example, when TextInput is selected as the type, the following are included in the other setting items: ValueType, ID, Label (the string displayed as the column name), Width (the width of the column), NumberFormat, DataFormat, Options, Footer, FooterText, Sorting, Visibility. Also, the setting items that can be set in the setting screen for the entire data grid corresponding to the "DataGrid" tab include the following: ID (the UI component ID of the data grid), the size (width, height) of the entire data grid, whether it is editable in the deployed app, whether to display an add row button for instructing row addition to the data grid in the deployed app, whether to display a delete button for the data grid, whether to display an update button for the data grid, etc.

[0378] In S3017, the developer terminal 100 determines whether the apply button 3131 or the apply button 3137 has been pressed. If the apply button 3131 has been pressed, it proceeds to S3018; otherwise, it proceeds to S3019.

[0379] In S3018, the developer terminal 100 records the content set in the property box in the definition information held in the memory 102, and changes the display form of the data grid, which is a specified UI component displayed on the canvas of the UI editor, reflecting the set content. For example, if a column is added, the data grid is displayed in a form with one additional column, and if the width of a column is changed, the width of the column of the data grid on the canvas is changed for display.

[0380] In S3019, the developer terminal 100 determines whether or not the end button 3140 has been pressed. If the end button 3140 has been pressed, the property box is made invisible and the process of FIG. 30 ends. If the end button 3140 has not been pressed, the process proceeds to S3011.

[0381] In this way, it is possible to more operably perform column addition to the data grid (table) and setting operations for each column. In particular, the operation of adding a column to the data grid can be performed by an operation on the property box of the data grid, and the setting operation regarding the added column can be directly performed within the same property box. That is, a series of operations including column addition and setting operation of the added column can be smoothly performed with the same operation feeling as an operation on the property box. Also, after adding a column, since the type is set from among the options that can be set as components of the column, it is possible to perform column addition and type setting without confusion.

[0382] In S3020, the developer terminal 100 displays, as sub - menus of the context menu, options for actions for each column. Fig. 32(a) shows an example of the display in S3020. Fig. 32(a) is an example of the display when action 3122 is pressed from the state of Fig. 31(a). The same symbols are assigned to the same displayed items in Fig. 31(a) and Fig. 32(a). The sub - menu 3210 is displayed as the sub - menu of action 3122 of the context menu 3120. The sub - menu 3210 includes options 3211 to 3217. Option 3211 is an option to open the action board of the action to be executed according to the operation on the entire data grid 3110. Options 3212 to 3217 are options to open the action boards of the column - by - column actions to be executed when each column of the data grid 3110 is operated. Options 3212 to 3217 correspond to columns 3111 to 3116 respectively. At this time, options corresponding to the action boards of columns of data grids different from the data grid of the specified UI component are not displayed.

[0383] In S3021, the developer terminal 100 determines whether any one of the options for the action of the entire data grid (option 3211) or the options for the action by column (3212 to 3217) is selected. If an option for any action is selected, it proceeds to S3022; otherwise, it waits for a selection in S3021.

[0384] In S3022, the developer terminal 100 displays the action board corresponding to the selected option of the action.

[0385] Fig. 32(b) shows an example of the display of an action board corresponding to the options (option 3211) of the actions of the entire data grid. The "DATA GRID" is selected in the selection area 3220 of the whole or the column, indicating that the action board 3211a is the area for inputting the actions of the entire data grid. The trigger for executing the content set in the action board 3211a is predetermined, and the pressing of the button related to the whole, which is displayed outside the column of the area of the data grid, which is a specified UI component in the constructed application, serves as the trigger. In other words, this trigger is a trigger related to the data grid (table) which is a specified UI component, and is a trigger independent of the columns of the data grid. The button related to the whole is the button that is displayed by setting to the setting screen corresponding to the "DataGrid" tab of the property box described above. For example, it is the delete button of the data grid and the update button of the data grid described above. Therefore, the developer does not need to set (does not need to describe in JavaScript) what the trigger for executing the action is. For example, in this action board 3211a, actions such as calculating the total of all rows of a specific column and displaying it in another UI component, saving the content displayed in the data grid to the database, and performing a screen transition to another UI screen can be set by describing in JavaScript.

[0386] FIG. 32(c) shows an example display of an action board corresponding to options (option 3212) for actions of a specific column in a data grid. In the selection area 3220, "MONTH" is selected, indicating that the action board 3212a is an area for inputting actions for the column (column 3111) whose label or column ID is "MONTH". The trigger for executing the content set in the column action board 3212a is predetermined. In a built application, among the specified UI components, the trigger is that the value of a cell in any row of the corresponding column is changed, or a button displayed in a cell in any row of the corresponding column is pressed. Therefore, the developer does not need to set (nor does it need to be described in JavaScript) what the trigger for executing the action is. For example, in this action board 3212a, an action can be set to calculate the sum of the value of the row with the change in the column corresponding to the action board 3212a and the value of another first column in the same row, and display it in another second column in the same row. An example of this action is an action such as when there is a change in the numerical value in the first column of a table, display the sum of the changed numerical value in the first column and the numerical value in the second column in the third column of the same row. That is, it is possible to accept the setting of an action that affects other columns in the data grid, which is a specified UI component, different from the column corresponding to the selected option 3212.

[0387] Note that by selecting other columns in the selection area 3220, it is possible to switch and display the action boards for other columns even after the action board is opened.

[0388] In S3023, the developer terminal 100 accepts an input operation of an action on the displayed action board. This process is the same as the processes of S802 to S823 in FIG. 8 described above.

[0389] In S3024, the developer terminal 100 determines whether there is an operation to close the action board (an operation to end the action board process). If there is no operation to close the action board, the process proceeds to S3023 and the process is repeated. If there is an operation to close the action board, the action board is made invisible, the display is switched to the canvas of the selected UI screen, and the process returns to the UI editor process.

[0390] In this way, for each column included in the data grid (table), actions can be set with better operability. In particular, as shown in the sub-menu 3210, in order to list all the options corresponding to the action boards of all the columns included in the data grid (table), the developer can recognize that actions can be set for each column, and the possibility of omission in setting actions for columns can be reduced. Also, since it is displayed as a sub-menu of the context menu of the data grid which is a specified UI component, the relationship with the specified UI component, the data grid, can be clearly grasped. That is, the design work can be carried out while clearly understanding which column of which data grid the action set on the action board relates to without confusion.

[0391] <Action execution related processing> Fig. 33(a) shows a flowchart of the save process (recording control process) executed by the development environment 300 which is the recording destination of the definition information. This process is a process that is executed in conjunction with receiving the definition information transmitted from the developer terminal 100 in S422 of Fig. 4 described above.

[0392] Also, Fig. 34 illustrates the transition of the information recorded in the developer terminal 100, the development environment 300, the execution environment 400, and the application user terminals 200 and 201. Fig. 34 is a diagram schematically showing the state of the transition of the information by the processes of the flowcharts of Figs. 33(a) to 33(c).

[0393] In S3301 of FIG. 33(a), the development environment 300 determines whether it has received the definition information (UI definition information) of the selected application from the developer terminal 100. The definition information received here is the one transmitted from the developer terminal 100 in S422 of FIG. 4 described above. If the UI definition is received, the process proceeds to S3302; otherwise, it waits in S3301.

[0394] In FIG. 34, the UI definition information 3401 recorded in the memory 102 of the developer terminal 100 is the definition information received in S3301. In this embodiment, it is assumed that the UI definition information is a text file described in JSON format with the file name "uiDef.json". Json is short for JavaScript Object Notification, a document standard for handling values in JavaScript and a data description language. The UI definition information 3401 includes various setting contents related to the application such as the initial UI, and information (arrangement position, size, color, etc.) of UI components (UI parts) for each UI screen. Further, the UI definition information 3401 includes an action description part 3402. This action description part 3402 is a character string input to the action board or function setting screen (including the creation function setting screen) of each UI part, canvas, or function. The action description part 3402 includes actions described in JavaScript and function definitions in Json format that describe the contents set on the function setting screen without inputting JavaScript. This UI definition information 3401 is transmitted (uploaded) from the developer terminal 100 to the development environment 300 and received by the development environment 300 in S3301.

[0395] In S3302, the development environment 300 stores the UI definition information in the area for the logged-in developer in the storage 320. As a result, as shown in FIG. 34, the UI definition information 3411 is recorded in the development environment 300. Immediately after this storage, the UI definition information 3411 recorded in the development environment 300 is the same information as the UI definition information 3401 recorded in the developer terminal 100.

[0396] In S3303, the development environment 300 extracts action information from the UI definition information saved in S3302. That is, the development environment 300 extracts the action description part 3412 from the UI definition information 3411 in FIG. 34.

[0397] In S3304, the development environment 300 generates a program for the execution environment from the action description part 3412 extracted in S3303 and saves it in the area for the logged-in developer in the storage 320. That is, based on the action description part 3412 extracted from the UI definition information 3411 in FIG. 34, a program 3413 for the execution environment is generated and saved in the development environment. The program 3413 for the execution environment is text data described in JavaScript. The program 3413 for the execution environment is a program obtained by adding a supplementary part necessary for execution by the execution engine of the execution environment to the string that was input to the action board obtained from the action description part 3412.

[0398] The UI definition information 3411 and the program 3413 for the execution environment saved in the development environment 300 by the saving process described in FIG. 33(a) are deployed (arranged, saved, recorded, constructed) to the execution environment 400 by the deployment process. This process is performed in S2423 or S2424 of FIG. 24 described above. As a result, as shown in FIG. 34, the UI definition information 3421 and the program 3423 for the execution environment are recorded in the execution environment 400. The UI definition information 3421 and the program 3423 for the execution environment in the execution environment 400 are the same information as the UI definition information 3411 and the program 3413 for the execution environment, respectively. This state is the state where the application has been generated.

[0399] FIG. 33(b) shows a flowchart of the application execution process in the execution environment 400. This process is a process executed by the execution engine of the execution environment 400, and is a process executed when there is an access to the deployed (constructed, generated) application from the application user terminals 200 or 201.

[0400] Fig. 33(c) shows a flowchart of the app execution process on the app user terminal 200 or 201. This process is executed by the CPU 101 of the app user terminal 200 or 201, and is a process executed when the browser software of the app user terminal 200 or 201 accesses an application that has been deployed (constructed, generated) in the execution environment 400. Also, the app execution process in the execution environment 400 in Fig. 33(b) and the app execution process on the app user terminal 200 or 201 in Fig. 33(c) are processes that are performed in conjunction. Hereinafter, the process by the app user terminal 200 or 201 will be described as being executed by the app user terminal 200 as a representative (the description regarding the app user terminal 201 is omitted because it is the same).

[0401] In S3311 of Fig. 33(b), the execution environment 400 determines whether it has received a request to obtain UI definition information sent from the app user terminal 200. The request to obtain UI definition information received here is the one sent from the app user terminal 200 in S3333 of Fig. 33(c) described later. If the request to obtain UI definition information is received, the process proceeds to S3312; otherwise, it waits in S3311.

[0402] In S3312, the execution environment 400 sends the UI definition information to the app user terminal 200. As a result, as shown in Fig. 34, the UI definition information 3421 recorded in the execution environment 400 is downloaded to the app user terminal 200 and recorded as UI definition information 3431. The UI definition information 3421 and the UI definition information 3431 are the same information.

[0403] In S3313, the execution environment 400 determines whether it has received an action request from the terminal 200 for the app user. An action request is a request to execute the content of an action input to the action board. The action request received here is the one sent from the terminal 200 for the app user in S3345 of FIG. 33(c) described later. If an action request is received, it proceeds to S3314; otherwise, it proceeds to S3320.

[0404] In S3314, the execution environment 400 determines whether it has received the value of an input item from the terminal 200 for the app user. The value of an input item is the value input by the user on the terminal 200 for the app user for a UI component classified as an input item among the UI components displayed on the app screen. For example, it is the text input to a Textfield. In this embodiment, the determination in S3314 shall be a determination as to whether the value of the input item is included in the action request received in S3313. If the value of the input item is received (if the value of the input item is included in the action request), it proceeds to S3315; otherwise, it proceeds to S3316.

[0405] In S3315, the execution environment 400 temporarily stores the received value of the input item in the memory included in the execution engine.

[0406] In S3316, the execution environment 400 executes the requested action by executing the program 3424 for the execution environment. If the value of the input item has been received, the action is also executed using the value of the input item. For example, the portion of the program 3424 for the execution environment that is the requested action is executed with the value of the input item as an argument.

[0407] In S3317, the execution environment 400 determines whether there is a value of the output item, which is the value to be displayed on the app screen displayed on the terminal 200 for the app user, as a result of the execution of the action in S3316. For example, when the action is an action such as "perform arithmetic operations", the solution of the operation is obtained as the value of the output item. Also, for example, when the action is an action such as "transition the screen" or "record in the database", there may be no value of the output item as a result of the action. If there is a value of the output item, it proceeds to S3318, and if not, it proceeds to S3319.

[0408] In S3318, the execution environment 400 generates action result information including the value of the output item as the result information of the action executed in S3316.

[0409] In S3319, the execution environment 400 transmits the result information of the action executed in S3316 to the terminal 200 for the app user. If the action result information including the value of the output item was generated in S3318, the value of the output item will also be transmitted to the terminal 200 for the app user. Then, in S3348 of FIG. 33(c) described later, the value of the output item is displayed on the screen of the terminal 200 for the app user. The result information of the action may include an instruction to transition the screen. If an instruction to transition the screen is included, a screen transition occurs on the app screen displayed on the display 105 of the terminal 200 for the app user by the process of S3347 of FIG. 33(c) described later.

[0410] In S3320, the execution environment 400 determines whether to end the process. If the execution environment 400 determines to end the process (Yes in S3320), it ends the process. If the execution environment 400 determines not to end the process (No in S3320), the process returns to S3313. For example, when an event to end the app described later occurs in S3350, it determines to end the process. In S3331 of FIG. 33(c), the application user terminal 200 (including the application user terminal 201, but hereinafter the application user terminal 200 will be described as an example) uses Internet browser software to access the application that has been deployed (constructed, generated) in the execution environment 400. More specifically, in response to an operation of specifying and accessing the URL of the deployed application (the URL for accessing the execution environment) (for example, an operation of clicking on the link of the application's URL or an operation of entering the application's URL in the address bar and pressing the Enter key), the application's URL is accessed (connected).

[0411] In S3332, the application user terminal 200 determines whether it has received the client program. When the execution environment 400 detects an access from the application user terminal 200, the distribution engine of the execution environment (the one of the distribution engines 415, 455, 465, 475, etc. of the accessed execution environment) transmits the client program recorded in the storage (the one of the client programs 422, 456c, 466c, 476c, etc. of the accessed execution environment) to the application user terminal 200. In S3332, it is determined whether the client program has been received. If the client program has been received, the process proceeds to S3333; otherwise, the reception of the client program is awaited in S3332.

[0412] In S3333, the application user terminal 200 transmits a request to obtain UI definition information to the execution environment 400. In the client program received in S3332, it is defined that when accessing the execution environment, a request to obtain UI definition information should be issued first. S3333 is the corresponding processing. The request to obtain UI definition information transmitted here is received by the execution environment 400 in S3311 of FIG. 33(b) described above.

[0413] In S3334, the terminal 200 for app users determines whether it has received UI definition information from the execution environment 400. The UI definition information received here is the one transmitted from the execution environment 400 in S3312 of FIG. 33(b) described above. If the UI definition information is received, it is recorded in the memory 102 and the process proceeds to S3335. Otherwise, the reception of the UI definition information is awaited in S3334. The UI definition information is recorded as temporary information in the memory 102 (working memory) and is automatically deleted in response to the termination of the app (in response to the termination of the connection to the app's URL). Also, the terminal 200 for app users displays the app screen on the display 105 based on the UI definition information recorded in the memory 102.

[0414] In S3335, the terminal 200 for app users determines whether an action trigger has occurred. Specifically, in the app screen, it is determined whether there is an operation instructing screen transition (activation trigger for the action of the destination canvas), or an operation on the UI component displayed on the app screen (action trigger for the UI component by click or the like). If there is an action trigger, the process proceeds to S3336. Otherwise, the process proceeds to S3350.

[0415] In S3336, the terminal 200 for app users extracts the description part regarding the action to be executed according to the trigger detected in S3335 from the UI definition information (UI definition information 3431 in FIG. 34) recorded in the memory 102. This description part is information of text (character string) described in JavaScript (programming language).

[0416] In S3337, the terminal 200 for app users searches for the character string "$ui" in half-width from the beginning in the description part extracted in S3336.

[0417] In S3338, the terminal 200 for app users determines whether the character string "$ui" exists as a result of the search in S3337. If "$ui" exists, the process proceeds to S3339. Otherwise, the process proceeds to S3343.

[0418] In S3339, the application user terminal 200 determines whether the character string "$ui" found in S3338 is on the left side within a sentence containing the character. A "sentence" (one sentence) is a character string in a programming language until it is delimited by a line termination symbol (e.g., semicolon ";") or a closing parenthesis "}". That is, two sentences are delimited by a line termination symbol or a closing parenthesis ('}'). If the "$ui" found by the search is located to the left of "=" (equal sign) within a sentence, it is determined to be on the left side. If "$ui" is on the left side, proceed to S3340; otherwise, proceed to S3341.

[0419] In S3340, the application user terminal 200 records, as an output item, information based on the element character string ($ui.UI component ID.type of information to be targeted) starting with "$ui" found in S3338 in the item definition list (item definition list 3433 in FIG. 34) generated in the memory 102. Specifically, the UI component ID (item code, component identifier) is obtained from the element character string ($ui.UI component ID.type of information to be targeted) delimited by "." (period) starting with "$ui", and it is recorded that the UI component is an output item. For example, when a trigger related to action A occurs, and "$ui" is found in the description part related to action A, and it is on the left side and the UI component ID is "UI component ID3", as in the item definition list 3433 in FIG. 34, it is recorded that there is UI component ID3 in the output item. Note that the item definition list 3433 is information temporarily held in the memory 102 which is a work memory, and it is automatically erased according to whether the result of the action is received and reflected in the output item (No in S3348 or the process of S3349 ends) or the application is terminated (Yes in S3350).

[0420] In S3341, the terminal 200 for the app user determines whether the character string "$ui" found in S3338 is located other than on the left side within a sentence containing the character. The case of being other than on the left side means being on the right side (to the right of "=") or being in the part not containing "=". If it is other than on the left side, the process proceeds to S3342; otherwise, it proceeds to S3337. Note that if it is determined as No in S3339, since it is synonymous with the character string "$ui" being other than on the left side within a sentence containing the character, it may be configured to proceed to S3342 without making the determination in S3341.

[0421] In S3342, the terminal 200 for the app user records, as input items, information based on the element character string ($ui.UI component ID.type of information to be targeted) of a predetermined structure starting with "$ui" found in S3338 in the item definition list (item definition list 3433 in FIG. 34) generated in the memory 102. Specifically, the UI component ID (item code, component identifier) is obtained from the element character string ($ui.UI component ID.type of information to be targeted) of a predetermined structure starting with "$ui", and it is recorded that the UI component is an input item. For example, when a trigger related to action A occurs, "$ui" is found in the description part related to action A, it is on the right, and the UI component ID is "UI component ID1", then as in the item definition list 3433 in FIG. 34, it is recorded that there is UI component ID1 as an input item. Also, for example, when a trigger related to action A occurs, "$ui" is found in the description part related to action A, it is in a sentence without "=", and the UI component ID is "UI component ID2", then as in the item definition list 3433 in FIG. 34, it is recorded that there is UI component ID2 as an input item.

[0422] When the process of S3342 ends, it proceeds to S3337. In the subsequent part of the description part extracted in S3336, it further searches for the character string of "$ui", and repeats the processes of S3339 to S3342 until it is determined in S3338 that there is no "$ui". That is, for all the character strings of $ui included in the description part extracted in S3336, the processes of S3339 to S3342 are performed, and it is recorded in the item definition list 3433 whether it is an input item or an output item.

[0423] In S3343, when it is determined in S3335 that there is an action trigger, the application user terminal 200 determines whether there is a value in the information targeted by the input items recorded in the item definition list 3433. For example, if it is described as "$ui.UI component ID1.value" in the description part extracted in S3336, it determines whether there is a value in the information of the type "value" within the UI component of UI component ID1. If the UI component of UI component ID1 is a TextField, value is the text (character string) input into that TextField. That is, for UI component ID1 which is a TextField displayed on the screen of the application, it determines whether the application user has input text with the keyboard, and if text has been input, it determines Yes, and if it is blank, it determines No. This determination is made for all the input items recorded in the item definition list 3433. If there is a value in the information targeted by the input item, it proceeds to S3344, and if not, it proceeds to S3345.

[0424]

[0425] ​In S3345, the terminal 200 for app users transmits an action request to the execution environment 400, which requests the execution of an action corresponding to the trigger detected in S3335. If an action with values in input fields has been generated in S3344, the values of the input fields are also transmitted to the execution environment 400. For example, as the value of the input field, information on the text input by the app user using the keyboard for the UI component ID1, which is a TextField displayed on the app screen shown on the display 105 of the terminal 200 for app users, is transmitted to the execution environment 400. The above-mentioned action request transmitted here is received by the execution environment 400 in S3313 of FIG. 33(b) executed in the execution environment 400, and an action corresponding to the trigger detected in S3335 is executed in the execution environment 400 as described in S3314 to S3319.

[0426] In S3346, the terminal 200 for app users determines whether it has received the result of the action corresponding to the action request transmitted in S3345 from the execution environment 400. If it has received the result of the action, it proceeds to S3347; otherwise, it waits for the reception of the result of the action in S3346.

[0427] In S3347, the terminal 200 for app users updates the app screen displayed on the display 105 by reflecting the result of the action received in S3346. Also at this time, the display is performed based on the UI definition information held in the memory 102. For example, if the result of the action indicates a screen transition, the screen transition is executed.

[0428] In S3348, the terminal 200 for app users determines whether the result of the action received in S3346 includes the value of the output field. If the value of the output field is included, it proceeds to S3349; otherwise, it proceeds to S3350.

[0429] In S3349, the application user terminal 200 displays the value of the output item included in the result of the action received in S3346 on the output item to be displayed on the display 105 based on the information of the output item recorded in the item definition list 3433 held in the memory 102. As a result, for example, if the type of the target information is value, text or numerical values that are the values of the output item are displayed in the UI component of the output item, or if the type of the target information is color, the color of the UI component of the output item is changed to the color indicated by the value of the output item.

[0430] In S3350, the application user terminal 200 determines whether there is an event to terminate the application. Examples of events to terminate the application include disconnection of the connection to the access destination indicated by the application's URL (closing the Internet browser, turning off the power of the application user terminal 200, changing the connection to another unrelated URL, etc.). If there is no event to terminate the application, the process proceeds to S3335. If there is an event to terminate the application, the process of FIG. 33(c) is terminated with the application screen hidden.

[0431] Taking the string in the programming language input to the action board 910 shown in FIG. 10(d) as an example, the process of discriminating and sorting whether the string including "$ui" described in S3338 to S3342 is an input item or an output item will be described more specifically.

[0432] The second line reads "const userid = $ui.text_field_a.value;". In this sentence, since "$ui" is on the right side, in the process of S3342, "text_field_a" is recorded as an input item in the item definition list. That is, the value input by the user in "text_field_a" on the application screen is obtained and set as the value of the variable "userid".

[0433] In the sentence on the 4th line, since the string including “$ui” and “$ui.text_area_a.value” is on the left side, in the process of S3340, “text_area_a” is recorded as an output item in the item definition list. That is, the value indicated on the right side of “=” (the output value obtained as a result of the action) will be displayed on the UI component “text_area_a”. In addition to the definition that “text_area_a” is an output item, this sentence also includes the process (logic) of outputting the value indicated on the right side of “=” (the output value obtained as a result of the action) to the output item. Thus, in a sentence including logic (a process different from the definition of at least one of the input item and the output item), the ability to define the input item and the output item is one of the characteristic parts of this embodiment. Similarly, on the 6th line, it is also a logic part, and since “$ui.text_area_a.value” is on the left side, it is treated as an output item.

[0434] Also, the following shows an example of the character string of the action where “$ui” exists in the sentence without “=”.

[0435] (The numbers at the beginning of each line are auxiliary characters indicating the line number and are not part of the main text of the programming language.) 1 SQLSave({ 2 PREF_CODE: $ui.PREF_CODE.value, 3 PREF_NAME: $ui.PREF_NAME.value 4}); 5 / / Screen transition 6 $fn.nextUI('List_ip_demo'); The above character string in the programming language is an action to register the input values (`$ui.PREF_CODE.value`, $ui.PREF_NAME.value) of the app screen to the database using them as parameters of the SQLSave function. In this case, $ui.{component ID}.{type of target information} used as a parameter of the SQLSave function is identified as indicating an input item (since it is not on the left side of “=”).

[0436] Also, in an element string of a predetermined structure using "$ui", the type of information to be targeted may be other than value, for example, it may be a color. For example, by describing "$ui.UI component ID.color = \"#008000\";", the color of the UI component can be changed.

[0437] In the present embodiment, in the description of the action input to the action board, depending on the position of the element string with the specific identifier of "$ui" in the string (more specifically, the position in one sentence), whether the UI component indicated by the element string is treated as an input item or as an output item can be described (defined). Conventionally, whether to use it as an input item or an output item was set on a setting screen separate from the area where the content of the action was input in the programming language. Alternatively, conventionally, even when described in the area where the content of the action was input in the programming language, it was necessary to make a declaration using a variable indicating whether to handle it as an input item or an output item in a sentence separate from the sentence of the logic part indicating the process itself. In contrast, in the present embodiment, the definition of the input item and the output item can be defined at any description location of the string in which the action logic is described in the programming language. Therefore, the input items and output items used in the logic can be defined near the logic description part, and when describing the logic, the input items and output items used in the logic can be easily set. Also, in the present embodiment, it is not necessary to define the value passing between the function setting screen and the description part of the action logic for the input item and the output item as a variable once. Therefore, the need for the developer to perform complicated variable management is reduced, and variable management becomes easy. Accordingly, the factors causing mistakes when describing the action are reduced, and mistakes can be reduced. In this way, in the present embodiment, it is possible to more easily set the input item or / and the output item used in the logic input in the programming language.

[0438] In addition, since the method of indicating whether it is an input item or an output item based on the position of the element string with a specific identifier of "$ui" is not common, in the execution of a program based on the ordinary JavaScript programming language, whether it is an input item or an output item cannot be interpreted properly and does not operate as intended. Therefore, in the present embodiment, by performing a process of specifying and sorting whether the string including "$ui" described in S3338 to S3342 is an input item or an output item, a mechanism that operates correctly is provided.

[0439] In the present embodiment, an example in which a specific identifier is the half-width "$ui" has been described, but it is not limited to this. Any string that is not confused with other existing identifiers in the programming language may be used as an identifier. For example, it may be the half-width "_inputoutput". The half-width "$" is the Unicode dollar sign. The half-width "_" is the Unicode underscore.

[0440] Also, in the present embodiment, as described in S3304 of FIG. 33(a), the development environment 300 generates an execution environment program 3414, which is a program to be executed in the execution environment 400 based on the UI definition information, and deploys it to the execution environment 400. When the application is executed, the application user terminal 200 executes processing based on the UI definition information 3431, and the execution environment 400 executes processing based on the execution environment program 3423. Also, as described in S3338 to S3342 of FIG. 33(c), the application user terminal 200 generates an item definition list 3433 necessary for the processing to be executed on the application user terminal 200 based on the UI definition information. By doing so, when developing an application by accessing the development environment 300 from the developer terminal 100, the developer of the application does not need to particularly distinguish between the information required for the processing to be executed in the execution environment 400 and the information required for the processing to be executed on the application user terminal 200. Therefore, when developing an application, the developer does not need to explicitly distinguish the information used by the execution environment and the terminal device, respectively, when the application is executed, reducing the labor of managing and developing, and making software development easier.

[0441] In addition, in this embodiment, an example of generating the execution environment program 3414 during the save process in the development environment 300 has been described. However, the development environment 300 may not generate the execution environment program 3414. Instead, after recording the UI definition information 3421 in the execution environment 400, the execution environment 400 may generate the execution environment program 3423 based on the UI definition information 3421.

[0442] <Modification Example of Action Execution Related Processing> FIG. 35(a) shows a modified flowchart of the save process (recording control process) executed by the development environment 300 which is the recording destination of the definition information. This process is a process that is executed in conjunction with receiving the definition information transmitted from the developer terminal 100 in S422 of FIG. 4 described above.

[0443] Also, FIG. 36 illustrates a modified example of the information transition recorded in the developer terminal 100, the development environment 300, the execution environment 400, and the application user terminals 200 and 201. FIG. 36 is a diagram schematically showing the state of information transition by the processes of the flowcharts in FIGS. 35(a) to 35(c). In FIG. 36, the same information as in FIG. 34 is denoted by the same reference numerals.

[0444] In FIG. 36, instead of performing the process of generating the item definition list 3433 based on the UI definition information in the application user terminal 200, the development environment 300 generates the client UI definition information 3615 based on the UI definition information. Then, this client UI definition information 3615 is deployed to the execution environment 400 (recorded in the execution environment 400 as the client UI definition information 3625), and further transmitted from the execution environment 400 to the application user terminal 200 (recorded in the application user terminal 200 as the client UI definition information 3635). When an action is executed, the application user terminal 200 performs processing based on the client UI definition information 3635.

[0445] In FIG. 36, unlike FIG. 34, a configuration is adopted in which UI definition information is not transmitted to the terminal 200 for app users (nor is it temporarily recorded on the terminal 200 for app users). By doing so, it is possible to prevent the detailed definition of the developed app from leaking through the terminal 200 for app users, and enhance the confidentiality of the configuration of the developed app. Therefore, for example, the possibility of a third party creating an app that mimics at least a part of the developed app (e.g., the JavaScript code described in the action board) can be reduced. Also, on the terminal 200 for app users, it is not necessary to perform the process of analyzing the UI definition information and generating the item definition list 3433 every time an action trigger occurs (the processes of S3338 to S3342 in FIG. 33(c)). Accordingly, the processing load on the terminal 200 for app users can be reduced, and an app operation with a comfortable response (response speed) can be realized.

[0446] S3501 to S3504 in FIG. 35(a) are the same processes as S3301 to 3304 in FIG. 33(a) described above, so the description thereof is omitted. In FIG. 35(a), in addition to the process of FIG. 33(a), the processes after S3505 are performed.

[0447] In S3505, the development environment 300 generates UI definition information 3615 for the client. Assume that the UI definition information 3615 for the client is a Json-formatted file with a file name such as "uiDef2.json". The UI definition information 3615 for the client includes, as information obtained from the UI definition information 3411, various setting information about the application such as the initial UI, information about UI components (components) for each UI screen (contents set by the UI component ID and properties, arrangement position and size of the UI component, etc.), identifiers for canvas actions, identifiers for UI component actions, etc. Also, in the UI definition information 3615 for the client, input / output item definitions for each action (definitions of which components are in the input items and output items respectively) are also recorded. At the time of S3505, the content of the input / output item definitions for each action is not inserted (inserted in the processes of S3506 to 3512 described later). Also, assume that the string (action source code) described in JavaScript (programming language) written on the action board itself is not recorded. That is, the generated UI definition information 3615 for the client includes identifiers for actions and information about input / output item definitions for each action, but does not include information indicating the operation content of the actions.

[0448] In S3506, the development environment 300 extracts the action description part 3412 from the UI definition information 3411. In this process, not only the description about a specific action but also the description parts about all actions are extracted.

[0449] In S3507, the development environment 300 searches for the character string "$UI" from the beginning in the action description part extracted in S3506.

[0450] In S3508, the development environment 300 determines whether the character string "$ui" exists as a result of the search in S3337. If "$ui" exists, it proceeds to S3509; otherwise, the process ends. The case where it is No in S3508 is when all searches for "$ui" are completed or there is no "$ui" at all in the action description part.

[0451] In S3509, the development environment 300 determines whether the character string "$ui" found in S3508 is on the left side within a sentence containing the character, similar to S3339 in FIG. 33(c). If "$ui" is on the left side, it proceeds to S3510; otherwise, it proceeds to S3511.

[0452] In S3510, the development environment 300 records, as an output item, information based on the element character string ($ui.UI component ID.type of information to be targeted) starting with "$ui" found in S3338 in the client UI definition information 3615 generated in S3505. More specifically, among the client UI definition information 3615, the UI component ID is obtained from the element character string ($ui.UI component ID.type of information to be targeted) starting with "$ui" found in S3338, and is recorded in the "uiItemsOut" array in the input / output item definition for each action in the array defining the output items. For example, if "$ui" indicating that the UI component ID is "RESULT" is found on the left side, it is recorded as shown in FIG. 36.

[0453] In S3511, the development environment 300 determines whether the character string "$ui" found in S3508 is on a side other than the left side within a sentence containing the character, similar to S3341 in FIG. 33(c). If it is on a side other than the left side, it proceeds to S3512; otherwise, it proceeds to S3507. Note that if it is determined as No in S3509, since it is synonymous with the character string "$ui" being on a side other than the left side within a sentence containing the character, it may proceed directly to S3512 without making the determination in S3511.

[0454] In S3512, the development environment 300 records, as input items, information based on an element character string ($ui.UI component ID.type of information to be targeted) with a predetermined structure starting with "$ui" found in S3338, in the client UI definition information 3615 generated in S3505. More specifically, from the element character string ($ui.UI component ID.type of information to be targeted) with a predetermined structure starting with "$ui" found in S3338, the UI component ID is obtained and recorded in the "uiItemsIn" array among the input / output item definitions for each action, in the array that defines the input items in the client UI definition information 3615. For example, if a "$ui" indicating that the UI component ID is "INPUT_1" is found on the right side, it is recorded as shown in FIG. 36. Also, for example, if a "$ui" indicating that the UI component ID is "INPUT_2" is found in a sentence without an "=", it is recorded as shown in FIG. 36.

[0455] After finishing the process of S3512, it proceeds to S3507, and in the subsequent part of the description part extracted in S3506, the string of "$ui" is further searched, and the processes of S3507 to S3512 are repeated until it is determined in S3508 that there is no "$ui". That is, for all the strings of $ui included in the description part extracted in S3506, the processes of S3509 to S3512 are performed, and whether it is an input item or an output item is recorded in the client UI definition information 3615.

[0456] FIG. 35(b) shows a flowchart of a modified example of the application execution process in the execution environment 400. This process is a process executed by the execution engine of the execution environment 400, and is a process executed when there is an access to a deployed (constructed, generated) application from the application user terminal 200 or 201.

[0457] FIG. 33(c) shows a flowchart of a modified example of the application execution process in the application user terminal 200 or 201. This process is a process executed by the CPU 101 of the application user terminal 200 or 201, and is a process executed when the browser software of the application user terminal 200 or 201 accesses an application that has been deployed (constructed, generated) in the execution environment 400. Also, the application execution process in the execution environment 400 in FIG. 35(b) and the application execution process in the application user terminal 200 or 201 in FIG. 35(c) are processes that are performed in conjunction. Hereinafter, the process by the application user terminal 200 or 201 will be described, representing the one executed by the application user terminal 200 (the description regarding the application user terminal 201 is omitted because it is the same).

[0458] In S3521 of FIG. 35(b), the execution environment 400 determines whether it has received a request for acquiring UI definition information transmitted from the application user terminal 200. The request for acquiring UI definition information received here is the one transmitted from the application user terminal 200 in S3543 of FIG. 35(c). If the request for acquiring UI definition information is received, the process proceeds to S3522; otherwise, it waits in S3521.

[0459] In S3522, the execution environment 400 transmits the client UI definition information 3615 to the execution environment 400 without transmitting the UI definition information 3411 to the application user terminal 200. As a result, as shown in FIG. 36, the client UI definition information 3625 recorded in the execution environment 400 is downloaded to the application user terminal 200 and recorded as the client UI definition information 3635. The client UI definition information 3615 and the client UI definition information 3635 are the same information.

[0460] The processes of S3523 to S3530 are the same as the processes of S3313 to S3320 in FIG. 33(b) described above, and thus the description thereof is omitted.

[0461] S3541 to S3543 in FIG. 35(c) are the same processes as S3331 to S3333 in FIG. 33(c) described above, so the description thereof is omitted. However, in S3543, a request for acquiring client UI definition information is transmitted.

[0462] S3544 is for the application user terminal 200 to determine whether it has received client UI definition information from the execution environment 400. The client UI definition information received here is the one transmitted from the execution environment 400 in S3522 of FIG. 35(b) described above. If the client UI definition information is received, the client UI definition information is recorded in the memory 102 and the process proceeds to S3545. Otherwise, the process waits for the reception of the client UI definition information in S3544. The client UI definition information is temporarily recorded as information in the memory 102 (working memory) and is automatically deleted when the application is terminated (when the connection to the application URL is terminated). Also, the application user terminal 200 displays the application screen on the display 105 based on the client UI definition information 3635 recorded in the memory 102.

[0463] In S3545, the application user terminal 200 determines whether an action trigger has occurred, similar to S3335 in FIG. 33(c) described above. If there is an action trigger, the process proceeds to S3546. Otherwise, the process proceeds to S3553.

[0464] The processes of S3546 to S3553 are the same processes as S3343 to S3350 in FIG. 33(c) described above, so the description thereof is omitted. The processes corresponding to S3336 to S3342 in FIG. 33(c) described above are not performed by the application user terminal 200 in the modified example.

[0465] Note that each type of control described in the above flowcharts may be performed by one piece of hardware, or the entire control of the device may be performed by a plurality of pieces of hardware (for example, a plurality of processors or circuits) sharing the processing. In addition, although the present invention has been described in detail based on its preferred embodiments, the present invention is not limited to these specific embodiments, and various forms within the scope not departing from the gist of the present invention are also included in the present invention. Furthermore, each of the above-described embodiments merely shows one embodiment of the present invention, and it is also possible to appropriately combine each embodiment

[0466] <CRUD generation process after the second time> FIG. 37 shows a flowchart of the context menu process of the canvas. This process is the detailed flowchart of S703 in FIG. 7 described above and is substantially the same as FIG. 19. The differences from FIG. 19 are S3701 to S3705.

[0467] The flowchart of FIG. 37 is for the case where program source code (e.g., (b) and (d) in FIG. 21) generated by the first CRUD generation process performed in S1907 to S1913 in FIG. 19, or program source code (e.g., (a) in FIG. 38) customized (added, changed, deleted, etc.) by the user already exists, and the second and subsequent CRUD generation processes are performed on the same canvas area. When using the flowchart of FIG. 19 for the second and subsequent CRUD generation processes on the same canvas area, the program source code customized by the user will be overwritten and disappear.

[0468] Therefore, when performing the second and subsequent CRUD generation processes on the same canvas area, by performing S3701 to S3705 in FIG. 37, it becomes possible to leave the program source code customized by the user as a comment without overwriting it.

[0469] Each process in FIG. 37 will be described. The same or similar configurations are given the same reference numerals, and duplicate explanations are omitted. The process in FIG. 37 is executed by the developer terminal 100 in the same manner as in FIG. 19.

[0470] S1907, S1909, and S1911 in FIG. 37 display the content selected in the first CRUD generation process performed in FIG. 19. The displayed content can be changed by the user. Thereby, in the CRUD generation process after the second time, while inheriting the content of the first CRUD generation process, it can be easily customized.

[0471] In S3701, the developer terminal 100 determines whether a selection operation is performed on the input form 3 and whether the NEXT icon (not shown) of the input form 3 is pressed. If the NEXT icon is pressed, the process proceeds to S3702; otherwise, it waits for the NEXT icon to be pressed in S3701.

[0472] In S3702, the developer terminal 100 displays the CRUD input form 4 (dialog box) and accepts the selection operation of the database and table to be the CRUD target. FIG. 38(b) shows an example of the display of the CRUD input form 4. In the input form 4, there are a radio button 3802 for "overwrite the existing code" and a radio button 3803 for "comment out the existing code and add".

[0473] These radio buttons are for cases where there is already program source code, such as the program source code generated by the first CRUD generation process (e.g., FIGS. 21(b)(d)), or the program source code customized (added, changed, deleted, etc.) by the user (e.g., FIG. 38(a)), etc., and when performing the CRUD generation process after the second time for the same canvas area, radio buttons for selecting "overwrite the existing code" or "comment out the existing code and add".

[0474] In S3703, if the radio button 3802 for "overwrite the existing code" is selected, the developer terminal 100 proceeds to S3704; if the radio button 3803 for "comment out the existing code and add" is selected, it proceeds to S3705.

[0475] In S3704, the developer terminal 100 deletes the existing code and generates new program source code (3801 in FIG. 38) based on the content selected in inputs 1 to 3. In S3705, the developer terminal 100 comments out the existing code (3805 in FIG. 38) and adds the new program source code generated based on the content selected in inputs 1 to 3 before the comment out (3804 in FIG. 38).

[0476] Since the program source code in the action board of FIG. 38 is JavaScript, the comment out is done by adding / / at the beginning of each line as in 3805. Of course, instead of / / , it may also be commented out by surrounding the whole of 3805 with / *~* / . Also, since the source code of the function in FIG. 38(d) is SQL, -- (3806 in FIG. 38) which is a SQL comment is used. In this way, the method of comment out shall be changed according to the programming language (e.g., #, ‘REM, etc.).

[0477] That is, this step shows an example of a process for controlling to comment out and display the source code string when the source code generation process is performed again. Also, this step shows an example of a process for controlling to comment out and display the source code string when the generated source code is already displayed.

[0478] As described above, since the user-customized program source code can be left as a comment without overwriting, in the low-code development tool, even when the user customizes the source code once generated, the customized source code remains as a comment, so that it becomes easy to re-edit or customize again after the source code is regenerated.

[0479] Also, in this embodiment, in the case of the first CRUD generation process, the flowchart in FIG. 19 is used, and in the case of the second and subsequent CRUD generation processes, the flowchart in FIG. 38 is used. However, it is also possible to use the flowchart in FIG. 38 for both the first and the second and subsequent times. In that case, even in the first CRUD generation process, radio buttons for selecting "overwrite existing code" or "comment out existing code and add" will be displayed. However, in that case, no matter which one is selected, it is assumed that the first program source code (e.g., (b) and (d) in FIG. 21) will be generated. Th...

Claims

1. Control means for defining an action on a screen of application software constructed based on an operation group including an operation of selecting from options without including an operation of writing source code in a programming language, or for controlling to arrange an automatically generated component in which an action is defined as a component displayed on the screen of the application software to be constructed; Display control means for controlling to display, in a character string in a programming language, the action defined for the selected target in response to a selection of either the screen on which the action is defined by the control means or the automatically generated component and an instruction to display the action; The display control means controls to comment out and display the character string when being controlled again by the control means An information processing system characterized by the above.

2. The information processing system according to claim 1, wherein the operation group is an operation group for creating CRUD buttons.

3. The operation group includes input of information regarding a destination database, The information processing system according to claim 1, wherein the reception means is capable of receiving a modification operation regarding the destination database for the character string.

4. The information processing system according to claim 1, wherein the reception means is capable of receiving a modification operation for the character string, the modification operation being to change at least one of a message and a screen displayed in response to execution of an action.

5. The information processing system according to claim 1, wherein the reception means is capable of receiving a modification operation for the character string, the modification operation being to change a component that is a target for acquiring and / or outputting information during execution of an action.

6. The reception means is capable of receiving an operation of adding a function that can be used in a character string in a programming language representing the action displayed by the display control means The information processing system according to claim 1, characterized by the above.

7. The information processing system according to claim 1, wherein the reception means receives a description operation in a programming language as the modification operation.

8. The information processing system according to claim 1, wherein the operation group is an operation group for creating a workflow.

9. The operation group includes a screen selection operation before and after a procedure in a workflow and a selection operation of an action type when transitioning to the next procedure. The information processing system according to claim 8, wherein the control means controls to generate an automatically generated component in which an action when transitioning to the next procedure in the workflow is defined and arrange it on the screen of the transition source.

10. The information processing system according to claim 1, further comprising processing means for processing so that the application software is constructed to execute an action reflecting the correction operation received by the reception means in response to the display of the screen in which an action is defined in the constructed application software or the operation of the automatically generated component.

11. The information processing system according to claim 10, wherein the processing means processes so that the application software is constructed by deploying definition information of the application software including information indicating an action reflecting the correction operation received by the reception means from a development environment to an execution environment.

12. The information processing system according to claim 1, wherein the display control means controls to comment out and display the character string when the character string has already been displayed.

13. Selection reception means for receiving a selection as to whether to comment out The information processing system according to claim 1, further comprising the same.

14. Based on an operation group including an operation of selecting from options without including an operation of describing source code in a programming language, defining an action for a screen of application software to be constructed, or controlling to arrange an automatically generated component in which an action is defined as a component displayed on the screen of the application software to be constructed; A display control step of controlling to display, in a character string in a programming language, an action defined for the selected target in response to a selection of either the screen in which an action is defined by the control step or the automatically generated component and an instruction to display the action. The display control step controls to comment out and display the character string when the control is performed again by the control step. A control method for an information processing system, characterized by the above.

15. A program for causing at least one computer to function as each means of the information processing system according to any one of Claims 1 to 13.

Images