Information processing systems, information processing methods, and programs

Abstract

In an application development system, this provides a mechanism for sharing definition information for building applications. [Solution] An information processing system characterized by comprising: a first storage unit which is a storage unit that can share definition information of an application set by a first user with a second user; and a control means which controls the copying of the definition information stored in the first storage unit to a second storage unit which stores the definition information set by the second user, in response to an operation by the second user.

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 particularly to a technique suitable for use in application construction. 【Background Art】 【0002】 Conventionally, there is an application construction system that constructs an application according to a definition as a no-code development tool / low-code development tool that does not require or requires little code description in a programming language. 【Prior Art Documents】 【Patent Documents】 【0003】 【Patent Document 1】 Japanese Patent Application Laid-Open No. 2018-67218 【Disclosure of the Invention】 【Problems to be Solved by the Invention】 【0004】 Patent Document 1 discloses a technique for automatically generating an application by setting definition information. 【0005】 However, in this technique, in order for a user (app developer) of an application development support system to generate an application, one user needs to set definition information. Team development in which multiple people work together while sharing definition information is not considered. 【0006】 In addition, recent application development support systems have many no-code tools that do not require program coding and low-code tools that require little program coding, and a mechanism different from the mechanism for version management of programs coded by developers as in conventional scratch development is required. 【0007】 Therefore, in an application development system, a mechanism is needed to share definition information for building the application in order for multiple people to work on it. 【0008】 Therefore, the objective of the present invention is to provide a mechanism for sharing definition information for building applications within an application building system. [Means for solving the problem] 【0009】 An information processing system characterized by comprising: a first storage unit which is a storage unit that can share definition information set by a first user with a second user; and control means which controls the copying of the definition information stored in the first storage unit to a second storage unit which stores the definition information set by the second user, in response to an operation by the second user. [Effects of the Invention] 【0010】 According to the present invention, an application building system can provide a mechanism for sharing definition information for building applications. [Brief explanation of the drawing] 【0011】 [Figure 1] This is a system configuration diagram of an information processing system. [Figure 2] This is a hardware block diagram of developer terminal 100, app user terminal 200, and app user terminal 201. [Figure 3] This is an example of a login process flowchart. [Figure 4] This is an example of a flowchart for UI editor processing. [Figure 5] This is an example of how login and UI editor processes are displayed. [Figure 6] This is an example of how tab components and the AppBar are displayed in a UI editor. [Figure 7]This is an example of a flowchart for context menu processing. [Figure 8] This is an example of a flowchart for action board processing. [Figure 9] This is a display example for explaining action board processing. [Figure 10] This is a display example in action board processing. [Figure 11] This is an example of the source code generated by the development environment 300. [Figure 12] This is an example of a flowchart for screen switching processing. [Figure 13] This is an example of a flowchart of the processes respectively executed in the developer terminal 100, the development environment 300, and the execution environment 400 regarding the display of the user information of the application. [Figure 14] (a) This is a specific example of the developer information 301. (b) This is a specific example of the user information 411 in the multi-tenant execution environment. (c) This is a specific example of the user information in the single-tenant execution environment. [Figure 15] This is a display example of user information. [Figure 16] This is an example of a flowchart for workflow processing. [Figure 17] This is a display example regarding workflow processing. [Figure 18] This is a display example of the database, UI components, and actions generated by workflow processing. [Figure 19] This is an example of a flowchart for the context menu processing of the canvas. [Figure 20] This is a display example regarding CRUD generation processing. [Figure 21] This is a display example of the database, actions, and functions generated by CRUD generation processing. [Figure 22] This is an example of a flowchart for developer account registration processing. [Figure 23] This is an example of the details of the DB set in the execution environment. [Figure 24] This is an example of a flowchart for deployment processing. [Figure 25] This is an example of how it looks when deploying a mobile app. [Figure 26] This is an example of how the template screen is displayed in the UI editor screen. [Figure 27] This is an example of how the template screen will look on the canvas. [Figure 28] This is an example of how the properties box looks. [Figure 29] This is an example of how an action board looks when an action has been entered. [Figure 30] This is an example of a flowchart for processing context menus in a data grid. [Figure 31] This is an example of how the properties box of a data grid will appear. [Figure 32] This is an example of how the action board in a data grid will appear. [Figure 33] This is an example of a flowchart for executing an action. [Figure 34] This is an example of a transition diagram for UI definition information, including action information. [Figure 35] This is an example of a flowchart showing the execution of actions in a modified example. [Figure 36] This is an example of a transition diagram of UI definition information, including action information in a modified example. [Figure 37] This is a system configuration diagram of the information processing system according to the second embodiment. [Figure 38] This is an example of a flowchart for the repository creation process. [Figure 39] This is an example of the display related to the repository creation process. [Figure 40] This is an example of a flowchart for the commit process. [Figure 41] This is an example of the display related to the commit process. [Figure 42] This is an example of a flowchart for the checkout process. [Figure 43] This is an example of a display related to the checkout process. [Figure 44] This is an example of a block diagram showing the software configuration of the second embodiment. [Modes for carrying out the invention] 【0012】 The embodiments will be described in detail below with reference to the attached drawings. Note that the following embodiments do not limit the invention as defined in the claims, and not all combinations of features described in the embodiments are essential to the invention. Two or more features from the multiple features described in the embodiments may be combined arbitrarily. Furthermore, identical or similar configurations will be given the same reference numeral, and redundant descriptions will be omitted. 【0013】 The various features shown in the embodiments below can be combined with each other. In the following, "application" and "app" both refer to application software. 【0014】 <System configuration of the first embodiment> Figure 1 shows a system configuration diagram of an information processing system as an embodiment of the present invention. Figure 1 shows a system for performing software development and a system for using the developed software. 【0015】 The developer terminal 100 is an information processing device (information processing terminal) operated by a developer user, which can be configured as a personal computer (hereinafter referred to as PC) or smartphone. In other words, it is the user terminal of the developer user. The developer terminal 100 receives design operations for the 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. 【0016】 The development environment 300 is an environment built on a network (on the cloud, on the internet) using at least one hardware resource. The development environment 300 is a multi-tenant environment, allowing multiple developer users to log in. The development environment 300 includes developer information 301, an execution engine 302, and storage 320. The development environment 300 is built by combining multiple web services (cloud services). 【0017】 Developer information 301 is information that records the account of a developer who can log in to the development environment 300, such as the email address (user ID) which is the developer's account ID, and the password. Developer information 301 is recorded on at least one recording medium included in the development environment 300. Details of developer information 301 will be described later using Figure 14(a). 【0018】 The execution engine 302 is at least one hardware resource for executing processes to be run in the development environment 300, and includes a processor 303 and memory 304. The processor 303 consists of at least one processor, which may be a single processor on the cloud or a group of processors combined together. The memory 304 is at least one recording medium that stores the program 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, this is achieved by the processor 303 loading the program stored in memory 304 into the work memory area of ​​the development environment 300 and executing it. 【0019】 The distribution engine 305 sends a client program 322 (such as HTML source code or JavaScript source code) to be executed on the developer terminal 100, which has accessed the development environment 300. The client program 322 is pre-recorded in the storage 320 included in the development environment 300. 【0020】 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 account. For example, if there are developers A, B, and C who can log in, it includes a developer A area 323 for developer A, a developer B area 324 for developer B, and a developer C area 325 for developer C. Each developer area stores definition information for the application developed by each developer. For example, developer A area 323 stores the application definition 323a (including the application UI definition information and the application execution environment program, which will be described later in Figure 34). 【0021】 The developer accesses the development environment 300 by accessing a URL for the development environment 300 from the browser software on the developer terminal 100, and logs into the development environment. Upon logging into the development environment, the developer receives the client program 322 and the application definition (UI definition information), which is the content of the development work previously performed and saved, from the development environment. Then, the developer performs an operation to design a new application or an operation to design an update for an existing (work-in-progress) application, and sends the resulting application definition information (application definition, UI definition information) to the development environment 300. The development environment 300 saves the received application definition in its developer area. Thus, 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 applications. Therefore, as long as there is a terminal that can connect to the internet, developers can develop applications regardless of location. 【0022】 The execution environment 400 is an environment built on a network (on the cloud, on the internet) using at least one hardware resource. The execution environment 400 includes a multi-tenant execution environment 410 and multiple single-tenant execution environments (e.g., single-tenant execution environments 450, 460, 470). The execution environment 400 is built by combining multiple web services (cloud services). The execution environment 400 is the environment where definition information (app definition) for applications developed using the developer terminal 100 and development environment 300 is deployed. App user terminals 200 and 201, used by users of the application, access the execution environment 400 by accessing a URL for application execution. The execution environment 400 then executes various actions in response to operations performed on the app user terminals 200 and 201, thereby running the developed application and providing the application's functionality to the app user. Applications built on the execution environment 400, which is located on the network, are so-called web applications. 【0023】 The multi-tenant execution environment 410 is a multi-tenant execution environment shared by multiple developers, and applications developed by multiple developers are deployed there. In other words, it is an environment shared by multiple developers, and an environment in which multiple applications from multiple developers can be built. The multi-tenant execution environment 410 includes user information 411, execution engine 412, delivery engine 415, storage 420, and DB set 433. 【0024】 User information 411 is information that records the account of an application user who can log in to the deployed application (built application), such as the email address (username) and password, which will be the user account ID of the deployed application (built application). User information 411 is recorded on at least one recording medium included in the multi-tenant execution environment 410. 【0025】 The execution engine 412 is at least one hardware resource for executing processes to be run in the multi-tenant execution environment 410, and includes a processor 413 and memory 414. The processor 413 consists of at least one processor, which may be a single processor on the cloud or a group of processors combined together. The memory 414 is at least one recording medium that stores the program 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, this is achieved by the processor 413 loading the program stored in memory 414 into the work memory area of ​​the multi-tenant execution environment 410 and executing it. The program executed here includes a program that performs application actions. 【0026】 The distribution engine 415 sends client programs 422 (such as HTML source code or JavaScript source code) to be executed on 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. 【0027】 Storage 420 is a storage area of ​​at least one recording medium and stores at least a client program 422 that is common to multiple applications. In addition, a predetermined area of ​​storage 420 (a predetermined folder, a predetermined bucket, a predetermined hierarchy) records access destination information 421 for accessing the execution environment (multitenant execution environment 410). It also has developer areas, which are storage areas for each developer account. For example, this includes developer A area 423 for developer A, developer B area 424 for developer B, and developer C area 425 for developer C. Each developer area stores definition information of the application developed by each developer and deployed from the development environment 300. For example, the application definition 423a is recorded in developer A area 423. 【0028】 DB set 430 is a set of information about the databases used by the applications deployed in the execution environment 410. DB set 430 is stored in the storage area of ​​at least one recording medium. Details of DB set 430 will be described later with reference to Figure 23. 【0029】 Single-tenant execution environments 1(450), 2(460), and 3(470) are each dedicated execution environments for one developer (one developer account), and applications developed using development environment 300 by the owner developer are deployed to them. In this embodiment, for example, the owner of single-tenant execution environment 1(450) is developer A, the owner of single-tenant execution environment 2(460) is also developer A, and the owner of single-tenant execution environment 3(470) is developer B. In this way, one developer can own multiple single-tenant execution environments. 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, respectively. These functions are similar to 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 a single developer; therefore, a detailed explanation will be omitted. It is possible to build many more single-tenant execution environments than the three shown in the diagram. 【0030】 Using the system shown in Figure 1, for example, the operator could provide the multi-tenant execution environment 410 to developers free of charge and the single-tenant execution environment for a fee. Both the multi-tenant execution environment 410 and each single-tenant execution environment require the system operator to pay maintenance costs to the resource and service providers (cloud service providers). By bearing the maintenance costs of the multi-tenant execution environment 410 and providing it free of charge to multiple developers, developers do not need to bear any costs for trial use of the system, making it more accessible to many developers and promoting its widespread adoption. The operator recovers costs by charging developers for the single-tenant execution environments. 【0031】 There is a limit to the number of processing requests that can be handled per unit of time in a single execution environment. If many applications are built in a multi-tenant execution environment and many app users access it simultaneously, the requests may not be processed properly, potentially leading to slow application performance. In addition, there are some limitations on deploying and running many applications developed by many developers in a multi-tenant execution environment, and these limitations may prevent applications from achieving sufficient performance. Developers can avoid (or mitigate) these problems caused by the limitations of multi-tenant execution environments by owning a dedicated, single-tenant execution environment for a fee. In other words, by building applications in a single-tenant execution environment, it is possible to build applications that can achieve sufficient performance. 【0032】 Taking into account the characteristics of both the multi-tenant single environment and the single-tenant execution environment, developers can utilize this system in the following ways. For example, when using this system for the first time, developers can build an application developed using this system in the multi-tenant execution environment 410 and test it. After determining that the system is beneficial to their software development, they can then purchase the single-tenant execution environment. Alternatively, when a developer is developing a specific application X, they can build an alpha version of application X in the multi-tenant execution environment 410 for a limited number of test users to try before releasing it to general users. There, they can test application X, make corrections, and continue development. After development is complete to a level where it can be released to general users without problems, they can build the production version of application X in the single-tenant execution environment and release it to general users. By using it in this way, developers can reduce development costs during the development period and operate applications that can be used by a large number of general users without problems. 【0033】 Figure 2 shows a hardware block diagram of an information processing device as an example of a device (electronic device) that can be used as a developer terminal 100, an application user terminal 200, and an application user terminal 201. In Figure 2, the CPU 101, memory 102, non-volatile memory 103, image processing unit 104, display 105, operation unit 106, recording medium I / F 107, external I / F 109, and communication I / F 110 are connected to the internal bus 150. Each part connected to the internal bus 150 is configured to exchange data with each other via the internal bus 150. 【0034】 Memory 102 consists of, for example, RAM (volatile memory using semiconductor elements). The CPU 101 controls each part of the information processing device using memory 102 as work memory, according to a program stored in, for example, non-volatile memory 103. Non-volatile memory 103 stores image data, audio data, other data, and various programs for the operation of the CPU 101. Non-volatile memory 103 consists of, for example, a hard disk (HD) or ROM. 【0035】 The image processing unit 104 performs various image processing operations on image data stored in the non-volatile memory 103 or recording medium 108, video signals acquired via the external I / F 109, image data acquired via the communication I / F 110, and captured images, based on the control of the CPU 101. The image processing operations performed by the image processing unit 104 include A / D conversion, D / A conversion, image data encoding, compression, decoding, resizing, noise reduction, and color conversion. The image processing unit 104 may be composed of dedicated circuit blocks for performing specific image processing operations. Furthermore, depending on the type of image processing, the CPU 101 may perform image processing according to a program without using the image processing unit 104. 【0036】 The display 105 displays images and GUI (Graphical User Interface) screens based on the control of the CPU 101. The CPU 101 generates display control signals according to the program and controls each part of the information processing device to generate video signals for display on the display 105 and output them to the display 105. The display 105 displays images based on the output video signals. The information processing device itself is configured to have an interface for outputting video signals for display on the display 105, and the display 105 may be an external monitor (such as a television). Hereinafter, in the processes executed by the developer terminal 100, the application user terminal 200, and the application user terminal 201, the display destination will be the display 105 of each operator unless otherwise specified. 【0037】 The operation unit 106 is an input device for receiving user input, including a keyboard and other text information input devices, a mouse and a touch panel, buttons, dials, joysticks, touch sensors, and a touchpad. The touch panel is a flat input device superimposed on the display 105, and outputs coordinate information corresponding to the position of contact. 【0038】 The recording medium interface (I / F) 107 is capable of receiving recording media 108 such as memory cards, CDs, and DVDs, and, based on the control of the CPU 101, reads data from the received recording media 108 and writes data to the recording media 108. The external interface (I / F) 109 is an interface for connecting to external devices via wired or wireless cables and for inputting and outputting video and audio signals. The communication interface (I / F) 110 is an interface for communicating with external devices and the internet (I / F) 111 to send and receive various data such as files and commands. The developer terminal (I / F) 100 can communicate with the development environment (I / F) 300 on the internet (I / F) 111 using the communication interface (I / F) 110. The application user terminals (I / F) 200 and 201 can communicate with the execution environment (I / F) 400 on the internet (I / F) 111 using the communication interface (I / F) 110. 【0039】 <Login process> Figures 3(a) and 3(b) show the flowchart of the login process. This process involves logging into the development environment 300 from the developer terminal 100 and displaying the UI editor. When the developer terminal 100 receives an instruction to launch the internet browser software and access the development system (application development platform) of this embodiment by specifying its URL, the process shown in Figure 3(a) begins. The process in Figure 3(a) is realized by the CPU 101 of the developer terminal 100 expanding 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 into memory 102 and executing them. Hereafter, anything simply described as a process executed by the developer terminal 100 will be understood as the process by which the CPU 101 of the developer terminal 100 expands 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 into memory 102 and executes them. 【0040】 When a developer launches an internet browser on the developer terminal 100 and accesses 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 sends the client program 322 to the developer terminal 100 that accessed it. 【0041】 In S301, the developer terminal 100 determines whether or not it has received the client program 322 sent from the development environment 300. If it has not received it, it waits for reception in S301, and if it has received it, it proceeds to S302. 【0042】 In S302, the developer terminal 100 records the client program 322 received from the development environment 300 into memory 102. 【0043】 In S303, the developer terminal 100 displays a login screen on the display 105 according to the client program 322. The login screen displays a message indicating that it is the login screen for the development system of this embodiment, as well as input fields for the developer ID and password, a new registration button (icon), and a login button (icon). 【0044】 In S304, the developer terminal 100 accepts input operations for the developer ID and password input fields on the login screen. User input operations are performed using the operation unit 106. The developer ID is user identification information used to identify (specify) the developer user. In this embodiment, the developer ID (username) is assumed to be an email address. The password used as the PIN is assumed to be an arbitrary string of characters, but other PIN information such as biometric authentication information (fingerprint authentication is information used for facial authentication) or pattern authentication information (information of a trajectory pattern entered on the screen) may also be used. 【0045】 In S305, the developer terminal 100 determines whether an operation (e.g., a click) has been performed to instruct the new registration button on the login screen. Hereafter, operations that instruct a display item (a display object or item such as a button or icon) by clicking with the mouse included in the operation unit 106 or touching the touch panel will simply be referred to as "press". If the new registration button is pressed, proceed to S306; otherwise, proceed to S307. 【0046】 In S306, the developer terminal 100 performs the developer account registration process. Details of the developer account registration process will be described later using Figure 22(a). 【0047】 In S307, the developer terminal 100 determines whether the login button on the login screen has been pressed. If the login button has been pressed, the process proceeds to S308; otherwise, it returns to S304. 【0048】 In S308, the developer terminal 100 sends the information entered into the developer ID and password fields on the login screen (the entered developer ID and password) to the development environment 300 as login information. After transmission, the development environment 300 performs an authentication process, and the terminal waits for the result. 【0049】 In S309, the developer terminal 100 determines whether or not it has received information from the development environment 300 indicating a login error. If it has received information indicating a login error, it returns to S304 and accepts login information input again; otherwise, it proceeds to S310. 【0050】 In S310, the developer terminal 100 determines whether or not it has received the execution environment list from the development environment 300. The development environment 300 sends the execution environment list to the developer terminal 100 if login authentication is successful, so receiving the execution environment list means that login authentication was successful (login was successful). If the execution environment list has been received, proceed to S311; otherwise, return to S309. 【0051】 In S311, the developer terminal 100 records the execution environment list received in S310 into memory 102 as the development screen for the application after login, and displays the execution environment options on the display 105 based on the received execution environment list. The execution environment list shows the execution environments that the logged-in developer can access. Screens displayed on the developer terminal 100 from S311 onwards, which are different from the screen of the completed application, are collectively referred to as development screens. 【0052】 Figure 5(a) shows an example of the display of execution environment options in S311. In the example in Figure 5(a), two options are displayed as execution environments accessible to the logged-in developer: option 551, which corresponds to the multi-tenant execution environment 410, and option 552, which corresponds to the single-tenant execution environment. The developer user can select one of these options by clicking on it and confirm the selection by clicking the SAVE button 553. The option selected here is where the application updated in the following steps will be deployed during this login. Access to the execution environment is not performed at this point. The execution environment selected here can be changed through the operations described later. 【0053】 In S312, the developer terminal 100 determines whether an execution environment has been selected. If one of the execution environment options is pressed and the SAVE button 553 is pressed, the process proceeds to S313; otherwise, the process waits in S312 for the execution environment to be selected. 【0054】 In S313, the developer terminal 100 records information identifying the execution environment selected in S312 (such as the execution environment ID) in memory 102 as the "selected execution environment" and also sends it to the development environment 300. In response to receiving the information identifying the selected execution environment (selected environment), the development environment 300 sends information identifying all applications owned by the logged-in developer (applications that were previously created and recorded in storage 320) (such as the application ID and application name) as application information. 【0055】 In S314, the developer terminal 100 determines whether or not it has received application information from the development environment 300. If it has received application information, it proceeds to S315; otherwise, it waits in S314 for the application information to be received. 【0056】 In S315, the developer terminal 100 records the received application information in memory 102 and, based on the application information, displays a list of applications owned (under development) by the logged-in user (application list) on the display 105. 【0057】 In S316, the developer terminal 100 determines whether any application has been selected from the list of applications displayed in the app list. If any application has been selected, the process proceeds to S317; otherwise, it proceeds to S320. 【0058】 In S317, the developer terminal 100 records information identifying the selected application (such as the application ID and application name) in memory 102 as the "selected application" and sends it to the development environment 300. When the development environment 300 receives the information identifying the selected application, it retrieves the definition information (application definition) of the selected application from the area of ​​storage 320 belonging to the logged-in developer and sends it to the developer terminal 100. 【0059】 In S318, the developer terminal 100 determines whether or not it has received definition information (UI definition information) for the selected application from the development environment 300. If it has received the definition information for the selected application, it records the received definition information in memory 102 and proceeds to S319; otherwise, it waits in S318 for the definition information to be received. In this embodiment, this definition information is assumed to be a JSON file in which various definitions related to the application are described in JSON format. Subsequently, when displaying information about the selected application on the display 105, the display is based on the definition information recorded in memory 102. When an operation to update the selected application is performed (for example, changing the arrangement of UI components) in the UI editor process described later, the definition information in memory 102 is updated to define the updated content. Then, when a save command is given, the latest definition information recorded in memory 102 is sent to the development environment 300 and saved in the logged-in developer area of ​​storage 320. In this way, the frequency of communication with the development environment 300 is suppressed, and the response time is prevented from decreasing due to communication, enabling comfortable update work. 【0060】 In S319, the developer terminal 100 displays the UI editor screen on the display 105 and also displays information based on the received definition information. For example, it displays a canvas (UI screen editing area) with a shape that corresponds to whether the selected application is for desktop or not (i.e., a shape that corresponds to the type of device on which the application is used). For desktop applications, it displays a 16:9 rectangular canvas, and for mobile applications, it displays a vertically elongated canvas that mimics a smartphone. The submenu area (described later) displays a list of UI screens that the selected application has (belong to the selected application) (this process is strictly performed in S401 in Figure 4, described later). The canvas also displays components (UI parts placed on the UI screen) that are placed on the UI screen that is selected by default (the initial UI or the UI screen that was edited when it was last saved). Note that it is also possible not to select a UI screen to be edited by default and to not display anything on the canvas at this point. The login process ends in the S319 process and then proceeds to S401 in Figure 4. 【0061】 Meanwhile, in S320, the developer terminal 100 determines whether the icon (+ mark, not shown) for creating a new application displayed on the application list screen has been pressed and whether a new application has been instructed to be created. If it is determined that a new application has been instructed to be created, the process proceeds to S321; otherwise, it returns to S316. 【0062】 In S321, the developer terminal 100 displays a screen allowing the user to select whether the newly created application is for desktop (PC) or mobile, and accepts the user's selection. A desktop application is an application intended to be accessed and operated from an application user terminal 200, such as a desktop PC or notebook PC. A mobile application is an application intended to be accessed and operated from an application user terminal 201, such as a smartphone. 【0063】 In S322, the developer terminal 100 displays a screen to accept input of basic application information (at least the application name and application ID) for the application to be newly created, and accepts input operations to set the application information. Upon receiving the application information, it sends the information received in S321 (whether it is for desktop (PC) or mobile) and the application information received in S322 to the development environment 300. In this way, the definition information for the newly created application is created in the storage 320 of the development environment 300, and the information of whether it is for desktop (PC) or mobile, the application name, and the application ID are recorded. The definition information for previously created applications also has the information of whether it is for desktop (PC) or mobile, the application name, and the application ID recorded in this manner. 【0064】 In S323, the developer terminal 100 displays the UI editor screen as the editing screen for the newly created application. In this case, the canvas is displayed in a shape that corresponds to whether it is for desktop or mobile, as selected in S321. The canvas is also displayed as blank information with no components placed on it. The login process ends in S323, and then the process proceeds to S401 in Figure 4. 【0065】 Figure 3(b) shows the login process on the development environment 300 side, which works in conjunction with the login process on the developer terminal 100 side in Figure 3(a). The process in Figure 3(b) is realized when the processor 303 of the development environment 300 loads the program recorded in memory 304 into the work memory area of ​​the development environment 300 and executes it. Hereafter, processes that are simply described as being executed by the development environment 300 will be considered as being executed by the execution engine 302 of the development environment 300, or more specifically, by the processor 303. 【0066】 In S331, the development environment 300 determines whether or not it has received the login information sent from the developer terminal 100 in S308. If the login information is received, it proceeds to S332; otherwise, it waits for the login information to be received. 【0067】 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 the developer ID and password pair contained in the received login information matches the information contained in the developer information 301 (user information). If it matches, authentication is successful. 【0068】 In S333, the development environment 300 determines whether the login was successful (authentication was successful, authenticated, authentication OK) based on the authentication process in S332. If the login is OK, it proceeds to S335; otherwise, it proceeds to S334 and sends information indicating a login error to the developer terminal 100. 【0069】 In S335, the development environment 300 sends a list of execution environments for logged-in developers (logged-in developers), which is included in the developer information 301, to the developer terminal 100. As shown in Figure 14(a), the developer information 301 records the email address (username, developer ID) and password, as well as the accessible execution environment IDs for each developer. Each execution environment ID is an account ID in the cloud service (web service), and in this embodiment, it is a 12-digit ID. For developers 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 comma-separated execution environment IDs) for the logged-in developer is sent to the developer terminal 100. That is, in S335, by referring to the developer information 301, the execution environments that the logged-in developer can access are identified. In this way, the accessible execution environments for each developer (execution environments that each developer can use) are recorded in the developer information 301 recorded in the development environment 300. Furthermore, this log-in execution environment can only be obtained by developers who have been granted permission to log in. Additionally, only the execution environments accessible to the developer themselves can be obtained. This eliminates the need for developers to manage information for accessing their own accessible execution environments separately from the information for logging into development environment 300. It also deters other users from gaining unauthorized access to the execution environment. 【0070】 In S336, the development environment 300 determines whether it has received information identifying the selected execution environment (environment identification information) sent from the developer terminal 100 in S313. If it has received information identifying the selected execution environment, it proceeds to S337; otherwise, it waits for the information identifying the selected execution environment to be received. 【0071】 In S337, the development environment 300 records the selected execution environment in a configuration management file stored in the area for logged-in developers of storage 320, based on the information identifying the selected execution environment received in S336. 【0072】 In S338, the development environment 300 retrieves app information from the logged-in developer's area of ​​storage 320, showing all applications owned (created) by the logged-in developer, and sends it to the developer terminal 100. The app information sent here includes only the app definition information necessary to display the app list mentioned above in S315, and does not include detailed definition information about each app (such as component placement or information indicating actions described later). 【0073】 In S339, the development environment 300 determines whether it has received information about a new application (including whether it is for desktop (PC) or mobile, the application name, and the application ID) sent from the developer terminal 100 in S322. If it has received information about a new application, it proceeds to S340; otherwise, it proceeds to S341. 【0074】 In S340, the development environment 300 creates and records new application definition information in the area of ​​the storage 320 designated for the logged-in developer, based on the information about the new application received in S339. The definition information recorded here includes whether it is for desktop (PC) or mobile, the application name, and the application ID. In the development environment 300, to distinguish the application from other users' applications in the multi-tenant execution environment 410, the application ID is recorded with an 8-digit developer code uniquely corresponding to the developer ID of the developer who owns the application, prepended to the ID entered by the developer in S322. Then, the login process ends. Subsequently, when performing internal processing or displaying in a programming language on the action board, the application ID is used with the logged-in developer's developer code appended. When displaying the application ID in the UI editor, only the ID portion entered by the developer in S322 is displayed, excluding the developer code. 【0075】 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. 【0076】 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 is terminated. 【0077】 <UI Editor Processing> Using FIGS. 4 and 5(b), the UI editor processing will be described. The UI editor processing is a process of performing various definitions (definitions of UI components, action definitions) of the application to be constructed in response to operations from the developer (user) on the UI editor screen (application development screen). 【0078】 FIG. 5(b) shows an example display of the layout editing screen displayed in the UI editor processing 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). 【0079】 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. 【0080】 The Selected Execution Environment box 501 displays the Selected Execution Environment ID as information indicating the selected execution environment. By clicking the arrow icon on the far right of the Selected Execution Environment box 501, a list of execution environments accessible to the logged-in developer obtained from S310 is displayed as a pull-down menu, and the selected execution environment can be changed by selecting an arbitrary execution environment from the list. Even if the selected execution environment is changed, the selected application is not changed, and the contents displayed in the main menu area 510, submenu area 520, and canvas 530 remain unchanged. 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 any number of execution environments. 【0081】 The selected app box 502 displays the name of the selected app as information indicating the selected app. By clicking the arrow icon on the far right of the selected app box 502, a list of apps owned by the logged-in developer, obtained in S314, is displayed as a pull-down menu, and the selected app can be changed by selecting any app from the list. When the selected app is changed, the content to be displayed in the submenu area 520 and canvas 530 changes. 【0082】 The selected UI screen box 503 displays the name of the UI screen being edited on canvas 530, representing the UI screen currently being edited. By pressing the arrow icon in the selected UI screen box 504, a list of UI screens belonging to the selected app is displayed as a pull-down menu, based on the definition information of the selected app obtained in S318. By selecting any UI screen from the list, it is possible to change the UI screen to be edited and displayed on canvas 530. 【0083】 The main menu area 510 displays the following selection icons as menu items for the main menu: App List button 511, UI Screen button 512, Workflow button 513, Settings button 514, Environment List button 515, Database button 516, File Manager button 517, User Management button 518, and Snapshot button 519. The processing that occurs when these selections are pressed will be described later in the screen switching process shown in Figure 12. 【0084】 The submenu area 520 displays submenus corresponding to the item selected in the main menu. In the example in Figure 5(b), the UI component list (UI parts list) is displayed as a sub-hierarchical menu of the UI screen button 512. 【0085】 Canvas 530 is the layout editing area for the selected UI screen of the selected application (the UI screen whose name is displayed in the selected UI screen box 503). The canvas 530 in Figure 5(b) is an example of how the canvas of a desktop application is displayed, and is shown in a desktop format. Users can select any UI component from the list of UI components displayed in the submenu area 520 and place it in the canvas area 530 by dragging and dropping. UI components placed in the canvas area 530 can be selected to adjust their size and position. Furthermore, by selecting a UI component placed in the canvas area 530 and right-clicking, more detailed settings such as color scheme can be made by selecting a property from the right-click menu (context menu) that appears. In addition, by selecting an action from the same context menu, an action board is displayed, and the action to be executed when that UI component is manipulated can be set. By right-clicking with the cursor in a blank area of ​​canvas 530, the canvas context menu can be displayed, and by selecting an action from there, the action to be executed when the UI screen of that canvas is loaded in the constructed application (executed when that UI screen is displayed) can be set. 【0086】 Figure 5(b) shows an example of an application named "UI1" with a canvas 530 named "ui1" containing UI components: a pie chart 531, a button 532, text fields 533 and 534, an output field 535, and a tab component 536. The operation path 531a is a selection frame that indicates the selected UI component and is an operation path (operation handle) that accepts resizing instructions, indicating that the pie chart 531 is selected. 【0087】 Figure 4 shows a flowchart of the UI editor process. This process is executed by the developer terminal 100 and follows S319 or S323 in Figure 3. 【0088】 In S401, the developer terminal 100 displays a list of UI screens for the selected application as options in the submenu area 520, based on the definition information of the selected application. Each screen displayed in this UI screen list is designed to be displayed when the selected application is deployed to the execution environment, built, and accessed and executed from application user terminals 200 and 201. Operations to add new UI screens and delete UI screens are also possible in this UI screen list. 【0089】 In S402, the developer terminal 100 determines whether or not an operation was performed to select any of the UI screens from the list of UI screens displayed in S401. If any UI screen is selected, proceed to S404; otherwise, proceed to S403. 【0090】 In S403, it is determined whether an operation has been performed to select one 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 in 112. Otherwise, the process returns to S402. 【0091】 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 application stored in memory 102. If the UI screen already has UI components placed on it, the UI components that were previously placed according to the definition information are displayed on the canvas 530. In other words, if a UI screen has been partially created 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 as a blank canvas with no UI components placed on it. If the UI screen selected in S402 is a pre-prepared UI screen (template screen), even if the user has not previously placed UI components on that UI screen, a template component with predefined actions is displayed in a predetermined position on the canvas 530. 【0092】 In S405, the developer terminal 100 displays a list of UI components in the submenu area 520. That is, it switches from the UI screen list of the selected application to the display of the UI component list. UI components that can be placed on the canvas 530 include INPUT, Button, Display (information display component), Navigation, Layout, and Chart, with multiple UI components classified within each category. In the UI component list, first, a list of UI component types is displayed as shown in Figure 5(c), and when an operation is made to select one of the displayed types, the UI components classified under the selected type are expanded and displayed. Figure 5(b) above is an example where the option 522 corresponding to INPUT is selected, and a list of UI components classified under INPUT is displayed. UI components classified under INPUT include, for example, a text field 523 and a text area 524. The submenu area 520 is scrollable, and options that cannot be displayed (options for UI components of the expanded type or options of other types) can be displayed by scrolling. As shown in Figure 5(b), when the expanded type selection 522 is manipulated, the expanded list of UI components of that type is collapsed, and the list of UI component types is displayed. 【0093】 In S406, the developer terminal 100 determines whether a UI component displayed in the submenu area 520 has been selected. More specifically, it determines whether a drag operation has been performed on the UI component displayed in the submenu area 520. If a UI component displayed in the submenu area 520 has been selected, the process proceeds to S407; otherwise, it proceeds to S411. 【0094】 In S407, the developer terminal 100 determines whether or not an operation to specify a position on the canvas 530 has occurred. More specifically, it determines whether or not an operation to drop a dragged UI component onto the canvas 530 has occurred. If an operation to specify a position on the canvas 530 has occurred, the process proceeds to S408; otherwise, S407 waits for a position to be specified on the canvas 530. In this embodiment, a drag-and-drop example is described, but the operation method is not limited to this, as long as it is an operation to select a UI component from the submenu area 520 and place it at a specified position on the canvas 530. 【0095】 In S408, the developer terminal 100 determines whether the position on the canvas specified in S407 is included in the area of ​​an already placed tab component (a type of UI component). If it is not included in the tab component's area, the process proceeds to S409; if it is included in the tab component's area, the process proceeds to S410. The tab component is, for example, the tab component 536 shown in Figure 5(b). The tab component has multiple tabs (in the example in Figure 5(b), there are three tabs labeled ITEM1, ITEM2, and ITEM3), and depending on which tab is selected, the display content shown by the tab component is switched to the element screen corresponding to the selected tab. 【0096】 The tab component will be explained using Figures 6(a) and 6(b). Figure 6(a) is an example of how the tab component 601 is displayed on the display 105 when it is placed on a canvas 530 displaying a different UI screen than that shown in Figure 5(b). The area indicated by the operation bus 601a of the tab component 601 is the area occupied by the tab component 601. By operating the operation bus 601a, the overall display position and overall 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 displays a label as the tab name, which can be set by the developer in the tab component's property settings. In the example shown, they are displayed as Tab0, Tab1, and Tab2, respectively. The number and order of tabs can be changed from the tab component's property settings. Tab property settings are performed in S706 of the context menu processing described later in Figure 7, where there is an operation to open the tab's property box from the tab's context menu, and the settings are performed on the tab's property box (settings screen) that is displayed accordingly. The element screen area 602, indicated by a dashed line (illustrated for illustrative purposes only and not displayed), is an area whose displayed content changes depending on the selected tab. The displayed content corresponding to each tab shown in the element screen area 602 is called the element screen corresponding to each tab. Different UI components can be placed in each element screen corresponding to each tab. The example in Figure 6(a) shows an example where tab 610 is selected and the element screen corresponding to tab 610 is displayed. In the illustrated example, UI components 611 and 612 are placed in the element screen corresponding to tab 610. The example in Figure 6(b) shows an example of the display when tab 620 is clicked from the state in Figure 6(a), and the selected tab changes from tab 610 to tab 620. In Figure 6(b), the element screen area 602 displays the element screen corresponding to the selected tab 620. In the illustrated example, UI component 621 is placed in the element screen corresponding to tab 620. In the examples shown in Figures 6(a) and 6(b), the definition information records at least the UI component ID (UI component identification information) of the tab component 601 and the position of the tab component 601 within the UI screen, associated with the ID (UI screen identification information) of the UI screen being edited on the canvas 530.Furthermore, the IDs of UI components 611 and 612, and their respective positions within the element screen of tab 610 are recorded, associated with the ID (element screen identification information) of tab 610 of tab component 601. Also, the ID of UI component 621 and its position within the element screen of tab 620 are recorded, associated with the ID of tab 620 of tab component 601. Return to the explanation of Figure 4. 【0097】 In S409, the developer terminal 100 places the UI component selected in S406 from the submenu area 520 at the specified location on the canvas 530 with the default size, and records the information defining this in the definition information stored in memory 102. Specifically, in the definition information, the type of UI component placed in S410, the UI component ID, placement coordinates, placement size, etc. are associated with the ID of the UI screen to which the component is placed (the UI screen being edited) and recorded. 【0098】 In S410, the developer terminal 100 places the UI component selected in S406 from the submenu area 520 onto the element screen (currently displayed element screen) corresponding to the selected tab among the tab components at a specified position on the canvas 530, using the default size, and records the information defining this in the definition information stored in memory 102. Specifically, the definition information records the ID of the destination UI screen (the UI screen being edited), the type of UI component placed in S410, the ID of the tab component as the UI component ID, the ID of the tab that was selected in that tab component, the placement coordinates in the element screen corresponding to the selected tab, and the placement size, associating them with the ID of the destination UI screen (the UI screen being edited). In this way, in this embodiment, it is possible to place and lay out different UI components on each element screen corresponding to each tab of the tab component. Furthermore, at this time, it is not necessary to perform complex operations to define the tab of the element screen to which the UI component is placed; it is simply necessary to select and display the destination element screen when placing the UI component by dragging and dropping. 【0099】 In S411, the developer terminal 100 determines whether a UI component placed on the canvas 530 has been selected by clicking or other means. If the placed UI component has been clicked (selected), the process proceeds to S412; otherwise, it proceeds to S415. 【0100】 In S412, the developer terminal 100 displays the operation path for the UI component clicked in S411. Examples of operation path displays are the aforementioned operation path 531a and operation path 601a. 【0101】 In S413, the developer terminal 100 determines whether the location specified by the click in S411 is within the area of ​​the tab portion of the tab component. If it is not within the tab portion, the process proceeds to S431; if it is within the tab portion, the process proceeds to S414. The tab portion is an instruction area that instructs switching to the corresponding element screen. 【0102】 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, if one of the three tabs displayed as ITEM1, ITEM2, or ITEM3 of the tab component 536 is clicked in S411, S412 displays an operation path for the tab component 536 and switches the display content of the element screen area 436a to that of the element screen corresponding to the clicked tab. Also, for example, if the display was as shown in Figure 6(a), the display switches to Figure 6(b) when tab 620 is specified. That is, UI components 611 and 612 that were placed on the element screen displayed before the click are hidden, and instead, UI component 621, which is placed on the element screen corresponding to the clicked tab 620, is displayed. This control is implemented to simplify the operation of defining the desired tab element screen when a developer wants to place other UI components on the element screen of a desired tab of the tab component. If a developer wants to place other UI components on the element screen of a desired tab of a tab component, they can simply click on the desired tab to display the desired element screen before dragging and dropping the UI components to be placed. 【0103】 In this embodiment, for the sake of simplicity, the processes in S409, S410, S413, and S414 were explained using a tab component as an example, but this is not the only example. Even for UI components other than tab components, if a certain type of UI component has its display content switched in response to an operation on that UI component after the application has been built, the processes in S409, S410, S413, and S414 can be applied in the same way as for tab components. 【0104】 On the other hand, in the case of UI components other than those of a predetermined type, such as tab components, the display content within the UI component is not switched in response to the selection of the UI component on the canvas 530. The only action performed in response to the selection of a UI component is the display of the operation path; no other actions are performed. For example, if button 532 is selected on canvas 530 in Figure 5(b), only the operation path is displayed, and the action of button 532 (the process executed when button 532 is pressed in the constructed application) is not performed. Similarly, if text field 533 is selected on canvas 530, only the operation path is displayed, and no processing such as displaying a text input cursor within text field 533 is performed. 【0105】 Using Figures 6(c), 6(d), and 6(e), we will explain the AppBar as an example of a type of UI component to which the processing of S409, S410, S413, and S414 can be applied, similar to the tab component. Figure 6(c) shows an example where the UI components AppBar650, TextField661, and Button662 are placed on canvas 530. AppBar650 is a single UI component and contains element icons 651 and 652. Element icon 651 is a display item that accepts instructions to display a drawer menu in the constructed application. Element icon 652 is a display item that accepts instructions to display a popup menu in the constructed application. When the positions of element icons 651 and 652 of the placed AppBar650 on canvas 530 are clicked, the same control is applied as to the tab portion of the tab component. More details are provided below. 【0106】 If the position of element icon 651 in the already placed AppBar 650 is clicked (Yes in S411), the operation path for AppBar 650 is displayed (S412), and if it is determined to be Yes in S413, the drawer menu as an element screen is displayed (S414). This transitions from the display state in Figure 6(c) to the display state in Figure 6(d). In Figure 6(d), the operation path 650a for AppBar 650 is displayed, and the drawer menu 651a, which is the element screen corresponding to element icon 651, is displayed. The drawer menu 651a is an area that is displayed by pulling it out from the left edge of the screen to the right, and displays one or more menu items. With the drawer menu 651a displayed, other UI components can be placed on the drawer menu 651a by dragging other UI components from the submenu area 520 and dropping them onto the drawer menu 651a, similar to the process described in S408 and S410 using a tab component as an example. 【0107】 If the position of element icon 652 on the already placed AppBar 650 is clicked (Yes in S411), the operation path for AppBar 650 is displayed (S412), and if it is determined to be Yes in S413, a popup menu as an element screen is displayed (S414). This transitions from the display state in Figure 6(c) to the display state in Figure 6(e). In Figure 6(e), the operation path 650a for AppBar 650 is displayed, and the popup menu 652a, which is an element screen corresponding to element icon 652, is displayed. The popup menu 652a is an area displayed near element icon 652, and displays one or more menu items (options). With the popup menu 652a displayed, other UI components can be placed on the popup menu 652a by dragging other UI components from the submenu area 520 and dropping them onto the popup menu 652a, similar to the process described in S408 and S410 using a tab component as an example. Return to the explanation of Figure 4. 【0108】 In S415, the developer terminal 100 determines whether or not an operation has occurred to drag a UI component already placed on the canvas 530. If an operation has occurred to drag a placed UI component, the process proceeds to S416; otherwise, it proceeds to S417. In S416, the developer terminal 100 changes the position where the dragged UI component (selected component) is placed in response to the drag operation. Specifically, it places it at the drop location. When the placement is changed, the definition information stored in memory 102 is also updated to reflect the changed position. 【0109】 In S417, the developer terminal 100 determines whether or not an operation has been performed on the operation path of a UI component already placed on the canvas 530. If an operation has been performed 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) to which the operation path was attached, according to the operation on the operation path. When the size is changed, the definition information stored in memory 102 is also updated to reflect the changed size. 【0110】 In S419, the developer terminal 100 determines whether an instruction operation (a right-click of the mouse in this embodiment) has been performed to display a context menu in any area of ​​the canvas 530. If a right-click has been performed, the process 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 a right-click occurred, and context menu processing is performed to perform processing according to the operation on the context menu. For example, if a right-click is performed while the mouse cursor is over button 532 in Figure 5(b), a context menu 540 related to button 532 (specified UI component) as shown in Figure 5(d) is displayed. The context menu 540 displays property 541, action 542, and erase 543 as selectable menu items. If property 541 is selected, a property box (detailed settings dialog) related to button 532 is displayed, allowing detailed settings such as the button name (label) to be displayed on button 532, the color of button 532, and the size specified by a numerical value. If action 542 is selected, an action board related to button 532 is displayed, and actions in the programming language JavaScript can be entered on the action board. The action entered here is the process that should be executed when button 532 (specified UI component) is pressed in the constructed application. If erase 543 is selected, button 532 will be erased (deleted) from canvas 530. Details of the context menu process will be described later using Figure 7. 【0111】 In S421, the developer terminal 100 determines whether the save button 504 has been pressed. If the save button 504 has been pressed, the process proceeds to S422; otherwise, it proceeds to S423. In S422, the developer terminal 100 sends the definition information of the application being edited, which is stored in memory 102, to the development environment 300. Upon receiving the definition information, the development environment 300 performs the save process described later in Figure 33(a) or Figure 35(a). 【0112】 In S423, the developer terminal 100 determines whether the preview button 505 has been pressed. If it determines that the preview button 505 has been pressed, it proceeds to S424; otherwise, it proceeds to S425. In S424, the developer terminal 100 performs a preview. In the preview process, the canvas 503 is hidden, and based on the definition information stored in memory 102 or the development environment 300, a preview is displayed of the UI screen being edited on canvas 503 that looks the same as when the UI screen is viewed in the constructed application. In the preview, the operation paths for manipulating UI components are not displayed. In addition, some operations that are not performed on the UI editor screen (not performed when operating on canvas 530) are performed in the preview. For example, when UI components for screen transitions or links are manipulated, screen transitions or transitions to the link destination are performed. Operations such as moving the selection frame for an item using the keyboard's tab key are also performed. However, actions entered by the developer in the action board or database references are not performed. Consequently, the preview process can display the results faster than actually deploying and checking the application. 【0113】 In S425, the developer terminal 100 determines whether the deploy button 506 has been pressed. If the deploy button 506 has been pressed, the process proceeds to S426; otherwise, it proceeds to S427. In S426, the developer terminal 100 executes the deployment process. The deployment process will be described later using Figure 24(a). When the deploy button 506 is pressed and the deployment process is performed, the developer does not need to select the execution environment to which the application will be deployed. The deployment is performed to the pre-selected execution environment displayed in the selected execution environment box 501. Developers often work by updating content to be deployed to a specific execution environment all at once. Therefore, in this system, the user is prompted to select the execution environment to which the application will be deployed before selecting the application to be updated (S311 in Figure 3), and the user is not prompted to select the execution environment each time an application is deployed. Thus, operational errors such as accidentally deploying to an unintended execution environment are suppressed, and the work can be made more efficient. Furthermore, although authentication is performed when logging into the development environment 300, there is no need to perform a separate account authentication operation for the execution environment to be deployed. Therefore, it is possible to prevent an increase in workload and work efficiently. In other words, the developer terminal 100 does not obtain authentication information regarding the target execution environment from the developer user. 【0114】 In S427, the developer terminal 100 determines whether or not an operation to change the selected execution environment has occurred. Specifically, it determines whether or not an operation to change the selected execution environment has occurred in the selected execution environment box 501. If an operation to change the selected execution environment has occurred, the process proceeds to S428; otherwise, it proceeds to S429. In S428, the developer terminal 100 records information identifying the selected execution environment (such as the execution environment ID) as "Selected Execution Environment" in memory 102 and sends it to the development environment 300. It also updates the display content of the selected execution environment box 501 to reflect the changed selected execution environment. When the development environment 300 receives the information identifying the selected execution environment, it records the selected execution environment in a settings management file stored in the login developer area of ​​storage 320 based on that information. 【0115】 In S429, the developer terminal 100 determines whether or not an operation has been performed to change the application being edited. Specifically, it determines whether or not an operation has been performed to change the selected application in the selected application box 502. If an operation has been performed to change the selected application, the process proceeds to S317 in Figure 3, and the processing from S317 onward is executed based on the changed selected application. That is, the display contents of the submenu area 520 and canvas 530 are updated. If there is no operation to change the selected application, the process proceeds to S430. 【0116】 In S430, the developer terminal 100 determines whether or not an operation has been performed to change the UI screen being edited. Specifically, it determines whether or not an operation has been performed to change the selected UI screen in the selected UI screen box 503. If an operation has been performed to change the selected UI screen, the process proceeds to S404, where processing is carried out based on the changed selected UI screen. That is, the display content of the canvas 530 is updated (switched) to the content of the changed selected UI screen. If there was no operation to change the selected UI screen, the process proceeds to S431. 【0117】 In S431, the developer terminal 100 determines whether or not an operation to select one of the options displayed in the main menu area 510 has occurred. If an option displayed in the main menu area 510 has been selected, the UI editor process ends and the process proceeds to the screen switching process described later in Figure 12. Otherwise, the process returns to S406. 【0118】 <Context menu processing> Figure 7 shows a flowchart of the context menu processing. This process is an example of a detailed flowchart of S420 in Figure 5. 【0119】 In S701, the developer terminal 100 determines whether the context menu to be displayed relates to a UI component of the Button type. More specifically, in S419, it determines whether the UI component specified by the mouse (specified UI component) when a right-click is received is a button. If it is a button, proceed to S710; otherwise, proceed to S702. 【0120】 In S702, the developer terminal 100 determines whether the context menu to be displayed relates to the canvas. More specifically, in S419, it determines whether the position specified by the mouse when the right-click was received was an empty area of ​​the canvas 530 where no UI components were placed. If it was an empty area (i.e., the context menu to be displayed relates to the canvas), the terminal proceeds to S703; otherwise, it proceeds to S704. 【0121】 In S703, the developer terminal 100 handles the context menu processing for the canvas. The canvas context menu processing will be described later using Figure 19. 【0122】 In S704, the developer terminal 100 determines whether the context menu to be displayed relates to a UI component of the data grid (table) type. More specifically, in S419, it determines whether the type of UI component (specified UI component) that was selected with the mouse when a right-click was received is a data grid. If it is a data grid, proceed to S705; otherwise, proceed to S706. 【0123】 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 using Figure 30. 【0124】 In S706, the developer terminal 100, as part of its other processing, displays a context menu related to the specified target corresponding to the specified location and performs processing according to the operation. Details are omitted. 【0125】 In S710, the developer terminal 100 determines whether the UI screen to be edited (the selected UI screen) is a template screen. If it is a template screen, it proceeds to S721; otherwise, it proceeds to S711. 【0126】 In S711, the developer terminal 100 overlays the context menu for the button shown in Figure 5(d) near the specified position (mouse cursor position) as a context menu for the specified UI component. 【0127】 In S712, the developer terminal 100 determines whether a property (property 541 in Figure 5(d)) has been selected from the options included in the context menu. If a property is selected, the process proceeds to S713; otherwise, it proceeds to S714. 【0128】 In S713, the developer terminal 100 displays a property box for a button, superimposed on the canvas 530, as a property box (detailed settings dialog) for the specified UI component. It then accepts various setting operations for the property box. Here, for example, detailed settings such as the button name (label) to be displayed on the specified UI component, the button color, and the size specified by a numerical value can be made. After making the settings and performing the apply operation, the specified UI component is displayed on the canvas 530 in a display format that reflects the settings. 【0129】 In S714, the developer terminal 100 determines whether an action (property 542 in Figure 5(d)) has been selected from the options included in the context menu. If an action is selected, the process proceeds to S715; otherwise, it proceeds to S716. 【0130】 In S715, the developer terminal 100 performs action board processing related to the designated UI component, which is a button. Action board processing will be described later using Figure 8. 【0131】 In S716, the developer terminal 100 determines whether "erase" (erasure 543 in Figure 5(d)) has been selected from the options included in the context menu. If "erase" is selected, the process proceeds to S717; otherwise, it proceeds to S718. 【0132】 In S717, the developer terminal 100 erases the specified UI component and deletes the definition information related to the specified UI component (such as definitions of position and size, properties and actions) from the definition information recorded in memory 102. As a result, the specified UI component is erased (deleted) and hidden on canvas 530. 【0133】 In S718, the developer terminal 100 determines whether another option has been selected from the options included in the context menu. If another option is selected, the process proceeds to S719, where it performs the processing corresponding to the selected option. Otherwise, the process proceeds to S720. 【0134】 In S720, the developer terminal 100 determines whether an operation to close the context menu has occurred (for example, clicking outside the area where the context menu is displayed). If an operation to close the context menu has occurred, the context menu is hidden and the process shown in Figure 7 is terminated. If no closing operation has occurred, the process returns to S712. 【0135】 On the other hand, in S721, the developer terminal 100 overlays a context menu for the specified UI component, as shown in Figure 26(d), which is for the template screen and includes buttons, near the specified position (mouse cursor position). Unlike the context menu for a normal UI screen (the context menu 540 shown in Figure 5(d)), the context menu for the template screen (template component 2634 in Figure 26(d)) does not display actions or delete options; only properties are displayed. In other words, for UI components placed on the template screen, the developer is prevented from setting the actions that occur when the UI component is manipulated. The reason for this will be explained later. 【0136】 In S722, the developer terminal 100 determines whether a property has been selected from the options included in the context menu. If a property is selected, the process proceeds to S723; otherwise, it proceeds to S724. The processing in S723 is the same as in S713. 【0137】 In S724, the developer terminal 100 determines whether an operation to close the context menu has occurred (for example, clicking outside the area where the context menu is displayed). If an operation to close the context menu has occurred, the context menu is hidden and the process shown in Figure 7 is terminated. If no closing operation has occurred, the process returns to S722. 【0138】 <Action Board Processing> This section explains the processing related to the action board. When you select an action from the context menu after specifying a UI component placed on the canvas, an action board is displayed for setting the action for the specified UI component. For example, consider the case where you are editing a UI screen as shown in Figure 9(a). Figure 9(a) is a diagram showing a part of the UI editor screen on display 105. In Figure 9(a), a list of UI components is displayed in the submenu area 520, and the UI screen to be edited is displayed on the canvas 900. The canvas 900 contains a UI component 901 which is a button, and other UI components. When UI component 901 is specified and an action option is selected from the context menu, an action board as shown in Figure 9(b) is displayed. 【0139】 Figure 9(b) shows an example of the display of the action board for UI component 901. The action board 910 is displayed in the area where the canvas 900 was previously displayed, replacing the canvas. Unless it is a template component pre-placed on the template screen, and unless the developer has previously set an action for the specified UI component, the action board 910 will be displayed blank as shown in Figure 9(b). Note that the "1" displayed on the action board 910 is a guide indicating the row number and does not represent the content of the action. Developers can set any action on this action board 910 by operating the keyboard included in the operation unit 106 and entering any string in the programming language JavaScript. The trigger for executing the content set on the action board is predetermined: the specified UI component is operated. Therefore, developers do not need to set what the trigger for executing the action is (they do not need to write it in JavaScript). For example, if the specified UI component is a button, the trigger is when that button is pressed in the built application, and the action set on the button's action board is executed in response to the trigger. 【0140】 In addition, along with the action board 910, the submenu area displays a list of functions 920 instead of the UI component list or UI screen list shown in Figure 9(a) that was displayed on the UI editor screen. The function list 920 displays an option 922 that instructs the display of the action board 910, and function options that instruct the display of each function. Functions created (added) by the developer (user) by pressing the function add button 921, described later, rather than pre-prepared functions, are referred to as custom functions (created functions, added functions, user-created functions). If there are no automatically created functions or pre-prepared functions, and the developer has not previously created a custom function for a specified UI component, the function list 920 will not display function options, as shown in Figure 9(b), and will only display the option 922 and the function add button 921. 【0141】 When the Add Function button 921 is pressed, a dialog box for adding a custom function (referred to as the Add dialog 930) is displayed. Figure 9(c) shows an example of the Add dialog 930. The Add dialog 930 displays a Function Type selection field 931 for selecting the Function Type, a Function Name input field 932 for entering the Function Name, and a SAVE button 933. After input is made in the Add dialog and the SAVE button 933 is pressed, the function settings screen corresponding to the function type selected in the Function Type selection field 931 is displayed, and the function name entered in the Function Name input field 932 is added to the Function List 920. 【0142】 Figure 9(d) shows an example of the REST function settings screen displayed when REST is selected in the type selection field 931. Instead of the action board 910, the REST function settings screen 940 is displayed to accept various settings necessary to create a function using REST (REpresentational State Transfer) (REST function). In addition, the function list 920 displays function 923 with the function name "rest01" entered in the function name input field 932 as a function option. The icon displayed before "rest01" indicates that the type of function 923 is a REST function. If all required settings are not set on the function settings screen (if there is insufficient information to set), an incomplete mark 929 is displayed to indicate that the function is incomplete, and the corresponding function 923 is displayed in an incomplete state. 【0143】 The REST function settings screen 940 in Figure 9(d) displays setting fields 941 to 944. Setting field 941 is the function name setting screen. Initially, the function name entered in the function name input field 932 is displayed, but it can be changed according to the developer's input. Setting field 942 is the setting field for setting the variable name for arguments. In this embodiment, "param" is set by default and cannot be changed. It is displayed in gray to indicate that it cannot be changed. Setting field 943 is the setting field for setting the type of REST function. By operating the triangular icon on the far right of this area, GET, POST, PUT, and DELETE will be displayed as options in the pull-down menu, and you can select one of these options to set it. The type set here is the type of request that this function makes. Setting field 944 is the setting field for the URL to which the request made by this function will be sent. Thus, when creating a REST function on the REST function settings screen 940, the developer does not need to write source code strings in a programming language. 【0144】 Figures 10(a) to (d) further show examples of the settings screen for the creation function and the display of the action board. In Figure 10, the same reference numerals as in Figure 9 are used, and their explanations are omitted. 【0145】 Figure 10(a) shows an example of the SQL function settings screen displayed when SQL is selected in the type selection field 931. Instead of the action board 910, the SQL function settings screen 950 is displayed to accept various settings necessary to create a function using SQL (Structured Query Language) (SQL function). In addition, the function list 920 displays function 924 with the function name "sql01" entered in the function name input field 932, along with an incomplete mark 929, as a function option. The icon displayed before "sql01" indicates that the type of function 924 is an SQL function. The settings field 951 is the function name setting screen, 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 the developer's input. The settings field 952 is a setting field for setting the variable name for setting arguments. In this embodiment, "param" is set by default and cannot be changed. It is displayed grayed out to indicate that it cannot be changed. The setting field 953 is an input field for entering a string of characters (SQL statement) that instructs the database using SQL, a type of computer language (a database language, not a programming language). Developers can enter any SQL statement into the setting field 953 using the keyboard included in the operation unit 106. In this way, when creating an SQL function on the SQL function setting screen 950, developers do not need to write source code strings in a programming language. 【0146】 Figure 10(b) shows an example of the display after the developer has created custom functions 923-925, and has entered some JavaScript code (strings) into the action board 910, and then entered "sq". In this embodiment, when a developer user enters a string, if the entered string has a prefix match with the function name (identification information) of a previously created custom function, the function name that has a prefix match is displayed as an option in the code assist field 911. In the example shown, the entered "sq" has a prefix match with the function name "sql01" of the previously created custom function 924, so "sql01" is displayed as an option. When the user selects "sql01" displayed in the code assist field 911, "sql01" is entered into the action board 910 as shown in Figure 10(c), without the user having to enter "l01". This code assist function allows developers (users) to input the function name (identification information) of a custom function without having to type the entire name on the keyboard, thus reducing the number of steps required. Furthermore, if the entered function name matches a function name of an existing custom function, the full name will be displayed in the code assist field 911. If there is no match (i.e., if no function starts with that string), the code assist field 911 will not be displayed. Therefore, developers can confirm that they are entering the correct function name of an existing custom function, preventing input errors. If there are multiple custom functions that match the entered name, multiple options will be displayed in the code assist field 911. In addition, the function names of custom functions displayed in the code assist field 911 are those created for the specified UI component targeted by the action board 910 (UI component 901 in the illustrated example), and custom functions created for other UI components are not displayed. Therefore, it is possible to prevent the mistake of writing the function name of a custom function created for another UI component that does not exist as a custom function for the specified UI component on the action board 910. 【0147】 Furthermore, as shown in Figure 10(c), along with the action board 910, the function list 920 displays the function type (icon before the string) and the function name for each of the custom functions 923 to 925 created by the developer. Therefore, the developer user can check what types and names of custom functions have been created while entering (writing) the action code (a string in JavaScript) into the action board 910. This reduces the effort required to check and manage valid custom functions that can be written on the action board 910 (for example, the effort of making a note of it or opening another screen to check). It also helps prevent input errors in function names. The functions displayed in the function list 920 are those created for the specified UI component targeted by the action board 910 (UI component 901 in the example shown), and custom functions created for other UI components are not displayed. Therefore, it is possible to prevent the mistake of writing the function name of a custom function created for another UI component that does not exist as a custom function for the specified UI component into the action board 910. Furthermore, custom functions are only effective when defining actions for a specified UI component and do not affect the definition of actions for other UI components. Therefore, if the function name of a custom function created for a specified UI component is the same as the function name of a custom function created for another UI component, even if that function name is written in the action board 910, only the function settings set for the specified UI component will be reflected, and the function settings set for the other UI component will not be reflected. Therefore, even if the same function name as a custom function already created for another UI component is used, no error will occur. Thus, users can decide on a function name for a custom function and enter it in the action board 910 without worrying about duplication with custom functions already created for other UI components. In other words, although many custom functions will be created throughout the development of the application, they are automatically managed and organized in association with the specified UI component and displayed in the code assist field 911 and the function list 920, making it very easy for developers to manage many custom functions. Therefore, the effort and time required to check function names can be reduced.Furthermore, it helps to reduce input errors in function names. As a result, debugging work (debugging) required when input errors in function names are made can also be reduced. This reduces the workload and man-hours required for software development (application development), enabling more efficient software development (application development). 【0148】 Figure 10(d) shows an example of how the action code will appear on the action board 910 after it has been entered in a programming language. In the example shown, the custom function "rest01" (function 923 in the function list 920) is used in the section indicated by the dotted line 960 on the third line. In the code string shown on the action board 910 in Figure 10(d), the details of the custom function rest01 are not defined. Also, when the developer sets up rest01 on the REST function setting screen 940, the details of rest01 are not defined in the programming language. When definition information including the definition of an action in this state is uploaded and saved to the development environment 300, the development environment 300, in the save process shown in Figure 33(a) or Figure 35(a) described later, creates source code in a programming language, including the definition of the function in a programming language, from the uploaded definition information, based on the function settings and the string written on the action board 910, as a program for the execution environment. Thus, when the development environment 300 obtains a string containing the identification information (function name) of a custom function written in a programming language, it controls the system to enable the execution of the function (action) indicated by the string containing the function of the custom function (the action listed on the action board), based on the information set on the function settings screen. 【0149】 Figure 11 shows an example of source code in a programming language generated by the development environment 300 based on the string written on the action board 910 in Figure 10(d) and the settings for rest01 configured on the REST function settings screen 940. Note that the numbers 1-75 on the left edge of the example are for line numbering purposes only and are not part of the source code. The example in Figure 11 is 75 lines of source code, including a detailed definition of rest01 in a programming language. However, the developer does not need to input 75 lines. By configuring the settings on the REST function settings screen 940 and writing the string of the amount shown (7 lines) on the action board 910 in Figure 10(d), the content of the source code shown in Figure 11 can be defined. In other words, efficient development can be performed using low-code. 【0150】 Figure 8 shows the flowchart of the action board processing. This process is a detailed flowchart of the action board processing described in S715 of Figure 7, and is a process that controls the operation to be as described using the display examples in Figures 9(b) to (d) and Figures 10(a) to (d). 【0151】 In S801, the developer terminal 100 displays an action board on the display 105. If no action is defined for the specified UI component, it displays a screen containing a blank action board 910 as described in Figure 9(b). If an action is already defined for the specified UI component, it displays a screen containing an action board 910 with the action string entered, as described in Figure 10(d). 【0152】 In S802, the developer terminal 100 determines whether or not an operation to describe an action (description operation) has been performed on the action board 910. An operation to describe an action is, for example, a text input operation performed by operating on the keyboard included in the operation unit 106 while the action board 910 is selected, or by touching the soft keyboard displayed on the touch panel. If an operation to describe an action has been performed, the process proceeds to S803; otherwise, it proceeds to S810. 【0153】 In the S803, the developer terminal 100 accepts action input operations through actions that describe actions, and displays the entered characters on the action board 910. 【0154】 In S804, the developer terminal 100 determines whether the string formed by the characters entered in S803 and the characters entered before it matches the function name of the created function (i.e., partially matches). If there is a match, proceed to S805; otherwise, proceed to S808. 【0155】 In S805, the developer terminal 100 displays the function name of the custom function determined to match in S804 as an option in the code assist field. This displays the code assist field 911 as explained in Figure 10(b). Note that the code assist field 911 may also display function names that are commonly used in programming languages, in addition to custom functions, if they match the input string. 【0156】 In S806, the developer terminal 100 determines whether one of the options displayed in the code assist field has been selected. If one of the options is selected, the process proceeds to S807, where the function name of the selected option is displayed in the code assist field 911. For example, if an option is selected in the code assist field 911 from the state shown in Figure 10(b), "sql01" is entered and displayed as shown on the 5th line of the action board 910. If none of the options are selected, the process proceeds to S808. 【0157】 In S808, the developer terminal 100 determines whether the operation to describe the action has been performed again. If the operation to describe the action has been performed again, the process proceeds to S803; otherwise, it proceeds to S802. 【0158】 In S810, the developer terminal 100 determines whether an operation to instruct the addition of 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, the process proceeds to S811; otherwise, it proceeds to S820. 【0159】 In S811, the developer terminal 100 displays an add dialog 930 for adding a custom function and accepts input for the add dialog 930. The content of the input accepted in the add dialog is as described above using Figure 9(c). Once input is made into the add dialog and the SAVE button 933 is pressed, the process proceeds to S812. 【0160】 In S812, the developer terminal 100 adds the function name entered in the function name input field 932 of the add dialog to the function list 920 in the submenu area, and displays it with an incomplete mark 929. 【0161】 In S813, the developer terminal 100 determines whether the type selected in the type selection field 931 of the add 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 the script function settings screen (not shown) and accepts setting operations from the developer user. 【0162】 In S815, the developer terminal 100 determines whether the type selected in the type selection field 931 of the add dialog is SQL. If it is SQL, it proceeds to S816; otherwise (i.e., if the type selected in the type selection field 931 of the add dialog is REST), it proceeds to S817. In S816, the developer terminal 100 displays the SQL function settings screen and accepts setting operations from the developer user. The settings accepted on the SQL function settings screen are as described above using Figure 10(a). 【0163】 In S817, the developer terminal 100 displays the REST function settings screen and accepts setting operations from the developer user. The settings accepted on the REST function settings screen are as described above using Figure 9(d). 【0164】 In S818, the developer terminal 100 determines whether the input of the predetermined required setting items has been completed (whether the settings have been completed) on the function setting screen for each type. If the input of the required items has been completed, it proceeds to S819; otherwise, it proceeds to S802. 【0165】 In S819, the developer terminal 100 hides the incomplete mark that was displayed in the function list 920 for the custom function being configured, as it corresponds to the function name. This allows the user (developer) to recognize that the custom function being configured is in a valid configuration state and can be used on the action board 910. 【0166】 In S820, the developer terminal 100 determines whether any of the custom functions displayed in the function list 920 have been selected (pressed). If a custom function is selected in the function list 920, the process proceeds to S813, and in either S814, S816, or S817, a settings screen corresponding to the type of custom function selected is displayed, reflecting the previously configured settings. The user (developer) can change or add settings to the settings screen (i.e., edit the custom function). 【0167】 In S821, the developer terminal 100 determines whether or not a save command operation (for example, pressing the save button 915) has been performed. If a save command operation has been performed, the process proceeds to S822; otherwise, it proceeds to S823. 【0168】 In S822, the developer terminal 100 records the contents of the action board processing performed so far in the definition information stored in memory 102, and also sends it to the development environment 300. 【0169】 In S823, the developer terminal 100 determines whether option 922, which instructs the display of the action board 910 displayed in the function list 920, has been pressed. If option 922 is pressed, the process proceeds to S801, and the action board of the specified UI component is displayed. As a result, if the function settings screen was displayed, the display switches to the action board. If option 922 is not pressed, the process proceeds to S824. 【0170】 In S824, the developer terminal 100 determines whether or not an action board closing operation (an operation to terminate the action board processing) has occurred. If there is no action board closing operation, the process proceeds to S802 and is repeated. If an action board closing operation has occurred, the action board is hidden, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor. 【0171】 <Screen switching process> Figure 12 shows a flowchart of the screen switching process. This process corresponds to the selection of an option displayed in the main menu area 510 as described in the display example in Figure 5(b). 【0172】 In S1201, the developer terminal 100 determines whether the app list button 511 has been pressed. If the app list button 511 has been pressed, the process proceeds to S315 in Figure 3; otherwise, it proceeds to S1202. 【0173】 In S1202, the developer terminal 100 determines whether the UI screen button 512 has been pressed. If the UI screen button 512 has been pressed, the process proceeds to S1203; otherwise, it proceeds to S1204. In S1203, the UI editor processing shown in Figure 4 is performed. 【0174】 In S1204, the developer terminal 100 determines whether the workflow button 513 has been pressed. If it determines that the workflow button 513 has been pressed, the process proceeds to S1205; otherwise, it proceeds to S1206. 【0175】 In S1205, the developer terminal 100 performs the workflow creation process. The workflow creation process will be described later using Figure 16. 【0176】 In S1206, the developer terminal 100 determines whether the settings button 514 has been pressed. If the settings button 514 has been pressed, the process proceeds to S1207; otherwise, it proceeds to S1209. 【0177】 In S1207, the developer terminal 100 displays the app settings screen. The app settings screen accepts setting operations related to the selected app. In S1208, the developer terminal 100 accepts setting operations on the app settings screen and updates the definition information stored in memory 102 based on the settings. Settings that can be accepted in S1208 include, for example, the display language setting and the setting of whether or not to build an app that can be used as a PWA (Progressive Web App). There is also a setting to determine which of the multiple UI screens belonging to the app will be the initial UI. The initial UI is the screen that is first displayed when accessing a built app deployed to the execution environment, or the screen that is first displayed after authentication is successful on the app's authentication screen after accessing a built app. 【0178】 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 Figure 3; otherwise, it proceeds to S1210. 【0179】 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. 【0180】 In S1211, the developer terminal 100 determines whether the selected execution environment is a multi-tenant execution environment 410. If it is a multi-tenant execution environment 410, it proceeds to S1213; otherwise (if it is a single-tenant execution environment), it proceeds to S1212. 【0181】 In S1212, the developer terminal 100 retrieves database information obtained from the selected execution environment by the development environment 300. More specifically, the development environment 300 determines whether the selected execution environment is a multi-tenant or single-tenant execution environment. If it is a single-tenant execution environment, the development environment 300 accesses the DB set of the selected single-tenant execution environment (one of DB sets 457, 467, 477, etc.) and retrieves the contents recorded in the database. The development environment 300 then sends the database information obtained from the 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. 【0182】 In S1213, the developer terminal 100 refers to the DB instance name recorded in the developer information of the logged-in developer (information registered for the logged-in developer from the developer information 301). Then, from the DB set 430 included in the multi-tenant execution environment 410, which is the execution environment selected by the development environment 300, it retrieves the contents 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. Then, the development environment 300 sends the database information obtained from the 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. 【0183】 In S1214, the developer terminal 100 displays the database management screen and shows the database information obtained in S1212 or S1213. It then accepts DB management operations, such as various settings for the database of the selected execution environment and instructions to update its contents. 【0184】 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. 【0185】 In S1216, the developer terminal 100 displays a file management screen for managing files to be saved in the selected execution environment, and in S1217, it accepts operations for managing files to be saved in the selected execution environment. For example, image files to be displayed on the screen of the application being built can be uploaded and saved to the developer area of ​​the selected execution environment. When a file to be saved to the selected execution environment is selected from the local storage area (such as the storage medium 108) of the developer terminal 100 and a save command is issued, the developer terminal 100 sends the selected file to the development environment 300. Upon receiving the selected file, the development environment 300 sends it to the developer area of ​​the selected execution environment, thereby saving it to the selected execution environment. Various execution environments only accept access from the development environment 300. Therefore, for file management, the developer terminal 100 accesses various execution environments 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 explained in the login process above, developers need to authenticate and log in to development environment 300. Therefore, by restricting access to various execution environments to only through development environment 300, other users who cannot log in to development environment 300 cannot illegally access the execution environment, thereby improving security. 【0186】 Furthermore, developer users only need to perform the authentication process required to log in to development environment 300, and do not need to perform the authentication process for each execution environment. This helps to reduce the number of operations required. 【0187】 In S1218, the developer terminal 100 determines whether or not the user management button 518 has been pressed. If it determines that the user management button 518 has been pressed, the process proceeds to S1219; otherwise, it proceeds to S1220. 【0188】 In S1219, the developer terminal 100 performs user information display processing. User information display processing displays user information (such as user information 411, 451, 461, 471 in each execution environment shown in Figure 1) which is information about application users (information managed separately from the developer) who can log in to the application built in the selected execution environment, and accepts management operations from the developer. The user information display processing will be described later using Figure 14. 【0189】 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 the snapshot process; otherwise, the process proceeds to S1222. 【0190】 In S1222, the developer terminal 100 determines whether or not a termination operation has been performed. If no termination operation has been performed, the process proceeds to S1201 and is repeated. If a termination operation has been performed, the screen switching process is terminated. 【0191】 <User information display processing> Figure 14(a) shows a specific example of developer information 301 held in the development environment 300. As shown in each row of the figure, the following information is associated with each developer and recorded in the developer information 301: the email address (username) that serves as the developer's account ID (developer ID), password, last name, first name, accessible execution environment ID, Verify, and accessible DB instance name in the multi-tenant execution environment. In this embodiment, the accessible execution environment ID is assumed to be the account ID of the cloud service. If one developer can access multiple execution environments, the accessible execution environment ID is recorded as a string in which multiple execution environment IDs are listed consecutively, separated by commas. Verify indicates whether the account is valid. Note that there may be other information associated with a single account besides the information shown in Figure 14(a). 【0192】 Figure 14(b) shows a specific example of user information 411 held in the multi-tenant execution environment 410. As shown in each row of the figure, the following information is associated with each application user and recorded in the user information 411. The account information for each application user includes the email address (username) which is the application user's account ID, password, last name, first name, information on whether the email is approved or not, and the owner ID. Multiple applications owned by multiple developers are deployed together in the multi-tenant execution environment. Therefore, in order to identify which developer (owner) created each application user, the developer ID is also recorded as the owner ID. Note that information other than the information shown in Figure 14(b) may be recorded in association with a single account. For example, the creation date and time, update date and time, etc. may also be recorded. 【0193】 Figure 14(c) shows specific examples of user information (user information 451, 461, 471, etc.) stored in a single-tenant execution environment. The user information in a single-tenant execution environment records two types: individual user information as shown in Figure 14(c1) and group information as shown in Figure 14(c2). 【0194】 As shown in Figure 14(c1), the user-specific information includes the following information associated with each app user, as shown in each row of the diagram. The app user account information includes the email address (username) which serves as the app user's account ID, password, last name, first name, and whether or not the email address is approved. On the other hand, in a single-tenant execution environment, there are no multiple applications owned by multiple developers, so the owner ID is not recorded. Note that information other than that shown in Figure 14(c1) may be recorded in association with a single account. For example, the creation date and time, and the update date and time may also be recorded. 【0195】 As shown in Figure 14(c2), the group information records the usernames of one or more members for each of the multiple group IDs, as shown in each row of the diagram. 【0196】 Figure 13(a) shows a flowchart of the user information display process on the developer terminal 100. This process is an example of a detailed flowchart of S1218 in Figure 12 mentioned above. 【0197】 In S130, the developer terminal 100 sends a command to retrieve user information for the development environment 300 (information indicating a command to retrieve user information for the selected execution environment). 【0198】 In S1302, the developer terminal 100 determines whether it has received user information sent from the development environment 300 in response to the user information acquisition instruction sent in S1301. If user information has not been received, S1302 waits for the user information to be received, and if user information is received, the process proceeds to S1303. The acquired user information is as shown in Figure 14(b) if the selected execution environment is a multi-tenant execution environment, and as shown in Figures 14(c1) and 14(c2) if the selected execution environment is a single-tenant execution environment. 【0199】 In S1303, the developer terminal 100 displays user information on the display 105 based on the user information received in S1302. Figure 15 shows an example of the user information display on the developer terminal 100 as shown in S1303. In Figure 15, the same reference numerals are used for display items that are the same as those in the display example in Figure 5(b) above, and their explanations are omitted. Display item 1501 is an instruction item for instructing the display to be based on user-specific information as shown in Figure 14(c1). Display item 1502 is an instruction item for instructing the display to be based on group information as shown in Figure 14(c2). Display items 1501 and 1502 can be switched and selected. Also, if the selected execution environment is a multi-tenant execution environment, display items 1501 and 1502 are not displayed, and it is not possible to switch to displaying group information. Group information 1505 displays user information received in S1302 (in the illustrated example, user information is displayed based on the user-specific information shown in Figure 14(c1). In group information 1505, the Username and Email Verified columns correspond to the email address (username) and whether the email is approved or not columns in the user-specific information shown in Figure 14(c1), respectively. The Delete column displays a button icon for each row that accepts instructions to delete the user account for that row. The Add User button 1503 is an operation icon that instructs the user to add a row to group information 1505 and register the information of a new app user. The Save button 1504 is an operation icon that instructs the user to save the group information 1505 with the edited content shown on the screen in Figure 15 to the selected execution environment. 【0200】 In S1304, the developer terminal 100 accepts editing operations for user information displayed in S1303. For example, this includes adding a user account by pressing the Add User button 1503, deleting a user count by pressing the button icon displayed in the Delete column, and editing the contents of editable items using the keyboard. 【0201】 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. 【0202】 In S1306, the developer terminal 100 sends an instruction to the development environment 300 to update the user information, reflecting the editing operations received in S1304. 【0203】 In S1307, the developer terminal 100 determines whether or not an execution environment change operation has occurred. If an execution environment change operation has occurred (i.e., an operation has been performed on the selected execution environment box 501), the process proceeds to S1308; otherwise, it proceeds to S1309. 【0204】 In S1308, the developer terminal 100 records the changed selected execution environment in memory 102 and sends it to the development environment 300. When the selected execution environment changes, the user information to be edited that should be displayed also changes, so the process returns to S1301 and is repeated. 【0205】 In S1309, the developer terminal 100 determines whether a screen switching operation has occurred, which is an operation to select one of the options displayed in the main menu area 510. If no screen switching operation has occurred, the process returns to S1304. If a screen switching operation has occurred, the user information display process ends and the process proceeds to the aforementioned screen switching process. 【0206】 Figure 13(b) shows a flowchart of the user information acquisition process in the development environment 300, which is the process in response to the user information display process in Figure 13(a). 【0207】 In S1311, the development environment 300 determines whether or not it has received the user information acquisition instruction sent from the developer terminal 100 in S1301. If the user information acquisition instruction has been received, the process proceeds to S1312; otherwise, it proceeds to S1316. 【0208】 In S1312, the development environment 300 obtains access destination information (connection destination information) from the selected execution environment. The access destination information obtained here is access destination information 421 if the selected execution environment is the multi-tenant execution environment 410 in Figure 1, and if the selected execution environment is the single-tenant execution environment in Figure 1, it is the access destination information 456b, 466b, 476b, etc., that pertains to the selected execution environment. More specifically, the development environment 300 obtains the execution environment ID of the selected execution environment (specific environment) from the account information of the logged-in developer in the developer information 301 and stores it in memory 304. From that selected execution environment, it accesses a file recorded in a predetermined path (a path that can be determined if the execution environment ID is known) and obtains the URL of the access destination stored in that file as 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 specified file name is, for example, a predetermined common file name common to all execution environments. In this case, the specified path will be "fixed string + execution environment ID / common file name.json". That is, if the execution environment ID is known, the specified file (access destination information file) located in a specified area is obtained, the access destination information is obtained from that file, and recorded in memory 304. The URL of the access destination information indicates an address within the execution environment, and is the URL to which requests are made to retrieve and update user information stored in the execution environment. Without making a request to this URL, it is not possible to retrieve or update user information stored in the execution environment. Thus, if the execution environment ID is unknown, the access destination information for retrieving and updating user information cannot be obtained. The execution environment ID is information that can only be obtained by a developer after they have authenticated and logged into the development environment 300. Furthermore, a developer who can log in to the development environment 300 can only obtain the execution environment IDs that they can access. 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 whose accessible execution environment is different, will illegally access the execution environment and leak user information.In other words, it improves security. 【0209】 In S1313, the development environment 300 sends a user information acquisition request (a request to execute a process to send user information to the development environment 300) and developer information (transmission control) to the access destination indicated by the access destination information obtained in S1312. The developer information to be sent to the access destination is obtained from the developer information 301, which contains encrypted account information of the logged-in developer. The account information to be obtained is one row of information for the logged-in developer from the table of developer information 301 shown in Figure 14(a). That is, it includes information such as email address, password, last name, first name, and accessible execution environment ID. This information is obtained as a single data column after being encrypted. Even if only this encrypted information is leaked, the email address, password, last name, first name, and accessible execution environment ID will not be leaked because they are encrypted. 【0210】 In S1314, the development environment 300 determines whether it has received user information from the selected execution environment in response to the user information acquisition request sent in S1313. This user information is sent from the execution environment in S1325 or S1326, which will be described later. If user information is received, the process proceeds to S1315; otherwise, it waits in S1314 for the user information to be received. 【0211】 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 as described above. 【0212】 In S1316, the development environment 300 determines whether or not it has received a user information update instruction from the developer terminal 100. The user information update instruction received here is the one sent from the developer terminal 100 in S1306 as described above. If a user information update instruction is received, the process proceeds to S1317; otherwise, it proceeds to S1318. 【0213】 In S1317, the development environment 300 sends a user information update request (a request to execute a user information update process) and developer information to the access destination indicated by the access destination information obtained in S1312. The developer information sent to the access destination is the same as that described in S1313, and is the encrypted account information of the logged-in developer obtained from the developer information 301. 【0214】 In S1318, the development environment 300 determines whether or not it has received a command from the developer terminal 100 to change the selected execution environment. This command is the one sent from the developer terminal 100 in S1308 as described above. If a command to change the selected execution environment is received, the process proceeds to S1319; otherwise, it proceeds to S1311 and the process is repeated. 【0215】 In S1319, the development environment 300 stores the execution environment ID of the selected execution environment after the change in memory 304. 【0216】 Figure 13(c) shows a flowchart of the user information management process in the selected execution environment of the execution environment 400, which is a process in response to the user information acquisition process in Figure 13(b). While the operator of this process will be simply referred to as the execution environment 400 below, in reality, it is executed by the execution engine in the selected execution environment of the execution environment 400. That is, for example, if the selected execution environment is a multi-tenant execution environment 410, the operator is the execution engine 412, and the process is implemented by the processor 413 included in the execution engine 412 executing a program using memory 414 as work memory. Similarly, if the selected execution environment is a single-tenant execution environment 450, the operator is the execution engine 452, and the process is implemented by the processor 453 included in the execution engine 452 executing a program using memory 454 as work memory. 【0217】 In S1321, the execution environment 400 determines whether or not it has received a user information acquisition request sent from the development environment 300. The user information acquisition request received here is the one sent from the development environment 300 in S1313 as described above. If the user information acquisition request is received, the process proceeds to S1322; otherwise, it proceeds to S1327. 【0218】 In S1322, the execution environment 400 performs access permission verification. This process determines whether the source of the user information acquisition request is a developer with legitimate access rights. This process reduces the possibility of user information being leaked to anyone other than a developer with legitimate access rights, thereby improving security. The access permission verification process will be described later using Figure 13(d). 【0219】 In S1323, the execution environment 400 determines whether the result of the access rights check is an error. If it is an error, it proceeds to S1321 without sending the user information it holds in its own environment to the requester of the user information acquisition request. If it is not an error, it proceeds to S1324. 【0220】 In S1324, execution environment 400 determines whether or not it is a multi-tenant execution environment 410. If it is a multi-tenant execution environment 410, it proceeds to S1326; otherwise, it proceeds to S1325. 【0221】 In S1325, the execution environment 400 sends the user information it holds in its own execution environment to the development environment 300. In a single-tenant execution environment, the owner of the environment itself is a single developer, so the user information is limited to that of applications owned by that single developer. Therefore, instead of sending only a portion of the user information owned by the logged-in developer, as in the multi-tenant execution environment processing described later in S1326, the entire user information is sent. For example, if the selected execution environment is a single-tenant execution environment 450, user information 451 is sent to the development environment 300. The user information sent here is received by the development environment 300 in S1314 and sent to the developer terminal 100 in S1315. 【0222】 In S1326, the execution environment 400 sends to the development environment 300 the portion of the user information it holds that matches the received developer information in terms of owner ID. The encrypted developer information is sent from the development environment 300, received in S1341 (described later), decoded (decrypted) in S1343, and stored in memory 414. This is the received developer information. From the user information 411 of the multitenant execution environment 410 shown in Figure 14(b), the information of the row that has the same owner ID as the developer ID (email address) included in the received developer information is obtained and sent to the development environment 300. From the user information 411 of the multitenant execution environment 410, 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 is not sent to the development environment 300. In a multitenant execution environment, user information owned by multiple developers is recorded together, so only a portion of the user information owned by the logged-in developer is sent. The user information sent here is received by the development environment 300 in S1314 and sent to the developer terminal 100 in S1315. 【0223】 In S1327, the execution environment 400 determines whether or not it has received a user information update request. The user information update request received here is the one sent from the development environment 300 in S1317 as described above. If a user information update request is received, the process proceeds to S1328; otherwise, it proceeds to S1321. 【0224】 In S1328, the execution environment 400 performs access permission verification. This process determines whether the source of the user information update request is a developer with legitimate access rights. This process reduces the possibility of user information being overwritten (updated) by requests from anyone other than developers with legitimate access rights, thereby improving security. The access permission verification process will be described later using Figure 13(d). 【0225】 In S1329, the execution environment 400 determines whether the result of the access rights check process is an error. If it is an error, it proceeds to S1321 without performing the update in accordance with the user information update request. If it is not an error, it proceeds to S1330. 【0226】 In S1330, the execution environment 400 updates the user information stored in its own environment in response to a user information update request. When registering a new user, if it is a multi-tenant execution environment, the developer ID of the logged-in developer is registered as the owner ID and associated with the new user's account information. 【0227】 Figure 13(d) shows a flowchart of the access rights verification process. This process is an example of a detailed flowchart of S1322 and S1328 in Figure 13(c) mentioned above. 【0228】 In S1341, the execution environment 400 determines whether or not it has received encrypted developer information from the development environment 300. The developer information received here is the same information that was sent from the development environment 300 in S1313 or S1317 as described above. If encrypted developer information is received, the process proceeds to S1343; otherwise, it proceeds to S1342. 【0229】 In S1342, the execution environment 400 records (outputs) that an error occurred as a result of the access rights verification process. In this case, S1323 or S1329, mentioned above, will be determined to be an error. Thus, even if a user information retrieval request or user information update request is received, if encrypted developer information is not received, it will be treated as an error, and request control will be implemented so that no processing corresponding to the request is performed (the request is not permitted). Therefore, processing in response to unauthorized access can be suppressed. 【0230】 In S1343, the execution environment 400 decodes (decrypts) the developer information received in S1341 using a pre-held decryption key. The decrypted developer information is not transmitted outside the execution environment, so the possibility of leakage is low. 【0231】 In S1344, the execution environment 400 determines whether the execution environment ID of its own execution environment (the execution environment in question) is included in the portion of the developer information decoded in S1342 that indicates the accessible execution environment. If it is included, the process terminates (in this case, the access is considered legitimate). If it is not included, the process proceeds to S1342, and an error is recorded (output) as a result of the access rights verification process. This prevents the execution environment from performing processing in response to a user information acquisition request or user information update request from a developer who does not have access rights to the execution environment. Therefore, processing in response to unauthorized access can be suppressed. 【0232】 Furthermore, the execution environment 400 will not accept access from sources other than the development environment 300, and will not process user information retrieval or user information update requests originating from sources other than the development environment 300. This ensures that even if encrypted developer information and user information retrieval or user information update requests are fabricated and sent by a device other than the development environment 300, no processing will be performed accordingly. Consequently, security is improved. 【0233】 The user information display process described above can deter unauthorized access to the execution environment 400, reduce the risk of information leakage, and improve security. While the above-described user information display process addresses user information stored in the execution environment, it can be similarly applied to other processes related to the execution environment. For example, the same process can be applied to processes related to databases and files stored in the execution environment 400 to improve security. 【0234】 For example, this can be applied to the database display and update processes described in S1210 to S1214 of Figure 12. In this case, in response to a DB operation instruction from the developer terminal 100, the development environment 300 obtains an access destination information file from the selected execution environment, similar to S1312. The access destination information file contains a DB operation request reception URL, which is the request destination for receiving DB operation requests. The DB operation request and developer information are sent to this URL, similar to S1313. The execution environment 400 performs a process to determine whether the source of the DB operation request is legitimate, similar to the processes described in Figures 13(c) and 13(d). Only if it is legitimate does it perform processing related to the DB set held in its own execution environment in response to the DB operation request. 【0235】 Furthermore, this can be applied, for example, to the file management process described in S1215 to S1217 of Figure 12. In this case, in response to a file management instruction from the developer terminal 100, the development environment 300 obtains an access destination information file from the selected execution environment, similar to S1312. The access destination information file contains a file management request reception URL, which is the request destination for receiving file management requests. Therefore, the file management request and developer information are sent to this URL, similar to S1313. The execution environment 400 performs a process to determine whether the source of the file management request is legitimate, similar to the process described in Figures 13(c) and 13(d). Only if it is legitimate does it perform processing on the files held in its own execution environment in response to the file management request. 【0236】 <Workflow Processing> Figure 16 shows a flowchart of the workflow process. This process is an example of a detailed flowchart for S1205 in Figure 12. This process is executed by the developer terminal 100. 【0237】 In S1601, the developer terminal 100 displays a workflow (WF) creation screen on the display 105. Figure 17(a) shows an example of the WF creation screen display. The submenu area 510 displays the node list 1710. The node list 1710 includes node options such as the starting point 1711, the ending point 1712, and the intermediate point status 1713. The area where the canvas 530 was displayed now displays the WF placement area 1700 instead of the canvas 530. The WF placement area 1700 is a blank area before placement. One of the multiple options (node ​​options) displayed in the node list 1710 can be selected and placed in the WF placement area 1700. In this embodiment, placement is done by drag and drop. That is, one of the multiple options displayed in the node list 1710 can be dragged and dropped into the WF placement area 1700 to place it. 【0238】 In S1602, the developer terminal 100 determines whether or not a node placement operation has occurred. Specifically, it determines whether or not a placement operation has occurred by dragging one of the multiple options displayed in the node list 1710 and dropping it into the WF placement area 1700. If a node placement operation has occurred, the process proceeds to S1603; otherwise, it proceeds to S1604. 【0239】 In S1603, the developer terminal 100 places the selected node in the WF placement area 1700 according to the operation to place the node. 【0240】 In S1604, the developer terminal 100 determines whether or not an operation to draw an arrow has occurred. An arrow is an arrow that connects two placed nodes and indicates the processing content when transitioning from the node where the arrow originates to the node where it ends. When a placed node is selected, an operation path is displayed for the selected node, and an arrow can be drawn by dragging with the mouse cursor over that operation path (i.e., pressing the left mouse button to start moving the mouse) and dropping it on another node (i.e., releasing the left button). The node where the drag started becomes the origin of the arrow, and the node where the arrow was dropped becomes the destination of the arrow. If an operation to draw an arrow has occurred, the process proceeds to S1605; otherwise, it proceeds to S1606. 【0241】 In S1605, the developer terminal 100 draws an arrow object between two nodes already placed in the WF placement area 1700 in response to an operation to draw an arrow. 【0242】 Figure 17(b) shows an example of the display after nodes and arrows have been placed in the WF placement area 1700. Nodes 1701 to 1705 are placed in the WF placement area 1700. Node 1701 is the starting node. Nodes 1702, 1703, and 1704 are intermediate (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 represents one step in a workflow that includes multiple steps, and the arrows indicate the sequence of steps. In other words, the example shown in the diagram indicates that nodes 1701 to 1705 represent the 1st to 5th steps, respectively. 【0243】 In S1606, the developer terminal 100 determines whether or not an operation to set node properties occurred. Specifically, it determines whether or not an operation to select a node already placed in the WF deployment area 1700 and right-click occurred. If an operation to set node properties occurred, the process proceeds to S1607; otherwise, it proceeds to S1608. 【0244】 In S1607, the developer terminal 100 displays a properties box for setting properties for a node and accepts operations to set the node's properties. Figure 17(c) shows an example of the display of the node's properties box. The node's properties box accepts settings for the node's ID (a default value is set that does not overlap with other nodes and can be changed), a label (the name that will be displayed), and the ID of the UI screen where the generated workflow will be placed. When setting the UI screen ID, a list of UI screen IDs is displayed as options, and the user can select and set from these options. 【0245】 In S1608, the developer terminal 100 determines whether or not an operation to set the properties of an arrow has occurred. Specifically, it determines whether or not an operation to select an arrow already drawn in the WF placement area 1700 and right-click has occurred. If an operation to set the properties of an arrow has occurred, the process proceeds to S1609; otherwise, it proceeds to S1610. 【0246】 In S1609, a properties box is displayed for setting properties for arrows, and it accepts operations to set the operation properties, which are properties of the arrows. Figure 17(e) shows an example of the display of the arrow properties box. The arrow properties box accepts the arrow ID (a default value is set that does not overlap with other arrows and can be changed), label (the name that is displayed), type, and user settings. The type can be set by selecting one of the options corresponding to Approval (Update), Request (Create), and Return (Remand). The user can be set by selecting one of the options corresponding to SelectUser and CurrentUser. The type indicates the type of action when transitioning from the original step to the next step of the arrow. Based on this type, the actions of the automatically placed UI components described later are automatically set. 【0247】 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. 【0248】 In S1611, the developer terminal 100 displays the selection acceptance form (dialog box) shown in Figure 17(e) as a wizard and accepts the selection of the status to be created. At least one of the following statuses can be selected for creation: Started, In Application, Approved, and Not Applied. 【0249】 In S1612, the developer terminal 100 displays the selection form (dialog box) shown in Figure 17(f) as a wizard, and accepts the selection of whether to add a task table. Here, it is possible to choose whether or not to generate a task table and to select the ID of the UI screen to be added. When selecting the UI screen ID, a list of UI screen IDs is displayed as options, and the user can select from these options. 【0250】 In S1613, the developer terminal 100 displays the specified form (dialog box) shown in Figure 17(g) as a wizard and accepts the specification (selection) of a database. The database can be specified by selecting from the displayed options. 【0251】 In S1614, the developer terminal 100 creates a workflow definition based on the nodes, arrows, and their respective properties already placed in the WF placement area 1700, as well as the settings configured by selecting options in S1611-S1614, and records it in the definition information of memory 102. As a result, UI components based on the workflow are automatically placed on the UI screen. The automatically placed UI components have actions automatically configured to correspond to the workflow. In this way, UI components with automatically defined actions are generated based on a workflow created by the developer user through the operation of selecting options, without the developer user having to write any code in a programming language. In addition, a table used in the workflow is created in the database specified in the designated reception form shown in Figure 17(g). Actions are also set (defined) on the canvas of the UI screen depending on the settings. The actions set on the canvas are processes to be performed when the UI screen is loaded in the constructed application. In other words, they are processes to be performed as initial operations when the screen is displayed. 【0252】 In S1615, the developer terminal 100 determines whether a screen switching operation has occurred. More specifically, it determines whether any of the options in the main menu area 510 have been selected. If any of the options in the main menu area 510 have been selected, the process in Figure 16 is terminated, and the process proceeds to the screen switching process described in Figure 12. Otherwise, the process proceeds to S1602. 【0253】 Figure 18(a) shows an example of how the database tables added in S1614 of Figure 16 are displayed when the database button 516 in the main menu area is pressed. In other words, Figure 18(a) is one of the database-related screens displayed in S1214 of Figure 12. Of the list of tables displayed in the submenu area, tables 1801 and 1802 are tables that were automatically added in response to the creation of the workflow. They were added (created) as tables included in (dependent, lower-level) the database specified in S1613. 【0254】 Figure 18(b) shows an example of the display of a UI screen canvas where UI components were automatically placed in S1614 of Figure 16. UI components 1811 to 1813 placed on canvas 530 are UI components that were automatically placed in accordance with the generation of the workflow. In other words, UI components 1811 to 1813 were not placed by the developer by dragging and dropping from the UI component list in the submenu area. An action is automatically set (defined) for UI component 1813. UI component 1813 is an automatically generated component in which an action is defined for transitioning to the next step in the workflow. Furthermore, the UI screen on which UI component 1813 is placed is the screen from which the transition to the next step in the workflow occurs when the action automatically defined for UI component 1813 is executed. 【0255】 Figure 18(c) shows an example of how the action board is displayed when UI component 1813, which is a button, is specified as the designated UI component. In other words, this action board is what is displayed in S801 as described in Figure 8 when UI component 1813 is the designated UI component. The action board 910 displays the action string as shown in Figure 18(c) as an initial value, even if the developer has not written the action in a programming language. In other words, the action board 910 displays the source code in a programming language that defines the action as an initial value, even if the developer has not written the source code in a programming language for that action. The action displayed on the action board 910 in Figure 18(c) has at least the database (3rd row) and the UI screen to be displayed next (6th row) defined based on the group of operations received from the user in the workflow creation process in Figure 16. The user can edit the actions that are automatically defined in this way using the processes S802 to S808 described above. In other words, it is possible to input programming language by using the automatically defined action string as a base, partially reusing it, partially modifying it, or adding to it. That is, it is possible to modify the automatically defined action string. In this way, by using the automatically generated and displayed action programming language as a base, actions can be set up easily with fewer operations (amount of text input) than if the developer were to write the action from scratch in a programming language. Furthermore, since the automatically generated action can be modified and customized instead of being used as is, it is possible to generate actions that meet more specific requirements. 【0256】 Figure 18(d) shows an example of how the action board of a UI screen canvas, where actions are automatically set according to the generation of a workflow, is displayed. This action board is displayed when a blank area on the canvas is specified and the context menu is processed to instruct the display of the action board. It is displayed in S1903 of Figure 19, which will be described later. The action board displays the action string as shown in Figure 18(d) as an initial value, even if the developer has not written the action in a programming language. In other words, the action board displays the source code in a programming language that defines the action as an initial value, even if the developer has not written the source code in a programming language for that action, as shown in Figure 18(d). The user can edit these automatically defined actions by the process in S1904, which will be described later. That is, similar to the actions that are automatically set for UI components as explained in Figure 18(c), actions can be easily set with fewer operations (amount of text input), and actions that meet more detailed requirements can be generated. 【0257】 The UI components and actions that are automatically generated in response to the workflow described above can be customized in the following ways, for example: • Set up an action on the campus action board to display the name of the current step in the workflow. - Place an input field (UI component) for the reason for the application, and modify the action board of UI component 1813 so that the data entered there is sent to the next step. • Modify the action board of part 1813 to save data to a different table. For example, customize it to record the application reason and case ID in a separate database. · On the campus action board, set the user who initially inputs into the UI component 1812 (combobox) to the person who applied last time by writing an action up to the programming limit. Alternatively, write an action to display eligible persons as options. 【0258】 Thus, according to this embodiment, the basic part of the workflow can be quickly created with simple operations along with the operations on the workflow creation screen and the input contents to the wizard (that is, based on an operation group including operations of selecting from options and not including operations of describing source code in a programming language). In addition, by presenting the actions set on the automatically created UI components and the canvas of the UI screen so that they can be modified in a programming language, a more flexible design can be achieved. 【0259】 <CRUD Generation Process> FIG. 19 shows a flowchart of the context menu process of the canvas. This process is an example of the detailed flowchart of S703 in FIG. 7 described above. This process is executed by the developer terminal 100. The context menu of the canvas includes options for generating CRUD. 【0260】 In this embodiment, as an example for explaining the generation of CRUD, 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) is displayed, an example where the blank area of the canvas is right-clicked and the context menu of the canvas is displayed will be explained. CRUD is an acronym formed by connecting the initial letters of the four basic functions required for 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 getting the ID of the newly registered user, UI component 2002 is an input field for getting the name of the newly registered user, and UI component 2003 of the UI is an input field for getting the age of the newly registered user. Let the UI component IDs of UI components 2001 to 2003 be "number_field_ID", "text_field_Name", and "number_field_age", respectively. 【0261】 In S1901, the developer terminal 100 superimposes and displays the context menu of the canvas near 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. 【0262】 In S1902, the developer terminal 100 determines whether the menu item (option 2013) that instructs the display of the action board from the canvas context menu 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, the process proceeds to S1906. 【0263】 In S1903, the developer terminal 100 displays the canvas action board based on the definition information stored in memory 102. An example of the canvas action board display is shown in Figure 18(d) above. Figure 18(d) shows an example where actions are automatically set. If no actions are set, the action board is displayed blank. If a developer has previously entered (set) actions on the action board and that information is recorded in the definition information, the action board displays a programming language string indicating the set action. 【0264】 In S1904, the developer terminal 100 accepts input operations in a programming language, editing operations, and function setting operations from the developer user to the action board (edit acceptance). This process is the same as the processes S802 to S823 in Figure 8 mentioned above, so the details are omitted. 【0265】 In S1905, the developer terminal 100 determines whether or not an action board closing operation (an operation to terminate the action board processing) has occurred. If there is no action board closing operation, the process proceeds to S1904 and is repeated. If an action board closing operation has occurred, the action board is hidden, the process shown in Figure 19 is terminated, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor. 【0266】 In S1906, it is determined whether the menu item (option 2015) that instructs the creation of CRUD operations from the context menu of the developer terminal 100 canvas has been pressed. If the menu item (option 2015) that instructs the creation of CRUD operations has been pressed, the process proceeds to S1907; otherwise, the process proceeds to S1914. 【0267】 In S1907, the developer terminal 100 displays CRUD input form 1 (a dialog box) as a wizard and accepts the operation to select the UI component from which to retrieve data in CRUD. Figure 20(c) shows an example of the display of CRUD input form 1. Area 2021 displays the UI component IDs of all UI components placed on the selected UI screen as options. The user (developer) makes a selection by selecting the option from the options displayed in area 2021 that they want to retrieve data from, and displaying it in the selected area 2022. 【0268】 In S1908, the developer terminal 100 determines whether a selection operation was performed on input form 1 and whether the NEXT icon 2023 was pressed. If the NEXT icon 2023 was pressed, the process proceeds to S1909; otherwise, it waits in S1908 for the NEXT icon 2023 to be pressed. 【0269】 In S1909, the developer terminal 100 displays CRUD input form 2 (a dialog box) and accepts the selection of columns to be prepared in the database table that will be the target of CRUD. Figure 20(d) shows an example of the display of CRUD input form 2. Area 2031 displays the UI component IDs of the UI components selected in input form 1 as options. The user (developer) makes a selection by selecting the option they want to use as the target column for CRUD from the options displayed in area 2031 and displaying it in the selected area 2032. 【0270】 In S1910, the developer terminal 100 determines whether a selection operation has been performed on input form 2 and whether the NEXT icon 2033 has been pressed. If the NEXT icon 2033 has been pressed, the process proceeds to S1911; otherwise, it waits in S1910 for the NEXT icon 2033 to be pressed. 【0271】 In S1911, the developer terminal 100 displays the CRUD input form 3 (a dialog box) and accepts the selection of the database and table to be CRUD. Figure 20(e) shows an example of the display of the CRUD input form 3. Area 2041 is for accepting the selection of the database. The database can be selected from the options displayed by pressing the icon on the far right. Area 2042 is for accepting the input of the table name. 【0272】 In S1912, the developer terminal 100 determines whether a selection / input operation has been performed on input form 3 and whether the FINISH icon 2043 has been pressed. If the FINISH icon 2043 has been pressed, the process proceeds to S1913; otherwise, it waits in S1912 for the FINISH icon 2043 to be pressed. 【0273】 In S1913, the developer terminal 100 generates CRUD buttons based on the content entered (selected) in input forms 1-3 and automatically places them on the selected UI screen. It also generates a UI screen called NextUI, which is the screen that is displayed when a CRUD button is pressed. In other words, a UI screen is automatically generated in the selected application. In addition, a database table of the content entered in input form 3 is automatically generated in the DB set of the selected execution environment. 【0274】 In S1914, the developer terminal 100 determines whether any of the other menu items (options 2011, 2012, or 2014) in the canvas context menu has been pressed. If any of the other menu items has been pressed, the process proceeds to S1915; otherwise, it proceeds to S1916. 【0275】 In S1915, the developer terminal 100 performs other processing, which corresponds to the menu item that was pressed. 【0276】 In S1916, the developer terminal 100 determines whether an operation to close the canvas context menu has occurred (for example, clicking outside the area where the context menu is displayed). If an operation to close the context menu has occurred, the context menu is hidden in S1917 and the process shown in Figure 19 is terminated. If no closing operation has occurred, the process returns to S1902. 【0277】 Figure 20(f) shows an example of the display of CRUD buttons (automatically generated components) that are automatically placed by the processing of S1913. Figure 20(f) is an example of the display of the canvas of the same UI screen as Figure 20(a), and the same UI components as in Figure 20(a) are given the same reference numerals. In Figure 20(f), UI components 2051 to 2053 have been added compared to Figure 20(a). These UI components 2051 to 2053 are CRUD buttons. Actions are automatically set for UI components 2051 to 2053, which are CRUD buttons. The action of UI component 2051, which is a CRUD button, is to save (update or add) the value entered in the UI component selected in input form 1 to the database table set in input form 3 in response to UI component 2051 being pressed, and then transition to the NextUI screen. The action of UI component 2052, which is a CRUD button, is to delete the data from the database table set in input form 3 that matches the value entered in the UI component selected in input form 1, and then transition to NextUI. The action of UI component 2053, which is a CRUD button, is to retrieve the data from the database table selected in input form 3 that matches the value entered in the UI component selected in input form 1, and then transition to NextUI to display the retrieved data. 【0278】 Figure 20(g) shows an example of a UI screen (UI screen ID: crud-newui-UI01) automatically generated by the S1913 process. Figure 20(g) is an example of a canvas display for a different UI screen than Figure 20(a), and a UI component, data grid 2061, is placed on it. Data grid 2061 has four columns: "ID", "number_field_ID", "text_field_Name", and "number_field_age". Of these, all columns except ID correspond to the UI component selected in input form 2. A UI component 2062, which is a button, is also automatically placed. The canvas action is also automatically set for this UI screen (crud-newui-UI01). The automatically set canvas action controls the display of data in data grid 2061 for rows that were the target of CRUD operations when the various CRUD buttons on the source screen were pressed, from the database table set in input form 3. This canvas action can also be customized by the developer (user) based on the action automatically set by the S1904 process described above. 【0279】 Furthermore, the automatically generated data grid 2061 can be edited in various ways using the grid's properties box and action board, which will be described later. For example, you can change the grid's appearance or change the label displayed as the column name from "text_field_Name" to "Name". You can also modify it to hide certain columns. After deploying and starting operation of the application, there may be situations where you want to add or remove columns due to various reasons (for example, changes in regulations or operational methods). For example, in the future, you may want to hide the "number_field_age" column in data grid 2061. In this case, you can simply delete the column you want to remove from the column properties in the UI editor. Therefore, there is no need to re-enter and regenerate CRUD input forms 1-3. In this way, by being able to edit the UI components and screens that are automatically generated in response to input into CRUD input forms (fizzed), you can easily and flexibly respond to future changes in the application's operation with minimal effort. 【0280】 Figure 21(a) shows an example of a database table that was automatically added by the S1913 process. This display example is what is displayed when the database button 516 in the main menu area is pressed. In other words, Figure 21(a) is one of the database-related screens displayed in S1214 of Figure 12. Among the list of tables (TABLES) contained in the database "sample" displayed in the submenu area, table 2101 (CRUD_T01) is a table that was automatically added in response to the generation of CRUD. Table 2102 displays the details of table 2101 (CRUD_T01), and it can be seen that in addition to the ID column, there is a column whose column name is the UI component ID of the UI component selected in input form 2. For these columns, properties such as data type are also automatically set according to the properties of the UI component selected in input form 2. 【0281】 FIG. 21(b) shows a display example when an action board of a 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 in 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 an action in a programming language, an action string as shown in FIG. 21(b) is displayed in a state where it is described in a programming language (JavaScript) 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. 21(b) is displayed as an 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, it is possible to input a programming language so as to partially reuse this, partially modify it, or add a string. That is, a correction operation for the automatically defined action string can be received. In this way, by using the programming language of the automatically generated and displayed action as a basis, the developer can easily set an action with fewer operation steps (amount of text input) than 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, it is possible to generate an action that meets more detailed requirements. 【0282】 Also, in FIG. 21(b), function list 920 in the sub-menu area displays function 2121 and function 2122 as options for pre-prepared functions. Function 2121 and function 2122 are functions automatically generated in the process of S1913 in FIG. 19. 【0283】 Figure 21(c) shows an example of the display when function 2121 is selected from function list 920 and the function settings screen is displayed. Function 2121 is an SQL function, and the SQL function settings screen is displayed. The SQL function settings screen has the same configuration as described above in Figure 10(a), so in Figure 21(c), the same setting fields / input fields as in Figure 10(a) are given the same symbols and explanations are omitted. In setting field 951, "SQL_Save" is automatically set as the function name. Also, the SQL statement is pre-filled in setting field 953. In this SQL statement, the string "INSERT INTO" indicates that the type of operation to the database is "INSERT", and that it is an operation to add a new row to the table. Also, the string "sample.CRUD_T01" indicates that the database to be processed is "sample" and the table is "CRUD_T01". This reflects the content entered in input form 3. The strings that follow indicate the values ​​of the columns included in the row to be added, and reflect the content entered in input form 1. The contents of settings fields 951 and 953 are based on automatically generated data and can be edited (modified, deleted, added to, and customized) by the developer through the processes S813 to S820 in Figure 8 mentioned above. 【0284】 Figure 21(d) shows an example of the display when function 2122 is selected from function list 920 and the function settings screen is displayed. Function 2122 is an SQL function, and the SQL function settings screen is displayed. The SQL function settings screen has the same configuration as described above in Figure 10(a), so in Figure 21(d), the same setting fields / input fields as in Figure 10(a) are given the same symbols and their explanations are omitted. In setting field 951, "SQL_Update" is automatically set as the function name. Also, the SQL statement is pre-filled in setting field 953. In this SQL statement, the string "UPDATE" indicates that the type of processing to the database is "UPDATE" and that the process updates the values ​​of existing rows in the table. Also, the string "sample.CRUD_T01" indicates that the database to be processed is "sample" and the table is "CRUD_T01". This reflects the content entered in input form 3. The strings that follow indicate the values ​​of the columns to be updated and reflect the content entered in input form 1. The contents of settings fields 951 and 953 are based on automatically generated data and can be edited (modified, deleted, added to, and customized) by the developer through the processes S813 to S820 in Figure 8 mentioned above. 【0285】 The content of the automatically generated actions illustrated in the action board 910 of Figure 21(b) will be explained in detail. Each line of JavaScript text written in the action board 910 of Figure 21(b) has the following meaning: Line 1... Defines a set of values, including the values ​​from lines 2-5, using the variable name `params`. Second line… Definition of the number that will be used as the ID. It will be a sequential number. Lines 3-5...Retrieve the value entered in the UI component selected in Input Form 1. Note that "$ui.UI component ID.type of target information" is written to the right of "=" to indicate that a value is being retrieved, but this notation itself is not the standard JavaScript notation and is unique to this system. More details on this will be explained later. Line 6... The function SQLUpdate is executed with the params defined in lines 2-5 as arguments. In other words, the database table set in input form 3 is updated with the value entered in the UI component selected in input form 1. Line 7...Gets the row affected by the Update. Line 8... This checks if there are any rows that were retrieved in line 7. In other words, it checks if there are any rows that were updated. Line 9...If line 8 is true, it will display "Successfully Updated". Line 10... NextUI transitions to the UI screen with UI screen ID "crud-newui-UI01". Line 12... This checks if the number of rows obtained in line 7 is 0. If this is true, it means that there was no existing row corresponding to the params obtained this time, so a new row will be added and a new entry will be registered. Line 13...If line 12 is true, the function SQLSave is executed with the params defined in lines 2-5 as arguments. In other words, a row is added to the database table set in input form 3 using the value entered in the UI component selected in input form 1, and a new save is performed. Line 14...Retrieves the lines affected by the new save in line 13 (i.e., the added lines). Line 15... This checks if there are any rows that were obtained in line 14. In other words, it checks if the new registration with the addition of a row was successful. Line 16...If line 15 is true, it will display "Successfully Inserted". Line 17... NextUI transitions to the UI screen with UI screen ID "crud-newui-UI01". If lines 19, 20, 8, and 12 are all false, then "Insertion Failed" will be displayed. 【0286】 The content is 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 then make customizations such as the following: • I want to change the message content (the message displayed in response to the action), so I will only rewrite the message content on lines 9, 16, and 20. I want to use a custom-made screen for the display that appears when the SAVE button is pressed (the screen that appears when an action is performed), so I will only rewrite the UI screen ID part of NextUI (crud-newui-UI01) on lines 10 and 17. We want to change the system so that age is not registered, so delete line 5. In other words, change the component that retrieves and / or outputs information when the action is executed. Since I want to register in multiple databases, I will create (add) a new SQL function (a custom function) and write it in. When creating a new SQL function, I will copy and paste the automatically created SQL statements for "SQLSave" and "SQLUpdate" into setting field 953, and only modify the part that specifies the target database and table. 【0287】 Thus, customizing automatically generated actions significantly reduces the number of steps required compared to creating CRUD button actions from scratch without any programming language code. Furthermore, the ability to freely customize the actions offers greater flexibility in their content. According to this embodiment, developers (users) can more flexibly modify and utilize defined actions (actions defined based on the operations entered into input forms 1-3) without having to write any code in a programming language. 【0288】 <Developer account registration process> Figure 22(a) shows a flowchart of the developer account registration process on the developer terminal 100. This process is an example of a detailed flowchart of S306 in Figure 3 mentioned above. 【0289】 In the S2201, the developer terminal 100 displays input fields on the display 105 that accept input for email address, last name, and first name as new account information, and accepts input from the user (developer) into each input field. 【0290】 In S2202, the developer terminal 100 sends the account information entered in S2201 and a registration request, which is a request to register that account information as a new account, to the development environment 300. 【0291】 In S2203, the developer terminal 100 displays a reception screen on the display 105 that accepts the input of a one-time password, and accepts the input of a one-time password from the user (developer). When a request to register account information is sent to the development environment 300, the development environment 300 sends a one-time password to the email address included in the account information in order to verify that the email address is valid. Since the developer is the owner of that email address, they look at the one-time password sent to that email address and enter it into the one-time password reception screen displayed on the display 105. 【0292】 In S2204, the developer terminal 100 sends the one-time password entered in S2203 to the development environment 300. 【0293】 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. 【0294】 In S2206, the developer terminal 100 displays a resend instruction screen to request the development environment 300 to resend the one-time password. 【0295】 In S2207, the developer terminal 100 determines whether or not the developer (user) has requested a resend of the one-time password. If a resend request has been received, the process proceeds to S2208. If no resend request has been received, the developer terminal 100 waits until a resend request is received. 【0296】 In S2208, the developer terminal 100 sends a request to the development environment 300 to resend the one-time password. 【0297】 In S2209, the developer terminal 100 sends a password registration screen to the developer terminal 100 and accepts password registration (input of data to be used as the password). 【0298】 In S2210, the developer terminal 100 sends the data to be used as the password, which was received in S2209, to the development environment 300. 【0299】 Figure 22(b) shows a flowchart of the developer account registration process in the development environment 300. This process is linked to the developer account registration process on the developer terminal 100 shown in Figure 22(a) and is performed on the development environment 300 side. 【0300】 In S2221, the development environment 300 determines whether it has received account information and a registration request (registration instruction), which is a request to register the account information, from the developer terminal 100. This account information and registration request were sent from the developer terminal 100 in S2202 in Figure 22(a). If the account information and the registration request, which is a request to register the account information, are received from the developer terminal 100, the process proceeds to S2222; otherwise, the process waits until they are received. 【0301】 In S2222, the development environment 300 adds a row to developer information 301 and records the account information received in S2221. The value of the "Verify" column in this row is recorded as "unconfirmed". The columns in developer information 301 are shown in Figure 14(a). Each row in developer information 301 represents the account information of one person, and the information in each column recorded in the same row is associated with the account information of the same developer. 【0302】 In S2223, the development environment 300 instructs an external one-time password issuance system (not shown) to issue and send a one-time password to the email address included in the account information received in S2221. As a result, the external one-time password issuance system sends a one-time password to the developer's email address. In this embodiment, the external one-time password issuance system is instructed to send the one-time password, but the development environment 300 itself may also send the one-time password. 【0303】 In S2224, the development environment 300 determines whether or not it has received a one-time password from the developer terminal 100. The one-time password received here is the one sent from the developer terminal 100 in S2204 in Figure 22(a). If a one-time password is received, the process proceeds to S2225; otherwise, it waits in S2224. 【0304】 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 verify whether it matches the issued one-time password. In other words, it instructs the system to verify the one-time password. 【0305】 In S2226, the development environment 300 determines whether it has received notification from the external one-time password issuance system that the one-time password was correct (that the verification was successful). If it is correct (verification was successful), proceed to S2228; otherwise, proceed to S227. 【0306】 In S2227, the development environment 300 determines whether or not it has received a request to resend the one-time password from the developer terminal 100. The request received here is the one sent from the developer terminal 100 in S2208 in Figure 22(a). If a request to resend the one-time password is received, the process proceeds to S2223; otherwise, it waits in S2227. 【0307】 In S2228, the development environment 300 activates the account added to developer information 301 in S2222. Specifically, it changes the value of the "Verify" column in the account information added to developer information 301 in S2222 to "confirmed". Account information with a "confirmed" value in the "Verify" column is considered a registered and valid account, as the registered email address has been verified as valid through one-time password matching. In this embodiment, authentication is performed using an email address, but if other contact information for the developer, such as a phone number or SNS account, is registered as account information, authentication using other contact information may be used. 【0308】 In S2229, the development environment 300 determines whether the number of valid accounts registered in the developer information 301 (the number of accounts whose "Verify" value is "confirmed") is greater than a predetermined threshold 2 (for example, 9000). If the number of valid accounts is greater than threshold 2, the process proceeds to S2230; otherwise, the process proceeds to S2232. 【0309】 S2230 determines whether a DB instance has been added to the multi-tenant execution environment 410 in the development environment 300. If the DB instance has been added, proceed to S2232; otherwise, proceed to S2231. 【0310】 In S2231, the development environment 300 adds a new DB instance to DB set 430 of the multitenant execution environment 410. Since adding (creating) a new DB instance takes several tens of minutes, preparation is done in advance when the number of active accounts exceeds threshold 1 (> threshold 2), before changing the connected DB instance. This way, when the connected DB instance changes, it is possible to connect to the new DB instance immediately without delay. 【0311】 In S2232, the development environment 300 determines whether the number of valid accounts registered in the developer information 301 (the number of accounts whose "Verify" value is "confirmed") is greater than a predetermined threshold 1 (a value greater than threshold 2, for example, 10000 developer terminals). If the number of valid accounts is greater than threshold 1, the process proceeds to S2233; otherwise, the process proceeds to S2236. 【0312】 In S2233, the development environment 300 determines whether the DB instance name held in memory 304 as the DB instance name of the multitenant execution environment 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, proceed to S2236; otherwise, proceed to S2234. 【0313】 In S2234, the development environment 300 updates the DB instance name, which was stored in memory 304 as the DB instance name of the multitenant execution environment to be assigned to newly added account information, to the DB instance name of the new DB instance added in S2231. The DB instance name is an identifier for the database environment. As a result, for example, if accounts added before this point were assigned "DB instance name 1", accounts added after this point will be assigned "DB instance name 2". When the number of accounts connecting to a single DB instance (database environment) increases, the number of times the database is accessed at once increases, which can lead to performance degradation such as slower response times when access is concentrated. In contrast, the process in S2233 configures accounts registered after this point to connect to a new DB instance (database environment) different from the previous ones if the number of accounts exceeds a threshold of 1. This reduces the possibility of access being concentrated due to an excessive number of developers using a single DB instance. Therefore, it reduces the possibility of performance degradation such as slower response times when accessing the database. 【0314】 In S2235, the development environment 300 updates threshold 1 to threshold 1 + threshold 1. It also updates threshold 2 to threshold 2 + threshold 1. For example, if threshold 1 before the update was 10,000 developer terminals and threshold 2 before the update was 9,000, then threshold 1 becomes 20,000 and threshold 2 becomes 19,000. In other words, each time the number of developer terminals increases by another 10,000 accounts (each time the number of valid accounts increases by the number of thresholds 1), the processes in S2231 and S2234 are performed. 【0315】 In S2236, the development environment 300 assigns the DB instance name held in memory 304 as the destination DB instance for the account information added in S2222 (the account added this time). More specifically, in the developer information 301, the DB instance name held in memory 304 as the destination DB instance is recorded in the column indicating the destination DB instance name (the rightmost column in Figure 14(a)) of the row for the account added this time. Through the process described in S2232 to S2235, for example, if threshold 1 is 10000 developer terminals and the account added this time is the 9999th valid account, "DB instance name 1" is recorded. If the account added this time is the 10001st valid account for developer terminals, "DB instance name 2" is recorded. 【0316】 In S2237, the development environment 300 sends a login OK notification to the developer terminal 100. This login OK notification is received by the developer terminal 100 in S2205, as described above. 【0317】 In S2238, the development environment 300 receives the data to be used as the password, which was sent from the developer terminal 100 in S2210 as described above, and registers it as the password for the newly added account information. More specifically, it is recorded in the password column of the row for the newly added account in the developer information 301. 【0318】 Figure 23(a) shows the details of DB set 430 in the multitenant execution environment 410. DB set 430 initially has a fixed number of DB environments (DB instances), which may be one or more. In this embodiment, the fixed number is 1, meaning that initially only DB instance 1 (2310) is provided. DB instance 1 contains developer information DB 2311 and individual developer databases. Developer information DB 2311 indicates which database is provided for each developer (each account). For example, DB information 2312 for developer A indicates that developer A's database is DB1. Individual developer databases include DB1 (2314), DB2 (2315), DB3 (2316), etc., and increase each time a valid account is registered in developer information 301. However, the upper limit is the same as threshold 1. If threshold 1 is 10,000 developer terminals, then DBmax(2317) is the 10,000th DB for developer terminals, and thereafter, DBs are created in different DB instances. Each inventor's DB contains one or more tables. For example, DB1(2314) contains multiple tables such as Table 1, Table 2, ... Each DB instance (database environment) is a writable database instance. 【0319】 The S2231 process ensures that DB instance 1 is created before the number of databases reaches its upper limit (threshold 1), and that DB instance 2 is created. If, after DB instance 1 has reached DBmax (2317), an additional valid developer account is added to developer information 301, S2232 will respond with Yes, and the newly registered developer will be registered in developer information 301 to connect to DB instance 2 (2320). DB instances for subsequent added accounts (developers) will then be created in DB instance 2 (2320). Note that the number of databases in DB instance 2 (2320) is also limited to threshold 1 (cumulatively, up to threshold 1 x 2), and accounts registered after that will be controlled to connect to the next DB instance in the same manner. 【0320】 Figure 23(b) shows the details of DB set 457 in the single-tenant execution environment. Since the single-tenant execution environment is dedicated to one account (one developer), DB set 457 is also dedicated to one account (one developer). Therefore, the possibility of an increase in the number of databases or a concentration of access that would degrade response times is low. Accordingly, DB set 457 is provided with only one DB environment, DB instance 1 (2350). In addition, the developer information DB 2351 only records information for one account statement (for example, DB information 2352 for developer A). There is no upper limit threshold set for the number of databases to be stored. Furthermore, as explained in Figure 22(b), the control that determines the database environment of the single-tenant execution environment to which the connection will be made, in association with the registered account information, is not performed when a new developer account is registered (added). 【0321】 <Deployment process> Figure 24(a) shows a flowchart of the deployment process on the developer terminal 100. This process is executed by the developer terminal 100 and is an example of a detailed flowchart of S426 in Figure 4. 【0322】 Figure 25(a) shows an example of the UI editor screen when the selected app is a mobile app. Canvas 2501 is a mobile-shaped canvas, modeled after a smartphone. When the deploy button 506 is pressed, the process shown in Figure 24(a) begins. 【0323】 In S2401, the developer terminal 100 sends information to the development environment 300 instructing it to deploy the selected application. Alternatively, before issuing the deployment instruction, the developer terminal 100 may perform a save process to save the latest definition information held in the memory 102 to the development environment 300 before issuing the deployment instruction. 【0324】 In S2402, developer terminal 100 displays a waiting screen. The waiting screen displays guide information indicating that the deployment process is underway. 【0325】 In S2403, the developer terminal 100 determines whether or not it has received a deployment failure notification from the development environment 300. If a failure notification is received, it proceeds to S2404; otherwise, it proceeds to S2405. 【0326】 In S2404, developer terminal 100 displays an error message indicating that the deployment failed. If the deployment fails, the processes described in S2407 and S2409 below will not be performed. 【0327】 In S2405, the developer terminal 100 determines whether or not it has received a deployment success notification from the development environment 300. The success notification includes access information (URL) for accessing the deployed application. If a success notification is received, the process proceeds to S2406; otherwise, it proceeds to S2403. 【0328】 In S2406, the developer terminal 100 determines whether the selected application (deployed application) is for mobile devices. If it is for mobile devices, it proceeds to S2408; otherwise (i.e., it is for desktop devices), it proceeds to S2407. If it is not for mobile devices, the QR code (registered trademark) described in S2409 below will not be displayed. 【0329】 In S2407, the developer terminal 100 displays a screen accessed via the URL of the deployed application (the URL to access the execution environment) included in the success notification, in a new tab of the browser software that is different from the screen displayed in the browser software before receiving the deployment instruction (for example, the UI editor screen including the canvas). This allows the developer to immediately recognize that the deployment was successful. In addition, the authentication screen or initial UI of the deployed application is displayed in the new tab, and by operating on the new tab, the developer can immediately check and verify the display content and operation of the actual application that has been deployed (built in the execution environment). This S2407 process performs the application execution process by accessing the URL of the deployed application (the URL to access the execution environment). Details of the application execution process will be explained using the flowchart in Figure 33(c) or Figure 35(c). 【0330】 In S2408, the developer terminal 100 processes the application URL included in the success notification into a QR code. That is, it generates a QR code (2D code) containing the application URL information. 【0331】 In S2409, the developer terminal 100 displays a QR code generated by S2409. The QR code is displayed according to the completion (success) of the deployment, so the developer can recognize when the deployment was successful. Figure 25(b) shows an example of the QR code display in S2409. Figure 25(b) is an example of the screen displayed when the deploy button 506 is pressed from the state in Figure 25(a) to give a deployment command 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 an open in a new tab button 2513. Note that the application URL, which is the information contained in the QR code 2511, is a different URL from the URL 2504 (the URL of the development system (application development platform) in this embodiment, which is the URL to access the developer terminal 100) displayed in the address bar of the browser displaying the UI editor screen. QR code 2511 is displayed when deployment is complete. It is the address for running the deployed application and is access information indicating the location (execution environment) where the deployment took place. 【0332】 Developers (users) can scan the QR code 2511 displayed on the developer terminal 100's display 105 with their smartphone (mobile device), thereby displaying a screen on their smartphone that accesses the URL of the deployed app (the URL to access the execution environment). Therefore, they can easily access the deployed URL with minimal steps. In this case, the smartphone functions as the app user terminal 201. This displays the authentication screen or initial UI of the deployed app on the smartphone, allowing the user to immediately check and verify the display content and operation of the actual deployed (built in the execution environment) app by operating the smartphone. Because the operation of the mobile app can be checked and verified on the mobile device rather than the developer terminal 100, it is easier to determine if the app is suitable for mobile use than if it were checked and verified on the developer terminal 100. In addition to, or instead of, the QR code 2511 may be used to display a code image other than a QR code as the code image that reads the app URL included in the success notification. For example, a barcode or Chameleon Code (registered trademark) may also be used. Alternatively, the QR code dialog 2510 may be configured to display the app's URL itself, which is included in the success notification, as a string. 【0333】 In S2410, the developer terminal 100 determines whether the "Open in new tab" button 2513 has been pressed. If the "Open in new tab" button 2513 has been pressed, the process proceeds to S2407; otherwise, it proceeds to S2411. 【0334】 In S2411, the developer terminal 100 determines whether the close button 2512 has been pressed. If the close button 2512 has been pressed, proceed to S2412; otherwise, proceed 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 instructions. 【0335】 Figure 24(b) shows a flowchart of the deployment process. This process is executed by the development environment 300 and is started when the development environment 300 receives the deployment instruction sent from the developer terminal 100 in S2401 of Figure 24(a). 【0336】 In S2421, the development environment 300 retrieves the definition information of the selected application to be deployed from the application definition information stored in the developer area of ​​the logged-in developer within the storage 320 of the development environment 300. The definition information retrieved here includes the UI definition information (uiDef.json), which will be described later, and the execution environment program (JavaScript). 【0337】 In S2422, development environment 300 determines whether the selected execution environment is a multi-tenant execution environment. If it is a multi-tenant execution environment, proceed to S2423; otherwise (if it is a single-tenant execution environment), proceed to S2424. 【0338】 In S2423, the development environment 300 stores the definition information of the selected application obtained in S2421 in the developer area (dedicated folder) of the logged-in developer, which is part of the storage 420 of the multi-tenant execution environment 410. More specifically, it sends the definition information of the selected application 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 (a folder for each developer) of the logged-in developer. If this recording is completed without any problems, the deployment is considered successful. 【0339】 In S2424, development environment 300 stores the definition information of the selected application obtained in S2421 in the storage of the single-tenant execution environment (a folder directly under the bucket of the single-tenant execution environment), which is the selected execution environment. More specifically, it sends the definition information of the selected application obtained in S2421 to the single-tenant execution environment, which is the selected execution environment, and instructs multi-tenant execution environment 410 to record it in the folder directly under the bucket. If this recording is completed without any problems, the deployment is considered successful. 【0340】 In S2425, the development environment 300 determines whether the deployment has failed. If the deployment fails, 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. 【0341】 In S2426, the development environment 300 sends a failure notification indicating that the deployment has failed to the developer's terminal 100. 【0342】 In S2427, the development environment 300 determines whether the deployment has completed (succeeded). If the deployment has completed, it proceeds to S2428; otherwise, it proceeds to S2425. 【0343】 In S2428, the development environment 300 sends a success notification of the deployment, including information on the URL of the deployed app (information on the access destination for accessing the app deployed in the execution environment), to the developer's terminal 100. The success notification sent here is received by the developer's terminal 100 in S2405 of FIG. 24(a) described above. 【0344】 <Template of UI screen> The template of the UI screen 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 that UI screen in the past. The template screen can be customized for the information prepared in advance. More specifically, the template screen can be displayed on the canvas in the UI editor and can be edited by the UI editor process described in FIG. 4. 【0345】 Figure 26(a) shows an example of how template screen options are displayed when a list of UI screens is displayed as options in the submenu area 520. This display is performed by the process S401 in Figure 4 described above. Figure 26(a) is an example of expanding and displaying a list of UI screen options that belong to the AuthenticationUI (Authentication UI screen, Authentication screen) group among the UI screens classified into multiple types. The group name 2610 indicates that the group being expanded and displayed is AuthenticationUI. When group name 2610 is pressed, the expanded AuthenticationUI options are collapsed, and the group names of the other groups are displayed in the submenu area 520. Options 2611 to 2622 are each options for one UI screen, and all of them are pre-prepared as template screens. 【0346】 Figure 26(b) shows an example of the display when option 2611 is selected and the template screen (UI screen) corresponding to option 2611, "Sign in ID," is displayed on canvas 2630. The screen in Figure 26(b) is displayed as S404 in Figure 4 as described above, in response to option 2611 being pressed. Template components 2631 to 2634 are displayed on canvas 2630. Template components 2631 to 2634 are not placed by the user (developer) by dragging and dropping from the UI component list in submenu area 520, but are template UI components with predefined display positions (arrangement), colors, sizes, and display content. Template components 2631 to 2634 are UI components as follows: • Template component 2631: UI component for displaying "Sign In" in Output Field. • Template component 2632: A UI component of type TextField that accepts input for the application's username (user ID), which is an email address. In other words, a UI component that accepts input for user-specific information. • Template component 2633: This is a button UI component that is set (labeled) to display "CREATE ACCOUNT?". When pressed, it is pre-configured (predefined) to transition to the "Sign Up form" screen, which is a type of template screen (the screen shown in Figure 27(c), which is the UI screen corresponding to option 2614). • Template component 2634: This is a UI component for a button, and it is set (labeled) to display "NEXT". When pressed, it is predetermined (predefined) that it will retrieve the value (email address) entered in template component 2632 and transition to the "Sign in Password" screen, which is a type of template screen (the screen shown in Figure 27(a), which is the UI screen corresponding to option 2612). 【0347】 Figure 27(a) shows an example of how the "Sign in Password" screen is displayed on the canvas. Figures 27(a) to 27(k) are partial examples showing only the canvas portion when the template screen is displayed on the canvas. The template components 2711 to 2715 placed on the "Sign in Password" screen are UI components as follows. • Template component 2711: A UI component of type TextField for accepting the user password of the application. • Template component 2712: This is a button UI component that is set to display "Forget Password?". When pressed, it is predetermined (predefined) that the user will transition to the "Reset Password Step1" screen, which is a type of template screen (the screen shown in Figure 27(g), which is the UI screen corresponding to option 2618). • Template component 2713: The checkbox displays "Trust this device for 14 days". • Template component 2714: A button that displays "CHANGE EMAIL," and when pressed, it is predefined to return to the "Sign in ID" screen. • Template component 2715: A button labeled "SIGN IN". When pressed, it is predetermined to send the value entered in template component 2632 (email address), the value entered in template component 2711 (password), and whether the checkbox in template component 2713 is checked or not to the execution environment on which the application is built. 【0348】 In the actual application, when a button corresponding to the template component 2715 displayed on the application user terminal 201 is pressed, the application user terminal 201 sends the email address that will serve as the username, the password, and whether or not a checkmark is checked to the execution environment. The execution environment verifies whether the received email address and password combination is correct by comparing it with the user information 411 of the multi-tenant execution environment (shown in Figure 14(b)) or the user-specific information of the single-tenant execution environment (shown in Figure 14(c1)). If the verification is successful, the user is logged into the application, and the initial UI is displayed on the application user terminal 201. 【0349】 Similarly, the following illustrations show examples of how the template screens are displayed on the canvas. All of these are screens related to user authentication for the application. • Figure 27(b): UI screen corresponding to option 2613. • Figure 27(c): UI screen corresponding to option 2614. • Figure 27(d): UI screen corresponding to option 2615. • Figure 27(e): UI screen corresponding to option 2616. • Figure 27(f): UI screen corresponding to option 2617. Figure 27(g): UI screen corresponding to option 2618. Figure 27(h): UI screen corresponding to option 2619. • Figure 27(i): UI screen corresponding to option 2620. Figure 27(j): UI screen corresponding to option 2621. • Figure 27(k): UI screen corresponding to option 2622. 【0350】 Each of the template screens described above is customizable and can be edited by developers using the UI editor, as explained in the process from S405 onwards in Figure 4. Editable elements include adding other UI components different from the template components, changing the placement and display size of template components, and changing the properties of template components (such as the display format, including text and color). The actions on the template screen's canvas can also be set and modified. However, it is not possible to change, delete, or erase the actions of template components. Similarly, actions of regular UI components (non-template components) added to the template screen cannot be changed or deleted. This prevents unintended errors caused by modifications to the actions required for authentication using the cloud service, which could lead to the authentication process failing. In other words, the actions required for error-free authentication are predefined in the template components of the template screen and are not modifiable, ensuring that the authentication process using the cloud service will function correctly even if developers customize the template screen. The reason why actions cannot be set on regular UI components added to the template screen is to prevent actions that would cause authentication to malfunction from being set. For example, if a new button is added to the "Sign in ID" template screen in Figure 26(b), and an action is set to that button that transitions to a UI screen unrelated to authentication, the email address and password required for authentication cannot be sent to the execution environment, and authentication will not work. Since the destination UI screen will not be displayed when authentication is not OK, the application will not function correctly. Such problems can be prevented by preventing actions from being set on regular UI components added to the template screen. 【0351】 Figure 26(c) shows an example of the context menu 2655 of button 2654 placed on a canvas of a UI screen that is not a template screen. As shown here, the context menu of a button usually includes options for action and delete. This is the same as explained in the example in Figure 5(d). Therefore, as explained in S711~S720 of Figure 7, it is possible to edit properties, edit actions, and delete components. 【0352】 Figure 26(d) shows an example of the context menu 2635 of button 2634 placed on the canvas of the template screen. As shown, the context menu of the template component placed on the template screen does not display the options for action or delete. This prevents the setting of actions and the deletion of the template component. In other words, the action board is not displayed either. Therefore, as explained in S721 to S724 of Figure 7, only property editing (changing the display format) is possible for the template component. 【0353】 Figure 26(e) shows an example of the display after editing (customization) the template screen canvas shown in Figure 26(b). The same UI components are denoted by the same symbols in Figure 26(b) and Figure 26(e). UI component 2641 is an output-type UI component added by the developer, and it displays an image file uploaded by the file management operation S1217 in Figure 12. If this image is an icon or image representing the app, it becomes easier for the user to understand which app this authentication screen is for. UI component 2642 is a type of UI component added by the developer that outputs a text message. In addition, as an action on the canvas of this screen, the developer has set an action by opening the canvas action board that retrieves today's date and, if it is the end of the month, displays the string "It is the end of the month closing date, so don't forget to submit your application" in UI component 2642. In this way, it is also possible to place UI components whose display content changes depending on the conditions for displaying this authentication screen. Template component 2631 is the same UI component (a UI component with the same ID) as template component 2631 in Figure 25(b), but the content displayed (label) is changed by the developer's property editing operation, and it displays "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 create a screen that allows the app user to easily recognize which app's authentication screen (login screen) it is, to design it in accordance with the company's established internal standard design, or to create a screen with a more suitable design that matches the nature of the app. 【0354】 <Example of property box display> This section explains the properties box that appears when you select a property from the context menu of a UI component placed on the canvas. 【0355】 Figure 28(a) shows an example of the display of the pie chart's properties box. Figure 28 is the screen displayed by right-clicking the pie chart 531, a UI component placed on the canvas 530, from the display state shown in Figure 5(b), and selecting "Properties" from the context menu that appears. The process of displaying this screen and accepting editing requests for the displayed properties box is performed in S706 as described in Figure 7 above. Property box 2810 is the properties box for the pie chart 531. Property box 2810 is displayed together with the pie chart 531 displayed on the canvas 530. The display format of the pie chart 531, such as the ratio and color coding, is displayed based on the settings in property box 2810. When the settings in property box 2801 are changed and the apply button 2811 is pressed, the display format of the pie chart 531 is updated based on the latest setting value (changed setting value) in property box 2801. In other words, developers can perform setting operations on property box 2810 while checking how the display format of the pie chart 531 changes. 【0356】 When a pie chart is dragged and dropped onto the canvas from the UI component list, if no values ​​are set, the sections representing each ratio of the pie chart will not be displayed, resulting in a simple circle-like appearance. This prevents developers from intuitively recognizing the placed UI component as a pie chart. To solve this, a predetermined initial value (a default setting not set by the developer) should be set as a property of the pie chart. By doing this, when a pie chart is dragged and dropped onto the canvas from the UI component list, a pie chart divided into sections according to ratios will be displayed from the start, allowing developers to quickly and intuitively understand that the placed UI component is a pie chart. 【0357】 Within the property box 2810, the Value input area 2812 is where you enter the ID, numerical value, color, and label (display string) for 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, only a portion of the initial values ​​is displayed, and you can scroll to see the entire set from beginning to end. The full text of the initial values ​​displayed in the Value input area 2812 is assumed to be as follows. Note that "" represents double quotes. 【0358】 [{″id″:″Jan″,″value″:Developer 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 shown in the structure used when writing in a programming language. Of the entire initial value above, the part enclosed in "{" and "}" corresponds to one dataset in the pie chart. A string enclosed in "" and linked with ":" is a pair of key name and key value. For example, in ""id":"Jan"", the key name is "id" and the key value is "Jan". "," is the separator between the previous key and the next key. In other words, of the entire initial value above, the part containing multiple pairs such as {"id":"Jan","value":Developer terminal 100.33","color":"#394E79","month":"Jan"} is one dataset (one set), and it contains four key name and value pairs: id, value, color, and month. It can be seen that there are a total of five such datasets. Thus, the initial value of the pie chart is a set of settings that contains multiple datasets, each containing a set of default settings. 【0359】 Developers can freely edit the initial values ​​displayed in the Value input area 2812 of the property box 2810 by selecting the Value input area 2812 and entering values ​​from the keyboard. However, since the initial values ​​are displayed in a structure that is easy to understand as described above, it is easy to understand what to edit and how to edit it. Also, by pressing the Apply button 2811, the edited content is reflected in the pie chart 531, so you can see how the pie chart 531 changes when you change the values ​​in each part of the structure. Therefore, it is easy to understand what each part of the string displayed in a structure that can be written in a programming language means. 【0360】 If the goal is simply to allow users to set the pie chart's parameters, one could separate the settings in the property box 2810 into items such as "Area 1 ID," "Area 1 Value," "Area 1 Color," "Area 1 Display Label," etc., and have the developer input or select each item. However, in this embodiment, we do not do this. Instead, we display the initial values ​​in a structure that is consistent with how they would be written in a programming language, and when the developer edits them, they input the information in a way that follows the same structure. This is because the pie chart's parameters can be changed by actions entered in JavaScript on other UI components or the canvas's action board. By displaying the initial values ​​as copyable text (strings) in a structure that can be written in a programming language, developers can copy these strings to the clipboard using a known copy and paste method and paste them into the action board. Then, by modifying only the text in the part they want to change on the action board, they can easily write actions that change the display content of the pie chart. In this way, when developers want to write actions that change the display format of the pie chart, they may not be able to write the actions they intend because they don't know how to write them, or they may spend a lot of time researching how to write them. In other words, it allows for more efficient software development. Because it's a programming language, it also offers a high degree of flexibility for further editing. 【0361】 Figure 29 shows an example of how the action board looks when the developer has entered an action to change (specify) the display format (display content) of pie chart 531 into the action board of another UI component (button) placed by the developer, which is different from pie chart 531. The action board 2900 shown in the figure is a description area (input area) in which the action to be executed when the button is pressed in the built application is written in a programming language. Of the strings (strings in JavaScript) displayed on action board 2900, lines 2 to 32 are based on the initial values ​​displayed in the Value input area 2812 of property box 2810, with line breaks added for readability, and only the numbers 2901 to 2951 have been edited (changed). Of course, other parts can be changed, and data sets (parts enclosed in "{}") can be added or deleted. In this way, inputting actions in a programming language becomes very easy. In the built application, when the button corresponding to this action board is pressed, the pie chart will be displayed in a format based on the content described in this action board, rather than using its default values. 【0362】 Similar to pie charts, UI elements such as lists also have initial values ​​(default settings), and these initial values ​​are displayed in the property box according to the structure used when describing them in a programming language. Figure 28(b) shows an example of the display of the property box 2820 for list 2802. As shown in the figure, the initial value is displayed in the Value input area 2821 according to the structure used when describing it in a programming language. 【0363】 Similar to pie charts, the LINE CHART (line chart, line graph) UI component also has initial values ​​(default settings), and these initial values ​​are displayed in the properties box according to the structure of how they would be written in a programming language. Figure 28(c) shows an example of the display of the properties box 2830 of LINE CHART 2803. Input areas 2831 to 2834 display the initial values ​​according to the structure of how they would be written in a programming language, as shown in the figure. 【0364】 Similar to pie charts, UI components such as data grids (tables), combo boxes, tab components, steppers, and breadcrumbs also have initial values ​​(default settings), and these initial values ​​are displayed in the properties box according to the structure of how they would be written in a programming language. Figure 28(d) shows an example of the display of the properties box 2840 of data grid 2804. As shown in the figure, the input area 2841 displays the initial values ​​according to the structure of how they would be written in a programming language. The initial value of the data grid includes a dataset for multiple rows, with the values ​​of each column in each row of the data grid forming one dataset. 【0365】 <Setting DataGrid Properties and Actions> Figure 30 shows a flowchart of the context menu processing for the data grid on the developer terminal 100. This process is an example of the detailed flowchart for S705 in Figure 7 mentioned above. This process is executed by the developer terminal 100. 【0366】 In S3001, the developer terminal 100 displays a context menu for the data grid. Figure 31(a) shows an example of the display of the context menu for the data grid. The data grid 3110, a UI component placed on the canvas 530, has six columns, columns 3111 to 3116. The dotted line surrounding the data grid 3110 is an auxiliary line in the diagram illustrating the entire data grid 3110 and is not displayed. The context menu 3120 for the data grid is displayed near the mouse cursor. The context menu 3120 displays at least property 3121 and action 3122 as options that will become menu items. 【0367】 In S3002, the developer terminal 100 determines whether property 3121 has been pressed (selected) from the options included in the context menu 3120. If property 3121 has been pressed (selected), the process proceeds to S3010; otherwise, it proceeds to S3003. 【0368】 In S3003, the developer terminal 100 determines whether action 3122 has been pressed (selected) from the options included in the context menu 3120. If action 3122 has been pressed (selected), the process proceeds to S3020; otherwise, it proceeds to S3004. 【0369】 In S3004, the developer terminal 100 determines whether one of the other options included in the context menu 3120 has been pressed (selected). If one of the other options has been pressed (selected), the process proceeds to S3005; otherwise, it proceeds to S3006. 【0370】 In S3005, the developer terminal 100 performs additional processing in response to the pressing (selection) of other options. For example, if the option to delete is selected, the specified UI component, the data grid, is deleted (deleted) from the canvas. 【0371】 In S3006, the developer terminal 100 determines whether an operation to close the context menu has occurred (for example, clicking outside the area where the context menu is displayed). If an operation to close the context menu has occurred, the context menu is hidden in S3007 and the process shown in Figure 30 is terminated. If no closing operation has occurred, the process returns to S3002. 【0372】 In S3010, the developer terminal 100 displays the properties box of the data grid, which is a specified UI component. Figures 31(b) to 31(f) show examples of the display of the data grid's properties box. In Figures 31(b) to 31(f), the same display items are denoted by the same symbols. The Apply button 3131 in Figure 31(b) is a button icon that instructs the system to apply the content entered in the properties box (changed settings). When the Apply button 3131 is pressed, the display format of the data grid, which is a specified UI component placed on the canvas displayed together with the properties box, is changed based on the latest settings in the properties box. The column selection field 3132 is a selection tab for selecting the column whose settings you want to change. The data grid's properties box displays a screen that accepts settings for each column, and accepts the settings for the properties of each column. The Add Column button 3133 is a display item that instructs the system to add a column to the data grid, which is a specified UI component. 【0373】 In S3011, the developer terminal 100 determines whether a tab corresponding to any column has been pressed in the column selection field 3132 within the properties box. That is, it determines whether any column has been selected as the target for configuration. If a tab corresponding to any column has been pressed, the process proceeds to S3012; otherwise, it proceeds to S3013. Of the tabs (options) displayed in the column selection field 3132, the leftmost tab (not shown) is labeled "DataGrid," and this tab displays the settings screen for configuring the entire data grid, which is a specified UI component. This "DataGrid" tab is not related to a specific column (it does not allow for the selection of a specific column). 【0374】 In S3012, the developer terminal 100 switches the display content of the area below the column selection field 3132 in the properties box to the settings screen (element screen) for the selected column. Figure 31(c) shows an example of the display when tab 3132E (the tab labeled "CompanyE") is selected in the column selection field 3132. In the area of ​​the properties box below the column selection field 3132, the upper area 3134t of the tab 3132E settings screen is displayed as a screen that accepts settings for the column corresponding to tab 3132E. This includes, for example, the type setting field 3135 for selecting the part type (component type) of the column. The tab 3132E settings screen continues further down, and the lower part can be displayed by scrolling. Figure 31(d) shows an example of the display when the lower area 3134d of the tab 3132E settings screen is displayed after scrolling. The lower area 3134d includes a column delete button 3136 for deleting the column itself corresponding to tab 3132E, and an apply button 3137 for applying the settings configured on the settings screen of tab 3132E and reflecting them in the data grid displayed on the canvas. The column selection field 3132 moves upward as you scroll and becomes invisible within the properties box, but it will reappear when you scroll back up so that the upper area 3134t is visible. Note that if the "DataGrid" tab is selected in S3011, the display content of the area below the column selection field 3132 in the properties box will switch to the settings screen for configuring the entire data grid. 【0375】 In S3013, the developer terminal 100 determines whether the column addition button 3133 in the properties box has been pressed. If the column addition button 3133 has been pressed, the process proceeds to S3014; otherwise, it proceeds to S3015. 【0376】 In S3014, the developer terminal 100 performs the column addition process. In the column addition process, the column addition form 3138 shown in Figure 31(e) is first displayed, and the developer (user) is asked to set the ID and label (name of the column to be displayed) of the column (table column) to be added. Then, when the ADD TO Value button is pressed, the new column is added, and a tab corresponding to the new column is added to the column selection field 3132. 【0377】 Figure 31(f) shows an example of how the properties box looks when a column is added. Compared to Figure 31(c), a tab 3032F (labeled "CompanyF") corresponding to the new column has been added to the column selection field 3132. Immediately after adding the column, the added column is selected, and the upper area 3139t of the settings screen for tab 3032F corresponding to the added column is displayed in the area below the column selection field 3132. Thus, in this embodiment, adding a column to the data grid (table) is done by operating on the properties box, which is the settings screen for the data grid. 【0378】 In S3015, the developer terminal 100 determines whether or not a setting operation has been performed on the selected column. Specifically, it determines whether or not input operations have been performed on the various setting fields on the setting screen displayed in the area below the column selection field 3132. If input operations have been performed on the setting fields, the process proceeds to S3016; otherwise, it proceeds to S3017. 【0379】 In S3016, the developer terminal 100 accepts setting operations and reflects them in the display. For example, it accepts setting the type for the type setting field 3135. In this way, the data grid allows you to select the type of component (part) for each column. The options for component types that can be set for a column are displayed as TextInput, NumberInput, ComboBox, Multi-Select, CheckBox, DataPicker, Link, Button, and IconButton, and the developer can select and set one of them. In addition, at least some of the other configurable items (setting items) change depending on the type of component selected. For example, if TextInput is selected as the type, the other setting items include the following: ValueType, ID, Label (string displayed as the column name), Width (column width), NumberFormat, DataFormat, Options, Footer, FooterText, Sorting, and Visibility. In addition, the setting items that can be set on the overall data grid settings screen corresponding to the "DataGrid" tab include the following: This includes the ID (UI component ID of the data grid), the overall size of the DataGrid (width, height), whether it should be editable in the deployed app, whether to display an add row button instructing the app to add rows to the data grid, whether to display a delete button for the data grid, whether to display an update button for the data grid, etc. 【0380】 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, the process proceeds to S3018; otherwise, it proceeds to S3019. 【0381】 In S3018, the developer terminal 100 records the settings configured in the properties box into definition information stored in memory 102, and changes the display format of the data grid, a specified UI component displayed on the UI editor canvas, to reflect the configured settings. For example, if a column has been added, the data grid is displayed with one column added, and if the column width has been changed, the width of the column in the data grid on the canvas is changed and displayed accordingly. 【0382】 In S3019, the developer terminal 100 determines whether the exit button 3140 has been pressed. If the exit button 3140 has been pressed, the properties box is hidden and the process shown in Figure 30 is terminated. If the exit button 3140 has not been pressed, the process proceeds to S3011. 【0383】 In this way, adding columns to a data grid (table) and configuring each column can be done with greater ease of use. In particular, adding columns to a data grid can be done through operations on the data grid's properties box, and settings for the added column can be performed within the same properties box. In other words, the series of operations—adding a column and configuring the added column—can be performed smoothly with the same intuitive operation of working with the properties box. Furthermore, after adding a column, the type can be set from the available options for the column's components, allowing for the addition and setting of columns without confusion. 【0384】 In S3020, the developer terminal 100 displays a selection of column-specific actions as a submenu of the context menu. Figure 32(a) shows an example of the display in S3020. Figure 32(a) is an example of the display when action 3122 is pressed from the state in Figure 31(a). The same symbols are used for the same displayed items in Figure 31(a) and Figure 32(a). Submenu 3210 is displayed as a submenu of action 3122 in the context menu 3120. Submenu 3210 contains options 3211 to 3217. Option 3211 is an option to open the action board for actions to be performed in response to operations on the entire data grid 3110. Options 3212 to 3217 are options to open the action board for column-specific actions to be performed when each column of the data grid 3110 is operated on. Options 3212 to 3217 correspond to columns 3111 to 3116, respectively. In this case, the options corresponding to the action board for columns in a data grid different from the data grid of the specified UI component will not be displayed. 【0385】 In S3021, the developer terminal 100 determines whether either an action option for the entire data grid (option 3211) or an action option for each column (3212-3217) has been selected. If either action option is selected, the process proceeds to S3022; otherwise, it waits for a selection in S3021. 【0386】 In S3022, the developer terminal 100 displays an action board corresponding to the selected action options. 【0387】 Figure 32(b) shows an example of the display of the action board corresponding to the action options (option 3211) for the entire data grid. "DATA GRID" is selected in the overall or column selection area 3220, indicating that action board 3211a is the area for entering actions for the entire data grid. The trigger for executing the settings in action board 3211a is predetermined; it is triggered by pressing the overall button displayed outside the column area of ​​the data grid, which is a specified UI component in the built application. In other words, this trigger is related to the data grid (table), a specified UI component, and is not related to the columns of that data grid. The overall button is a button that is displayed when it is set to display in the settings screen corresponding to the "DataGrid" tab in the aforementioned property box. Examples include the data grid delete button and the data grid update button mentioned earlier. Therefore, developers do not need to set what the trigger for executing the action is (they do not need to write it in JavaScript). This action board 3211a can be configured by writing JavaScript for actions such as calculating the sum of all rows in a specific column and displaying it in another UI component, saving the contents displayed in the data grid to the database, and transitioning to another UI screen. 【0388】 Figure 32(c) shows an example of the display of the action board corresponding to the action options (option 3212) for a specific column in the data grid. "MONTH" is selected in the selection area 3220, indicating that the action board 3212a is the area for entering actions for the column (column 3111) whose label or column ID is "MONTH". The trigger for executing the content set in the column's action board 3212a is predetermined, and in a built application, the trigger is when the value of a cell in any row of the corresponding column among the specified UI components is changed, or when a button displayed in a cell in any row of the corresponding column is pressed. Therefore, developers do not need to set what the trigger for executing the action is (they do not need to write it in JavaScript). For example, it is possible to set an action in this action board 3212a to calculate the sum of the value of the row in the column corresponding to action board 3212a that has been changed 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 to display the sum of the changed values ​​in the first and second columns in the third column of the same row when the value in the first column of the table changes. In other words, it is possible to configure actions that affect other columns in the specified UI component, the data grid, which are different from the column corresponding to the selected option 3212. 【0389】 Furthermore, by selecting another column in selection area 3220, it is possible to switch to and display the action board of another column even after opening the action board. 【0390】 In S3023, the developer terminal 100 accepts input commands for actions on the displayed action board. This process is the same as the processes in S802 to S823 in Figure 8 described above. 【0391】 In S3024, the developer terminal 100 determines whether or not an action board closing operation (an operation to terminate the action board processing) has occurred. If there is no action board closing operation, the process proceeds to S3023 and is repeated. If an action board closing operation has occurred, the action board is hidden, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor. 【0392】 In this way, actions can be set for each column in the data grid (table) with greater ease of use. In particular, as shown in submenu 3210, the options corresponding to the action boards for all columns in the data grid (table) are displayed in a list, so developers can recognize that actions can be set for each column, reducing the possibility of forgetting to set actions for columns. Furthermore, since it is displayed as a submenu of the context menu of the specified UI component, the data grid, its relationship to the specified UI component, the data grid, can be clearly understood. In other words, design work can be carried out while understanding without confusion which data grid and which column the action set in the action board relates to. 【0393】 <Action execution related processing> Figure 33(a) shows a flowchart of the saving process (record control process) executed by the development environment 300, which is the destination for recording the definition information. This process is executed in conjunction with the receipt of the definition information transmitted from the developer terminal 100 in S422 of Figure 4 mentioned above. 【0394】 Furthermore, Figure 34 illustrates the transition of information recorded on the developer terminal 100, development environment 300, execution environment 400, and application user terminals 200 and 201. Figure 34 schematically represents the transition of information through the flowchart processing shown in Figures 33(a) to 33(c). 【0395】 In S3301 of Figure 33(a), the development environment 300 determines whether or not it has received definition information (UI definition information) for the selected application from the developer terminal 100. The definition information received here is the same information that was sent from the developer terminal 100 in S422 of Figure 4 mentioned above. If the UI definition is received, the process proceeds to S3302; otherwise, it waits in S3301. 【0396】 In Figure 34, the UI definition information 3401 recorded in the memory 102 of the developer terminal 100 is the definition information received by S3301. In this embodiment, the UI definition information is a text file named "uiDef.json" written in JSON format. JSON stands for JavaScript Object Notification, and it is a document standard and data description language for handling values ​​in JavaScript. The UI definition information 3401 includes various settings related to the application, such as the initial UI, and information defining UI components (UI parts) for each UI screen (position, size, color, etc.). The UI definition information 3401 also includes an action description section 3402. This action description section 3402 is a string entered in the action board or function setting screen (including the creative function setting screen) of each UI part or canvas. The action description section 3402 includes actions written in JavaScript and function definitions in JSON format that describe the content set in the function setting screen without entering JavaScript. This UI definition information 3401 is sent (uploaded) from the developer terminal 100 to the development environment 300 and received by the development environment 300 at S3301. 【0397】 In S3302, the development environment 300 saves the UI definition information to the area of ​​the storage 320 reserved for logged-in developers. As a result, as shown in Figure 34, the UI definition information 3411 is recorded in the development environment 300. Immediately after this saving, the UI definition information 3411 recorded in the development environment 300 is the same as the UI definition information 3401 recorded in the developer terminal 100. 【0398】 In S3303, the development environment 300 extracts action information from the UI definition information saved in S3302. Specifically, the development environment 300 extracts the action description portion 3412 from the UI definition information 3411 in Figure 34. 【0399】 In S3304, the development environment 300 generates an execution environment program from the action description portion 3412 extracted in S3303 and saves it in the area of ​​the storage 320 reserved for logged-in developers. That is, based on the action description portion 3412 extracted from the UI definition information 3411 in Figure 34, the execution environment program 3413 is generated and saved within the development environment. The execution environment program 3413 is text data written in JavaScript. The execution environment program 3413 is a program that adds the necessary supplementary parts to be executed by the execution engine of the execution environment, in addition to the string that was entered into the action board obtained from the action description portion 3412. 【0400】 The UI definition information 3411 and the execution environment program 3413, saved in the development environment 300 through the save process described in Figure 33(a), are deployed (placed, saved, recorded, and built) to the execution environment 400 through the deployment process. This process is performed in S2423 or S2424 of Figure 24 as described above. As a result, the UI definition information 3421 and the execution environment program 3423 are recorded in the execution environment 400, as shown in Figure 34. The UI definition information 3421 and the execution environment program 3423 in the execution environment 400 are the same information as the UI definition information 3411 and the execution environment program 3413, respectively. This state is the state in which the application has been generated. 【0401】 Figure 33(b) shows a flowchart of the application execution process in the execution environment 400. This process is executed by the execution engine of the execution environment 400 and is performed when an application user terminal 200 or 201 accesses a deployed (built, generated) application. 【0402】 Figure 33(c) shows a flowchart of the application execution process on application user terminal 200 or 201. This process is executed by the CPU 101 of application user terminal 200 or 201, and is performed when the browser software on application user terminal 200 or 201 accesses an application that has been deployed (built, generated) in the execution environment 400. Furthermore, the application execution process in the execution environment 400 shown in Figure 33(b) and the application execution process on application user terminal 200 or 201 shown in Figure 33(c) are processes that are performed in conjunction.Hereafter, the process by application user terminal 200 or 201 will be described as being performed by application user terminal 200 as a representative example (the explanation for application user terminal 201 is similar and will be omitted). 【0403】 In S3311 of Figure 33(b), the execution environment 400 determines whether or not it has received a request to acquire UI definition information sent from the application user terminal 200. The request to acquire UI definition information received here is the same one sent from the application user terminal 200 in S3333 of Figure 33(c), which will be described later. If a request to acquire UI definition information is received, the process proceeds to S3312; otherwise, it waits in S3311. 【0404】 In S3312, the execution environment 400 sends UI definition information to the application user terminal 200. As a result, as shown in Figure 34, the UI definition information 3421 recorded in the execution environment 400 is downloaded to the application user terminal 200 and recorded as UI definition information 3431. UI definition information 3421 and UI definition information 3431 are the same information. 【0405】 In S3313, the execution environment 400 determines whether or not it has received an action request from the application user terminal 200. An action request is a request to execute the content of the action entered on the action board. The action request received here is the one sent from the application user terminal 200 in S3345 of Figure 33(c), which will be described later. If an action request is received, the process proceeds to S3314; otherwise, it proceeds to S3320. 【0406】 In S3314, the execution environment 400 determines whether or not it has received a value for an input item from the application user terminal 200. The value of an input item is a value entered by the user on the application user terminal 200 for a UI component that is classified as an input item among the UI components displayed on the application screen. For example, it is the text entered in a Textfield. In this embodiment, the determination in S3314 is to determine whether or not the value of an input item was included in the action request received in S3313. If the value of an input item was received (if the value of an input item was included in the action request), the process proceeds to S3315; otherwise, it proceeds to S3316. 【0407】 In S3315, the execution environment 400 temporarily stores the value of the received input item in the memory included in the execution engine. 【0408】 In S3316, the execution environment 400 executes the requested action by running the execution environment program 3424. If a value for an input field has been received, the value of the input field is also used to execute the action. For example, the portion of the execution environment program 3424 that performs the requested action is executed with the value of the input field as an argument. 【0409】 In S3317, the execution environment 400 determines whether there is a value for an output item, which is a value that should be displayed on the application screen shown on the application user terminal 200 as a result of the execution of the action in S3316. For example, if the action was "perform arithmetic operations," the solution to the operation will be obtained as the value of the output item. Also, if the action was, for example, "transition to another screen" or "record to a database," there may be no value for an output item as a result of the action. If there is a value for the output item, the process proceeds to S3318; otherwise, it proceeds to S3319. 【0410】 In S3318, the execution environment 400 generates action result information, including the values ​​of the output items, as result information of the action performed in S3316. 【0411】 In S3319, the execution environment 400 sends the result information of the action performed in S3316 to the application user terminal 200. If action result information including the value of an output item was generated in S3318, the value of the output item is also sent to the application user terminal 200. Then, in S3348 of Figure 33(c) described later, the value of the output item is displayed on the screen of the application user terminal 200. The action result information may also include instructions for screen transitions. If instructions for screen transitions are included, a screen transition occurs on the application screen displayed on the display 105 of the application user terminal 200 through the process in S3347 of Figure 33(c) described later. 【0412】 In S3320, the execution environment 400 determines whether or not to terminate the process. If the execution environment 400 determines to terminate the process (Yes in S3320), it terminates the process. If the execution environment 400 determines not to terminate the process (No in S3320), the process returns to S3313. For example, in S3350, it determines to terminate the process if an event occurs that terminates the application, as described later. In S3331 of Figure 33(c), the application user terminal 200 (including application user terminal 201, but application user terminal 200 will be used as an example below) uses internet browser software to access the application that has been deployed (built, generated) in the execution environment 400. More specifically, it accesses (connects to) the application's URL in response to an operation that specifies the URL of the deployed application (the URL to access the execution environment) (for example, clicking a link to the application's URL or entering the application's URL in the address bar and pressing the Enter key). 【0413】 In S3332, the application user terminal 200 determines whether or not it has received the client program. When the execution environment 400 detects access from the application user terminal 200, the execution environment's distribution engine (distribution engines 415, 455, 465, 475, etc., corresponding to the accessed execution environment) sends the client program (client programs 422, 456c, 466c, 476c, etc., corresponding to the accessed execution environment) recorded in storage to the application user terminal 200. In S3332, it is determined whether or not the client program has been received. If the client program has been received, the process proceeds to S3333; otherwise, it waits in S3332 for the client program to be received. 【0414】 In S3333, the application user terminal 200 sends a request to the execution environment 400 to obtain UI definition information. The client program received in S3332 is defined to first send a request to obtain UI definition information when it accesses the execution environment. S3333 is the process that follows this. The UI definition information acquisition request sent here is received by the execution environment 400 in S3311 of Figure 33(b) mentioned above. 【0415】 In S3334, the application user terminal 200 determines whether or not it has received UI definition information from the execution environment 400. The UI definition information received here is the same information sent from the execution environment 400 in S3312 of Figure 33(b) mentioned above. If UI definition information is received, it is recorded in memory 102 and the process proceeds to S3335; otherwise, S3334 waits for the reception of UI definition information. The UI definition information is recorded in memory 102 (work memory) as temporary information and is automatically deleted when the application is terminated (when the connection to the application's URL is terminated). The application user terminal 200 also displays the application screen on the display 105 based on the UI definition information recorded in memory 102. 【0416】 In S3335, the app user terminal 200 determines whether an action trigger has occurred. Specifically, it determines whether there has been an operation on the app screen that instructs a screen transition (a trigger for an action on the destination canvas) or an operation on a UI component displayed on the app screen (a trigger for an action on a UI component, such as a click). If an action trigger has occurred, the process proceeds to S3336; otherwise, it proceeds to S3350. 【0417】 In S3336, the application user terminal 200 extracts the portion of the UI definition information (UI definition information 3431 in Figure 34) stored in memory 102 that describes the action to be executed in response to the trigger detected in S3335. This portion is text (string) information written in JavaScript (a programming language). 【0418】 In S3337, the app user terminal 200 searches for the string "$ui" (half-width characters) from the beginning of the description extracted in S3336. 【0419】 In S3338, the app user terminal 200 determines whether the string "$ui" was found in the search results of S3337. If "$ui" is found, proceed to S3339; otherwise, proceed to S3343. 【0420】 In S3339, the application user terminal 200 determines whether the string "$ui" found in S3338 is on the left side of a sentence containing that character. A "sentence" (one sentence) is a string in a programming language that is separated by a line-ending symbol (e.g., a semicolon ";") or a closing brace "}". That is, two sentences are separated by a line-ending symbol or a closing brace ('}'). If the "$ui" found in the search is located to the left of the "=" (equals sign) in a sentence, it is determined to be on the left side. If "$ui" is on the left side, the process proceeds to S3340; otherwise, it proceeds to S3341. 【0421】 In S3340, the application user terminal 200 records information based on element strings of a predetermined structure ($ui.UI component ID.Type of target information) that start with "$ui" and are found in S3338, as output items in the item definition list (item definition list 3433 in Figure 34) generated in memory 102. Specifically, it obtains the UI component ID (item code, component identifier) ​​from element strings of a structure ($ui.UI component ID.Type of target information) that start with "$ui" and are separated by periods ("."), and records that the UI component is an output item. For example, if 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", then, as shown in the item definition list 3433 in Figure 34, it will be recorded that UI component ID3 is an output item. The item definition list 3433 is information temporarily stored in the work memory, memory 102, and is automatically deleted depending on whether the result of the action is received and reflected in the output items (No in S3348 or completion of processing in S3349 described later) or the application is terminated (Yes in S3350). 【0422】 In S3341, the application user terminal 200 determines whether the string "$ui" found in S3338 is located anywhere other than the left-hand side in a sentence containing that character. Being located anywhere other than the left-hand side means it is either on the right-hand side (to the right of the "=" sign) or in a sentence that does not contain the "=" sign. If it is located anywhere other than the left-hand side, the process proceeds to S3342; otherwise, it proceeds to S3337. Note that if the result in S3339 is "No," this is equivalent to the string "$ui" being located anywhere other than the left-hand side in a sentence containing that character, so the process in S3341 may be skipped and the process proceeds to S3342. 【0423】 In S3342, the application user terminal 200 records information based on an element string of a predetermined structure ($ui.UI component ID.Type of target information) that starts with "$ui" and was found in S3338, as an input item in the item definition list (item definition list 3433 in Figure 34) generated in memory 102. Specifically, it obtains the UI component ID (item code, component identifier) ​​from the element string of a predetermined structure ($ui.UI component ID.Type of target information) that starts with "$ui", and records that the UI component is an input item. For example, if a trigger related to action A occurs, and "$ui" is found in the description part related to action A, and it is on the right, and the UI component ID is "UI component ID1", then it will be recorded that there is an input item called UI component ID1, as shown in the item definition list 3433 in Figure 34. Furthermore, for example, if a trigger related to action A occurs, and "$ui" is found in the description of action A, and it is in a sentence without "=", and the UI component ID is "UI component ID2", then the fact that there is a UI component ID2 in the input field will be recorded, as shown in item definition list 3433 in Figure 34. 【0424】 After completing the process in S3342, the process proceeds to S3337, where the string "$ui" is searched again in the continuation of the description extracted in S3336. The process from S3339 to S3342 is repeated until it is determined in S3338 that "$ui" is not present. In other words, the process from S3339 to S3342 is performed on all instances of the string "$ui" contained in the description extracted in S3336, and whether it is an input item or an output item is recorded in the item definition list 3433. 【0425】 In S3343, the app user terminal 200, upon determining in S3335 that an action has been triggered, checks whether there is a value in the information corresponding to the input item recorded in the item definition list 3433. For example, if the description extracted in S3336 contains "$ui.UI component ID1.value", it checks whether there is a value in the information of type "value" within the UI component of UI component ID1. If the UI component of UI component ID1 is a TextField, then value is the text (string) entered into that TextField. In other words, it checks whether the app user has entered text using the keyboard into UI component ID1, which is a TextField displayed on the app screen. If text has been entered, it checks Yes; if it is blank, it checks No. This check is performed for all input items recorded in the item definition list 3433. If there is a value in the information corresponding to the input item, the process proceeds to S3344; otherwise, it proceeds to S3345. 【0426】 In S3344, the app user terminal 200 generates an action request that includes the value of an input field and requests the execution of an action corresponding to the trigger detected in S3335. For example, as the value of an input field, it generates an action request that includes the text information entered by the app user using the keyboard for UI component ID1, which is a TextField displayed on the app screen shown on the display 105 of the app user terminal 200. 【0427】 In S3345, the application user terminal 200 sends an action request to the execution environment 400 requesting the execution of an action corresponding to the trigger detected in S3335. If an action with a value for an input field was generated in S3344, the value of the input field is also sent to the execution environment 400. For example, as the value of the input field, the text information entered by the application user using the keyboard for UI component ID1, which is a TextField displayed on the application screen shown on the display 105 of the application user terminal 200, is sent to the execution environment 400. The action request sent here is received by the execution environment 400 in S3313 of Figure 33(b) mentioned above, and as explained in S3314 to S3319, the action corresponding to the trigger detected in S3335 is executed in the execution environment 400. 【0428】 In S3346, the application user terminal 200 determines whether it has received the result of the action corresponding to the action request sent in S3345 from the execution environment 400. If the result of the action has been received, it proceeds to S3347; otherwise, it waits in S3346 for the result of the action to be received. 【0429】 In S3347, the app user terminal 200 updates the app screen displayed on the display 105 to reflect the result of the action received in S3346. At this time, the display is also based on the UI definition information stored in memory 102. For example, if the result of the action is an instruction to transition to another screen, the screen transition is executed. 【0430】 In S3348, the application user terminal 200 determines whether the result of the action received in S3346 contains the value of an output item. If the value of an output item is included, proceed to S3349; otherwise, proceed to S3350. 【0431】 In S3349, the application user terminal 200 displays the values ​​of the output items included in the result of the action received in S3346 on the output items displayed on the display 105, based on the output item information recorded in the item definition list 3433 held in memory 102. For example, if the type of information to be dealt with is value, the UI component of the output item will display the text or number that represents the value of the output item, or if the type of information to be dealt with is color, the color of the UI component of the output item will be changed to the color indicated by the value of the output item. 【0432】 In S3350, the app user terminal 200 determines whether or not an event occurred that would terminate the app. Events that terminate the app include, for example, disconnecting the connection to the destination indicated by the app's URL (closing the internet browser, turning off the app user terminal 200, changing the connection to another unrelated URL, etc.). If there is no event that would terminate the app, the process proceeds to S3335. If there is an event that would terminate the app, the process shown in Figure 33(c) is terminated by hiding the app screen. 【0433】 Using the example of a string in a programming language entered into the action board 910 shown in Figure 10(d), we will now explain in more detail the process of determining whether a string containing "$ui" is an input item or an output item, as explained in S3338 to S3342. 【0434】 The second line contains "const userid = $ui.text_field_a.value;". In this statement, "$ui" is on the right-hand side, so in the S3342 process, "text_field_a" is recorded as an input item in the item definition list. In other words, the value of the variable "userid" is set to the value that the user entered into "text_field_a" on the app screen. 【0435】 In the fourth line of the statement, the string "$ui.text_area_a.value", which contains "$ui", is on the left side, so in the S3340 process, "text_area_a" is recorded as an output item in the item definition list. In other words, the value indicated on the right side of "=" (the output value obtained as a result of the action) will be displayed in the UI component "text_area_a". This statement not only defines that "text_area_a" is an output item, but 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 that output item. Thus, one of the distinctive features of this embodiment is that the definitions of input and output items can be made within a statement that includes logic (processing that is different from the definition of at least one of the input and output items). Similarly, the sixth line is also a logic part, and because "$ui.text_area_a.value" is on the left side, it is treated as an output item. 【0436】 Also, below is an example of an action string that contains "$ui" in a statement without "=". 【0437】 (The numbers at the beginning of each line are auxiliary characters indicating the line number and are not part of the programming language text.) 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 string in the programming language represents an action that registers the input values ​​(`$ui.PREF_CODE.value`, $ui.PREF_NAME.value) from the app screen into the database using the SQLSave function as parameters. In this case, $ui.{part ID}.{type of information to be included}, used as a parameter for the SQLSave function, is identified as an input item (since it is not the left-hand side of the = sign). 【0438】 Furthermore, in element strings with a predetermined structure using "$ui", the type of information being targeted does not have to be value; for example, it could be color. For example, the color of a UI component can be changed by writing "$ui.UI component ID.color = "#008000";". 【0439】 In this embodiment, when describing an action entered into the action board, it is possible to specify (define) whether the UI component indicated by an element string with a specific identifier "$ui" is treated as an input item or an output item, depending on its position within the string (more specifically, its position within a single sentence). Conventionally, whether an item is an input or an output item was done in a settings screen separate from the area where the action content is entered in the programming language. Alternatively, conventionally, even when describing the action content in the area where the action content is entered in the programming language, it was necessary to declare whether it would be treated as an input item or an output item using a variable in a separate statement from the logic statement that describes the process itself. In contrast, in this embodiment, the definitions of input items and output items can be defined at any point in the string describing the action logic in the programming language. Therefore, the input items and output items used in the logic can be defined near the logic description section, and the input items and output items used in the logic can be easily set when writing the logic. Furthermore, in this embodiment, there is no need to define variables once to pass values ​​between the function setting screen and the action logic description section for input and output items. Therefore, the need for developers to perform cumbersome variable management is reduced, and variable management becomes easier. Consequently, the factors that cause errors when describing actions are reduced, and errors can be reduced. In this way, in this embodiment, it is possible to set input items and / or output items used in logic entered in a programming language more easily. 【0440】 Furthermore, since the method of indicating whether an element string is an input or output item based on its position with a specific identifier "$ui" is not common, programs executed using the standard JavaScript programming language may not properly interpret whether an element is an input or output item, resulting in the program not functioning as intended. Therefore, in this embodiment, a process is implemented to identify and sort whether a string containing "$ui," as explained in S3338 to S3342, is an input or output item, ensuring that the program functions correctly. 【0441】 In this embodiment, an example was described in which a specific identifier was represented by the half-width character "$ui", but this is not the only example. Any other string can be used as an identifier as long as it is not confused with other existing identifiers in the programming language, for example, the half-width character "_inputoutput" can be used. The half-width character "$" is the Unicode dollar sign. The half-width character "_" is the Unicode underscore. 【0442】 Furthermore, in this embodiment, as explained in S3304 of Figure 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 explained in S3338 to S3342 of Figure 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. In this way, when the built application is executed, the application developer does not need to be particularly aware of distinguishing between the information necessary for the processing to be executed in the execution environment 400 and the information necessary for the processing to be executed on the application user terminal 200 when developing the application by accessing the development environment 300 from the developer terminal 100. Therefore, by clearly managing and separating the information used by the execution environment and the terminal device when running the application being developed, the effort required for development is reduced, making software development easier. 【0443】 In this embodiment, an example was described in which the execution environment program 3414 is generated during the save process in the development environment 300. However, the development environment 300 may not generate the execution environment program 3414, and 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. 【0444】 <Examples of action execution-related processing> Figure 35(a) shows a modified flowchart of the saving process (recording control process) executed by the development environment 300, which is the destination for recording definition information. This process is executed in conjunction with the receipt of definition information transmitted from the developer terminal 100 in S422 of Figure 4 mentioned above. 【0445】 Furthermore, Figure 36 illustrates a modified example of the information transitions recorded on the developer terminal 100, development environment 300, execution environment 400, and application user terminals 200 and 201. Figure 36 schematically represents the information transitions resulting from the flowcharts in Figures 35(a) to 35(c). In Figure 36, the same reference numerals are used for the same information as in Figure 34. 【0446】 In Figure 36, instead of generating an item definition list 3433 based on UI definition information on the app user terminal 200, the development environment 300 generates client UI definition information 3615 based on the UI definition information. This client UI definition information 3615 is then deployed to the execution environment 400 (recorded in the execution environment 400 as client UI definition information 3625), and then sent from the execution environment 400 to the app user terminal 200 (recorded in the app user terminal 200 as client UI definition information 3635). When an action is executed, the app user terminal 200 processes based on the client UI definition information 3635. 【0447】 Unlike Figure 34, Figure 36 shows a configuration in which UI definition information is not sent to the app user terminal 200 (it is not even temporarily recorded on the app user terminal 200). This prevents the detailed definition of the developed app from being leaked via the app user terminal 200, thereby increasing the confidentiality of the developed app's configuration. Consequently, it reduces the possibility of a third party creating an app that imitates at least a part of the developed app (for example, the JavaScript code written in the action board). Furthermore, the app user terminal 200 does not need to perform the process of analyzing the UI definition information and generating the item definition list 3433 every time an action trigger occurs (processing S3338~S3342 in Figure 33(c)). This reduces the processing load on the app user terminal 200, enabling smooth app operation with a comfortable response speed. 【0448】 The processes S3501 to S3504 in Figure 35(a) are the same as those S3301 to S3304 in Figure 33(a) mentioned above, so their explanation is omitted. In Figure 35(a), in addition to the processes in Figure 33(a), the processes from S3505 onwards are performed. 【0449】 In S3505, the development environment 300 generates client-side UI definition information 3615. The client-side UI definition information 3615 is assumed to be a JSON file with a filename such as "uiDef2.json". The client-side UI definition information 3615 includes information obtained from the UI definition information 3411, such as application settings information including the initial UI, information on UI components for each UI screen (UI component ID, properties, placement and size of UI components, etc.), canvas action identifiers, and UI component action identifiers. The client-side UI definition information 3615 also records input / output item definitions for each action (definitions of which components are present in the input and output items). At the time of S3505, the contents of the input / output item definitions for each action are not yet inserted (they will be inserted in the processing described in S3506-3512). Furthermore, the JavaScript (programming language) strings (action source code) written on the action board are not recorded. In other words, the generated client UI definition information 3615 includes information such as action identifiers and input / output item definitions for each action, but does not include information describing the operation of the action. 【0450】 In S3506, the development environment 300 extracts the action description portion 3412 from the UI definition information 3411. This process extracts not only the description for a specific action, but also the description portion for all actions. 【0451】 In S3507, development environment 300 searches for the string "$UI" from the beginning of the action description section extracted in S3506. 【0452】 In S3508, development environment 300 determines whether the string "$ui" was found in the search results of S3337. If "$ui" is found, the process proceeds to S3509; otherwise, it terminates. S3508 will result in "No" if all searches for "$ui" have been completed, or if there is no "$ui" at all in the action description section. 【0453】 In S3509, the development environment 300, similar to S3339 in Figure 33(c), determines whether the string "$ui" found in S3508 is on the left side of a sentence containing that character. If "$ui" is on the left side, proceed to S3510; otherwise, proceed to S3511. 【0454】 In S3510, the development environment 300 records information based on an element string of a predetermined structure ($ui.UI component ID.Type of target information) that starts with "$ui" and is found in S3338 as an output item in the client UI definition information 3615 generated in S3505. More specifically, in the array defining the output items in the client UI definition information 3615, the UI component ID is obtained from the element string of a predetermined structure ($ui.UI component ID.Type of target information) that starts with "$ui" and is found in S3338, and recorded in the "uiItemsOut" array among the input / output item definitions for each action. For example, if "$ui", which indicates that the UI component ID is "RESULT", is found on the left side, it will be recorded as shown in Figure 36. 【0455】 In S3511, the development environment 300, similar to S3341 in Figure 33(c), determines whether the string "$ui" found in S3508 exists anywhere other than on the left side of a sentence containing that character. If it exists anywhere other than on the left side, proceed to S3512; otherwise, proceed to S3507. Note that if the result in S3509 is "No", this is equivalent to the string "$ui" existing anywhere other than on the left side of a sentence containing that character, so the determination in S3511 may be omitted and the process may proceed to S3512. 【0456】 In S3512, the development environment 300 records information based on an element string of a predetermined structure ($ui.UI component ID.Type of target information) that starts with "$ui" and is found in S3338 as an input item in the client UI definition information 3615 generated in S3505. More specifically, in the array defining the input items in the client UI definition information 3615, the UI component ID is obtained from the element string of a predetermined structure ($ui.UI component ID.Type of target information) that starts with "$ui" and is found in S3338, and recorded in the "uiItemsIn" array among the input / output item definitions for each action. For example, if "$ui", indicating that the UI component ID is "INPUT_1", is found on the right side, it will be recorded as shown in Figure 36. Also, for example, if "$ui", indicating that the UI component ID is "INPUT_2", is found in a statement without "=", it will be recorded as shown in Figure 36. 【0457】 After completing the processing in S3512, the process proceeds to S3507, where the string "$ui" is searched again in the continuation of the description extracted in S3506. The processing from S3507 to S3512 is repeated until it is determined in S3508 that "$ui" is not present. In other words, the processing from S3509 to S3512 is performed on all instances of the string "$ui" contained in the description extracted in S3506, and whether it is an input item or an output item is recorded in the client UI definition information 3615. 【0458】 Figure 35(b) shows a flowchart of a modified application execution process in the execution environment 400. This process is executed by the execution engine of the execution environment 400 and is performed when an application user terminal 200 or 201 accesses a deployed (built, generated) application. 【0459】 Figure 33(c) shows a flowchart of a modified example of the application execution process on application user terminal 200 or 201. This process is executed by the CPU 101 of application user terminal 200 or 201, and is performed when the browser software of application user terminal 200 or 201 accesses an application that has been deployed (built, generated) in the execution environment 400. Furthermore, the application execution process in the execution environment 400 shown in Figure 35(b) and the application execution process on application user terminal 200 or 201 shown in Figure 35(c) are processes that are performed in conjunction.Hereafter, the processing by application user terminal 200 or 201 will be described as being performed by application user terminal 200 as a representative example (the explanation for application user terminal 201 is similar and will be omitted). 【0460】 In S3521 of Figure 35(b), the execution environment 400 determines whether or not it has received a request to acquire UI definition information sent from the application user terminal 200. The request to acquire UI definition information received here is the same one sent from the application user terminal 200 in S3543 of Figure 35(c). If a request to acquire UI definition information is received, the process proceeds to S3522; otherwise, it waits in S3521. 【0461】 In S3522, the execution environment 400 sends the client UI definition information 3615 to the execution environment 400 without sending the UI definition information 3411 to the application user terminal 200. As a result, as shown in Figure 36, the client UI definition information 3625 recorded in the execution environment 400 is downloaded to the application user terminal 200 and recorded as client UI definition information 3635. The client UI definition information 3615 and the client UI definition information 3635 are the same information. 【0462】 The processes in S3523 to S3530 are the same as those in S3313 to S3320 in Figure 33(b) mentioned above, so their explanation will be omitted. 【0463】 The steps S3541 to S3543 in Figure 35(c) are the same as the steps S3331 to S3333 in Figure 33(c) described above, so their explanation is omitted. However, in S3543, a request to obtain client UI definition information is sent. 【0464】 S3544 determines whether the application user terminal 200 has received client UI definition information from the execution environment 400. The client UI definition information received here is the same information sent from the execution environment 400 in S3522 of Figure 35(b) mentioned above. If the client UI definition information is received, it is recorded in memory 102 and the process proceeds to S3545; otherwise, S3544 waits for the client UI definition information to be received. The client UI definition information is recorded in memory 102 (work memory) as temporary information and is automatically deleted when the application is terminated (when the connection to the application's URL is terminated). The application user terminal 200 also displays the application screen on the display 105 based on the client UI definition information 3635 recorded in memory 102. 【0465】 In S3545, the application user terminal 200 determines whether an action trigger has occurred, similar to S3335 in Figure 33(c) mentioned above. If an action trigger has occurred, the process proceeds to S3546; otherwise, it proceeds to S3553. 【0466】 The processes in S3546 to S3553 are the same as those in S3343 to S3350 in Figure 33(c) mentioned above, so their explanation is omitted. The processes corresponding to S3336 to S3342 in Figure 33(c) mentioned above are not performed on the application user terminal 200 in this modified example. 【0467】 This concludes the explanation of Figures 35 and 36. <System configuration of the second embodiment> Figures 1 to 36 illustrate a first embodiment of the present invention, describing a system for software development and a system for using the developed software. 【0468】 Figures 37 to 43 show a second embodiment of the present invention, illustrating differences from the first embodiment or additions to the first embodiment. 【0469】 Figure 37 shows the system configuration diagram of the information processing system of the second embodiment. The same parts as in Figure 1 will be omitted from the explanation; only the parts that differ from Figure 1 will be explained. 【0470】 In the second embodiment, the storage 320 of the development environment 300 includes a repository area 330, separate from the developer areas 323 to 325, which are storage areas for each developer account. 【0471】 Developer areas 323-325 are dedicated storage areas for each developer, while repository area 330 contains multiple repositories, and developers belonging to a repository team can share application definitions within this storage area. 【0472】 Team members of the repository can copy (hereinafter referred to as commits) application definitions stored in their own developer areas 323-325 to the repository and share them with other team members. 【0473】 Team members of a repository can copy the application definitions stored in that repository to their own developer areas 323-325 (hereinafter referred to as "checkout") and use them to build applications. 【0474】 As a result, the application development system will be able to share definition information for building applications. Next, we will explain Figure 38. Figure 38 is an example of a flowchart for the repository creation process. 【0475】 This repository creation process involves creating a repository in repository area 330 for sharing application definitions, so that the team can configure the application definition using the information processing system used to build the application. 【0476】 In S3801, the developer terminal 100 receives an instruction from the developer user to select the "Create New Repository" button. 【0477】 Specifically, it accepts clicks on the "Create New Repository" button 3901 or the "Create New Repository" button 3902 (Figure 39(a)) on the repository list screen. 【0478】 In S3802, the developer terminal 100 displays the new repository creation dialog (Figure 39(b)). 【0479】 In S3803, the developer terminal 100 accepts the input of repository information in the new repository creation dialog. 【0480】 Specifically, the system accepts input or selection of the repository name 3903, the application to be registered in the repository 3904, and the comment 3905 in the new repository creation dialog (Figure 39(b)). 【0481】 In S3804, when the developer terminal 100 receives a click of the create button 3906 in the new repository creation dialog from the developer user, it sends the repository information received in S3803 to the development environment 300. 【0482】 In S3805, the development environment 300 receives repository information sent from the developer terminal 100. Specifically, it receives the repository name 3903, the application to be registered in the repository 3904, and the comment 3905. 【0483】 In S3806, the development environment 300 obtains application definition information from the application definition 323a (Figure 37) in the storage 320. 【0484】 Specifically, the developer user who instructed the creation of the repository will, for example, if developer A retrieves the application definition information from application definition 323a stored in developer A area 323 (Figure 37), if developer B retrieves the application definition information from application definition 324a (not shown in Figure 37) stored in developer B area 324 (Figure 37), and if developer C retrieves the application definition information from application definition 325a (not shown in Figure 37) stored in developer C area 325 (Figure 37). 【0485】 In S3807, the development environment 300 creates a repository in the repository area 330 (Figure 37). Specifically, it creates the repository using the repository information received in S3805 (repository name 3903, application to be registered in the repository 3904, and comment 3905). At this point, the only member who can access this repository is the developer user who created the repository. 【0486】 In other words, the developer X area 32X is an example of a memory unit that stores definition information set by the first user. 【0487】 In other words, the developer X area 32X is an example of a memory unit that stores definition information set by the first user. 【0488】 In other words, the repository area 330 is an example of a storage unit that stores definition information in a way that allows it to be shared with a second user. 【0489】 In other words, the repository area 330 is an example of a storage unit used to share definition information with a second user. 【0490】 In other words, this step is an example of a process that controls the creation of the repository area 330 in response to an operation by the first user. 【0491】 In S3808, development environment 300 stores the application definition obtained in S3806 in the created repository. 【0492】 As a result, at this point, the same application definition will exist in two locations: one in the developer area 323-325 of the developer who created the repository, and the repository itself. 【0493】 In S3809, the developer terminal 100 receives the repository creation result. 【0494】 In S3810, developer terminal 100 proceeds to S3812 if the repository creation is successful, and to S3811 if it fails. 【0495】 In S3811, the developer terminal 100 displays a message (not shown) indicating that repository creation failed. 【0496】 In S3812, the developer terminal 100 displays a message (not shown) indicating that the repository creation was successful. 【0497】 In S3813, the developer terminal 100 sends a request to the development environment 300 to retrieve repository list information. 【0498】 In S3814, development environment 300 receives a request to retrieve repository list information. 【0499】 In S3815, the development environment 300 retrieves a list of repositories to which this developer user belongs and sends the repository list information to the developer terminal 100. 【0500】 In S3816, the developer terminal 100 receives repository list information. 【0501】 In S3817, the developer terminal 100 displays the list of received repositories (Figure 39(c)). Here, it can be seen that a repository has been created based on the repository information received in S3803. 【0502】 In S3818, developer terminal 100 accepts an operation to add a team member who can access the repository. 【0503】 In other words, this step is an example of a process that accepts settings related to the second user from the first user. 【0504】 Specifically, when the developer terminal 100 receives a click from the developer user on the permission button 3911 (Figure 39(d)) in the repository's pull-down menu, it displays a screen 3912 (Figure 39(d)) for adding team members and accepts input of team member information (e.g., username, email address, etc.). Multiple team members can be added using the add button 3913. 【0505】 In S3819, the developer terminal 100 sends information about team members who can access the repository to the development environment 300. Specifically, it sends information about each team member (e.g., username, email address, etc.) to the development environment 300 for each team member being added. 【0506】 In S3820, development environment 300 receives information about team members who can access the repository. 【0507】 In S3821, development environment 300 uses the received team member information to register them as a member who can access the repository. 【0508】 This concludes the explanation of Figure 38. Next, we will explain Figure 40. Figure 40 is an example of a flowchart for the commit process. 【0509】 This commit process involves registering application definition information set by the developer user into the repository, allowing other team members to retrieve and edit it, enabling collaborative development. 【0510】 In S4001, the developer terminal 100 receives commit instructions from the developer user. 【0511】 Specifically, there are two ways to commit: committing the entire application definition, and committing individual application definition files. 【0512】 In this embodiment, there are two methods for committing, but the method is not limited to these. Other commit methods may also be used, such as committing application definitions for multiple applications together, or committing items within an application definition file individually. 【0513】 If the commit button 4101 (Figure 41(a)) in the application definition's pull-down menu is clicked, the entire application definition will be committed. 【0514】 When the commit button 4105 (Figure 41(b)) is pressed, the application definition file displayed on the screen in Figure 41(b) is committed. 【0515】 In this embodiment, commits can be made on an application definition file basis, but this is not limited to individual files. Other units may also be used, such as folders containing multiple files, rows or items within a file, tables, records, columns, or views stored in a database. 【0516】 In this embodiment, the method for issuing a commit instruction is as described above, but it is not limited to this method. Other methods of issuing commit instructions may be used, such as a commit instruction that combines the application definitions of multiple applications, or a commit instruction that applies to each item of the application definition. 【0517】 In S4002, the developer terminal 100 proceeds to S4003 if the commit instruction from the developer user is for the entire application definition, and to S4005 if it is for individual application definition files. 【0518】 In S4003, the developer terminal 100 obtains the app ID of the app definition for which a commit instruction has been received. 【0519】 In S4004, the developer terminal 100 accepts the developer user's selection of the commit destination repository name 4102 (Figure 41(a)). 【0520】 This commit destination repository 4102 will display the names of repositories to which the developer user is a member, making them selectable. 【0521】 In S4005, the developer terminal 100 displays a dialog box for the definition file to be committed (Figure 41(c)). 【0522】 In S4006, the developer terminal 100 accepts the selection of definition files to commit from the developer user. 【0523】 Specifically, the commit dialog for the application definition file (Figure 41(c)) accepts the selection and input of the commit destination repository name 4106, the definition file information to be committed 4107, and the comment 4108. 【0524】 Here, let me explain the circle mark in the lower right corner of the icon for definition file information 4107 to be committed. 【0525】 This circle is an identifier displayed when there is a difference between the app definition stored in the repository and the app definition stored in the developer user's developer area. 【0526】 Developer users can easily find app definitions they have updated by looking at this identification display. They can also easily find app definitions that have been updated by other team members, even if they haven't updated them themselves, which can cause discrepancies. 【0527】 In this embodiment, a circle was used as the identification mark, but this is not the only identification method. Other identification methods may be used, such as a star, changing the color of the icon, or making the file name bold. 【0528】 In this embodiment, the differences are identified and displayed in the commit dialog for the application definition file (Figure 41(c)). However, this method of identification is not limited to this method. For UI definitions, the UI screen layout editor can be displayed, and the differences in the definition (for example, differences in the presence or absence of buttons, differences in display position, differences in wording, etc.) can be identified and displayed on the layout editor. For action definitions, the action board 910 can be displayed to show the differences in the code, or each screen such as Figure 9 can be displayed to identify and display the parts where the settings are different. 【0529】 In other words, this step is an example of a process that identifies and displays the difference between the definition information stored in the first memory unit and the definition information stored in the second memory unit. 【0530】 In S4007, the developer terminal 100 sends commit-related information to the development environment 300. 【0531】 Specifically, in the case of committing the entire application definition, when the commit button 4104 on the application definition commit screen (Figure 41(a)) is pressed, the application ID of the application to be committed and the repository ID of the target repository are sent. 【0532】 On the other hand, in the case of committing an application definition file, when the commit button 4110 in the application definition file commit dialog (Figure 41(c)) is pressed, S4006 sends the repository ID of the target repository, the definition file information to be committed 4107, and the comment 4108. 【0533】 In S4008, development environment 300 receives information related to commits. 【0534】 In S4009, the development environment 300 retrieves the application ID of the application to be committed or the application definition file information 4107 to be committed, which are included in the information related to the received commit, from the developer user's developer area. 【0535】 Specifically, if the developer user who issued the commit instruction is Developer A, the app definition file to be committed, stored in app definition 323a in Developer A's area 323 (Figure 37), is retrieved. 【0536】 In S4010, development environment 300 repeats the process in S4011 for each application definition file obtained. 【0537】 In S4011, the development environment 300 stores the application definition file obtained in S4009 in the repository corresponding to the repository ID received in S4008, located within the repository area 330. 【0538】 At this time, to manage the versions of committed application definition files, the application definition files are stored along with their version IDs (or snapshot date and time), and the application definition files at a specific point in time can be retrieved by specifying a past version ID (snapshot date and time). 【0539】 In other words, this step is an example of a process that controls the copying of definition information to the second storage unit in response to the operation of the first user. 【0540】 In other words, this step is an example of a process that controls the storage of data in the second storage unit in response to the operation of the first user. 【0541】 In other words, this step is an example of a process that controls the copying of definition information related to an operation performed by the first user to the second storage unit. 【0542】 In other words, this step is an example of a process that controls the storage of definition information related to an operation performed by the first user in the second storage unit. 【0543】 In other words, this step is an example of a process that stores definition information in association with identification information or a date and time to identify the version. 【0544】 In S4012, development environment 300 sends the results of the commit process to development environment 100. 【0545】 In S4013, developer environment 100 receives the results of the commit process. 【0546】 In S4014, developer environment 100 displays the results of the commit process. 【0547】 As a result, the application building system can now register definition information for building applications in a storage area (repository) that is shared with team members. 【0548】 This concludes the explanation of Figure 40. Next, we will explain Figure 42. Figure 42 is an example of a flowchart for the checkout process. 【0549】 This checkout process allows a developer to retrieve application definition information committed to the repository into their own developer area. 【0550】 In S4201, the developer terminal 100 accepts the selection of items to be checked out from the developer user. 【0551】 Specifically, there are two ways to check out: checking out the entire application definition, and checking out individu...

Claims

[Claim 1] Application definition information, the first storage unit is a storage unit that allows the second user to share the definition information set by the first user, Control means for controlling the copying of definition information stored in the first storage unit to a second storage unit that stores definition information set by the second user, in response to the operation of the second user. An information processing system characterized by comprising the following features. [Claim 2] A first storage unit is a storage unit used to share application definition information set by a first user with a second user, Control means for controlling the copying of definition information stored in the first storage unit to a second storage unit that stores definition information set by the second user, in response to the operation of the second user. An information processing system characterized by comprising the following features. [Claim 3] A first storage unit is a storage unit that contains application definition information, and the definition information set by the first user can be shared with the second user. Control means for controlling the storage of definition information stored in the first storage unit in response to the operation of the second user, to be stored in the second storage unit which stores definition information set by the second user. An information processing system characterized by comprising the following features. [Claim 4] A first storage unit is a storage unit used to share application definition information set by a first user with a second user, Control means for controlling the storage of definition information stored in the first storage unit in response to the operation of the second user, to be stored in the second storage unit which stores definition information set by the second user. An information processing system characterized by comprising the following features. [Claim 5] A first storage unit is a storage unit that contains application definition information, and the definition information set by the first user can be shared with the second user. Control means for controlling the copying of definition information related to an operation performed by the second user on the definition information stored in the first storage unit to the second storage unit which stores definition information set by the second user. An information processing system characterized by comprising the following features. [Claim 6] A first storage unit is a storage unit used to share application definition information set by a first user with a second user, Control means for controlling the copying of definition information related to an operation performed by the second user on the definition information stored in the first storage unit to the second storage unit which stores definition information set by the second user. An information processing system characterized by comprising the following features. [Claim 7] A first storage unit is a storage unit that contains application definition information, and the definition information set by the first user can be shared with the second user. Control means for controlling the storage of definition information related to an operation performed by the second user on the definition information stored in the first storage unit, in response to the operation performed by the second user on the definition information stored in the first storage unit. An information processing system characterized by comprising the following features. [Claim 8] A first storage unit is a storage unit used to share application definition information set by a first user with a second user, Control means for controlling the storage of definition information related to an operation performed by the second user on the definition information stored in the first storage unit, in response to the operation performed by the second user on the definition information stored in the first storage unit. An information processing system characterized by comprising the following features. [Claim 9] Difference identification display means for identifying and displaying the difference between the definition information stored in the first storage unit and the definition information stored in the second storage unit. The information processing system according to any one of claims 1 to 8, further comprising the above. [Claim 10] Control means for updating definition information stored in the second storage unit in response to operations by the second user. The information processing system according to any one of claims 1 to 8, further comprising the above. [Claim 11] The control means is Controlling the copying or storage of definition information stored in the second storage unit in the first storage unit in response to an operation by the second user. An information processing system according to any one of claims 1 to 8, characterized by the above. [Claim 12] Construction means for constructing the application based on the defined information. The information processing system according to any one of claims 1 to 8, further comprising the above. [Claim 13] The aforementioned definition information is: Definition information relating to the screen of the aforementioned application, Definition information relating to the user interface of the aforementioned application, Definition information relating to the user who uses the aforementioned application, Definition information relating to an information processing device that uses the aforementioned application, Definition information relating to the information processing device that executes the aforementioned application, Definition information relating to the session used by the aforementioned application, Definition information relating to the library that uses the aforementioned application, Definition information relating to the wording used in the aforementioned application, Definition information related to the processing to be executed by the aforementioned application, Definition information relating to arguments used in the aforementioned application, Definition information relating to the return value used in the aforementioned application, Definition information relating to the methods used in the aforementioned application, Definition information relating to the program used in the aforementioned application, Definition information relating to the script used in the aforementioned application, Definition information relating to files used by the aforementioned application, Definition information relating to the business logic used in the aforementioned application, Definition information relating to the workflow that includes the aforementioned application, Definition information relating to the Web service provided by the aforementioned application, Definition information relating to the Web services used by the aforementioned application, Definition information relating to functions used in the aforementioned application, Definition information relating to constants used in the aforementioned application, Definition information relating to variables used in the aforementioned application, Definition information relating to the settings of the aforementioned application, Definition information related to communication used in the aforementioned application, Definition information relating to the database used in the aforementioned application, Definition information relating to queries used in the aforementioned application and Definition information relating to data used in the aforementioned application must include at least one of the following An information processing system according to any one of claims 1 to 8, characterized by the above. [Claim 14] A control step that controls the copying of definition information, which is defined by an application and is stored in a first storage unit that is a storage unit shared by a second user, to a second storage unit that stores definition information set by the second user, in response to an operation by the second user. A control method for an information processing system, characterized by having the following features. [Claim 15] At least one computer, A program for causing each of the means of the information processing system described in any one of claims 1 to 8.

Images