A method to support the deep integration of MBSE modeling tools and modeling methodology

Abstract

The present invention provides a method for supporting the deep integration of MBSE modeling tools and modeling methodology, including: step 1: designing a methodology metamodel based on GOPPRR‑E meta-metamodel; step 2: defining a methodology mapping specification: a mapping diagram of GOPPRR‑E meta-metamodel and XML based on a meta-object mechanism; step 3: constructing a methodology model: loading the methodology metamodel stored in XML format into the MBSE modeling tool, and converting the methodology metamodel in XML into an internal model structure recognizable by the modeling tool by parsing the mapping specification; step 4: designing a physical exchange specification: designing a navigation modeling language based on XML, and designing and defining an abstract syntax. The present invention can solve the problems of poor scalability of existing methodologies, insufficient deep integration of methodologies and tools, and realize the design of a process model-driven system based on methodology construction.

Description

Technical Field

[0001] The present invention relates to a method for supporting the deep integration of MBSE modeling tools and modeling methodology, and relates to the field of modeling languages ​​and modeling tools, and more specifically, to the field of Model-based Systems Engineering (MBSE). Background Art

[0002] MBSE is an important part of the development and implementation of intelligent manufacturing and a core element of digital transformation, and methodology is one of the pillars of MBSE. Considering the shift of MBSE applications from laboratory level to major equipment fields such as aerospace, designers are more concerned about "how to design the right system". The issue of methodology supporting the design of complex equipment systems is the focus of research.

[0003] With the increasing complexity of systems, Model-based Systems Engineering (MBSE) has been proposed and proven to be a powerful method to solve the challenges of complex system design. MBSE is a system engineering method that describes complex product systems by establishing system models, supporting the requirements, design, analysis, verification and validation activities of the entire life cycle of the system from the conceptual design stage. Modeling language, modeling tools and modeling methodology are the three pillars of MBSE application practice. Modeling language is a modeling specification that gives the system model practical meaning that is different from the elements in traditional PPT and Visio diagrams through semantic and grammatical rules, and is used to develop system models; modeling tools are the carriers of modeling languages ​​and modeling methodologies, supporting designers to perform modeling, simulation, verification and analysis activities on the tools; modeling methodology is a modeling guide, which is the basis for guiding designers to use modeling languages ​​and modeling tools to carry out system design and model management.

[0004] At present, researchers have done a relatively thorough study on modeling languages, modeling tools, and the combination of the two, but the research on the deep integration of methodology and modeling tools is relatively weak. In the development process of complex equipment systems with multi-disciplinary and multi-system hierarchical coupling, designers either use a combination of multiple mature methodologies, which are generally supported by specific modeling tools, which will lead to data heterogeneity and is not conducive to the management of system models; or customize a set of special methodologies. However, since there are no special custom development tools, this customized methodology often exists implicitly in the minds of designers, strongly dependent on specific personnel, and is not conducive to the maintenance and expansion of the model. As the number of models increases, the above problems will be more obvious, which will seriously reduce the design efficiency and reliability.

[0005] Although there have been some related studies in the field, such as the paper "Research on Application of CNI System Architecture Definition Based on OOSEM", which introduces the application process of the object-oriented system engineering method (OOSEM) of the International Systems Engineering Association in the definition of a communication, navigation and identification (CNI) system architecture. OOSEM was formed from the work of the Software Productivity Alliance (now the Systems and Software Alliance) in cooperation with Lockheed Martin. The methodology is applied to Lockheed Martin's large-scale distributed information systems, including hardware, software, databases and manual program components. OOSEM uses a model-based approach to express development activities and various artifacts using OMG SysML as the dominant modeling language. It enables system engineers to accurately capture, analyze and specify the system and its many components, and ensure consistency between various system views. OOSEM includes 6 development activities: analyzing stakeholder needs, defining system requirements, defining logical architecture, synthesizing candidate allocation architectures, optimizing and evaluating alternative architectures, and confirming and verifying systems. However, the following problems still exist in this type of research:

[0006] (1) Existing methodologies have poor scalability and cannot adapt to multi-level and multi-domain complex equipment system development scenarios. Although existing mature methodologies such as OOSEM define the complete process of system design (including requirements capture, logical architecture design, etc.), they are essentially general methodologies and lack the ability to expand for specific fields. In addition, the use of existing mature methodologies is limited by modeling languages ​​and modeling tools. If multiple methodologies are used to develop complex equipment systems, different methodologies use different modeling languages ​​and modeling tools (for example, if MagicGrid is selected as the modeling methodology, SysML modeling language and MagicDraw modeling tool must be used; if OOSEM is selected, SysML modeling language and IBM Rhapsody modeling tool must be used). This will lead to inconsistent models and interface problems between different tool systems.

[0007] 2) The lack of deep integration of existing methodologies with modeling tools has resulted in a complex design process. MBSE aims to drive system design through models. However, the current application of methodologies in modeling tools generally focuses on expression, which is just the electronicization of the methodology (similar to the transformation from paper documents to Word electronic documents, which is actually still based on documents). The problem is that the advantages of the model are not fully utilized, resulting in insufficient ability of the process model built based on the methodology to drive system design, and unable to support functions such as viewing, creating, accessing, and executing the model. Summary of the invention

[0008] Based on a comprehensive analysis of relevant research on MBSE and methodology at home and abroad, this paper proposes a navigational modeling technology for complex equipment systems, and conducts in-depth research on modeling and model conversion issues related to methodology. The navigational modeling of this invention is the result of the in-depth promotion of MBSE applications. In-depth research on navigational modeling helps model designers better cope with increasingly complex products, improve design efficiency, ensure the design of the "right" product, and create greater value for the promotion of MBSE applications.

[0009] In view of the problems existing in the above-mentioned prior art, the present invention provides a method, device and system for constructing a system engineering system and a system architecture model.

[0010] The method of supporting the deep integration of MBSE modeling tools and modeling methodology described in the present invention includes:

[0011] Step 1: Design a methodology metamodel based on the GOPPRR-E meta-metamodel. The specific steps for constructing the methodology metamodel include:

[0012] Step 1.1, extract similar information in BPMN and conceptual data model, map BPMN tasks into tasks, and uniformly define sub-processes as activities;

[0013] A set of standards called Business Process Modeling Notation (BPMN) was developed by BPMI (The Business Process Management Initiative).

[0014] Business Process Modeling Notation (BPMN) is a set of specifications, including how to combine these elements into a business process diagram. BPMN is one of the modeling language standards for BPM and workflow.

[0015] Step 1.2, integrate all process elements in BPMN, including event elements, gateway elements and connection objects;

[0016] Step 1.3, based on the GOPPRR-E meta-metamodel, the entity relationship diagram and BPMN are integrated and abstracted to obtain the design of the object and relationship metamodel;

