JP2009009384A - Verification system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system for judging whether evidence is consistent or not. <P>SOLUTION: A judgment result output means 6 in Fig.4 outputs a judgment result indicating that a change of a processing target is not consistent with a processing procedure when judging that judgment of no consistency is obtained in any partial graphic data W composing business flow data D. When judgment of consistency in all partial graphic data W composing the business flow data D, the means 6 outputs a judgment result indicating that a change of the processing target is consistent with the processing procedure. A non-consistent portion is displayed. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a verification system for verifying whether each evidence included in processing procedure data is consistent with the processing procedure indicated by the processing procedure data.

  Software for creating a business flow is used to formulate a business model. For example, Office Visio (Microsoft), Jude (Changevision), Eclipse Modeling FrameWork (Eclipse Foundation), Enterprise Architect (SparxSystems), Konesa (CanyonBlue), Pattern Weaver (Foundatao) ) Etc. are commercially available. In such a business model, documents, data (referred to as evidence), and the like are created and stored. In general, software for creating a business model can be operated while checking the flow of business on a screen as a flowchart. As a result, the creator can create a complex business model relatively easily.

  In the business model created as described above, the generation and storage of evidence must be consistent and consistent. For example, in the established business model, there is an inconsistent state where storage is not performed even when evidence is generated, or there is a process for storing although evidence is not generated. Must not exist. This is because operating a business model in a state of inconsistency is not preferable because necessary evidence cannot be secured or unnecessary business occurs.

  The following systems have been proposed for business flow verification.

  Patent Document 1 discloses a system for verifying local processing properties and flow connectivity.

  Patent Document 2 discloses a system that simulates how the state of evidence changes according to the flow of business, thereby verifying the validity of the business flow.

  Japanese Patent Application Laid-Open No. 2004-228688 discloses a system that allows rules for creating a business flow to be determined and enables accurate verification of the business flow.

JP-A-8-180110

JP-A-8-190587

JP-A-10-247212

  However, in the system of Patent Document 1, it is possible to verify whether the content of each process is appropriate, but whether the generation and storage of evidence as a whole flow is consistent and consistent (the life cycle of the evidence is consistent) It cannot be verified.

  Since the system of Patent Document 2 simulates how the state of evidence changes, it is possible to verify whether the life cycle of the evidence is consistent. However, since each piece of evidence is simulated sequentially, there is a problem that it takes a processing time for verification.

  The system of Patent Document 3 is not intended to verify the consistency of the evidence life cycle. Furthermore, in Patent Document 3, a large restriction is imposed on the creation of a business flow in order to perform accurate verification, and the burden on the creation of the business flow is large.

  An object of the present invention is to solve the above problems and to provide a system capable of efficiently determining whether or not the evidence is consistent.

  The features of the present invention are shown below. Each feature can be combined, but can be established independently.

(1) In the verification system according to the present invention, in the processing procedure data including the action and the flow, whether the change in the state of the processing target processed by the action is consistent with the processing procedure indicated by the processing procedure data. A verification system for verifying, a recording unit for recording processing procedure data, and a partial graph extracting unit for extracting a plurality of flows from the start to the end as partial graph data based on a determination action in the processing procedure data; For each extracted partial graph data, based on the determination result of the partial graph determination means for determining whether the state change of the processing target in each action is consistent in relation to the flow, and the determination result of the partial graph determination means, Judgment result output that outputs whether the status change of the processing target is consistent with the processing procedure indicated by the processing procedure data And a means.

  Therefore, it is possible to perform a consistency check by separating into subgraphs, and it is possible to make a quick and accurate determination.

(2) In the verification system according to the present invention, the subgraph determining means has an action that causes a state change of any one of the processing objects to at least one of both ends from the subgraph data or the processing procedure data, In addition to line extraction means for extracting line data that does not have any action that causes a change in the state of any processing target, and for each processing target that appears in at least one of the both ends in each extracted line data Based on the determination result for each processing target obtained by the in-line processing target determination unit and the in-line processing target determination unit for determining whether the state change of the processing target is consistent or inconsistent, By referring to other lines in the same subgraph data for the state change of the processing target determined to be inconsistent If it can be found that it is consistent, the state change of the processing target is determined to be consistent. It is characterized by comprising line determination means for determining that the state change of the object is inconsistent.

  Since the line is extracted and the consistency is determined, it can be determined that the line is consistent in relation to other lines, and an accurate determination is possible.

(3) In the verification system according to the present invention, the in-line processing target determination means has an action for the processing target at both the start point and the end point, the start point action is not the end process for the processing target, and the end point action is a process When a line that is not a start process for a target is recorded as a consistent continuation state, an action for the process target is included at the end point, and an action for the end point is not a start process for the process target but an action for the process target at the start point The line in which the action is the end process for the processing target is recorded as an inconsistent appearance state, and has an action for the processing target at the end point. The action at the end point is not the end process for the processing target, but the action for the processing target at the end point. If you have Down to record the line is the start processing for the processing object as a non-aligned manner extinguished state, it is characterized by recording a line that does not correspond to any of the above conditions as consistent discontinued state.

  Therefore, it can be determined whether or not the extracted lines are consistent, and classification can be performed, and the final consistency determination can be performed quickly.

