A software development intelligent assistance method and system

Abstract

This invention discloses an intelligent auxiliary method and system for software development, relating to the field of software development technology. The method includes the following steps: parsing insurance rule text to obtain a set of insurance rules; constructing business object relationships based on the insurance rule set to obtain a set of business object relationships; performing rule constraint analysis based on the set of business object relationships to obtain a set of rule constraint expressions; generating executable rule descriptions based on the set of rule constraint expressions to obtain a set of rule descriptions; mapping functional implementations based on the set of rule descriptions to obtain a set of implementation logic; and performing traceable consistency verification based on the set of implementation logic to obtain an implementation consistency result. This invention makes the implicit constraints in insurance rules explicit, establishing a clear correspondence between business object relationships and rule constraints, avoiding the problem of rule semantic offset, improving the traceability and consistency verification capability of the rule implementation process, and enhancing the consistency and reliability of rule implementation in insurance software.

Description

Technical Field

[0001] This invention relates to the field of software development technology, specifically to an intelligent auxiliary method and system for software development. Background Technology

[0002] As the digitalization of insurance business continues to increase, insurance software systems are gradually taking on core business functions such as underwriting, claims processing, expense calculation, and liability determination. The functionality of these software systems is highly dependent on the rule system formed by insurance terms, business rules, and regulatory requirements. Insurance rules themselves are typically characterized by complex conditions, high interrelationships between objects, and strict constraints.

[0003] In existing technologies, there are shortcomings in the analysis and expression of rule constraints: existing rule constraint processing usually embeds rule conditions directly into business logic, which is implicitly reflected in the implementation stage. It relies on human experience to avoid rule conflicts during development, or only performs local validation of the conditions of a single rule at the rule configuration layer. It fails to uniformly map and formally describe the constraints imposed on the same business object by rules at the business object relationship level, which affects the consistency and reliability of rule implementation. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides an intelligent auxiliary method and system for software development, thereby resolving the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] In a first aspect, the present invention provides a software development intelligent assistance method and system, comprising the following steps:

[0007] S1. Parse the insurance rule text to obtain a set of insurance rules;

[0008] S2. Construct the business object relationship set based on the insurance rule set;

[0009] S3. Perform rule constraint analysis based on the set of business object relationships to obtain the set of rule constraint expressions;

[0010] S4. Generate executable rule descriptions based on the rule constraint expression set to obtain a rule description set;

[0011] S5. Map the functionality based on the rule description set to obtain the implementation logic set;

[0012] S6. Perform traceable consistency verification based on the implementation logic set to obtain the implementation consistency result.

[0013] To further optimize this technical solution, the insurance rule text parsing in step S1 includes:

[0014] The scope of the insurance rule text is determined, the syntactic structure of each rule statement is analyzed, key entities in the insurance field are identified, the objects involved in the rule are clarified, the triggering conditions and processing behaviors of the rule are extracted, the execution results of the rule are determined, and the insurance rules are obtained, forming a set of insurance rules.

[0015] To further optimize this technical solution, the business object relationship construction in step S2 includes:

[0016] Based on the obtained set of insurance rules, for each insurance rule, identify the types of insurance business objects involved, clarify the functional positioning of the objects in the rules, construct the association relationships between objects in the same rule, and obtain the business object relationship set.

[0017] To further optimize this technical solution, the rule constraint analysis in step S3 includes:

[0018] Based on the obtained set of business object relationships, the constraints in the insurance rules are extracted through rule constraint identification and mapping, and transformed into independent and verifiable rule constraint expressions, resulting in a set of rule constraint expressions.

[0019] To further optimize this technical solution, the rule constraint identification and mapping includes:

[0020] For each business object relationship, determine the source of the rule, identify mandatory constraint characteristics, extract the preconditions for the constraint to be established for the business object relationship identified as a mandatory constraint, and construct the rule constraint expression.

[0021] To further optimize this technical solution, the generation of executable rule descriptions in step S4 includes:

[0022] Based on the obtained set of rule constraint expressions, for each rule constraint expression, the rule constraint expression is transformed into a rule description with a fixed structure, definite semantics, and can be directly mapped to software implementation logic by extracting preconditions, determining mandatory processing behaviors, and limiting unique legal results, thus obtaining a set of rule descriptions.

[0023] To further optimize this technical solution, the functional implementation mapping in step S5 includes:

[0024] Based on the obtained rule description set, domain-specific language parsing technology is used to map the rule description into a structured expression of the implementation logic, and a mapping relationship between the rule description and the implementation logic is constructed to obtain the implementation logic set.

[0025] To further optimize this technical solution, the traceability consistency verification in step S6 includes:

