JP7827583B2 - Cloud environment construction support system, cloud environment construction support method - Google Patents

Description

The present invention relates to a cloud environment construction support system and a cloud environment construction support method.

Various technologies for supporting the creation of cloud-based system environments have existed for some time. Patent Document 1 describes an environment construction support system 100 that includes a storage unit 101 that stores a constant design document 125 for the information processing device (hereinafter referred to as "device") to be constructed, a definition file template 126 that defines the settings for the device, and a construction script template 127 that describes a series of environment construction commands to be executed on the device. It also describes a calculation unit 104 that converts the constant design document 125 into a constant setting value file 130 using a specified tool 110, executes a specified environment construction tool 140 using the constant setting value file 130 as input, generates a definition file 131 and a construction script 132 that set specified items in the constant design document 125 in the definition file template 126 and the construction script template 127, distributes the definition file 131 and the construction script 132 to the device, executes the construction script 132 on the device, and constructs a specified environment defined in the constant design document 125 on the device.

Japanese Patent Application Laid-Open No. 2020-017053

In Patent Document 1, in order to build a system environment for a financial system, construction scripts, parameters, etc. are automatically generated based on a manually created constant design document for the target system. However, when building a system environment on the cloud, the non-functional requirements of the various customers who will be using the system result in numerous changes to the feature model, which determines the system configuration by selecting some of the system elements (features) defined in a hierarchical structure, and the constant design document. Furthermore, even for the same system environment, systems may need to be built using different cloud vendors depending on the customer's requests. In this case, a separate constant design document and feature model must be created for each cloud vendor.

The present invention aims to provide technology that can support the creation of a cloud environment that better reflects customer requirements by creating a feature model that takes into account the customer's non-functional requirements and cloud services provided by different cloud vendors.

The cloud environment construction support system of the present invention is a cloud environment construction support system that supports the construction of a cloud environment system using a computer having a processor and memory. The processor generates feature model data that constitutes the cloud environment system based on feature model basic data that defines the general configuration of cloud services and non-functional requirements provided by different cloud vendors, a non-functional requirement list that indicates, for each type of non-functional requirement, the means for realizing the non-functional requirements, cloud data that stores options for cloud services provided by the cloud vendor, non-functional requirement selection data that stores the non-functional requirements selected by the user, and cloud selection data that stores the cloud services selected by the user. The processor converts the generated feature model data into a predetermined format that is editable by the user, and outputs the user-editable feature model data converted into the predetermined format to the user terminal.

This invention creates a feature model that takes into account the customer's non-functional requirements and cloud services offered by different cloud vendors, thereby helping to build a cloud environment that better reflects customer needs. Issues, configurations, and advantages other than those described above will become clear from the description of the following mode for implementing the invention.

FIG. 1 illustrates an example of a configuration of a cloud environment construction support system according to an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of a schematic configuration of a computer. 10 is a flowchart showing a processing procedure of a process (feature model data generation process) performed by a feature model data generation unit. FIG. 10 is a diagram illustrating an example of feature model basic data. FIG. 10 is a diagram illustrating an example of a non-functional requirement list. FIG. 10 is a diagram illustrating an example of non-functional requirement selection data. FIG. 10 is a diagram illustrating an example of feature model data. FIG. 10 is a diagram illustrating an example of cloud data. FIG. 10 is a diagram illustrating an example of cloud selection data. 10 is a flowchart showing a processing procedure of a process (feature model conversion process) performed by a feature model conversion unit. 10 is a diagram for explaining how the feature model conversion unit outputs feature model data for user editing, which is a file in json format. FIG. 10 is a flowchart showing a processing procedure of a process (feature model editing process) performed by a feature model editing unit. FIG. 10 is a diagram illustrating an example of a screen (feature model editing screen) displayed on a user terminal.

Embodiments of the present invention will be described below with reference to the drawings. The following description and drawings are examples for explaining the present invention, and some details have been omitted or simplified as appropriate for clarity of explanation. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

The position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.

In the following explanation, various types of information may be described using terms such as "database," "table," and "list," but the various types of information may also be expressed in other data structures. To indicate that the information is not dependent on the data structure, "XX table," "XX list," etc. may be referred to as "XX information." When describing identification information, terms such as "identification information," "identifier," "name," "ID," and "number" are used, and these terms are interchangeable.

