System suitable for field demand modeling

Abstract

The invention relates to a system suitable for field demand modeling, and belongs to the field of software modeling. Comprising a front-end module used for interface display and user interaction; the demand template customization module is used for creating a new demand template, the demand modeling module is used for demand modeling, the checking module is used for checking the correctness of the newly created demand template or model, and the publishing module is used for generating a code of a demand modeling system based on the newly created demand template and automatically deploying the code; the data management module is used for storing the new demand template and data corresponding to the model into a database; and the operation management module is used for configuring the operation environment of the demand modeling system. The system supports a new demand template, the code of the demand modeling system is incrementally generated based on the new demand template through the publishing module, and automatic incremental deployment is carried out, so that the online demand modeling system supports new demand change to realize continuous integration, the iterative development cost brought by the demand change is greatly reduced, and the demand modeling efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of software modeling technology, and in particular to a system suitable for domain requirement modeling. Background Technology

[0002] System developers need to develop systems strictly according to requirements. In order to standardize the description of domain requirements, it is usually necessary to develop corresponding domain requirement modeling tools. Domain system developers use domain requirement modeling tools to model requirements.

[0003] Existing domain requirement modeling generation tools, such as OutSystems, have the following shortcomings in generating domain requirement modeling tools: (1) the process of customizing requirement modeling tools is complex and the development efficiency is low; (2) the generated requirement modeling tools have relatively simple functions and lack support for advanced functions such as multi-person collaborative modeling, model management and reuse; (3) they cannot automatically generate the code for requirement modeling tools or the generated code architecture is too complex; (4) the generated requirement modeling tools do not have the ability to configure requirement templates, making it difficult to cope with requirement changes after the requirement modeling tools are launched. Therefore, providing a requirement modeling system that simplifies requirement template customization and supports requirement template changes, reuse and collaborative modeling, thereby improving the efficiency of requirement modeling, has become an urgent problem to be solved. Summary of the Invention

[0004] Based on the above analysis, the present invention aims to provide a system suitable for domain requirement modeling, in order to solve the problems of the complexity of customizing existing requirement templates and the lack of support for requirement template changes after the requirement modeling tools are launched, resulting in low efficiency of requirement modeling.

[0005] This invention provides a system suitable for domain requirement modeling, the system comprising the following modules:

[0006] The front-end module is used for UI display and user interaction, and transmits user input data to the business system module;

[0007] The business system module includes a requirement template customization module, a requirement modeling module, an inspection module, and a deployment module. The requirement template customization module receives user input data and creates new requirement templates. The requirement modeling module receives user input data and performs requirement modeling based on the newly created and existing requirement templates. The inspection module checks the correctness of the newly created requirement templates or models. The deployment module generates the code for the requirement modeling system based on the newly created requirement templates and automatically deploys it.

[0008] The data management module is used for data caching and storing the forms corresponding to newly created requirement templates, the relationships between forms, and the form data values ​​corresponding to requirement modeling into the database;

[0009] The operation management module is used to configure the operating environment of the requirement modeling system to support its normal operation.

[0010] Furthermore, the requirement template customization module includes an ontology model construction module, an expression pattern construction module, a requirement template definition module, and a requirement template reuse module. The ontology model construction module is used to extract four-level entities and attributes with hierarchical dependencies based on domain semantic analysis to construct a requirement template ontology model. The expression pattern construction module is used to obtain the requirement template syntax and semantic constraints based on the four-level entities and attributes with hierarchical dependencies, and to construct a requirement template expression pattern based on the requirement template syntax and semantic constraints. The requirement template definition module is used to construct a requirement template based on the requirement template ontology model and the requirement template expression pattern. The requirement template reuse module is used to realize the reuse of requirement templates.

[0011] Furthermore, the requirement modeling module includes a model building module and a collaborative modeling module; the model building module is used to perform requirement modeling based on requirement templates; the collaborative modeling module is used to enable multi-user collaborative requirement modeling.

[0012] Furthermore, the publishing module includes a code generation module and a deployment module; the code generation module includes a database script module, a backend code module, and a frontend code module; the database script module is used to generate database scripts for the requirement modeling system based on newly created requirement templates; the backend code module is used to construct CRUD business logic templates and collaboration logic templates, and generate backend code for the requirement modeling system based on the database scripts, CRUD business logic templates, and collaboration logic templates; the frontend code module is used to construct atomic component templates, and generate frontend code for the requirement modeling system based on newly created requirement templates and atomic component templates; the deployment module is used to connect to the server and automatically deploy the code generated by the code generation module.

[0013] Furthermore, the requirement modeling system also includes a service governance module and a permission management module; the service governance module is used to manage the microservices generated by the requirement template customization module, requirement modeling module, inspection module, and release module.

[0014] The permission management module is used to manage user permissions; the users include teams and team members.

[0015] Furthermore, the permission management module includes a team management module and a team member management module; the team management module is used to set the basic information of different teams and the corresponding requirement modeling projects of the teams; the team member management module is used to set the basic information and permission levels of different members.

[0016] Furthermore, the requirement template reuse module achieves requirement template reuse through the following method:

[0017] Keyword vectors are extracted from the names of existing requirement templates and stored in the database; keyword vectors are extracted from the names of requirement templates to be created; the similarity between the keyword vectors of the requirement templates to be created and those of existing requirement templates is calculated; a list of existing requirement templates corresponding to similarity values ​​greater than a threshold is displayed; existing requirement templates are selected from the list to construct the requirement template to be created, thus achieving requirement template reuse.