(4) In the verification system according to the present invention, when a line recorded as a consistent continuation state has a simple branch or simple connection, the line determination means records the line as a “solution”, and the inconsistency If a line recorded as an appearance state has a simple join, the line is recorded as “solvable inconsistency”, and if a line recorded as an inconsistent appearance state has a simple branch, the line Is recorded as “solvable non-matching”, and a line recorded as an inconsistent application state or inconsistent extinction state other than the above is recorded as “unsolvable non-matching”.

  Therefore, the characteristics for each line can be classified and used for consistency determination.

(5) In the verification system according to the present invention, the line that can be resolved by the line judging means as the “solvable inconsistency” is recorded as “solution” in the same subgraph data. Depending on the above judgment, the "solvable non-matching" line where the "solution" for the solution cannot be found, the same start point and the same evidence and the end point is different, or the same end point A feature is that a plurality of “solution” lines and “unsolvable non-matching” lines having the same evidence and different starting points are extracted as inconsistent portions.

  Therefore, the presence or absence of consistency can be determined based on the characteristics of the line.

(6) In the verification system according to the present invention, the flow indicated by the processing procedure data extends over a plurality of files, and connects the end of the flow in the file and the start of the flow in another file corresponding to the end. In this way, it is characterized in that a flow generated over a plurality of files is a processing target for consistency determination.

  Accordingly, consistency can be verified even if the flow spans multiple files.

(7) A processing procedure data generation system according to the present invention is a processing procedure data generation system for generating processing procedure data having an action and a flow. In order to verify whether the state change of the processing target to be processed is consistent with the processing procedure, the above system is provided.

  Therefore, it is possible to obtain a processing procedure data generation system capable of determining whether or not the state change of the processing target is consistent with the processing procedure indicated by the processing procedure data.

  In the present invention, “processing procedure data” refers to data describing a flow of some action for a processing target, and in the embodiment, this is business flow data.

  “Action” refers to processing for a processing target, and includes processing such as generating, discarding, storing, and processing the processing target.

  The “flow” indicates the flow of action.

  “State change” refers to a change in the state of a processing target caused by an action, and in the embodiment, this corresponds to the life cycle of evidence.

  The “program” is a concept that includes not only a program that can be directly executed by the CPU, but also a source format program, a compressed program, an encrypted program, and the like.

BEST MODE FOR CARRYING OUT THE INVENTION

1. Processing Procedure Data The verification system according to the present invention verifies processing procedure data including actions and flows, such as business flow data. The business flow data is a flow chart showing a business flow (flow) and a business content (action). The business flow data is used to unify the business flow within the organization and reduce processing errors. In each action, it is shown that documents, electronic data, etc. (evidence) are generated and stored.

  The verification system according to the embodiment of the present invention verifies whether the state change of the evidence processed by the action indicated in the business flow data is consistent with the flow.

  FIG. 1 shows business flow data as an example of processing procedure data to be verified. This business flow data shows the flow and action at the time of planning, and a plan document and a consent document are shown as evidence.

  The business flow data shown in FIG. 1 is generated by a business flow creation program or the like. Actually, it is data described by XML data or the like as shown in FIGS. 2a, 2b, and 2c, but the computer can display it on the display as a diagram as shown in FIG. Hereinafter, in order to facilitate understanding, business flow data will be described as a diagram.

  In FIG. 1, a black circle appearing at the top of the business flow indicates a trigger action SA. The trigger action SA indicates the start of business flow data. A double circle appearing at the end of the business follow indicates an end action EA. The end action EA indicates the end of the business flow data.

  In the action AC1, it is shown that a plan is created. The evidence to be processed in this action AC1 is a plan document. Therefore, “plan” is shown as the processing target evidence EV1 adjacent to the action AC1. In the action AC1, evidence is generated and (+) is described. (-) Is described when the evidence disappears (storage or destruction).

  Action AC2 indicates that the plan is reviewed. The processing target evidence EV2 is a plan. In this action AC2, since no evidence is generated or disappears, neither of the (+) and (-) marks is attached.

  Action AC3 indicates that it is determined whether or not the budget scale of the plan is 3 million yen or more. If it is 3 million yen or more, the approval of the department Y is required (action AC5), and if it is less than 3 million yen, the supervisor X approves it (action AC4). An action that needs to be determined like the action AC3 is called a determination action.

  In the action AC4, a plan document and an acceptance document are shown as the processing target evidence EV4. Since the consent form is generated by this action, it is marked with a (+) mark.

  In the action AC5, a plan document and an acceptance document are shown as the processing target evidence EV5. Since the consent form is generated by this action, it is marked with a (+) mark.

  Action AC6 is an action that combines two or more processes. That is, it indicates that the process proceeds to the next action AC7 regardless of whether the process of action AC4 or action AC5 is performed. Such an action is called merging in the sense of combining processes.

  In action AC7, it is indicated that the plan / acceptance document is stored. Accordingly, a plan document and a consent document with a (−) mark are shown as the processing target evidence EV7.

  The business flow data created as described above is used as business guidelines in the organization.

  FIG. 3 shows the types of actions that appear in the business flow data. The trigger action, end action, normal action, determination action, and merge action are as described in FIG. A fork action that is a simple branch represents that the process branches into two or more. In the determination action, the process proceeds to any one flow according to the determination content. In the fork action, the process proceeds to a plurality of flows simultaneously without determination. A join action is a combination of processes similar to a merge action. The join action is different from the merge action in that it does not shift to the next action unless all actions on the input side are performed.

  The join action, which is a simple combination, is used when, for example, when the document A and the document B are prepared, the next action is executed. Therefore, even if only the document A has arrived, if the document B has not reached, the next action is not performed.

  The output terminal is used as a connection destination when the business flow diagram is divided into a plurality of diagrams. Similarly, the input terminal is used to indicate a connection source when the business flow diagram is divided into a plurality of diagrams.