When there are multiple components with the same or similar functions, they may be described using the same reference numeral with different subscripts. However, when there is no need to distinguish between these multiple components, the subscripts may be omitted.

In addition, the following description may describe processing performed by executing a program, but since a program is executed by a processor (e.g., a CPU or a GPU (Graphics Processing Unit)) to perform a specified process using storage resources (e.g., memory) and/or interface devices (e.g., communication ports) as appropriate, the processor may be the subject of the processing. Similarly, the subject of processing performed by executing a program may be a controller, device, system, computer, or node having a processor. The subject of processing performed by executing a program may be any computing unit, and may include a dedicated circuit (e.g., an FPGA (Field-Programmable Gate Array) or ASIC (Application Specific Integrated Circuit)) that performs specific processing.

A program may be installed on a device such as a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. If the program source is a program distribution server, the program distribution server may include a processor and storage resources for storing the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. Also, in the following description, two or more programs may be realized as one program, and one program may be realized as two or more programs.

The following describes an example of a cloud environment construction support system and a cloud environment construction support method according to this embodiment.

Figure 1 is a diagram showing an example of the configuration of a cloud environment construction support system in this embodiment. As shown in Figure 1, the cloud environment construction support system 1000 includes a cloud environment construction support device 100 for supporting the construction of a system environment in the cloud, and a user terminal 300 operated by a system engineer, who is the user, connected via a general network N such as the Internet.

The cloud environment construction support device 100 is a server that supports the system construction of various cloud environments in response to customer requests. The cloud environment construction support device 100 is configured to include a feature model data generation unit 101 that generates feature model data 206 using a non-functional requirements list 201, cloud data 202, non-functional requirement selection data 203, cloud selection data 204, and feature model basic data 205; a feature model conversion unit 102 that converts the feature model data 206 into user-editable feature model data 207 in json format; and a feature model editing unit 103 that edits the user-editable feature model data 207. json is a data exchange format and data description language that uses the object notation of JavaScript (registered trademark). This example illustrates the case where feature model data 206 is converted into a user-editable json format, but other formats may also be used.

As will be described in detail later, the feature model data generation unit 101 processes the feature model basic data 205 and generates feature model data 206 based on the non-functional requirements and cloud determined by the user.

Functional requirements are functional requirements required by the customer when building a system, while non-functional requirements are requirements other than the functional requirements required by the customer. Examples of types of non-functional requirements include system availability, system performance and scalability, system operation and maintainability, system migration, system security, and system environment and ecology. Here, we will assume that non-functional requirements are the requirements listed above, but they may of course include other general requirements that are defined as non-functional requirements.

Availability refers to requirements for the continued use of a system, including definitions of, for example, redundancy of equipment such as servers and terminals, operation schedules, and recovery methods in the event of a failure. Performance and scalability refer to requirements related to the processing performance and expansion of a system, including definitions of, for example, the number of transactions to be processed by the system to be constructed, the number of users, and the load on the system. Operation and maintainability refer to requirements related to the operation and maintenance of a system, including definitions of, for example, system monitoring methods, backup methods, and operational structures. Portability refers to requirements related to migration from the current system, including definitions of migration plans such as the transition period, transition structure, and transition rehearsals for migrating to the new system. Security refers to requirements related to ensuring the safety of a system, including definitions of, for example, access restrictions and methods for monitoring unauthorized access. Environment and ecology refer to requirements related to the environment and ecology in which the system is installed, including definitions of, for example, system configurations that reduce environmental impact such as earthquake resistance and noise, and the suitability of systems to reduce CO2 emissions and energy consumption.

The feature model conversion unit 102 converts the generated feature model data 206 into user-editable feature model data 207 in a predetermined format, such as JSON format, and transmits the converted data to the user terminal 300. In the user terminal 300, the display output unit 301 displays the converted data on the screen by launching a browser, for example, and the input unit 302 accepts input from the user and generates a feature model, constant design document, construction script, parameters, etc. The following illustrates an example of editing a feature model, but the same applies to constant design documents, construction scripts, parameters, etc.

The feature model editing unit 103 saves and outputs the new feature model edited by the user through operation on the user terminal 300.

The specific contents of the non-functional requirements list 201, cloud data 202, non-functional requirements selection data 203, cloud selection data 204, feature model basic data 205, feature model data 206, and user-edited feature model data 207 will be explained together with the explanation of the processing of this system using a flowchart.