[0018] Furthermore, the inspection module generates front-end and back-end code related to the requirement template inspection logic based on the requirement template syntax and semantic constraints, which is used to check the correctness of newly created requirement templates or models when constructing requirement templates or performing requirement modeling.

[0019] Furthermore, the construction of the requirement template ontology model based on the extraction of four-level entities and attributes of hierarchical dependencies through domain semantic analysis includes:

[0020] Based on the analysis of the semantics of all requirements from different domains, a four-level entity and attribute with hierarchical dependency relationship are extracted to construct a requirement template ontology model; the four-level entities include Template, Group, Entry, and EntryAttribute, and each entity has its own attributes;

[0021] The Template represents a domain requirement template, under which there are Groups describing all its requirements;

[0022] The Group organizes all requirements into a requirement tree through aggregation relationships, and each requirement has an Entry describing its data entity format.

[0023] The Entry class contains EntryAttributes, which describe the data type of the attributes in the data entity format.

[0024] Furthermore, the requirement template syntax constraints include:

[0025] For a Template, its children can have one or more Groups;

[0026] For a Group, its children can have one or more CompositeGroups or AtomicGroups; for a CompositeGroup, it is composed of AtomicGroups or aggregates of AtomicGroups and CompositeGroups, and its children can have at least one AtomicGroup; for an AtomicGroup, its children have one Entry and have an instantiable number constraint.

[0027] For an Entry, its children can have one or more EntryAttributes;

[0028] For EntryAttribute, the data type needs to be specified, and different EntryAttributes can have association relationships;

[0029] Template, CompositeGroup, AtomicGroup, and EntryAttribute all need to have both Chinese and English names defined;

[0030] The semantic constraints of the requirement template include:

[0031] The Template should include at least one non-empty child AtomicGroup;

[0032] An AtomicGroup must have a unique parent CompositeGroup;

[0033] The Chinese and English names of AtomicGroup and AtomicGroup, AtomicGroup and CompositeGroup, and CompositeGroup and CompositeGroup at the same CompositeGroup level cannot be the same.

[0034] The Chinese and English names of EntryAttributes at the same Entry level cannot be the same.

[0035] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0036] 1. This invention supports the creation of new requirement templates through a requirement template customization module. The release module incrementally generates the code of the requirement modeling system based on the newly created requirement templates and automatically deploys it incrementally. This enables the online requirement modeling system to support new requirement changes and achieve continuous integration. There is no need to customize new requirement templates and generate new requirement modeling systems through another requirement template customization tool and then deploy them. This greatly reduces the iterative development costs caused by requirement changes and improves the efficiency of requirement modeling.

[0037] 2. This invention constructs CRUD business logic templates and collaboration logic templates, and then automatically generates CRUD logic code and collaboration logic code corresponding to the requirement templates. By constructing atomic component templates, the corresponding collaborative modeling data display logic and UI interface style are encapsulated, and the front-end code corresponding to the requirement templates is automatically generated. This not only simplifies the front-end and back-end code architecture, but also supports multi-user collaborative requirement modeling. It is suitable for domain requirement modeling with large scale and complex modeling tasks, and improves the efficiency of requirement modeling.

[0038] 3. This invention simplifies the customization of requirement templates by extracting four-level entities and attributes that are dependent on each other, thereby improving the efficiency of requirement template customization and requirement modeling. Furthermore, this invention improves the versatility of the requirement template ontology model by designing it to cover all requirement semantics in different domains.

[0039] 4. Based on the syntax and semantic constraints of the requirement template, this invention constructs a simple and easy-to-use requirement template expression mode for the requirement template ontology model, thereby improving the efficiency of requirement template customization and requirement modeling.

[0040] 5. This invention obtains related existing requirement templates by analyzing the names of the requirement templates to be built, supports the reuse of requirement templates, and thus improves the efficiency of custom requirement templates.

[0041] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0042] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0043] Figure 1 This is a block diagram of a system applicable to domain requirement modeling according to an embodiment of the present invention;

[0044] Figure 2 This is a schematic diagram of the user access interface during collaborative requirement modeling in an embodiment of the present invention;

[0045] Figure 3 This is a schematic diagram of a CRUD business logic template according to an embodiment of the present invention;

[0046] Figure 4 This is a schematic diagram of the collaborative logic template in an embodiment of the present invention;

[0047] Figure 5 This is a code diagram of the Text component template in an embodiment of the present invention. Detailed Implementation

[0048] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0049] One specific embodiment of the present invention discloses a system suitable for domain requirement modeling. For example... Figure 1 As shown, the system includes the following modules:

[0050] The front-end module is used for UI display and user interaction, and transmits user input data to the business system module;

[0051] The business system module includes a requirement template customization module, a requirement modeling module, an inspection module, and a deployment module. The requirement template customization module receives user input data and creates new requirement templates. The requirement modeling module receives user input data and performs requirement modeling based on the newly created and existing requirement templates. The inspection module checks the correctness of the newly created requirement templates or models. The deployment module generates the code for the requirement modeling system based on the newly created requirement templates and automatically deploys it.

[0052] The data management module is used for data caching and storing the forms corresponding to newly created requirement templates, the relationships between forms, and the form data values ​​corresponding to requirement modeling into the database;

[0053] The operation management module is used to configure the operating environment of the requirement modeling system to support its normal operation.