[0026] Based on the obtained implementation logic set, the corresponding rule description and rule constraint expression are traced back for each implementation logic unit. The rule constraint expression is used as the consistency verification benchmark to perform consistency comparison on the corresponding implementation logic unit and obtain the implementation consistency result.

[0027] To further optimize this technical solution, the consistency comparison includes:

[0028]

[0029] in:

[0030] : No. Consistency determination results for each implementation logic unit;

[0031] : No. Each implementation logic unit;

[0032] : No. Rules and constraints;

[0033] Consistency comparison function;

[0034] The consistency determination result is obtained by comparing the implementation logic unit with the corresponding rule constraint expression.

[0035] This technical solution has been further optimized, including the following functional modules:

[0036] The module includes a rule text parsing module, a business object relationship construction module, a rule constraint mapping module, a rule description generation module, an implementation logic mapping module, and a consistency verification module.

[0037] In a second aspect, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, wherein the computer program instructions, when executed by the processor, implement the steps of the software development intelligent assistance method and system as described in the first aspect of the present invention.

[0038] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program instructions are executed by a processor, they implement the steps of the software development intelligent assistance method and system described in the first aspect of the present invention.

[0039] Compared with the prior art, the present invention provides an intelligent auxiliary method and system for software development, which has the following beneficial effects:

[0040] This software development intelligent assistance method and system, through rule constraint identification and mapping, makes the implicit constraints in insurance rules explicit, establishes a clear correspondence between business object relationships and rule constraints, avoids the problem of rule semantic offset, improves the traceability and consistency verification capability of the rule implementation process, and enhances the consistency and reliability of rule implementation in insurance software. Attached Figure Description

[0041] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating an intelligent software development assistance method proposed in this invention.

[0043] Figure 2 This is a schematic diagram of a software development intelligent auxiliary system proposed in this invention. Detailed Implementation

[0044] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0045] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0046] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places throughout this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment selectively excluded from other embodiments.

[0047] Example 1:

[0048] Reference Figure 1 This is the first embodiment of the present invention, which provides a software development intelligent assistance method, including the following steps:

[0049] S1. Parse the insurance rule text to obtain the insurance rule set.

[0050] In this embodiment, the parsing of the insurance rule text includes:

[0051] In the development of insurance software, insurance rules are the fundamental source of constraints on system behavior. However, existing insurance rules are usually in the form of natural language text, such as insurance clauses, product descriptions, and actuarial rule descriptions. The expression of rules relies on natural language and contains a large number of conditional restrictions, exceptions, nested descriptions, and cross-section references, which cannot be directly understood or executed by the software system. Moreover, the way the same rule is expressed is inconsistent between different text sources, which can easily introduce misunderstandings in the subsequent software implementation process. If the rules are directly converted into program logic based on human understanding, it is difficult to maintain a stable and consistent correspondence between the triggering conditions, processing actions, and results of the rules, which can easily lead to implicit deviations in the evolution of the system.

[0052] The scope of insurance rule texts is defined, and syntactic structure analysis is performed on each rule statement to identify key entities in the insurance domain, clarify the objects involved in the rule, extract the rule triggering conditions and processing behaviors, determine the rule execution results, and obtain the insurance rules, forming an insurance rule set. This avoids omissions or ambiguities in conditions, ensures that all subsequent software implementation logic can be traced back to clear insurance rule definitions, eliminates the uncertainty and unverifiability brought about by manual interpretation of rules, and provides a definite source of rules for the construction of subsequent business object relationships.

[0053] The steps for parsing insurance rule texts include:

[0054] Determine the scope of insurance rule text parsing: Clarify the scope of insurance rule text to be parsed, and include all texts that have binding significance on the behavior of insurance software into the parsing object. This text includes, but is not limited to, the main text of insurance terms, liability explanation paragraphs, disclaimer paragraphs, and actuarial rule explanations, thereby ensuring that subsequent parsing only focuses on text content with rule significance, providing a stable and controllable rule text foundation;

[0055] Syntactic structure analysis of rule text: For a given insurance rule text, syntactic structure analysis is performed on each rule statement to identify the main structure and modification relationship in the statement, determine the positional relationship of the parts that indicate condition limitation, the parts that indicate behavior description and the parts that indicate result description in the statement, and divide the rule constituent elements from the grammatical level;

[0056] Identifying key entities in the insurance field: After completing the syntactic structure analysis, key entities in the insurance field appearing in the text are identified, including entities related to insurance liability, entities related to risk factors, entities related to amount, and entities related to time. This maps the abstract or vague textual descriptions in the rules into objects with definite meanings, so that each condition and behavior in the rules clearly points to a specific insurance business object, avoiding the problem of unclear object meanings in subsequent processing.