The user terminal 300 is a terminal used by a user who creates a cloud environment. The user terminal 300 has a display output unit 301 and an input unit 302. The display output unit 301 is, for example, a display, and displays various information related to the execution of the processes described below on the screen. The input unit 302 is, for example, a keyboard or mouse, and accepts input of various information related to the execution of the processes described below.

The cloud environment construction support device 100 and user terminal 300 used in this system can be realized, for example, as shown in Figure 2 (computer schematic diagram), by a general computer 1600 equipped with a CPU 1601, memory 1602, an external storage device 1603 such as an HDD (Hard Disk Drive), a reading/writing device 1607 for reading and writing information from a portable storage medium 1608 such as a CD (Compact Disk) or USB memory, an input device 1606 such as a keyboard or mouse, an output device 1605 such as a display, a communication device 1604 such as a NIC (Network Interface Card) for connecting to a communication network, and an internal communication line (referred to as a system bus) 1609 such as a system bus that connects these devices.

In addition, various data stored in each terminal or server or used for processing can be realized by the CPU 1601 reading it from the memory 1602 or the external storage device 1603 and using it. Furthermore, each functional unit (e.g., the feature model data generation unit 101, the feature model conversion unit 102, the feature model editing unit 103) of the cloud environment construction support device 100 or the user terminal 300 can be realized by the CPU 1601 loading a specific program stored in the external storage device 1603 into the memory 1602 and executing it.

The above-mentioned predetermined program may be stored (downloaded) into the external storage device 1603 from the storage medium 1608 via the reading/writing device 1607 or from the network via the communication device 1604, and then loaded into the memory 1602 and executed by the CPU 1601. Alternatively, the program may be loaded directly into the memory 1602 from the storage medium 1608 via the reading/writing device 1607 or from the network via the communication device 1604, and then executed by the CPU 1601.

The following describes an example in which the cloud environment construction support device 100 is configured from a single computer, but similar functions may be realized by distributing all or part of these functions across one or more computers, such as a cloud, and communicating with each other via a network.

Figure 3 is a flowchart showing the processing steps of the feature model data generation process performed by the feature model data generation unit 101.

As shown in FIG. 3, the feature model data generation unit 101 extracts one table from one or more feature model basic data 205 (S301), and extracts one row of record from the extracted table (S302).

Figure 4 shows an example of feature model basic data 205. Feature model basic data 205 is a table that defines the general configuration of cloud services and non-functional requirements when creating a feature model. Feature model basic data 205 is defined in advance by, for example, a system administrator.

As shown in Figure 4, the feature model basic data 205 stores, in association with one another, an ID for uniquely identifying each record, levels 1 to n indicating the names of features at the 1st to nth levels, the options that the record can take, option types indicating the types of constraints on the selection state when the options are incorporated into the feature model, cloud service types indicating the names of services provided by the cloud, and a non-functional requirement selection data ID list indicating the IDs of non-functional requirements allowed by the level described in the record.

In Figure 4, for example, the record identified by ID "3" is basic data for a feature model with "AP" (application server) as tier 1 and "middleware" as tier 2, and indicates that the possible middleware options for this feature model are the "JBOSS" application. This also indicates that the "JBOSS" application must be incorporated. Choice types are set to "Required," which means that a choice must be made; "Selection," which requires that one of the options from the list be selected; or "Optional," which means that selection is optional. However, for records in which a "Non-functional Requirement Selection Data ID List" is defined, the choice type is left blank because it will be updated in a process described below. Furthermore, the cloud service type indicates that the name of the service provided on the cloud is determined by the "instance type." The cloud service type is a name that is not affected by the "cloud type" defined in cloud data 202.

Next, the feature model data generation unit 101 extracts one line of records from the non-functional requirements list 201 (S303).

Figure 5 is a diagram showing an example of the non-functional requirements list 201. The non-functional requirements list 201 is a list that lists, in tabular form, the means for realizing each non-functional requirement and the options for those means, for each type of non-functional requirement. As shown in Figure 5, the non-functional requirements list 201 stores, in association with each other, an ID for uniquely identifying each non-functional requirement, a non-functional requirement type that indicates the type of non-functional requirement to be achieved, a non-functional requirement realization means that indicates the means for realizing the non-functional requirement described in that non-functional requirement type, a realization means option list that indicates the options that the non-functional requirement realization means can take, and option types similar to those of the feature model basic data 205.

