CN107273407B - A Discovery Method for Conflicting Operations in MOF Repository Based on Constraint Deduction - Google Patents

Abstract

The invention relates to a method for discovering MOF storage bank conflict operation based on constraint deduction, which is technically characterized by comprising the following steps of: defining internal activities that affect good format constraints and establishing their correspondence to MOF construction activities; simplifying good format constraints; establishing a discovery graph; marking the discovery map; obtaining internal activities; potential operations that violate the constraints are determined. The invention can deduce the constraint condition irrelevant to the given operation by deducing the internal activity which may violate the constraint condition and further deducing the potential operation which violates the constraint condition. The constraint conditions which are irrelevant to the given operation are removed from the constraint detection process after the operation is executed, so that the efficiency of the process can be obviously improved, and the method can be widely applied to the field of constraint detection.

Description

A Discovery Method for Conflicting Operations in MOF Repository Based on Constraint Deduction

technical field

The invention belongs to the technical field of storage library systems, in particular to a method for discovering conflict operation of MOF storage library based on constraint deduction.

Background technique

Today, the Meta Object Facility (MOF) has become an internationally accepted and adopted metadata repository system standard. As an important part of the MOF repository system, well-formed constraints defined based on the Object Constraint Language OCL specify the conditions that all states of the system must comply with. The contents of the repository system can be changed by the execution of the operation, so it must be ensured that the state of the repository system after the operation is performed does not violate the well-formed constraints in the meta-level.

However, this task is quite difficult for two reasons: On the one hand, the organization of metadata in repository systems presents a complex structure that is hierarchical, multi-level, and dynamically changing. Unlike the database system, the repository system introduces the M3 layer to allow users to define the M2 layer. Layers M2, M1, and M0 can all be dynamically modified at runtime; on the other hand, the MOF standard does not specify enough constraints to ensure well-formedness. MOF provides several mechanisms for ensuring repository system consistency, including: first, MOF defines a set of model constraints; second, MOF defines a set of closure rules and computational semantics for abstract mappings, and the JAVA metadata interface JMI is Jave maps define computation semantics; thirdly, MOF provides constraint model elements for describing domain rules; finally, MOF and JMI define a set of repository interfaces. However, the above measures are aimed at ensuring grammatical correctness, not well-formed constraints.

The following relevant documents were found by searching: Petrov et al. (Petrov I, et al. On the notion of consistency in metadata repository systems, LNCS 3520: Proc of the 16th Int Confon Advanced Information Systems Engineering. Berlin: Springer, 2004: 90-104) discussed Various concepts of consistency in MOF-based metadata repository systems are presented, and strategies and algorithms are proposed to enhance the consistency between system states and well-formed constraints after operations are performed. However, they check all constraints in the process, making the detection process inefficient. In contrast, since only the constraints that may actually be violated are considered in the detection process, irrelevant constraints will be omitted, and our method can significantly improve the efficiency of the process. Takeshi et al. (Takeshi A, et al. Metabolonote: A wiki-based database for managing hierarchical metadata of metabolome analyses. Frontiers in Bioinformatics and Computational Biology, 2015, 15(38): 1-12) will also address the metadata exchange problem Metadata is organized into different levels, and its metadata levels are not organized according to the semantic level of metadata but according to the content and relevance of different metadata, and there is no semantic relationship between levels. The modification of the repository content by its operation will not affect the following layers, making the guarantee of constraints relatively simple, but the framework is difficult to apply to the dynamically changing complex metadata structure. The metadata framework proposed in the literature (Metadatabased management and sharing of distributed biomedical data. International Journal of Metadata, Semantics and Ontologies, 2014, 9(1): 42-57) also has similar problems.