As the business flow data becomes more complicated, more evidence appears and the flow becomes more complicated. Therefore, an error may occur in the generated business flow data. Errors in business flow data, which should be a unified guideline for business, are fatal and must be avoided. The verification system according to the embodiment of the present invention verifies whether there is no error in the business flow data. In particular, it is verified whether the change in the state of evidence processed by the action indicated in the business flow data is consistent with the flow.

2. 4 is a functional block diagram of a verification system according to an embodiment of the present invention. The processing procedure data D is data to be verified such as business flow data. The partial graph extraction unit 2 extracts the partial graph data W from the processing procedure data D. The subgraph determination unit 4 determines whether or not the state change of the processing target (evidence, for example) is consistent in relation to the flow for each extracted partial graph data W.

  The determination result output means 6 determines that the change in the processing target is not consistent with the processing procedure if any of the partial graph data W constituting the business flow data is determined to be inconsistent. Output the result. When it is determined that all the partial graph data W constituting the business flow data D are consistent, a determination result that the change of the processing target is consistent with the processing procedure is output.

  The operation of the system in FIG. 4 will be described by taking as an example the case of verifying the business flow data as shown in FIG.

  The partial graph extraction unit 2 extracts the partial graph data W by paying attention to the determination action in the business flow data. In the case of the business flow data shown in FIG. 5, the determination action AC3 is focused. This determination action AC3 branches to “L” and “R”. As shown in FIGS. 6A and 6B, the subgraph extracting unit 2 performs the flow from the trigger action SA to the end action EA for each of the case where the decision action AC3 branches to “L” and the case where the branch to “R”. Extract. This is called partial graph data W (L), W (R) (sometimes referred to as restriction graph data in the present specification). Therefore, here, the two partial graph data W (L) and W (R) shown in FIGS. 6A and 6B are extracted.

  6A and 6B, partial graph data W (L) and W (R) are schematically shown. Specifically, the partial graph data W (L) is recorded as a series of actions such as SA-AC1-AC2-AC3 (L) -AC4-AC5-AC6-AC7-AC8-EA1. In addition, which evidence is included in each action can be understood by referring to the business flow data. The same applies to the partial graph data W (R).

  Next, the subgraph determination means 4 is consistent with the flow in the state change of the evidence to be processed for each of the two subgraph data W (L) and W (R) extracted above. Determine whether or not. If the two partial graph data W (L) and W (R) are both consistent, it can be determined that the entire business flow data is also consistent.

  The subgraph judging means 4 extracts the life cycle of evidence from the subgraph data W (L). If the life cycle of all the extracted evidences is normal, it is determined that the subgraph data W (L) is consistent. The same determination is made for the partial graph data W (R).

  For the partial graph data W (L) in FIG. 6A, the life cycles LLA, LLB, and LLC of the evidences A, B, and C are extracted as shown in FIG. 7A. Similarly, for the partial graph data W (R) in FIG. 6B, life cycles LRA, LRB, and LRC of evidence A, B, and C are extracted as shown in FIG. 7B.

  In the figure, the life cycle of evidence is schematically shown. Specifically, for example, the life cycle LLA is recorded as (+) A−A − (−) A. The same applies to other life cycles.

  If the life cycle of each evidence satisfies all the following conditions i) to v), it can be determined that the life cycle is normal.

i) All actions included in the lifecycle include evidence
ii) The first action in the life cycle has evidence of the (+) mark
iii) Actions other than the first action in the life cycle have no (+) mark evidence
iv) The last action in the lifecycle has evidence of the (-) mark
v) Actions other than the last action in the life cycle do not have evidence of the (-) mark. The life cycles LLA, LLB, and LLC shown in FIG. 7A all satisfy the above conditions. It can be determined that the partial graph data W (L) is consistent. Similarly, since the life cycles LRA, LRB, and LRC of the evidences shown in FIG. 7B all satisfy the above conditions, it can be determined that the partial graph data W (R) in FIG. 6B is also consistent.

  The judgment result output means 6 judges that the change in evidence is consistent with the processing procedure as a whole because all the partial graph data W (L) and W (R) included in the business flow data are consistent. be able to. And the result is output.

  For example, assume that business flow data as shown in FIG. 8 is verified. The partial graph extraction means 2 extracts the partial graph data W (L) shown in FIG. 9A and the partial graph data W (R) shown in FIG. 9B.

  The subgraph determining means 4 finds that the life cycle LRC in FIG. 9B does not satisfy the above condition ii) (meaning that the evidence C appears without being created). Therefore, it can be detected that the evidence C of the partial graph data W (R) is not consistent.

  The judgment result output means 6 outputs that there is no consistency with the evidence C of the subgraph data W (R).

As described above, the business flow data can be verified.