In Figure 5, for example, the record identified by ID "3" is a non-functional requirement represented by the non-functional type "security," and indicates that the means for realizing this non-functional requirement is to select either "HTTPS" or "SSL/TSL" and perform encryption.

Next, the feature model data generation unit 101 determines whether the "non-functional requirement selection data ID list" of the row extracted from the feature model basic data 205 in S302 includes the "ID" of the row extracted from the non-functional requirement list 201 (S304).

If the feature model data generation unit 101 determines in S302 that the "non-functional requirement selection data ID list" of the row extracted from the feature model basic data 205 contains the "ID" of the row extracted from the non-functional requirement list 201 (S304; Yes), it proceeds to S305.

For example, if the feature model data generation unit 101 extracts a record with ID "1" from the feature model basic data 205 shown in FIG. 4 in S302, and then extracts a record with ID "1" from the non-functional requirement list 201 shown in FIG. 5 in S303, the record with ID "1" from the non-functional requirement list 201 will be included among the IDs "1" and "3" listed in the "Non-functional requirement selection data ID list" of the record in the feature model basic data 205. Therefore, the feature model data generation unit 101 will determine "Yes" in S304 and proceed to S305. In this example, the same applies when the record with ID "3" from the non-functional requirement list 201 is extracted.

On the other hand, if the feature model data generation unit 101 determines in S302 that the "non-functional requirement selection data ID list" of the row extracted from the feature model basic data 205 does not include the "ID" of the row extracted from the non-functional requirement list 201 (S304; No), it proceeds to S307.

Furthermore, the feature model data generation unit 101 determines whether a selection flag exists for a row in the non-functional requirement selection data 203 described below that has a "non-functional requirement selection ID" that matches the "ID" of the row extracted from the non-functional requirement list 201 (S305).

Figure 6 is a diagram showing an example of non-functional requirement selection data 203. Non-functional requirement selection data 203 is data that stores which non-functional requirements the user selected from one or more non-functional requirements. As shown in Figure 6, non-functional requirement selection data 203 stores a non-functional requirement ID indicating the ID of non-functional requirement list 201 in association with a selection flag indicating whether the non-functional requirement ID was selected.

Figure 6 shows that the user has selected non-functional requirements with non-functional requirement IDs "1" and "3" for the feature model they are trying to create. The selection flags can be set, for example, by the user terminal 300 displaying the non-functional requirement selection data 203 shown in Figure 6 on the display output unit 301, the input unit 302 accepting the selection of the selection flag corresponding to the non-functional requirement ID from the user, and transmitting the result to the cloud environment construction support device 100 as non-functional requirement selection data 203.

In this example, since non-functional requirement IDs "1" and "3" are selected in the non-functional requirement selection data 203, the feature model data generation unit 101 determines "Yes" in S305 and proceeds to S306. On the other hand, if it determines in S305 that there is no selection flag in the row having a "non-functional requirement selection ID" that matches the "ID" of the row extracted from the non-functional requirement list 201 (S305; No), it proceeds to S307.

The feature model data generation unit 101 adds the non-functional requirement realization means, realization means option list, and option type of the record extracted from the non-functional requirements list 201 in S303 to the record extracted from the feature model basic data 205 in S302, and writes this as a new row in the feature model data 206 (S306).

Figure 7 is a diagram showing an example of feature model data 206. Feature model data 206 is data that stores a feature model that configures a system environment on the cloud by adding non-functional requirements selected by the user to feature model basic data 205. As shown in Figure 7, feature model data 206, like feature model basic data 205 shown in Figure 4, stores an ID for uniquely identifying each record, levels 1 to n indicating the names of features in the first to nth levels, options that the record can take, and option types indicating the constraint types of those options, all associated with each other. Also, associated with each of these items are stored selection results indicating the non-functional requirements selected by the user in non-functional requirement selection data 203.

In Figure 7, for example, the record identified by ID "2" indicates that, based on the feature model basic data 205, "HTTPS" is selected as one of the means for realizing the non-functional requirement represented by the non-functional type "security."

The feature model data generation unit 101 determines whether processing has been performed for all records in the non-functional requirement list 201 (S307). If it is determined that processing has been performed for all records (S307; Yes), the process proceeds to S308. On the other hand, if the feature model data generation unit 101 determines that processing has not been performed for all records in the non-functional requirement list 201 (S307; No), the process returns to S303 and repeats the subsequent processing.