To our knowledge, the problem of inferring the exact set of potentially conflicting constructive active PEAs for a given constraint in a MOF repository system has not been studied internationally. Similar research exists in the fields of deductive and relational databases, and the solution adopted is mainly to convert OCL constraints into logical expressions or SQL expressions, and then design algorithms on this basis to infer the exact PEA set for a given constraint, For example, Duboisset et al. (Duboisset M, et al. Integrating the calculus-based method into OCL: Study of expressiveness and code generation, Proc of the 18th Int Workshop on Database and Expert Systems Applications. Piscataway, NJ: IEEE, 2007: 502-506), Pinet et al. (Pinet F, Duboisset M, Demuth B, et al. Constraints modeling in agricultural databases, Advances in Modeling Agricultural Systems. Berlin: Springer, 2009: 1-11), Donald et al. (Donald C, Narayanaswamy K. Using first -order logic to query heterogeneous internet datasources, Proc of the 2015 Int Conf on Soft Computing and Software Engineering. Holand: Academic Press, Elsevier, 2015: 1-8), Demuth et al. (Demuth B, Hussmann H, Loecher S. OCL as a specification language for business rules in database applications, LNCS 2185: Proc of the 4th Conf on UML. Berlin: Springer, 2006: 104-117), Chen et al. (Chen Lianggang et al. Interval Constrained Database Query Language: ISQL. Computer Research and Development, 2000, 37(6):677-683), however, since OCL constraints include many complex structures such as negation, recursion, package semantics, aggregation operations, etc., the processing power of the proposed algorithm is difficult to cover all OCL constraints. mechanism. Although some algorithms have improved this to support all mechanisms of OCL constraints, the high complexity of the processing logic results in inefficient algorithms (for their limitations, see Siva et al. (Siva S, et al.) al. Constraint processing in relational database systems: From theory to implementation, Proc of the 25th ACM Symp on Applied Computing. New York: ACM, 2010: 2066-2070)).

SUMMARY OF THE INVENTION

The purpose of the present invention is to overcome the deficiencies of the prior art, and to provide a method for discovering the conflict operation of MOF repository based on constraint deduction with reasonable design, stable performance and high efficiency.

The present invention solves the existing technical problems and adopts the following technical solutions to realize:

A method for discovering conflicting operations in MOF repository based on constraint deduction, comprising the following steps:

Step 1. Define internal activities that affect well-formed constraints and establish their correspondence with MOF construction activities;

Step 2: Simplify the well-formed constraints;

Step 3: Create a discovery map;

Step 4: Mark the discovery map;

Step 5: Get the internal activity;

Step 6: Identify potential actions that violate constraints.

The internal activities are defined according to entity types and relationship types, including eight internal activity relationships including creating instances and deleting instances.

The specific implementation method of step 2 is as follows: first, the equivalent operations defined in the OCL standard library are used to reduce the number of operations appearing in the expression; then the expression is converted into an equivalent conjunctive normal form, and the converted The result is that each constraint is represented as a conjunction of disjunctions; the resulting disjunct literals include forAll iterators, arithmetic comparisons, object/set equivalence comparisons, boolean properties, the not operator, the oclIsTypeOf operator, and oclIsKindOf operator.

The step 3 is a discovery graph established according to the content-instance relationship between the well-formed constraints and the OCL metamodel.

The method of marking the discovery graph in the step 4 is: the marking for each node indicates the information of the mutual influence between the node and its successor nodes, including four different types of marking information: "+" means expressing An increase in the value of the expression or an increase in the number of items may lead to a constraint violation; "-" indicates that a decrease in the value of the expression or a decrease in the number of items may lead to a violation of the constraint; "m" indicates a change in the value of the expression or the number of items Changes in may lead to constraint violations; "nr" means that the node and its successors do not interact with each other.

The specific method of the step 5 is: obtaining according to the bottom-up step-by-step inference and aggregation process, and infers the PIA set of each constraint condition.

The specific method of the step 6 is: according to the PIA set of each constraint, convert it into the MOF standard construction activity and obtain the PEA set, and finally check whether each operation has a violated constraint. .