[0054] Furthermore, the requirement template customization module includes an ontology model construction module, an expression pattern construction module, a requirement template definition module, and a requirement template reuse module. The ontology model construction module is used to extract four-level entities and attributes of hierarchical dependencies based on domain semantic analysis to construct a requirement template ontology model. The expression pattern construction module is used to obtain the requirement template syntax and semantic constraints based on the four-level entities and attributes of hierarchical dependencies, and to construct a requirement template expression pattern based on the requirement template syntax and semantic constraints. The requirement template definition module is used to receive user input data and construct a requirement template based on the requirement template ontology model and the requirement template expression pattern. The requirement template reuse module is used to realize the reuse of requirement templates.

[0055] Specifically, the construction of the requirement template ontology model based on the extraction of four-level entities and attributes of hierarchical dependencies through domain semantic analysis includes:

[0056] Based on the analysis of the semantics of all requirements from different domains, a four-level entity and attribute with hierarchical dependency relationship are extracted to construct a requirement template ontology model; the four-level entity includes Template, Group, Entry, and EntryAttribute, and each entity has its own attribute;

[0057] The Template represents a domain requirement template, under which there are Groups describing all its requirements;

[0058] The Group organizes all requirements into a requirement tree through aggregation relationships, and each requirement has an Entry describing its data entity format.

[0059] The Entry class contains EntryAttributes, which describe the data type of the attributes in the data entity format.

[0060] Furthermore, the requirement tree consists of CompositeGroup and AtomicGroup. CompositeGroup is a branch node of the requirement tree, and AtomicGroup is a leaf node of the requirement tree. An AtomicGroup represents a specific requirement, and an AtomicGroup can be a subordinate of CompositeGroup.

[0061] Specifically, the requirement template ontology model is represented by the ModelStructure class, which has four subclasses: Template, Group, Entry, and EntryAttribute. Each class / subclass has its own attribute. The Group subclass has two subclasses: CompositeGroup and AtomicGroup, where AtomicGroup can be a subclass of CompositeGroup. The Entry subclass has two subclasses: RequirementsItem and PredefinedItem. RequirementsItem describes the format of the requirement table, and PredefinedItem describes the format of the definition item table. EntryAttribute describes the data type of each attribute in the data entity format (i.e., the requirement table format or the definition item table format).

[0062] For example, a certain requirement template (a Template) has a "Predefined Items" CompositeGroup; the "Predefined Items" includes four AtomicGroups: "Terminology Definition Table", "Module Definition Table", "Interface Definition Table", and "Data Definition Table"; each AtomicGroup has an Entry describing its data entity format. For example, the "Terminology Definition Table" is described by PredefinedItem, which describes the format of the definition table, i.e., the attributes of the "Terminology Definition Table": "Abbreviation", "Full English Name", and "Full Chinese Name"; under PredefinedItem, there is an EntryAttribute describing the data type of each attribute in the "Terminology Definition Table". For example, the data type of "Abbreviation", "Full English Name", and "Full Chinese Name" are all String.

[0063] It should be noted that a parent requirement can consist of multiple child requirements, with the child requirements collectively fulfilling the parent requirement's requirements. Therefore, this application uses CompositeGroup and AtomicGroup to describe the parent-child hierarchical relationship between domain requirements, ensuring the completeness and consistency of the requirement description. When designing the requirement template ontology model, this application focuses on how to abstractly cover all the requirement semantics and requirement description patterns of currently known domain requirement models. Furthermore, it expands the domain semantic expressive power of the requirement template ontology model, enabling it to be used to describe requirement templates for software in different domains. Therefore, the requirement template ontology model provided by this application can cover all requirement semantics in different domains, and the standardized requirement description ensures the correctness of the requirement templates constructed by developers.

[0064] Understandably, this invention simplifies the customization of requirement templates by extracting four-level entities and attributes that are dependent on each other, thereby improving the efficiency of requirement template customization and requirement modeling. Furthermore, this invention improves the versatility of the requirement template ontology model by designing it to cover all requirement semantics in different domains.

[0065] Specifically, the requirement template syntax constraints include:

[0066] For a Template, its children can have one or more Groups;

[0067] For a Group, its children can have one or more CompositeGroups or AtomicGroups; for a CompositeGroup, it is composed of AtomicGroups or aggregates of AtomicGroups and CompositeGroups, and its children can have at least one AtomicGroup; for an AtomicGroup, its children have one Entry and have an instantiable number constraint.

[0068] For an Entry, its children can have one or more EntryAttributes;

[0069] For EntryAttribute, the data type needs to be specified, and different EntryAttributes can have association relationships;

[0070] Template, CompositeGroup, AtomicGroup, and EntryAttribute all need to have both Chinese and English names defined.

[0071] Specifically, the number of instantiable AtomicGroups is constrained by the number of project work segments.

[0072] For example, a spacecraft project has three work segments: A, B, and C. Each work segment needs to have an input / output table (AtomicGroup). Therefore, during requirements modeling, it is necessary to create an input / output table for each of the three work segments (i.e., instantiate the input / output table) to describe the software requirements for the input and output of the control software of each work segment. Thus, the constraint on the number of input / output tables that can be instantiated is 3.

[0073] Specifically, different EntryAttributes within the same Entry or different Entryes can have a relationship.

[0074] For example, a Template may contain two CompositeGroups: "Software Environment Requirements" and "Security Analysis". "Software Environment Requirements" includes an AtomicGroup called "HLR Table", and "Security Analysis" includes an AtomicGroup called "CFC Table". The "HLR Table" has an attribute called "CFC Trace", and the "CFC Table" has an attribute called "Content". Therefore, the data type of "CFC Trace" in the "HLR Table" is a reference to the data in the "Content" of the "CFC Table".

