JP6287396B2 - Information processing apparatus and program - Google Patents

Description

  The present invention relates to an information processing apparatus and a program.

  Conventionally, in software design, two different objects using a message and a queue are linked and used for, for example, communication between processes in a kernel part of an embedded system.

  In addition, a technique called MQ (message queuing) in which application software (hereinafter referred to as “application”) is linked using messages and queues is spreading. MQ is applied to the processing of multiple transactions such as financial transactions and cellular applications, and the utilization of existing systems.

  As a technology for exchanging data between multiple applications, for example, a queuing manager manages messages sent by one application, and another application receives the queue so that the applications can cooperate with each other. Has been proposed (see Patent Document 1).

  Also, a system dedicated to medical institutions that performs cooperative exchange of medical data based on MQ has been proposed (see Patent Document 2).

JP 2003-022251 A JP 2008-527519 A

  However, since the conventional application linkage system links tasks and devices such as applications using messages and queues, system vendors must specially construct specific use cases. There was a problem.

  In addition, because the system vendor specializes in a specific use case, the system vendor makes it a black box and provides it to the user. There was a risk that the possibility of expansion would disappear.

As described above, application cooperation by MQ has advantages such as high processing performance and ease of software design, but depending on the user who actually operates the system, the mainframe, server, virtual environment, etc. Like the system, there was a problem that it was difficult to change use cases.
Therefore, it has been desired that the user himself / herself can easily correct the processing procedure including task cooperation.

  The present invention has been made in view of the above-described problems in the prior art, and enables general and explicit description of cooperation between tasks, and can easily complement tasks even when description of tasks is omitted. The problem is to do.

In order to solve the above problems, an information processing apparatus of the present invention, a hierarchical structure based on the descriptive document describing the execution sequence of tasks in describable description language, corresponding to the completion candidates and complementary position Creating means for creating an attached table, and complementing means for complementing a complementing candidate associated with the complementing position to a complementing position whose description is omitted in the processing target description document based on the created table And comprising.

  According to the present invention, cooperation between tasks can be described generically and explicitly, and tasks can be easily supplemented even when description of the task is omitted.

It is a block diagram which shows the functional structure of the information processing apparatus in embodiment of this invention. It is a figure which shows the type of task for every process pattern. (A) is an image figure which shows the hierarchical structure of a task. (B) is an example of a task description in XML. (A) is an image figure which shows the correspondence of the input / output data of a task. (B) is an example of a story describing data exchange information. This is an example of a story describing data exchange information when the input data in the task “employee inquiry” is fixed. This is an example of a story that omits a part and describes data exchange information. It is an example of a history table. It is an example of a recommendation table. It is a flowchart which shows a history table creation process. It is a flowchart which shows a traverse process. It is a flowchart which shows a node process. (A) is an ideal structural example of the story of "employee inquiry A". (B) is a configuration example of a story “employee inquiry B” including only “request” and “output”. (C) is a configuration example of a story “employee inquiry C” including only “request” and “employee search”. (A) is an example of the multidimensional vector table before normalization. (B) is an image diagram representing each task as a two-dimensional story vector. (A) is an example of the multidimensional vector table after normalization. (B) is obtained by normalizing the vector shown in FIG. It is a flowchart which shows a recommendation table creation process. It is a flowchart which shows the preparation process of a multidimensional vector table. It is a flowchart which shows the cosine similarity calculation and the write-in process to a recommendation table. It is a flowchart which shows a story complement process. It is a flowchart which shows the complement process by a recommendation table. It is a flowchart which shows a recommendation complementing part process. It is a flowchart which shows the traverse process for recommendation. It is a flowchart which shows the complementation process by a history table. It is a flowchart which shows a log | history complement component process. It is a flowchart which shows the traverse process for log | history. It is a figure which shows the example of a complement of a story.

  Embodiments of an information processing apparatus according to the present invention will be described below with reference to the drawings. The present invention is not limited to the illustrated example.