The advantages and positive effects of the present invention are:

The present invention defines a set of MOF internal activities that are more precise and flexible than MOF construction activities and establishes the corresponding relationship between the two; infers internal activities that may violate constraints; finally, compares the internal activities corresponding to these internal activities Whether or not the construction activity occurs in the operational specification can infer potential operations that violate constraints. The principle is that each constraint finds a set of construction activities that may violate it, and then compares it with the operation specification. If one or more construction activities are related to the operation specification, it can be concluded that the execution of the operation may violate the constraint. condition. By inferring constraints irrelevant to a given operation and removing them from the constraint detection process after the operation is performed, the present invention can significantly improve the efficiency of this process. The invention can be widely used in the field of constraint detection.

Description of drawings

Fig. 1 is the hierarchical structure example diagram of the metadata model;

Fig. 2 is an example diagram of a good format constraint in the M1 layer of the MOF repository system;

Fig. 3 is the operation example diagram of modifying the content of the repository system;

Fig. 4 is the discovery graph corresponding to the constraint OldTeacher;

Fig. 5 is the result graph after the discovery graph corresponding to constraint OldTeacher is marked;

Figure 6 is a schematic diagram of the process of inferring a potentially conflicting internal activity PIA that constrains OldTeacher.

Detailed ways

Embodiments of the present invention are described in further detail below in conjunction with the accompanying drawings:

A method for discovering conflicting operations in MOF repository based on constraint deduction, comprising the following steps:

Step 1: Define the internal activities that affect well-formed constraints and establish their correspondence with MOF construction activities.

In order to infer the set of potentially conflicting construction activities PEA for OCL well-formed constraints, we need to investigate which construction activities may be executed in violation of the constraints. Therefore, this step is mainly to define internal activities and establish their corresponding relationship with MOF construction activities. It is the internal activities that actually take part in inference during the inference process. Reasoning on top of internal rather than constructive activities is chosen for two reasons: First, our approach leverages the property that well-formed constraints are instances of the OCL metamodel, by building discovery graph instances and building on them Inference to achieve PEA inference, so it is more convenient to infer activities that may affect OCL metamodel instances. Conversely, construction activities are oriented towards the MOF model mechanism, and inference is performed directly on it (although theoretically achievable) It will bring a lot of inconvenience; secondly, there are currently many international metadata repository standards such as MOF, IRDS, PCTE, etc. Each standard defines the construction activities within its own framework. Instead, we would like to propose a general method for inferring PEA, because once the correspondence between the internal activities proposed by the present invention and the construction activities of other repository frameworks is established, the method of the present invention can be adapted to other repositories frame. This will greatly improve the applicability of our proposed method.

The following is an analysis of the element types and characteristics of the OCL metamodel. Constraint metamodel elements include entity type and relation type, on which there are two activities of creating an instance and deleting an instance, which may lead to the violation of constraints. In addition, the generalization and specialization of entity types and the activities of modifying instance attributes and association ends may lead to violation of constraints, so there are 8 kinds of internal activities. Table 1 lists these internal activities and their correspondence with MOF tectonic activities. Although there is no one-to-one correspondence between internal activities and MOF construction activities, they are more convenient for PEA inference than MOF construction activities and can be converted to construction activities through the simple mapping in Table 2. For example, if it is inferred that the internal activity AssignObject on an instance may violate constraints, and the instance is neither an associated class nor adjusted by other instances, it needs to be converted into the construction activity CreateObjectAction on the instance, if The AssignObject is caused by the change of the associated end, and the construction activity AddStructuralFeatureAction on the instance needs to be added. The transformation of other internal activities is similar and will not be repeated here.

Table 1 Internal activities and their correspondence with MOF tectonic activities

Step 2: Simplify the well-formed constraints