[0017] Step 1.4, define the role metamodel according to the definition of GOPPRR-E meta-metamodel.

[0018] Step 1.5, describe the rules and constraints between metamodels using the extension of the GOPPRR-E meta-metamodel:

[0019] Step 2: Define the methodology mapping specification: Based on the meta-object mechanism, the GOPPRR-E meta-meta model and XML mapping diagram; specifically including:

[0020] Step 2.1: Define the key structures of XML including tags, elements and attributes;

[0021] Step 2.2: Construct a mapping diagram between the GOPPRR-E meta-metamodel and XML based on the meta-object mechanism, specifically including the M3 layer, M2 layer, M1 layer and M0 layer.

[0022] Step 3: Build the methodology model: Load the methodology metamodel stored in XML format into the MBSE modeling tool, and convert the methodology metamodel in XML into an internal model structure that can be recognized by the modeling tool by parsing the mapping specification;

[0023] Step 4: Physical exchange specification design: Design of navigation modeling language based on XML.

[0024] Design and define abstract syntax; take the root node as the physical exchange specification, and define the tag as <physical>The root node is the basis for storing the entire model and has an attribute name, which indicates the name of this XML model file.

[0025] Furthermore, the method for establishing the navigation modeling system also includes:

[0026] Step 5: Semantic parsing and model conversion: specifically including:

[0027] Step 5.1: Define a code generator for generating the methodology process model and the file structure model into an XML model;

[0028] Step 5.2: Convert the process model and the file structure model into a unified KARMA language format so as to be read and parsed by the code generator;

[0029] Step 5.3: According to the defined XML grammar rules, the specific XML file involves complex nesting.

[0030] The present invention needs to solve:

[0031] 1) Support customized methodological models: Based on the Meta Object Facility (MOF), a set of general methodological metamodels is designed to support modelers to customize and build methodological models based on the methodological metamodel.

[0032] 2) System design driven by process model built based on methodology: The process model built based on methodology is associated with the system architecture model, and the functions of viewing, creating, accessing and executing the architecture model are supported in the methodology process model.

[0033] Through the above-mentioned technical means, the present invention can solve the problems of poor scalability of existing methodologies and insufficient deep integration of methodologies and tools, and realize the design of process model-driven systems based on methodology construction.

[0034] In order to solve the problem that existing modeling tools focus on the presentation of methodology but have weak functionality in actual application, a method for deep integration of methodology and modeling tools is proposed. Three commonly used modes for expressing methodology are designed, including process model, file structure and XML model, which support automatic conversion of models in the three modes, reducing the time for designers to build different forms of methodology models. Functionally, the navigation model supports integration with the system's full life cycle model, including requirements, functions, logic, physics and other system models, forms, Gantt charts and other plug-ins, code generation, architecture drive, SMT and other functions, as well as simulation tools such as Modelica, which realizes the rapid creation, navigation and execution of the system design full life cycle model, and improves the efficiency of design, analysis and verification during system development. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a general flow chart of the method for supporting the deep integration of MBSE modeling tools and modeling methodology of the present invention;

[0036] Figure 2 A schematic diagram of the methodology metamodel designed based on the GOPPRR-E meta-metamodel of the present invention;

[0037] Figure 3 A mapping relationship diagram between the GOPPRR-E meta-meta model and XML based on the meta-object mechanism in the method of supporting the deep integration of MBSE modeling tools and modeling methodology of the present invention;

[0038] Figure 4 A schematic diagram for mapping the modeling language abstract syntax specification of the method supporting the deep integration of MBSE modeling tools and modeling methodology of the present invention on the basis of the navigation modeling metamodel;

[0039] Figure 5 A schematic diagram of the code generator workflow in the method for supporting the deep integration of MBSE modeling tools and modeling methodology of the present invention;

[0040] Figure 6 A schematic diagram of mapping rules between a metamodel and a file structure model in a method for supporting deep integration of MBSE modeling tools and modeling methodology of the present invention;

[0041] Figure 7 In the method of the present invention for supporting the deep integration of MBSE modeling tools and modeling methodology, a conceptual diagram of swimlane class subnodes is traversed and generated;

[0042] Figure 8 A schematic diagram of a language interpreter workflow in the method of supporting the deep integration of MBSE modeling tools and modeling methodology of the present invention;

[0043] Fig. 9 Dynamically registering workflows in a mode of dynamic registration of external libraries in a method of supporting deep integration of MBSE modeling tools and modeling methodology of the present invention;

[0044] Fig.10 A schematic diagram of the phase control workflow in the method of the present invention supporting the deep integration of MBSE modeling tools and modeling methodology. DETAILED DESCRIPTION

[0045] The present invention is further described below in conjunction with specific embodiments.

[0046] The terms "include" and "comprising" used herein should be understood as inclusive and open-ended, rather than exclusive. Specifically, when the terms "include" and "comprising" and their synonyms are used in the specification and claims, they mean including the specified features, steps or components. These terms should not be understood to exclude the existence of other features, steps or components.

[0047] Based on the above problems, the present invention proposes a method that supports the deep integration of MBSE modeling tools and modeling methodology, aiming to solve the problems of insufficient integration of modeling tools and modeling methodology, poor scalability of modeling methodology and so on in the prior art, and to realize process model-driven system design based on methodology.

[0048] The present invention supports the method of deep integration of MBSE modeling tools and modeling methodology. Figure 1 As shown. First, the methodology metamodel is designed based on the metamodeling mechanism MOF and the GOPPRR-E meta-metamodel. Then, the storage format of the methodology metamodel is clarified as XML, and the mapping specifications between the GOPPRR-E meta-metamodel based on the metamodeling mechanism MOF, the methodology metamodel, and the methodology model and XML are defined. Finally, based on the above mapping specifications, the loading, parsing and application of the methodology metamodel in the MBSE modeling tool are realized to support the construction of the methodology model. Among them, the methodology model covers information such as the design process sequence, design process level, design process content, and the design process corresponding model.

[0049] The specific implementation steps are as follows Figure 1 As shown, specifically including:

[0050] Step 1: Design a methodological metamodel based on the GOPPRR-E meta-metamodel.

[0051] The methodological metamodel is designed based on the GOPPRR-E meta-metamodel, where:

[0052] (1) The graph metamodel is a container composed of objects, relationship types and connectors (constraints), in which the object and relationship metamodels are contained, and the graph metamodel can also be associated with the attribute metamodel. Connectors are composed of objects, nodes, roles and relationships, forming binding relationships;

[0053] (2) The object meta-metamodel defines a group or class of objects, each of which has the same characteristics and can exist independently of the relational meta-metamodel. It is represented by symbols such as rectangles in the visualization model. The object meta-metamodel is the main element of the graph meta-metamodel, and has an inclusion relationship with the point meta-metamodel. It also adds the semantics of the object by associating the attribute meta-metamodel.