FIG. 1 is a block diagram illustrating a functional configuration of the information processing apparatus 10 according to the present embodiment. The information processing apparatus 10 is configured by, for example, a personal computer.
As shown in FIG. 1, the information processing apparatus 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, and an operation unit 14. A display unit 15, a communication unit 16, and a storage unit 17.

  The CPU 11 comprehensively controls the processing operation of each unit of the information processing apparatus 10. Specifically, the CPU 11 reads out various programs stored in the ROM 12, develops them in the RAM 13, and performs various processes in cooperation with the programs.

  The ROM 12 is a read-only semiconductor memory that stores various programs and various data. For example, the ROM 12 stores a history table creation program 121, a recommendation table creation program 122, and a story complement program 123.

  The RAM 13 is a volatile memory. The RAM 13 stores various programs to be executed and data related to these various programs.

  The operation unit 14 is a functional unit that receives an operation instruction from a user. The operation unit 14 includes a keyboard having cursor keys, character input keys, various function keys, and the like, and a pointing device such as a mouse, and outputs operation signals input by keyboard operations and mouse operations to the CPU 11. To do.

  The display unit 15 is configured by an LCD (Liquid Crystal Display) or the like, and performs screen display according to a display control signal from the CPU 11.

  The communication unit 16 is configured by a network interface or the like, and transmits and receives data to and from an external device connected via a communication network.

  The storage unit 17 is configured by a hard disk, a nonvolatile memory, or the like, and stores information so as to be readable and writable. The storage unit 17 stores a story 171 as a plurality of description documents and a plurality of application programs (hereinafter referred to as “applications”) AP.

  The story 171 describes the task execution order in a description language that can describe a hierarchical structure. Specifically, XML (Extensible Markup Language) language is used as a description language capable of describing a hierarchical structure, and the elements constituting the story 171 are described as tasks, and the story 171 is described in a task hierarchy. When the application AP is designated as a task, the designated application AP is called when the story 171 is executed, and processing corresponding to the application AP is executed. In the story 171, for example, a flow (processing procedure) that uses a plurality of linked application APs is described.

  The task has, as an attribute, a type in which the cooperating application AP is classified based on the MQ processing pattern. A task is defined for each of a data transmission side and a data reception side when data is linked.

  FIG. 2 shows, for each processing pattern, an actual business example in which the processing pattern is used, a task type included in the processing pattern, and a task definition. For example, “online processing: one-way type” includes a “send” type task for transmitting the created data and a “receive” type task for receiving and processing the data.

  In order to accurately represent a set of tasks on the data transmission side and data reception side, the task on the transmission side is represented by an XML node, and the tasks on the reception side are nested in that node, thereby representing the tasks hierarchically. Arranging tasks in parallel without nesting represents sequential processing.

  FIG. 3A is an image diagram showing a hierarchical structure of tasks. A subtask B1 is nested in the main task A1, and a subtask B2 is nested in the main task A2. The main task A2 indicates processing performed after the main task A1.

  FIG. 3B shows an example of task description in XML. A subtask B3 called "Employee search" of "Response" type is nested in the main task A3 of "Request employee" type "Employee inquiry". Then, after the main task A3, a main task A4 of “send notification” type “employee notification” is described in parallel, and a subtask of “reception” type “notification sending” is added to the main task A4 of “employee notification”. B4 is nested.

“Employee inquiry” is a “request” type application for inquiring a specified employee.
The “employee search” is a “response” type application for searching for information related to employees using a database or the like in which employee information is stored in advance.
“Employee notification” is a “send” type application for notifying a specified employee.
“Notification sending” is a “reception” type application for sending a predetermined notice to a designated employee.

  A task can describe input data and output data under each hierarchy. In the nested task, the output data of the upper layer task becomes the input data of the lower layer task. Since the data of each task has an arbitrary structure, when the same data is used between tasks, it is necessary to describe the corresponding relationship.

FIG. 4A shows the correspondence between input / output data of tasks. The request data of the upper-level task A5 of the “request” type becomes input data of the lower-level task B5 of the “response” type. Further, the output data of the lower-level task B5 of the “response” type becomes the output data of the higher-level task A5 of the “request” type.
By strictly describing the data correspondence in the story 171, the data can be referred to based on the correspondence when the task is executed.

FIG. 4B is an example of a story (XML document) describing data exchange information.
“Employee inquiry” is a task (application AP) for inquiring an employee specified by an employee number or the like. The employee number is input from a file in which the employee number is stored in advance, or input of data (employee number) is requested and manually input by the user.
“Employee search” is a task (application) for outputting employee information corresponding to the employee number etc. according to the specified output contents (employee number, employee name, etc.) for the entered employee number etc. AP).

  The node C1 describes that “employee number” is used as input data for the task “employee search”. The “employee number” is specified by the ref attribute to refer to the “employee number” of the node D1. When each information used for data exchange is represented hierarchically, the reference source (node including the ref attribute) is “/ employee inquiry / employee search / input / employee number”, and the reference destination (specified by the ref value) Reference destination) is “/ employee inquiry / request / employee number”.

  Similarly, the value of “/ employee inquiry / employee search / output / employee number” of node D2 is used as the value of “/ employee inquiry / output / employee number” of node C2. Further, the value of “/ employee inquiry / employee search / output / employee name” of node D3 is used as the value of “/ employee inquiry / output / employee name” of node C3.

  FIG. 5 is an example of a story (XML document) describing data exchange information when the input data in the task “employee inquiry” is fixed. The node D4 describes that a file named “c: / temp / employee number file.txt” is used as input data for the task “employee inquiry”. The node C4 describes that “employee number” is used as input data for the task “employee search”. The “employee number” is designated to refer to the “file” of the node D4 by the ref attribute. That is, the value of “/ employee inquiry / input / file” is referred to as the value of “/ employee inquiry / employee search / input / employee number”.

  FIG. 6 shows an example of a story (XML document) in which data exchange information is described with a part omitted. In the node C5, the description of “employee number” used as input data is omitted in the task “employee search” which is a lower-level task of the task “employee inquiry”. An object of the present invention is to supplement a description such as the node C1 of FIG. 4B or the description of the node C4 of FIG. .