Equivalent simplification of OCL expressions that define well-formed constraints. First reduce the number of operations appearing in the expression using equivalent operations defined in the OCL standard library, and then convert the expression to the equivalent conjunctive normal form. The result of the transformation is that each constraint is represented as a conjunction of disjunctive terms. The resulting disjunct literals include forAll iterators, arithmetic comparisons, object/set equivalence comparisons, Boolean properties, not operator, oclIsTypeOf operator, and oclIsKindOf operator, etc. Obviously to satisfy the constraints, the repository system must satisfy every disjunction. A disjunct is satisfied requires that at least one of its literals be satisfied.

After reducing the number of operations for the 4 constraints in Figure 2, the constraints OldTeacher and UniqueName become (other constraints remain unchanged):

context School inv OldTeacher:

self.teacher->select(t|t.age>60)->size()>0

context Teacher inv UniqueName:

Teacher.allInstances()->forAll(t ₁ ,t ₂ |not t ₁ =t ₂ implies not t ₁ .name=t ₂ .name)

After further conversion to conjunctive normal form, the constraint UniqueName becomes (other constraints remain the same):

context Teacher inv UniqueName:

Teacher.allInstances()->forAll(t ₁ ,t ₂ |t ₁ =t ₂ or not t ₁ .name=t ₂ .name)

Step 3: Build a discovery graph based on the content-instance relationship between the well-formed constraints and the OCL metamodel.

In this step, each node of the graph is found as an instance of a metaclass in the OCL metamodel, representing an atomic subset of the OCL expression. The 1st successor of a node is the part of the OCL expression that precedes the node. If the node represents a binary operation (such as ">", "+", etc.), the second successor of the node is the parameter of the operation; if the node represents a loop expression (such as forAll, select, etc.), the second successor of the node A successor is the body of the iterator.

Figure 4 shows the discovery graph built according to the constraint OldTeacher(self.teacher->select(t|t.age>60)->size()>0). The instance of the metaclass OperationCallExp corresponding to the operation ">" is the initial node, and its 1st successor is the expression located before the ">" (self.teacher->select(t|t.age>60)->size( )) and the next successor is the parameter of the operation (integer constant 0). The 1st successor of the 1st successor of the initial node is the operation size, which has only 1 child select. The first successor of node select is the association end teacher and the second successor is the operation ">" between the attribute age and the integer constant 60.

Step 4: Label the discovery map

In order to infer a PEA set for a given constraint, it is not enough to consider each part of an OCL expression alone. For example, in order to infer whether the constraint OldTeacher may be violated by the two activities of assigning a teacher to a school or releasing a teaching relationship, one cannot just consider the subexpression self.teacher->select(t|t.age>60)->size(). In fact, both of these two activities may change the value of the subexpression. However, since the size operation is followed by the ">" operation, the constraint violation can only be caused by releasing the teaching relationship. On the contrary, if the size is followed by the "<=" operation , then only assigning classrooms to schools may result in a violation of constraints. The above analysis shows that the PEA set for a given constraint can be correctly inferred only by comprehensively considering the contextual information of each subset of OCL atoms, so it needs to be labeled with the contextual information of each node in the discovery graph.

Labels for each node indicate information about the interaction between that node and its successors. Based on a comprehensive analysis of various structures of OCL, we conclude four different types of tag information: 1) "+" indicates that an increase in the value of an expression or an increase in the number of items may lead to a violation of constraints; 2) "-" indicates that The reduction of the value of the expression or the reduction of the number of items may lead to the violation of the constraint; 3) "m" indicates that the change of the value of the expression or the change of the number of items may lead to the violation of the constraint; 4) "nr" indicates that the node and its successors Nodes do not affect each other.

