JPH06242930A - Problem solving device - Google Patents

Abstract

PURPOSE:To reduce the influence of the change of respective modules on the other modules at the time of solving a problem by the mutual operations of the respective modules. CONSTITUTION:This problem solving device for realizing problem solution by the mutual action of the plural modules M1-Mn is provided with a module management mechanism 1 for controlling mutual calling among the respective modules. When the values of prescribed attributes are to be decided by utilzing the other modules, the respective modules supply the required attributes to the module management mechanism 1 and issue requests. When the requests are received, the module management mechanism 1 retrieves the module whose goal attribute is the attribute whose value is to be obtained and calls the module.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a problem solving apparatus which realizes problem solving by modularizing a program and interaction of each module.

[0002]

2. Description of the Related Art In recent years, a programming style (object-oriented programming) in which a program is made into a module and a problem is solved by their interaction is drawing attention. In this object-oriented programming,
One object activates another object in the form of a message, and the object that receives the message interprets the message internally and performs the corresponding process internally. Further, it is possible for this object to send messages to other objects during this process.

By the way, in the conventional programming style including an object-oriented language, when one program module calls another program module, the call is made by calling the name of the called module and the arguments defined by the calling module. It was done by directly specifying in.

[0004]

However, if the relationship between the "function" to be called and the "module name" to be called is fixed in the program as described above, the change of the called module There was a problem that it was necessary to rewrite the calling module. For example, when changing the arguments when calling a module, when multiple functions that were realized in one module until now are divided into multiple modules, and when replacing existing functions with new objects, etc. It will be necessary to rewrite all modules that call. Furthermore, from the viewpoint of program efficiency, usually related functions are implemented by one object, and a method of selecting a function with an argument is often used. However, since the module name is not the function name itself, It makes the readability of the program worse.

The present invention solves such a conventional drawback, and when the problem is solved by the interaction of each module, it is possible to reduce the influence of the change of each module on other modules. It is intended to provide a problem solving device.

[0006]

In order to achieve the above object, the invention according to claims 1 and 2 has a module management means for controlling mutual calls between modules, and each module is When it is desired to determine the value of a predetermined attribute by using another module, the required attribute is given to the module management means to issue a request, and when the module management means receives the request, the attribute desired to obtain the value. It is characterized in that a module having a goal attribute is searched for and the module is called. Further, in the invention according to claim 3, when the module management unit calls a certain module and executes the process, if the value of the attribute required for executing the process in the module is not yet determined, A feature is that a module having an attribute as a goal attribute is searched and the module is called. As described above, in the present invention, each module can call another module by designating a required attribute.

The inventions according to claims 4 and 5 are:
It is characterized in that the module management means calls a module by referring to a correspondence table that stores the goal attributes indicating the function of each module and the calling format of the module in association with each other. I am trying. As a result, when the module name or argument of a module is changed or the module is divided, the module management means only needs to update the correspondence table without affecting each module. I'm done.

The invention according to claim 6 is characterized in that the correspondence table is constructed so that it can be referred to by a user. As a result, the programmer can refer to the above correspondence table when developing a new module, and can easily grasp which function is already provided in the current system.

The invention according to claim 7 is further provided with a synonym dictionary capable of calling the same attribute in a plurality of different vocabularies, and the module management means refers to the synonym dictionary to identify the attribute. The feature is that it is designed to do. This allows calling modules with the same goal attribute in different vocabularies.

[0010]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a configuration diagram of an embodiment of a problem solving device according to the present invention. Referring to FIG. 1, the problem solving apparatus according to the present exemplary embodiment performs a module M _{1 to} M _n that is modularized and programmed into a plurality of modules (for example, n) and a mutual call between the modules M _{1 to} M _n. The module management mechanism 1 to be controlled, the correspondence table 2 referred to by the module management mechanism 1, the synonym dictionary 3 referred to by the module management mechanism 1, and variables used when each module M _{1 to} M _n solves a problem. And an attribute set unit 4 which is a set of various attributes C _{1 to} C _k .

