WO2013058394A1 - Verification device, verification method, and computer program - Google Patents

Abstract

Disclosed is a verification device that can easily verify consistency between dependencies of a system and dependencies of components constituting such a system. The verification device determines consistency by verifying a containment relationship between a group of function modules that a first system is dependent on and a group of function modules that a second system constituting the first system is dependent on.

Description

Verification device, verification method, and computer program

The present invention relates to a verification technique for various systems using a computer.

In order to improve the reusability of various systems using computers, the dependence of the system on the specific environment, middleware and functional modules that are essential for the operation of the system is eliminated as much as possible. It is effective to increase the sex.
For example, when a certain system SA depends on a specific database product DA, in order for another system SB to reuse the system SA, it is necessary to install the database product DA together. In this case, when the database product DA is an expensive commercial product or requires a lot of memory resources, it is difficult for the system SB to use the system SA.
Alternatively, when the system SB uses another database product DB and there is a situation where the database product DA and the database product DB cannot coexist due to the structure, the system SB may use the system SA. It becomes difficult.
Here, let us consider a case where the constraint condition is relaxed such that the dependency of the system SA is not limited to the database product DA, but only the database product DA or the database product DB exists. In this case, if the system SB introduces a database product DB that meets the requirements of its own system, the system SB can use the system SA. That is, the reusability of the system SA is improved.
In this manner, the more the system dependency includes more options (the looser the constraint), the more independent the system, and the more the system can be reused.
By the way, when a system is comprised from several components, the dependence of the system is determined by the dependence of the component with the severest restrictions of the dependence among the components which the said system contains.
For example, even if a user or the like expects that a certain system SC can be operated by an arbitrary database product, if the component CC included in the system SC depends on a specific database product DC, the result Therefore, the system SC depends on the database product DC.
Therefore, when a user or the like tries to maintain the dependency constraint condition in a loose state in order to increase the independence and reusability of such a system, the dependency of the system and It is necessary to check the consistency with the dependency of each component, that is, to verify the consistency.
In particular, in the development of a system composed of many components, this verification work becomes difficult. Therefore, it is desirable to provide a mechanism for facilitating this verification work.
Patent Document 1 and Patent Document 2 describe an example of a mechanism for automatically verifying consistency between requirements of a system and its components. The verification devices described in Patent Document 1 and Patent Document 2 set requirements to be verified and data necessary for the verification in advance in the system and each component. Then, the verification device verifies the requirements based on the data when incorporating the component into the system. If it is determined that the component does not meet the requirements on the system side, the verification device avoids the incorporation. Maintain proper operation of the system.

JP 2004-326366 A JP 2008-171318 A

However, the data necessary for verification of the requirements proposed in the above-mentioned patent document is a detailed model description of the target system or component. For this reason, in the technique proposed in the patent document, the number of work steps required for preparing the necessary data is large. Therefore, there is a problem that the consistency between the system dependency and the component dependency cannot be easily verified.
Therefore, the present invention has been made to solve the above-described problems. SUMMARY OF THE INVENTION The main object of the present invention is to provide a verification apparatus and a control method therefor, and a computer program capable of easily verifying consistency between system dependencies and dependencies of components constituting the system. To do.

In order to achieve such an object, one aspect of the present invention is a verification apparatus,
Storage means for storing a functional module ID and association information between the functional module ID and another functional module ID;
With reference to the storage unit for the specific functional module ID to be verified, when the specific functional module ID is associated with the other functional module ID, the other functional module ID is output. And if not associated, a function management means for outputting information indicating that there is no specific function module ID or association;
When the function module ID on which the first system depends is input to the function management unit as the specific function module ID, if at least one of the function module IDs is acquired from the function management unit, the function module ID is acquired. When the function module ID is the first set of function module IDs and information indicating that there is no association is acquired from the function management unit, the function module ID is input to the function management unit as the specific function module ID. The function module ID thus obtained is set as the first function module ID set,
When the function module ID on which the second system constituting the first system depends is input to the function management unit as the specific function module ID, at least one of the function module IDs is input from the function management unit. If acquired, the acquired functional module ID is set as the second functional module ID set, while if the information indicating that there is no association is acquired from the functional management unit, the specific functional module The function module ID input to the function management means as an ID is used as the second function module ID set,
Verifying means for outputting information indicating matching when the second functional module ID set includes the first functional module ID set;
Is provided.
Another embodiment of the present invention is a verification method,
By the computer, the function module ID and the association information between the function module ID and another function module ID are stored in a storage unit for storing,
When the computer refers to the storage unit for a specific functional module ID to be verified, and the specific functional module ID is associated with the other functional module ID, the other functional module ID On the other hand, if it is not associated, it outputs information indicating that there is no specific functional module ID or association,
When at least one of the functional module IDs is acquired when the computer inputs the functional module ID on which the first system depends as the specific functional module ID, the acquired functional module ID is On the other hand, when the information indicating that there is no association is obtained while the first functional module ID set, the functional module ID input as the specific functional module is set as the first functional module ID set,
When at least one of the functional module IDs is acquired by the computer when the functional module ID on which the second system constituting the first system depends is input by the computer, the acquired functional module ID is On the other hand, when information indicating that there is no association is acquired, the function module ID input as the specific function module ID is set as the second function module ID set.
When the second functional module ID set includes the first functional module ID set, the computer outputs information indicating matching.
This object can also be achieved by a computer program that implements the verification apparatus or the verification method having the above configuration by a computer, and a computer-readable storage medium that stores the computer program.

According to the present invention, it is possible to provide a verification device or the like that can easily verify the consistency between the dependency of a system and the dependency of components constituting the system.