An example of each marker is given below. For "+" and "-", considering the ">" operation, there are 2 situations to violate the constraint A>B: the decrease of the value of A or the increase of the value of B, so the first successor node of the node ">" should be is marked with a "-", and above the 2nd successor node should be marked with a "+". For the mark "m", considering the select operation, not only adding objects to the set to be selected or deleting objects may affect the result of the select, but even replacing some objects in the set to be selected by the same quantity may also affect the result of the select, so the successor node of the node select Above should be marked "m". For the flag "nr", consider the and operation. Since the activities of violating A and B are the same as the activities of violating A and B alone, that is to say, there is no mutual influence between the node and and its successor, so the successor of the node and Above the node should be marked "nr".

Since the process of labeling the discovery graph needs to first consider the label information on the current node and the type of the node to determine the label information on its successor nodes, the labeling process requires breadth-first traversal of the discovery graph. Table 2 summarizes the labeling methods for various node types. In the cells of Table 2, if there is more than 1 marker symbol on a node, each marker should be applied separately to determine the marker on its successor node. The content of the cell "X" indicates that there are no constraints for this combination.

Table 2 Summary of marker information for discovery graphs

The result of labeling the discovery graph corresponding to the constraint OldTeacher is shown in Figure 5. For the sake of brevity, we omit the content that has nothing to do with marking in Figure 4. In addition, for each node, the information of the cells in Table 2 used to mark the node is added, where (X, Y) represents the Xth row and the Y column 's cells.

The marking process starts with the initial node. Since ">" has no predecessor node, there is no need to mark it. According to cell (2, 1), the 1st successor of the initial node should be marked with "-" and the 2nd successor Should be marked "+", so above node size is "-". Then according to cell (11, 3), we mark the successor (node select) of node size as "-". According to cell (10, 3) ), the mark above the 1st successor of node select is "-m" and the mark above the 2nd successor is "nr". Referring again to cells (9, 3) and (9, 4), The successor node self of node teacher should be marked with "-m". The labeling of other parts is analogous, and it is not repeated here because of space limitations.

Step 5: Get Internal Activities

Once the discovery graph is marked, the next step is to infer the potential conflicting internal activity PIA for a given constraint. Since the labeling graph has clearly marked the type of the OCL atomic subset expression and how the expression changes can violate the entire constraint, the process of inferring the PIA is a bottom-up inference and summary process, that is, the breadth of the graph. Reverse process of priority traversal.

Table 3 summarizes the set of PIAs corresponding to different combinations of node types and tag information. c1+c2 indicates that the PIA set of this node is the union of the PIA sets of its successor nodes. c1 is suitable for the situation that the node has only one successor node. An empty cell means that the node does not affect the inferred summary of the PIA. In particular, it is c ₁ +X and opp(X). c ₁ +X means that the node adds activity X to the PIA set. For example, if an association end is marked "+", the establishment of a link instance of its subordinate association may result in a constraint violation, so the node should add an AssignLink activity to the PIA set, ie c ₁ +AssignLink. opp(X) indicates that the PIA of this node is the opposite activity of the PIA returned by its successor, such as a not operation. The opposite activities of the internal activities are as follows: opp(AssignObject)=RomoveObject, opp(ModifyProperty)=ModifyProperty, opp(RomoveObject)=AssignObject, opp(AssignLink)=RemoveLink, opp(RemoveLink)=AssignLink, opp(ModifyEnd)=ModifyEnd.

Table 3 PIA sets corresponding to node types and tag information

Applying Table 3 to the constraint OldTeacher, the result is shown in Figure 6. Node self is processed first. Since the marks above the node self are "-" and "m", according to the cells (17, 3) and (17, 4) of Table 3, it can be known that this node does not add any PIA. Then refer to cells (9, 3), (9, 4) to process the associated end teacher, and add the activities AssignObject(School), RemoveLink(TeachesIn), and ModifyEnd(TeachesIn-Teacher) to the collection of PIA. Then process the 2nd successor of node select (t.age>60), which adds the activity ModifyProperty(age). After this node select is processed, referring to cell (10, 3), the PIA set of node select is the union of the PIA sets of its successor nodes. Then process node size, integer constant node 0 and end with initial node ">", none of which add any activity. Finally, the set of PIAs returned by the initial node ">" is the set of PIAs of the entire constraint expression. Through this step, we know that the internal activities that may violate the constraint OldTeacher include ModifyProperty(age), ModifyEnd(TeachesIn-Teacher), RemoveLink(TeachesIn), AssignObject(School).