Here, each of the modules M _{1 to} M _n is configured as a module group of reusable programs, and each module can realize a plurality of new functions by utilizing the functions provided by other modules. It has become. Further, the attributes C _{1 to} C _k are determined according to an object (for example, a product such as “FAX”) for which a problem is to be solved, and when the object is, for example, “FAX”, the attributes (that is, the attributes Name) C _{1 to} C _k , respectively, for example, “cost”, “status”, “user name”, “processing”, “fault cause”, “fault treatment”, “product name”, “maintenance history”, respectively. It can be defined as “file”, “maintenance check”, ... Further, each of the attributes C _{1 to} C _k can have an attribute value (a value that a variable takes), and each of the attributes C _{1 to} C _k can be assigned to each of the attributes C _{1 to} C _k in the process of problem solving by each of the modules M _{1 to} M _n. The attribute value of each is determined. For example, the attribute of "user name" is "Tanaka"
Alternatively, “Suzuki” or the like can have an attribute value, and the “processing” attribute can have “CAUSE (cause)” or “REPAIR (treatment)” as an attribute value. When the attribute does not have an attribute value yet, this attribute is a variable, and when this attribute has an attribute value, that attribute is a constant. Further, as will be described later, each of the attributes C _{1 to} C _k can be an input attribute,
In addition, it has the property that it can also be a goal attribute.

FIG. 2 is a diagram showing a basic structure of each of the modules M _{1 to} M _n , and one module is composed of a module name, a specification description section, and a procedure description section. Here, the module name is a name given to the module, for example, the module name of the module M ₁ is “diagnosis. module ”, the module name of the module M ₂ is“ maintenance status module ”, the module name of the module M ₃ is“ maintenance report For example, "module" can be attached according to the user's preference.

The processing procedure of this module is described in the procedure description section of the module.

The specification description section of the module is provided with input attributes I _{1 to} I _i which are input conditions necessary for the module to perform the processing procedure described in the procedure description section, and the input is given to the specification description section. The goal attribute O to be obtained when the module executes the processing procedure is described. For example, when this module receives a process, a user name, and a situation as an input, and functions to obtain a solution for some failure cause and / or failure action based on this input, the specification description of this module In the department,
As the input attributes I _{1 to} I _i , “process”, “user name”,
Each attribute of “situation” is described, and as the goal attribute O, attributes of “fault cause” and / or “fault treatment” are described. In this case, the module is adapted to determine the attribute values of the goal attributes "fault cause" and / or "fault treatment" as a solution.
In order for this module to execute the processing procedure and determine the solution, the attribute values of the input attributes “processing”, “user name”, and “situation” are set in advance before the processing procedure of this module is executed. It has been decided, and its attribute value must be decided during the processing procedure execution. For example,
Regarding the input attribute “user name”, for example, the attribute value of “Tanaka” must be determined before execution of the processing procedure, or must be determined during execution of the processing procedure.

By the way, each module M _{1 to} M _n can call another module in the processing and determine the attribute value necessary for the processing by utilizing the function of the other module. . At that time, in this embodiment,
It is configured to call other modules by specifying an attribute (attribute name) whose value is to be obtained, instead of calling the module name or the like as in the conventional case.

Specifically, in the procedure description part of the module, the function "call" using the attribute whose value is to be obtained as an argument service ”
By writing, it is possible to specify the call of another module. Note that the function "call servic
e ”further includes input attributes as input conditions, and /
Alternatively, a pair of an input attribute and its attribute value can be described as an argument. Also, the function "call service ”is
It is a general-purpose function that can be used in all modules. In this case, what this module specifies is the attribute whose value you want to get, and you don't need to know which other module actually handles this call.

Alternatively, it is possible to describe an attribute whose value is to be determined by another module as an input attribute in the specification description part of the module. At this time, since the attribute value of this input attribute has not been determined in the processing procedure of this module, another module capable of determining the attribute value of this input attribute is automatically called, and The module determines the attribute value. Thus, again, this module does not need to know in which module this call is actually handled.