FIG. 1 is a block diagram showing a configuration example of a verification apparatus 100 according to the first embodiment for implementing the present invention. FIG. 2 is an example of configuration information managed by the configuration management unit 102 according to the first embodiment that implements the present invention. FIG. 3 is an example of a configuration information change request according to the first embodiment for carrying out the present invention. FIG. 4 is an example of a configuration information acquisition request according to the first embodiment for carrying out the present invention. FIG. 5 is an example of function information managed by the function management unit 103 according to the first embodiment that implements the present invention. FIG. 6 is an example of a function information acquisition request according to the first embodiment for carrying out the present invention. FIG. 7 is an example of a verification request according to the first embodiment for carrying out the present invention. FIG. 10 is a flowchart showing an operation of a requirement definition process for the configuration management unit 102 in the first embodiment for implementing the present invention. FIG. 9 is a flowchart showing an example of the verification processing operation of the verification unit 101 according to the first embodiment of the present invention. FIG. 10 is an example of function information managed by the function management unit 103 according to the second embodiment that implements the present invention. FIG. 11 is an example of configuration information managed by the configuration management unit 102 according to the third embodiment that implements the present invention. FIG. 12 is an example of function information managed by the function management unit 103 according to the third embodiment that implements the present invention. FIG. 13 is an example of a function information acquisition request according to the third embodiment for implementing the present invention. FIG. 14 is a block diagram illustrating a configuration example of the verification apparatus 100 according to the fourth embodiment that implements the present invention. FIG. 15 is an example of function resolution information managed by the function resolution unit 401 according to the fourth embodiment that implements the present invention. FIG. 16 is an example of configuration information managed by the configuration management unit 102 according to the fourth embodiment that implements the present invention. FIG. 17 is an example of external configuration information referred to by the configuration management unit 102 according to the fourth embodiment that implements the present invention. FIG. 18 is an example of resolvable format information managed by the function resolution unit 401 according to the fourth embodiment that implements the present invention. FIG. 19 is an example of a function information acquisition request according to the fourth embodiment for implementing the present invention. FIG. 20 is a flowchart illustrating an operation example of the function information acquisition process of the function management unit 103 according to the fourth embodiment of the present invention. FIG. 21 is a block diagram illustrating a configuration example of the verification apparatus 100 according to the fifth embodiment of this invention. FIG. 22 is a block diagram illustrating the configuration of an information processing apparatus to which each embodiment of the present invention can be applied.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In all the drawings, the same components are denoted by the same reference numerals, and description thereof will be omitted as appropriate.
First, each part which comprises the apparatus etc. which concern on each embodiment demonstrated below is comprised by hardware, such as a logic circuit.
Alternatively, the respective units can be realized by an information processing apparatus (computer) 10 having a general configuration illustrated in FIG. That is, the present invention, which will be described by taking each of the embodiments as an example, includes a storage unit 14 such as a hard disk that stores a control unit, a memory 12, and a computer program (hereinafter simply referred to as “program”) 15 constituting the computer. It may be realized by any combination of hardware resources such as a communication interface (I / F) 13 that is communicably connected to the network 20 and software (program) that cooperates with the hardware resources. And unless there is particular notice, the realization method and apparatus are not limited.
The control unit includes a CPU (Central Processing Unit) 11 and the like, and by executing the program 15 under the management of an OS (Operating System) that operates on the CPU, the apparatus according to each of the embodiments And the like, and the entire apparatus is controlled. Alternatively, the control unit may read a program or data from the recording medium 17 mounted on the drive device 16 or the like to the memory 12 and execute various processes according to the program or data. The recording medium 17 is, for example, an optical disk, a flexible disk, a magnetic optical disk, an external hard disk, a semiconductor memory, or the like, and records the program so that the computer can read it. The program may be obtained from an external computer (not shown) or the like that is communicably connected to the communication network 20.
<First Embodiment>
Next, a first embodiment of the present invention will be described with reference to the drawings.
[Description of configuration]
FIG. 1 is a block diagram showing a configuration example of a verification apparatus 100 according to the first embodiment for implementing the present invention.
As shown in FIG. 1, the verification device 100 according to the first embodiment of the present invention includes a front end 105, a verification unit 101, a configuration management unit 102, a function management unit 103, and a storage device 104.
The front end 105 is communicably connected to the input / output device 110 via a wired or wireless communication line such as a communication network (20). The input / output device 110 is a device external to the verification device 100 that is used by a user to input and output information. Note that the input / output device 110 may be provided inside the verification device 100.
The verification unit 101 receives a verification request input from the input / output device 110 by the user via the front end 105. In accordance with the verification request, the verification unit 101 is based on configuration information obtained from the configuration management unit 102 to be described later and functional information obtained from the function management unit 103 to be described later. Verify the consistency with the dependency of the components that make up the functional module. The operation of the verification unit 101 will be described later.
The storage device 104 stores information (configuration information, see FIG. 2) representing components of the system and components constituting the system, and function information (see FIG. 5) described later.
The configuration management unit 102 manages configuration information stored in the storage device 104. FIG. 2 is an example of configuration information managed by the configuration management unit 102 according to the first embodiment that implements the present invention. In the example shown in FIG. 2, the configuration information is described in an XML (Extensible Markup Language) format, but the format of the configuration information according to the present invention that is described by taking this embodiment as an example is not particularly limited.
System configuration information is described by a system tag. The ID (Identification) of the system is defined by the attribute “id” of the tag “system”. In the example shown in FIG. 2, two systems, system A and system B, are defined.
Further, a component constituting the system is described by a tag “component” corresponding to a child element of a tag “system” defining the system. The ID of the component is defined by the attribute “name” of the tag “component”. In the example shown in FIG. 2, the component of system A is defined as system B.
In addition, the functional module on which the system and its components depend is described by a tag “dependency” that is a child element of the tag “system” that defines the system or component. An ID (functional module ID) for identifying each of one or more functional modules on which the system or component depends is defined by an attribute “name” of the tag “dependency”.
For example, the function module ID on which the system B shown in FIG. 2 depends is “mysql”. The function module ID on which the system A depends is “rdb”. The “rdb” defined by the attribute “name” of the tag “dependency” of the system A in FIG. 2 includes three function module IDs “mysql”, “postresql”, and “oracle”, as shown in FIG. Associated (this association will be described later).
The configuration management unit 102 receives a configuration information change request input by the user via the input / output device 110 via the front end 105, and updates the configuration information according to the content of the request.
Here, the configuration information change request is, for example, a specific system addition request, update request, deletion request, or the like. The request content includes, for example, a request type related to the system and content related to the request target, as shown in FIG. In the example shown in FIG. 3, the request type is shown in the first line of the configuration change request, and the target of the request is shown in the second and subsequent lines.
For example, in the system addition request shown at the top of FIG. 3, “create” indicates that the request is an additional request for the system, and the following description indicates configuration information of the system to be added. ing.
In the system update request shown in the center of FIG. 3, “update” indicates that the request is a system update request, and the following description indicates the system to be updated and its configuration information. Yes.
Further, in the system deletion request shown at the bottom of FIG. 3, “delete” indicates that the request is a system deletion request, and the following description indicates the ID of the system to be deleted. Yes.
In addition, the configuration management unit 102 receives the configuration information acquisition request from the verification unit 101, and returns configuration information regarding the system specified in the request and the components constituting the system.
Here, for example, as shown in FIG. 4, the configuration information acquisition request includes information indicating a configuration information acquisition request and information indicating a target system for which the user wants to acquire configuration information. For example, “getcomp” on the first line in FIG. 4 indicates that the request is a configuration information acquisition request, and the subsequent second line indicates the ID of the information acquisition target system (A in this example). ing.
The storage device 104 stores functional information (see FIG. 5) that includes functional module IDs, functional module IDs, and association information with other functional module IDs.
The function management unit 103 manages function information. FIG. 5 is an example of function information managed by the function management unit 103.
In the example of FIG. 5, the functional module ID is shown, and when another functional module is associated with the functional module, the associated other functional module is displayed in parentheses on the right side of the functional module. It is described collectively. In the example shown in FIG. 5, “mysql”, “postgresql”, “oracle”, “tomcat”, “jetty”, “glassfish”, “rdb”, and “apContainer” are shown as function module IDs. “Rdb” is associated with other function module IDs “mysql”, “postgresql”, and “oracle”. “ApContainer” is associated with “tocat”, “jetty”, and “glassfish”. In the following description, the associated function module ID is also referred to as “associated function module ID”.
Here, consider a case where a functional module ID is described in a tag “dependency” in the system configuration information. In this case, when the function module ID is not associated with another function module ID, the system is expressed as having a dependency on the function module indicated by the function module ID. On the other hand, when the function module ID is associated with another function module ID, the system is expressed as having a dependency on one of the function modules indicated by the other function module ID. And For example, when the tag “dependency” in the system configuration information is <dependency name = X>, and the function module ID X is associated with the IDs of three function modules α, β, and γ The system is expressed as having a dependency on the functional module α, β, or γ (the dependency requirement of the system is also referred to as α, β, γ).
Here, the dependency will be described. When the system has dependencies on the function modules α, β, and γ (that is, when the system dependency requirement is α, β, and γ), at least one of the function modules α, β, and γ If present, it means that the system is available. That is, as the number of functional modules having dependencies increases, the system constraints are relaxed. For example, the constraint condition is relaxed such that the dependency of the system SA can be used if either the database product DA or the database product DB exists, rather than only the database product DA. Therefore, the looser the dependency requirement includes many options, the more the system becomes more independent, and the more the system can be reused.
The function management unit 103 accepts the function information acquisition request from the verification unit 101, and returns the function module ID itself when the function module ID specified in the request is not associated with another function module ID. On the other hand, when another function module is associated with the function module ID, the function management unit 103 returns the other function module ID (associated function module ID). Here, if the function module ID is not associated with another function module ID, the function management unit 103 may return information indicating that there is no association.
Here, for example, as shown in FIG. 6, the function information acquisition request includes information indicating a function information acquisition request and a function module ID. For example, “getfunc” on the first line in FIG. 6 indicates that the request is a function information acquisition request, and the description on the second line indicates the function module ID to be acquired.
The function information returned by the function management unit 103 is the function module ID specified in the request or the associated function module ID. That is, when the function module ID specified in the function information acquisition request is a function module ID for which no association is defined in the storage device 104, the function management unit 103 returns the function module ID itself. Note that the function management unit 103 may return information indicating that the association is not performed. When the functional module ID specified in the request is a functional module ID whose association is defined with another functional module ID in the storage device 104, the function management unit 103 displays all the associated functional modules. An ID (associated function module ID) is returned.
As described above, the verification unit 101 receives a verification request from the user via the front end 105, and based on the configuration information obtained from the configuration management unit 102 and the functional module ID obtained from the function management unit 103, Verify the consistency of consistency of the system and its components with respect to functional modules. Verification processing for performing such verification will be described later.
Here, the verification request includes information indicating that the request is a verification request and an ID indicating the system to be verified. For example, FIG. 7 shows an example of the verification request. “Validate” on the first line in FIG. 7 indicates that the request is a verification request, and the description on the second line indicates the ID of the system to be verified.
[Description of operation]
Next, the operation of the verification apparatus 100 according to the first embodiment of the present invention will be described.
FIG. 8 is a flowchart illustrating an operation example of the requirement definition processing for the configuration management unit 102 according to the first embodiment of this invention.
First, when a request is input from the input / output device 110, the front end 105 checks the content of the first line indicating the type of the request, and this content is a configuration information change request (see FIG. 3). If it is any one of “create”, “update”, and “delete” indicating this, the request is transmitted to the configuration management unit 102 (step S101).
When receiving the configuration information change request, the configuration management unit 102 changes the configuration information according to the type of the request (step S102). Specifically, if the type of request is “create”, that is, addition, the configuration management unit 102 adds system configuration information described in the second and subsequent lines of the request.
If the request type is “update”, that is, update, the configuration management unit 102 uses a system having the same ID as the ID according to the system configuration information and the ID described in the second and subsequent lines of the request. Update the configuration information.
If the request type is “delete”, that is, deletion, the configuration management unit 102 deletes the configuration information of the system having the same ID as the ID according to the system ID described in the second line of the request. To do.
Finally, the configuration management unit 102 outputs the configuration information change result to the input / output device 110 via the front end 105 (step S103). The change result of the configuration information is, for example, information such as a symbol indicating that the change process has been completed and the content of the change.
FIG. 9 is a flowchart showing an operation example of the verification process of the verification unit 101 according to the first embodiment of the present invention.
When the front end 105 receives an input of a request from the input / output device 110, the front end 105 checks the content of the first line indicating the type of the request, and if the content is “validate” indicating that the request is a verification request, the front end 105 The request is transmitted to the verification unit 101 (step S104).
Upon receipt of the verification request (see FIG. 7), the verification unit 101 starts verification with the system having the ID described in the second line of the request as the verification target system.
The verification unit 101 first transmits a configuration information acquisition request (see FIG. 4) including the ID of the system to the configuration management unit 102, and acquires configuration information of the system and all its components from the configuration management unit 102 (see FIG. 4). Step S105).
At this time, the configuration management unit 102 first acquires the configuration information of the system having the ID described in the configuration information acquisition request. Subsequently, the configuration management unit 102 recursively acquires configuration information of components that constitute the system, and transmits all the acquired configuration information to the verification unit 101. Here, recursive means that if the component includes another component, the configuration information of the included component is also acquired. Note that the configuration management unit 102 can acquire the configuration information of the components constituting a certain system based on the IDs described in the attribute “name” of all the tags “component” in the system.
For example, it is assumed that the configuration management unit 102 acquires a configuration information acquisition request from the verification unit 101 for the system whose ID is A as illustrated in FIG. In this case, for example, if the configuration information shown in FIG. 2 exists in the storage device 104, the configuration management unit 102 transmits the two configuration information of the system A and its component B to the verification unit 101.
Next, the verification unit 101 acquires the function module ID described in the attribute “name” of the tag “dependency” in the system configuration information from the acquired configuration information, and acquires a function information acquisition request including the ID (FIG. 6). To the function management unit 103. Further, the verification unit 101 acquires the function module ID described in the attribute “name” of the tag “dependency” in the configuration information of the system component, and acquires a function information acquisition request including the ID (see the lower side in FIG. 6). Is transmitted to the function management unit 103. Then, the verification unit 101 performs functional management on the functional module ID (first functional module ID set) on which the verification target system depends and the ID of the functional module (second functional module ID set) on which the component depends. Obtained from the unit 103 (step S106).
For example, it is assumed that the verification unit 101 obtains the configuration information illustrated in FIG. 2 from the configuration management unit 102. In this case, the verification unit 101 transmits a function information acquisition request including “rdb” to the function management unit 103 in order to acquire the function module ID (first function module ID set) on which the system A depends (FIG. 1). 6 upper reference). Further, the verification unit 101 acquires a function information acquisition request including “mysql” in order to acquire a function module ID (second function module ID set) on which the system B, which is a component of the system A, depends. Reference) is transmitted to the function management unit 103.
Then, the function management unit 103 that has acquired these function information acquisition requests from the verification unit 101 refers to the storage device 104 and sets “mysql” associated with the function module ID of “rdb” as the first function module ID set. Three functional module IDs “,“ postgresql ”, and“ oracle ”are transmitted to the verification unit 101, and at the same time, the ID of the“ mysql ”functional module that is the second functional module ID set is transmitted to the verification unit 101 ( (See FIG. 5). The function management unit 103 may transmit information indicating that there is no association to the verification unit 101 instead of the ID of the “mysql” function module.
Subsequently, the verification unit 101 checks the consistency between the system and its components based on the acquired functional module ID (step S107).
Here, when the second functional module ID set includes the first functional module ID set, the verification unit 101 outputs information indicating matching to the input / output device 110. In other cases, the verification unit 101 may output information indicating inconsistency to the input / output device 101. Also, if the second functional module ID set is a true subset other than the empty set of the first functional module ID set, it is determined that there is a mismatch and information indicating that it is mismatched is entered. You may output to the output device 110.
As a result of transmitting the function information acquisition request including the function module ID depending on the system to the function management unit 103, the verification unit 101 acquires information indicating that the function module ID is not associated from the function management unit 103. In this case, the functional module ID itself is included in the first functional module ID set. In addition, the verification unit 101 transmits, to the function management unit 103, a function information acquisition request including a function module ID on which a component constituting the system depends, and as a result, information indicating that there is no association with the function module ID. When acquired from the unit 103, the function module ID itself is included in the second function module ID set.
The verification process of the verification unit 101 will be described using a specific example. For example, if a system depends on <"mysql", "postgresql"> (ie, if the first functional module ID set is "mysql", "postgresql"), its components are <"mysql", "postgresql". When it depends on “″,” oracle ”> (that is, when the second functional module ID set is“ mysql ”,“ postgresql ”,“ oracle ”), the verification unit 101 enters information indicating matching. Output to the output device 101.
Also, when a certain system depends on <"mysql", "postgresql", "oracle">, the components are <"mysql">, <"postgres">, <"oracle">, <"mysql". If it depends on the function module indicated by any of the function module IDs of “,“ postgresql ”>, <“ postgresql ”,“ oracle ”>, <“ mysql ”,“ oracle ”>, the verification unit 101 does not. Judged to be consistent. The reason will be described using a specific example.
For example, an example will be described in which a certain system depends on <“mysql”, “postgresql”, “oracle”>, and components constituting the system depend on <“mysql”, “postgresql”>.
If a system depends on <“mysql”, “postgresql”, “oracle”>, the system can be used with any of the function modules “mysql”, “postgresql”, and “oracle”.
If the component depends on <“mysql”, “postgresql”>, the component can be used if any of the functional modules “mysql” or “postgresql” is provided. Therefore, even if “oracle” which is another functional module exists, the component is not available.
As a result, even if a “module” functional module exists, the component cannot be used, and thus the system including the component cannot be used.
However, this is consistent with the fact that the system can be used if there is a function module of “mysql”, “postgresql”, or “oracle” (that is, if there is a function module of “oracle”). Not taken. Therefore, in this case, the verification unit 101 determines that the system dependency requirement and the component dependency requirement are inconsistent.
If the dependency requirement of the system or component is an empty set, it means that there is no dependency requirement. Therefore, the system or component does not depend on any functional module, which is inconsistent. There is nothing. Therefore, if the system dependency requirement is an empty set, the verification unit 101 determines that the system is consistent. For example, when there is no information regarding the tag “dependency” in the configuration information of a certain system or component, the dependency requirement is an empty set because the system or component has no dependency.
In addition, when a system depends on <"mysql", "postgresql"> and components constituting the system depend on <"mysqll", "postgresql", "oracle">, the system is "mysql". And “postgresql” are used, the components are available, so that the matching is achieved.
Finally, the verification unit 101 transmits the verification result to the user terminal 110 via the front end 105 (step S108).
The verification result only needs to include information such as a symbol indicating matching or mismatching. The verification unit 101 may add detailed information such as an ID indicating a functional module on which the system depends on the cause of the mismatch or an ID of a component dependent on the functional module to the verification result.
According to the present embodiment, it is possible to easily verify the consistency between the system dependency and the component dependency.
<Second Embodiment>
[Description of configuration]
Next, a second embodiment of the present invention will be described. Elements similar to those in the first embodiment are denoted by the same reference numerals as those in FIG. 1, and detailed description thereof is omitted.
FIG. 10 is an example of function information managed by the function management unit 103 according to the second embodiment of this invention. In this example, the function information indicates the function module ID and information for associating the function module with another function module, as in the first embodiment, but the associated function module ID is further different. The configuration of being associated with the functional module ID is different from that of the first embodiment.
In this example, “db” is associated with “rdb”, “kvs”, “rdb” is associated with “mysql”, “postgresql”, “oracle”, and “kvs” is “simpledb”, “ associated with coachdb ". That is, “db” includes “rdb” and “kvs”, “rdb” includes “mysql”, “postgresql”, and “oracle”, and “kvs” includes “simpledb” and “couchdb”. It can also be understood as a set relationship (or tree structure) that includes.
[Description of operation]
Next, the operation of the verification apparatus 100 according to the second embodiment of the present invention will be described.
The operation of the verification apparatus 100 in the second embodiment is the same as that in the first embodiment in steps S104, S105, S107, and S108 shown in FIG. On the other hand, in the operation of step S106, the configuration in which the function management unit 103 recursively searches the function module ID association information and collects the associated function module IDs is different from the first embodiment. Here, “recursively search and collect associated function module IDs” means that when another function module ID is associated with a certain function module ID, the other function module ID is further When the function module ID is associated with another function module ID, the associated function modules are sequentially searched to obtain all the function module IDs associated with a certain function module ID.
That is, when the function management unit 103 receives a function information acquisition request from the verification unit 101, the function management unit 103 searches for another function module ID associated with the function module ID specified in the request.
When the function module ID acquired by the search is further associated with another function module ID, the function management unit 103 searches for the further associated function module ID and further associates the function module ID. When the ID is not found, the function module ID (end point function module ID) is acquired.
When the function management unit 103 acquires all end function module IDs, the function management unit 103 returns the function module IDs to the verification unit 101, and the verification unit 101 acquires these pieces of information.
As an example, the operation when the function information shown in FIG. 10 exists in the storage device 104 and the function management unit 103 receives a function information acquisition request regarding “db” will be described.
The function management unit 103 first searches for “db” to find the definition of “db (rdb, kvs)” in the storage device 104, and is enclosed in parentheses on the right side of “db”. Since there is a set of associated functional module IDs, the functional module IDs are searched recursively.
Since “rdb” and “kvs”, which are elements of “db”, have function module IDs associated with each other, the function management unit 103 sets “mysql”, “postgresql”, and “oracle”, respectively. “Simpledb” and “couchdb” are obtained from the storage device 104. When the function management unit 103 further recursively searches for these function module IDs, the function management unit 103 recognizes that no further associated IDs are found. Therefore, the function management unit 103 returns “mysql”, “postgresql”, “oracle”, “simpledb”, and “couchdb” to the verification unit 101.
According to this embodiment, dependency requirements related to many functional modules can be expressed more easily and efficiently. Therefore, consistency between the system related to the dependency requirements and the components constituting the system is improved. Verification work can be made more efficient.
<Third Embodiment>
[Description of configuration]
In the third embodiment of the present invention, a configuration in which a user or the like can add an attribute to each of the part that specifies the dependency of the configuration information and the function information, and the function information acquisition that the function management unit 103 accepts A configuration in which a user or the like can add attribute information to the request is different from that of the first embodiment. The other configuration is the same as that of the first embodiment. The same elements as those in the first embodiment are denoted by the same symbols as those in FIG. 1, and the detailed description in this embodiment is omitted.
FIG. 11 is an example of configuration information managed by the configuration management unit 102 according to the third embodiment that implements the present invention.
As shown in the example of FIG. 11, the configuration information in the present embodiment is different from the configuration information in the first embodiment in that an attribute can be added to the part for specifying the dependency. In the example shown in FIG. 11, “rdb” is specified as the function module ID on which the system A depends, and “oss” is added as the attribute “attribute”.
FIG. 12 is an example of function information managed by the function management unit 103 according to the third embodiment.
As shown in the example of FIG. 12, the functional information in the present embodiment is different from the functional information in the first embodiment in that the user can add an attribute to each functional module ID.
In this example, the added attribute is described as a pair of attribute name and value in square brackets placed on the right side of each element, and the attribute name and value are expressed in a format delimited by the symbol “=”. .
That is, in this example, “oss” is added as an attribute attribute of “mysql” and “postgresql”, and “commercial” is added as an attribute “attribute” of “orange”.
FIG. 13 is an example of a function information acquisition request according to the third embodiment.
As shown in FIG. 13, the function information acquisition request received by the function management unit 103 in this embodiment is configured such that an attribute can be added to the function module ID indicating the acquisition target. Different from information acquisition request. As illustrated in FIG. 13, the added attribute is described as a pair of attribute name and value in square brackets arranged on the right side of the functional module ID to be acquired. The attribute name and value are indicated by “=”. Expressed in a delimited format. That is, in this example, the function module ID to be acquired is “rdb”, and “oss” is added as the attribute “attribute”.
[Description of operation]
Next, an operation example of the verification apparatus 100 according to the third embodiment of the present invention will be described.
The operation of the verification apparatus 100 in the present embodiment is the same as that in the first embodiment in steps S104, S105, S107, and S108 shown in FIG. On the other hand, in the present embodiment, in step S106, the function management unit 103 verifies only the function module IDs whose attributes match, as well as the acquisition target function module IDs included in the function information acquisition request. The configuration of replying to is different from that of the first embodiment.
In other words, in the present embodiment, when the function management unit 103 receives the function information acquisition request from the verification unit 101, all the function module IDs associated with the ID are based on the function module ID specified in the request. Search for.
Subsequently, when an attribute is specified in the request, the function management unit 103 extracts only the function module ID to which the same attribute is added from the function module IDs found by the search. This is the function module ID that finally responds.
As an example, a description will be given of an operation example when the function information shown in FIG. 12 exists in the function management unit 103 and the function management unit 103 receives the function information acquisition request shown in FIG.
First, the function management unit 103 searches for a function module ID associated with “rdb” to obtain “mysql [attribute = oss]”, “postgresql [attribute = oss]”, and “oracle [attribute = commercial]”. Find three functional module IDs.
Subsequently, since the attribute “attribute = oss” is added to the “rdb” that is the acquisition target indicated by the function information acquisition request, the function management unit 103 includes the attribute attribute among the searched function module IDs. Only those whose value is “oss” are extracted, and the function module IDs returned to the verification unit 101 are set to “mysql” and “postgresql”.
The function management unit 103 extracts only elements having attribute name / value pairs added in the function information acquisition request at the time of search. However, the function management unit 103 extracts elements having no corresponding attribute or Elements other than attribute name / value pairs may be extracted. The function management unit 103 may further control the extraction method of the function module ID based on the attribute as described above by adding a meta attribute.
According to the present embodiment, dependency requirements can be efficiently expressed even when the functional module classification is complicated, and the consistency verification work between the system related to the dependency requirements and its components can be made efficient. .
<Fourth Embodiment>
[Description of configuration]
FIG. 14 is a block diagram illustrating a configuration example of the verification apparatus 100 according to the fourth embodiment that implements the present invention.
As illustrated in FIG. 14, the verification apparatus 100 according to the fourth embodiment of the present invention relates to a function resolution unit 401 that associates an ID (external system ID) in a specific ID system with a function module ID in the function information. Is different from the first embodiment. Also, the configuration of including a file processing module group 402 for extracting the external system ID included in the file from a specific format file is different from that of the first embodiment.
Elements similar to those in the first embodiment are denoted by the same symbols as those in FIG. 1 and detailed description thereof is omitted.
The storage device 104 records function solution information. The function resolution information is information that associates an ID (external system ID) in the specific ID system with the function module ID managed by the function management unit 103. The function resolution information is managed by the function resolution unit 401. The function resolution unit 401 is communicably connected to the function management unit 103 and the storage device 104.
FIG. 15 is an example of function resolution information managed by the function resolution unit 401. In the example shown in FIG. 15, an external system ID in a certain ID system is described in a tag “aliases”, and information indicating the ID system is described by an attribute “type” of the tag. A plurality of tags “alias” are listed in the tag “aliases”, and each tag “alias” describes information that associates an external system ID and a functional module ID in the ID system. For example, in the tag “alias”, an external system ID in the ID system is described in the attribute “name”, and a function module ID associated with the external system ID is described in the attribute “value” in the tag.
In the example shown in FIG. 15, it is first declared that information for associating an external system ID and a functional module ID in the “maven” ID system is described by an attribute “type” of the tag “aliases”. Further, in the example shown in FIG. 15, “mysql: mysql-connector-java: 5.1.17” and the function module ID “mysql” in the ID system of “maven” by the tag “alias” in the tag “aliases”. "Is associated with the symbol" = ".
FIG. 16 is an example of configuration information managed by the configuration management unit 102 according to the fourth embodiment, and FIG. 17 is stored in an external storage device or the like referenced by the configuration management unit 102 according to the fourth embodiment. It is an example of the made external file.
In the present embodiment, it is possible to define information related to the dependency requirements of the system and its components by referring to an external file. For example, in the configuration information shown in FIG. 16, when the dependency of the system B is defined by reference to an external file, the position information of the external file is specified by a ref attribute in the tag “dependency”, and the format of the file Is specified by the attribute “type”. That is, in the configuration information shown in FIG. 16, the dependency of the system B is defined by an external file specified by “/xxx/xxx/pom.xml”, and the file format (external file format name) is the format “maven”. ". Here, the name indicating the ID system and the format name of the external file are associated with each other and have the same name, but they may not be the same.
FIG. 17 illustrates the contents of the external file. In the “maven” file “pom.xml”, the dependency on the module is described by the tag “dependencies”, and the information of each dependency is described by the tag “dependency”.
The tag “dependency” includes a tag “groupId”, a tag “artifactId”, a tag “version”, and the like. In “maven”, the dependency is defined by at least these three pieces of information (tag “groupId”, tag “artifactId”, and tag “version”). In this example, “groupId” is defined as “mysql”, “artifactId” is defined as “mysql-connector-java”, and “version” is defined as “5.1.17”.
The format of the external file that can be resolved by the function resolution unit 401 is managed by the function resolution unit 401 as resolvable format information and recorded in the storage device 104. FIG. 18 is an example of resolvable format information managed by the function resolution unit 401 according to the fourth embodiment.
The resolvable format information illustrated in FIG. 18 includes two items: the format name of the external file and the name (module name) of the processing module that extracts the external system ID from the file in the format indicated by the format name of the external file. Tabular information consisting of is recorded. For example, module 1 can extract an external system ID from an external file of the format “maven” (format “maven” can be solved by module 1).
The processing module may be incorporated by a user or the like in a state that can be called from the function resolution unit 401 as a plug-in for each format.
FIG. 19 is an example of a function information acquisition request according to the fourth embodiment for implementing the present invention.
The function information acquisition request in the present embodiment includes, for example, the location information of the external file to be referenced instead of the function module ID to be acquired and the format name of the external file.
In the example shown in FIG. 19, the format name of the external file and the position of the file are described by being separated by “:”. Specifically, in FIG. 19, “maven” is designated as the format name of the external file, and “/xxx/xxx/pom.xml” is designated as the file position.
The function management unit 103 according to the present embodiment acquires function information using the function resolution unit 401 based on the above-described external file format name and file position information.
[Description of operation]
Next, an operation example of the verification apparatus 100 according to the fourth embodiment for carrying out the present invention will be described with reference to FIG. The same operations as those in the first embodiment are denoted by the same symbols as those in FIG. 9, and detailed description thereof is omitted. Since steps other than step S106 are the same as those of the first embodiment shown in FIG. 9, the steps will be described.
FIG. 20 is a flowchart illustrating an operation example of the function information acquisition process of the function management unit 103 according to the fourth embodiment. The verification unit 101 according to the present embodiment performs the function module ID acquisition process illustrated in FIG. 20 for the information described in the tag “dependency” in the configuration information acquired from the configuration management unit 102 during the verification process. To do.
First, the verification unit 101 confirms the content of the tag “dependency” and determines whether an external file is referenced within the tag “dependency” (step S401).
When referring to such an external file (in the case of “YES” in step S401), the verification unit 101 sets the format name and attribute “ref” of the external file specified in the attribute “type” of the tag “dependency”. The position of the described external file is acquired, and a function information acquisition request (see FIG. 19) including these pieces of information is transmitted to the function management unit 103 (step S404). For example, in FIG. 16, the format name of the external file specified in the attribute “type” of the tag “dependency” is “maven”, and the position of the external file described in the attribute “ref” is “/ xxx / xxx”. /Pom.xml ". Further, as shown in FIG. 19, the function information acquisition request including these pieces of information indicates that the request is a function information acquisition request by “getfunc” on the first line, and the symbol “:” on the second line that follows. The format name of the external file is before the symbol, and the position information of the external file is after the symbol “:”.
The function management unit 103 determines whether “:” is included in the received function information acquisition request. If included, the function management unit 103 transfers the function information acquisition request to the function resolution unit 401 (step S405).
Upon receiving the function information acquisition request, the function resolution unit 401 extracts the part before the symbol “:” as the format name of the external file, and extracts the part after the symbol “:” as the position information of the external file. The function resolution unit 401 acquires an external file (see FIG. 17) based on the position information of the external file. Further, the function resolution unit 401 identifies processing modules in the file processing module group 402 corresponding to the format name of the external file by referring to the resolvable format information (see FIG. 18). Then, the function resolution unit 401 acquires the external system ID based on the system of the format by processing the acquired external file in the specified processing module (step S406).
For example, consider a case in which the function information acquisition request shown in FIG. 19 is transmitted from the verification unit 101 to the function management unit 103, and the external file shown in FIG. 17 and the resolvable format information shown in FIG. In this case, the function management unit 103 first acquires “maven” as the external file format name and “/xxx/xxx/pom.xml” as the external file position information. The function management unit 103 acquires the external file shown in FIG. Further, the function management unit 103 identifies that the processing module corresponding to “maven” is “module 1” by referring to the resolvable format information shown in FIG. Send to.
The module 1 is implemented with a process for extracting an external system ID in “maven” from a file having the format “maven”. The module 1 acquires the information described by the tags “groupId”, “artifactId”, and “version” from the file shown in FIG. 17, concatenates the acquired information by “:”, and “mysql: mysql-connector-java: 5.1.17 ″ external system ID is acquired.
Next, the function resolution unit 401 refers to the function resolution information (see FIG. 15), and the function corresponding to the function information managed by the function management unit 103 using the external system ID acquired by the module in the file processing module group 402. The module ID is converted to the module ID, and the function module ID obtained by the conversion is transmitted to the function management unit 103 (step S407). As in the first embodiment, the function management unit 103 acquires the acquired function module ID or the function module ID associated with the function module ID. The function management unit 103 transmits these function module IDs to the verification unit 101. Then, the verification unit 101 acquires the functional module ID on which the verification target system and its components depend from the function management unit 103 (step S403).
When the external file is not referred to in the tag “dependency” (“NO” in step S401), the subsequent operation is the same as the function information acquisition process (step S106) in the first embodiment. is there. That is, the verification unit 101 acquires the function module ID described in the attribute “name” of the tag “dependency”, and transmits a function information acquisition request including the function module ID to the function management unit 103 (step S402). The verification unit 101 acquires the functional module ID on which the verification target system and its components depend from the function management unit 103 (step S403).
In the above description, after the module in the file processing module group 402 extracts the external system ID from the external file, the function resolution unit 401 converts the external system ID into the functional module ID. However, the present invention is not limited to this example. For example, a module in the file processing module group 402 may directly convert an external system ID into a functional module ID by referring to the function resolution information. Further, the function solution information may be stored not in the storage unit 104 but in an external storage unit (not shown).
According to the present embodiment, even if the system of ID that defines the dependency described in the configuration information of the system or component is different from the system of functional module ID in the function information, the system and component Verification of the consistency of dependency requirements between Further, according to the present embodiment, it is possible to achieve flexibility in description of ID. This allows the user to use the information that defines the dependencies described for the use of other system development support functions, and to add dependencies between the system and its components without adding any other information. Can verify the consistency of requirements.
<Fifth Embodiment>
Next, a fifth embodiment of the present invention will be described.
The verification device 100 according to the present embodiment includes a storage device 104, a function management unit 103, and a verification unit 101.
The storage device 104 stores functional module IDs and association information between functional module IDs and other functional module IDs.
The function management unit 103 acquires a function module ID (a specific function module ID to be verified) input from the outside. The ID or information including the ID is input from the verification unit 101, for example.
The function management unit 103 refers to the storage device 104, and extracts another function module ID and outputs it to the verification unit 101 when another function module is associated with the function module ID. In addition, when the input function module ID is not associated with another function module ID, the function management unit 103 verifies the input function module ID itself or information indicating that there is no association. 101.
The verification unit 101 inputs a function module ID corresponding to each of one or more function modules on which the system depends to the function management unit 103. As a result, the verification unit 101 acquires information indicating that there is no functional module ID or association from the function management unit 103.
When the verification unit 101 acquires the functional module ID, it is set as a first functional module set.
When the verification unit 101 acquires information indicating that there is no association, the function module ID input to the function management unit 103 is set as the first function module set.
That is, the verification unit 101 sets a set of functional module IDs on which the system depends as a first functional module set.
The verification unit 101 inputs a function module ID corresponding to each of one or more function modules on which components constituting the system depend, to the function management unit 103. As a result, the verification unit 101 acquires information indicating that there is no functional module ID or association from the function management unit 103.
When the verification unit 101 acquires the functional module ID, it is set as the second functional module set.
When the verification unit 101 acquires information indicating that there is no association, the function module ID input to the function management unit 103 is set as the second function module set.
That is, the verification unit 101 sets a set of functional module IDs on which components depend as a second functional module set.
When the second functional module ID set includes the first functional module ID set, the verification unit 101 outputs information indicating matching to the input / output device 101 or the like. In other cases, the verification unit 101 may output information indicating inconsistency to the input / output device 101. The verification unit 101 also displays information indicating that the second functional module ID set acquired from the function management unit 103 is inconsistent when the second functional module ID set is a true subset that is not an empty set of the first functional module ID set. You may output to the input / output device 101 grade | etc.,.
According to the present embodiment, it is possible to verify the consistency between the system dependency and the component dependency with respect to the dependency on the functional module. Therefore, development of a highly reusable system is promoted. In addition, according to the present embodiment, it becomes easy to set the dependency requirement including the constraint condition, so that the number of work steps can be reduced and mistakes such as omission of setting can be prevented.
The present invention has been described above using the above-described embodiments as exemplary examples. However, the present invention is not limited to the above-described embodiments. That is, the present invention can apply various modes that can be understood by those skilled in the art within the scope of the present invention.
This application claims the priority on the basis of Japanese application Japanese Patent Application No. 2011-229043 for which it applied on October 18, 2011, and takes in those the indications of all here.

10 Information processing device (computer)
11 CPU
12 Memory 13 Communication interface (I / F)
DESCRIPTION OF SYMBOLS 14 Storage apparatus 15 Computer program 16 Drive apparatus 17 Storage medium 20 Communication network 100 Verification apparatus 101 Verification part 102 Configuration management part 103 Function management part 104 Storage apparatus 105 Front end 110 User terminal 401 Function resolution part 402 File processing module group

Claims (10)

1. Storage means for storing a functional module ID and association information between the functional module ID and another functional module ID;
   With reference to the storage unit for the specific functional module ID to be verified, when the specific functional module ID is associated with the other functional module ID, the other functional module ID is output. And if not associated, a function management means for outputting information indicating that there is no specific function module ID or association;
   When the function module ID on which the first system depends is input to the function management unit as the specific function module ID, if at least one of the function module IDs is acquired from the function management unit, the function module ID is acquired. When the function module ID is the first set of function module IDs and information indicating that there is no association is acquired from the function management unit, the function module ID is input to the function management unit as the specific function module ID. The function module ID thus obtained is set as the first function module ID set,
   When the function module ID on which the second system constituting the first system depends is input to the function management unit as the specific function module ID, at least one of the function module IDs is input from the function management unit. If acquired, the acquired functional module ID is set as the second functional module ID set, while if the information indicating that there is no association is acquired from the functional management unit, the specific functional module The function module ID input to the function management means as an ID is used as the second function module ID set,
   Verifying means for outputting information indicating matching when the second functional module ID set includes the first functional module ID set;
   A verification apparatus comprising:
2. The function management means includes
   The verification device according to claim 1, wherein when the functional module ID associated with the functional module ID acquired from the outside is further associated with the other functional module ID, the other functional module ID is extracted. .
3. The storage means stores the functional module ID to which an attribute condition is added,
   The function management unit acquires the function module ID to which the attribute condition is added, extracts the function module ID to which the same attribute condition as the attribute condition is added, and outputs the function module ID. The verification device according to claim 1 or 2.
4. The storage means associates and stores a format name of an external file and a module name from which the functional module ID can be extracted from the contents of the external file,
   Obtain the input external file name and the format name of the external file, and based on the acquired external file name, acquire the content of the external file from the outside,
   By referring to the storage means, the module specified by the module name associated with the acquired format name is caused to extract the function module ID from the acquired external file, and the function module ID is set to the function The verification apparatus according to claim 1, further comprising a function solving unit that outputs to the management unit.
5. In a computer provided with storage means for storing a functional module ID and association information between the functional module ID and another functional module ID,
   With reference to the storage unit for the specific functional module ID to be verified, when the specific functional module ID is associated with the other functional module ID, the other functional module ID is output. In the case of not being associated with each other, a function management process for outputting information indicating that there is no specific function module ID or association;
   When a function module ID on which the first system depends is input to the function management process as the specific function module ID, if at least one of the function module IDs is acquired by the function management process, the acquisition is performed. If the information indicating that there is no association is acquired by the function management process while the function module ID is the first function module ID set, the function management process is used as the specific function module ID. The function module ID input to is set as the first function module ID set,
   When the function module ID on which the second system constituting the first system depends is input to the function management process as the specific function module ID, and the function module ID is acquired by the function management process When the acquired function module ID is used as the second function module ID set, and information indicating that the association is not found is acquired by the function management process, the function management is used as the specific function module ID. The function module ID input to the process is set as the second function module ID set.
   A verification process for outputting information indicating matching when the second functional module ID set includes the first functional module ID set;
   Verification program that executes
6. The function management process includes:
   The verification program according to claim 5, wherein when the functional module ID associated with the functional module ID acquired from the outside is further associated with the other functional module ID, the other functional module ID is extracted. .
7. The storage means stores the functional module ID to which an attribute condition is added,
   The function management processing acquires the function module ID to which the attribute condition is added, extracts the function module ID to which the same attribute condition as the attribute condition is added, and outputs the extracted function module ID. The verification program according to claim 5 or claim 6.
8. The storage means associates and stores the external file format name and the module name from which the functional module ID can be extracted from the content of the external file,
   Obtain the input external file name and the format name of the external file, and based on the acquired external file name, acquire the content of the external file from the outside,
   By referring to the storage means, the module specified by the module name associated with the acquired format name is caused to extract the function module ID from the acquired external file, and the function module ID is set to the function The verification program according to claim 5, wherein the computer executes a function solution process to be output to a management process.
9. By the computer, the function module ID and the association information between the function module ID and another function module ID are stored in a storage unit for storing,
   When the computer refers to the storage unit for a specific functional module ID to be verified, and the specific functional module ID is associated with the other functional module ID, the other functional module ID On the other hand, if it is not associated, it outputs information indicating that there is no specific functional module ID or association,
   When at least one of the functional module IDs is acquired when the computer inputs the functional module ID on which the first system depends as the specific functional module ID, the acquired functional module ID is On the other hand, when the information indicating that there is no association is obtained while the first functional module ID set, the functional module ID input as the specific functional module is set as the first functional module ID set,
   When at least one of the functional module IDs is acquired by the computer when the functional module ID on which the second system constituting the first system depends is input by the computer, the acquired functional module ID is On the other hand, when information indicating that there is no association is acquired, the function module ID input as the specific function module ID is set as the second function module ID set.
   A verification method for outputting information indicating matching when the second functional module ID set includes the first functional module ID set by the computer.
10. The verification method according to claim 9, wherein when the functional module ID associated with the functional module ID acquired from the outside is further associated with the other functional module ID, the other functional module ID is extracted. .

Images