Step 6: Identify potential actions that violate constraints

After inferring the set of PIAs for each constraint according to step 5, it is necessary to convert them into sets of corresponding PEAs and check whether they appear in the operation specification. Taking OldTeacher as an example, ModifyEnd(TeachesIn-Teacher) is directly converted into AddStructuralFeatureAction on the associated end teacher, ModifyProperty(age) is directly converted into AddStructuralFeatureAction on the attribute age, and RemoveLink(TeachesIn) is converted into DestroyLinkAction on the associated TeachesIn. AssighObject(School), since School is neither an associated class nor adjusted by other instances, and AssignObject is not caused by changes at the associated end, it only needs to be converted into CreateObjectAction above School.

So we get the following result:

(1) The set of PIAs for each constraint:

①OldTeacher—ModifyProperty(age), ModifyEnd(TeachesIn-Teacher), RemoveLink(TeachesIn), AssignObject(School);

②NotHeadmasterParttimeteacher—SubReclassify(Parttimeteacher), AssignLink(Manages), ModifyEnd(Manages-Headmaster);

③UniqueName—AssignObject(Teacher), ModifyProperty(Name-Teacher);

④ValidWorkinghours—AssignObject(Parttimeteacher), ModifyProperty(Workinghours);

(2) Converted to MOF standard construction activities, the resulting PEA set:

①OldTeacher—AddStructuralFeatureAction on the attribute age, AddStructuralFeatureAction on the associated teacher, DestroyLinkAction on the associated TeachersIn, and CreateObjectAction on the School;

②NotHeadmasterParttimeteacher—Modify the class element to which the full-time teacher belongs to ReclassifyObjectAction of Parttimeteacher, CreateLinkAction above Manages, and AddStructuralFeatureAction above headmaster of the associated end;

③UniqueName—CreateObjectAction above Teacher, CreateObjectAction above Parttimeteacher, AddStructuralFeatureAction above attribute name;

④ValidWorkinghours—CreateObjectAction above Parttimeteacher, AddStructuralFeatureAction above attribute workinghours;

(3) Constraints that each operation may violate:

①EmployParttimeteacher may violate ValidWorkinghours and UniqueName, but the other two constraints will not be violated;

②DismissTeacher may only violate OldTeacher;

③DeleteAssociation may only violate OldTeacher.

Using the above inferred knowledge, there is no need to detect all 4 constraints after each operation is performed. After executing EmployParttimeteacher, only 2 constraints are required to be detected, and after DismissTeacher and DeleteAssociation are executed, only one constraint is detected. It can be seen that by narrowing the set of constraints to be detected, our method can significantly improve the efficiency of well-formed constraint detection.

In order to evaluate the effectiveness of the present invention, the metadata model processed by the present invention is taken as an example to illustrate, which includes the model structure of the metadata, four OCL good format constraints located at the M1 layer, and three operations to modify the content of the repository system . For brevity, we ignore constraints in other layers. The model structure is shown in Figure 1. The M1 layer metadata, which is an example of the M2 layer metadata, describes the information of schools and teachers. Faculty are divided into full-time faculty and part-time faculty. The four constraints in the M1 layer are shown in Figure 2, which are used to ensure that: each school has at least one teacher over 60 years old (OldTeacher constraint); the principal cannot be a part-time teacher (NotHeadmasterParttimeteacher constraint); Names cannot be the same (UniqueName constraint); part-time teachers must have weekly working hours between 10h and 40h (ValidWorkinghours constraint). The three operations are shown in Figure 3. After each concrete activity we append the equivalent MOF construction activity. Operate the EmployParttimeteacher to hire 1 new part-time teacher for a given school. It creates a new object instance of the classifier Parttimeteacher, initializes it and associates it with the school. Action DismissTeacher dismisses 1 teacher (full-time or part-time) and removes its association with the school. Operation DeleteAssociation deletes an association, and at the same time deletes its association end, the relationship between the association and the association end, and the relationship between the association end and the class. EmployPartimeteacher and DismissTeacher only modify the content in the M0 layer, while DeleteAssociation modifies the content in the M1 layer and propagates the changes to the M0 layer, that is, the content in the M0 layer will also be modified. (Because changes in content at a higher level must be propagated to all levels below it, for example deleting a class must delete all instances of that class in all levels below it.)