After the feature model data generation unit 101 performs the process up to S307 to add the daily functional requirements selected by the user to the feature model basic data 205, it then extracts one row of record from the cloud data 202 (S308).

Figure 8 is a diagram showing an example of cloud data 202. Cloud data 202 is a table that stores the options available for cloud services provided by a cloud vendor. As shown in Figure 8, cloud data 202 stores, in association with each other, an ID for uniquely identifying each record, a cloud type indicating the name of the cloud vendor, a cloud service type indicating the name of the service provided by the cloud of that cloud type, a cloud service indicating the name of the service that realizes the cloud service of that cloud service type, cloud service options indicating the options available for the cloud service type in that cloud service, and, similar to non-functional requirements list 205, option types indicating the constraints on the selection state when incorporated into a feature model.

In Figure 8, for example, the record identified by ID "1" is an AWS cloud provided by an EC2 instance, and indicates that one (or more) specifications must be selected from the cloud service options, including "m5.xlarge."

The feature model data generation unit 101 determines whether the "cloud service type" of the row extracted from the feature model basic data 205 in S302 matches the "cloud service type" of the row extracted from the cloud data 202 (S309).

If the feature model data generation unit 101 determines in S302 that the "cloud service type" of the row extracted from the feature model basic data 205 matches the "cloud service type" of the row extracted from the cloud data 202 (S309; Yes), it proceeds to S310.

For example, in S302, when the feature model data generation unit 101 extracts a record with ID "2" from the feature model basic data 205 shown in FIG. 4, it reads the "instance type" described in the "cloud service type" of the record in the feature model basic data 205. Because the "cloud service type" of the record with ID "1" in the cloud data 202 is "instance type," the feature model data generation unit 101 determines "Yes" in S308 and proceeds to S310.

On the other hand, if the feature model data generation unit 101 determines in S302 that the "cloud service type" of the row extracted from the feature model basic data 205 does not match the "cloud service type" of the row extracted from the cloud data 202 (S309; No), it proceeds to S312.

Furthermore, the feature model data generation unit 101 determines whether a selection flag exists for a row in the cloud selection data 204 (described below) that has a "cloud data ID" that matches the "ID" of the row extracted from the cloud data 202 (S310).

Figure 9 shows an example of cloud selection data 204. Cloud selection data 204 is data that stores which cloud service the user selected from one or more cloud services. As shown in Figure 8, cloud selection data 204 stores a cloud data ID indicating the ID of cloud data 206 and a selection flag indicating whether the cloud data ID was selected, in association with each other.

Figure 9 shows that the user has selected a cloud service with cloud data ID "1" for the feature model they are trying to create. The selection flag can be set, for example, by the user terminal 300 displaying the cloud selection data 204 shown in Figure 9 on the display output unit 301, the input unit 302 accepting the selection of the selection flag corresponding to the cloud data ID from the user, and transmitting the result to the cloud environment construction support device 100 as the cloud selection data 204.

In this example, cloud data ID "1" is selected in the cloud selection data 204, so the feature model data generation unit 101 determines "Yes" in S310 and proceeds to S311. On the other hand, if it determines in S310 that there is no selection flag in the row having a "cloud data ID" that matches the "ID" of the row extracted from the cloud data 202 (S310; No), the process proceeds to S312.

The feature model data generation unit 101 adds the cloud service and cloud service options of the record extracted from the cloud data 202 in S308 to the record extracted from the feature model basic data 205 in S302, and writes this as a new row in the feature model data 206 (S311).

The feature model data 206 shown in Figure 7 shows that in addition to the record with ID "2" added in S307, the record with ID "3" has also been added as feature model data 206, based on the feature model basic data 205, with a cloud service that is an AWS cloud provided by an EC2 instance and has the specs "m5.xlarge".

The feature model data generation unit 101 determines whether processing has been performed for all cloud data 202 (S312), and if it determines that processing has been performed for all cloud data 202 (S312; Yes), it proceeds to S313. On the other hand, if the feature model data generation unit 101 determines that processing has not been performed for all cloud data 202 (S312; No), it returns to S308 and repeats the subsequent processing.