[0054] (3) The relational meta-model defines the connection between objects. It is another important element in the graph meta-model. It has an inclusion relationship with the role meta-model and an association relationship with the attribute meta-model. In the modeling domain, object models are connected and defined as subsets of the Cartesian product of participating object models.

[0055] (4) The role meta-metamodel defines how the object meta-metamodel connects to the relational meta-metamodel and establishes an association relationship with the attribute meta-metamodel. Since GOPPRR-E supports the concept of roles, relationships indirectly connect objects through roles. Some features of the relational meta-metamodel in the GOPPRR-E concept are inherited into the role meta-metamodel. In addition, the identifier of the role must be unique in the association of the corresponding instance of the metamodel;

[0056] (5) The point metamodel establishes an association relationship with the attribute metamodel, allowing objects to be matched through additional semantics or constraints connected by roles. The point metamodel is used to limit the role metamodel of the relationship to which an object can be connected;

[0057] (6) Attributes of meta-meta-models are attributes of other meta-meta-model elements and can contain specific values ​​in the modeling domain. The most important function is to define metadata types, such as regular data types (such as strings, integers, etc.) and meta-model class data types (such as object data, graph data, etc.);

[0058] (7) Extended concepts are used to describe the association relationship between the six meta-metamodels and explain their rules and constraints. These extended concepts include inclusion, binding, decomposition, dissection, and reference / association. Among them, inclusion describes the combination relationship between meta-metamodels, such as combining objects and points together. Binding describes the constraint method between object, point, role and relationship meta-metamodels, which is used to define the rules of the metamodeling language. An object point can correspond to multiple roles, each role corresponds to at least one object point, and each relationship binds two roles. Decomposition refers to the constraint that an object (or relationship, point) metamodel can be decomposed into a graph instance in the modeling domain. Dissection refers to the constraint that an object (or relationship, point, role) metamodel can be mapped into multiple graph instances from different perspectives in the modeling domain. Reference / association defines the reference of a point or attribute metamodel and indicates how objects, relationships, etc. are connected to attributes.

[0059] ER diagrams can intuitively express the entities involved in the methodology process (such as tasks, tools, inputs, outputs) and their relationships. BPMN describes the dynamic execution process of the methodology process through graphical symbols (such as tasks, events, gateways, etc.), which is highly consistent with the logical order of the methodology process in system design. Therefore, by abstracting the ER diagram and Business Process Modeling Notation (BPMN), the GOPPRR-E meta-metamodel is used to design the meta-model.

[0060] In the ER diagram, the process entity contains activities and tasks and is the top-level element. It describes the entire methodology process and describes the methodology flow by constructing different activities, tasks, and task implementations. As shown in Table 1, based on the GOPPRR-E meta-meta model, the process is designed as a diagram meta-model using the diagram meta-model. In order to fit the MBSE description of the diagram, the process is redefined as a methodology flow chart.

[0061] Table 1 Methodology process diagram metamodel

[0062] Metamodel Meta-Meta-Model meaning Methodology Flowchart (Process) picture Used to describe the process of methodology, including all entity elements that make up the methodology process model and the relationships between them.

[0063] Combined with the study of BPMN, the core business process description model is abstracted. The specific steps of constructing the methodology metamodel include:

[0064] Step 1.1, extract similar information in BPMN and conceptual data model, map BPMN tasks into tasks, and define sub-processes uniformly as activities (composite tasks).

[0065] There are concepts of activities, tasks, lanes and pools in BPMN. Therefore, BPMN tasks are mapped as tasks, and sub-processes are defined as activities (composite tasks). Lanes and pools are both a type of swimlane, similar to perspectives and views in the conceptual data model. However, in the definition of BPMN, lanes and pools are used to describe the responsibilities of different system participants, while views and perspectives in the conceptual data model are based on system engineering theory to describe different aspects of the system. Therefore, drawing on the representation of lanes and pools in BPMN, views and perspectives are defined as swimlanes, and their metamodel type is object.

[0066] Step 1.2: Integrate all process elements in BPMN, including event elements, gateway elements, and connection objects.

[0067] In addition to activity and swimlane elements, BPMN also includes event elements, gateway elements and connection objects.

[0068] Event class elements express events that occur during a business process. The logical data model extracts the start, middle, and end events as object metamodels to mark the progress of the methodology.

[0069] The gateway class element is used to control the branching and merging of the process. The exclusive gateway, parallel gateway, and inclusive gateway are extracted as the object metamodel for the branching and merging of the methodology process.

[0070] The connection object is used to connect the model elements in the business process model to form a basic business process, and extract the sequence flow, message flow, association and remarks as the relational metamodel.

[0071] Step 1.3, based on the GOPPRR-E meta-metamodel, the entity relationship diagram and BPMN are integrated and abstracted to obtain the design of the object and relationship metamodel.

[0072] The design of the methodology object and relational metamodel is shown in Tables 2 and 3.

[0073] Table 2 Methodology object metamodel

[0074] Metamodel Meta-Meta-Model meaning Metamodel, code generation, architecture driver, hybrid state machine simulation, indicator verification Object KARMA-like elements Requirements management, tables, design structure matrix, relationship mapping form, Gantt chart Object Form Elements Sankey diagram, relationship diagram, tree map Object Knowledge graph elements Perspective, View, Activity Object Lane Elements start Object Indicates the starting point of a process. Usually used to trigger the start event of the process middle Object Represents an intermediate event in a process, which is usually used to indicate events that are triggered when waiting for a certain condition or processing some logic. Finish Object Indicates the end point of a process. When a process reaches the end event, the current branch of the process is completed. Task Object Represents a specific step or activity in a process, which can be manual, automated, or a combination of both. Exclusive Gateway Object Used to make a unique choice in the process and decide which branch to enter based on the conditions Parallel Gateway Object Used for concurrent execution in a process, allowing multiple branches to execute simultaneously until all branches are completed and then merged Including Gateway Object Multi-path branch selection

[0075] Table 3 Methodological relationship metamodel

[0076] Metamodel Meta-Meta-Model meaning Sequence Flow relation Indicates the order in which different elements of a process are executed. Message Flow relation Represents the message passing relationship between different elements in a process. Relevance relation Indicates the relationship between different elements in a process, such as whether a task requires a code generation. Remark relation Indicates the connection relationship between different elements and notes in the process.

[0077] Step 1.4, define the role metamodel according to the definition of GOPPRR-E meta-metamodel.

[0078] The relational metamodel needs to rely on the role metamodel to achieve connection and directional constraints with the object metamodel.

[0079] Based on the above relationship metamodel definition, the role metamodel definition is shown in Table 4:

[0080] Table 4 Methodological role metamodel

