JP7787967B2 - App development support system, app development support method, and app development support program - Google Patents

Description

The present invention relates to an application development support system, an application development support method, and an application development support program.

Patent Document 1, for example, is an example of a conventional application development support system. This system includes a program development unit that generates an application program based on input from a terminal connected to a development environment and visually displays the generated application program, and a communication unit that provides communication functions between multiple users of the development environment, whereby part or all of the application program generated by the program development unit of a development environment used by a first user is copied and visually displayed so that it can be used in a development environment used by a second user.

JP 2018-55588 A

However, Patent Document 1 does not provide any information on how developers can appropriately determine and manage the type of permission control that will be applied to actual applications.

The present invention has been made in light of the above, and aims to provide an application development support system, application development support method, and application development support program that enable developers to appropriately determine and manage the type of permission control to be applied to actual applications.

To solve the above-mentioned problems and achieve the objectives, the present invention provides an application development support system equipped with a control unit, characterized in that the control unit comprises: a screen display control means for displaying a security settings screen that displays a matrix of master page logic and its permissions; and a setting means for setting the security of each piece of master page logic in response to operations by a developer on the security settings screen.

Furthermore, according to one aspect of the present invention, the security set on the master page may be inherited by child screens subordinate to the master page.

Furthermore, according to one aspect of the present invention, the screen display control means may be configured to be able to query, in a list, the master page security that has been set for the master page and child screens subordinate to the master page.

Furthermore, according to one aspect of the present invention, when there is logic information assigned to a subflow for calling another logic from a processing flow included in the logic, the setting means may be configured to be able to set the logic information assigned to the subflow in a list in response to a developer's operation on the security setting screen, and the display control means may be configured to be able to recursively query the logic assigned to the subflow in a tree format under the calling logic including the subflow.

Furthermore, according to one aspect of the present invention, the screen display control means may be configured to, in conjunction with security set for logic assigned to the subflow in response to a developer's operation on the security setting screen, query the corresponding logic displayed in a tree structure under the calling logic including the subflow for the same security content.

Furthermore, according to one aspect of the present invention, the logic may include at least one of new registration logic, modification logic, deletion logic, inquiry logic, and startup logic.

Furthermore, according to one aspect of the present invention, the application development support system may be a system capable of developing applications by defining GUI operations.

Furthermore, in order to solve the above-mentioned problems and achieve the objectives, the present invention provides an application development support method for execution by an information processing device equipped with a control unit, characterized by including a screen display control step executed by the control unit to display a security settings screen that displays a matrix of logic for a master page and a list of its permissions, and a setting step to set the security of each piece of logic on the master page in accordance with operations performed by the developer on the security settings screen.

In order to solve the above-mentioned problems and achieve the object, the present invention provides an application development support program to be executed by an information processing device having a control unit, wherein the control unit:
The application development support program is characterized by executing a screen display control step for displaying a security setting screen that displays a matrix of logic for a master page and a list of its permissions, and a setting step for setting the security of each logic of the master page in accordance with operations performed by a developer on the security setting screen.

The present invention has the effect of enabling developers to appropriately determine and manage the type of permission control that will be applied to actual applications.

FIG. 1 is a diagram showing an outline of the overall configuration of a system according to an embodiment. FIG. 2 is a block diagram showing an example of the configuration of an application development support system. FIG. 3 is a block diagram showing an example of the configuration of a business support system. FIG. 4 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 5 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 6 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 7 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 8 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 9 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 10 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 11 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 12 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 13 is a diagram for explaining a specific example of processing by the control unit of the application development support system. FIG. 14 is a diagram for explaining a specific example of processing by the control unit of the business support system. FIG. 15 is a diagram for explaining a specific example of processing by the control unit of the business support system. FIG. 16 is a diagram for explaining a specific example of processing by the control unit of the business support system. FIG. 17 is a diagram for explaining a specific example of processing by the control unit of the business support system. FIG. 18 is a diagram for explaining a specific example of processing by the control unit of the business support system. FIG. 19 is a diagram for explaining a specific example of processing by the control unit of the business support system. FIG. 20 is a diagram for explaining a specific example of processing by the control unit of the application development support system.

Below, embodiments of the application development support system, application development support method, and application development support program according to the present invention will be described in detail with reference to the accompanying drawings. Note that the present invention is not limited to these embodiments.

[1. Overview]
The application development support system of the present invention is a system that allows applications to be developed without coding the program source, regardless of whether it is a no-code system, low-code system, or other system, by defining at least the application's screen layout, events, processing flow, and security settings through GUI operations alone.

Here, "no-code" refers to no-code, coding-less, non-coding, etc., and refers to a system that allows application developers to create simple, standard applications by arranging and combining existing functions and components using GUI operations, etc., without creating or modifying any program source code. "Low-code" refers to low-code, etc., and refers to a system that is basically the same as no-code, but because applications lack flexibility, allows for flexible customization by partially coding the program or using external APIs as needed. Furthermore, the general group of functions that support application development is referred to as a "platform, infrastructure, or development tool," and the term "infrastructure" is used here.

In the following explanation, a low-code platform will be used as an example of an app development support system, but the present invention is not limited to this and can be applied to all systems that allow applications to be developed using GUI operation definitions.