[0057] Extracting rule triggering conditions: Based on syntactic structure and entity recognition results, the triggering conditions of the rule are extracted from the rule text to fully describe all the limiting factors that must be met for the rule to be valid, including insurance status, risk status, time range and liability prerequisites, etc., to ensure that the condition content is complete, covers all necessary limiting factors, and does not omit any implicit conditions.

[0058] Extracting the corresponding processing behaviors of the rules: After clarifying the triggering conditions, further extract the processing behaviors that need to be executed when the conditions are met from the rule text, and describe the processing actions that should be taken in a deterministic way, such as whether to underwrite, whether to pay, whether to terminate the process, etc., to ensure that each rule corresponds to a unique processing path and avoid multiple optional behaviors or ambiguous instructions.

[0059] Determine the unique result after rule execution: After the processing behavior is extracted, determine the unique result that should be produced after the behavior is executed from the rule text. This is used to describe the state change or output result after the rule is executed, ensuring that the rule has a definite termination state at the execution level and preventing the rule from entering an uncertain state after execution.

[0060] Construct and summarize insurance rules: Combine triggering conditions, processing behaviors, and execution results into an insurance rule, and summarize all insurance rules to form an insurance rule set.

[0061] S2. Construct business object relationships based on the insurance rule set to obtain the business object relationship set.

[0062] In this embodiment, the construction of the business object relationship includes:

[0063] Insurance software does not operate directly around rules, but rather around insurance business objects and their interrelationships, such as policies, insured persons, risk factors, and liability outcomes. Although the rules clarify the rule logic, the object relationships involved in the rules are still implicit in the rule content and have not yet been explicitly expressed in technical form. If the object relationships implicit in the rules are not systematically constructed, the subsequent software implementation will only be able to rely on the developers' subjective understanding of the rules, thus introducing uncertainty again.

[0064] Based on the obtained set of insurance rules, for each insurance rule, the types of insurance business objects involved are identified, the functional positioning of the objects in the rules is clarified, the relationship between objects in the same rule is constructed, and a set of business object relationships is obtained. This achieves the connection between the rules and the software structure, ensures that the software implementation structure is consistent with the objective structure of the insurance business itself, clarifies the roles and functions of different insurance business objects in the rules, avoids overlapping or missing object responsibilities, and provides a unified object foundation for subsequent steps.

[0065] The steps for establishing business object relationships include:

[0066] Read insurance rules: Read the set of insurance rules obtained in step S1 and process each insurance rule separately. By expanding the content of each rule, ensure that each rule exists as an independent analysis unit in the subsequent analysis process and avoid mutual interference between rules.

[0067] Identify the types of insurance business objects: For each insurance rule, analyze its condition and behavior parts to identify the insurance business objects involved. Classify the objects appearing in the rule into different object types according to their business attributes, such as objects used to describe the contract as a whole, objects used to describe the responsible parties, objects used to describe risk factors, and objects used to describe the processing results. Ensure that objects with the same semantics but different expressions in different rules can be uniformly classified.

[0068] Extracting the role and usage of objects in rules: After identifying the types of objects involved in the rules, further analyze the role of each object in the rule. For example, is an object part of the rule triggering condition, an object that acts on the processing behavior, or an object that carries the result description? This clarifies the functional positioning of objects in the rules, provides a reliable basis for constructing the relationship between objects, and avoids misuse or misinterpretation of objects in the subsequent modeling process.

[0069] Building relationships between objects: After clarifying the object types and their roles, by analyzing the way multiple objects appear together in the same rule, as well as the interaction between objects at the condition and behavior levels, we can build relationships between objects, such as constraint relationships, dependency relationships, or causal relationships, so as to ensure that the object relationships are not artificially set, but directly derived from the insurance rules themselves, and truly reflect the logical structure of the insurance business itself.

[0070] Using the Unified Modeling Language to describe objects and their relationships: The class diagram modeling technique in the Unified Modeling Language is adopted. This technique is a mature software engineering modeling technique that can ensure the standardization and consistency of the description of object relationships. By formally describing the attributes and relationships of insurance business objects, the business object relationships can be expressed in a standardized form, which is convenient for subsequent software development tools to understand and use directly.

[0071] Summarize object relationships and form a business object relationship set: Summarize the object relationships extracted and constructed from each insurance rule to form a complete business object relationship set. Each object relationship in the set can be traced back to a specific insurance rule, making the source and meaning of the object relationship clear.

[0072] S3. Perform rule constraint analysis based on the set of business object relationships to obtain the rule constraint expression set.

[0073] In this embodiment, the rule constraint analysis includes:

[0074] Business object relationships describe how objects are associated, but do not specify whether these relationships can be violated at the rule level. In insurance rules, many constraints are not simply object relationships, but rather mandatory, exclusive, or prerequisite rule requirements. If these rule-level constraints are not made explicit, subsequent software implementation may still produce results inconsistent with the insurance rules without breaking the object relationships.

[0075] Based on the obtained set of business object relationships, constraints in insurance rules are extracted through rule constraint identification and mapping, and transformed into independent and verifiable rule constraint expressions, resulting in a set of rule constraint expressions. This makes the implicit constraints in insurance rules explicit, establishes a clear correspondence between business object relationships and rule constraints, effectively avoids the problem of rule semantic deviation caused by different implementation details, provides clear constraint basis for subsequent steps, improves the traceability and consistency verification capability of the rule implementation process, and enhances the consistency and reliability of rule implementation in insurance software.

[0076] Furthermore, the rule constraint identification and mapping includes:

[0077] For each business object relationship, determine the rule source, identify mandatory constraint characteristics, and for business object relationships identified as mandatory constraints, extract the preconditions that the constraints depend on, and construct a rule constraint expression. The specific steps include:

[0078] Read business object relationships: Read the set of business object relationships obtained in step S2, and process each object relationship as an independent analysis unit to ensure that the rule constraints extracted later can be clearly mapped to specific object relationships, avoid unclear source of constraints, and ensure the accuracy and traceability of constraint analysis;

[0079] Tracing the source of insurance rules corresponding to object relationships: For each object relationship, trace back the insurance rules corresponding to it during the construction process to determine under what rule conditions and rule behaviors the object relationship was formed, so as to establish a one-to-one correspondence between the object relationship and the specific insurance rules, and have a clear source of rule semantics;

[0080] Identify mandatory constraint features in object relationships: After clarifying the object relationships and the source of the rules, further analyze the content of the rules to determine whether the object relationship contains constraints that cannot be violated, such as prerequisite relationships between objects, exclusive relationships between object states, and necessary condition relationships for triggering object behavior, thereby distinguishing between general object associations and mandatory constraints at the rule level and avoiding excessive constraints on subsequent software implementation;

[0081] Extracting the preconditions required for the constraint to be valid: For object relationships identified as mandatory constraints, extract the preconditions on which the constraint depends for its validity. The preconditions are derived from the condition part of the original insurance rules and are used to limit the scope of application of the constraint, avoid the constraint being incorrectly generalized, and make the rule constraints constructed subsequently both mandatory and scenario-limited.

[0082] Constructing rule constraint expressions: Combine the object relationships, constraint features, and preconditions involved in the constraints to form a rule constraint expression, so that each rule constraint has a complete structure and definite semantics, and can participate as an independent constraint unit in subsequent rule description generation and consistency verification.

[0083] Forming a set of rule constraint expressions: The rule constraint expressions constructed from different object relationships are summarized to form a set of rule constraint expressions. Each rule constraint in the expression set can be traced back to the specific business object relationship and the original insurance rule, ensuring that the source of the constraint is clear and the meaning is certain, thus improving verifiability and interpretability.

[0084] S4. Generate executable rule descriptions based on the rule constraint expression set to obtain the rule description set.

[0085] In this embodiment, the generation of the executable rule description includes:

[0086] While rule constraints emphasize "relationships that cannot be violated," they don't directly describe how the software should execute when conditions are met. Furthermore, rule constraints lack a structure that directly maps to program logic and require further interpretation before being used by the implementation layer. If directly applied to functional implementation, different implementers might interpret the same rule constraint differently, leading to implementation discrepancies. Therefore, given that the rule constraints are fully defined, it's necessary to unify them into a rule description form that directly guides the implementation layer.

[0087] Based on the obtained set of rule constraint expressions, for each rule constraint expression, by extracting preconditions, determining mandatory processing behaviors, and limiting unique legal results, the rule constraint expression is transformed into a rule description with a fixed structure, defined semantics, and direct mapping to software implementation logic, thus obtaining a set of rule descriptions. This establishes a unified intermediate expression layer between rule constraints and software implementation, eliminating the inconsistency risk caused by differences in interpretation during the implementation stage, ensuring that the same rule has consistent execution semantics in different modules and different implementation stages, providing standardized input for subsequent steps, and guaranteeing the interpretability and verifiability of the insurance software.

[0088] The method steps for generating executable rule descriptions include:

[0089] Rule constraint expression set acquisition and constraint parsing: Read the rule constraint expression set obtained in step S3, and parse each rule constraint expression as an independent processing object to ensure that the subsequently generated rule description corresponds one-to-one with the specific constraint, and avoid multiple constraints being mixed to generate a single rule description, which would lead to semantic ambiguity.