Furthermore, the feature model data generation unit 101 determines whether processing has been performed on all records of the feature model basic data 205 extracted in S302 (S313), and if it determines that processing has been performed on all records of the feature model basic data 205 extracted in S302 (S313; Yes), it proceeds to S314. On the other hand, if the feature model data generation unit 101 determines that processing has not been performed on all records of the feature model basic data 205 extracted in S302 (S313; No), it returns to S302 and repeats the subsequent processing.

Furthermore, the feature model data generation unit 101 determines whether or not all tables in the feature model basic data 205 to be extracted in S301 have been processed (S314), and if it determines in S301 that all tables in the feature model basic data 205 to be extracted have been processed (S314; Yes), it terminates this processing. On the other hand, if the feature model data generation unit 101 determines in S301 that all tables in the feature model basic data 205 to be extracted have not been processed (S314; No), it returns to S301 and repeats the subsequent processing.

By performing this feature model data generation process, the feature model data generation unit 101 can process the feature model basic data and generate feature model data based on the non-functional requirements and cloud services selected by the user.

Figure 10 is a flowchart showing the processing steps of the feature model conversion process performed by the feature model conversion unit 102 (feature model conversion process).

As shown in FIG. 10, the feature model conversion unit 102 extracts one table from one or more feature model data 206 generated by the feature model data generation unit 101 (S1001), and extracts one row of record from the extracted table (S1002).

Furthermore, the feature model conversion unit 102 extracts one "layer" from the record extracted in S1002 (S1003), and determines whether the content of the extracted "layer" is blank (S1004).

If the feature model conversion unit 102 determines that the content of the extracted "hierarchy" is not blank (S1004; No), the process proceeds to S1005. On the other hand, if the feature model conversion unit 102 determines that the content of the extracted "hierarchy" is blank (S1004; Yes), the process proceeds to S1008.

Furthermore, the feature model conversion unit 102 determines whether the contents of the "layer" extracted in S1003 have already been written out (S1005). If the feature model conversion unit 102 determines that the contents of the "layer" extracted in S1003 have not already been written out (S1005; No), it outputs the contents of "layer N" to the user-edited feature model data 207, with the value of "name" and a serial number as the value of "id" (S1006). On the other hand, if the feature model conversion unit 102 determines that the contents of the "layer" extracted in S1003 have already been written out (S1005; Yes), it proceeds to S1007 without doing anything.

In S1006, the feature model conversion unit 102 outputs the contents of "Layer N" to the user-edited feature model data 207 with the value of "name" and the serial number as the value of "id." Then, it determines whether all the contents of that layer have been processed (S1007). If it determines that all the contents of that layer have been processed (S1007; Yes), it proceeds to S1008. On the other hand, if the feature model conversion unit 102 determines that all the contents of that layer have not been processed (S1007; No), it returns to S1003 and repeats the subsequent processes.

The feature model conversion unit 102 outputs the contents of the "option" corresponding to the layer processed in S1007 as the value of "item," the contents of the option type as the value of "option," and the contents of the selection result as the value of "selection" to the feature model data for user editing 207 (S1008).

Figure 11 is a diagram illustrating how the feature model conversion unit 102 outputs json-formatted user-editable feature model data 207. As shown in Figure 11, in S1006, the feature model conversion unit 102 outputs to the user-editable feature model data 207 the contents set for each layer (in this example, layer 1 and layer 2) of the record (in this example, the record with ID "1") stored in the feature model data 206 generated by the feature model data generation unit 101. In Figure 11, the "AP" set for layer 1 and the "region" set for layer 2 are output as the values of "name" (S1101, S1102). The feature model conversion unit 102 also sets the serial numbers "1" and "2" to "id".

Furthermore, in S1008, the feature model conversion unit 102 sets the "option" content of the record with ID "1" stored in the feature model data 206 output in S1101 and S1102, "single, multi", as the value of "item", sets the content of the option type, "selection", as the value of "option", and outputs the content of the selection result, "single", as the value of "selection" to the feature model data 207 for user editing (S1103, S1104, S1105).

Returning to FIG. 10, the feature model conversion unit 102 determines whether all records in the table extracted in S1001 have been processed (S1009), and if it determines that all records in the table extracted in S1001 have been processed (S1009; Yes), the process proceeds to S1010. On the other hand, if the feature model conversion unit 102 determines that all records in the table extracted in S1001 have not been processed (S1009; No), the process returns to S1002 and repeats the subsequent processes.