For example, the security requirements that companies require of information systems such as ERP systems have become increasingly important in recent years. For example, control requirements in audits include checking whether user privileges are being properly managed within the information system. Furthermore, when it comes to managing My Number, it is also a legal requirement to properly manage users with viewing/editing privileges. In order for companies to properly manage information and carry out their business, information systems such as ERP systems require a mechanism to check the security of each user and ensure that only appropriate users can access and edit information.

The Ministry of Economy, Trade and Industry's DX report points out the problem that aging systems that have been in operation for decades or more will lead to a decline in Japan's international competitiveness and economic stagnation (the "2025 Cliff" problem). One of the reasons for this aging is that, because information systems are closely linked to a company's business operations, the cost of updating a system once it has been completed is too high.

One solution to these problems has been the use of low-code platforms (tools) to reduce system development costs, a method that has gained attention in recent years. The applicant has many years of experience building system platforms that meet the security requirements of companies, and has devised a system that leverages this strength and the characteristics of low-code platforms to simplify security settings.

With a low-code platform, users drag and drop controls such as buttons (hereafter referred to as UI) and assign separately prepared click events (hereafter referred to as logic) to the UI. This inevitably means that the UI and logic must each be configured independently. In traditional system development using programming, the UI and logic are integrated, and it is not very common to separate them.

As an example of a system, let's consider a case where clicking the delete button (UI) executes the deletion process (logic). To ensure security, users without deletion authority must be prevented from executing the deletion process.

As mentioned above, in conventional systems, the UI and logic were not independent, so security settings also had to depend on the delete button (UI). If security settings depended on the UI, security settings would need to be configured for each UI on each screen in the system, and as the system became larger, security settings and the associated testing would incur significant costs. Specifically, in the case of the delete button, security settings would need to be configured for each delete button (for each screen) in department master maintenance and business unit master maintenance.

In addition, because security must always be taken into consideration when making system changes, only highly skilled personnel are able to make system changes. As a result, there is the problem that it becomes difficult to continuously improve the system after it has been built (the system is prone to becoming rigid). This increased complexity in system settings is also cited as one of the causes of the aforementioned "2025 Cliff" problem.

In this invention, the separation of UI and logic achieved through the low-code platform makes it possible to apply security to the logic. This means that, in the case of the relationship between the delete button and the deletion process mentioned earlier, security can now be applied only to the deletion process.

By combining this separation of UI and logic with a mechanism for inheriting logic from a master page, it is now possible to build systems using a low-code platform without worrying too much about security. For the purposes of explanation, this specification refers to systems (applications) created using a low-code platform as the "execution environment."

More specifically, this invention achieves the following: In conventional systems, it was common to develop individual jobs through programming. Therefore, to check whether security settings were configured correctly across the entire system, it was necessary to check each and every job for any omissions or mistakes in the settings.

As such, with traditional development methods, there was no mechanism for easily checking security settings, and in order to ensure that security settings were correctly configured across the entire system, it was common to conduct large-scale testing after the program was completed. As a result, once a system was completed, it was difficult to make flexible changes to the system, which led to the issue of the system becoming obsolete.

Unlike the regular jobs used by users, the low-code development platform has master pages that aggregate processes that are commonly used across multiple jobs. In addition to setting the processes to be executed, the master page also allows you to set security for the user permissions required for execution.

In this invention, to visualize this security information, the vertical axis represents the process and the horizontal axis represents the user permissions, allowing developers to check the overall security settings for the process in a list format, enabling them to appropriately determine and manage the type of permission control that will be applied to the actual application.

2. Configuration
[2-1. Overall system configuration]
Fig. 1 is a diagram showing an outline of the overall system configuration of an embodiment. In Fig. 1, an application development support system (e.g., a web server) 100, a business support system (e.g., a web server) 200, a development user terminal 300, and a business user terminal 400 are connected to a network 500 and configured to be able to communicate data with each other.

The application development support system 100 provides, for example, a low-code infrastructure platform (tool) to the developer user terminal 300, and provides a configuration screen (e.g., a web page) for generating business application definition data (including logic information and security information). The definition data is the source data for business applications and is also referred to as "objects," "packages," or "sources." In the following description, the application development support system 100 may be referred to as the "low-code infrastructure."

The development user terminals 300... are used by development users (also called "developers") who are responsible for creating business applications to access the application development support system 100 and create definition data for the business applications. The development user terminals 300... are operated, for example, using a browser on a settings screen provided by the application development support system 100.

The business support system 200 acquires business application definition data from the database of the application development support system 100, converts the acquired definition data, and generates a business application 206a. The business support system 200 executes the generated business application 206a and provides a business execution screen (e.g., a web page) to the business user terminal 400... In the following description, the business support system 200, which executes a business application based on the definition data created by the application development support system 100, may be simply referred to as the "execution environment."

The business user terminals 400... are used by business users (also referred to as "users") who are responsible for business operations to access the business support system 200 and perform business operations. The business user terminals 400... use, for example, a browser to perform operations on a business execution screen provided by the business support system 200.

[2-2. Configuration of application development support system]
The configuration of the application development support system (low-code platform) 100 in Fig. 1 will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the configuration of the application development support system 100 in Fig. 1.

The application development support system 100 is a workstation or a commercially available desktop or notebook personal computer, etc.

As shown in FIG. 2, the application development support system 100 includes a control unit 102, a communication interface unit 104, a memory unit 106, and an input/output interface unit 108. Each unit included in the application development support system 100 is connected to each other so that they can communicate with each other via any communication path.