[0081] Metamodel Meta-Meta-Model meaning Sequence flow start Role Connect sequence flow relationships and task / activity / event class / gateway class objects. Sequence Flow Terminal Role Connect sequence flow relationships and task / activity / event class / gateway class objects. Message flow start Role Connect the message flow relationship and the objects corresponding to the task / activity / view / perspective / tool ​​class entities. Message Flow Terminal Role Connect the message flow relationship and the objects corresponding to the task / activity / view / perspective / tool ​​class entities. Association start Role The object that connects the association relationship and the tool entity. Associated Terminal Role Connects associations and task / activity objects. Notes start Role Connects the note relationship and the note object. Note terminal Role Connect note relationships and other objects except notes.

[0082] The methodological attribute metamodel is shown in Table 5:

[0083] Table 5 Methodology attribute metamodel

[0084] Metamodel Meta-Meta-Model meaning name property Indicates the angle of analysis expressed by perspectives and views. File name property Indicates the name of a specific file in the project or to be created. Task Name property Indicates the specific content of task execution. Element model property Represents a diagram model type, such as an activity diagram. describe property Indicates the content of the note description. Filter file types property Indicates the file type that the form filters. Filtering Files property Indicates the name of the file to be filtered by the form. Filtering Metamodel property Metamodel representing form filtering, such as the graph metamodel.

[0085] Step 1.5, use the extension of GOPPRR-E meta-metamodel to describe the rules and constraints between meta-models:

[0086] (1) Inclusion rule: The methodology flowchart (graph metamodel) includes all other metamodels.

[0087] (2) Binding rules: including the binding of relationships to roles and the binding of roles to objects. 1) Binding of relationships to roles: The beginning and end of sequence flows are bound at both ends of sequence flows, the beginning and end of message flows are bound at both ends of message flows, the beginning and end of associations are bound at both ends of associations, and the beginning and end of notes are bound at both ends of notes; 2) Binding of roles to objects.

[0088] (3) Reference / association rules: describe the attribute metamodel referenced by the object metamodel. Objects that reference the "name" attribute include views and perspectives; objects that reference the file name attribute include architecture driver, code generation, diagram metamodel, indicator verification, requirement management, table, Gantt chart, design structure matrix, relationship mapping form, relationship diagram, Sankey diagram, and tree mapping diagram; objects that reference the task name attribute are tasks; objects that reference the diagram metamodel attribute are diagram metamodels; objects that reference the three attributes of filter file type, filter file, and filter metamodel include design structure matrix and relationship mapping form; objects that reference the description attribute are notes.

[0089] (4) Sectioning rules: According to the characteristics of the designed conceptual data model, views and perspectives express the analysis of specific problems in the system engineering process, and activities express the composition of multiple tasks. At different levels of abstraction, these three object metamodels are essentially a type of "process" or methodological flowchart. Therefore, GOPPRR-E is used to extend the definition of views, perspectives, and activities, and define the sectioning of view, perspective, and activity object metamodels to the methodological flowchart metamodel. Designers can model in the sectioned model to achieve model partitioning.

[0090] Methodology metamodel designed based on GOPPRR-E meta-metamodel such as Figure 2 shown.

[0091] Step 2: Define the methodology mapping specification: Based on the meta-object mechanism, the GOPPRR-E meta-meta model and XML mapping diagram. Specifically include:

[0092] Step 2.1: Define the key structures of XML including tags, elements and attributes.

[0093] The specific meanings are as follows:

[0094] (1) Marking

[0095] A tag is a label structure that starts with < and ends with >. There are three types of tags: start tags, e.g. <methodology> ; End tag, for example< / methodology> ; Empty element tag, for example <methodology / > XML tags are similar to HTML tags, but they are different. The difference is that XML tags are customizable and can be extended and defined according to specific needs. This is of great value to the modeling language design in this study.

[0096] (2) Elements

[0097] An element begins with a start tag and ends with a matching end tag, or consists of only empty element tags. The characters between the start and end tags are the content of the element, and may contain multiple sub-elements consisting of tags or other elements. For example: <methodology> MOFLP< / methodology> or <methodology / > .

[0098] (3) Attributes

[0099] Attributes consist of name-value pairs that appear in a start tag or empty element tag. For example,<methodologyname="MOFLP" / > , where the name of the attribute is "name" and the value is "MOFLP". Each attribute can only correspond to one value, and each attribute can appear at most once on each element.

[0100] Step 2.2: If Figure 3 As shown in the figure, a mapping diagram of GOPPRR-E meta-meta model and XML based on meta-object mechanism is constructed, which specifically includes M3 layer, M2 layer, M1 layer and M0 layer. Specifically:

[0101] The M3 layer is the GOPPRR-E meta-metamodel, which corresponds to the basic structural elements and attributes of XML. By defining different tags and different element nesting, the non-attribute meta-metamodel in the GOPPRR-E meta-metamodel can be expressed. For example, the object meta-metamodel is mapped to <object>< / object> The property meta-model is consistent with the concept of XML attributes and can be directly expressed as <object property=""”">< / object> ;

[0102] The M2 layer is a metamodel constructed using the GOPPRR-E meta-metamodel, which corresponds to XSD. The metamodel is constructed by defining constraints and rules between GOPPRR-E meta-metamodels and has certain semantics and syntax. The process of XSD construction is similar to that of XSD, which requires the specification of elements and data types contained in XML documents;

[0103] The M1 layer is a model built using the metamodel, corresponding to the XML document file. In MBSE, the construction of the model needs to follow the metamodel specification. Under the XSD specification, the generation of the XML document also needs to follow its specification, otherwise it will not pass the document standardization verification.

[0104] The M0 layer is a descriptive perspective. Whether it is a methodology model or an XML file, its purpose is to describe the methodology for developing complex equipment systems, but its existence form is different.

[0105] Step 3: Build the methodology model: Load the methodology metamodel stored in XML format into the MBSE modeling tool, and convert the methodology metamodel in XML into an internal model structure recognizable by the modeling tool by parsing the mapping specification.

[0106] Based on the methodology metamodel, a customized methodology model can be created through a visual interface or by directly editing XML format files, including information such as the design process sequence, design process level, design process content, and the model corresponding to the design process. In the modeling tool, through the guidance of the design process sequence and design process level of the methodology model, it supports the viewing and modification of the design process content, as well as the viewing, creation, access, and execution of the system architecture model corresponding to the design process. For example, designers can directly operate the corresponding models in the specific design process of the methodology model, such as the requirement model, logical architecture model, and physical architecture model, to avoid manual switching of models or tools.