Furthermore, the feature model conversion unit 102 determines whether or not all tables in the feature model data 206 to be extracted in S1001 have been processed (S1010), and if it determines in S1001 that all tables in the feature model data 206 to be extracted have been processed (S1010; Yes), this processing ends. On the other hand, if the feature model data generation unit 101 determines in S1001 that all tables in the feature model data 206 to be extracted have not been processed (S1010; No), the process returns to S1001 and repeats the subsequent processing.

By performing this feature model conversion process, the feature model conversion unit 102 can output user-edited feature model data 207, which is a file in a specified format such as JSON format, from feature model data containing non-functional requirements and cloud services selected by the user.

Figure 12 is a flowchart showing the processing steps of the processing (feature model editing processing) performed by the feature model editing unit 103. In this example, the feature model editing unit 103 reads one piece of user-edited feature model data 207 converted by the feature model conversion unit 102, and transmits the read user-edited feature model data 207 to the user terminal 300. Furthermore, the user terminal 300 displays editing data (e.g., data in a browser display format) including each item stored in the user-edited feature model data 207 on the display output unit 301, and the input unit 302 accepts editing of the feature model composed of the user-edited feature model data 207, and transmits the data of the selected feature and the user-edited feature model data 207 to the cloud environment construction support device 100.

As shown in FIG. 12, when the save button is pressed on the user terminal 300, the feature model editing unit 103 receives data of the selected feature and user-edited feature model data 207 from the user terminal 300 (S1201).

The feature model editing unit 103 selects one selected feature from one or more selected features received from the user terminal 300, and updates the "selection" value of the corresponding location in the user-edited feature model data 207 received from the user terminal 300 in S1201 to the value of the selected feature (S1202).

The feature model editing unit 103 determines whether or not one or more of the selected features received from the user terminal 300 have been processed (S1203), and if it determines that one or more of the selected features received from the user terminal 300 have been processed (S1203; Yes), it terminates this processing. On the other hand, if the feature model editing unit 103 determines that one or more of the selected features received from the user terminal 300 have not been processed (S1203; No), it returns to S1202 and continues processing.

Figure 13 is a diagram showing an example of a screen (feature model editing screen) displayed on the user terminal 300. As shown in Figure 13, the feature model editing screen 1300 includes a load button 1301 for loading the editing data, a save button 1302 for reflecting each item of the editing data edited in the editing area 1303 in the user-edited feature model data 207, and an editing area 1303 indicating an area in which the user can edit the user-edited feature model data 207.

In Figure 13, the items S1101 to S1105 output from the feature model data 206 shown in Figure 11 to the user-edited feature model data 207 are displayed in the left column of the editing area 1303. For example, "AP", which was set as tier 1 in S1101, is set as item 1304, and "Region", which was set as tier 2 in S1102, is set as item 1305. Furthermore, "Single, Multi", which was set as an option in S1103, is set as item 1306, and of these, the selection result "Single" set in S1105 is checked.

When the display output unit 301 of the user terminal 300 displays a feature model editing screen such as that shown in FIG. 13, the input unit 302 accepts edits to the displayed content from the user. For example, if the user determines that a "multiple" feature model should be generated rather than a "single" one in light of customer requirements for the "region" set as tier 2, the user checks "multiple" on the screen and presses the save button 1302. When the input unit 302 accepts the press of the save button 1302, the display output unit 301 outputs the selected features, including the items entered, updated, or changed on the edited screen, and transmits the output data and the user-edited feature model data 207 to the cloud environment construction support device 100.

The feature model editing unit 103 reflects each item of the newly edited editing data received from the user terminal 300 in the user-edited feature model data 207, as described above.

As explained above, the cloud environment construction support system in this embodiment is a cloud environment construction support system 1000 that supports the construction of a cloud environment system using a computer having a processor and memory. The processor (e.g., CPU 1601) executes the feature model data generation unit 101 (program) to generate feature model basic data 205 that defines the general configuration of cloud services and non-functional requirements provided by different cloud vendors, a non-functional requirement list 201 that represents, for each type of non-functional requirement, the means to realize the non-functional requirement, and a cloud data list that stores the options available for the cloud services provided by the cloud vendor. The system generates feature model data 206 constituting the cloud environment system based on the user's data 202, non-functional requirement selection data 203 storing the non-functional requirements selected by the user, and cloud selection data 204 storing the cloud service selected by the user. The system then executes a feature model conversion unit 102 (program) to convert the generated feature model data into user-editable feature model data 207 in a predetermined user-editable format (e.g., JSON format). The system then executes a feature model editing unit 103 (program) to output the feature model data converted to the predetermined format to a user terminal 300. This creates a feature model that takes into account the customer's non-functional requirements and cloud services offered by different cloud vendors, thereby supporting the creation of a cloud environment that better reflects customer needs. While addressing non-functional requirements and supporting multi-cloud environments traditionally required significant system design man-hours, the system reduces these man-hours and automatically accommodates non-functional requirements and multi-cloud environments by aligning the system engineer's desired cloud services and non-functional requirements into a common feature model.