The communication interface unit 104 communicatively connects the application development support system 100 to the network 500 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has the function of communicating data with other devices via the communication line. Here, the network 500 has the function of communicatively connecting the application development support system 100 with the development user terminal 300, the business support system 200, the server 600, etc., for example, the Internet or a LAN (Local Area Network).

An input device 112 and an output device 114 are connected to the input/output interface unit 108. The output device 114 may be a monitor (including a home television), a speaker, or a printer. The input device 112 may be a keyboard, a mouse, a microphone, or a monitor that functions as a pointing device in conjunction with a mouse. Note that, below, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112. Furthermore, operations performed by a user using the input device 112 on the screen of the output device (monitor) 114 may be simply referred to as "user operations."

The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 stores computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes. The storage unit 206 can be, for example, a memory device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, or an optical disk.

The storage unit 106 includes a database 106a and a security configurable master 106b.

Database 106a is used to store data such as business application definition data (logic information, security information, etc.). Database 106a may be provided externally, for example, on server 600.

The security configurable master 106b can be configured as a table that associates and registers controls, actions, and configurable flags that indicate whether security can be configured (see Figure 20). The security configurable master 106b is referenced when security is configured for a control action on the settings screen.

The control unit 102 is a CPU or the like that provides overall control of the application development support system 100. The control unit 102 has internal memory for storing control programs such as an OS, programs that define various processing procedures, and required data, and executes various information processes based on these stored programs. Functionally, the control unit 102 includes a screen control unit 102a, a setting unit 102b, a registration unit 102c, a detection unit 102d, and a master maintenance unit 102e.

In response to access from the developer user terminal 300, the screen control unit 102a provides the developer user terminal 300 with various setting screens for setting logic information and security information for each logic. In response to access from the developer user terminal 300, the screen control unit 102a may also provide the developer user terminal 300 with a security setting screen that displays a matrix of master page logic (processing) and permissions. The screen control unit 102a may also query (display) a list of master page security settings for master pages and child screens subordinate to the master page. The screen control unit 102a may recursively query (display) logic assigned to a subflow in a tree format under the calling logic that includes the subflow. In conjunction with security settings set for logic assigned to a subflow in response to developer operations on the security setting screen, the screen control unit 102a may query (display) the same security settings for the corresponding logic displayed in a tree format under the calling logic that includes the subflow. In response to access from a developer user terminal 300, the screen control unit 102a may provide the developer user terminal 300 with a settings screen for setting the security of control actions.

The setting unit 102b sets logic information and security information for each logic for a master page (parent screen) and child screens subordinate to the master page in response to operations on the setting screen by the developer of the developer user terminal 300, and at that time, the child screens inherit the logic information and security information set on the master page. Child screens may be configured so that security set on the master page cannot be changed. The setting unit 102b may set security information for logic information assigned to a subflow that calls other logic information from a processing flow included in the logic information, and may cause the security information set for the logic information assigned to the subflow to be inherited by the calling logic information, including the subflow. The setting unit 102b may set security information for each logic on the master page in response to operations on the security setting screen by the developer of the developer user terminal 300. If there is logic information assigned to a subflow that calls other logic from a processing flow included in the logic, the setting unit 102b may set a list of the logic information assigned to the subflow in response to operations on the security screen by the developer of the developer user terminal 300.

The security type setting for the business support system 200 (execution environment) targets the combination of user and job, and as a result, the security of the logic contained in the job (screen) is reflected as the operation permissions for each user (see Figures 14 and 15).

The registration unit 102c converts the logic information and security information of the set master page and child screens subordinate to the parent screen into a specified data format and registers it in the database 106a as business application definition data.

When a developer sets security for an action of a control on the setting screen, the detection unit 102d refers to the security configurable master 106b to detect whether or not the action of the control can be set.
By referring to the security configurable master 106b, if the action flag of the control can be set, the setting is permitted, and if the action flag of the control cannot be set, an error may be notified.

The master maintenance unit 102e registers, adds, edits, and configures data in the security configurable master 106b.

[2-3. Example of business support system configuration]
The configuration of the business support system (execution environment) 200 in Fig. 1 will be described with reference to Fig. 3. Fig. 3 is a block diagram showing an example of the configuration of the business support system 200 in Fig. 1.

The business support system 200 may be a workstation or a commercially available desktop or notebook personal computer.

As shown in FIG. 3, the business support system 200 includes a control unit 103, a communication interface unit 204, a memory unit 206, and an input/output interface unit 208. Each unit included in the business support system 200 is connected to each other so that they can communicate with each other via any communication path.

The communication interface unit 204 communicatively connects the business support system 200 to the network 500 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 204 has the function of communicating data with other devices via the communication line. Here, the network 500 has the function of communicatively connecting the business support system 200 with the business user terminal 400, the application development support system 100, the server 700, etc., for example, the Internet or a LAN (Local Area Network).

An input device 212 and an output device 214 are connected to the input/output interface unit 208. The output device 214 may be a monitor (including a home television), a speaker, or a printer. The input device 212 may be a keyboard, a mouse, a microphone, or a monitor that functions as a pointing device in conjunction with a mouse. Note that, below, the output device 214 may be referred to as the monitor 214, and the input device 212 may be referred to as the keyboard 212 or the mouse 212. Furthermore, operations performed by a user using the input device 212 on the screen of the output device (monitor) 214 may be referred to simply as "user operations."