The storage unit 17 stores a history table T1 and a recommendation table T2.
FIG. 7 is an example of the history table T1. In the history table T1, the reference destination (complementation candidate) and the reference count are associated with the index path (complementation position). The index path is information indicating a node whose reference destination is specified by the ref attribute in the story 171. The reference destination is information indicating the reference destination designated by the ref value. The reference count is the number of times the reference destination is referred to the corresponding index path.

  FIG. 8 is an example of the recommendation table T2. In the recommendation table T2, complement candidates are associated with index paths (complement positions). The index path is information indicating a higher-level task in which the description of the lower-level task is omitted in the story 171. The complement candidate is information indicating a hierarchical relationship between a task in the upper hierarchy indicated by the index path and a task in the lower hierarchy immediately below it.

  Based on the plurality of stories 171, the CPU 11 creates a history table T1 and a recommendation table T2 in which complementary positions and complementary candidates are associated with each other.

  Specifically, the CPU 11 extracts the reference relationship of data between tasks from a plurality of stories 171, and the reference source description data and the reference destination description data included in the plurality of stories 171 are represented hierarchically and correspond to each other. The attached history table T1 is created.

  In addition, the CPU 11 creates a recommendation table T2 in which upper level tasks and lower level tasks of the upper level are associated with each other from the plurality of stories 171. More specifically, the CPU 11 treats a plurality of tasks included in a lower hierarchy of a corresponding task in the plurality of stories 171 as a corresponding task vector, and calculates a cosine similarity between the plurality of tasks. The “corresponding task” is a task (including the story 171 itself) including processing contents similar to each other. For example, among tasks using the same application AP, when a lower-level task included in a certain task is not included in other tasks, it corresponds to “corresponding task”. The CPU 11 creates a recommendation table T2 with a task whose calculated cosine similarity is equal to or higher than a predetermined value as a lower layer task and a corresponding task as an upper layer task.

  Based on the created history table T1 and recommendation table T2, the CPU 11 supplements the complement candidate associated with the complement position at the complement position that is not described in the story 171 to be processed.

  Specifically, based on the history table T1, the CPU 11 supplements the description data of the reference destination with the description data of the reference source included in the story 171 to be processed.

  Further, the CPU 11 complements the lower-level task to the lower level of the higher-level task included in the story 171 to be processed based on the recommendation table T2.

(History table creation process)
FIG. 9 is a flowchart showing history table creation processing. This process is a process for extracting a pattern of data reference relation between tasks from each story 171 accumulated so far, and is executed in units of stories 171. This processing is realized by software processing by the cooperation of the CPU 11 and the history table creation program 121.

First, the CPU 11 acquires a root node from the story 171 (step S1).
Next, the CPU 11 acquires the node path acquired in step S1 (step S2). The node path represents the processing target node hierarchically. The CPU 11 stores the acquired node path in the RAM 13.
Next, the CPU 11 performs a traverse process on the root node acquired in step S1 (step S3).

Here, the traverse process will be described with reference to FIG.
The CPU 11 counts the number of child nodes that are lower-level nodes of the processing target node (step S11).
Next, the CPU 11 determines whether or not there is an unprocessed child node (step S12). If there is an unprocessed child node (step S12; YES), any of the unprocessed child nodes is determined. One node is acquired (step S13).
Next, the CPU 11 performs node processing on the node acquired in step S13 (step S14).