3. Hardware Configuration FIG. 10 shows a hardware configuration when the verification system is constructed using a CPU. A display 12, a memory 14, a keyboard / mouse 16, a CD-ROM drive 18, and a hard disk 22 are connected to the CPU 10.

  The hard disk 22 stores an operating system (such as WINDOWS (trademark) of Microsoft Corporation) 24, a business flow creation program 26, a verification program 28, and business flow data 30.

  The business flow creation program 26 is a program for creating business flow data 30 and performs its function in cooperation with the operating system 24. The verification program 28 is a program for verifying the consistency of the created business flow data 30 and performs its function in cooperation with the operating system 24.

The business flow creation program 26 and the verification program 28 are both installed on the CD-ROM 20 through the CD-ROM drive 18.

4). Verification Program The function of the verification program 28 recorded on the hard disk 22 is basically the same as that shown in FIG. However, in this embodiment, the subgraph determining unit 4 includes a line extracting unit 40, an in-line process target determining unit 42, and a line determining unit 44 as shown in FIG.

  The line extraction means 40 extracts line data L from the business flow data. The in-line process target determination unit 42 determines whether the change in the evidence that is the process target is consistent for each extracted line data L.

  The line determination means 44 determines that the consistency determination obtained for each line data and each processing target is inconsistent if it is determined to be inconsistent with reference to other line data. Find what you can do. This determination is made for each extracted partial graph data W. Thereby, it is determined whether or not the evidence change is consistent with the processing procedure in each line data L constituting the partial graph data W.

  If the change in the evidence is consistent for all the line data L constituting the partial graph data W, it is determined that the partial graph data W is consistent.

  FIG. 12a shows a flowchart of the verification program 28 in this embodiment. First, in step S1, the CPU 10 extracts partial graph data from the business flow data 30 to be verified. Here, description will be made assuming that the business flow data 30 as shown in FIG. 13 is verified. The business flow data 30 in FIG. 13 includes two determination actions AC3 and AC11. Therefore, as shown in FIGS. 14A, 14B, and 15, the three partial graph data W (1-L, 2-L), W (1-R, 2-L), W (1-R, 2- R) will be extracted.

  Note that W (1-R, 2-L) indicates a partial graph when “R” is determined in the determination action AC3 and “L” is determined in the determination action AC11. Since there are two judgment actions, four partial graph data are likely to be extracted. However, in the business flow data of FIG. 13, the partial graph data W (1-L, 2-L) and the partial graph data W (1- Since (L, 2-R) is the same, three subgraph data are extracted. The extracted partial graph data is recorded on the hard disk 22.

  Next, the CPU 10 executes step S2 and subsequent steps for the business flow data 30. As shown in step S2, each flow in the business flow data 30 is detected, and the repetition process of steps S3 and S4 is executed for each flow (loop 01).

  As shown in step S3, line data L is extracted according to the detected flow. Then, step S4 and subsequent steps are repeated for each detected line data L (loop 02).

  Here, the line data L is a flow connection in the business flow data and satisfies all of the following conditions i) to iii).

i) The action of the flow at the start point is a normal action (which means an action other than decision, merge, fork, and join) or a trigger action.

ii) The action of the end-point flow is a normal action.

iii) There is no normal action between the start and end points.