The storage unit 206 stores various databases, tables, files, and the like. The storage unit 206 stores computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes. The storage unit 206 can be, for example, a memory device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, or an optical disk.

The memory unit 206 stores a business application 206a. As described above, the business application 206a is a data conversion result of the definition data of a business application created by the application development support system 100.

The control unit 202 is a CPU or the like that provides overall control of the application development support system 100. The control unit 202 has internal memory for storing control programs such as an OS, programs that define various processing procedures, and required data, and executes various information processes based on these stored programs. Functionally, the control unit 202 is equipped with an execution unit 202a.

The execution unit 202a executes the business application 206a in response to access from the business user terminal 400.... Specifically, the execution unit 201a provides a business execution screen in response to access from the business user terminal 400..., and performs processing in response to user operations on the business user terminal 400 on the business execution screen. Users can execute specified tasks by accessing the business support system 200.

3. Specific examples of processing
1 to 20, a specific example of the processing by the control unit 102 of the application development support system 100 and the control unit 201 of the business support system 200 in this embodiment will be described. Figures 4 to 20 are diagrams for explaining a specific example of the processing by the control unit 102 of the application development support system 100 and the control unit 201 of the business support system 200 in this embodiment.

(Example 1: The relationship between master pages and child screens in a low-code platform and how to add processing)
The relationship between master pages and child screens in a low-code platform and the add-on method for processing will be described with reference to Figure 4. The setting unit 102b of the application development support system 100 sets logic information and security information for each logic of the master page (parent screen) and child screens subordinate to the master page in response to operations on the setting screen by the developer using the development user terminal 300, and then inherits the logic information and security information set in the master page to the child screen. In the child screen, only a portion of the logic flow (within the placeholder) of the logic inherited from the master page can be changed.

A screen that acts as a template for each screen in a system is called a master page. By using a master page that suits the characteristics of each screen, such as for registration processing or report output processing, the development costs for each screen can be reduced. The master page corresponds to the template function of each child screen. The master page (parent screen) and each screen (child screen) have a parent-child relationship, so to speak. One or more areas called "placeholders" are placed on the master page (parent), and controls can only be placed in those areas on the child screen.

In Example 1, security settings are made using the relationship between the master page and the screen that inherits it (hereafter referred to as the child screen).

Figure 4 is a diagram explaining the relationship between master pages and child screens, and how to add processing. Figure 4(A) shows the flow setting screen, and Figure 4(B) shows the execution environment set on the flow setting screen. The following explanation uses the registration screen master page (a master page referenced from all registration screens) as an example.

The registration screen master page is pre-configured with common processes required for registration screens (such as department master maintenance), such as new registration, modification, deletion, and inquiry. For simplicity, Figure 4 shows only the deletion process.

Due to the characteristics of the low-code platform, the delete button (UI) and the deletion process (logic) are separate. On the screen where you configure the master page deletion process on the low-code platform, you can connect each process (hereafter referred to as "actions"), such as message display, to configure it as a flowchart (logic flow) that summarizes a series of business processes.

Among these, actions labeled "placeholder" are special actions used to set specific processing on child screens that inherit the master page. Child screens that inherit the master page call and use the deletion processing on the master page.

On child screens, (1) for logic flows inherited from the parent screen (master page), only the placeholder actions set on the parent screen can be set, and (2) new logic flows can be created on the child screen, which can be freely set for each child screen. There is no need to configure the flowchart itself or security settings on child screens. This ensures security consistency between pages that inherit from the same master page.

Therefore, when creating child screens by inheriting a master page, the creator (developer) of each child screen can focus solely on the add-ons for each screen process without having to worry about security. Detailed security settings will be explained in Example 3.

In Figure 4(A), the permission settings of the master page are inherited by the child screen. The master page and its child screens require deletion permission at runtime. In the example shown in Figure 4(A), a flowchart is set on the master page deletion process settings screen. In this example, the start action is set to "Display a message (Perform deletion process. Are you sure?)", the action for "Yes" is set to "Placeholder: Child screen deletion process", and the action for "No" is set to "End processing".

This flowchart is carried over to child screens (department master deletion process settings screen and customer master deletion process settings screen).

(Example 2: Differences in security settings between traditional system development and low-code development)
The differences in security settings between conventional system development and development on a low-code platform will be described with reference to Figures 5 and 6.

Figure 5 is a diagram explaining security settings for conventional systems. For example, on registration screens A and B, security is typically assigned (permissions are set) to each of the new registration button, edit button, delete button, and inquiry button. While this is intuitive, the UI differs for each screen, so configuration work by specialized engineers is required for each screen. In other words, configuration work is required equal to the number of screens x the number of permissions. As such, security settings for conventional systems have been a significant burden in system construction.

Figure 6 is a diagram explaining security settings on a low-code platform. When setting up security on a low-code platform, security settings are made for each piece of logic on the master page (parent screen), and the logic set on the master page (parent screen) is inherited by child screens, eliminating the need to set security settings for each screen.

In other words, the same logic of the master page can be used on all child screens. Furthermore, when adding a new registration screen, as long as it inherits the same registration screen's master page, developers only need to add on the processing specific to each screen, making it possible to develop the system without worrying about security (see Example 1).