In the procedure description part of the module, the function "ca
ll When the attribute is specified using "service" or the input attribute is described in the specification description section, the process of selecting another module for determining the value of the attribute is , The module management mechanism 1.

That is, the module management mechanism 1 refers to the correspondence table 2 and the synonym dictionary 3 in response to a request for determining the value of an attribute from a certain module, and refers to the other module that uses the requested attribute as a goal attribute. It is meant to select (ie, a module that can determine the value of the requested attribute) and call it. When processing is performed in another called module and the requested attribute value is determined, the module management mechanism 1 returns the attribute value to the module that issued the request.

When a module, for example, M ₁ requests another module, for example, M ₂ to call and perform processing, a request for determining the attribute value may be issued. Or a module,
For example it may further request is made during the process execution M ₂ from the module M _2. Therefore, the module management mechanism 1 may receive a plurality of requests REQ _{1 to} REQ _j in the process until the value of the attribute is finally determined.
Such to deal with multiple requests REQ ₁ to REQ _j, as shown in each request REQ ₁ to 3 a process for the REQ _j, so that the respective handle an event IVT ₁ to IVT _j. That is, the module management mechanism 1 generates a new event each time there is a request,
The request is processed as an event. At that time, the respective events IVT _{1 to} IVT _j are linked to each other using, for example, an event management table. Specifically, for example, a request REQ ₁ from _one module M ₁ causes another module M ₁ to
_When calling ₂ to perform processing, event I
VT ₁ is generated, performs the process in the event IVT _1, in the processing process of the event IVT _1,
When another request REQ ₂ is issued, the event IVT ₂
Is generated and the processing in this event IVT ₂ is performed. In this case, links the event IVT ₂ in the event IVT _1, event IVT ₁ is adapted to receive the processing result of the event IVT _2. That is, Event IV
T ₁ is in a waiting state until the processing of event IVT ₂ is completed. When there are a plurality of requests in this way, events corresponding to the number of requests are generated and registered as a queue (queue), and the events are linked to each other in a parent-child relationship.