Therefore, no evidence is written in the line data L other than the start point or the end point.

  In this embodiment, line data L is extracted from the business flow data 30 based on the above conditions using, for example, a depth highest priority search algorithm. The CPU 10 records the extracted line data L on the hard disk 22. Here, line data La, Lb, Lc, Ld, Le, Lf, L1, L2, L3, and L4 indicated by arrows in FIG. 16 are extracted.

  CPU10 performs said state grasp according to the step shown to step S4-S14. As shown in step S4, the CPU 10 extracts the evidence described in the line from the extracted line data. For example, since the line data La in FIG. 16 has evidence A, it is extracted as line data (La, A). Since line data L4 has evidences A, B, and C, three line data such as line data (L4, A), line data (L4, B), and line data (L4, C) are stored. Extract.

  Next, the CPU 10 determines which of the four states shown in Table 1 is about each extracted line data L, and records it in association with the line data L.

  The consistent continuation state and the consistent non-continuation state can be determined to be consistent when the line data is alone.

  The inconsistent appearance state and the inconsistent disappearance state have a possibility that it is finally determined that there is no consistency.

  Specifically, the CPU 10 grasps the state of each of the extracted line data by the processing from step S5 onward (loop 03).

  First, in step S <b> 5, the CPU 10 determines whether or not the target line data L meets the “consistent continuation state” condition shown in Table 1. If this determination is affirmative, the CPU 10 records in the hard disk 22 that the line data L is in a consistent continuation state (see FIG. 17). For example, line data (Lb, A), line data (L2, B), etc. meet the above conditions, and are recorded as a consistent continuation state as shown in FIG.

  For the line data L in the consistent continuation state, the CPU 10 determines whether the line data L has a fork or a join (step S6). Otherwise, the process proceeds to step S14, and the process of loop 03 is repeated. If it has a fork or a join, the line data L is classified and recorded as a solution Suc (step S7). For example, since the line data (L2, B) has a fork, it is classified and recorded as a solution Suc as shown in FIG. Then, it progresses to step S14 and repeats the process of the loop 03.

  If the determination in step S5 is negative (that is, if it is not the consistent continuation state), the CPU 10 determines whether the target line data L meets the “inconsistent appearance state” condition shown in Table 1. (Step S8). If this determination is affirmative, the CPU 10 records in the hard disk 22 that the line data L is in an inconsistent appearance state (see FIG. 17). For example, since the line data (L1, C) meets the above condition, it is recorded as an inconsistent appearance state as shown in FIG.

  For the line data L that is in an inconsistent appearance state, the CPU 10 determines whether the line data L has a join (step S9). If it has a join, the line data L is classified and recorded as a resolvable non-matching Inq (step S10). Then, it progresses to step S14 and repeats the process of the loop 03.

  If there is no join, the line data L is classified and recorded as unresolvable inconsistent Res (step S13). For example, since the line data (L1, C) does not have a join, as shown in FIG. 19, it is classified and recorded as unresolvable non-matching Res. Then, it progresses to step S14 and repeats the process of the loop 03.

  If the determination in step S8 is negative (that is, neither the consistent continuation state nor the inconsistent appearance state), the CPU 10 indicates that the target line data L is in the “inconsistent disappearance state” shown in Table 1. It is determined whether the condition is met (step S11). If this determination is affirmative, the CPU 10 records in the hard disk 22 that the line data L is in an inconsistent disappearance state (see FIG. 17). For example, line data (L4, A), line data (L4, B), line data (L2, A), etc. meet the above conditions and are recorded as inconsistent disappearance states as shown in FIG. .

  For the line data L that is in an inconsistent disappearance state, the CPU 10 determines whether the line data L has a fork (step S12). If it has a fork, the line data L is classified and recorded as a resolvable non-matching Inq (step S10). For example, line data (L4, A), line data (L4, B), and the like have a fork, and are classified and recorded as resolvable non-matching Inq as shown in FIG. Then, it progresses to step S14 and repeats the process of the loop 03.

  If it does not have a fork, the line data L is classified and recorded as unresolvable inconsistent Res (step S13). Then, it progresses to step S14 and repeats the process of the loop 03.

  When the determination in step S11 is negative (that is, in the consistent continuation state, the inconsistent appearance state, or the inconsistent disappearance state), the CPU 10 determines the target line data L as the consistent discontinuity. Classify and record the status. For example, the line data (La, A) is classified and recorded in a consistent non-continuation state as shown in FIG.

  In the above description, the line data (L1, C) classified as unresolvable inconsistent Res is determined to be inconsistent. As can be seen from FIG. 18, there is an inconsistency that evidence C appears suddenly.

  Line data (L2, A) (L3, B) (L3, C) (L4, A) (L4, B) (L4, C) classified as non-matchable non-matchable Inq is related to other line data Depending on the situation, there is a possibility that it can be determined to be consistent.

  The line data (L2, B) (L2, C) (L3, A) classified as the solution Suc is for solving the inconsistency of the line data that is determined to be the above-described resolvable inconsistent Inq.

  After classifying the line data L as described above, the CPU 10 determines whether there is a solution for the line data classified as solvable non-matching Inq for each partial graph data extracted in step S1 ( That is, it is determined whether or not there is consistency. This processing flowchart is shown in FIG.

In step S20, it is shown that processing is performed for each partial graph data as loop 04. From the target subgraph data, the CPU 10
Lines classified into the solution Suc and the resolvable non-matching Inq are extracted (step S21). In step S21 of FIG. 12b, SucΠW (i) means a collection of line data (L, E) included in Suc and L included in W (i). The same applies to InqΠW (i).

  Specifically, in the case of the partial graph data W (1-L, 2-L), nothing is extracted because there is no corresponding data (see FIG. 20B). For the partial graph data W (1-R, 2-L), line data (L2, B) (L2, C) (L3, A) is selected as the solution Suc, and the line data (L2 , A) (L3, B) (L3, C) are selected (see FIG. 20B). For the partial graph data W (1-R, 2-R), the line data (L2, B) (L2, C) is selected as the solution Suc, and the line data (L2, A) (L4 , A) (L4, C) is selected (see FIG. 20B).

  Next, the CPU 10 performs the processing from step S23 onward for each line data (L2, A) (L3, B) (L3, C) extracted as the resolvable non-matching Inq (step S22).

  In step S23, the CPU 10 determines whether or not there is line data L ′ (solution Suc) as a solution with respect to the target line data L of the resolvable non-matching Inq (step S23). Specifically, this determination is made by line data L ′ that merges with the line data L or branches from the line data L, and has the same flow and the same evidence as the line data L. This is performed based on whether L ′ is in the solution Suc extracted from the subgraph W.

  If there is no solution Suc that matches the above condition, the target resolvable non-matching Inq line data L is recorded in the unsolvable non-matching Res. (Step S24). If the solution Suc exists, it is determined that the line data L of the resolvable non-matching Inq is consistent.

  For example, for the evidence A of the line data (L2, A), there is line data (L3, A) as a solution having the evidence. Therefore, it can be determined that the line data (L2, A) is consistent. As can be seen from FIG. 20B, the evidence A disappears from the processing of the line data L2 due to the presence of the fork, but is processed by the line data L3 and can be said to be consistent. Represents that.

  Similarly, line data (L2, B) (L2, C) exist as solutions for the line data (L3, B) (L3, C), respectively. Therefore, it can be determined that the partial graph data W (1-R, 2-L) is consistent.

  Therefore, the partial graph data W (1-R, 2-L) is newly recorded as unresolvable inconsistent Res in addition to the line data (L1, C) already recorded as unresolvable inconsistent Res. There is no line data to do.

  On the other hand, for the partial graph data W (1-R, 2-R), an unsolvable inconsistent Res is newly found and recorded as follows. First, the CPU 10 selects only the line data included in the partial graph data W (1-R, 2-R) from the line data classified in FIG. 19 (step S21). Therefore, the line data (L2, B) (L2, C) is selected as the solution Suc, and the line data (L2, A) (L4, A) (L4, B) (L4, C) is selected as the resolvable non-matching Inq. Selected (see FIG. 21).

  For the line data (L4, B) (L4, C) that is the resolvable non-matching Inq, the line data (L2, B) (L2, C) that is the solution Suc exists. However, there is no solution for the line data (L2, A) (L4, A). Therefore, the CPU 10 records the line data (L2, A) (L4, A) in the unresolvable non-matching Res as non-matching. As a result, the line data (L1, C) (L2, A) (L4, A) is recorded in the unresolvable non-matching Res.

  Next, the CPU 10 executes step S27 and subsequent steps for each line data L of the solution Suc in the target subgraph W (loop 05). In step S27, it is determined whether or not there is a contradiction regarding the solution Suc of the target subgraph W in relation to other solutions Suc of the target subgraph W. Specifically, the line data L ′ having the same flow and the same evidence as the line data L of the solution Suc of the target subgraph W, which is merged with the line data L or branched from the line data L It is determined whether L ′ is in the solution Suc of the target subgraph W (step S27). The existence of such line data L ′ means that there is an inconsistency in which there is one evidence that should originally be plural or one evidence is plural due to branching or merging of flows. Will be. Therefore, if such line data L ′ exists, the CPU 10 records this in the unsolvable non-matching Res (step S28). Then, it progresses to step S30 and repeats the process of loop 06.

If the line data L ′ is not found, do nothing.
Proceeding to step S30, the process of loop 05 is repeated.

  When all the processes of loop 05 and loop 04 are completed, the CPU 10 then performs non-matching based on the line data (L1, C) (L2, A) (L4, A) recorded in the unsolvable non-matching Res. The indication of the part is displayed on the display 12 (may be output from a printer or the like, or output as data) (step S32).

  For example, as shown in FIG. 22, business flow data is displayed on a display, line data (L1, C) (L2, A) (L4, A) that are unresolvable inconsistent Res, and problematic evidence A, C. Can be displayed so as to be distinguishable by highlighting or the like.

  In addition to the above display (or by itself), non-matching contents may be displayed in characters or the like. For example, the following display can be performed.

i) When 1-L, C appears improperly in L1
ii) When 1-R and 2-R, Act1's A does not move anywhere. Note that the above message is displayed by classifying the situation and preparing sentences corresponding to each situation in advance. can do.

  Note that the business flow diagram (activity diagram) shown in the above example is shown for explanation, and other business flow diagrams can be verified by the present invention.