By using this mechanism, development can be carried out with security guaranteed, even if the technical levels of developers vary. In the example in Figure 6, secure logic is assigned to the click event of each button (New Registration button, Edit button, Delete button, Inquiry button), but from a security perspective, the control to which it is assigned must be restricted (see Example 5). Control restrictions are explained in detail in Example 5.

(Example 3: How to configure security on a low-code platform)
A method for setting security in a low-code platform will be described with reference to Figures 7 to 11. The setting unit 102b sets security information for each logic of the master page in response to operations by the developer on the development user terminal 300 on a security setting screen that displays a matrix of logic (processing) for the master page and a list of user permissions.

With a low-code platform, multiple processes can be configured as flowcharts (see Example 1). As mentioned above, depending on the process content executed in this flowchart, it is necessary to ensure that only authorized users can execute the process.

With a low-code platform, security can be configured using this configured flowchart as a single unit (hereafter, this series of flowcharts will be referred to as "logic").

Figure 7 shows an example of a security settings screen. The security settings screen is in a list format, with logic (new registration logic, modification logic, deletion logic, query logic, startup logic) on the vertical axis and user permissions required to execute the logic (none, startup, new, modification, deletion, query, execution, output) on the horizontal axis. Permissions can be set by checking the boxes.

In the example shown in Figure 7, the following permissions are set: "New" for new registration logic, "Modify" for modification logic, "Delete" for deletion logic, "Query" for query logic, and "Launch" for startup logic.

By displaying it in a list format like this, you can set security for all logic at once, preventing you from forgetting to apply security.

The configured security settings screen can be viewed from the master page and its child screens.

In addition, logic and security permissions are managed on the master, allowing developers to freely customize data.

Referring to Figure 8, an example of the registration screen master page will be explained, similar to Figure 4. The left side of Figure 8 shows an example of the flow setting screen (same as Figure 4(A)), and the right side shows an example of the security setting screen. For simplicity of explanation, Figure 8 only shows the deletion process.

In Figure 8, the logic set on the master page can only be configured for security on the master page. Security settings cannot be changed on child screens that inherit the master page's logic. Child screens can only query the security settings screen, ensuring security consistency.

The logic information to be registered will be explained with reference to Figures 9 and 10. The set logic is serialized and saved in the database 106a in Json format. One screen is registered as a single row of record, within which multiple pieces of logic are linked in a 1:N relationship and registered.

Among the logic information, the parts in bold are security-related information. The type information in the security type master is embedded in Json, and security control is performed based on this information in the execution environment.

Figure 9 shows an example of logic information (the vertical axis portion of the list in Figure 7) registered in database 106a. The example of logic information shown in Figure 9 includes screen information (screen ID, screen name), and logic data.

In the example shown in Figure 9, screen ID "1" has the screen name "Registration Screen Master Page," screen ID "2" has the screen name "Department Registration Screen," and screen ID "3" has the screen name "Customer Registration Screen." Figure 9 also shows an example of logic data, and the logic data for each screen is saved in Json format.

Figure 9 is a diagram showing an example of the security type master (the horizontal axis portion of the list in Figure 7). The security type master registers security types and security names in association with each other. In the example shown in Figure 9, security type "0" has the security name "Launch", security type "1" has the security name "New Addition", security type "2" has the security name "Modify", security type "3" has the security name "Delete", security type "4" has the security name "Query", and security type "5" has the security name "Report Output". Using this security type master allows for easy security configuration.

Placeholder actions set within the master page logic (see example 1) can be redefined as specific logic on child screens.

Figure 11 is a diagram illustrating an example of information registered in database 106a. The left side shows an example of the flow setting screen, and the right side shows an example of information (Json format) registered in the database. The flow setting screen is the same as Figure 4 (A). For simplicity of explanation, Figure 11 only shows the deletion process.

(Example 3-2: How to configure security on a low-code platform (when using subflows))
12 and 13, a security setting method when using a subflow in a low-code platform will be described. The setting unit 102b sets security information for logic information assigned to a subflow for calling another logic information from a processing flow included in the logic information, and causes the security information set for the logic information assigned to the subflow to be inherited by the calling logic information including the subflow.

If there is logic information assigned to a subflow for calling another logic from a processing flow included in the logic, the setting unit 102b may set a list of the logic information assigned to the subflow in response to the developer's operation on the security settings screen.

The screen control unit 102a may recursively query (display) the logic assigned to a subflow in a tree format under the calling logic that includes the subflow.

The screen control unit 102a may, in conjunction with the security set for logic assigned to a subflow in response to a developer's operations on the security settings screen, inquire about (display) the same security content as that set for the corresponding logic displayed in a tree view under the calling logic that includes the subflow.

Among the actions that can be used within a logic configuration flow (see example 1), there is a function called a subflow call action, which allows you to call another flowchart itself. This allows common logic to be shared between multiple logics. If this subflow is used within logic, the method for setting security (see example 3) will change slightly.

Figure 12 is a diagram explaining how to configure security on a low-code platform (when using subflows). In the example shown in Figure 12, main process A1 calls subprocess B, which calls subprocess C. Main process A2 also calls subprocesses B and D.

Figure 13 is a diagram explaining security settings when using the subflow in Figure 12. When a subflow is set within logic, security can be set not only for the main process but also for the subprocess. In complex flows, processes may be nested multiple times, so on the security settings screen, as shown in Figure 13, processes called by subprocesses are displayed under the main process that called them (at a lower level than the main process).