[0090] Precondition extraction: For each rule constraint expression, extract the preconditions used to limit the scope of the constraint's effectiveness. These preconditions clarify the applicable business state, object conditions, and scenario boundaries of the rule, ensuring that the generated rule description does not omit any necessary restrictions during execution.

[0091] Determining mandatory processing behaviors: After clarifying the preconditions, further analyze the mandatory processing behaviors corresponding to the rule constraints. Mandatory processing behaviors describe the actions that must be taken when the preconditions are met. These actions are unique and do not allow for multiple interpretation paths, thus transforming the constraint relationship into a definite behavioral requirement.

[0092] Unique Valid Result Limitation: After determining the processing behavior, further clarify the range of unique valid results allowed after the processing behavior is completed. This result limitation is used to describe the state change or output result after the rule is executed, to prevent the rule from entering an uncertain or intermediate state after execution, and to make the rule description have a complete execution loop.

[0093] Generate rule descriptions: Combine the preconditions, mandatory processing behaviors, and result constraints according to a fixed structure to generate a complete rule description. Each rule description adopts a consistent structural order so that it can be directly understood as an implementation logic specification.

[0094] Forming a rule description set: The rule descriptions generated by different rule constraints are summarized to form a rule description set. Each rule description in this set can be traced back to the specific rule constraint expression and the original insurance rule, ensuring that the source of the rule description is clear and the semantics are certain.

[0095] Furthermore, the extraction of preconditions includes:

[0096]

[0097] in:

[0098] : No. A rule constraint represents a specific rule constraint in the rule constraint expression set. It includes the constraint triggering conditions, the logical relationship between conditions, the restriction requirements on business objects, and the scope of allowed or prohibited results. It is the only source of constraints for subsequent precondition decomposition, processing behavior determination, and result limitation. It is obtained through step S3. Each rule constraint has a unique semantics and can be traced back to a specific clause in the original insurance rule text. There is no duplication or equivalence relationship between different rule constraints.

[0099] : No. The preconditions of a rule constraint represent the set of conditions extracted from the rule constraint expression. They are used to limit the business state, object attribute, or business scenario to which the rule applies. They are the preconditions that must be met for the rule constraint to take effect. The preconditions must completely cover all the triggering conditions of the rule constraint and are not allowed to include conditions that are unrelated to the rule.

[0100] The technical relationship of precondition extraction describes the process of parsing and extracting the preconditions contained in a rule constraint;

[0101] This means extracting the preconditions that make each rule constraint effective from each rule constraint.

[0102] Furthermore, the determination of the mandatory processing behavior includes:

[0103]

[0104] in:

[0105] : No. The mandatory processing behavior when the preconditions of a rule constraint are met represents the irreplaceable processing action determined by the rule constraint. This processing action is used to implement the technical requirements of the rule constraint, including executable processing behaviors in insurance business software such as status change, result determination or process control actions. For the same rule constraint precondition, there is only one corresponding mandatory processing behavior.

[0106] : Technical relationship, indicating that when the condition on the left of the arrow is met, the result on the right will necessarily be obtained. It emphasizes that the result is not optional, there are no multiple branches, and the situation where the result is uncertain after the condition is met is not allowed;

[0107] This means that when the prerequisite conditions of a rule are met, the corresponding processing behavior must be executed.

[0108] Furthermore, the unique legal result is limited to:

[0109]

[0110] in:

[0111] : No. The only valid result after the mandatory processing behavior constrained by a rule is completed. It is a description of the termination state of the rule execution, representing the deterministic impact of the rule after execution. It is used to prevent the rule from entering an ambiguous state after execution. For the same mandatory processing behavior, there is only one corresponding valid result.

[0112] This indicates that once the mandatory processing action is completed, a unique and valid result must be obtained.

[0113] S5. Map the functionality based on the rule description set to obtain the implementation logic set.

[0114] In this embodiment, the function implementation mapping includes:

[0115] The rule description belongs to the rule layer expression. Its content has not been directly transformed into the functional implementation logic in the software. If the developers directly code according to the rule description, it may lead to different developers having different understandings of the behavioral semantics in the rule description. The rule description may be repeatedly implemented or inconsistently implemented in different functional modules. Furthermore, there is a lack of formal mapping relationship between the rules and the implementation, making it difficult to verify consistency.

[0116] Based on the obtained rule description set, domain-specific language parsing technology is used to map the rule description into a structured expression of the implementation logic, and to construct the mapping relationship between the rule description and the implementation logic, thereby obtaining the implementation logic set. This establishes a formal mapping bridge between the rule description and the software function implementation, ensuring that the rule description is not simplified, tampered with, or misunderstood at the implementation level, and ensuring that the implementation logic of the same rule remains consistent in different modules, providing a traceable logical unit for subsequent function combination, testing, and verification.