[0075] Furthermore, the semantic constraints of the requirement template include:

[0076] The Template should include at least one non-empty child AtomicGroup;

[0077] An AtomicGroup must have a unique parent CompositeGroup;

[0078] The Chinese and English names of AtomicGroup and AtomicGroup, AtomicGroup and CompositeGroup, and CompositeGroup and CompositeGroup at the same CompositeGroup level cannot be the same.

[0079] The Chinese and English names of EntryAttributes at the same Entry level cannot be the same.

[0080] Furthermore, each entity has its own expression mode, which is constrained by the syntax and semantics of the requirement template; the expression mode of Group is a requirement directory that displays the aggregation relationship of the requirement tree, the expression mode of CompositeGroup is a subdirectory of the requirement directory, and the expression mode of AtomicGroup is a directory item of the requirement directory; the expression mode of Entry is in tabular form, which is determined by the format of the requirement table or definition item table; the expression mode of EntryAttribute is an editor component, which is related to the data type corresponding to EntryAttribute.

[0081] Specifically, the expression pattern of each entity is represented by its own ModelPattern class, which is instantiated and expressed in the requirements modeling tool. EntryAttribute expression patterns are divided into Text, TextArea, Select, and Radio. Text represents a short text input box, TextArea represents a long text input box, Select represents a multi-option list, and Radio represents a single option. Each expression pattern of EntryAttribute corresponds to a specific editor component for editing during requirements modeling. Each data type described by EntryAttribute has one or more specific EntryAttribute expression patterns.

[0082] For example, the attributes of the "HLR table" include "requirement number" and "requirement name". The data type of "requirement number" and "requirement name" is string. String has two expression modes: Text and TextArea. Therefore, depending on the actual situation, the expression mode of "requirement number" is set to Text and the expression mode of "requirement name" is set to TextArea.

[0083] Understandably, this invention constructs a simple and easy-to-use requirement template expression mode for the requirement template ontology model based on requirement template syntax and semantic constraints, thereby improving the efficiency of requirement template customization and requirement modeling.

[0084] Specifically, the system receives user-input data, and based on the hierarchical relationship of entities in the requirement template ontology model, defines the entity according to the user-input data in order from upper to lower level, using the requirement template expression mode corresponding to the entity to construct the requirement template. When defining the data entity format corresponding to a certain AtomicGroup, it provides prompts based on the attributes already defined in the data entity format corresponding to that AtomicGroup and other defined AtomicGroups. When defining EntryAttribute, data type constraints and prompt information can be set.

[0085] Specifically, when defining the data entity format corresponding to a certain AtomicGroup, based on the defined attributes in the data entity format of that AtomicGroup, all other defined AtomicGroups containing the defined attributes are found. The most recently defined AtomicGroup is selected, and suggestions are provided for any undefined attributes within it based on the data entity format of that most recently defined AtomicGroup. When defining an EntryAttribute, the format constraints and suggestion information for the data type corresponding to that EntryAttribute can be set according to actual needs, and displayed through the editor component corresponding to that EntryAttribute.

[0086] For example, suppose that when constructing a certain requirement template, three AtomicGroups, namely "Running Scenario Table," "CFC Table," and "HLR Table," have been defined based on user input data. Among them, the "Running Scenario Table" was defined most recently, and the "CFC Table" was defined earliest. The data entity format corresponding to the "CFC Table" includes the following attributes: Requirement Number, Content, and Traceability. The data entity format corresponding to the "HLR Table" includes the following attributes: Requirement Number, Requirement Name, Requirement Description, Reason, and CFC Traceability. The data entity format corresponding to the "Running Scenario Table" includes the following attributes: Requirement Number and Content. Next, the "SRATS Table" needs to be defined. When defining the "SRATS Table," the attribute "Requirement Number" is defined first based on user input. Based on the "Requirement Number," the "Running Scenario Table," "CFC Table," and "HLR Table" are found, and the "Running Scenario Table" is selected, prompting the "Content" attribute. Secondly, the attribute "Requirement Name" is defined based on user input. Based on the "Requirement Number" and "Requirement Name," the "HLR Table" is found, prompting the "Requirement Description," "Reason," and "CFC Traceability" attributes.

[0087] Furthermore, the requirement template reuse module achieves requirement template reuse through the following method:

[0088] Keyword vectors are extracted from the names of existing requirement templates and stored in the database; keyword vectors are extracted from the names of requirement templates to be created; the similarity between the keyword vectors of the requirement templates to be created and those of existing requirement templates is calculated; a list of existing requirement templates corresponding to similarity values ​​greater than a threshold is displayed; existing requirement templates are selected from the list to construct the requirement template to be created, thus achieving requirement template reuse.

[0089] Specifically, the Template attributes include a Chinese name. The Chinese name of the existing requirement template is segmented and word-removed to obtain keywords. Word removal includes removing adverbs, auxiliary words, and prepositions. Keyword vectors are obtained using the word2vec model and stored in the database. Similarly, keyword vectors for the name of the requirement template to be created can be obtained. The cosine similarity between the keyword vectors of the requirement template to be created and those of existing requirement templates is calculated, and all existing requirement templates with a cosine similarity greater than a threshold are displayed in a list. An existing requirement template is selected from this list, and its data is copied to the requirement template to be created, thus achieving requirement template reuse.