If the security settings of a sub-process are changed, the information under the main process (the layer below the main process) will also be automatically changed. The example shown in Figure 13 shows what happens when the settings of sub-process B are changed. When a process is executed, the permissions required for the main process and sub-process are added together, and the process can only be executed if the user has all the required permissions (otherwise, an error will occur during the permission check).

(Example 4: Permission check flow when executing a process based on security settings)
The flow of authority checks when executing processing based on security settings will be described with reference to FIGS.

The execution unit 201a of the business support system 200 executes the business application 206a in response to access from the business user terminal 400, and performs the following authority checks.

Security is controlled in the execution environment based on the security information registered in the security settings (see example 3 for information registered in database 106a).

The information shown in Figure 15 is information set by the application development support system (low-code platform) 100. Figure 14 is information showing the setting status of the business support system 200 (execution environment), which is setting information different from that of the application development support system 100.

Figure 14 shows an example of security information settings. The user authority assignment master can be configured as a table that associates and registers values (Guid values) assigned by the system for each user, values (Guid values) assigned by the system for each job, security types, and permission flags (True or False). The data in the security type master is applied to the security type.

Figure 15 is a diagram showing an example of logic information settings. Logic information includes the screen ID, screen name, logic data, job ID, and job name. The logic data used in each screen (e.g., department master maintenance) is saved in Json format as shown below (see specific example 3). Data is extracted from this and used for security checks. In the example of Figure 15, a security check is performed in the following order: master page deletion process inherited from the master page → master page modification process → ... By linking the screen created on the low-code platform with job information, it is possible to obtain the information in the user authority assignment master in Figure 14 and determine whether the operating operator (user) has the necessary authority. In other words, the user authority assignment master is referenced using the job ID of the target screen in the logic information as a key to determine whether the operating operator (user) has the necessary authority for the security type (launch, deletion, etc.).

In the example shown in Figures 14 and 15, user "1111-aaaa-aaaa-aaaa-aaaaaaaaaaaaa" is authorized to start, add new jobs, modify, inquire, and print reports, but not delete jobs, for job "2222-bbbb-bbbb-bbbb-bbbbbbbbbbbbbb" on the department master maintenance screen.

The following describes the authority check process executed by the execution unit 201a of the business support system 200. Authority checks are performed in two stages: when the screen is launched and when the process is executed. When the screen is launched, the following two checks are performed: (1) whether the user has the authority to launch a job, and (2) whether the user has the authority to execute the logic assigned to the controls on the screen.

The execution unit 201a of the business support system 200 executes the business application 206a to perform, for example, the following processing. Here, an example of the startup processing of the department master maintenance screen will be described. Figure 16 shows an example of the department master maintenance registration screen. In the example shown in the figure, the contents of the department master are as follows: Department "1" has the department name "Sales Department", Department "2" has the department name "Accounting Department", and Department "3" has the department name "General Affairs Department", and a New button, Modify button, Delete button, and Inquiry button are displayed.

Figure 17 is a flow diagram showing an example of the department master maintenance screen startup process executed by the execution unit of the business support system.

In the process shown in Figure 17, (1) if the launch authority check determines that the user does not have the authority, the job cannot be launched and the process is terminated. (2) If the authority check determines that logic that cannot be executed is assigned to each control, it is determined whether the control in question is a button, and if so, it is hidden. By hiding the button, unauthorized users cannot recognize that they can execute deletion processing on that screen, thereby achieving even stronger security. Regarding user authority, authority checks are performed when a job is launched and when processing is executed based on the security information shown in Figure 14. In the example shown in Figure 14, the user is set to not have deletion authority for a certain job. Because launch authority exists, the job can be launched, but buttons associated with logic that requires deletion authority are launched in a hidden state.

Specifically, in Figure 17, the department master maintenance registration screen is first launched (step S1). Normal business check control is performed (step S2). For example, one example of business check control is to lock a button if the closing date for a voucher has passed, preventing modifications to vouchers made before the closing date.

The logic information and security information are referenced to check whether the user has permission to start a job on the department master maintenance screen (step S3). If the user does not have permission to start a job (step S3: No), the process ends without starting the job (step S7), and an error is notified that the user does not have permission. In the example shown in Figures 14 and 15, user "1111-aaaa-aaaa-aaaa-aaaaaaaaaaaa" is set to have permission to start job "2222-bbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbbbb" on the department master maintenance screen.

If the user has launch authority ("Yes" in step S3), the security information is referenced to check whether the user has execution authority for the master page deletion process (step S4). If the user has execution authority for the master page deletion process ("Yes" in step S4), the process proceeds to step S5. Note that in the example shown in Figures 14 and 15, the user "1111-aaaa-aaaa-aaaa-aaaaaaaaaaaa" is set to have no deletion authority for the job "2222-bbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbbbb" on the department master maintenance screen.

If there is no authority to execute the master page deletion process ("No" in step S4), it is determined whether a button is assigned to the master page deletion process (step S8). If a button is not assigned to the master page deletion process ("No" in step S8), proceed to step S5. If a button is assigned to the master page deletion process ("Yes" in step S8), the delete button assigned to the master page deletion process is hidden (step S9), and proceed to step S5. In the example of Figure 14 above, the authority flag for deletion is "false," so the delete button on the department master maintenance screen in Figure 16 is hidden.