5). Other Embodiments In the above embodiment, the case where the processing procedure data is recorded as one file has been described. When the processing procedure data extends over two or more files, the verification can be performed by connecting the flow start point and end point in each file.

  In the above embodiment, the case where the processing target is evidence has been described. However, if it is processed by an action and its state changes, it can be similarly verified.

  In the above embodiment, the partial graph data is extracted in step S1, but may be performed after step S5 and before step S6.

  In the above embodiment, after extracting and classifying line data from the entire business flow data, a solution is searched for each partial graph data. However, line data may be extracted and classified for each partial graph data to find a solution.

  Moreover, in the said embodiment, the system which stored the verification program in the stand-alone computer was shown. However, a verification program may be recorded in the server device so that the verification program can be used from the client device via the Internet or the like. In this case, the processing procedure data to be verified may be recorded on the client device side.

  In the above embodiment, the processing procedure data creation program and the verification program are independent. However, a verification program may be provided as a function of the processing procedure data creation program.

  In the above embodiment, it is assumed that (+) mark is attached to the occurrence of evidence and (−) mark is attached to the disappearance in the business flow data. However, it is also possible to verify the business flow data with only the (+) mark without the (-) mark. In this case, in the classification of line data, it is sufficient to use Table 2 instead of Table 1. In Table 2, an inconsistent disappearance state is not provided. Other processes are the same as those in the above embodiment.

  In Table 2, the consistent continuation state is also obtained when both the start point and end point of the line data have evidence and the end point evidence has a (+) mark. However, in order to make a more accurate determination, this may be classified as an inconsistent disappearance state. In this case, Table 3 is used.

  Further, it is possible to verify the business flow data with only the (+) mark but not the (+) mark. In this case, it is sufficient to use Table 4 in place of Table 1 in the classification of line data. In Table 4, no inconsistent appearance state is provided. Other processes are the same as those in the above embodiment.

  In Table 4, the consistent continuation state is also established when both the start point and end point of the line data have evidence, and the evidence at the start point has a (-) mark. However, in order to make a more accurate determination, this may be classified as an inconsistent appearance state. In this case, Table 5 is used.

  Furthermore, it is possible to verify business flow data without a (+) mark or a (-) mark. However, in one business flow data, the business flow data must be created so as to satisfy the assumption that evidence that has once disappeared (saved or discarded) will not be restored. Even in this case, the process up to the extraction of the subgraph is the same as in the above embodiment. However, the processing in the subgraph determining unit 4 is different. The subgraph determination means 4 makes the following determination for each evidence for each extracted subgraph. That is, if the evidence E is included in the subgraph, it is determined whether the evidence E is continuously included in a single sequence of flows. If this determination is positive for all evidence in all subgraphs, it is determined that the life cycle is consistent. If negative, it is determined that the life cycle is not consistent.

  For example, an example of the above determination is shown for the case where the extracted partial graph is the one shown in FIG. Evidence A appears in actions 101 and 103, but does not appear in action 102 and is not continuous. Therefore, it is determined that the life cycle is inconsistent.

  Evidence B appears continuously with actions 102, 103, and 104, and is judged to be consistent.

  Evidence C appears continuously with actions 103, 104, and 105. However, there is a flow of actions 103 and 106. Therefore, it cannot be said that it appears as a single series of flows, and is judged to be inconsistent.