[0107] This invention takes MagicGrid methodology as an example and supports the construction of MagicGrid methodology model. Its design process sequence is expressed through "sequence flow"; the design process level includes problem domain (problem domain black box, problem domain white box) and solution domain; the design process content includes stakeholder needs, use cases, system context, effectiveness measurement, etc., which are executed in the order of the design process; and the design process is associated with the corresponding model. The corresponding model of the design process is such as the "Requirement Management" requirement form and "Graph Meta Model" corresponding to the "Stakeholder" task. By clicking to execute the "Requirement Management" requirement form or "Graph Meta Model", the model corresponding to the process can be opened.

[0108] Step 4: Physical exchange specification design: Design a navigation modeling language based on XML, and perform abstract syntax design and definition.

[0109] As an XML model, the Navigational Modeling Language (i.e., Physical Exchange Specification) is essentially used for the physical storage of models. There is a gap between its expression of methodological processes and graphical methods. Therefore, the description focuses on lightweightness, and pays attention to describing the structural information of the methodology, making full use of the advantages of XML semantic self-evidence.

[0110] The present invention designs a navigation modeling language based on XML, designs and defines abstract syntax, and its meaning is as follows:

[0111] Abstract syntax is an abstract representation of the grammatical structure of a programming language, which is obtained by abstracting and simplifying the specific syntax. Abstract syntax usually only focuses on the important grammatical structure and semantics in the programming language, ignoring the details and underlying implementation of the specific syntax. Abstract syntax is a commonly used concept in programming language design and program analysis, which can help programmers better understand the grammatical structure and semantics of the programming language.

[0112] The abstract syntax is mapped on the basis of the navigational modeling metamodel according to the XML syntax specification, such as Figure 4 This article uses UML class diagram to express the abstract syntax of navigation modeling language, as shown in the figure, including three types of elements:

[0113] 1) Class, in Figure 4 It is represented by a rectangle, which includes the name, attributes and methods of the class. Classes are mapped to the concept of XML language elements. For example, the top-level class object represents the root node of the navigational modeling language, which is the physical exchange specification. <physical>Tag, and has a name attribute;

[0114] 2) Combination relationship, in Figure 4 It is represented by a diamond plus a solid line. The diamond represents the whole object, and the solid line represents the component object. The composition relationship means that a class object contains another class object, and the contained object is a part of the class object, that is, the relationship between the whole and the part. The composition relationship is a strong association relationship, which means that the whole object has its components, and the components cannot exist in other whole objects;

[0115] 3) Generalization relationship, in Figure 4 It is represented by a hollow triangle and a solid line. The hollow triangle points to the parent class, and the solid line connects the subclass and the parent class. It indicates that a class is a special form of another class, that is, the relationship between the subclass and the parent class. The subclass inherits the properties and methods of the parent class and can add its own properties and methods. The above two relationships correspond to the relationship between elements in the designed navigational modeling language, such as the modeling method ( <methodology>) elements consist of object elements and lane elements, where the lane elements inherit from the modeling method and have localLabel attributes and element relationships consistent with the modeling method.

[0116] Step 4 specifically includes:

[0117] Step 4.1: Set the root node as the physical exchange specification and define the tag as <physical>The root node is the basis for storing the entire model and has an attribute name, which indicates the name of this XML model file.

[0118] The root node consists of modeling method, stage control and model information. These elements work together to store various types of information in the methodology.

[0119] (1) Modeling method <methodology>

[0120] The modeling method maps the concept of the methodology flow chart in the metamodel. Each XML model file contains a modeling method element. The modeling method node includes an attribute <locallabel>, consistent with the local name of the methodology flowchart in the metamodel, describing the name of the modeling method.

[0121] The modeling method element node is composed of object elements and lane elements for the following reasons: 1) Although the lane is a type of object in the metamodel, in order to clearly express the hierarchical structure of the method in the XML model, the lane element and the object element are listed in parallel in the syntax; 2) Since the XML model file is in text form, its ability to express the logical relationship between tasks is weak. Therefore, the modeling method element node focuses on expressing the hierarchical structure and specific content of the methodology, and other metamodels are not mapped as sub-elements of the modeling method element node.

[0122] 1) Object <object>

[0123] According to the definition of the composition relationship, each modeling method allows the existence of zero or more objects. As a higher-level parent element, the object is mapped one-to-one with the object metamodel constructed in the logical data model. However, as mentioned above, the XML model focuses on expressing the structure, so it does not include objects that express logical relationships in the object metamodel, such as start and end.

[0124] The object has localLabel and metaObject attributes, which represent the local name of the object and its metamodel type ID respectively. The purpose of this design is that the localLabel (local name) of each model element constructed in the navigational modeling system can be modified, which is convenient for designers to name elements. When the default label is modified, the specific model element corresponding to the element cannot be distinguished by XML text alone, so the metaObject tag is added to indicate its metatype.

[0125] Although the object class in the abstract syntax establishes a mapping relationship with the object metamodel of the logical data model, its basic design pattern is different from the process-oriented and function-oriented design pattern of the logical model. Its design idea is object-oriented, making full use of the advantages of XML to achieve the reuse and extension of specific subclasses and improve design efficiency. Therefore, this study abstracts the object metamodel of the logical data model and designs the hierarchical structure of the object class and its subclasses. All subclasses are generalized from the object class and have the attributes of the object class. According to whether the object metamodel has a file name attribute, the objects without the file name attribute include behavioral simulation, system simulation, multi-physics field simulation, Simulink simulation and tasks. Among them, the task has a task name attribute alone, so the attribute is extended; the objects with file names are generalized into file classes, including indicator verification, graph metamodel, architecture drive, code generation, requirement management, matrix, Gantt chart, relationship diagram, Sankey diagram, and tree mapping diagram. Among them, the graph metamodel class also extends the graph metamodel as an attribute, and the matrix class also extends the filtering file type, filtering metamodel and filtering file as attributes. The design structure matrix and relationship mapping form inherit the matrix class.

[0126] 2) Lanes <swimlane>

[0127] The swimlane has three subclasses: view, perspective, and activity. Each XML model file has at least zero swimlanes. View, perspective, and activity inherit the modeling method element, so these three elements can be nested as parent elements with child elements. The inheritance process of view, perspective, and activity to the modeling method element is equivalent to the definition of the profile in the logical data model design process, which is also a mapping of the metamodel.

[0128] (2) Stage control <phasecontrol>

[0129] The phase control element is a new element additionally defined in the navigational modeling language, and each XML model file contains a phase control element. The navigational modeling workflow designed by the present invention and the method flow chart model need to control the reading and writing of the model in different application phases during use.

[0130] It is not feasible to control the read and write of the entire model object by establishing a specific model object separately, because when the model canvas is locked, the process model canvas cannot be unlocked by changing the object model. Therefore, this study designs the stage control element in the XML model of the navigational modeling language, and controls the read-only and design status of the process model by modifying the stage control tag information in the storage file.

[0131] (3) Model information <modelinformation>

