WO2017033441A1 - システム構築支援システム、方法および記憶媒体 - Google Patents
システム構築支援システム、方法および記憶媒体 Download PDFInfo
- Publication number
- WO2017033441A1 WO2017033441A1 PCT/JP2016/003775 JP2016003775W WO2017033441A1 WO 2017033441 A1 WO2017033441 A1 WO 2017033441A1 JP 2016003775 W JP2016003775 W JP 2016003775W WO 2017033441 A1 WO2017033441 A1 WO 2017033441A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- component
- definition
- field
- port
- information
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
Definitions
- the present invention relates to a system construction support system that supports system construction, a system construction support method, a storage medium in which a system construction support program is recorded, and the like.
- System componentization is a technology that enables a system to be efficiently defined as a set of coarser abstract components.
- a system In general, in order to configure a system, it is necessary to describe many detailed specific components. However, when looking down on a huge system or multiple systems, multiple similar components or collections may appear.
- a pattern of a group of components composed of one or more components abstracted so as to be reusable in this way is generally called a component.
- VM virtual machine
- MW middleware
- APP application
- the elements necessary for defining the VM are defined as VM components
- the elements necessary for defining the MW are defined as MW components
- the elements necessary for defining the APP are defined as APP components.
- the entire system by combining groups of components as needed.
- the whole system only having a different MW can be redefined with a slight change.
- Non-Patent Document 1 As a standard specification regarding component description for realizing such system componentization.
- Non-Patent Document 2 as a standard specification for defining information necessary for system deployment using a combination of components.
- the contents of processing for materializing and deploying the combined component are defined together, and the entity of the component is deployed by calling the defined processing. can do.
- the combination of the components can be combined with another component. In that case, in order to define the processing contents for deployment with respect to the new combination, the processing defined in the already combined components can be reused.
- Non-Patent Document 2 has a problem that it is necessary to define the processing content based on the relationship between components determined by the combination every time the combination of components is defined. For example, in the processing content necessary for the deployment of the system composed of the above-mentioned APP, MW, and VM, when the MW is replaced with a different type of component, the processing content to be executed may have to be changed. .
- FIG. 74 is an explanatory diagram showing an example of a system definition defined by a combination of components.
- Three rounded rectangles in the figure indicate components.
- the system of this example has three components: an APP1 component corresponding to a certain APP, a MW1 component corresponding to a certain MW, and a VM1 component corresponding to a certain VM.
- the double line has shown the connection between components.
- a rectangle in each component indicates a deployment process as a component corresponding to the component. For example, in the APP1 component in the figure, a component “app” corresponding to a corresponding application deployment process is defined.
- a component “package” corresponding to middleware package deployment processing (for example, installation processing of the middleware package resource provided by the configuration management system) is defined.
- a component “vm” corresponding to a VM deployment process (for example, a startup process) is defined in the VM1 component in the figure.
- the dotted arrows between the components in the figure indicate the dependency between the components.
- the dependency is a concept indicating the necessity in advance of the relationship between the two parties that in order to do something, it is necessary to do something else.
- the “app” component depends on the “package” component and the “vm” component, so the “package” component and the “vm” configuration before deploying (executing) the “app” component. Elements must be deployed.
- the “package” component depends on the “vm” component, the “vm” component must be deployed before deploying the “package” component. Due to these dependencies, a correct processing order of VM activation, MV installation, and APP activation is derived.
- FIG. 75 is an explanatory diagram showing another example of the system definition defined by the combination of components.
- FIG. 75 shows an example in which the system definition is made using the MW2 component corresponding to the MW when the MW different from the MW supported by the MW1 component in FIG. 74 is used.
- the dependency of the “app” component of the APP1 component is the component that the MW2 component has from the “package” component of the MW1 component, and the deployment process of the MW (for example, , Service processing activation, etc.).
- the component having the dependency relationship with the “vm” component of the VM1 component is changed from the “package” component of the MW1 component to the “package” component of the MW2 component.
- an object of the present invention is to improve the ease of system definition such that it is not necessary to add a setting corresponding to each combination of components.
- the system construction support system is a component definition that is information that defines a component that has at least one field that stores information about a component and is finally associated with one specific component.
- the component specification using the component definition can include the field definition that is the information of the field of the component to be defined and the setting definition that is the information related to the setting for the configuration element associated with the field
- a system definition input means for inputting a system definition including at least an assignment definition for assigning a component to a field of the component, and based on the system definition and the component definition, a specific configuration is specified for the field of the specified component.
- a setting granting means for assigning settings to the components constituting the target system by associating the elements and reflecting the setting contents defined for the fields in the components associated with the fields It is characterized by that.
- the information processing apparatus defines a component that has at least one field that stores information about a component and is finally associated with one specific component.
- a component definition that is information can include a field definition that is information on a field of a component to be defined, and a setting definition that is information on settings for a component associated with the field.
- the computer stores at least one field that stores information on the component and is finally associated with one specific component.
- a component definition that is information that defines a component that has a field definition that includes information on a field of a component that is a definition target, and a setting definition that is information on a setting for a component associated with the field
- the specified component is defined based on the system definition and the component definition.
- the ease of system definition can be improved.
- the block diagram which shows the structural example of the system construction assistance system of 1st Embodiment.
- Explanatory drawing which shows the example of a definition of Ubuntu component by GUI.
- Explanatory drawing which shows the example of a definition of Ubuntu component by JSON.
- Explanatory drawing which shows the example of the system definition input into the system definition input part 001.
- FIG. Explanatory drawing which shows the example of the system definition by JSON.
- Explanatory drawing which shows the example of the system configuration information which the system configuration output part 002 outputs.
- Explanatory drawing which shows the example of the system configuration information by JSON.
- Explanatory drawing which shows the other example of a system definition.
- Explanatory drawing which shows the other example of system configuration information.
- the flowchart which shows an example of operation
- Explanatory drawing which shows the example of a definition by GUI of Ubuntu component of 2nd Embodiment.
- Explanatory drawing which shows the example of definition by JSON of Ubuntu component of 2nd Embodiment.
- Explanatory drawing which shows the definition example by GUI of the Tomcat component of 2nd Embodiment.
- Explanatory drawing which shows the example of definition by JSON of the Tomcat component of 2nd Embodiment.
- Explanatory drawing which shows the other example of a definition by GUI of the Tomcat component of 2nd Embodiment.
- Explanatory drawing which shows the other example of a definition by JSON of the Tomcat component of 2nd Embodiment.
- the flowchart which shows an example of operation
- Explanatory drawing which shows the relationship between the component after the setting provision in 2nd Embodiment.
- Explanatory drawing which shows the example of data of a certain component after the setting provision in 2nd Embodiment.
- Explanatory drawing which shows the example of the system configuration information by GUI of 2nd Embodiment.
- Explanatory drawing which shows the example of the system configuration information by JSON of 2nd Embodiment.
- Explanatory drawing which shows the example of a definition by GUI of OS port of 3rd Embodiment.
- Explanatory drawing which shows the example of a definition by JSON of the OS port of 3rd Embodiment.
- Explanatory drawing which shows the example of the system definition of 3rd Embodiment.
- Explanatory drawing which shows the example of a definition of Ubuntu component by GUI of 3rd Embodiment.
- Explanatory drawing which shows the example of a definition of Tomcat component by GUI of 3rd Embodiment.
- Explanatory drawing which shows the example of data after system definition expansion
- Explanatory drawing which shows the example of expression by the GUI of the field and component of 4th Embodiment.
- Explanatory drawing which shows the example of the system definition by GUI of 4th Embodiment.
- Explanatory drawing which shows the example of a definition of OS port by GUI of 4th Embodiment.
- Explanatory drawing which shows the example of an OS port definition by JSON of 4th Embodiment.
- Explanatory drawing which shows the example of a definition of the WAS port by GUI of 4th Embodiment.
- Explanatory drawing which shows the example of a definition of the WAS port by JSON of 4th Embodiment.
- Explanatory drawing which shows the example of a definition by UGUI of the Ubuntu component of 4th Embodiment.
- Explanatory drawing which shows the example of definition by JSON of Ubuntu component of 4th Embodiment.
- Explanatory drawing which shows the example of a definition by the GUI of the Tomcat component of 4th Embodiment.
- Explanatory drawing which shows the example of a definition by JSON of the Tomcat component of 4th Embodiment.
- Explanatory drawing which shows the example of a definition by GUI of the WebApp component of 4th Embodiment.
- Explanatory drawing which shows the other example of the system definition in 4th Embodiment.
- Explanatory drawing which shows the other example of the system definition in 4th Embodiment.
- Explanatory drawing which shows the example of a definition of CentOS component by GUI of 4th Embodiment.
- Explanatory drawing which shows the example of a definition of CentOS component by JSON of 4th Embodiment.
- Explanatory drawing which shows the example of a definition of Jetty component by GUI of 4th Embodiment.
- Explanatory drawing which shows the example of a definition of Jetty component by JSON of 4th Embodiment.
- Explanatory drawing which shows the example of an expression of the relationship of the component by the GUI of 5th Embodiment, and a component.
- Explanatory drawing which shows the example of expression by JSON of the type definition of the component of 5th Embodiment.
- Explanatory drawing which shows the example of expression by JSON of the component of 5th Embodiment.
- Explanatory drawing which shows the example of definition by JSON of the WAS port of 5th Embodiment.
- the block diagram which shows the outline
- the block diagram which shows the other structural example of the system construction assistance system by this invention.
- Explanatory drawing which shows an example of the system definition prescribed
- Explanatory drawing which shows the other example of the system definition prescribed
- FIG. 1 is a block diagram illustrating a configuration example of a system construction support system according to the first embodiment.
- the system construction support system 100 according to the first embodiment is a system that provides a configuration definition function that converts a system configuration indicated by components into a configuration using specific components and outputs the configuration.
- a system definition expansion unit 101 and a component setting unit 102 are provided.
- the system definition expansion unit 101 is connected to the system definition input unit 001 and the component definition storage unit 003 indirectly or directly via a network or the like.
- the component setting unit 102 is connected to the system configuration output unit 002 indirectly or directly via a network or the like.
- the system definition development unit 101 and the component setting unit 102 are realized by a CPU or the like that operates according to a program, for example.
- the system definition input unit 001 inputs a system definition in which a configuration of a system to be constructed is expressed using a component defined by a component definition described later.
- the system definition input unit 001 may be, for example, various input devices such as a mouse and a keyboard, and an arbitrary server device that inputs information via a network.
- the system configuration output unit 002 embodies and outputs the system configuration indicated by the system definition input by the system definition input unit 001.
- the system configuration output unit 002 may be, for example, various output devices such as a display device, or any server device that outputs information via a network.
- the component has at least a field for storing information on the component.
- the field is a concept representing a frame for substituting component information.
- one specific component is finally associated with the field.
- Each field is preferably compatible with a plurality of types of components.
- the fact that one field can handle a plurality of types of components means that the components are abstracted, such as the extraction of common requirements of these components.
- the component definition includes a field definition that is information regarding the fields of the component to be defined.
- the component definition may include a setting definition that is information related to the setting for the component stored in the field, as necessary.
- the system definition input by the system definition input unit 001 more specifically includes at least a component designation using the component definition and an allocation definition related to the allocation of the component to the field of the component.
- Information is information that expresses the configuration of the system by specific components.
- the system construction support system 100 accepts the system definition in which the configuration of the target system is indicated using the component that is the abstracted component group pattern, and the specific component configures the system definition. It has a function to convert it into expressed information and output it.
- the information output by the system configuration output unit 002 may be referred to as system configuration information.
- the part definition storage unit 003 stores a part definition that is information defined as a reusable part by abstracting the constituent elements constituting the system.
- the component is a concept including the above-described components.
- a pattern of abstracted component groups (such as deployment processing in the above example) is also referred to as a component.
- the expression “component” is used as a concept that does not correspond to a specific component, for example, a port that is a concept that abstracts a terminal function for connecting components to each other.
- the component definition storage unit 003 is realized by a storage device, for example.
- the system definition expansion unit 101 receives a system definition from a user via the system definition input unit 001 and converts it into a specific system definition.
- the specific system definition is resolved (specifically specified) while the components associated with the fields of the components constituting the target system are resolved with respect to the input system definition.
- Information in which the relationship between components is resolved fields related to the fields of the components constituting the target system are specified).
- the component element setting unit 102 receives a specific system definition from the system definition expansion unit 101, and assigns settings such as attribute values and relationships with other component elements to the component elements constituting the target system. To do.
- the construction process of the target system is defined as the system configuration
- the target system is an IT system.
- an example is shown in which an arbitrary program unit included in the construction process of the IT system is used as a component and the construction of a system configured by a combination thereof is supported.
- the component is not limited to the construction process, Any unit constituting any system may be used.
- the component definition includes an identifier of the component definition (hereinafter referred to as id) and a field definition that is information on one or more fields of the component that is the definition target of the component definition.
- the field definition may have a name of the field definition, an initial value of the field (definition of an instance of a component stored in the field), and a setting definition.
- the setting definition is information (setting contents, setting method, etc.) regarding various settings for the component stored in the field.
- an attribute value set for the constituent element, a relationship between the constituent element and another constituent element, or the like can be designated.
- a relationship in particular, a dependency on another component can be specified.
- an identifier for identifying the attribute and a value for the attribute can be designated.
- FIG. 2 is an explanatory diagram showing a definition example of Ubuntu component by GUI (Graphical user interface).
- the Ubuntu component is assumed to be a component corresponding to “Ubuntu” which is a kind of operating system (OS).
- FIG. 2 shows an example of a component definition with an identifier “Ubuntu_1”.
- “Ubuntu_1” shown in FIG. 2
- two fields of a “file” field and a “boot” field are defined.
- “file” and “boot” represent names as ids of fields in components to be defined.
- the “file” field is assumed to be a field corresponding to a component related to file construction on “Ubuntu”, such as a process for creating a file.
- the “boot” field is assumed to be a field corresponding to a component related to booting “Ubuntu” such as OS boot processing.
- the value of the attribute “mode” of the component stored in the field is set to “644”, and the component stored in the field is “boot” "It is specified that the component stored in the field has relevance.
- the component “boot1” is specified as the initial value of the field.
- components are indicated by rounded rectangles as an example of expression by component definition GUI.
- the field is indicated by a dotted rectangle.
- the constituent elements are indicated by solid rectangles.
- the attribute value is indicated by a balloon with a field. Relevance is indicated by dotted arrows from the field to other fields.
- a character string in which a component is attached to the upper right inside the rounded rectangle indicates the id of the component definition.
- a character string attached outside the dotted rectangular frame representing the field indicates the id (name) assigned to the field.
- the component definition can be described in a text format by using a language such as JSON (Java Script (registered trademark) Object Notification) other than GUI notation.
- JSON Java Script (registered trademark) Object Notification
- FIG. 3 is an explanatory diagram showing a definition example of Ubuntu component by JSON.
- the example shown in FIG. 3 is an example in which the component definition shown in FIG. 2 is defined by JSON.
- FIG. 3 shows an example in which the system definition by JSON includes three elements of “type” element, “id” element, and “field” element.
- the “type” element defines what the series of information is, and in this example, “component definition” indicating that it is a component definition is designated.
- the “id” element defines the id of the component definition. In this example, “Ubuntu_1” is defined.
- the “field” element defines a field of a component defined by the component definition. In this example, two fields of a “file” field and a “boot” field are defined.
- the initial value of the “file” field is empty, and the component “boot1” is defined in the “initial value” of the “boot” field.
- a component having id “boot1” is defined as the “value” to be assigned to the field.
- the “value” element in the “initial value” definition of the field is defined according to the “type” element in the initial value definition and the content of the type.
- the “value” element is also defined.
- a component is defined as the content of the “value” element.
- the component id may be designated as shown in FIG.
- “boot1” is defined as such an id.
- FIG. 3 shows an example including an “attribute” element and a “dependency” element as the “setting” element of the field definition.
- the “setting” element of the “file” field includes an “attribute” element and a “dependency” element.
- nothing is defined in the “setting” element of the “boot” field.
- the “attribute” element in this example defines the attribute value of the component stored in the field. For example, an attribute identifier and attribute value pair may be specified as the definition method. .
- the “dependency” element defines the dependency of the component stored in the field on other components, and as a method of defining the component, You may specify in the format showing the reference of the other field in which the said component is stored. In this example, the field name to which the dollar mark “$” is added represents the reference of the field.
- the component definition as described above may be recorded in a readable manner in an external component definition storage unit 003 or the like in advance.
- a developer who develops a common model defines a model that is commonly used across multiple projects in advance as a pattern of component groups, and defines the component definition as information that indicates such a definition. You may memorize
- FIG. 4 is an explanatory diagram showing an example of the system definition input to the system definition input unit 001.
- FIG. 4 is an example in which the system definition is expressed by GUI.
- the system definition may include, for example, an identifier (name) of the system indicated by the system definition, information specifying one or more components constituting the system, and information regarding various settings for the components. .
- the “system1” has a “ubuntu1” component that is one of the component instances defined by the component definition “Ubuntu_1”, and the “ubuntu1” Information relating to the substitution of components for the “file” field of the “component” is specified.
- the “file1” component is assigned to the “file” field of the “ubuntu1” component, and the “file1” component is ““ file1 ”as the value of the“ name ”attribute. .txt ”is specified.
- system definition can be defined by JSON as well as the component definition.
- FIG. 5 is an explanatory diagram showing an example of system definition by JSON.
- the example shown in FIG. 5 is an example in which the system definition shown in FIG. 4 is defined by JSON.
- the system definition shown in FIG. 5 includes three elements: a “type” element, an “id” element, and a “component” element.
- “system definition” indicating that the series of information is system definition is specified in the “type” element.
- the “id” element the id of the system defined by the system definition is specified.
- component a component included in the system defined by the system definition is designated. In this example, only one “ubuntu1” component is specified.
- information on the components may be listed in the “component” element in association with the component names.
- id is specified as an identifier of a component definition that defines the state of the component.
- Ubuntu_1 is specified.
- assignment assignment of a component to a field of the component indicated by the component definition is defined.
- FIG. 6 is an explanatory diagram showing an example of system configuration information output by the system configuration output unit 002.
- FIG. 6 shows a display example of system configuration information by GUI.
- FIG. 6 is also an example of a component generation result based on the system definition shown in FIG.
- the system configuration information includes, for one or a plurality of components constituting the target system, information specifying these components, and information on the relationship with attribute values and other components. It may be what was done.
- the target system “system1” includes two components “file1” and “boot1”, and the “file1” component has a “name” attribute value of “file1.txt”.
- the value of the “mode” attribute is “644”, and it is indicated that the “boot1” information element has dependency.
- FIG. 7 is an explanatory diagram showing another example of the system configuration information output by the system configuration output unit 002.
- FIG. 7 shows an example of system configuration information by JSON.
- FIG. 7 is also an example of a component generation result based on the system definition shown in FIG.
- the system definition may define a system configuration other than the construction method of the system, and the component definition may define relevance other than dependency as a relevance definition. Also good.
- FIG. 8 is an explanatory diagram showing another example of the system definition.
- FIG. 9 is an explanatory diagram showing an example of system configuration information based on the system definition shown in FIG. Both FIG. 8 and FIG. 9 are display examples using the GUI.
- the target system has a “dBApplication” component that is one of the component instances defined by the component definition “DBApplication”, and a component “logic1” is included in the “logic” field. It is defined to be assigned.
- the “dBApplication” component defined by the component definition has two fields, “logic” field and “dBConnection” field. It can be seen that the component initialized with “dBConnection1” and stored in the “dBConnection” field is related to the component stored in the “logic” field.
- the relationship between the component stored in the “dBConnection” field and the component stored in the “logic” field is that the specific processing function expressed as the “logic” field is expressed as the “dBConnection” field.
- the usage relationship between functions and objects is simply derived.
- the relationship between the constituent elements may indicate a usage relationship.
- FIG. 10 is a flowchart showing an example of the operation of the system construction support system 100 of this embodiment.
- the system definition expansion unit 101 when the system definition expansion unit 101 first receives a system definition from the system definition input unit 001 (step S11), it reads it. Then, if there is a component definition referred to by the system definition, the system definition expansion unit 101 acquires the component definition from the component definition storage unit 003, expands the system definition, and resolves the components stored in each field. A specific system definition is generated (step S12). The specific system definition generated in step S12 is transmitted to the component setting unit 102.
- the component setting unit 102 sets the setting defined in the field storing the component corresponding to the field included in the specific system definition received from the system definition development unit 101. It grants while making it concrete (step S13).
- the specificization of the setting is, for example, a specific constituent element based on the dependency or initial value specified for the field based on the constituent element information stored in the other field. This is the process of setting it up.
- the component setting unit 102 outputs the system configuration information indicating the configuration of the system including the configuration elements to which the setting is given to the system configuration output unit 002 (step S14).
- step S12 and step S13 will be described in more detail.
- FIG. 11 is a flowchart showing a more detailed operation example of the system definition expansion process (step S12 in FIG. 10) by the system definition expansion unit 101 of the present embodiment.
- the system definition expansion unit 101 reads the system definition received from the system definition input unit 001 (step S121), and if a location for specifying a component is found in the system definition (Yes in step S122), the definition is converted into a component. Obtained from the definition storage unit 003 or the like (step S123). Then, based on the obtained component definition, a value (component) is assigned to the component to be embodied (step S124).
- “Ubuntu_1” is specified as the definition of the “ubuntu1” component, and is acquired from the component definition storage unit 003.
- the component definition storage unit 003 may have a function of receiving an id of a component definition and returning a corresponding component definition, and may be realized by an http server, a file server, or a DB server as an example.
- the system definition expansion unit 101 substitutes the value.
- the “file1” component is assigned to the “file” field defined in the system definition that is the reference source of the component definition, and the “boot” defined in the component definition
- the “boot1” component is assigned to the “field”, and the resulting component is the “ubuntu1” component.
- the system definition expanding unit 101 outputs the materialized system definition (step S125) and ends the system definition expanding process.
- FIG. 12 is an explanatory diagram showing an example of a specific system definition as output information after system definition expansion by JSON.
- system definition 2 is set in the “type” element to indicate a specific system definition.
- attribute values and dependency settings are still set for the component fields.
- FIG. 13 is a flowchart showing a more detailed operation example of the component setting process (step S13 in FIG. 10) by the component setting unit 102 of the present embodiment.
- the component setting unit 102 executes the following three steps for all fields included in the specific system definition generated by the system definition expansion unit 101. That is, first, the component stored in the target field is acquired (step S131), and the setting set in the field is assigned to the component (step S132). In step S132, for example, an attribute value or the like is set for the component.
- the acquisition of configuration elements and the assignment of settings to configuration elements specifically, generate or acquire definition information of the configuration elements in the target system, and reflect the settings set in the field in the definition information (Assignment of values, etc.) may be used.
- the component setting unit 102 converts the designation of the reference destination into the id of the component stored in the reference destination field, The setting contents are reflected (step S133).
- the component while using an abstracted component group pattern called a component, the component is shared as information about the component supported by the component as definition information of the component.
- the setting attribute value and dependency between other components
- the setting with reusability among the settings for each component can be confined as component information.
- the setting for the content component is defined, and after the combination of the components is determined, Since it has a mechanism that reflects the settings set in the frame for the contents of the contents, it is possible to save the trouble of resetting the same settings every time the combination is changed. In this way, by using the component settings that have already been defined, even if the combination of the component elements is changed, it is not necessary to add settings for the related component elements, and the system definition is facilitated.
- FIG. 14 is an explanatory diagram showing another example of the system definition.
- the example shown in FIG. 14 has a “ubuntu1” component defined by a component definition “Ubuntu_1”, similarly to “system1”.
- the components assigned to the “file” field of the “ubuntu1” component are different.
- a component having id “file2” is assigned, and the component has a value “file2.py” in the “name” attribute and a value “755” in the “mode” attribute. It is defined.
- system configuration information as shown in FIG. 15 is output.
- the system “system2” includes a “boot1” component and a “file2” component, and the “file2” component has “file2.py” as a “name” attribute. And “755” as the “mode” attribute and dependency on the “boot1” component.
- the system configuration information for the system “system1” includes the “boot1” component, the “file1” component, and the “file1” component.
- the value “664” as the “mode” attribute value and the dependency information on “boot1” are automatically added. In this way, more information can be included in the system definition simply by specifying the component definition and the specific specification of the system, and the amount of description required for the output amount can be reduced. I understand that.
- Embodiment 2 a second embodiment of the present invention will be described.
- the configuration of the system construction support system 100 in the second embodiment is the same as the configuration of the first embodiment except that the operations of the system definition expansion unit 101 and the component element setting unit 102 are different.
- the same symbols are attached to the same parts as those in the first embodiment, and the description thereof is omitted.
- the component definition in addition to the component definition, includes a port definition that is information for defining a port, the component definition can include a port specification, and the system definition can include a wire specification.
- a port is a concept representing a terminal for defining a connection relationship between components
- a wire is a concept representing a connection between ports.
- the system definition expansion unit 101 and the component element setting unit 102 of the present embodiment are different from the first embodiment in that they handle the information of these ports and wires.
- a port has one or more fields, similar to a component.
- the field that the port has is for storing information on the components that are required when the component that includes the port connects another component.
- the port definition includes an id of the port definition and a field definition that specifies one or more fields of the port defined by the port definition.
- FIG. 16 is an explanatory diagram showing an example of definition of an OS port by GUI according to the present embodiment.
- the OS port is assumed to be an abstraction of a connection process for connecting a component generally corresponding to the OS, such as a Ubuntu component, to another component.
- FIG. 16 shows an example of a port definition with an id “OS_2”.
- the port definition “OS_2” shown in FIG. 16 has two fields, a “file” field and a “package” field.
- the “file” field is assumed to be a field corresponding to a component related to file construction, such as a process for creating a file necessary for connection with other components on a general OS.
- the “package” field assumes a field corresponding to a packaged resource or the like provided by a middleware configuration management system operating under the OS. Note that the setting definition and the initial value are not specified in these two fields in the port definition.
- the port in the port definition is expressed in the base form as an example of expression by GUI.
- FIG. 17 is an explanatory diagram showing an example of OS port definition by JSON in this embodiment.
- the example shown in FIG. 17 is an example in which the port definition shown in FIG. 16 is defined by JSON.
- the port definition of the OS port by JSON is basically the same as the component definition shown in FIG. 3 except that “port definition” indicating port definition is specified in the “type” element.
- the “id” element specifies an identifier of the port definition, and the “field” element is defined by the port definition.
- the configuration may be such that information on the fields of the ports to be listed is listed.
- the component definition includes the id of the component definition, the definition of the field of the component defined by the component definition, and the designation of the port of the component defined by the component definition. May be.
- the wire may always connect a set of ports defined by the same port definition.
- the ports may be divided into two types of ports, service ports and reference ports.
- the service port is a concept that indicates a terminal that accepts a connection
- one reference port is a concept that indicates a terminal that requests a connection.
- the wire may be a port defined by the same port definition, and a pair of a service port and a reference port may be connected, and service ports or reference ports may not be connected.
- a reference to another field can be designated as a type in the initial value definition of the field. This is in order to cover necessary settings by propagating components between fields of different components in the process of connecting the components.
- FIG. 18 is an explanatory diagram showing an example of the system definition in the present embodiment.
- FIG. 18 shows an example of system definition by GUI.
- the target system “system2” is an instance of a component defined by the component definition “Tomcat_2” and a component instance defined by the component definition “Ubuntu_2”. It can be seen that it has a certain “ubuntu2” component. It can also be seen that the “os” reference port of the “tomcat2” component and the “os” service port of the “ubuntu2” component are connected by a wire.
- “tomcat2” which is an example of Tomcat component, assumes a component corresponding to “Tomcat”, which is a kind of Web application.
- the component definitions “Tomcat_2” and “Ubuntu_2” in this example will be described later.
- a service port is represented by a mountain shape on one of the opposing sides, the other is a valley shape (hereinafter referred to as an arrow feather shape), and a reference port is represented by a home base type.
- the wire is expressed by a double line.
- FIG. 19 is an explanatory diagram showing an example of system definition by JSON in this embodiment.
- the example shown in FIG. 19 is an example in which the system definition shown in FIG. 18 is defined by JSON.
- the system definition shown in FIG. 19 includes a “wire” element in addition to a “type” element, an “id” element, and a “component” element.
- the “wire” element includes a “connection source” element for designating a connection source port and a “connection destination” element for designating a connection destination port.
- “$ ubuntu2.os” is specified in the “connection source” element
- “$ tomcat2.os” is specified in the “connection destination” element.
- the user specifies a component using the component definition already defined in this way, and then specifies that the ports of the component are connected using wires, so that multiple components can work together. Even such a system can be easily defined.
- FIG. 20 is an explanatory diagram showing a definition example by the GUI of the Ubuntu component in the present embodiment.
- FIG. 20 shows an example of a component definition with an id “Ubuntu_2”.
- the component defined by the component definition has three fields of “file” field, “package” field, and “boot” field, and the port definition “ It is defined that it has a service port “” port defined by “OS_2”.
- references to the “file” field and the “package” field of the “os” port are respectively defined.
- the initial value definition of the “boot” field it is defined that a “boot2” component is newly created.
- the “file” field and the “package” field define the dependency on the “boot” field.
- GUI expression example the definition of a value by referring to a field is expressed by a solid line arrow from a black circle attached to a reference side field to a reference destination field.
- FIG. 21 is a definition example by USON of the Ubuntu component in this embodiment.
- the example shown in FIG. 21 is an example in which the component definition shown in FIG. 20 is defined by JSON.
- the component definition shown in FIG. 21 includes a “service port” element for designating a service port in addition to a “type” element, an “id” element, and a “field” element.
- one “os” port which is a port defined by the port definition “OS_2”, is specified in the “service port” element.
- the “type” is “reference”
- “$” is the “reference destination”.
- FIG. 22 is a definition example using the GUI of the Tomcat component in this embodiment.
- FIG. 22 shows an example of a component definition with an id “Tomcat_2”.
- the component defined by the component definition has two fields, a “configFile” field and a “package” field.
- the reference port has an “os” port defined by the port definition “OS_2”.
- the “tomcatConfig2” component element and the “tomcatPackage2” component element are newly defined in the initial value settings of the “configFile” field and the “package” field of the component defined by “Tomcat_2”.
- FIG. 23 is an explanatory diagram showing a definition example by JSON of the Tomcat component in the present embodiment.
- the example shown in FIG. 23 is an example in which the component definition shown in FIG. 22 is defined by JSON.
- the component definition shown in FIG. 23 includes a “reference port” element for designating a reference port in addition to a “type” element, an “id” element, and a “field” element.
- the “os” port defined by the port definition “OS_2” is defined in the “reference port” element.
- the “tomcatConfig2” component element and the “tomcatPackage2” component element are newly defined in the initial value settings of the “configFile” field and the “package” field of the component defined by “Tomcat_2”. Furthermore, the “configFile” field defines a dependency on the “package” field. In addition, for the “file” field and “package” field in the “os” port, as settings related to the substitution of the value of the field, the “configFile” field and the “package” field of the main body component having the port are included. It is defined that the contents are referred to.
- FIG. 24 is an explanatory diagram showing another definition example of the Tomcat component in the present embodiment.
- FIG. 24 shows an example of component definition by GUI.
- the component definition “Tomcat_2x” shown in FIG. 24 the component of the main body does not have a direct field, but a value is directly assigned to the field of the reference port of the component of the main body. In this case, the component can be interpreted as having a field indirectly through its own port.
- the assignment of a value to a field in the reference port is specified by a new definition of a component, not by referring to another field.
- the dependency on the “package” field in the same port is specified for the “tomcatConfig2” component stored in the “file” field in the “os” port.
- the dependency can be set by directly specifying the component in the field.
- other components are substituted when the component is reused. If the original component is overwritten, it will be lost. If you want to keep the same dependency in the overwritten component, use the “package” field reference in the same port for the “file” field in the “os” port. It is sufficient to specify the dependency on the component stored in.
- FIG. 25 is an explanatory diagram showing another definition example of Tomcat components by JSON in this embodiment.
- the example shown in FIG. 25 is an example in which the component definition shown in FIG. 24 is defined by JSON.
- FIG. 25 shows an example of specifying the dependency on the component stored in the “file” field in the “os” port by using the reference of the “package” field in the same port. Is shown, but it is also possible to specify the “tomcatpackage2” component directly. In this case, for example, “dependency”: [“tomcatpackage2”] may be specified, or “#” is introduced as a symbol indicating that the component is directly specified, and “# tomcatpackage2” You may specify as follows.
- FIG. 26 is a flowchart showing an example of the operation of the system construction support system 100 of this embodiment.
- the same operations as those in the first embodiment are denoted by the same symbols, and the description thereof is omitted.
- a system definition expansion process (step S22) for generating a specific system definition by the system definition expansion unit 101 and a component element setting process (step S23) by the component element setting unit 102 are the first. Different from the operation of the embodiment.
- FIG. 27 is a flowchart showing a more detailed operation example of the system definition expansion process by the system definition expansion unit 101 of this embodiment.
- the system definition expansion unit 101 connects the ports according to the contents of the component definition reading process (step S221) and the wire definition after reading all the components (step S222). Is different from the first embodiment.
- linking ports means that it is possible to transfer field values between ports to be linked in addition to holding that there is a connection relationship between the ports to be linked as configuration information. More specifically, it refers to performing a process of propagating (transferring) component information to a destination port in accordance with the system definition, component definition, and port definition.
- FIG. 28 is a flowchart showing a more detailed operation example of the component definition reading process (step S221 in FIG. 27) by the system definition expanding unit 101 of this embodiment.
- the system definition expanding unit 101 reads this from the component definition storage unit 003 or the like (step S2211). If there is a port definition referred to by the component definition (Yes in step S2212), this is read from the component definition storage unit 003 or the like (step S2213). Then, a specific system definition is generated by substituting values (information elements) in accordance with the component definition and port definition for each field of the component indicated by the system definition, and embodying the information element included in the component. (Step S2214).
- the system definition expansion unit 101 acquires “Ubuntu_2” and “Tomcat_2”, which are component definitions included in the “system2” system indicated by the system definition. Further, the system definition expansion unit 101 acquires the port definition in response to the reference of the “OS_2” port definition as the port definition of the “os” port in these component definitions. Further, based on the acquired port definition, the system definition development unit 101 assigns values (components) to the fields of the component and the port.
- substitution definition the value defined at the reference destination is substituted.
- substitution of values (components) by reference to the “configFile” field and the “package” field of the main body component is defined in the “os” reference port of the “tomcat2” component of “system2”.
- the “os” port defined by the port definition “OS_2” is assigned a reference to the “tomcat2.configFile” field of the main component in the “file” field and “tomcat2.package” in the “package” field.
- the reference to the “field” is assigned, it is set as the “os” reference port of the “tomcat2” component.
- the system definition expanding unit 101 connects the ports according to the wire definition included in the system definition (step S222).
- the port connection processing the values stored in each field in the reference port are propagated (transferred) to the field in the corresponding service port. As a result, two ports connected by a wire are combined into one.
- the system definition expansion unit 101 sets the value of the field of the “os” reference port that is the connection source as the connection destination based on the wire setting included in the system definition in the port connection process. Move to the value of the corresponding field of the “os” service port.
- the values stored in the “file” and “package” fields of the “os” reference port of the “tomcat2” component that is the connection request source are the “os” service port of the “ubuntu2” component that is the connection request destination.
- step S125 when the system definition expansion unit 101 completes the port connection processing for all the wires, the system definition expansion unit 101 outputs a specific system definition (step S125), and ends the system definition expansion process.
- FIG. 30 is an explanatory diagram showing the relationship between fields after port connection.
- FIG. 30 based on the system definition described above, only the fields in the specific system definition after port connection are extracted, and their relationship is shown.
- the value of the “os” reference port field of the “tomcat2” component is directly reflected in the corresponding field of the “os” service port of the “ubuntu2” component at the connection destination. Although omitted, you may leave the “os” reference port of the “tomcat2” component.
- a “tomcat2.os.file” field is provided between the “tomcat2.configFile” field and the “ubuntu2.os.file” field, and the reference destination of the “ubuntu2.os.file” field is set to “tomcat2 .os.file ”field.
- the multi-level reference setting is resolved in the next component setting process, so that the component corresponding to the series of fields in the reference relationship is the final reference destination. It is embodied in the value stored in the field.
- FIG. 31 is a flowchart showing a more detailed operation example of the component setting process (step S23 in FIG. 26) by the component setting unit 102 of this embodiment.
- the component setting unit 102 executes the same processing as in the first embodiment for all fields in the specific system definition generated by the system definition expansion unit 101.
- the present embodiment is different in that the component associated with each field may be a copy by reference.
- the component setting unit 102 of the present embodiment first checks the value stored in each field, and simply acquires it if the value directly specifies the component. On the other hand, if the value specifies a reference to another field, duplicate the component information stored in the referenced field, store it in the referenced field, and finally the target field The information stored in is acquired (step S231).
- the value stored in the reference field further specifies a reference to another field
- the component information stored in the other field that is the reference destination is further copied.
- the process of storing in the reference source field is recursively performed, and the component information stored in the final reference destination field is stored, and the component is stored in each reference source field.
- the duplication of the component element may have, for example, an identifier generated so as not to overlap appropriately and an element of an identifier of the duplication source component element as component element information.
- FIG. 32 is an explanatory diagram showing the relationship between fields after resolving the constituent elements by reference from the specific system definition shown in FIG. 32, a component that does not have an id inside (a solid-line rectangle in the figure that is shaded) is a duplicate of the component indicated by the arrow.
- the solid arrows drawn from “1” to “component” or from “duplicate” to “replica” indicate the component that is the source of the duplication.
- FIG. 33 is an explanatory diagram showing an example of data of a certain component after reference resolution.
- FIG. 33 shows an example of component information stored in the “file” field (ie, “ubuntu2.os.file” field) of the “os” service port of the “ubuntu2” component in FIG. Yes.
- the “file” field contains the identifier of the component element of the copy source (in this example, Information including “tomcatConfig2”) and a temporary identifier (“tomcatConfig2_1” in this example) of the copied component stored in the field may be held.
- the name of the original component + “_” (underscore) + a number is added as a temporary identifier of the copied component to express that the component is a duplicate. Yes.
- the component setting unit 102 assigns a setting to the component stored in the field or the copied component based on the information (setting definition) regarding the setting for the component held by each field ( Step S232).
- FIG. 34 is an explanatory diagram showing the relationship between the components after the setting is given based on the relationship between the fields shown in FIG. As shown in FIG. 34, the contents set in the field are given as they are to the components stored in the field. In FIG. 34, the name given to the upper part of the shaded rectangle representing the duplicate of the component indicates the id of the duplicate.
- FIG. 35 is an explanatory diagram showing an example of data of a certain component after the setting is given in the present embodiment. The example shown in FIG. 35 is an example of component duplication information stored in the “file” field (ie, “ubuntu2.file” field) of the “ubuntu2” component in FIG.
- the reference definition in the setting for the component in the field is specified in the component definition that defines the field, it is only necessary to search the reference destination using the component in which the reference is defined as a scope.
- the dependency reference definition defined for the “file” field of the “ubuntu2” component is “$ boot”.
- the “boot” field may be searched for within the “ubuntu2” component.
- the “ubuntu2.boot” field is found here.
- the configuration element setting unit 102 resolves the reference in the setting for the configuration element in the field, and the configuration element that is the source of all the settings given to the replication (Step S233).
- the component setting unit 102 performs an aggregation process for aggregating the settings made for the duplication of the component to the duplication source. For example, it is assumed that, as a result of setting the information based on the information shown in FIG. 32, the relationship between the components as shown in FIG. 34 is established. In this case, the dependency on the component “boot2” stored in the “ubuntu2.boot” field of the replication “tomcatConfig2_2” stored in the “ubuntu2.file” field is the original replication source. Centralized in the “tomcatConfig2” component.
- FIG. 36 is an explanatory diagram showing an example of system configuration information by GUI
- FIG. 37 is an explanatory diagram showing an example of system configuration information by JSON.
- 36 and 37 both show the same configuration.
- “system2” includes three components “tomcatConfig2”, “tomcatPackage2”, and “boot2”
- the “tomcatConfig2” component includes the “tomcatPackage2” component and “boot2”. It can be seen that each “component has a dependency, and the tomcatPackage2” component has a dependency on the “boot2” component.
- all the settings defined by a plurality of components can be collectively given to the component, and the definition related to the assignment of the component to the field is abstracted so that it can be reused.
- the user can define the system configuration more efficiently just by defining the wire. More specifically, in the present embodiment, it is possible to specify that it is a reference to another field in the setting definition related to the assignment of the component element to the field (additional abstraction element is added), Setting contents such as attribute values and dependencies set for the field can be propagated based on the reference relationship. In addition, such a reference relationship is determined only after the combination of components is determined. In this embodiment, the reference relationship is set using a field, and the abstract parts such as ports and wires are used.
- FIG. Next, a third embodiment of the present invention will be described.
- the configuration of the system construction support system 100 in the third embodiment is the same as the configuration of the second embodiment except that the operations of the system definition expansion unit 101 and the component element setting unit 102 are different.
- the same parts as those in the first and second embodiments are denoted by the same symbols, and the description thereof is omitted.
- This embodiment is different from the second embodiment in that types of accept field and provide field are provided for the fields of the port.
- the accept field is a field that handles the propagation of the component from the reference port to the service port. For this reason, with respect to the accept field, except for propagation due to connection between ports, substitution of values is accepted only from components having the port as a reference port.
- the provide field is a field that handles propagation of components from the service port to the reference port. For this reason, with respect to the provider field, except for propagation by connection between ports, substitution of values is accepted only from components having the port as a service port.
- the system definition expansion unit 101 and the component element setting unit 102 according to the third embodiment are different from the second embodiment in that definition information corresponding to these types is handled.
- FIG. 38 is an explanatory diagram showing a definition example of an OS port by GUI according to the present embodiment.
- FIG. 38 shows an example of the port definition to which the identifier “OS_3” is attached.
- the fields defined by the port definition include two accept fields, “file” field and “package” field, and one provide field, “boot” field. Is defined. In this example, the dependency on the “boot” field is defined for each of the “file” field and the “package” field.
- the accept field is represented by an arrow feather with the right side convex
- the provide field is represented by an arrow feather with the left side convex.
- FIG. 39 is an explanatory diagram showing a definition example of an OS port by JSON in the present embodiment.
- the example shown in FIG. 39 is an example in which the port definition shown in FIG. 38 is defined by JSON.
- the port definition of the OS port by JSON is that the “type” element is “port definition”, the “field element” is the “accept field” element, and the “provide field” element. It can be basically the same as the component definition except for the points.
- the contents of the port definition in this example are the same as those in FIG. That is, in the port definition shown in FIG.
- the port definition is the “type” element
- OS_3 is defined as the “id” element
- file field
- packet is defined as the “accept field” element. It is defined that a “boot” field is provided as a “provide field”.
- the “file” field and the “package” field which are accept fields, are assigned values from the corresponding fields of the component having the port as a reference port.
- a value is supplied to a “boot” field that is a provide field from a corresponding field of a component having the port as a service port.
- a component having a port defined by the port definition as a service port is assumed to have a host relationship with a component having the port defined by the port definition as a reference port. ing.
- the relationship between the fields in the port defined in the component in the second embodiment can be defined in the port.
- the definition related to the dependency can be reused together with the port.
- FIG. 40 is an explanatory diagram illustrating an example of a system definition using a GUI according to the present embodiment.
- the target system “system3” is an instance of “tomcat3” which is an instance of a component defined by the component definition “Tomcat_3” and an instance of a component defined by the component definition “Ubuntu_3”. It can be seen that there is a certain “ubuntu3” component, and the “os” reference port of the “tomcat3” component and the “os” service port of the “ubuntu3” component are connected by a wire.
- the component definitions “Tomcat_3” and “Ubuntu_3” will be described later.
- FIG. 41 is an explanatory diagram illustrating a definition example of a Ubuntu component using a GUI according to this embodiment.
- FIG. 41 shows an example of a component definition to which an identifier “Ubuntu_3” is attached.
- the component defined by the component definition has three fields of a “file” field, a “package” field, and a “boot” field, and further, a port definition “ It can be seen that one port defined by “OS_3” has an “os” port.
- references to the “file” field and the “package” field of the “os” port are respectively defined.
- the initial value definition of the “boot” field it is defined that a “boot3” component is newly created, and the component that is the main component for the “boot” field of the “os” port.
- a reference to the “boot” field is defined.
- FIG. 42 is a definition example of Tomcat component by GUI in this embodiment.
- FIG. 42 shows an example of the component definition to which the identifier “Tomcat_3” is attached.
- the component defined by the component definition has a “configFile” field and a “package” field, and further, as a reference port, one “1” defined by the port definition “OS_3”. It can be seen that it has an “os” port.
- the “tomcatConfig3” component and the “tomcatPackage3” component are newly defined in the initial value settings of the “configFile” field and the “package” field, respectively.
- the “configFile” field defines a dependency on the “package” field.
- the “boot” field which is the provide field in the “os” port in this example, is assigned to the value from the main body component because the port is included in the component defined by the component definition “Tomcat_3” as the reference port.
- the field is not used because it is not accepted and the value is not substituted even when the port is connected using a wire (the port is a reference port and is a position to be transferred to another service port). Is omitted.
- FIGS. 40 to 42 are examples of definitions that have the same configuration after deployment, except for the definitions shown in the second embodiment and id.
- the component definition “Ubuntu_3” shown in FIG. 41 defines a reference to the “boot” field of the main component as a setting relating to the substitution of the value of the field for the “boot” field in the OS port. This is different from the component definition “Ubuntu_2” in the second embodiment in that the dependency between the fields of the component is omitted.
- FIG. 43 is an explanatory diagram showing the relationship between fields after port connection.
- FIG. 43 based on the system definition shown in FIG. 40, fields in a specific system definition after connection of ports are extracted and their relationship is shown.
- the dependency from the “ubuntu2.file” field and the “ubuntu2.package” field to the “ubuntu2.boot” field is set (see FIG. 30).
- the example is greatly different in that the dependency on the “os.boot” field is set from the “os.file” field and the “os.package” field.
- the final system configuration information in the third embodiment is the same as the system configuration information in the second embodiment shown in FIG.
- the system definition refers to, when a specific system definition is generated by assigning values to each of the fields of the component indicated by the system definition, whether the target port is a reference port Depending on the service port, the assignment of values to the fields of the port is restricted. For example, in the “file” field and “package” field of the “os” reference port of the “tomcat3” component of “system3”, references to the “configFile” field and the “package” field of the main body component are defined, respectively.
- the system definition expansion unit 101 of this example substitutes a value from a main body component having the “os” port as a reference port. to approve.
- the “file” field is assigned a reference to the “tomcat3.configFile” field of the main component
- the “package” field is assigned a reference to the “tomcat3.package” field.
- the port instance “os” port by the port definition “OS_3” is set as the “os” reference port of the “tomcat3” component.
- the initial value setting by reference from the “ubuntu3.os.file” field is defined for the “ubuntu3.file” field of “system3”, and the “ubuntu3.package” field
- the initial value setting by reference from the “ubuntu3.os.package” field is defined.
- the port definition “OS_3” port instance “os” port which has a dependency on the “boot” field, references to the “file” and “package” fields, and the “ubuntu3.boot” field
- the “os” port having the “boot” field substituted with “” is set as the “os” service port of the “ubuntu3” component. Subsequent port connection processing is the same as in the second embodiment.
- the setting relating to the relationship between the component of a component having a port as a reference port and the component of a component having a service port (for example, the “file” field of the “os” port) And the dependency on the “boot” field for the “package” field can be defined in the port, and this can be reused together with the port, so that the system definition can be described more efficiently. That is, reusability can be further improved by completing the abstracted dependency setting in the port.
- Embodiment 4 FIG. Next, a fourth embodiment of the present invention will be described.
- the configuration of the system construction support system 100 in the fourth embodiment is the same as that of the third embodiment except that the operations of the system definition expansion unit 101 and the component element setting unit 102 are different.
- the same parts as those in the first to third embodiments are denoted by the same reference numerals, and description thereof is omitted.
- This embodiment is different from the first to third embodiments in that the type of component is handled.
- the type of component element a specific component that is a specific component having all the information elements necessary for the purpose of the component, and an abstract configuration having only some of the information elements It handles two types of abstract components.
- the fields and components of this embodiment have “type name” information. Then, the system definition development unit 101 and the component element setting unit 102 perform processing according to these “type names”.
- FIG. 44 is an explanatory diagram showing a representation example of fields and components using a GUI according to the present embodiment.
- FIG. 44 shows an example in which two types of “OSFile” type and “FileUbuntu” type are set in the “file” field.
- the “file” field of the “OSFile” type is an example of an abstract component type intended to be a “file” component for various types of OSs
- the “file” field of the “FileUbuntu” type is This is an example of a specific component type intended to handle a “file” component for a specific OS called “Ubuntu”.
- the “file1” component represents an abstract component
- the “file2” component represents a specific component.
- the field type name is written together with the field name separated by a colon “:”.
- the type name of the component is not particularly described when it is the same as the type of the field storing the component.
- the abstract component type field is indicated by a dotted rectangle with a white background.
- the field of the specific component type is indicated by a dotted rectangle with a diagonal pattern in the background.
- the components of the abstract component type are indicated by a solid rectangle with a white background.
- the components of the specific component type are indicated by a rectangle with a black background.
- FIG. 45 is an explanatory diagram illustrating an example of a system definition using a GUI according to the present embodiment.
- the target system “system4” is an instance of a component defined by a component definition “Tomcat_4” and a component instance “webApp4” that is an instance of a component defined by the component definition “WebApp_4”.
- tomcat4 component and “ubuntu4” component which is an instance of the component defined by component definition “Ubuntu_4”.
- “was” port of the “webApp4” component and the “was” port of the “tomcat4” component are connected, and the “os” port of the “tomcat4” component and the “os” port of the “ubuntu4” component are connected.
- “webApp4”, which is an example of a WebApp component is assumed to be a component corresponding to the function of the Web Application Server (hereinafter referred to as “WebApp”).
- WebApp WebApp4
- the “was” port which is an example of the WAS port, is a port related to the WebApp function.
- FIG. 46 is an explanatory diagram showing a definition example of an OS port by GUI according to the present embodiment.
- FIG. 47 is an explanatory diagram showing a definition example by the JSON of the port definition shown in FIG.
- the port definitions shown in FIGS. 46 and 47 have the same configuration.
- the port configuration defined by the port definition shown in FIG. 46 and FIG. 47 is the port configuration defined by the port definition “OS_3” shown in FIG. 38 and FIG. 39, except that each field has type name information.
- the configuration is the same.
- the port definition “OS_4” shown in FIG. 46 and FIG. 47 the port defined by the port definition has the “file” field of the abstract component type having the type name “OSFile” as the accept field. .
- the port also has an abstract component type “file” field of the type name “OSPackage” as an accept field.
- the port also has an abstract component type “boot” field of the type name “OSBoot” as a provide field.
- the dependency on the “boot” field is defined for the “file” field and the “package” field.
- JSON JSON, it is not shown whether the type name is an abstract component type or a concrete component type. However, in association with the type name of each field, the type is an abstract component type or a concrete component type. Such information is held separately.
- FIG. 48 is an explanatory diagram showing a definition example of a WAS port by GUI according to the present embodiment.
- FIG. 49 is an explanatory diagram showing a definition example by the JSON of the port definition shown in FIG.
- the port defined by the port definition has an abstract component type “war” field of the type name “War” as an accept field. It has a “package” field of an abstract component type of the type name “OSPacage” as a provide field. Also, dependency on the “package” fold is defined for the “war” field.
- the “War” type “war” accept field stores a component of a WAR file in which a WebApp program or the like is archived.
- the “OSPackage” type “package” provide field stores, as a component, a WebApp installation process that uses the component stored in the “war” field as a host.
- FIG. 50 is an explanatory diagram showing a definition example of Ubuntu component by GUI in this embodiment.
- FIG. 50 shows an example of a component definition with an id “Ubuntu_4”.
- the component definition shown in FIG. 50 includes id, a point in which each field has type information, and a point in which conversion processing is defined when a component of the main body refers to a value from the OS port. This is different from the definition of the Ubuntu component in the third embodiment.
- the component definition in this example refer to the values of the “file” field and “package” field of the “os_4” type “os” service port of the relevant component, and the “file” field and “package” field of the main component
- a designation for converting the component into a component of an appropriate specific component type and storing it is added instead of simply duplicating the component.
- the “ubuntu4.boot” field for the “ubuntu4.os.boot” field the “BootUbuntu” type in the “ubuntu4.boot” field that is the reference destination is the “ubuntu4.os.boot” that is the assignment destination. Since it is a derivative type of the “OSBoot” type of the “field”, it is assumed that it is propagated by a normal reference setting.
- conversion call such a reference involving conversion to a specific component is referred to as a conversion call.
- the conversion call is represented by a double line arrow connected from the black circle to the reference destination (conversion source) field as shown in FIG.
- conversion method designation method is not illustrated, but when a conversion call is designated by the GUI, another screen or the like for defining the details of the conversion call is displayed. It is assumed that detailed information of the conversion call can be input by the user.
- FIG. 51 is an explanatory diagram showing a definition example of Ubuntu component by JSON in the present embodiment.
- the example shown in FIG. 51 is an example in which the contents similar to the component definition shown in FIG. 50 are defined by JSON.
- the component definition “Ubuntu_4” shown in FIG. 51 is compared with the component definition “Ubuntu_3” of the third embodiment, and the definition of the type name of the storable component is added to the “field” element. “Conversion call” is added to the type of the “initial value” setting. Further, the component definition “Ubuntu_4” includes “conversion method” element and “argument” element in the “initial value” setting when the type of the initialization setting is “conversion call”.
- the component definition includes an element of “conversion”.
- the conversion definition that is each element in the “conversion” element includes three elements “return value type name”, “argument”, and “attribute assignment” in association with the conversion element name.
- return value type name the type name of the component received as a result of the conversion is designated.
- argument the type name of the component is specified in association with the name of the field storing the component to be converted.
- attribute assignment if there is an attribute value to be newly assigned to the converted component, the definition method is specified.
- the component value of the conversion source specified by the “argument” can be referred to and its attribute value can be used.
- the conversion definition “convertFile” included in the “convert” element is a definition for converting a “file” component of the “OSFile” type stored in the “file” field into a component of the “FileUbuntu” type.
- the “attribute assignment” at that time the “name” attribute value of the converted component stored in the “file” field, the “name” attribute value of the “file” component of the “OSFile” type before conversion Is assigned as it is.
- the “initial value” setting of the “file” field in which conversion call is set includes “conversion call” and the conversion method definition of any of the “conversion” elements as the “conversion method” setting. Is specified.
- the “file” field of the “os” port is specified as the “argument” setting. This means that the “file” component stored in the “os.file” field is used as an argument passed to “convertFile” which is the conversion method, that is, the component of the conversion source.
- conversion call when the value of the component is “conversion call”, “type” specifies that it is a conversion call, “conversion method” specifies the name of the conversion definition in the same definition, The “argument” may specify a component to be converted.
- the conversion method in the conversion call can be specified by, for example, a conversion name with an ampersand “&” added at the beginning.
- FIG. 52 is an explanatory diagram showing a definition example of Tomcat component by GUI in this embodiment.
- FIG. 52 shows an example of a component definition with an id “Tomcat_4”.
- the components defined by the component definition include the “package” field of “OSPackage” type, the “os” reference port defined by the port definition “OS_4”, and the port definition “ It is defined to have a “was” service port defined by WAS — 4 ”.
- WAS — 4 the port definition
- both the “package” field of the “os” reference port and the “package” field of the “was” service port are set to refer to the “package” field of the main component.
- the file field of the “os” reference port is set to be substituted by a conversion call for the “war” field of the “was” service port.
- “tomcat” is set in the value of the “name” attribute of the component “tomcatPackage4” defined as the initial value of the “package” field. This indicates that the component is a component including tomcat installation processing and the like.
- FIG. 53 is an explanatory diagram showing a definition example of Tomcat components by JSON in this embodiment.
- the example shown in FIG. 53 is an example in which the component definition shown in FIG. 52 is defined by JSON.
- “& convertWar” is set as the conversion method of the conversion call from the “file” field of the “os” reference port to the “war” field of the “was” service port.
- “convertWar” is defined in the “convert” element of the component definition. This “convertWar” receives a “War” type component from the “war” field, converts it to an “OSFile” type component, and returns it.
- FIG. 54 and FIG. 55 are explanatory diagrams showing examples of defining WebApp components in the present embodiment.
- FIG. 54 shows an example of definition by GUI
- FIG. 55 shows an example of definition by JSON.
- all show examples of component definitions to which the identifier “WebApp_4” is attached.
- the component defined by the component definition is a “war” field of “War” type and “war4” component is stored as an initial value. It is defined to have a field and a “was” reference port defined by the port definition “WAS — 4”.
- the “war” field of the “war” reference port is set to refer to the “war” field of the main component.
- “app.war” that is the file name of the “war” file is specified in the “name” attribute value of the “war4” component that is the value of the “war” field.
- FIG. 56 is an explanatory diagram showing the relationship between fields after port connection.
- FIG. 56 shows the relationship between fields in the specific system definition after port connection developed based on the system definition shown in FIG.
- the component is propagated not only by the reference but also by the conversion call.
- the “war4” component that is an abstract component of the “war” type stored in the “webApp4.war” field is passed to the “ubuntu4.os.file” field via the “tomcat4.was.war” field. Propagated.
- the “war” type is converted to the abstract component type “OSFile” type.
- the “war4” component after the conversion to the “OSFile type” is propagated to the “ubuntu4.file” field, and is converted from the “OSFile” type to the “fileubuntu” type of the specific component type.
- the operation of this embodiment is that the system definition expansion unit 101 and the component setting unit 102 handle the type of component defined in the field or component, and handle “conversion call” as the field value.
- the operation is the same as that of the third embodiment.
- the component setting unit 102 first checks the value stored in the target field, and if the value is a conversion call, the conversion source After acquiring the component specified in, convert it based on the conversion method definition specified in the conversion method, duplicate the resulting component, and convert the target field that is the conversion caller field Acquired after storing in.
- FIG. 57 is an explanatory diagram showing the relationship between components after resolving the component by reference including conversion call from the relationship between fields shown in FIG.
- the type and attribute value of the component may differ between the propagation source and the propagation destination, not the complete copy of the component.
- FIG. 58 is an example of data of the component after resolving the reference setting to the field value in the present embodiment.
- FIG. 58 shows an example of component information stored in the “file” field (ie, “ubuntu4.file” field) of the “ubuntu4” component.
- the identifier of the constituent element of the copy source (this example) is used as the constituent element information stored in the “file” field.
- "War4_2” the identifier of the component stored in the field (in this example, "war4_3”), the type name after conversion, and attribute value information attached after conversion are held. Also good.
- the main component of this component is the “War” type “war4” component stored in the “war” field of the “webApp4” component.
- the component is converted to the “OSFile” type in the “tomcat4” component, and the value of the “name” attribute value is changed. Furthermore, it is converted to “FileUbuntu” type in the “ubuntu4” component.
- “FileUbuntu” type is specified for “type name”
- “/usr/local/tomcat/app.war” is specified for the name attribute value as the “attribute value”.
- the constituent element aggregation processing by the constituent element setting unit 102 in this embodiment is strictly different from the aggregation processing in each of the above embodiments.
- the process of consolidating the constituent elements in this embodiment that is, the process of combining a series of constituent elements composed of newly defined constituent elements and duplicate constituent elements including the converted ones into a single constituent element that is output information
- a single component that is output information has an identifier of a newly defined component of a series of component groups, and the type and attribute value of a specific component located at the end of propagation by duplication are typed and It is given as an attribute value, and a set of relevance given to all copies is given as relevance information of the component.
- the component setting unit 102 traces the “id” of the copy source component of the component stored in each field, for example, and collects a set of component elements constituting each component group and the copy source Identify the newly defined component that is the end and the component of the specific component type. Then, the information of the output component is synthesized by collecting “id” from the newly defined component, the type and attribute value from the component of the specific component type, and the dependency from all the components. .
- the component setting unit 102 may have a function of verifying that one specific component is specified in one field in the entire reference relationship field. For example, the component setting unit 102 may detect an error when a plurality of specific component types are included in a component group stored in a series of fields having a reference relationship.
- the location where a specific component is specified is limited to one location, so that the correct deployment process of the component is realized.
- a situation in which a single component is realized at a plurality of locations can be said to be an unintended situation in an application that defines a target system construction process as in this example. Therefore, in such a case, it is preferable to detect and warn of a situation where a single component is realized at a plurality of locations.
- FIG. 59 is an explanatory diagram showing the relationship between the components after the setting is applied.
- the name given to the upper part of the shaded rectangle representing the copy of the component indicates the type name and id of the copy.
- FIG. 60 and 61 are explanatory diagrams showing examples of system configuration information in the present embodiment.
- FIG. 60 is an explanatory diagram showing a GUI display example of system configuration information generated as a result of generating a component based on the above-described definition.
- FIG. 61 is an explanatory diagram showing an example of output of the system configuration information by JSON. 60 and 61 both show the same configuration.
- the system definition can be defined more efficiently by appropriately adjusting information such as attribute values and types of components according to the combination of components.
- the type of the component can be appropriately converted according to the host, and the finally generated component can be made specific according to the host.
- the setting for that purpose can be confined to the host of the connection destination, the user can flexibly determine the host destination.
- FIG. 62 is an explanatory diagram showing another example of system definition by GUI.
- 62A shows “system4_2” as an example of a system using CentOS instead of Ubuntu
- FIG. 62B shows an example of a system using Jetty instead of Tomcat.
- system4-4 is shown as an example of a system that uses CentOS instead of Ubuntu and Jetty instead of Tomcat.
- FIG. 63 is an explanatory diagram showing a definition example by the JSON of the system definition shown in FIG.
- the “mw” component shown as an example of the Jetty component in FIGS. 62B and 62C assumes a component corresponding to the jetty that is a kind of Web application.
- FIG. 64 and FIG. 65 are explanatory diagrams showing definition examples of CentOS components in the present embodiment.
- the component defined by the component definition is the “os” service defined by “OS_4”, as in the case of the component definition “Ubuntu_4”. Has a port.
- the types of “file” field, “package” field, and “boot” field are specialized for “CentOS”, such as “FileCentOS”, “PackageCentOS”, and “BootCentOS”, respectively. Yes.
- the “FileCentOS” type is included in each return value.
- the reassignment of values from the “boot” field in the main body component to the “os.boot” field is a normal reference setting as in “Ubuntu_4”. This is because the “BootCentOS” type is a derived type of the “OSboot” type.
- FIG. 66 and FIG. 67 are explanatory diagrams showing examples of definition of Jetty components in the present embodiment.
- the component defined by the component definition is the “was” reference defined by “WAS_4” as in the case of the component definition “Tomcat_4”. It has a port and a “package” field of the “OSPackage” type.
- the “name” attribute of the component “jettyPackage4” defined as the initial value of the “package” field is “jetty”. This indicates that the component is a component including Jetty installation processing and the like.
- attribute assignment in the conversion method “convertWar” is a rule based on the directory structure in Jetty.
- the component definition “CentOS_4” defines a component having the same port configuration as the component definition “Ubuntu_4”
- the component definition “Jetty_4” defines a component having the same port configuration as the component definition “Tomcat_4”. is doing.
- FIGS. 62A to 62C there is a system in which the component “app” defined by “WebApp_4” is deployed, but the combination of the types of “mw” component and “vm” component is different. Is defined.
- the number of selectable patterns will increase exponentially. In this way, various systems can be efficiently described from a small number of definitions by reusability of components.
- FIG. Next, a fifth embodiment of the present invention will be described.
- the configuration of the system construction support system 100 in the fifth embodiment is the same as that of the fourth embodiment except that the operations of the system definition expansion unit 101 and the component element setting unit 102 are different.
- the same parts as those in the first to fourth embodiments are denoted by the same reference numerals, and description thereof is omitted.
- each field has not only the contents of the component such as the construction process but also the information that the component can take and possible state transition information as the component information, and the field The information indicating the relationship between them is specified from the state of the component stored in the field to the state of the other component. Such a relationship means that the former component must be in the state in order for the former component to execute the state transition.
- FIG. 68 is an explanatory diagram illustrating an example of expression of components and relevance between components using a GUI according to the present embodiment.
- FIG. 68 shows two examples of the “War” type “war” component and the “OSPackage” type “package” component.
- the “war” component has two states “f” and “t” and state transitions connecting the states to each other.
- the “package” component also has two states “f” and “t” and state transitions connecting the states to each other.
- the “war” component is the “t” of the “package” component in the state transition from the “f” state to the “t” state and the state transition from the “t” state to the “f” state. Has dependency on the state.
- the “package” component has dependency on the “f” state of the “war” component in the state transition from the “t” state to the “f” state. This is because when the “war” component transitions from the “f” state to the “t” state or from the “t” state to the “f” state, the “package” component state changes to the “t” state. It means that you have to be. This also indicates that when the “package” component transitions from the “t” state to the “f” state, the state of the “war” component must be in the “f” state.
- FIG. 69 is an explanatory diagram showing a definition example of the component type by JSON.
- FIG. 70 is an explanatory diagram showing an example of component definition by JSON.
- Each component in FIG. 70 can be interpreted as having a state or state transition held by a component type specified as a type name.
- the description “f-> t” indicates a state transition from the “f” state to the “t” state
- the description “package (t)” indicates the “package” component.
- “T” state is shown.
- FIG. 70 as an example of the definition of a component, an example is shown in which the dependency of the component on other components is set, but a similar definition can be set for a field.
- the component stored in the set field has a state or state transition held by the component type specified as the type name, or the component stored in the set field has a state transition, etc. Therefore, it can be interpreted as having a dependency on the state of the component stored in the specified other field.
- the constituent elements and fields have type information is described as an example. However, in the present embodiment, the constituent element and field type information is not essential.
- the procedure for changing each component from the specified current state to the requested state can be changed by specifying the current state and the requested state for each component according to the situation. It can be derived as an enumeration.
- the “package” component In order to transition the “war” component from the “f” state to the “t” state, the “package” component must be in the “t” state. It is possible to derive a procedure of transitioning from the state to the “t” state and then transitioning the “war” component from the “f” state to the “t” state.
- This method is a method for obtaining the order of state conversion that brings the initial state to the requested state while satisfying the restricting condition, based on the information of the initial state, the requested state, the state converting method, and the restricting condition of the state converting.
- the system construction support system 100 of the present invention can also be used for components having such state transitions.
- FIG. 71 is an explanatory diagram showing a definition example of a WAS port by JSON in the present embodiment.
- the way of defining the dependency is different from that in each of the above embodiments.
- the state transition of a component stored in a certain component or field is specified as “dependence source transition”, and the state of a component stored in another component or field as “dependence destination state” May be specified.
- the system definition expanding unit 101 and the component setting unit 102 are configured such that the component has a dependency on the state and state transition and the state transition of a certain component to the state of another component or This is the same as the fourth embodiment except that a field for storing such a component is handled.
- system construction procedure can be generated not only in the present embodiment but also in the first to fourth embodiments described above.
- each component that holds the construction process is linked with dependency.
- the order for executing all the construction processes can be determined based on such information while satisfying the dependency.
- topological sort For example, if there is no cycle in dependency, there is always at least one component that does not have any dependency on other components.
- the construction process of such a component may be executed. As a result, a component that solves all the dependencies that it holds is generated. Therefore, such a component construction process may be executed after the above construction process.
- the construction process of all construction elements is always executed by sequentially executing the components whose dependency is resolved by the execution of the migration and the preceding construction process.
- Such an algorithm for determining the order is generally known as “topological sort”.
- FIG. 72 is a block diagram showing an outline of the present invention.
- the system construction support system shown in FIG. 72 includes system definition input means 501 and setting provision means 502.
- the system definition input unit 501 (for example, the system definition input unit 001) stores a component that has at least one field that stores information about a component and is finally associated with one specific component.
- a component definition that is information to be defined, a field definition that is information on a field of a component to be defined, and a setting definition that is information on a setting for a component associated with the field (for example, an “assignment” definition
- the system definition including at least the designation of the component using the component definition that can include the component definition and the allocation definition related to the assignment of the component to the field of the component is input.
- the setting assigning unit 502 (for example, the system definition expanding unit 101 and the component setting unit 102) associates the component with the field of the designated component based on the system definition and the component definition, and is defined for the field. By reflecting the set contents in the component associated with the field, the setting is given to the component configuring the target system.
- FIG. 73 is a block diagram showing another configuration example of the system construction support system of the present invention.
- the system construction support system has a component definition storage unit 503 (for example, a component definition storage unit 003) that stores at least two or more component definitions, and information on specific components constituting the target system.
- the system configuration output unit 504 (for example, the system configuration output unit 002) that outputs the system configuration information, which is information including the content of the setting given to the component, may be provided.
- the setting definition included in the component definition may include at least information indicating the attribute value of the constituent element associated with the target field or the relevance between the constituent elements of the constituent element. .
- designation of another component in the information indicating the relationship may be performed by designation of any field to which the other component is associated.
- the component definition can include an assignment definition (for example, “initial value” definition, etc.) that is information related to the assignment of the component that is associated with the target field, and the setting assigning means is specified by the system definition.
- the assignment definition is included in the component definition of the selected component, the constituent element may be associated with the field specified by the assignment definition based on the assignment definition.
- the assignment definition includes information that specifies whether the component to be assigned is a new definition or a reference from another field, and the setting assigning means defines the component definition of the component specified by the system definition.
- the setting assigning means defines the component definition of the component specified by the system definition.
- the component definition is a port that is a concept that abstracts the terminal function for the component to be defined to connect with other components, and is defined by the port definition. It includes the designation of a port having at least one field to be stored and finally associated with one specific component, and the port definition is information on the field of the port to be defined Including a field definition, the system definition includes information for specifying a connection between ports, and the setting assigning unit is configured to correspond to the component information and the component corresponding to the corresponding fields of the ports in the connection relationship. The assigned setting may be propagated.
- the port definition can include a setting definition (for example, “setting” definition) that is information related to the setting for the configuration element associated with the field of the port to be defined. If the setting definition is included in the field, the setting content defined for the field is reflected in the component associated with the field, and then the setting is propagated between the corresponding fields of the connected ports. You may let them.
- a setting definition for example, “setting” definition
- the component definition can include an allocation definition that is information on allocation of a component associated with a field included in a port when the component to be defined has a port.
- the component may include a designation that the reference is from the field of the component.
- the component definition can include an assignment definition that is information relating to assignment of a component that is associated with a field included in the component when the component to be defined has a port.
- the allocation target component may include a designation that the reference is from a field of the port.
- the port definition can include an allocation definition (for example, “initial value” definition) that is information related to allocation of a component associated with a field of a port to be defined.
- the component may include a designation that the reference is from the field of any component associated with the port.
- the component definition or system definition indicates whether a port of a component is a reference port indicating use of a connection function provided by another port or a service port indicating provision of a connection function to another port.
- the port definition can be specified.
- the field of the port to be defined is an accept field that handles the propagation of the component from the reference port to the service port, or the component of the component from the service port to the reference port. It is possible to specify whether it is a provide field that deals with propagation, and the setting granting means, based on the component definition or system definition and port definition, from the field of the component having the service port to the service port accept field.
- Limiting the assignment of the components may limit the allocation of the components by reference from the field of Component having the reference port for-provide field reference port.
- the assignment definition can include a conversion definition that is information related to the conversion method of the component, and when the setting assigning unit associates the component with the field, the specified component is assigned based on the conversion definition. You may make it correspond after converting.
- the component definition includes information related to the type, which is information related to the type of component that can be stored in the field
- the allocation definition includes information related to the type of the component to be allocated
- the type indicates other types.
- the setting assigning means limits the association of the component to the field only when the type set for the field matches or is in the inclusion relationship with the type of the component to be assigned. May be.
- the system construction support system has, as the types of component elements, a specific component element including all essential information and an abstract component element including only a part of essential information.
- a conversion definition which is information related to the conversion method of the component, can be included.
- the conversion definition includes information that specifies the type of the component that is the conversion source and the conversion destination.
- the specification of the type in the conversion definition is abstract from the conversion source. Either a component type and a conversion destination is an abstract component type, or a conversion source is an abstract component type and a conversion destination is a specific component type.
- the setting assigning means when the assignment definition for the field included in the component designated by the system definition includes a reference from another field in the designation of the component to be assigned, It may be verified that there is only one place where a specific component is specified.
- the component may include information on the state and the state transition.
- the information indicating the relationship between the components is changed from the state transition in one component to the state in the other component. It may be information indicating dependency on the.
- the present invention is not limited to an IT system and can be suitably applied to design support when a system composed of a plurality of parts is constructed.
Abstract
Description
以下、本発明の実施形態を図面を参照して説明する。図1は、第1の実施形態のシステム構築支援システムの構成例を示すブロック図である。第1の実施形態のシステム構築支援システム100は、コンポネントを用いて示されるシステムの構成を、具体的な構成要素による構成に変換して出力する構成定義機能を提供するシステムであって、図1に示されるように、システム定義展開部101と、構成要素設定部102とを備える。
また、以下では、ITシステムの構築処理に含まれる任意のプログラム単位を構成要素とし、それらの組み合わせによって構成されるシステムの構築を支援する例を示すが、構成要素は、構築処理に限られず、あらゆるシステムを構成する任意の単位であればよい。
このような、コンポネントやフィールドや構成要素や属性値や関連性の指定に対応する各々のGUI部品を用意して、任意のコンポネント定義をユーザが入力できるようにしてもよい。
次に、本実施形態の動作を説明する。図10は、本実施形態のシステム構築支援システム100の動作の一例を示すフローチャートである。図10に示す例では、まず、システム定義展開部101が、システム定義入力部001からシステム定義を受け取ると(ステップS11)、これを読み込む。そして、システム定義展開部101は、システム定義が参照するコンポネント定義があれば、これを部品定義記憶部003から取得して、システム定義を展開して各フィールドに格納される構成要素を解決して、具体的なシステム定義を生成する(ステップS12)。なお、ステップS12で生成された具体的なシステム定義は、構成要素設定部102へ送信される。
そして、“file1”構成要素に対して、“file”フィールドに設定された設定内容が付与される。ここでは、“file1”構成要素に対して、“mode”属性の値として“644”が追加されるとともに、“file1”構成要素に対して、“boot”フィールドに対応する具体的な構成要素である“boot1”に対する依存性が付与される。結果として、図6や図7に示すようなシステム構成情報が生成される。
本実施形態によれば、コンポネントという抽象化された構成要素群のパターンを利用するとともに、そのようなコンポネントの定義情報として、当該コンポネントが対応している構成要素に関する情報として、当該構成要素が共通に有する設定(属性値や他の構成要素との間の依存関係)を持たせることによって、個々の構成要素に対する設定のうちの再利用性がある設定をコンポネントの情報として閉じ込めることができる。また、本実施形態によれば、抽象化された構成要素の情報を格納するフィールドという枠に対して、その中身の構成要素に対する設定を定義しておき、構成要素の組み合わせが確定した後で、中身の構成要素に対して、枠に設定された設定を反映する仕組みを有しているので、組み合わせが変更される度に同様の設定を設定しなおすといった手間を省略できる。このように、既に定義されたコンポネントの設定を利用することで、構成要素の組み合わせを変更しても、関係する構成要素に対する設定の追加が不要となりシステム定義が容易化される。
また、“Ubuntu”上で使用するファイルの種別を変更するなどシステム構成の一部を変更する場合であっても、“Ubuntu_1”というコンポネント定義が既に定義済みであれば、“file”フィールドに対する値の代入を設定するだけで、“Ubuntu”上において“file2”ファイルの構築処理が有するブート処理への依存性を設定しなおす必要なしに、システム構成を変更できる。このように、本実施形態によれば、構成要素間の依存性に対しても再利用性を持たせることができる。
次に、本発明の第2の実施形態について説明する。第2の実施形態におけるシステム構築支援システム100の構成は、システム定義展開部101と構成要素設定部102の動作が異なる点を除いて第1の実施形態の構成と同様である。以下、第1の実施形態と同様の部位には同一の記号を付し、説明を省略する。
本実施形態のシステム定義展開部101および構成要素設定部102は、これらポートおよびワイヤの情報を扱う点が第1の実施形態と異なる。
ここで、OSポートは、Ubuntuコンポネントなど一般にOSに対応するコンポネントが他のコンポネントと接続するための接続処理を抽象化したものを想定している。図16には、“OS_2”というidが付されたポート定義の一例が示されている。図16に示すポート定義“OS_2”は、“file”フィールドと“package”フィールドという2つのフィールドを有する。ここで、“file”フィールドは、一般的なOS上において他のコンポネントとの接続に必要なファイルの作成処理といったファイル構築に関する構成要素に対応したフィールドを想定している。また、“package”フィールドは、OSの下で動作するミドルウェアのコンフィグレーションマネージメントシステムが提供するパッケージ化されたリソース等に対応したフィールドを想定している。なお、当該ポート定義においてこれら2つのフィールドには、設定定義および初期値は特に指定されていない。
次に、本実施形態の動作を説明する。図26は、本実施形態のシステム構築支援システム100の動作の一例を示すフローチャートである。以下では、第1の実施形態と同様の動作については同一の記号を付し、説明を省略する。
ここで、ポートを連結するとは、連結対象とされたポート間に接続関係があることを構成情報として保持することに加えて、連結対象とされたポート間においてフィールドの値を移譲可能にすること、より具体的には、システム定義、コンポネント定義およびポート定義に従って構成要素の情報を相手先ポートに伝搬させる(移し替える)処理を行うことをいう。
その結果、ポート定義“OS_2”によって定義づけされる”os”ポートは、“file”フィールドに本体コンポネントの“tomcat2.configFile”フィールドへの参照が代入され、かつ“package”フィールドに“tomcat2.package”フィールドへの参照が代入された上で、“tomcat2”コンポネントの“os”リファレンスポートとして設定される。
本実施形態によれば、複数のコンポネントで定義された設定の全てを構成要素に集約的に付与可能となり、またフィールドへの構成要素の代入に関する定義までが再利用可能に抽象化されることで、ユーザはワイヤを定義するだけでより効率的にシステムの構成を定義できる。より具体的には、本実施形態では、フィールドへの構成要素の代入に関する設定定義に、他のフィールドの参照である旨を指定できるようにした(代入の抽象化要素を追加した)ことで、フィールドに対して設定されている属性値や依存性といった設定内容を、参照関係に基づいて伝搬させていくことができる。また、このような参照関係は、コンポーネントの組み合わせが決定して初めて確定されるものであるが、本実施形態では参照関係の設定をフィールドを用いて行い、かつポートとワイヤという抽象化された部品を使って伝搬可能に結びつける仕組みとなっている。このように代入の抽象化と設定対象の抽象化とを組み合わせることで、再利用性を犠牲にせずに、設定の伝搬が可能になっている。このような構成を備えているので、本実施形態によれば、より効率的にシステム構成を定義できる。
次に、本発明の第3の実施形態について説明する。第3の実施形態におけるシステム構築支援システム100の構成は、システム定義展開部101と構成要素設定部102の動作が異なる点を除いて第2の実施形態の構成と同様である。以下、第1~2の実施形態と同様の部位には同一の記号を付し、説明を省略する。
図38には、“OS_3”という識別子が付されたポート定義の一例が示されている。図38に示すポート定義“OS_3”では、当該ポート定義によって定義づけられるポートが有するフィールドとして、“file”フィールドと“package”フィールドという2つのアクセプトフィールドと、“boot”フィールドという1つのプロバイドフィールドとが定義されている。また、本例では、“file”フィールドと“package”フィールドのそれぞれに対して、“boot”フィールドへの依存性が定義されている。
また、“file”フィールドと“package”フィールドの初期値定義として、“os”ポートの“file”フィールドと“package”フィールドへの参照がそれぞれ定義されている。一方、“boot”フィールドの初期値定義として、“boot3”構成要素が新規に作成される旨が定義されているとともに、“os”ポートの“boot”フィールドに対して本体のコンポネントである当該コンポネントの“boot”フィールドの参照が定義されている。
次に、本実施形態の動作を説明する。本実施形態の動作は、システム定義展開部101と構成要素設定部102が、ポートのアクセプトフィールドとプロバイドフィールドとを扱う点を除いて第2の実施形態と同様である。
本実施形態によれば、あるポートをリファレンスポートとして持つコンポネントが持つ構成要素と、サービスポートとして持つコンポネントが持つ構成要素との間の関連性に関する設定(例えば、“os”ポートの“file”フィールドと“package”フィールドに対する“boot”フィールドへの依存性の設定等)をポート内で定義でき、これを当該ポートと共に再利用できることにより、より効率的にシステム定義を記述できる。すなわち、抽象化された依存性という設定をポート内で完結させることでより再利用性を高めることができる。
次に、本発明の第4の実施形態について説明する。第4の実施形態におけるシステム構築支援システム100の構成は、システム定義展開部101と、構成要素設定部102の動作が異なる点を除いて第3の実施形態の構成と同様である。以下、第1~3の実施形態と同様の部位には同一の記号を付し、説明を省略する。
本実施形態の動作は、システム定義展開部101と構成要素設定部102が、フィールドや構成要素に定義された構成要素の型を扱う点と、フィールドの値として“変換呼出し”を扱う点を除いて第3の実施形態の動作と同様である。
さらに“ubuntu4“コンポネント内で“FileUbuntu”型に変換される。その結果、“型名“には“FileUbuntu”型が指定されており、“属性値“としてはname属性値に“/usr/local/tomcat/app.war”が指定される。
本実施形態によれば、コンポネントの組み合わせに応じて構成要素の属性値や型といった情報が適切に調整されることで、さらに効率的にシステム定義を定義できる。例えば、本実施形態によれば、構成要素の型をホストに応じて適切に変換することができ、最終的に生成される構成要素をそのホストに応じた具体的なものにできる。また、そのための設定を接続先のホスト側に閉じ込めておけるので、ユーザはホスト先を柔軟に決定することができる。
次に、本発明の第5の実施形態について説明する。第5の実施形態におけるシステム構築支援システム100の構成は、システム定義展開部101と構成要素設定部102の動作が異なる点を除いて、第4の実施形態の構成と同様である。以下、第1~4の実施形態と同様の部位には同一の記号を付し、説明を省略する。
これは、“war”構成要素が“f”状態から“t”状態に遷移するもしくは“t”状態から“f”状態に遷移する場合に、“package”構成要素の状態が“t”状態にいなければならないことを表している。また、“package”構成要素が“t”状態から“f”状態に遷移する場合に、“war”構成要素の状態が“f”状態にいなければならないことを表している。
本実施形態の動作は、システム定義展開部101と構成要素設定部102が、状態と状態遷移およびある構成要素の状態遷移から他の構成要素の状態への依存性を持つような構成要素またはそのような構成要素を格納するフィールドを扱う点を除いて、第4の実施形態と同様である。
本実施形態によれば、状態と状態遷移およびある構成要素の状態遷移から他の構成要素の状態への依存性を持つような構成要素を有するシステムであっても、そのような構成要素またはそのような構成要素を格納するフィールドを有するコンポネントを用いることで、容易に定義できる。
001 システム定義入力部
002 システム構成出力部
003 部品定義記憶部
101 システム定義展開部
102 構成要素設定部
501 システム定義入力手段
502 設定付与手段
503 部品定義記憶手段
504 システム構成出力手段
Claims (20)
- 構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも1つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、前記フィールドの情報であるフィールド定義と、前記フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、前記コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を入力するシステム定義入力手段と、
前記システム定義および前記コンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う設定付与手段とを備えた
ことを特徴とするシステム構築支援システム。 - コンポネント定義に含まれる設定定義は、対象とされたフィールドに対応づけられる構成要素の属性値または前記構成要素が有する他の構成要素との間の関連性を示す情報を少なくとも含む
請求項1に記載のシステム構築支援システム。 - 関連性を示す情報における他の構成要素の指定が、前記他の構成要素が対応づけられるいずれかのフィールドの指定により行われる
請求項2に記載のシステム構築支援システム。 - コンポネント定義は、対象とされたフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
設定付与手段は、システム定義により指定されたコンポネントのコンポネント定義に前記割当定義が含まれている場合に、前記割当定義に基づいて、前記割当定義が指定するフィールドに構成要素を対応づける
請求項1から請求項3のうちのいずれか1項に記載のシステム構築支援システム。 - 割当定義は、割り当て対象の構成要素が、新規定義であるか、他のフィールドからの参照であるかを指定する情報を含み、
設定付与手段は、システム定義により指定されたコンポネントのコンポネント定義に含まれる前記割当定義が新規定義を指定している場合に、指定された構成要素を生成した上で前記割当定義が指定するフィールドに対応づけ、前記割当定義が他のフィールドからの参照を指定している場合に、前記割当定義が指定されたフィールドに対して前記他のフィールドに対応づけられている構成要素を対応づける
請求項4に記載のシステム構築支援システム。 - コンポネント定義は、定義対象とされるコンポネントが他のコンポネントと接続するための端子機能を抽象化した概念であるポートであって、ポート定義により定義づけられ、接続処理に必要な構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも1つ以上有するポートの指定を含み、
前記ポート定義は、定義対象とされるポートが有するフィールドの情報であるフィールド定義を含み、
前記システム定義は、ポート間の接続を指定する情報を含み、
設定付与手段は、接続関係にあるポートの対応するフィールド間で、対応づけられる構成要素の情報および前記構成要素に対して付与された設定を伝搬させる
請求項1から請求項5のうちのいずれか1項に記載のシステム構築支援システム。 - ポート定義は、定義対象とされるポートが有するフィールドに対応づけられる構成要素に対する設定に関する情報である設定定義を含むことができ、
設定付与手段は、ポート定義に前記設定定義が含まれている場合に、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映した上で、接続関係にあるポートの対応するフィールド間で前記設定を伝搬させる
請求項6に記載のシステム構築支援システム。 - コンポネント定義は、定義対象とされるコンポネントがポートを有している場合に、前記ポートが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
前記割当定義は、割り当て対象の構成要素が、前記コンポネントが有するフィールドからの参照である旨の指定を含むことができる
請求項6または請求項7に記載のシステム構築支援システム。 - コンポネント定義は、定義対象とされるコンポネントがポートを有している場合に、前記コンポネントが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
前記割当定義は、割り当て対象の構成要素が、前記ポートが有するフィールドからの参照である旨の指定を含むことができる
請求項6から請求項8のうちのいずれか1項に記載のシステム構築支援システム。 - ポート定義は、定義対象とされるポートが有するフィールドに対応づけられる構成要素の割り当てに関する情報である割当定義を含むことができ、
前記割当定義は、割り当て対象の構成要素が、前記ポートに対応づけられる任意のコンポネントが有するフィールドからの参照である旨の指定を含むことができる
請求項6から請求項9のうちのいずれか1項に記載のシステム構築支援システム。 - コンポネント定義またはシステム定義は、コンポネントが有するポートが、他のポートが提供する接続機能の利用を示すリファレンスポートであるか、他のポートへの接続機能の提供を示すサービスポートであるかを指定することができ、
ポート定義は、定義対象とされるポートが有するフィールドが、リファレンスポートからサービスポートへの構成要素の伝搬を扱うアクセプトフィールドであるか、サービスポートからリファレンスポートへの構成要素の伝搬を扱うプロバイドフィールドであるかを指定することができ、
設定付与手段は、前記コンポネント定義または前記システム定義および前記ポート定義に基づいて、サービスポートのアクセプトフィールドに対して当該サービスポートを有するコンポネントのフィールドからの参照による構成要素の割り当てを制限し、リファレンスポートのプロバイドフィールドに対して当該リファレンスポートを有するコンポネントのフィールドからの参照による構成要素の割り当てを制限する
請求項6から請求項10のうちのいずれか1項に記載のシステム構築支援システム。 - 割当定義は、構成要素の変換方法に関する情報である変換定義を含むことができ、
設定付与手段は、フィールドへ構成要素を対応づける際に、前記変換定義に基づいて、指定された構成要素を変換した上で対応づける
請求項1から請求項11のうちのいずれか1項に記載のシステム構築支援システム。 - コンポネント定義は、フィールドが格納可能な構成要素の種類に関する情報である型に関する情報を含み、
割当定義は、割り当て対象とされる構成要素の型に関する情報を含み、
前記型は、他の型を包含することができ、
設定付与手段は、フィールドへの構成要素の対応づけを、当該フィールドに対して設定されている型が、割り当て対象の構成要素の型と一致もしくは包含関係にある場合に限定する
請求項1から請求項12のうちのいずれか1項に記載のシステム構築支援システム。 - 構成要素の型の種類として、必須の情報を全て備えた具体構成要素と、必須の情報の一部のみを備えた抽象構成要素とを有し、
割当定義は、構成要素の変換方法に関する情報である変換定義を含むことができ、
前記変換定義は、変換元と変換先の構成要素の型を指定する情報を含み、
前記変換定義における型の指定は、変換元が抽象構成要素型であって変換先が抽象構成要素型であるか、変換元が抽象構成要素型であって変換先が具体構成要素型であるかのいずれかである
請求項13に記載のシステム構築支援システム。 - 設定付与手段は、システム定義により指定されたコンポネントが有するフィールドに対する割当定義に、割り当て対象の構成要素の指定に他のフィールドからの参照が含まれる場合に、参照関係にあるフィールド全体において、具体的な構成要素が指定される箇所が1箇所であることを検証する
請求項1から請求項14のいずれか1項に記載のシステム構築支援システム。 - 構成要素は、状態と状態遷移の情報を含み、
構成要素間の関連性を示す情報は、ある一方の構成要素内の状態遷移から他の構成要素内の状態への依存性を示す情報である
請求項1から請求項15のいずれか1項に記載のシステム構築支援システム。 - 少なくとも2以上のコンポネント定義を格納する部品定義記憶手段を備えた
請求項1から請求項16のうちのいずれか1項に記載のシステム構築支援システム。 - 対象システムを構成する具体的な構成要素の情報であって、前記構成要素に付与された設定の内容を含む情報であるシステム構成情報を出力するシステム構成出力手段を備えた 請求項1から請求項17のうちのいずれか1項に記載のシステム構築支援システム。
- 情報処理装置が、構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも1つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、前記フィールドの情報であるフィールド定義と、前記フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、前記コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を受け付けると、前記システム定義および前記コンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う
ことを特徴とするシステム構築支援方法。 - コンピュータに、
構成要素の情報を格納するフィールドであって最終的に具体的な一の構成要素と対応づけられるフィールドを少なくとも1つ以上有するコンポネントを定義づける情報であるコンポネント定義であって、前記フィールドの情報であるフィールド定義と、前記フィールドに対応づけられる構成要素に対する設定に関する情報である設定定義とを含むことができるコンポネント定義を用いたコンポネントの指定と、前記コンポネントが有するフィールドに対する構成要素の割り当てに関する割当定義とを少なくとも含むシステム定義を受け付けると、前記システム定義および前記コンポネント定義に基づいて、指定されたコンポネントのフィールドに構成要素を対応づけるとともに、前記フィールドに対して定義された設定内容を、前記フィールドに対応づけられた構成要素に反映することにより、対象システムを構成する構成要素に対する設定の付与を行う処理
を実行させるためのシステム構築支援プログラムが記録された記憶媒体。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017536608A JP6673359B2 (ja) | 2015-08-27 | 2016-08-18 | システム構築支援システム、方法およびプログラム |
US15/748,236 US10599447B2 (en) | 2015-08-27 | 2016-08-18 | System construction assistance system and method, and storage medium |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015-167797 | 2015-08-27 | ||
JP2015167797 | 2015-08-27 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017033441A1 true WO2017033441A1 (ja) | 2017-03-02 |
Family
ID=58099866
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2016/003775 WO2017033441A1 (ja) | 2015-08-27 | 2016-08-18 | システム構築支援システム、方法および記憶媒体 |
Country Status (3)
Country | Link |
---|---|
US (1) | US10599447B2 (ja) |
JP (1) | JP6673359B2 (ja) |
WO (1) | WO2017033441A1 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018230352A1 (ja) * | 2017-06-14 | 2018-12-20 | 日本電気株式会社 | 変更手順生成装置、変更手順生成方法および変更手順生成プログラム |
US11403270B2 (en) | 2018-06-22 | 2022-08-02 | Nec Corporation | System configuration derivation device, method, and program |
US11561770B2 (en) | 2018-05-07 | 2023-01-24 | Nec Corporation | System configuration derivation device and system configuration derivation method |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10587457B1 (en) * | 2019-05-10 | 2020-03-10 | Capital One Services, Llc | Techniques for dynamic network resiliency |
US10644954B1 (en) | 2019-05-10 | 2020-05-05 | Capital One Services, Llc | Techniques for dynamic network management |
US10756971B1 (en) | 2019-05-29 | 2020-08-25 | Capital One Services, Llc | Techniques for dynamic network strengthening |
US10698704B1 (en) | 2019-06-10 | 2020-06-30 | Captial One Services, Llc | User interface common components and scalable integrable reusable isolated user interface |
US10846436B1 (en) | 2019-11-19 | 2020-11-24 | Capital One Services, Llc | Swappable double layer barcode |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012111725A1 (ja) * | 2011-02-18 | 2012-08-23 | 日本電気株式会社 | リファクタリング装置、リファクタリング方法、及び、プログラム |
WO2014115505A1 (ja) * | 2013-01-28 | 2014-07-31 | 日本電気株式会社 | 設定支援装置、及び、設定支援方法 |
WO2015040788A1 (ja) * | 2013-09-17 | 2015-03-26 | 日本電気株式会社 | 情報処理装置、及び、システム設計支援方法 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6901588B1 (en) * | 2000-04-17 | 2005-05-31 | Codemesh, Inc. | Sharing components between programming languages by use of polymorphic proxy |
US7890543B2 (en) * | 2003-03-06 | 2011-02-15 | Microsoft Corporation | Architecture for distributed computing system and automated design, deployment, and management of distributed applications |
US20050278694A1 (en) * | 2003-11-15 | 2005-12-15 | International Business Machine Corporation | Describing Runtime Components of a Solution for a Computer System |
US20080168096A1 (en) * | 2007-01-08 | 2008-07-10 | Shalom Daskal | Extracting business logic from the user interface of service and product oriented computerized systems |
DE112010005023B4 (de) * | 2009-12-28 | 2023-11-30 | Mitsubishi Electric Corporation | Verwendung einer programmerstellungsunterstützungsvorrichtung zum erstellen von programmen für zu steuernde anlagen |
US20150135160A1 (en) * | 2012-05-01 | 2015-05-14 | Simon Gauvin | System and method for providing an application development and distribution social platform |
US9875090B2 (en) * | 2012-12-20 | 2018-01-23 | Microsoft Technology Licensing, Llc | Program analysis based on program descriptors |
US9558017B2 (en) * | 2014-03-18 | 2017-01-31 | Sap Se | Software dependency management through declarative constraints |
-
2016
- 2016-08-18 US US15/748,236 patent/US10599447B2/en active Active
- 2016-08-18 JP JP2017536608A patent/JP6673359B2/ja active Active
- 2016-08-18 WO PCT/JP2016/003775 patent/WO2017033441A1/ja active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012111725A1 (ja) * | 2011-02-18 | 2012-08-23 | 日本電気株式会社 | リファクタリング装置、リファクタリング方法、及び、プログラム |
WO2014115505A1 (ja) * | 2013-01-28 | 2014-07-31 | 日本電気株式会社 | 設定支援装置、及び、設定支援方法 |
WO2015040788A1 (ja) * | 2013-09-17 | 2015-03-26 | 日本電気株式会社 | 情報処理装置、及び、システム設計支援方法 |
Non-Patent Citations (2)
Title |
---|
HISASHI SHIMAMURA ET AL.: "Model Base deno Sizing to Kosei Kanri ni yori Cloud-jo no SI o Koritsuka suru Cloud-gata SI", NEC TECHNICAL JOURNAL, vol. 67, no. 2, 20 March 2015 (2015-03-20), pages 79 - 82, ISSN: 0285-4139 * |
MANABU NAKANOYA ET AL.: "Model Base Provisioning ni yoru Application Shiko Network Kosei Kanri", SYMPOSIUM ON MULTIMEDIA, DISTRIBUTED, COOPERATIVE AND MOBILE SYSTEMS (DICOM02015) RONBUNSHU, vol. 2015, no. 1, 1 July 2015 (2015-07-01), pages 1121 - 1128, ISSN: 1882-0840 * |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018230352A1 (ja) * | 2017-06-14 | 2018-12-20 | 日本電気株式会社 | 変更手順生成装置、変更手順生成方法および変更手順生成プログラム |
JPWO2018230352A1 (ja) * | 2017-06-14 | 2020-04-09 | 日本電気株式会社 | 変更手順生成装置、変更手順生成方法および変更手順生成プログラム |
US11429398B2 (en) | 2017-06-14 | 2022-08-30 | Nec Corporation | Change procedure generation device, change procedure generation method, and change procedure generation program |
US11561770B2 (en) | 2018-05-07 | 2023-01-24 | Nec Corporation | System configuration derivation device and system configuration derivation method |
US11403270B2 (en) | 2018-06-22 | 2022-08-02 | Nec Corporation | System configuration derivation device, method, and program |
Also Published As
Publication number | Publication date |
---|---|
JPWO2017033441A1 (ja) | 2018-06-14 |
US20180225133A1 (en) | 2018-08-09 |
US10599447B2 (en) | 2020-03-24 |
JP6673359B2 (ja) | 2020-03-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2017033441A1 (ja) | システム構築支援システム、方法および記憶媒体 | |
US8495352B2 (en) | System and method for instantiation of distributed applications from disk snapshots | |
US9021419B2 (en) | System and method for supporting intelligent design pattern automation | |
US10901804B2 (en) | Apparatus and method to select services for executing a user program based on a code pattern included therein | |
JP5350428B2 (ja) | 自動プログラム生成装置、方法及びコンピュータプログラム | |
US8756407B2 (en) | Configuration rule prototyping tool | |
CN108830720A (zh) | 智能合约运行方法、装置、系统和计算机可读存储介质 | |
US11481200B1 (en) | Checking source code validity at time of code update | |
US10817284B2 (en) | Melding of mediation flow service component architecture (SCA) components | |
JP6479184B2 (ja) | コンピュータ実行可能なモデルリバースエンジニアリング方法及び装置 | |
JP7231518B2 (ja) | パッケージ化支援システムおよびパッケージ化支援方法 | |
Jaworski et al. | Expert Python Programming: Become a master in Python by learning coding best practices and advanced programming concepts in Python 3.7 | |
US20130074068A1 (en) | Method, System, and Computer Program for Implementing a Customizable Virtual Appliance | |
Hanjura | Heroku cloud application development | |
KR100656419B1 (ko) | 정보시스템 개발장치 및 방법 | |
JP5867540B2 (ja) | プログラム生成装置、プログラム生成装置の制御方法、およびプログラム | |
KR102397494B1 (ko) | 로우(Low) 코드 웹 개발 및 운영 시스템 및 이를 이용한 서비스 방법 | |
JP2014164545A (ja) | デプロイメント方法およびプログラム | |
JP6705482B2 (ja) | システム構築パラメータ管理装置、システム構築パラメータ管理システム、システム構築パラメータ管理方法、及び、システム構築パラメータ管理プログラム | |
US11645193B2 (en) | Heterogeneous services for enabling collaborative logic design and debug in aspect oriented hardware designing | |
JP2014059699A (ja) | デモアプリケーション生成システムおよびデモアプリケーション生成プログラム | |
WO2023037506A1 (ja) | システム構成導出装置、システム構成導出方法、及びコンピュータ可読媒体 | |
US20230297366A1 (en) | Two-way synchronization of infrastructure-as-code templates and instances | |
CN116909545A (zh) | 一种基于微服务架构的低代码mom平台 | |
Ranabahu | Abstraction driven application and data portability in cloud computing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16838792 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2017536608 Country of ref document: JP Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15748236 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16838792 Country of ref document: EP Kind code of ref document: A1 |