In the node processing, as shown in FIG. 11, the CPU 11 acquires the path of the processing target node (step S21). The CPU 11 stores the acquired node path in the RAM 13.
Next, the CPU 11 determines whether or not the processing target node has a ref attribute (step S22). When the processing target node has the ref attribute (step S22; YES), the CPU 11 acquires the ref value from the processing target node (step S23). The CPU 11 stores the acquired ref value in the RAM 13.

  Next, the CPU 11 writes to the history table T1 based on the node path and the ref value (step S24). Specifically, the path of the node acquired in step S21 is written in the index path of the history table T1, the ref value acquired in step S23 is written in the reference destination, and 1 is written in the reference count. If the combination of the node path and the ref value already exists in the history table T1, the node path and the ref value are not newly written, and the combination of the node path and the ref value in the history table T1 is used. Add 1 to the reference count of the corresponding record.

  As shown in the history table T1 of FIG. 7, for example, from the story shown in FIG. 4B, the reference path “/ employee inquiry / employee search / input / employee number (node C1)” is referred to as “ / Employee inquiry / Request / Employee number (node D1) "is written. Also, the reference destination “/ employee inquiry / employee search / output / employee number (node D2)” is written to the index path “/ employee inquiry / output / employee number (node C2)”. Further, the reference destination “/ employee inquiry / employee search / output / employee name (node D3)” is written to the index path “/ employee inquiry / output / employee name (node C3)”.

  Similarly, from the story shown in FIG. 5, the reference destination “/ employee inquiry / input / file (node D4)” is associated with the index path “/ employee inquiry / employee search / input / employee number (node C4)”. Written. The reference destination for the index path “/ employee inquiry / output / employee number” and the reference destination for the index path “/ employee inquiry / output / employee name” are the same as the story shown in FIG. 1 has been added to the list twice.

  After step S24 or when the processing target node does not have the ref attribute in step S22 (step S22; NO), the node processing ends.

Next, returning to FIG. 10, the CPU 11 performs a traverse process (see FIG. 10) on the node acquired in step S13 (step S15). In this way, the process is sequentially repeated for the nodes in the lower hierarchy.
After step S15, the process returns to step S12, and the process is repeated for the other child nodes.
In step S12, when there is no unprocessed child node (step S12; NO), the traverse process ends.

  In step S3 in FIG. 9, when the traversing process for the root node is completed, the history table creating process is terminated.

(Recommendation table creation process)
Next, creation of the recommendation table T2 will be described.
FIG. 12A shows the structure of the story “Employee inquiry A”. “Employee inquiry A” is composed of tasks “request”, “employee search”, and “output”, and has an ideal structure of a story “employee inquiry”. However, it is assumed that “employee inquiry A” does not exist in the storage unit 17 of the information processing apparatus 10.

FIG. 12B shows the structure of the story “Employee inquiry B”. “Employee inquiry B” is composed of tasks “request” and “output”, and does not include a task “employee search”.
FIG. 12C shows a story structure of “employee inquiry C”. “Employee inquiry C” includes tasks “request” and “employee search”, and does not include a task “output”.
For example, the recommendation table T <b> 2 is created with tasks corresponding to “employee inquiry B” and “employee inquiry C”.

  FIG. 13A shows an example of the multidimensional vector table L1 before normalization. The multi-dimensional vector table L1 represents each task as a vector of N-dimensional stories (N is the number of stories), with stories in columns and tasks in rows. The multidimensional vector table L1 indicates whether or not each task is included in each story. If each task in the multidimensional vector table L1 includes a corresponding task, “1” is displayed. ", Or" 0 "if the corresponding task is not included. In this embodiment, a case where a two-dimensional vector centering on two stories of “employee inquiry B” and “employee inquiry C” is illustrated, but when more stories are used. The number of columns in the multidimensional vector table L1 also becomes N columns according to the number N of stories, and each task is represented as an N-dimensional vector.

  FIG. 13B is an image diagram representing each task shown in FIG. 13A as a two-dimensional story vector with “employee inquiry B” and “employee inquiry C” as axes. In the example of FIG. 13B, the task “request” is represented by a vector (employee inquiry B, employee inquiry C) = (1, 1), and the task “employee search” is represented by (employee inquiry B, The employee inquiry C) = (0,1) is represented by a vector, and the task “output” is represented by a vector (employee inquiry B, employee inquiry C) = (1,0).

FIG. 14A is an example of a normalized multidimensional vector table L2 in which the length of each vector is normalized to 1 with respect to the multidimensional vector table L1 shown in FIG.
FIG. 14B is a normalized version of the vector shown in FIG.

  FIG. 15 is a flowchart showing a recommendation table creation process. This process is a process of extracting a hierarchical relationship pattern from the story 171 accumulated so far. This processing is realized by software processing by the cooperation of the CPU 11 and the recommendation table creation program 122.

  First, the CPU 11 performs a multidimensional vector table creation process (step S31).