[0132] The model information element is a new element additionally defined in the navigational modeling language. Model information is used to express the location, layout, size and appearance of objects and relationships in the entire canvas. It is an important element for converting XML model files into graphical models using model conversion. Each XML model file of navigational modeling contains at least one model information element, which stores the information of the methodology flowchart model itself. The reason why there may be multiple model information elements is that there are often multiple lanes in the flowchart model, and the lanes also need to be stored as section view models.

[0133] The model element consists of a CDATA element, which is plain text data in XML. This element is used to hold the KARMA language model of a specific model (formalized from the process model). Since the KARMA language syntax is relatively complex, this part uses CDATAXML blocks that can contain any characters, including special characters (such as <, >, &, etc.), and will not be parsed by the parser to avoid obstacles during the parsing process.

[0134] Model information can have an object name. The elements such as views, perspectives and activities defined in the navigational modeling language are the modeling method elements ( <methodology>), which corresponds to the section view relationship between it and the methodology flowchart constructed in the metamodel. In actual modeling activities, the construction of such section view relationships is object-based, that is, the view, perspective and activity itself is an object, and the section view model is created in these objects. Therefore, in order to realize the information description of the section view relationship, it is necessary to obtain the object name attribute to which each section view belongs, so as to associate each section view model in the methodology flowchart with its corresponding object. The methodology flowchart itself does not have an object name attribute, mainly because it itself is not derived from object sectioning, but exists as the highest-level model of the XML model file.

[0135] On the basis of the mutual conversion between KARMA language and graph model, we study how to make multiple sets of KARMA language file information compatible in XML and realize the conversion between graph model, XML and file structure. The advantage of this is that we avoid the research on model conversion of complex native computer data of graph model, and KARMA language provides a good data model interface to facilitate data operation. Finally, the actual model conversion work includes the mutual conversion between XML model and KAMRA language (multiple files), and the mutual conversion between file structure model and XML model.

[0136] The method for establishing the navigation modeling system further comprises:

[0137] Step 5.1: Define a code generator for generating the methodology process model and the file structure model into an XML model;

[0138] The code generator is used to generate the methodology process model and the file structure model into an XML model. The workflow of the code generator is as follows: Figure 5 shown.

[0139] Define the triggering mechanism for the code generator:

[0140] Since the methodology process model and the file structure model are for designers to use or view, and the model itself will not be modified during the viewing process, if these models are generated with real-time code, it will take up a lot of resources and reduce the efficiency of the navigation modeling system. Therefore, the trigger definition of the code generator is when the designer modifies and saves the methodology process model or the file structure model.

[0141] Step 5.2: Convert the process model and the file structure model into a unified KARMA language format so as to be read and parsed by the code generator;

[0142] KARMA language generation

[0143] Both the process model and the file structure model constructed by navigational modeling need to be converted into a unified KARMA language format before they can be read and parsed by the code generator designed in this section. For the process model constructed by navigational modeling, it is based on the KARMA language modeling platform, so its model data can be automatically converted into KARMA language description. The file structure model belongs to the file node type data and cannot be automatically converted. Therefore, this section mainly studies the mapping of the file structure model to the KARMA language.

[0144] From the perspective of model design purpose, the file structure model is mainly used to express the hierarchical structure of the model, which is consistent with the description of the XML model. Since the KARMA language is also a modeling language developed on the GOPPRR-E meta-metamodel, the present invention realizes its mapping with the KARMA language by constructing a mapping between the metamodel and the file structure model.

[0145] like Figure 6 As shown in the figure, the mapping rules between the metamodel and the file structure model are illustrated. The objects related to the file are mapped to folders, that is, the method flow chart is mapped to a folder, and the perspective, view and activity as the generalization of the method flow chart are also mapped to folders, and the other objects related to the file are mapped to files.

[0146] The generation of the file structure model to the specific KARMA language is realized by defining code templates. In fact, in the process of code generation, there are a lot of codes used to describe the reference information and appearance of the meta-meta model, while the only things related to the file structure model are the file name, local name, file type and file hierarchy relationship. Therefore, designing code templates can effectively encapsulate the mapping target model, reduce duplication tools and improve code generation efficiency.

[0147] The code template from the file structure model of the present invention to the KARMA language is mainly divided into folder class and file class. The code generation template of the folder takes the swimlane class object - view as an example, and the code generation template of the file takes the file class object as an example, where <> represents the content that needs to be filled in the code template. In addition, since the model object created by the file structure does not have sufficient layout parameters (mapped to the specific position and size in the methodology process model), the relevant position parameters are all defaulted.

[0148] (1) XML generation

[0149] The code generation of the XML model is divided into two parts: KARMA language processing and XML construction. KARMA language processing is used to provide all the information required for XML construction. The XML parsing generation tool used is DOM4J. Compared with other XML parsing tools, DOM4J is chosen because of its high performance. DOM4J uses a memory management mechanism based on caching and lazy loading, which can greatly reduce memory usage and improve performance. At the same time, DOM4J uses SAXReader to parse XML documents, which is faster and easier to use than other DOM parsers, and is highly readable and highly scalable.

[0150] Step 5.3: According to the defined XML syntax rules, the specific XML file involves complex nesting. The specific construction process follows the following steps:

[0151] a) Build the root node (level one). The root node has an attribute name, whose value comes from the navigation model file name.

[0152] b) Build the phase control node (secondary), with the initial value of "dev". The phase control of the methodology process model is determined by the XML file itself, so the properties of the phase control node will not change due to changes in the methodology process model, so unless you edit this manually, the value will not be modified.

[0153] c) Construct a modeling method node (secondary level) and define the node as a marker symbol m. The attribute value of the modeling method node comes from the parsing of the localLabel of the KARMA language of the main model.

[0154] d) Construct all object child nodes (level 3 and above) of the current level node. These child nodes are obtained by parsing the object part of the graph model corresponding to the current node. The modeling method corresponds to the main graph, and the lane class nodes correspond to each section view. Step 4d) is always executed after the modeling method node or the lane class node to construct the file class object node of the next level of these nodes, such as the graph metamodel child node.

[0155] e) Construct all lane-type child nodes (level 3 and above) of the current level node. These child nodes are obtained by parsing the cross-section of the graph model corresponding to the current node. Figure 7 As shown, the i-th lane subnode of the current level node is defined as , M is the parent node mark symbol of the child node, for example, the first lane child node of the third level is , the fourth-level child node generated is ; The number of lane subnodes owned by the M node, 0 ≦ ≦ ; Special circumstances, when = 0, Represents all object child nodes of the parent node M. According to the definition of the modeling language syntax, lane-type child nodes are inherited from the modeling method node. Therefore, each construction of a lane-type child node is equivalent to starting from step 3 again and executing steps 4d) and 5e). In this process, the model hierarchy is continuously deepened to achieve node nesting, thereby structurally describing the process model information of the methodology. The node completes the construction of its last swimlane child node and the recursion ends.