FIG. 4 is a diagram showing an example of the correspondence table 2. In the correspondence table 2, the function of the module (that is, the goal attribute of the module) and the calling format of the module are stored in association with each other. There is. Here, this correspondence table 2 includes the attribute information (goal attribute, input attribute) described in the specification description part of the module, for example, when the problem solving device is initialized or when the module is changed. It can be read and created by the management mechanism 1. In this case, the module call format is defined by the module name of the called module and the input attribute of the module. By referring to this correspondence table 2, for example, the module management mechanism 1 identifies a module having a "user name" as a goal attribute by "user".
information module (“processing attribute” = “NAM
It can be called in the form of E ")". The correspondence table 2 is configured so that it can be referred to by the user (for example, it can be displayed on a display or a printer).

FIG. 5 is a diagram showing an example of the synonym dictionary 3, and the synonym dictionary 3 stores attributes that are synonymous to each other. By referring to the synonym dictionary 3, the module management mechanism 1 is synonymous with the goal attribute “customer name” when a module requests a value of “customer name” as the goal attribute, for example. You can search for the goal attribute of the word "username".

Next, the processing operation of the problem solving apparatus having such a configuration, particularly the processing operation in the module management mechanism 1, will be described with reference to the flowchart of FIG. At the initial stage, the attribute for which the user wants to obtain a value (final solution of the problem) to solve a certain problem, and further the input attribute (and / or the pair of the input attribute and its attribute value) as the input condition Is input and there is a request from the user,
Or, in the process of solving this problem, when there is a request based on an attribute for which a value is to be obtained from a certain module, for example, M ₁ and also an input attribute (and / or a pair of the input attribute and its attribute value) as an input condition. The module management mechanism 1 accepts this request, generates _one event, for example IVT ₁ , and activates it (step S
1). In the processing of this event IVT ₁ , by referring to the correspondence table 2 and the synonym dictionary 3, whether there is a goal attribute in the correspondence table 2 that matches the attribute (or its synonym) for which the requested value is to be obtained. If there is a matching goal attribute, the correspondence table 2 is searched for the module call format corresponding to this goal attribute (step S
2). When this module call format can be retrieved from the correspondence table 2 (step S3), a module of this module call format, for example, M ₂ is called to cause this module M ₂ to execute the processing. In order for the module M ₂ to execute the process, the attribute value of the input attribute of the module M ₂ needs to be already determined. Therefore, prior to calling this module M ₂ , the input attributes set in the module calling format are read out, and it is sequentially checked whether or not each input attribute has an attribute value, and the attribute value still exists. If not, the process of determining the attribute value is performed.

More specifically, all the input attributes set in this module call format are read out and stored as elements in the buffer ALIST, for example (step S4). Next, it is sequentially checked whether or not each element (that is, each input attribute) stored in the buffer ALIST has an attribute value. That is, the buffer ALIST
Sequentially read each element (each input attribute) stored in
It is sequentially checked whether or not each input attribute already has an attribute value (step S5).

At this time, when a certain input attribute does not yet have an attribute value, this event IVT ₁ itself issues a request REQ ₂ to obtain the value of this input attribute (step S6). As a result, the module management mechanism 1
Event IVT ₂ is generated, and the process in event IVT ₂ is performed (step S7). At this time, event IVT
₁ is in a waiting state until the processing in event IVT ₂ is completed. Even at Event IVT ₂ , this flow
When the attribute value of the input attribute is determined as a result of the processing in the event I _{2 as} a result of the processing similar to that of the chart, the same processing is repeated for the remaining input attributes, so that it is stored in the buffer ALIST. Attribute values are determined for all input attributes. When the attribute values are determined for all input attributes, module M ₂ is called,
The module M ₂ is caused to execute the processing (step S8).
As a result, the module M ₂ outputs the attribute value of the attribute that the user wants to obtain, or the attribute value of the attribute that a certain module M ₁ wants to obtain, to the module management mechanism 1 to the user, or It is passed to the module M ₁ (step S9). As a result of searching the correspondence table 2 in step S3, if there is no corresponding module M ₂ is sent directly to the attribute value of the input attributes to be obtained values to the user (step S10), and if the request is from the module M ₁ Passes the attribute value of the input attribute obtained by the user to the module M ₁ . The solution of the problem can be finally obtained through such a procedure.

Next, a specific example of such processing will be described.
Now, it is assumed that the correspondence table 2 and the synonym dictionary 3 store information as shown in FIGS. 4 and 5, respectively. At this time,
When "failure cause" is specified as an attribute whose value is to be obtained and there is a request to this effect, the module management mechanism 1 first refers to the correspondence table 2 and determines that the goal attribute is "failure cause". Search for. As a result, the module call format is "diagnosis module (“processing” = “CAUSE”,
User name, status) can be searched, and the module management mechanism 1 displays “diagnosis Call the module with the module name "module".

At the time of this call, this module is notified that the input attributes are processing, user name, and status. Regarding the input attribute "processing," the attribute value is "CAUSE", and When the attribute values of the user name and the situation are already determined, these attribute values are notified. When there is an input attribute that does not have an attribute value (for example, when the attribute value of the situation attribute is not yet determined), this attribute value is first determined. In this case, however, for convenience of explanation, "user name", " It is assumed that the attribute value of the “status” has already been determined, for example, “Tanaka” or “power not turned on”. "Diagnosis If a module with a module name of “module” is configured as shown in FIG. 7,
When this module is called, in this module, the notified input attribute is "process" = "CAUSE",
Since it is "user name" and "status", PA of the specification description section
TTERN1 is selected, and thereby, the processing of determining the goal attribute, that is, the attribute value of "fault cause" as an output is performed.