[0117] Functional implementation mapping methods include:

[0118] Rule description acquisition: Read the rule description set obtained in step S4 and process each rule description as an independent mapping object. By processing each rule description one by one, ensure that each rule description has a unique corresponding implementation logic unit at the implementation logic level, and avoid the confusion of implementation logic semantics caused by the mixed mapping of multiple rules.

[0119] Rule description parsing: For each rule description, according to its fixed structure, the preconditions, processing behavior and result constraints are parsed separately to ensure that the implementation logic accurately inherits every constraint information in the rule description. This avoids focusing only on behavior and ignoring conditions or results during the implementation process. The parsing process strictly follows the structural order of the rule description and does not reorganize or cut the rule content, thereby ensuring the complete inheritance of the rule description.

[0120] Logical structure generation: Domain-specific language (DSL) parsing technology is used to map the parsed conditions, behaviors and results into a structured expression of the implementation logic. The syntax rules of the DSL are fixed and the semantic interpretation is unique. It is used to constrain the organization of the implementation logic, so that the implementation logic does not depend on a specific programming language, and provides a neutral and stable logical intermediate layer for subsequent function implementation.

[0121] Mapping relationship construction: While generating the implementation logic structure, a mapping relationship between rule descriptions and corresponding implementation logic is established. This mapping relationship is used to identify which rule description a certain implementation logic comes from, thereby ensuring the traceability of the implementation logic and supporting rule consistency verification and implementation logic maintenance.

[0122] Forming implementation logic units: If the implementation logic exists in a fragmented structure, it will be difficult to combine, call or reuse, and it will also increase the overall complexity. Therefore, the implementation logic structure generated by the rule description mapping is encapsulated to form implementation logic units. Each implementation logic unit corresponds to a rule description and only contains the logic content required to execute the rule, without introducing other business logic, so that the implementation logic has good composability and reusability.

[0123] Forming an implementation logic set: All implementation logic units are summarized to form an implementation logic set. This implementation logic set serves as the logical foundation for the subsequent construction of software functions. Its content fully covers all rule semantics expressed by the rule description set, providing a unified logical source for subsequent function combination, execution scheduling, or consistency verification.

[0124] S6. Perform traceable consistency verification based on the implementation logic set to obtain the implementation consistency result.

[0125] In this embodiment, the traceability consistency verification includes:

[0126] In insurance software development, simply mapping rules to implementations does not technically guarantee that the implementation logic will always strictly conform to the original insurance rules and their constraints. During the generation or combination of implementation logic, local deviations from rule constraints may occur. When combining implementation logic corresponding to multiple rules, implicit conflicts may be introduced. Traditional verification methods, which rely on test cases or manual review, cannot cover the completeness of the rule space.

[0127] Based on the obtained implementation logic set, the corresponding rule description and rule constraint expression are traced back for each implementation logic unit. The rule constraint expression is used as the consistency verification benchmark to compare the consistency of the corresponding implementation logic unit and obtain the implementation consistency result. Thus, the correctness of the implementation logic is verified from the source of the rule, and the closed-loop verification of the rule-to-implementation link is completed to ensure the authority of the verification benchmark. The inconsistency between the implementation logic and the rule constraints is accurately located, providing interpretable and verifiable implementation consistency conclusions for insurance software and improving the interpretability and maintainability of insurance software.

[0128] The implementation methods for traceable consistency verification include:

[0129] Read the implementation logic set: Read the implementation logic set obtained in step S5 and create an index for each implementation logic unit to identify the unique location of each implementation logic unit, ensuring that the subsequent verification process can accurately locate the specific implementation logic;

[0130] Rule description backtracking: Using the mapping relationship between the rule description and the implementation logic established in step S5, backtrack the corresponding rule description for each implementation logic unit to ensure that the verification does not deviate from the rule semantics and always uses the rule description as the intermediate reference layer.

[0131] Rule constraint expression backtracking: After obtaining the corresponding rule description, continue backtracking to the rule constraint expression formed in step S3. The rule constraint expression serves as the final benchmark for consistency verification and is used to limit the constraint boundaries that the implementation logic must satisfy at the condition, behavior, and result levels. Its constraint effect is higher than that of the rule description.

[0132] Consistency comparison: The structure and execution semantics of the implementation logic are compared item by item with the corresponding rule constraint expression, including whether the implementation logic covers all the preconditions of the rule constraint, whether the processing behavior required by the rule is executed, and whether the result allowed by the rule is produced.