[0156] f) Construct model information node (secondary). For each main model or section view model in the process model, a model information node will be generated. The node has an attribute and a text. The object name attribute comes from the parsing of the corresponding diagram model. The text paragraph is used to store the KARMA language text content corresponding to the main model or section view model, but it needs to be processed first. Specifically, rewrite the KARMA language text and delete all "this.explode (section view model ID)" fields, which define the section view model ID corresponding to the lane class object. The reason is that the KARMA language definition of section view is multi-file, that is, each section view model will generate a KARMA language file. However, in fact, there is only one navigation modeling file in the navigation modeling system, and there are no multiple language files mentioned above. If this part of the field is retained, it will affect the syntax interpreter part calling the KARMA language specific method to process these model information.

[0157] like Figure 8 As shown, the language interpreter is used to interpret the XML model into a methodology process model and a document tree structure model.

[0158] (1) Define the trigger mechanism of the language interpreter

[0159] Since the language interpreter is used to interpret the XML model file into a process model or a file structure model, the trigger mechanism of the interpreter is defined as when the model is opened for the first time and when the content of the XML model file is changed.

[0160] (2) Dynamic registration of external libraries

[0161] This step is the basis for explaining the XML model file to the process model. In the KARMA language modeling tool, the model built by the designer must be based on a specific metamodel that already exists and is registered under the tool project, including metamodel files, ecore and odesign data. The metamodel file is directly exposed to the tool for designers to develop independently, and the latter two are automatically generated based on the metamodel file.

[0162] From a practical business perspective, if users want to use navigational modeling, they must first create a navigational modeling metamodel in their own project or have the tool import these metamodels into the project, which will result in redundant metamodel files in the project, affecting normal design and project planning. Therefore, this study uses the navigational modeling metamodel library as an external library of the KARMA language modeling tool to study the mode of dynamic registration of external libraries. The dynamic registration workflow is as follows: Fig. 9 shown.

[0163] First, the navigational modeling metamodel must exist as a file library on the designer's computer. This study developed the installation program of the modeling tool so that the project file is automatically installed to the system's AppData folder during the tool installation process.

[0164] Subsequently, in actual use, once the operation of compiling the navigation model is triggered, the system will add ecore and odesign to the project space. After adding, the two files exist implicitly and are invisible to the user. They will be automatically cleaned up when the project is saved. These two types of files are used to register the navigation modeling metamodel in the modeling system. After registration, no specific metamodel project is required to model in the navigation modeling system. In addition to the above two files, the metamodel file is used to provide support for the parsing of the KARMA language file during the model conversion process.

[0165] (3) XML model interpreted as process model

[0166] The tool used in the process of interpreting XML to the process model is also DOM4J. The work of this step is to assemble the KARMA language model split in the code generation process into a complete data model, which is further parsed by the background of the navigation modeling system to generate a process model.

[0167] 3.1) Parsing the model information node of the XML model

[0168] The following contents are included: by parsing and processing all model information nodes, the matrix of the main model and each section view model and its KAMRA language mapping is obtained; the KARMA language is parsed into a data model, and the matrix of the main model and each section view model and the data model mapping is obtained (because the section view field is deleted in the code generation, there is no connection relationship between the data models, which is why each data structure can be successfully parsed to avoid searching for non-existent files during the parsing process); the object name attribute corresponding to each section view is extracted from the model information node; the data model of the main model is extracted. The above parsed data is used as the input for subsequent language interpretation.

[0169] 3.2) Traverse all data models

[0170] Each data model is a computer description of a KARMA language model. During the traversal process, find out whether there is a lane class object in the data model. If so, find the section view list of the lane class (only the section view field is deleted in code generation, but the section view list is still retained, and the two are two fields), and add the data model corresponding to the section view list to the data model of the lane class in the form of a section view; if not, continue to traverse backwards and repeat the above process until all data models are traversed. The essence of this step is to read the attribute information of XML, connect the main view and the section view, and the section views to each other to form a complete model network.

[0171] 3.3) Return to the completed main model

[0172] Traversing all data models will re-establish the association between the data models, through which the data of any model can be accessed from the main model. Finally, returning to the main model can drive the navigation modeling system to generate the process model of the methodology from XML.

[0173] (4) XML model is interpreted as a file structure model

[0174] The XML model has a direct mapping relationship with the file structure model. The modeling method, view, perspective, and activity nodes are mapped to folders, and the file class nodes are mapped to files. The specific interpretation process follows the following steps:

[0175] 4.1) Parse the modeling method node and generate a first-level project folder of the file structure according to the local name of the node;

[0176] 4.2) Parse all file class object child nodes of the current node, define i = 0, and obtain the file name of each file child node according to the file name attribute of the file class child node. For example, the "code generation" node attribute is codeGen, and the file mapped in the file structure is codeGen.karma. At the same time, according to the different types of file class child nodes, their file suffixes and actual access paths are also different. This step is used to create files in the folder, and designers can directly open files from the file structure;

[0177] 4.3) Parse the ++i-th lane subnode of the current node. The lane subnode is consistent with the modeling method node and is also mapped to a folder. Define the i-th lane subnode of the current level as , M is the marker symbol of the current node. For example, the first lane subnode (secondary folder) of the primary project folder is , the third-level i-th lane class child node generated by it is ; The number of lane subnodes owned by the M node, 0 ≦ ≦ ; Special circumstances, when = 0, Represents all object child nodes of the M node.

[0178] 4.4) Determine if it exists Subnode, that is, generate a folder according to the localLabel of the subnode, and As the parent node of the next level, execute the second step and enter the loop; if it does not exist If a child node is found, the parent node M of the child node is returned. If it is a modeling method node m, the loop ends, otherwise it returns to step 3. In fact, this step is similar to the process of generating XML from a process model in code generation, which is the opposite process, that is, generating all folder and file models through highly structured XML reverse mapping.

[0179] (5) Phase control node analysis

[0180] The parsing of the phase control node is done after the methodology process model is generated but before the model is opened. This is because, affected by the compilation mechanism, once the read-only of the model is triggered, the system will no longer perform compilation activities. Therefore, if the read-only control of the node is executed before the methodology process model is compiled, the methodology process model will be compiled to empty and the canvas cannot be opened.

[0181] The specific read-only control is based on the secondary development of the graphical modeling framework Sirius. The process is as follows Fig.10 As shown. First, parse and obtain the attribute value of the stage control node. Then, before setting the application stage, it is necessary to first determine whether the model comes from the methodological process model. This is because read-only and non-read-only are used to control the global model in the Sirius framework, while this study only needs to control the read-only and non-read-only of the current methodological process model. Finally, rewrite the read-only state of the model according to the attribute value of the stage control node.