In this module, the processing for determining the attribute value of "fault cause" is described in the procedure description section. In the example of FIG. 7, “if input attribute 1
= “CAUSE” then proc Since the program of "1" is written, "proc Go to step 1. “proc For the 1 step, "product = call ser
The vice (“Maintenance schedule (“ Product name ”=“ FAX ”)”) program is described, and according to this program,
This module specifies “maintenance schedule (“ product name ”=“ FAX ”)” as an attribute whose value is to be obtained, and requests the module management mechanism 1 for this.

Upon receipt of this request, the module management mechanism 1 puts the processing of the module shown in FIG. 7 in a waiting state and refers to the correspondence table 2 to search for a goal attribute of "maintenance scheduled". As a result, the module call format is "maintenance status "module (product name, maintenance history file)" can be searched. At this time, the module management mechanism 1 further adds the input attribute "product name",
Check if the attribute value has already been determined for the "maintenance history file". In the present case, the input attribute "Product name"
For the above request, this attribute value is "FAX"
However, if the attribute value of the input attribute “maintenance history file” is not yet determined, the module management mechanism 1 determines that “main
tenance status Prior to calling the module “module”, the correspondence table 2 is referred to in order to determine the attribute value of the input attribute “maintenance history file”, and the module whose goal attribute is “maintenance history file” is searched.

As a result, the module call format is "maintenance report It is possible to search the module of "module (user name, product name)". At this time, regarding the input attributes "user name" and "product name", whether the attribute values have already been determined in the processing path up to now. As a result, the "user name" has already been determined at the time of calling the module in FIG. 7, and the "product name" is "FAX" when requested by the module in FIG. Since it has already been determined as ", the module management mechanism 1
“Maintenance report A module having a module name of "module" is called. At this time, the input attributes "user name" and "product name" and these attribute values are notified to this module. report mod
If a module having a module name of “ule” is configured as shown in FIG. 8, when this module is called, the notified input attributes are “user name” and “product name”. PATT of the specification description section
ERN1 is selected, and thereby, the processing for determining the goal attribute, that is, the attribute value of the "maintenance history file" as an output is performed. In this module, the processing for determining the attribute value of the "maintenance history file" is described in the procedure description section, and in the example of FIG. 8, "maintenance history file is searched from user name and product name ... A program to that effect is described. So in this module,
Search the maintenance history file based on the attribute value of the user name and the attribute value of the product name (“FAX”) to find the “maintenance history file”
Determine the attribute value of.

In this way, when the attribute value of "maintenance history file" is determined in the module of FIG. 8, this attribute value is sent to the module management mechanism 1. Since the module management mechanism 1 has determined the attribute value of the "maintenance history file", the module management mechanism 1 uses "maintenanc".
e status You can call a module with the module name "module". status modul
When the module having the module name of "e" is configured as shown in FIG. 9, in this module, since the notified input attributes are "product name" and "maintenance history file", PATTERN1 of the specification description section is changed. By this, the processing for determining the goal attribute, that is, the attribute value of "maintenance scheduled" as an output is performed. That is, in this module, the processing for determining the attribute value of "maintenance scheduled" is the procedure description. Section, and in the example of FIG.
A program that reads "the last maintenance date is read from the maintenance history file and the scheduled maintenance date is determined ..." is described. As a result, this module determines the scheduled maintenance date as the attribute value of "maintenance scheduled" from the attribute value of the maintenance history file.

In this way, when the attribute value of "scheduled maintenance" is determined in the module of FIG. 9, this attribute value is sent to the module management mechanism 1. Since the module management mechanism 1 has determined the attribute value of "maintenance scheduled", it sends this to the module of FIG.

In the module of FIG. 7, this results in "pr
oc After finishing the step 1 ”and proceeding to the next step, the attribute value of“ fault cause ”can be finally obtained in this manner.