Here, with reference to FIG. 16, a process of creating a multidimensional vector table will be described.
The CPU 11 determines whether there is an unprocessed story 171 among the stories 171 stored in the storage unit 17 (step S41). If there is an unprocessed story 171 (step S41; YES), the CPU 11 adds the unprocessed story 171 to the column of the multidimensional vector table L1 (see FIG. 13A) (step S42).

  Next, the CPU 11 determines whether or not there is an unprocessed task in the story 171 being processed (step S43). If there is an unprocessed task (step S43; YES), the CPU 11 sets this unprocessed task as a processing target task, and whether there is an item of the same task as the processing target task in the row of the multidimensional vector table L1. Is determined (step S44).

  When there is no item of the same task as the processing target task in the row of the multidimensional vector table L1 (step S44; NO), the CPU 11 adds an item (processing target task) to the row of the multidimensional vector table L1 (step S44). S45).

  After step S45 or in step S44, if there is an item of the same task as the processing target task in the row of the multidimensional vector table L1 (step S44; YES), the CPU 11 selects a column ( The value of the position where the story) and the line (task) intersect is set to 1 (step S46). And it returns to step S43 and a process is repeated about the other task in the story 171 in process.

  If there is no unprocessed task in step S43 (step S43; NO), the process returns to step S41, and the process is repeated for the other stories 171.

If there is no unprocessed story 171 in step S41 (step S41; NO), the CPU 11 treats each task in the multidimensional vector table L1 as a vector of each story, normalizes the vector of each task, and multidimensionally A vector table L2 (see FIG. 14A) is generated (step S47).
This completes the multidimensional vector table creation process.

  Next, returning to FIG. 15, the CPU 11 performs cosine similarity calculation and write processing to the recommendation table (step S <b> 32).

Here, the cosine similarity calculation and the writing process to the recommendation table will be described with reference to FIG.
The CPU 11 determines whether there is an unprocessed story 171 (step S51). If there is an unprocessed story 171 (step S51; YES), the CPU 11 determines whether or not there is an unprocessed task in the unprocessed story 171 (step S52).

  If there is an unprocessed task in the story 171 (step S52; YES), the CPU 11 sets this unprocessed task as a processing target task in the column of the story 171 being processed in the multidimensional vector table L2. It is determined whether there is a task (step S53). The comparison target task is a task not included in the story 171 being processed, that is, a task having a value of “0” in the column of the story 171 being processed in the multidimensional vector table L2.

  When there is a comparison target task in the multidimensional vector table L2 (step S53; YES), the CPU 11 calculates the cosine similarity between the processing target task and the comparison target task (step S54). The cosine similarity is obtained as an inner product of normalized vectors of both tasks when the task is expressed as an N-dimensional story vector. The closer the cosine similarity is to 1, the more similar the tasks are.

  Next, the CPU 11 determines whether or not the calculated cosine similarity is greater than or equal to a predetermined threshold (step S55). The threshold value can be set to an arbitrary value, but for example, 0.7 is used as the threshold value.

  If the cosine similarity is greater than or equal to the threshold (step S55; YES), the CPU 11 writes to the recommendation table T2 (step S56). Specifically, the “story” being processed is written in the index path of the recommendation table T2, and “story / comparison task” is written in the complement candidate.

For example, in the multidimensional vector table L2 shown in FIG. 14 (a), when the story “employee inquiry B” is processed, “employee inquiry B” includes a “request” task and an “output” task. , Search for a task having a vector close to “request” and “output”.
cos (request, employee search) = 0.7 × 0 + 0.7 × 1 = 0.7
cos (output, employee search) = 1 × 0 + 0 × 1 = 0
As a result, “employee search” is considered to have a high similarity to “request”.
Therefore, as shown in the first row of the recommendation table T2 of FIG. 8, the supplement candidate “employee inquiry B / employee search” is written to the index path “employee inquiry B”.

Similarly, if the story “Employee inquiry C” is the target of processing, “Employee inquiry C” includes “Request” task and “Employee search” task. Find a task that has a close vector.
cos (request, output) = 0.7 × 1 + 0.7 × 0 = 0.7
cos (employee search, output) = 0 × 1 + 1 × 0 = 0
As a result, “output” is considered to have a high degree of similarity to “request”.
Therefore, as shown in the fourth row of the recommendation table T2 of FIG. 8, the supplement candidate “employee inquiry C / output” is written to the index path “employee inquiry C”.

After step S56 or when the cosine similarity is less than the threshold value in step S55 (step S55; NO), the process returns to step S53, and the process is repeated for the other comparison target tasks.
If there is no other comparison target task in the multidimensional vector table L2 in step S53 (step S53; NO), the process returns to step S52, and the process is repeated for other tasks in the story 171 being processed.

  In step S52, when there is no unprocessed task in the story 171 being processed (step S52; NO), the process returns to step S51, and the process is repeated for the other stories 171.