[0182] This application has the following technical advantages:

[0183] 1. Deep integration method of methodology and modeling tools: The methodologies in the prior art usually focus on the static display of models, and their functional applications are relatively limited. This invention realizes process model-driven system design by designing a deep integration mechanism of methodology and modeling tools, directly supports the viewing, creation, access and execution of architecture models in the methodology process, and significantly improves modeling efficiency and practicality.

[0184] In order to solve the problem that existing modeling tools focus on the presentation of methodology but have weak functionality in actual application, a method for deep integration of methodology and modeling tools is proposed. The process model built based on methodology is associated with the system architecture model, and the functions of viewing, creating, accessing and executing the architecture model are supported in the methodology process model.

[0185] 2. Methodology metamodel with strong scalability: The present invention designs a set of general methodological metamodels to support customized construction of methodological models, as well as construction of general methodological models such as OOSEM, Harmony SE, MagicGrid, etc.

[0186] Based on the MOF and GOPPRR-E meta-metamodel mechanism, a general methodology metamodel that supports customization is designed. Compared with the existing technology that only supports fixed methodologies (such as OOSEM, MagicGrid, etc.), the present invention can quickly customize the methodology model according to the needs of specific fields, and can flexibly adapt to complex system development scenarios in different fields and at multiple levels.

[0187] 3. Improved data consistency and collaboration efficiency: By associating the methodological process model with the architecture model, the use specifications of multiple modeling languages ​​and tools are unified, solving the model inconsistency and interface problems caused by the multi-tool system in the existing technology, and promoting cross-disciplinary collaboration and standardization of complex equipment system design.

[0188] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0189] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the functional units in the various embodiments of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0190] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0191] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.< / methodology> < / modelinformation> < / phasecontrol> < / swimlane> < / object> < / locallabel> < / methodology> < / physical> < / methodology> < / physical> < / physical>

Claims

1. A method to support the deep integration of MBSE modeling tools and modeling methodology, including: Step 1: Design a methodological metamodel based on the GOPPRR-E meta-metamodel; The specific steps include: Step 1.1, extract similar information in BPMN and conceptual data model, map BPMN tasks into tasks, and uniformly define sub-processes as activities; Step 1.2, integrate all process elements in BPMN, including event elements, gateway elements and connection objects; Step 1.3, based on the GOPPRR-E meta-metamodel, the entity relationship diagram and BPMN are integrated and abstracted to obtain the design of the object and relationship metamodel; Step 1.4, define the role metamodel according to the definition of GOPPRR-E meta-metamodel; Step 1.5, describe the rules and constraints between metamodels using the extension of the GOPPRR-E meta-metamodel; Step 2: Define the methodology mapping specification: Based on the meta-object mechanism, construct a mapping diagram between the GOPPRR-E meta-meta model and XML; specifically include: Step 2.1: Define the key structures of XML including tags, elements and attributes; Step 2.2: Based on the tags, elements and attributes obtained in step 2.1, a mapping diagram between the GOPPRR-E meta-metamodel and XML is constructed, wherein the mapping diagram specifically includes an M3 layer, an M2 layer, an M1 layer and an M0 layer; Step 3: Build the methodology model: Load the methodology metamodel stored in XML format into the MBSE modeling tool, and convert the methodology metamodel in XML into an internal model structure that can be recognized by the modeling tool by parsing the mapping specification; Step 4: Physical exchange specification design: Design a navigation modeling language based on XML, and perform abstract syntax design and definition; Taking the root node as the physical exchange specification, the tag is defined as <physical> The root node is the basis for storing the entire model and has an attribute name, which indicates the name of this XML model file;< / physical> The root node is composed of modeling method, stage control and model information. These elements together store various information of the methodology. Step 5: Semantic parsing and model conversion; specifically including: Step 5.1: Define a code generator for generating the methodology process model and the file structure model into an XML model; Step 5.2: Convert the process model and the file structure model into a unified KARMA language format so as to be read and parsed by the code generator; Step 5.3: According to the defined XML grammar rules, the specific XML file involves complex nesting.

2. The method for supporting the deep integration of MBSE modeling tools and modeling methodology according to claim 1, wherein: The M3 layer is the GOPPRR-E meta-metamodel, which corresponds to the basic structural elements and attributes of XML; the non-attribute meta-metamodel in the GOPPRR-E meta-metamodel is expressed by defining different tags and different element nesting; The M2 layer is the metamodel constructed using the GOPPRR-E meta-metamodel, corresponding to XSD; The M1 layer is a model built using the metamodel, corresponding to the XML document file; The M0 layer is a descriptive perspective. Whether it is a methodology model or an XML file, its purpose is to describe the methodology for developing complex equipment systems.

3. The method for supporting the deep integration of MBSE modeling tools and modeling methodology according to claim 1, wherein: The modeling method maps the concept of the methodological flowchart in the metamodel. Each XML model file has a modeling method element. The modeling method node includes a property <locallabel> , consistent with the local name of the methodology flowchart in the metamodel, describing the name of the modeling method.< / locallabel> 4. The method for supporting the deep integration of MBSE modeling tools and modeling methodology according to claim 1, wherein: The phase control element is a new element additionally defined in the navigational modeling language. Each XML model file contains a phase control element. The navigation modeling workflow and methodology flowchart model need to be read and written in different application stages during use; The phase control elements are designed in the XML model of the navigational modeling language, and the read-only and design states of the process model are controlled by modifying the phase control tag information in the storage file.

5. The method for supporting the deep integration of MBSE modeling tools and modeling methodology according to claim 1, wherein: The model information is used to express the position layout, size and appearance of objects and relationships in the entire canvas; Each XML model file of navigational modeling contains at least one model information element, which stores the information of the methodology flowchart model itself.

6. The method for supporting deep integration of MBSE modeling tools and modeling methodology according to claim 1, wherein: The trigger definition of the code generator is when the designer modifies and saves the methodology process model or the file structure model.

7. The method for supporting the deep integration of MBSE modeling tools and modeling methodology according to claim 1, wherein: Step 5.3 specifically includes: a) construct a root node, wherein the root node has an attribute name, and the value comes from the navigation model file name; b) Construction phase control node, the initial value is "dev"; c) construct a modeling method node and define the node as a marker symbol m; d) Construct all object child nodes of the current level node. These child nodes are obtained by parsing the object part of the graph model corresponding to the current node. The modeling method corresponds to the main graph, and the lane nodes correspond to each section view. e) Construct all lane-type child nodes of the current level node. These child nodes are obtained by parsing the cross-section part of the graph model corresponding to the current node; f) Constructing a model information node. For each main model or section view model in the process model, a model information node will be generated. The node has an attribute and a text. The object name attribute comes from the analysis of the corresponding graph model.

Images