[0090] It should be noted that the requirement modeling system provided by this invention is generated and deployed by a separate requirement template customization tool. Therefore, the requirement modeling system contains pre-built requirement templates for users to perform requirement modeling. However, requirements often change, causing the pre-built requirement templates to become unsuitable for new requirement changes. In this case, users can customize new requirement templates using the requirement template customization module of the requirement modeling system, thereby enabling the requirement modeling system to support new requirement changes without needing to customize new requirement templates and generate a new requirement modeling system through the requirement template customization tool.

[0091] Understandably, this invention obtains related existing requirement templates by analyzing the names of the requirement templates to be built, supporting the reuse of requirement templates and thus improving the efficiency of customizing requirement templates. This invention supports the creation of new requirement templates through a requirement template customization module to address new requirement changes after the requirement modeling system goes live, eliminating the need for additional requirement template customization tools to create new requirement templates and generate a new requirement modeling system, significantly reducing the iterative development costs caused by requirement changes.

[0092] Furthermore, the requirement modeling module includes a model building module and a collaborative modeling module; the model building module is used to receive user input data and perform requirement modeling based on newly created and existing requirement templates; the collaborative modeling module is used to enable multi-user collaborative requirement modeling.

[0093] Furthermore, the model building module performs requirement modeling using the following method:

[0094] The system receives user input data, obtains all AtomicGroups based on the requirement template, and retrieves the corresponding data based on the user input using the editor component corresponding to each AtomicGroup, according to the format constraints and prompts of the data type displayed by the editor component, thereby realizing requirement modeling.

[0095] Specifically, an AtomicGroup instantiates a requirement table or definition item table based on the data entity format described by the corresponding Entry. The attributes in the data entity format are instantiated as fields in the requirement table or definition item table. Each EntryAttribute corresponding to an AtomicGroup corresponds to an editor component. Each editor component displays the format constraints and prompts for the data type corresponding to the EntryAttribute set when building the requirement template. Users can use the editor component to standardize the data values ​​of the fields according to the format constraints and prompts of the data type, obtain the input data, and realize requirement modeling.

[0096] For example, if the data type of a certain EntryAttribute has a format constraint of reference and the prompt message is "Reference data from the CFC table", the editor component corresponding to this EntryAttribute is Select. This Select will display a selection box containing data from the CFC table and the above prompt message. The user selects data based on the selection box containing data from the CFC table and the above prompt message.

[0097] Furthermore, the collaborative modeling module implements multi-user collaborative requirement modeling through the following method:

[0098] When multiple users are collaboratively modeling requirements, for fields in the requirement table or definition table instantiated from the attributes in the data entity format described by the Entry, when a user changes the data value of a field, the field is locked and the user's username is displayed; when the user has finished changing the data value of the field, the change is synchronized to all other users and the field is unlocked.

[0099] Preferably, a requirement modeling tool is generated based on the constructed requirement template, and the requirement modeling tool is deployed to a server; multiple users collaboratively modeling the same requirement simultaneously connect to the same WebSocket terminal on the server, such as... Figure 2As shown, when a user changes the data value of a field, the user sends the field name and the user's username to the server via the WebSocket terminal. The server then broadcasts the received field name and username to other users. On the other users' access interfaces, the field becomes uneditable, and the user's username is displayed next to the field. When the user finishes changing the data value of the field, the user sends the change to the server via the WebSocket terminal. The server then broadcasts the received change to other users. On the other users' access interfaces, the change is displayed, the field is unlocked, and the user's username is no longer displayed.

[0100] Specifically, users obtain requirement templates by accessing the requirement modeling tool on the server and then perform modeling based on these templates. Modifying field data values ​​includes adding, deleting, and updating field data values. Since multiple users collaboratively modeling the same requirement are simultaneously connected to the same WebSocket terminal on the server, the server can broadcast the received data to other users on the same WebSocket terminal. Other users can then extract the corresponding data based on the broadcast message and synchronize it to their own access interface.

[0101] For example, users A, B, and C perform collaborative modeling. User A adds data to field E in table D. At this time, they send the name of field E in table D and user A's username to the server via a WebSocket terminal. The server broadcasts the received name of field E in table D and user A's username to users B and C. On users B and C's access interfaces, the editor for field E in table D is grayed out (editing is disabled), and user A's username is displayed next to the field. When user A finishes adding data to field E in table D, they send a CREATE message containing the added data to the server via a WebSocket terminal. The server broadcasts the received CREATE message to users B and C. Users B and C extract the added data based on the CREATE message. On users B and C's access interfaces, the added data is displayed in field E of table D, the field is unlocked, and user A's username is no longer displayed.

[0102] Understandably, this invention, by supporting multi-user collaborative requirement modeling, is applicable to domain requirement modeling with large scale and complex modeling tasks, thus improving the efficiency of requirement modeling.

[0103] Furthermore, the inspection module generates front-end and back-end code related to the requirement template inspection logic based on the requirement template syntax and semantic constraints, which is used to check the correctness of newly created requirement templates or models when constructing requirement templates or performing requirement modeling.

[0104] Specifically, the requirement template checking logic includes four-level entity name checking, model tree structure checking, EntryAttribute reference relationship checking, and EntryAttribute corresponding data type and value range checking. Based on the requirement template syntax and semantic constraints, the front-end code related to the above requirement template checking logic is generated to display the user interface and check results, while the back-end code is used to encapsulate the specific checking logic.