In step S51, when there is no unprocessed story 171 (step S51; NO), the cosine similarity calculation and the writing process to the recommendation table are ended.
Then, returning to FIG. 15, the recommendation table creation process ends.

  16 and 17, the case where the hierarchical relationship between the story 171 and the task immediately below is extracted has been described. However, the upper hierarchy task other than the story 171 and the lower hierarchy task below the task 171 The hierarchical relationship can be obtained in the same manner. For example, as shown in the second and third lines of the recommendation table T2 in FIG. 8, the candidate “employee search / input”, “employee search / output”, etc. are extracted for the index path “employee search”. .

(Story supplement processing)
FIG. 18 is a flowchart showing the story complement process. The story complement process is a process for complementing a task for a story 171 (hereinafter referred to as a process target story) from which a part of the description is omitted. This process is realized by software processing by the cooperation of the CPU 11 and the story complement program 123.

First, the CPU 11 performs a complementing process using a recommendation table for the processing target story (step S61).
Next, the CPU 11 performs a complementary process using a history table for the story to be processed (step S62).
This completes the story complement process.

(Complementary processing by recommendation table)
FIG. 19 is a flowchart showing the complementing process (step S61) using the recommendation table. This process is a process for complementing the hierarchical relationship of tasks based on the recommendation table T2 for the story to be processed.

First, the CPU 11 acquires a root node from the processing target story (step S71).
Next, the CPU 11 performs recommended complement component processing for the node acquired in step S71 (step S72).

Here, with reference to FIG. 20, the recommendation complementing part process will be described.
The CPU 11 searches the recommendation table T2 using the processing target node as a key (step S81), and determines whether or not there is a complement candidate in the recommendation table T2 (step S82). Specifically, the CPU 11 determines whether or not there is a complement candidate corresponding to the index path that matches the processing target node in the recommendation table T2.

When there is a complement candidate in the recommendation table T2 (step S82; YES), the CPU 11 acquires a complement candidate corresponding to the processing target node from the recommendation table T2, and inserts a child node in a lower hierarchy of the processing target node ( Step S83). That is, the CPU 11 complements the hierarchical relationship between the processing target node and the child node.
Note that the CPU 11 does not insert the child node when the same child node as the complement candidate already exists in the lower hierarchy of the processing target node.

  In addition, when there are two or more complement candidates corresponding to the processing target node, the CPU 11 displays two or more complement candidates on the display unit 15, and displays the complement candidates displayed by an operation from the user operation unit 14. One or a plurality of complementary candidates may be selected from the inside. The order in which a plurality of child nodes are inserted under the same node may be inserted in a predetermined order (normal processing order) or may be designated by the user.

  After step S83 or in step S82, if there is no complement candidate in the recommendation table T2 (step S82; NO), the recommendation complement component process ends.

  Next, returning to FIG. 19, the CPU 11 performs a recommendation traversal process on the root node acquired in step S71 (step S73).

  In the recommendation traverse process, as shown in FIG. 21, the CPU 11 determines whether or not there is an unprocessed child node in the process target node (step S91). When there is an unprocessed child node (step S91; YES), the CPU 11 performs a recommended complement component process (see FIG. 20) on the unprocessed child node (step S92).

  Next, the CPU 11 performs a recommendation traverse process (see FIG. 21) on an unprocessed child node (step S93). In this way, the process is sequentially repeated for the nodes in the lower hierarchy.

After step S93, the process returns to step S91, and the process is repeated for the other child nodes.
If there is no unprocessed child node in step S91 (step S91; NO), the recommendation traverse process is terminated.

  In step S73 in FIG. 19, when the recommendation traversing process for the root node is completed, the complementing process using the recommendation table is completed.

(Complementary processing by history table)
FIG. 22 is a flowchart showing the complementing process (step S62) using the history table. This process is a process of complementing the data reference relationship between tasks based on the history table T1 for the story to be processed.

First, the CPU 11 acquires a root node from the processing target story (step S101).
Next, the CPU 11 performs history complement component processing on the node acquired in step S101 (step S102).

Here, with reference to FIG. 23, the history complement component processing will be described.
The CPU 11 acquires the full path of the processing target node (step S111). The CPU 11 stores the acquired full path of the node in the RAM 13.
Next, the CPU 11 searches the history table T1 using the full path of the node acquired in step S111 as a key (step S112), and determines whether or not there is a complement candidate in the history table T1 (step S113). Specifically, the CPU 11 determines whether or not there is a reference destination corresponding to the index path that matches the full path of the processing target node in the history table T1.