6). Operation and Implementation FIG. 24 shows an operation example of the verification system according to the present invention. If the verification program 28 is recorded in each of the terminal devices T1 and T2, the business flow 30 can be checked in each of the terminal devices T1 and T2. If the verification program 28 is recorded in the server device S, the business flow 30 can be transmitted from the terminal devices T1 and T2 to the server device S and checked. If the verification program 28 is recorded in both the terminal devices T1, T2 and the server device S, any of the above checks can be performed.

  FIG. 25 shows a package configuration example of the verification program according to the present invention. The conversion program 27 receives the business flow created by the business flow creation program 26 and converts the format of the business flow into a format that can be processed by the verification program 28. For example, the conversion program 27 deletes image data and the like that are unnecessary for verification from the workflow created by the workflow creation program 26.

  The interface module 25 displays a button for a verification start command on the creation screen of the business flow creation program 26, or detects that the button has been pressed and starts the verification process by the conversion program 27 / verification. The program 28 is instructed. It is also the role of the interface module 25 to receive the verification result by the verification program 28 and display it on the creation screen of the business flow creation program 26.

  The business flow diagram in the above embodiment is defined for the sake of explanation, and the present invention can be applied to other business flow diagrams.

It is a figure which shows the business flow data which is an example of the process procedure data made into verification object in this invention. It is a figure which shows the business flow data of FIG. 1 expressed by the XML format. It is a figure which shows the business flow data of FIG. 1 expressed by the XML format. It is a figure which shows the business flow data of FIG. 1 expressed by the XML format. It is a figure which shows the action used in business flow data. It is a functional block diagram of the verification system by one Embodiment of this invention. It is a figure which shows the example of business flow data. It is a figure which shows partial graph data. It is a figure for showing the life cycle of evidence. It is a figure which shows partial graph data. It is a figure for showing the life cycle of evidence. It is a figure which shows the hardware constitutions of the verification system by other embodiment. It is a functional block diagram of a verification system. It is a flowchart of a verification program. It is a flowchart of a verification program. It is a figure which shows the example of business flow data. It is a figure which shows partial graph data. It is a figure which shows partial graph data. It is a figure which shows the detection of line data. It is a figure which shows the data which recorded the state of each line. It is a figure which shows the classification | category of each line. It is a figure which shows the data which recorded the classification | category of each line. It is a figure which shows the determination for every partial graph data. It is a figure which shows the determination for every partial graph data. It is an example of a display of a non-matching part. It is a figure which shows the judgment with respect to the business flow data without a (+) mark and a (-) mark. It is a figure which shows the operation example of a verification system. It is a figure which shows the package structural example of a verification program.

Explanation of symbols

2 ... Subgraph extraction means 4 ... Subgraph judgment means 6 ... Judgment result output means D ... Processing procedure data W ... Subgraph data

Claims (14)