[0133] Generate implementation consistency results: Based on the consistency comparison results, generate a consistency judgment result for each implementation logic unit. When the implementation logic fully meets the corresponding rule constraints, it is judged as consistent. When any constraint is not met, it is judged as a consistency mismatch, and the specific rule constraint position of the mismatch is recorded. The consistency judgment results of each implementation logic unit are summarized to form the implementation consistency result, which is used to judge whether the functional implementation of insurance software fully follows the original insurance rule system, and supports subsequent problem location or version verification.

[0134] Furthermore, the consistency comparison includes:

[0135]

[0136] in:

[0137] : No. The consistency determination result of each implementation logic unit reflects the conformity status between the implementation logic and the rule constraints. When the result is 1, it means that the implementation logic unit is consistent with the corresponding rule constraint expression; when the result is 0, it means that they are inconsistent.

[0138] : No. Each implementation logic unit is used to represent the smallest granularity of functional implementation logic corresponding to a specific insurance rule in insurance software. This includes the structural expression of judgment conditions, the organization of execution branches, the usage relationship of business object attributes, and the output form of the result after the rule is triggered. It is an abstract description of the semantic structure of the implementation logic. Different implementation logic units represent different rule implementation logics.

[0139] : No. A rule constraint represents a specific rule constraint in the rule constraint expression set. It includes the constraint triggering conditions, the logical relationship between conditions, the restriction requirements on business objects, and the scope of allowed or prohibited results. It is the only source of constraints for subsequent precondition decomposition, processing behavior determination, and result limitation. It is obtained through step S3. Each rule constraint has a unique semantics and can be traced back to a specific clause in the original insurance rule text. There is no duplication or equivalence relationship between different rule constraints.

[0140] : Consistency comparison function, used to perform semantic consistency judgment between implementation logic and rule constraints. The judgment logic includes whether the implementation logic fully covers the constraint conditions, whether the implementation logic weakens or omits the constraint restrictions, and whether the implementation logic introduces behaviors not allowed by the rules. It is based on the structural definition of the rule constraint expression, the semantic structure of the implementation logic unit, and the judgment rules for constraint coverage and behavior inclusion relationships.

[0141] The consistency determination result is obtained by comparing the implementation logic unit with the corresponding rule constraint expression.

[0142] Example 2:

[0143] Reference Figure 2 This is the second embodiment of the present invention, which provides a software development intelligent assistance system, including the following functional modules:

[0144] Rule text parsing module: Parses insurance rule texts from regulations, product terms and business specifications, extracts rule names, conditions, behaviors and results to form a set of insurance rules, providing standardized input for subsequent business object mapping;

[0145] Business object relationship construction module: Based on the rule set, analyze the business objects involved and their interrelationships, and generate a business object relationship set to clarify the objects on which the rule execution depends and the interaction relationships between them;

[0146] Rule constraint mapping module: maps business object relationships to rule constraints, generates a unified set of rule constraint expressions, and provides a standard benchmark for subsequent logic generation and consistency verification;

[0147] Rule description generation module: Transforms rule constraint expressions into executable rule descriptions for software, including preconditions, processing behaviors, and result outputs, which are used to directly guide the construction of implementation logic;

[0148] The implementation logic mapping module maps rule descriptions to implementation logic units, encapsulates each logic unit, and forms a composable and reusable set of implementation logic, providing a foundation for the final software function implementation.

[0149] Consistency verification module: Performs a traceable consistency comparison between the implementation logic set and the rule constraint expression, generates implementation consistency results, realizes closed-loop verification from rules to implementation, and ensures that the software implementation conforms to the rule system.

[0150] Example 3:

[0151] In practical applications, this invention can be applied to the intelligent rule implementation of insurance product development and underwriting systems, transforming complex insurance rules from text descriptions into executable implementation logic. The underwriting process of a new type of health insurance product is used as a typical scenario for illustration.

[0152] This application first receives the terms and conditions of health insurance products, regulatory requirements, and internal business specifications. It then performs structured parsing of all relevant rules, extracting the conditions, behaviors, and results of each rule to form a standardized set of rules. These rule sets are subsequently used as the basis for analyzing business objects and their interrelationships, identifying customer information, policy information, risk parameters, and underwriting conditions involved in the underwriting process, and establishing a mapping of relationships between various business objects, thereby clarifying the scope and dependencies of rule execution.

[0153] By mapping business object relationships to the parsed rule conditions, a centralized and traceable set of rule constraint expressions is generated, ensuring that the constraints of each insurance rule have a unified and clear expression form within the system. Using these constraint expressions, executable rule descriptions are further generated, clarifying the condition judgments, behavior executions, and result outputs of each rule at the software execution level. The generated rule descriptions are then mapped to implementation logic units, each corresponding to the functional implementation of one or more rule descriptions, forming a composable and reusable set of implementation logic that provides a concrete execution basis for the business functions of the underwriting software.