When there is a complement candidate in the history table T1 (step S113; YES), the CPU 11 acquires a reference destination corresponding to the full path of the processing target node from the history table T1, and inserts a ref attribute in the processing target node (step). S114). That is, the CPU 11 supplements the data reference relationship between the processing target node and the reference destination node.
Note that the CPU 11 does not insert the ref attribute when the same ref attribute as the complement candidate (reference destination) already exists in the processing target node.

  Further, when there are two or more reference destinations corresponding to the full path of the processing target node, the CPU 11 displays two or more reference destinations on the display unit 15, and the reference displayed by the operation from the operation unit 14 by the user. One reference destination may be selected from the destinations.

  After step S114 or in step S113, if there is no complement candidate in the history table T1 (step S113; NO), the history complement component process ends.

  Next, returning to FIG. 22, the CPU 11 performs history traversal processing on the root node acquired in step S101 (step S103).

  In the history traverse process, as shown in FIG. 24, the CPU 11 determines whether or not there is an unprocessed child node in the process target node (step S121). When there is an unprocessed child node (step S121; YES), the CPU 11 performs history complement component processing (see FIG. 23) on the unprocessed child node (step S122).

  Next, the CPU 11 performs history traversal processing (see FIG. 24) for unprocessed child nodes (step S123). In this way, the process is sequentially repeated for the nodes in the lower hierarchy.

After step S123, the process returns to step S121, and the process is repeated for the other child nodes.
In step S121, when there is no unprocessed child node (step S121; NO), the history traverse process is terminated.

  In step S103 in FIG. 22, when the history traversing process for the root node is completed, the complementing process using the history table is completed.

  After the story complement process is completed, the CPU 11 sequentially executes processes including a plurality of tasks based on the complemented story.

FIG. 25 shows an example of complementing a story.
In the story 21 before the supplement, “employee search” which is a lower-level task of “employee inquiry B” is omitted.
The story 22 is obtained by complementing tasks to the story 21 based on the recommendation table T2 shown in FIG. Specifically, based on “employee inquiry B / employee search” that is a candidate for completion corresponding to the index path “employee inquiry B” of the recommendation table T2, the task “employee search” is subordinate to “employee inquiry B”. Has been complemented. Furthermore, based on “employee search / input” and “employee search / output”, which are complementary candidates corresponding to the index path “employee search”, the task “input” and “output” are subordinate to “employee search”. Tasks are complemented.

Here, although the task of “employee search” is incorporated in the story 22, it is unclear what should be used as input data for “employee search”.
The story 23 is obtained by complementing tasks to the story 22 based on the history table T1 shown in FIG. Specifically, “/ employee query B / employee search” is based on the reference destination “../../request” corresponding to the index path “/ employee query B / employee search / input” of the history table T1. / Input ”node, the“ ref = ”. . /. . / Request "" is complemented. That is, in the story 23, the reference relationship of the data between the tasks is complemented so that the request data of the “employee inquiry B” is referred to as the input data of the “employee search” which is a lower hierarchy task of the “employee inquiry B”. Has been.

  In FIG. 25, the description of the reference count is omitted in the history table T1, but the priority order for complementing the reference destination may be changed according to the reference count for the combination of the index path and the reference destination. . In FIG. 25, the reference destination is described as a relative path in the history table T1, but the path description method may be an absolute path as shown in FIG.

As described above, according to the information processing apparatus 10 in the present embodiment, the cooperation between tasks can be described generically and explicitly by using a description language that can describe a hierarchical structure. .
Further, when the description is omitted in the story 171, the omitted portion is complemented, so that the task can be easily supplemented even when the task description is omitted. That is, even a person who does not have a technique for strictly creating the story 171 can easily create the story 171. For example, the story 171 can be corrected / added by a user who actually uses the information processing apparatus 10 instead of an expert belonging to a system vendor or the like.

  Specifically, when the reference relationship of data between tasks is omitted, based on the history table T1, the description data of the reference destination is supplemented to the description data of the reference source included in the story to be processed. Complementation based on past history is possible.

Further, when the task hierarchy relationship is omitted, the lower-level task is complemented to the lower-level task of the upper-level task included in the story to be processed based on the recommendation table T2. Complementation based on the trend of hierarchical relationships is possible.
Further, the similarity between tasks can be easily determined by using the cosine similarity.

  Further, by adopting XML as the description format of the story 171, it is possible to strictly describe the cooperation of a plurality of application APs, and it is possible to make a general-purpose description that does not depend on a specific use case.

  Note that the description in the above embodiment is an example of the information processing apparatus according to the present invention, and the present invention is not limited to this. The detailed configuration and detailed operation of each part constituting the apparatus can be changed as appropriate without departing from the spirit of the present invention.

  For example, in the above embodiment, the case where both the complementing process using the recommendation table (step S61) and the complementing process using the history table (step S62) are performed in the story complementing process (FIG. 18) is described. It is good also as performing only either one of the complementing process by or the complementing process by a history table.