[0105] Furthermore, the publishing module includes a code generation module and a deployment module; the code generation module includes a database script module, a backend code module, and a frontend code module; the database script module is used to generate database scripts for the requirement modeling system based on newly created requirement templates; the backend code module is used to construct CRUD business logic templates and collaboration logic templates, and generate backend code for the requirement modeling system based on the database scripts, CRUD business logic templates, and collaboration logic templates; the frontend code module is used to construct atomic component templates, and generate frontend code for the requirement modeling system based on newly created requirement templates and atomic component templates; the deployment module is used to connect to the server and automatically deploy the code generated by the code generation module.

[0106] Specifically, the database script is used to create forms corresponding to newly created requirement templates and the relationships between these forms. Each form consists of a column structure; the attributes in the data entity format corresponding to an Entry correspond to the column names in the column structure, and the data types of the attributes in the data entity format corresponding to an EntryAttribute correspond to the data types of the column structure. The relationships between forms refer to the associations between different forms, such as establishing a reference relationship between two forms through foreign keys. The database script can create forms corresponding to newly created requirement templates and the relationships between these forms on the server. One AtomicGroup corresponds to one database form, thus formatting the data entity formats corresponding to its Entry and the data entity formats corresponding to its EntryAttribute into the database form.

[0107] Furthermore, the backend code module obtains the form corresponding to the newly created requirement template through the database script, passes the form data to the CRUD business logic template to generate CRUD logic code, and passes the form data to the collaboration logic template to generate collaboration logic code. The backend code of the requirement modeling system includes CRUD logic code and collaboration logic code.

[0108] Specifically, such as Figure 3As shown, a CRUD business logic template is constructed. This template includes a form CRUD interface Controller template, a form data entity template, a form Mybatis Mapper template, a form CRUD service interface class template, and a form CRUD service implementation class template. The form CRUD interface Controller template receives client requests, calls corresponding business operations for processing, and returns the processing results to the client. The form data entity template receives data from the form and its column structure. The form Mybatis Mapper template interacts with the database via SQL statements. The form CRUD service interface class template encapsulates the business operation interface. The form CRUD service implementation class template implements specific business operations, such as CRUD operations on the form and processing business rules. The database script obtains the form and its column structure corresponding to each AtomicGroup in the newly created requirement template. For each form in each AtomicGroup, the parameters of the form and its column structure are passed to the CRUD business logic template to generate the corresponding code for each of the above templates, forming the CRUD logic code.

[0109] Specifically, such as Figure 4 As shown, a collaborative logic template is constructed, which includes a collaborative service terminal template, a collaborative data entity template, a collaborative WebSocket configuration template, and a collaborative utility class template. The collaborative service terminal template is used for WebSocket connection event management, such as establishing a connection and sending / receiving messages. The collaborative data entity template is used to receive data from a form column structure and create messages, including messages corresponding to adding, deleting, and updating data. The collaborative WebSocket configuration template is used to configure the WebSocket service. The collaborative utility class template is used to encapsulate message processing logic interfaces to enable message synchronization between users. For the column structure of the form corresponding to each AtomicGroup: the parameters of the column structure are passed to the collaborative logic template to generate the code corresponding to each of the above templates, forming the collaborative logic code.

[0110] Understandably, this invention, by constructing CRUD business logic templates and collaboration logic templates, and then automatically generating CRUD logic code and collaboration logic code corresponding to the requirement templates, not only simplifies the backend code architecture but also supports multi-user collaborative requirement modeling. It is suitable for domain requirement modeling with large scale and complex modeling tasks, and improves the efficiency of requirement modeling.

[0111] Furthermore, the front-end code module obtains the corresponding form based on the newly created requirement template, and passes the form data into the atomic component template to generate the front-end code of the requirement modeling system.

[0112] Specifically, atomic component templates are constructed, including a requirements tree component template, a form information component template, a collaborative modeling user tag component template, a Text component template, a TextArea component template, a Select component template, and a Radio component template. The requirements tree component template displays the requirements tree; the form information component template displays the form column structure; the collaborative modeling user tag component template displays the username; the Text component template displays the Text editor and encapsulates the corresponding collaborative modeling data display logic; the TextArea component template displays the TextArea editor and encapsulates the corresponding collaborative modeling data display logic; the Select component template displays the Select editor and encapsulates the corresponding collaborative modeling data display logic; and the Radio component template displays the Radio editor and encapsulates the corresponding collaborative modeling data display logic. For each form corresponding to an AtomicGroup: the form parameters are passed to the atomic component templates to generate the code corresponding to each of the above templates, forming the front-end code.

[0113] For example, such as Figure 5 As shown, the Text component template inherits from the Input component. In the Input component, the specific display logic of collaborative modeling of its Focus, Blur, and data change events is encapsulated, and the display is performed in real time in the Input component, and its UI style is also encapsulated.

[0114] Understandably, this invention encapsulates the corresponding collaborative modeling data display logic and UI style by constructing atomic component templates, thereby automatically generating the front-end code corresponding to the requirement template. This not only simplifies the front-end code architecture but also supports multi-user collaborative requirement modeling, making it suitable for large-scale domain requirement modeling with complex modeling tasks and improving the efficiency of requirement modeling.

[0115] It should be noted that the code generation module generates incremental code based on the user's newly created requirement template. Compared with the first time the requirement modeling system was launched, it is no longer necessary to initialize the database, set up the runtime environment of the requirement modeling system, and generate the code for the permission management module and the runtime management module. Only the form corresponding to the newly created requirement template and its front-end and back-end code need to be added.