In this way, by hiding the button, unauthorized users will not be aware that deletion operations can be performed on that screen, providing strong security.

In step S5, all logic on the screen is checked and the job is launched (step S6).

Controls other than buttons are not hidden even if the user does not have the required permissions during the startup check, so after a process is requested, the business support system 200 must check the execution permissions for the process. Figure 18 is a diagram showing an example of the execution logic flow in this case. Specifically, even for hidden buttons, there is a possibility that a user may directly post a process to the business support system 200, so the business support system 200 must also check the execution permissions for the process. For this reason, processes posted to the business support system 200 are checked again, ensuring robust permission checks.

In FIG. 18, a processing event is fired from the development user terminal 300 (step S11), and the processing is posted to the business support system 200. The business support system 200 checks whether execution authority exists for the master page deletion process (step S12). If execution authority does not exist ("No" in step S12), the processing is interrupted (step S13), and an error is sent from the business support system 200 to the client. If execution authority exists ("Yes" in step S12), the processing is executed (step S14).

(Specific example 4-2: Security settings and assessment methods when using subflows)
The method of setting and determining security when using a subflow will be described with reference to the above-mentioned FIGS.

As shown in Figure 12 above, among the actions that can be used in the logic setting flow (see Example 1), there is a subflow call action, which is a function that can call another flowchart itself. This allows common logic to be shared between multiple logics.

When this subflow is used within logic, the security assessment method (see Specific Example 4) changes slightly, so we will explain this. When logic uses subflows, it is necessary to check whether the subflow within each logic has execution permission. Therefore, the security assessment method is also controlled as follows:

Figure 19 is a flow diagram illustrating an example of job startup control when using a subflow. In Figure 19, first, a check is made to see if the user has job startup authority (step S21). If the user does not have startup authority ("No" in step S21), the job is terminated and an error indicating lack of authority is notified (step S28).

If there is activation authority ("Yes" in step S21), a check is made to see if there is execution authority for Logic A (step S22). If there is execution authority for Logic A ("Yes" in step S22), proceed to step S23. If there is no execution authority for Logic A ("No" in step S22), execute the same process as in Figure 17.

In step S23, it is checked whether Logic A has a subflow (step S23). If Logic A does not have a subflow (step S23: No), proceed to step S26. If Logic A has a subflow (step S23: Yes), it is checked whether execution authority exists for that subflow (step S24). If execution authority exists for that subflow (step S24: Yes), proceed to step S25. On the other hand, if execution authority does not exist for that subflow (step S24: No), it is checked whether a button has been assigned to Logic A (step S30). If no button has been assigned (step S30: No), proceed to step S25. If an assignment has been made (step S30: Yes), the button assigned to Logic A is hidden (step S31), and proceed to step S25.

In step S25, all subflows within the logic are checked, and then all logic within the screen is checked (step S26), after which the job is launched (step S27).

(Example 5: Controlling security assignment destinations)
Control of security allocation controls will be described with reference to Figure 20. When a developer sets security for a control action on a setting screen, the detection unit 102d of the application development support system 100 references the security configurable master 106b to detect whether the action of the control can be set. In this case, the detection unit 102d may refer to the security configurable master 106b and, if the permission flag for the action of the control is configurable, permit the setting, but, if the permission flag for the action of the control is not configurable, notify an error.

Figure 20 is a diagram explaining the control of security allocation destination controls. In a typical system, it is thought that the majority of UIs that link logic to which security settings are assigned, such as master deletion processing and report output processing, are button click events. From a security perspective, being able to assign security settings to any control is undesirable, as it could unintentionally create security holes.

In particular, with low-code platforms, developers with no security knowledge may be responsible for system configuration. In extreme cases, developers without such specialized knowledge may make abnormal configurations, such as assigning a delete process to a radio button check process. Therefore, the low-code platform must limit the assignment of security as much as possible.

On the other hand, imposing strict restrictions such as assigning all security logic to button click events alone raises concerns that this could impair the system's scalability and usability.

We therefore devised a system that allows developers to arbitrarily restrict the types of controls that can be assigned security logic by registering them in the master. This makes it possible to ensure consistency in security settings across the entire system, even in large-scale development projects where multiple developers are working on a system, without each developer having to be particularly aware of it.

Controlling such exceptional security settings on the low-code platform also leads to improved usability. For example, if an attempt is made to add security logic to a control type with restricted settings (such as a radio button), the low-code platform will notify the developer of an error, allowing the developer to immediately correct the settings.

Figure 20 (A) shows an example of a security configurable master 106b. The security configurable master 106b can be configured as a table or the like that associates and registers controls, actions, and configurability flags that indicate whether or not they can be set. In the example shown in the figure, the first row has the control "button," the action "click," and the configurability flag "1 (configurable)," the second row has the control "radio button," the action "check," and the configurability flag "0 (not configurable)," and the third row has the control "table," the action "click," and the configurability flag "0 (not configurable)."

For example, if a development user attempts to set security that requires modification authority when a radio button is executed on the settings screen shown in Figure 20 (B), the detection unit 102d will notify an error because, in the example of the security configurable master 106b, the control "radio button" has its configurability flag set to "0 (not configurable)."

Furthermore, if an error occurs on the low-code platform, conversion to the execution environment is not possible, as shown in Figure 20 (C). This ensures robust security.