By applying this method, we can infer that EmployParttimeteacher can only violate the constraints ValidWorkinghours and UniqueName, while the other two constraints cannot be violated. DismissTeacher and DeleteAssociation can only violate the constraints OldTeacher, and the other three constraints cannot be violated. Therefore, there is no need to detect all 4 constraints after each operation is executed. After executing EmployParttimeteacher, only 2 constraints are required, and after DismissTeacher and DeleteAssociation are executed, only 1 constraint is required. It can be seen that our method can greatly improve the efficiency of well-formed constraint detection.

It should be emphasized that the embodiments described in the present invention are illustrative rather than restrictive, so the present invention includes but is not limited to the embodiments described in the specific implementation manner. Other embodiments derived from the scheme also belong to the protection scope of the present invention.

Claims (6)

1. a discovery method based on the MOF repository conflict operation of constraint deduction, is characterized in that comprising the following steps: Step 1. Define internal activities that affect well-formed constraints and establish their correspondence with MOF construction activities; Step 2: Simplify the well-formed constraints; Step 3: Create a discovery map; Step 4: Mark the discovery map; Step 5: Get the internal activity; Step 6: Identify potential actions that violate constraints; The specific implementation method of step 2 is as follows: first, the equivalent operations defined in the OCL standard library are used to reduce the number of operations appearing in the expression; then the expression is converted into an equivalent conjunctive normal form, and the converted The result is that each constraint is represented as a conjunction of disjunctions; the resulting disjunct literals include forAll iterators, arithmetic comparisons, object/set equivalence comparisons, boolean properties, the not operator, the oclIsTypeOf operator, and oclIsKindOf operator. 2. the discovery method of the MOF repository conflict operation based on constraint derivation according to claim 1, is characterized in that: described internal activity is according to entity type and relation type definition and comprises the eight kinds of internal activities of establishing instance and deleting instance relation. 3. the discovery method of the MOF repository conflict operation based on constraint derivation according to claim 1, it is characterized in that: described step 3 is the discovery that according to the content between good format constraint and OCL metamodel---instance relationship is established picture. 4. the discovery method of the MOF repository conflict operation based on constraint derivation according to claim 1, it is characterized in that: the method that described step 4 marks the discovery graph is: the mark made for each node indicates this node The information that interacts with its successor nodes, including four different types of tag information: "+" indicates that the increase in the value of the expression or the increase in the number of items may lead to a constraint violation; "-" indicates the value of the expression A decrease in the number of items or a decrease in the number of items may lead to a constraint violation; "m" indicates that a change in the value of the expression or a change in the number of items may lead to a constraint violation; "nr" indicates that the node and its successors do not interact with each other. 5. the discovery method of the MOF repository conflict operation based on constraint deduction according to claim 1, it is characterized in that: the concrete method of described step 5 is: by the process of bottom-up inference and summary step by step, obtain, A set of PIAs for each constraint is inferred. 6. the discovery method of the MOF repository conflict operation based on constraint deduction according to claim 1, is characterized in that: the concrete method of described step 6 is: according to the PIA set of each constraint, be converted into the construction activity of MOF standard And get the PEA set, and finally check whether each operation has violated constraints.

Images