[0116] Specifically, the deployment module connects to the target server specified when the requirements modeling system is first launched, where the front-end and back-end code will run. The front-end and back-end code can run on different servers. The deployment module packages the code generated by the code generation module and automatically deploys it to the target server via a Docker container to update the requirements modeling system; the Docker container is built by running Dockerfile and Docker-compose files on the target server.

[0117] Understandably, this invention uses a release module to incrementally generate code for a requirements modeling system based on newly created requirements templates and automatically deploys it incrementally. This enables the already deployed requirements modeling system to support continuous integration with new requirements changes, eliminating the need for additional requirements template customization tools to create new requirements templates, generate new requirements modeling systems, and then deploy them. This significantly reduces the iterative development costs associated with requirements changes.

[0118] Furthermore, the requirement modeling system also includes a service governance module and a permission management module; the service governance module is used to manage the microservices generated by the requirement template customization module, requirement modeling module, inspection module, and release module.

[0119] The permission management module is used to manage user permissions; the users include teams and team members.

[0120] It should be noted that, to ensure the robustness of the requirements modeling system, the entire business system is divided into four independent functional modules: a requirements template customization module, a requirements modeling module, an inspection module, and a release module. Each functional module has its own independent operating environment and provides corresponding service functions to users, i.e., microservices. To organize these independently running microservices into a cohesive whole to provide services to users, the service governance module is needed to manage the microservices of the entire business system, thereby organizing them together.

[0121] Specifically, the service governance module includes a registration and discovery module, a distributed transaction module, a service monitoring module, and a service configuration module. The registration and discovery module is used for registering and monitoring the status of microservice instances, and provides an interface for discovering and invoking available microservice instances. The distributed transaction module is used to control microservices in the distributed system to ensure that microservice data meets the principles of atomicity, consistency, isolation, and durability (ACID). The service monitoring module is used to monitor the status of microservices. The service configuration module is used to dynamically update the configuration of microservices; the configuration updates take effect without restarting the microservices. Preferably, the open-source Nacos service governance solution can be used to manage the microservices of the entire business system.

[0122] Furthermore, the permission management module includes a team management module and a team member management module; the team management module is used to set the basic information of different teams and the corresponding requirement modeling projects of the teams; the team member management module is used to set the basic information and permission levels of different members.

[0123] Specifically, the team members' permission levels, from highest to lowest, are as follows:

[0124] Owner: Team owner privileges, can update team information, disband the team, and invite team members; Developer: Team developer privileges, can add or edit requirement templates and perform requirement modeling; Viewer: Team visitor privileges, can preview requirement modeling projects within the team.

[0125] Furthermore, the operation management module includes a log recording module, a permission verification module, and an operation environment management module; the log recording module is used to record operation logs; the permission verification module is used to verify the permissions set by the permission management module; the operation environment management module includes a gateway management module and a routing management module; the gateway management module is used for load balancing between microservices; the routing management module is used for routing management.

[0126] Specifically, due to differences in target server environments, the corresponding runtime environment of the generated requirements modeling system needs to be configured to ensure its proper functioning. Data requests sent from the front end will be forwarded to different microservices for processing via the gateway management module. For example, querying requirements template information will access the Backend-Template microservice; querying team information will access the Backend-Group microservice. For critical microservices, multiple service nodes can provide services simultaneously. Therefore, the gateway management module needs to evenly forward large numbers of data requests to different service nodes to avoid a large number of data requests accessing a single service node at the same time.

[0127] Compared with existing technologies, the beneficial effects of the system for domain requirement modeling provided by this invention are as follows:

[0128] 1. This invention supports the creation of new requirement templates through a requirement template customization module. The release module incrementally generates the code of the requirement modeling system based on the newly created requirement templates and automatically deploys it incrementally. This enables the online requirement modeling system to support new requirement changes and achieve continuous integration. There is no need to customize new requirement templates and generate new requirement modeling systems through another requirement template customization tool and then deploy them. This greatly reduces the iterative development costs caused by requirement changes and improves the efficiency of requirement modeling.

[0129] 2. This invention constructs CRUD business logic templates and collaboration logic templates, and then automatically generates CRUD logic code and collaboration logic code corresponding to the requirement templates. By constructing atomic component templates, the corresponding collaborative modeling data display logic and UI interface style are encapsulated, and the front-end code corresponding to the requirement templates is automatically generated. This not only simplifies the front-end and back-end code architecture, but also supports multi-user collaborative requirement modeling. It is suitable for domain requirement modeling with large scale and complex modeling tasks, and improves the efficiency of requirement modeling.

[0130] 3. This invention simplifies the customization of requirement templates by extracting four-level entities and attributes that are dependent on each other, thereby improving the efficiency of requirement template customization and requirement modeling. Furthermore, this invention improves the versatility of the requirement template ontology model by designing it to cover all requirement semantics in different domains.

[0131] 4. Based on the syntax and semantic constraints of the requirement template, this invention constructs a simple and easy-to-use requirement template expression mode for the requirement template ontology model, thereby improving the efficiency of requirement template customization and requirement modeling.

[0132] 5. This invention obtains related existing requirement templates by analyzing the names of the requirement templates to be built, supports the reuse of requirement templates, and thus improves the efficiency of custom requirement templates.