[0154] After generating the implementation logic, a traceable consistency check is performed on the logic set and rule constraints to ensure that all implementation logic fully complies with the constraints of the original insurance rules. Any inconsistencies can be precisely located, ultimately resulting in a consistent implementation. In this way, insurance product development teams can directly verify rule coverage and consistency during the software implementation phase, avoiding problems such as missing rule constraints, logical errors, or implementation deviations in traditional methods. This significantly improves the development efficiency and reliability of health insurance underwriting systems, while ensuring that software implementation strictly adheres to regulatory requirements and product terms.

[0155] Example 4:

[0156] This embodiment also provides a computer device applicable to a software development intelligent assistance method and system, including a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the software development intelligent assistance method and system proposed in the above embodiment.

[0157] This embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, it implements a software development intelligent assistance method and system as proposed in the above embodiments.

[0158] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0159] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0160] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0161] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0162] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0163] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A software development intelligent assistance method, characterized in that, Includes the following steps: S1. Parse the insurance rule text to obtain a set of insurance rules; S2. Construct the business object relationship set based on the insurance rule set; S3. Perform rule constraint analysis based on the set of business object relationships to obtain the set of rule constraint expressions; S4. Generate executable rule descriptions based on the rule constraint expression set to obtain a rule description set; S5. Map the functionality based on the rule description set to obtain the implementation logic set; S6. Perform traceable consistency verification based on the implementation logic set to obtain the implementation consistency result.

2. The intelligent auxiliary method for software development according to claim 1, characterized in that, The insurance rule text parsing in step S1 includes: The scope of the insurance rule text is determined, the syntactic structure of each rule statement is analyzed, key entities in the insurance field are identified, the objects involved in the rule are clarified, the triggering conditions and processing behaviors of the rule are extracted, the execution results of the rule are determined, and the insurance rules are obtained, forming a set of insurance rules.

3. The intelligent auxiliary method for software development according to claim 1, characterized in that, The business object relationship construction in step S2 includes: Based on the obtained set of insurance rules, for each insurance rule, identify the types of insurance business objects involved, clarify the functional positioning of the objects in the rules, construct the association relationships between objects in the same rule, and obtain the business object relationship set.

4. The intelligent auxiliary method for software development according to claim 1, characterized in that, The rule constraint analysis in step S3 includes: Based on the obtained set of business object relationships, the constraints in the insurance rules are extracted through rule constraint identification and mapping, and transformed into independent and verifiable rule constraint expressions, resulting in a set of rule constraint expressions.

5. The intelligent auxiliary method for software development according to claim 4, characterized in that, The rule constraint identification and mapping includes: For each business object relationship, determine the source of the rule, identify mandatory constraint characteristics, extract the preconditions for the constraint to be established for the business object relationship identified as a mandatory constraint, and construct the rule constraint expression.

6. The intelligent auxiliary method for software development according to claim 1, characterized in that, The generation of executable rule descriptions in step S4 includes: Based on the obtained set of rule constraint expressions, for each rule constraint expression, the rule constraint expression is transformed into a rule description with a fixed structure, definite semantics, and can be directly mapped to software implementation logic by extracting preconditions, determining mandatory processing behaviors, and limiting unique legal results, thus obtaining a set of rule descriptions.

7. The intelligent auxiliary method for software development according to claim 1, characterized in that, The function implementation mapping in step S5 includes: Based on the obtained rule description set, domain-specific language parsing technology is used to map the rule description into a structured expression of the implementation logic, and a mapping relationship between the rule description and the implementation logic is constructed to obtain the implementation logic set.

8. The intelligent auxiliary method for software development according to claim 1, characterized in that, The traceability consistency verification in step S6 includes: Based on the obtained implementation logic set, the corresponding rule description and rule constraint expression are traced back for each implementation logic unit. The rule constraint expression is used as the consistency verification benchmark to perform consistency comparison on the corresponding implementation logic unit and obtain the implementation consistency result.

9. The intelligent auxiliary method for software development according to claim 8, characterized in that, The consistency comparison includes: in: : No. Consistency determination results for each implementation logic unit; : No. Each implementation logic unit; : No. Rules and constraints; Consistency comparison function; The consistency determination result is obtained by comparing the implementation logic unit with the corresponding rule constraint expression.

10. A software development intelligent assistance system, constructed based on the software development intelligent assistance method according to any one of claims 1-9, characterized in that, Includes the following functional modules: The module includes a rule text parsing module, a business object relationship construction module, a rule constraint mapping module, a rule description generation module, an implementation logic mapping module, and a consistency verification module.

Images