As described above, the application development support system of this embodiment is equipped with a screen control unit 102a that displays a security settings screen that displays a matrix of logic for the master page and a list of its permissions, and a settings unit 102b that sets the security of each piece of logic on the master page in accordance with operations performed by the developer on the security settings screen, allowing the developer to appropriately determine and manage what kind of permission control will be applied to the actual application.

[4. Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to SDGs goals 12, 13, and 15.

Furthermore, this embodiment can contribute to strengthening control and governance, thereby contributing to Goal 16 of the SDGs.

5. Other Embodiments
The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

In addition, the processing procedures, control procedures, specific names, registered data for each process, information including parameters such as search conditions, screen examples, and database configurations shown in this specification and drawings may be changed as desired unless otherwise specified.

Furthermore, with regard to the application development support system 100, the components shown in the figure are functional concepts and do not necessarily have to be physically configured as shown.

For example, all or any part of the processing functions of the application development support system 100, particularly the processing functions performed by the control unit 102, may be implemented by a CPU and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory, computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the application development support system 100 as needed. That is, a computer program is recorded on the storage unit 106, such as a ROM or HDD (Hard Disk Drive), for working with the OS to issue commands to the CPU and perform various processes. This computer program is executed by being loaded into RAM, and works with the CPU to configure the control unit 102.

In addition, this computer program may be stored on an application program server connected to the application development support system 100 via any network, and all or part of it may be downloaded as needed.

In addition, the program for executing the processing described in this embodiment may be stored on a non-temporary computer-readable recording medium, or may be configured as a program product. Here, this "recording medium" includes memory cards, USB (Universal Serial Bus) memories, SD (Secure Digital) cards, flexible disks, magneto-optical disks, ROMs, EPROMs (Erasable Programmable Read Only Memory), EEPROMs (registered trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROMs (Compact Disk Read Only Memory), MOs (Magneto-Optical disks), DVDs (Digital Versatile Disks), and more. This includes any "portable physical media" such as a Blu-ray Disc (registered trademark) and a Blu-ray (registered trademark) Disc.

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. It should be noted that a "program" is not necessarily limited to a single structure, but also includes a distributed structure consisting of multiple modules or libraries, or a structure that achieves its function by working in conjunction with a separate program, such as an OS. The specific structure and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known structures and procedures.

The various databases stored in the memory unit 106 are storage devices such as memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and website provision.

The application development support system 100 may also be configured as an information processing device such as a known personal computer or workstation, or as an information processing device connected to any peripheral device. The application development support system 100 may also be realized by installing software (including programs, data, etc.) that causes the information processing device to perform the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional additions. In other words, the above-mentioned embodiments may be implemented in any combination, or embodiments may be implemented selectively.

100 Application development support system 102 Control unit 102a Screen control unit 102b Setting unit 102c Registration unit 102d Detection unit 102e Master maintenance unit 104 Communication interface unit 106 Storage unit 106a Database 106b Security configurable master 108 Input/output interface unit 112 Input device 114 Output device 200 Business support system 202 Control unit 202a Execution unit 204 Communication interface unit 206 Storage unit 206a Business application 208 Input/output interface unit 212 Input device 214 Output device 300 Development user terminal 400 Business user terminal 500 Network 600 Server 700 Server

Claims (7)

An application development support system including a control unit,
The control unit
a screen display control means for displaying a security setting screen that displays a list of logic and permissions for the master page in a matrix format;
a setting means for setting security for each logic of the master page in response to an operation by a developer on the security setting screen;
Equipped with
The application development support system is characterized in that the screen display control means is configured to be able to query the set master page security in a list for the master page and child screens subordinate to the master page. The application development support system of claim 1, characterized in that, when there is logic information assigned to a subflow for calling another logic from a processing flow included in the logic, the setting means is configured to be able to set a list of the logic information assigned to the subflow in response to a developer's operation on the security setting screen, and the screen display control means is configured to be able to recursively query the logic assigned to the subflow in a tree format under the calling logic including the subflow. The application development support system described in claim 2, characterized in that the screen display control means is configured to be able to link with security set for logic assigned to the subflow in response to operations by the developer on the security setting screen, and to query the corresponding logic displayed in a tree structure under the calling logic including the subflow for the same security content. An application development support system according to any one of claims 1 to 3, characterized in that the permissions include at least one of new registration permission, modification permission, deletion permission, inquiry permission, and startup permission. The application development support system described in any one of claims 1 to 4 is a system capable of developing applications by defining GUI operations. An application development support method executed by an information processing device having a control unit,
Executed by the control unit,
a screen display control step of displaying a security setting screen that displays a list of logic and permissions for the master page in a matrix format;
a setting step of setting security for each logic of the master page in accordance with operations of the developer on the security setting screen;
Including,
The application development support method is characterized in that the screen display control step is configured to enable the security of the set master page to be queried in a list for the master page and child screens subordinate to the master page. An application development support program to be executed by an information processing device having a control unit,
The control unit
a screen display control step of displaying a security setting screen that displays a list of logic and permissions for the master page in a matrix format;
a setting step of setting security for each logic of the master page in accordance with operations of the developer on the security setting screen;
It is an application development support program to execute
The application development support program is characterized in that the screen display control step is configured to enable the security of the set master page to be queried in a list for the master page and child screens subordinate to the master page.