Furthermore, as explained using FIG. 13 etc., the processor executes the feature model editing unit 103 to reflect the feature model edited on the user terminal in the generated user-edited feature model data stored in the computer. This allows the editing content desired by the user to be reflected in the user-edited feature model.

Furthermore, as explained using FIG. 11 etc., the processor executes the feature model conversion unit 102 to convert the generated feature model data by selecting the json format as the predetermined format. This makes it possible to edit feature models in the json format from among multiple other formats.

Furthermore, as explained using Figures 3, 5, etc., when the processor executes the feature model data generation unit 101, the non-functional requirements stored in the feature model basic data include definitions related to at least system availability, system performance and scalability, system operation and maintainability, system migration, system security, and system environment and ecology. This allows the feature model to be generated taking these non-functional requirements into consideration.

The present invention is not limited to the above-described embodiments, and in the implementation stage, the components may be modified and embodied within the scope of the gist of the invention, or multiple components disclosed in the above-described embodiments may be combined as appropriate.

1000 Cloud environment construction support system 100 Cloud environment construction support device 101 Feature model data generation unit 102 Feature model conversion unit 103 Feature model editing unit 201 Non-functional requirement list 202 Cloud data 203 Non-functional requirement selection data 204 Cloud selection data 205 Feature model basic data 206 Feature model data 207 Feature model data for user editing 300 User terminal 301 Display output unit 302 Input unit N Network

Claims (6)

A cloud environment construction support system that supports system construction of a cloud environment using a computer having a processor and a memory,
The processor:
Generate feature model data that configures a system in the cloud environment based on feature model basic data that defines a general configuration of cloud services and non-functional requirements provided by different cloud vendors, a non-functional requirement list that indicates means for realizing the non-functional requirements for each type of non-functional requirement, cloud data that stores options that can be taken by cloud services provided by the cloud vendor, non-functional requirement selection data that stores the non-functional requirements selected by a user, and cloud selection data that stores the cloud services selected by the user;
converting the generated feature model data into a predetermined format that is editable by a user;
When the user-edited feature model data converted into the predetermined format is output to a user terminal,
The non-functional requirements to be stored in the feature model basic data include at least definitions regarding system availability, system performance and scalability, system operation and maintainability, system migration, system security, and system environment and ecology.
A cloud environment construction support system characterized by: the processor reflects the features selected by editing on the user terminal in the generated user-edited feature model data stored in the computer;
2. The cloud environment construction support system according to claim 1. the processor converts the generated feature model data by selecting a json format as the predetermined format;
2. The cloud environment construction support system according to claim 1. A cloud environment construction support method performed by a cloud environment construction support system that supports system construction of a cloud environment using a computer having a processor and a memory, comprising:
Generate feature model data that configures a system in the cloud environment based on feature model basic data that defines a general configuration of cloud services and non-functional requirements provided by different cloud vendors, a non-functional requirement list that indicates means for realizing the non-functional requirements for each type of non-functional requirement, cloud data that stores options that can be taken by cloud services provided by the cloud vendor, non-functional requirement selection data that stores the non-functional requirements selected by a user, and cloud selection data that stores the cloud services selected by the user;
converting the generated feature model data into a predetermined format that is editable by a user;
When the user-edited feature model data converted into the predetermined format is output to a user terminal,
The non-functional requirements to be stored in the feature model basic data include at least definitions regarding system availability, system performance and scalability, system operation and maintainability, system migration, system security, and system environment and ecology.
A cloud environment construction support method comprising: reflecting the features selected by editing on the user terminal in the generated user-edited feature model data stored in the computer;
5. The cloud environment construction support method according to claim 4 . converting the generated feature model data by selecting a json format as the predetermined format;
5. The cloud environment construction support method according to claim 4 .