[0133] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0134] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A system suitable for domain requirements modeling, characterized in that, The system comprises the following modules: a front-end module for UI interface display and user interaction, and transmitting user input data to a business system module; the business system module comprises a requirement template customization module, a requirement modeling module, a checking module, and a release module; the requirement template customization module is used for receiving user input data and creating a new requirement template; the requirement modeling module is used for receiving user input data and performing requirement modeling based on the newly created and existing requirement templates; the checking module is used for checking the correctness of the newly created requirement template or model; and the release module is used for generating the code of the requirement modeling system based on the newly created requirement template and automatically deploying the code; a data management module for data caching and storing the forms corresponding to the newly created requirement templates and the relationships between the forms, and the form data values corresponding to the requirement modeling, into a database; a running management module for configuring the running environment of the requirement modeling system to support normal operation thereof.

2. The system suitable for domain requirements modeling according to claim 1, characterized in that, The requirement template customization module comprises an ontology model construction module, an expression pattern construction module, a requirement template definition module, and a requirement template reuse module; the ontology model construction module is used for extracting four-level entities and attributes with upper and lower level dependencies based on domain semantic analysis, and constructing a requirement template ontology model; the expression pattern construction module is used for obtaining requirement template syntax and semantic constraints based on the four-level entities and attributes with upper and lower level dependencies, and constructing a requirement template expression pattern based on the requirement template syntax and semantic constraints; the requirement template definition module is used for constructing a requirement template based on the requirement template ontology model and the requirement template expression pattern; the requirement template reuse module is used for realizing the reuse of requirement templates.

3. The system suitable for domain requirements modeling according to claim 1, wherein, The requirement modeling module comprises a model construction module and a collaborative modeling module; the model construction module is used for performing requirement modeling based on requirement templates; and the collaborative modeling module is used for realizing collaborative requirement modeling by multiple users.

4. The system suitable for domain requirements modeling according to claim 1, wherein, The release module comprises a code generation module and a deployment module; the code generation module comprises a database script module, a back-end code module, and a front-end code module; the database script module is used for generating a database script of the requirement modeling system based on the newly created requirement template; the back-end code module is used for constructing CRUD business logic templates and collaborative logic templates, and generating back-end code of the requirement modeling system based on the database script, the CRUD business logic templates, and the collaborative logic templates; the front-end code module is used for constructing atomic component templates, and generating front-end code of the requirement modeling system based on the newly created requirement templates and the atomic component templates; the deployment module is used for connecting to a server and automatically deploying the code generated by the code generation module.

5. The system suitable for domain requirements modeling according to claim 1, wherein, The requirement modeling system further comprises a service governance module and a permission management module; the service governance module is used for managing the micro services generated by the requirement template customization module, the requirement modeling module, the checking module, and the release module; the permission management module is used for managing the permissions of users; the users comprise teams and team members.

6. The system suitable for domain requirements modeling according to claim 1, wherein, The permission management module comprises a team management module and a team member management module; the team management module is used for setting basic information of different teams and demand modeling projects corresponding to the teams; and the team member management module is used for setting basic information of different members and permission levels.

7. The system suitable for domain requirements modeling according to claim 2, wherein, The demand template reuse module realizes reuse of the demand template by the following method: Key words of a built demand template name are extracted to obtain a key word vector and store in a database; key words of a to-be-built demand template name are extracted to obtain a key word vector; similarity of the key word vectors of the to-be-built demand template and the built demand template name is calculated; a built demand template list corresponding to the similarity greater than a threshold is displayed; a built demand template is selected from the list to construct the to-be-built demand template, thereby realizing reuse of the demand template.

8. The system suitable for domain requirements modeling according to claim 1, wherein, The checking module generates front-end and back-end codes related to demand template checking logic based on the demand template syntax and semantic constraints, and is used for checking correctness of a newly-built demand template or model when the demand template or demand modeling is constructed.

9. The system suitable for domain requirements modeling according to claim 2, wherein, The four-level entities and attributes with superior-inferior dependency are extracted based on analysis of all demand semantics of different domains to construct a demand template ontology model, which comprises: The four-level entities and attributes with superior-inferior dependency are extracted based on analysis of all demand semantics of different domains to construct a demand template ontology model; the four-level entities comprise Template, Group, Entry and EntryAttribute, and each entity has its own attribute; The Template represents a domain demand template, and the Group describes all demands under the Template; The Group aggregates all demands into a demand tree through an aggregation relationship, and the Entry describes data entity formats under each demand; The EntryAttribute describes data types of attributes in the data entity formats under the Entry.

10. The system suitable for domain requirements modeling according to claim 2, wherein, The demand template syntax constraints comprise: For the Template, one or more Groups can be in the child level; For the Group, one or more CompositeGroups or AtomicGroups can be in the child level; for the CompositeGroup, the child level can comprise at least one AtomicGroup, which is aggregated by AtomicGroups or AtomicGroups and CompositeGroups; for the AtomicGroup, one Entry is in the child level, and the number of instances can be constrained; For the Entry, one or more EntryAttributes can be in the child level; For the EntryAttribute, a data type needs to be specified, and the EntryAttributes can have an association relationship; The Template, CompositeGroup, AtomicGroup and EntryAttribute need to have Chinese and English name definitions; The demand template semantic constraints comprise: Template shall have at least one non-empty child AtomicGroup; AtomicGroup shall have exactly one parent CompositeGroup; The Chinese and English names of AtomicGroup and AtomicGroup, AtomicGroup and CompositeGroup, CompositeGroup and CompositeGroup in the same CompositeGroup child shall not be the same; The Chinese and English names of EntryAttribute in the same Entry child shall not be the same.

Images