The story complementing process may be performed when the story 171 is executed, or may be performed in advance before the story 171 is executed.
Moreover, although the case where application AP was memorize | stored in the memory | storage part 17 of the information processing apparatus 10 was demonstrated in the said embodiment, application AP preserve | saved at the external server is called and used via the communication part 16. It is good as well.

Although the embodiments of the present invention have been described, the scope of the present invention is not limited to the above-described embodiments, but includes the scope of the invention described in the claims and the equivalents thereof.
The invention described in the scope of claims attached to the application of this application will be added below. The item numbers of the claims described in the appendix are as set forth in the claims attached to the application of this application.
[Appendix]
<Claim 1>
Storage means for storing a plurality of descriptive documents describing the execution order of tasks in a description language capable of describing a hierarchical structure;
Creating means for creating a table in which a complement position and a complement candidate are associated with each other based on the plurality of description documents;
Based on the created table, a complement means for complementing a complement candidate associated with the complement position to a complement position whose description is omitted in the description document to be processed;
An information processing apparatus comprising:
<Claim 2>
The creation means extracts a reference relation of data between tasks from the plurality of description documents, and corresponds to the description data of the reference source and the description data of the reference destination included in the plurality of description documents in a hierarchical manner. Create a history table with
The information processing apparatus according to claim 1, wherein the complementing unit supplements the description data of the reference destination with the description data of the reference source included in the description document to be processed based on the created history table. .
<Claim 3>
The creation means creates a recommendation table in which upper layer tasks and lower layer tasks of the upper layer are associated with each other from the plurality of description documents,
2. The information processing according to claim 1, wherein the complementing unit complements the task of the lower hierarchy to a lower hierarchy of the task of the upper hierarchy included in the description document to be processed based on the created recommendation table. apparatus.
<Claim 4>
The creation means treats a plurality of tasks included in a lower hierarchy of a corresponding task in the plurality of description documents as a vector of the corresponding task, calculates a cosine similarity between the plurality of tasks, and calculates the calculated The information processing apparatus according to claim 3, wherein the recommendation table is created with a task having a cosine similarity equal to or higher than a predetermined value as the lower layer task and the corresponding task as the upper layer task.
<Claim 5>
The information processing apparatus according to claim 1, wherein the description language is an XML language.
<Claim 6>
Computer
A creation means for creating a table in which a complement position and a complement candidate are associated with each other based on a plurality of description documents describing a task execution order in a description language capable of describing a hierarchical structure,
Based on the created table, a complement means for complementing a complement candidate associated with the complement position to a complement position whose description is omitted in the description document to be processed;
Program to function as.

10 Information processing apparatus 11 CPU
12 ROM
17 storage unit 121 history table creation program 122 recommendation table creation program 123 story complement program 171 story AP application program T1 history table T2 recommendation table

Claims (6)

And creation means on the basis of the descriptive document describing the execution sequence of tasks, creating a table which associates the completion candidates and complementary position in a hierarchical structure can be described description language,
Based on the created table, a complement means for complementing a complement candidate associated with the complement position to a complement position whose description is omitted in the description document to be processed;
An information processing apparatus comprising: It said creation means, before extracting the reference data relationships between tasks from crisis predicate document correspondence before and referencing descriptive data contained in crisis predicate referenced document description data and the respectively hierarchically represents Create a history table with
The information processing apparatus according to claim 1, wherein the complementing unit supplements the description data of the reference destination with the description data of the reference source included in the description document to be processed based on the created history table. . It said creating means creates a recommendation table associating the lower layer task before crisis mentioned document from the upper layer tasks and the upper layer,
2. The information processing according to claim 1, wherein the complementing unit complements the task of the lower hierarchy to a lower hierarchy of the task of the upper hierarchy included in the description document to be processed based on the created recommendation table. apparatus. It said creation means treats filter disk included in the lower layer of the corresponding task before crisis mentioned document as a vector of the corresponding task, before calculating the cosine similarity between Northern disk was the calculated The information processing apparatus according to claim 3, wherein the recommendation table is created with a task having a cosine similarity equal to or higher than a predetermined value as the lower layer task and the corresponding task as the upper layer task.   The information processing apparatus according to claim 1, wherein the description language is an XML language. Computer
Based hierarchical structure describe document describing the execution sequence of tasks in describable description language, creating means for creating a table which associates the completion candidates and complementary position,
Based on the created table, a complement means for complementing a complement candidate associated with the complement position to a complement position whose description is omitted in the description document to be processed;
Program to function as.

Images