As described above, in this embodiment, each module can call another module by designating a required attribute, and it is necessary to know what type of other module is called. Therefore, even if the module name or argument of another module is changed, it is not necessary to change the program accordingly. That is, when the module name or argument of a module is changed or the module is divided, the module management mechanism 1 reads the information in the specification description section of the changed module and updates the correspondence table 2. It does not have any influence on each module.

Further, since the correspondence table 2 shows a list of function names (goal attributes) of the currently existing modules, the programmer can use the correspondence table 2 when developing a new module. By referring to the list of function names shown, it is possible to easily understand which function is already provided in the current system.

Since the synonym dictionary 3 for function names is provided, the user can call the same function with a plurality of different vocabularies.

[0037]

As described above, according to the inventions of claims 1 to 3, each module can call another module by designating a required attribute. There is no need to know what type of other modules are called, and even if the module names and arguments of other modules are changed, it is not necessary to change the program accordingly.

Further, according to the inventions of claims 4 and 5, the module management means stores the correspondence table in which the goal attributes representing the functions of each module are stored in association with the calling format of the module. Since the module is called by referring to, the module management means only needs to update the correspondence table when the module name or argument of a certain module is changed or the module is divided. Does not have any effect on.

According to the invention described in claim 6, since the correspondence table is constructed so that it can be referred to by the user, the programmer can refer to the correspondence table when developing a new module. This makes it easy to understand which functions are already provided in the current system.

Further, according to the invention described in claim 7, a synonym dictionary capable of calling the same attribute with a plurality of different vocabularies is further provided, and the module management means refers to the synonym dictionary and identifies the attribute. Since it is specified, modules having the same goal attribute in different vocabularies can be called.

[Brief description of drawings]

FIG. 1 is a configuration diagram of an embodiment of a problem solving device according to the present invention.

FIG. 2 is a diagram showing a basic structure of each module.

FIG. 3 is a diagram illustrating an example of a processing form of a module management mechanism.

FIG. 4 is a diagram showing an example of a correspondence table.

FIG. 5 is a diagram showing an example of a synonym dictionary.

FIG. 6 is a flowchart for explaining the processing operation of the problem solving device of FIG. 1.

FIG. 7 is a diagram showing a specific example of a module.

FIG. 8 is a diagram showing a specific example of a module.

FIG. 9 is a diagram showing a specific example of a module.

[Explanation of symbols]

1 Module Management Mechanism 2 Correspondence Table 3 Synonym Dictionary 4 Attribute Collection Part M _{1 to} M _n Modules

Claims (7)

[Claims] 1. A problem solving device for realizing problem solving by interaction of a plurality of modules, comprising module management means for controlling mutual calls between the modules,
When each module wants to determine the value of a predetermined attribute by using another module, it gives a request by giving the required attribute to the module management means, and when the module management means receives the request, the module manages the value. A problem solving apparatus characterized in that a module having a goal attribute as an attribute to be obtained is searched and the module is called. 2. The problem solving device according to claim 1,
The required attributes given to the module management means include at least an attribute for which a value is desired to be obtained, and further include an input attribute as an input condition and / or a pair of the input attribute and its attribute value. A problem-solving device characterized by being possible. 3. The problem solving device according to claim 1,
When calling a certain module and executing a process, when the value of the attribute necessary for executing the process in the module is not yet determined, the module management means searches for a module having the attribute as a goal attribute. A problem solving device characterized in that the module is called. 4. The problem solving apparatus according to claim 1 or 3, wherein the module management means stores goal attributes indicating the function of each module in association with a calling format of the module. A problem solving device characterized in that a module is called by referring to a table. 5. The problem solving device according to claim 4,
The problem solving device, wherein the correspondence table is created or updated by the module management means at the time of initial setting of each module or when the module is changed. 6. The problem solving device according to claim 4,
The problem solving device is characterized in that the correspondence table is configured to be referred to by a user. 7. The problem solving device according to claim 4,
A synonym dictionary that can call the same attribute in a plurality of different vocabularies is further provided, and the module management means is
A problem solving device characterized in that an attribute is specified by referring to a synonym dictionary.