In the processing procedure data including an action and a flow, a verification system for verifying whether the state change of the processing target processed by the action is consistent with the processing procedure indicated by the processing procedure data,
A recording unit for recording processing procedure data;
A subgraph extracting means for extracting a plurality of flows from the start to the end as subgraph data based on the judgment action in the processing procedure data;
For each extracted subgraph data, a subgraph judging means for judging whether the state change of the processing target in each action is consistent in relation to the flow;
A determination result output means for outputting whether or not the state change of the processing target is consistent with the processing procedure indicated by the processing procedure data based on the determination result of the subgraph determination means;
Verification system with The system of claim 1, wherein
The subgraph judging means is
From subgraph data or processing procedure data, have an action that causes a change in the state of one of the processing objects at at least one of both ends, and do not have an action that causes a change in the state of any of the processing objects other than both ends Line extraction means for extracting the correct line data;
In-line process target judging means for judging whether the state change of the process target is consistent or inconsistent with respect to each of the process targets appearing in at least one of the both ends in each extracted line data ,
Based on the determination result for each processing target obtained by the in-line processing target determination means, other line in the same subgraph data is referred to for the state change of the processing target determined to be inconsistent. If it can be found that it is consistent, the state change of the processing target is determined to be consistent, and if it cannot be determined consistent even if other lines are referenced, Line determination means for determining that the state change of the processing target is inconsistent,
A system characterized by comprising: In the system according to claim 1 or 2,
The in-line process target judging means is:
It has an action for the processing target at both the start point and the end point, the start point action is not the end process for the processing target, and the end point action is a line that is not the start process for the processing target, and is recorded as a consistent continuation state.
If there is an action for the processing target at the end point, and the action at the end point is not a start process for the processing target, but has an action for the processing target at the start point, the line in which the action is an end process for the processing target appears inconsistently Record as state,
If there is an action for the processing target at the end point, and the action at the end point is not an end process for the processing target, but has an action for the processing target at the end point, the line that is the start process for the processing target is inconsistently disappeared Record as state,
A system that records a line that does not correspond to any of the above states as a consistent discontinuous state. The system of claim 3,
The line determination means includes
If a line recorded as a consistent continuation has a simple branch or simple connection, record the line as a “solution”
If a line recorded as inconsistent appearance has a simple join, record the line as “solvable inconsistency”;
If a line recorded as inconsistent appearance has a simple branch, record the line as “solvable inconsistency”;
Lines recorded as inconsistent application states or inconsistent extinction states other than the above are recorded as “unresolvable inconsistencies”. The system of claim 4, wherein
The line determination means includes
Determine whether a line that can resolve the inconsistency of the line recorded as “solvable inconsistency” is recorded as “solution” in the same subgraph data,
Depending on the above judgment, a “solvable non-matching” line where the “solution” for solving cannot be found, the same start point and the same evidence, and the end point is different, or
A system characterized by extracting a plurality of “solution” lines and “unresolvable non-matching” lines having the same end point and the same evidence but different starting points as inconsistent portions. In the system in any one of Claims 1-5,
The flow indicated by the processing procedure data spans multiple files,
By connecting the end of a flow in a file and the start of a flow in another file corresponding to the end, a system that generates a flow across multiple files is the target of consistency judgment processing. . A processing procedure data generation system for generating processing procedure data having an action and a flow,
In order to verify whether the state change of the processing target processed by the action is consistent with the processing procedure for the processing procedure data being created or completed, the system according to claim 1 is provided. A processing procedure data generation system characterized by the above. A verification program for causing a computer to function as a verification system. The verification program uses a plurality of flows from the start to the end as subgraphs based on the determination action in the processing procedure data recorded in the recording unit. A subgraph extracting means for extracting;
In the extracted subgraph, when attention is paid to each processing target, a subgraph determining unit that determines whether the state change of the processing target is consistent in relation to the flow;
Based on the determination result of the subgraph determination means, it functions as a determination result output means for outputting whether or not the state change of the processing target is consistent with the processing procedure indicated by the processing procedure data. The program of claim 8,
The subgraph judging means is
From subgraph data or processing procedure data, have an action that causes a change in the state of one of the processing objects at at least one of both ends, and do not have an action that causes a change in the state of any of the processing objects other than both ends Line extraction means for extracting the correct line data;
In-line process target judging means for judging whether the state change of the process target is consistent or inconsistent with respect to each of the process targets appearing in at least one of the both ends in each extracted line data ,
Based on the determination result for each processing target obtained by the in-line processing target determination means, other line in the same subgraph data is referred to for the state change of the processing target determined to be inconsistent. If it can be found that it is consistent, the state change of the processing target is determined to be consistent, and if it cannot be determined consistent even if other lines are referenced, Line determination means for determining that the state change of the processing target is inconsistent,
A program characterized by comprising: In the program according to claim 8 or 9,
The in-line process target judging means is:
It has an action for the processing target at both the start point and the end point, the start point action is not the end process for the processing target, and the end point action is a line that is not the start process for the processing target, and is recorded as a consistent continuation state.
If there is an action for the processing target at the end point, and the action at the end point is not a start process for the processing target, but has an action for the processing target at the start point, the line in which the action is an end process for the processing target appears inconsistently Record as state,
If there is an action for the processing target at the end point, and the action at the end point is not an end process for the processing target, but has an action for the processing target at the end point, the line that is the start process for the processing target is inconsistently disappeared Record as state,
A program that records a line that does not correspond to any of the above states as a consistent non-continuation state. The program of claim 10, wherein
The line determination means includes
If a line recorded as a consistent continuation has a simple branch or simple connection, record the line as a “solution”
If a line recorded as inconsistent appearance has a simple join, record the line as “solvable inconsistency”;
If a line recorded as inconsistent appearance has a simple branch, record the line as “solvable inconsistency”;
Recording a line recorded as an inconsistent application state or inconsistent extinction state other than the above as “unresolvable inconsistency”. 12. The program of claim 11, wherein
The line determination means includes
Determine whether a line that can resolve the inconsistency of the line recorded as “solvable inconsistency” is recorded as “solution” in the same subgraph data,
A program characterized by extracting a “solvable non-matching” line and a “unsolvable non-matching” line from which a “solution” for solving cannot be found based on the above determination as an inconsistent part. In the program in any one of Claims 8-12,
The flow indicated by the processing procedure data spans multiple files,
By connecting the end of a flow in a file and the start of a flow in another file corresponding to the end, a program that generates a flow across multiple files is the target of consistency judgment processing. . A processing procedure data generation program for generating processing procedure data having an action and a flow,
In order to verify whether the state change of the processing target processed by the action is consistent with the processing procedure for the processing procedure data being created or completed, the program according to any one of claims 8 to 13 is provided. A processing procedure data generation program characterized by the above.

Images