System modeling language module definition graph model tree representation method based on JSON (JavaScript Object Notation)

Abstract

The invention discloses a JSON (JavaScript Object Notation)-based system modeling language module definition graph model tree representation method, and belongs to the technical field of computer software. The method comprises the following steps: defining a model tree structure, taking a JSON object as a root node of a model, and setting packets and blocks as top layer attributes; the method comprises the following steps: defining a Package element and a Block element; designing a structure attribute and a behavior attribute of the Block module; data structures and association mechanisms are enriched; and carrying out legality verification on the model tree by adopting JSON Schema. According to the method, a modular modeling idea and standardized model structure abstraction are introduced, a model tree system which supports structure and behavior attribute expression and has relevance and hierarchy is constructed, a semantic level verification mechanism is achieved in combination with JSON Schema, and the blank of a SysML model in the aspect of Web friendly expression and verification is filled up.

Description

Technical Field

[0001] The present invention relates to a method for representing a model tree of a system modeling language module definition diagram based on JSON, belonging to the technical field of computer software. Background Art

[0002] In the modern engineering field, a system is usually composed of a set of interacting components aimed at achieving specific goals or solving complex problems. As a complex aggregate to meet human needs, an engineering system covers physical entities, information, human resources, procedures, facilities, and their relationships with the natural and social environments. Its life cycle includes creation, operation, maintenance, and optimization, and is jointly driven by multiple demands and external environments. As the complexity of systems continues to increase, the model-based systems engineering (MBSE) method has gradually become the mainstream design paradigm.

[0003] The System Modeling Language (SysML) is specifically designed for systems engineering design and supports key tasks such as requirements analysis, architecture design, behavior modeling, parameter modeling, and verification and validation. SysML can be used to model hardware, software, personnel, procedures, and other artificial or natural system elements, helping to achieve the structured definition and architecture specification of systems. Its core consists of a "nine Figure 1 table" that comprehensively describes the structure, behavior, requirements, parameters, and constraints of the system, covering all stages of systems engineering and improving the modeling and analysis efficiency of engineers.

[0004] Although SysML plays an important role in engineering modeling, currently, mainstream modeling tools such as MagicDraw and IBM Rhapsody mostly adopt the C / S architecture. Such tools usually require a large software environment to be installed locally, and model data is mostly stored and exchanged in the XMI format. Although the XMI format is widely used in model-driven engineering, its structure is complex, the parsing efficiency is low, and it is not conducive to Web front-end processing, restricting the lightweight access and wide integration of models.

[0005] In contrast, the B / S architecture has attracted more and more attention from enterprise-level modeling platforms due to its advantages such as flexible deployment, convenient update, support for unified management, and centralized "source of truth". The browser-based SysML modeling platform can not only significantly reduce the client pressure but also facilitate multi-user collaboration, centralized model storage, and permission control. However, the key problem currently hindering the evolution of SysML tools to the B / S architecture is the lack of a lightweight, highly readable, and easily parsable model representation method. Currently, most SysML tools do not provide a data storage solution based on JSON, while JSON, as a lightweight data exchange format with a clear structure, high parsing efficiency, and natural compatibility with the Web front-end, has been widely used in the front-end and back-end separation architecture.

[0006] Therefore, researching and proposing a JSON-based SysML model representation and verification method to construct a JSON Schema that can perform semantic verification not only helps to break down existing architectural barriers but also is of great significance for promoting the webification of SysML tools, enhancing model circulation, and modernizing system engineering tools. Summary of the Invention

[0007] To solve the problems in the background art, the present invention provides a method for representing a model tree of a SysML module definition diagram based on JSON.

[0008] To achieve the above object, the present invention adopts the following technical solution: A method for representing a model tree of a SysML module definition diagram based on JSON, the method comprising the following steps:

[0009] S1: Define the model tree structure, use a JSON object as the root node of the model, and set packages and blocks as top-level attributes;

[0010] The model tree in S1 adopts a hierarchical organization form of key-value pairs to construct the basic framework of the model.

[0011] Both packages and blocks of the top-level attributes in S1 are of array type, and each array item references the externally defined Package and Block structures through $ref to achieve hierarchical nesting and structured organization of modules.

[0012] S2: Define Package elements and Block elements, use Package elements and Block elements as basic modeling container units, support nested structures, ensure the uniqueness of each element, and label each element with a type;

[0013] The Package element in S2 supports a nested structure and includes name, sub-packages, modules, association relationships, association blocks, and value type fields.

[0014] The Block element in S2 is the core structure modeling unit and includes name, abstract attributes, conjugate attributes, composition relationships, reference relationships, value attributes, and operation method fields.

[0015] S3: Design the structural attributes and behavioral attributes of the Block module;

[0016] The S3 includes the following steps:

[0017] S301: Design the structural attributes of the Block:

[0018] S30101: Design the composition relationship field as an array of Attribute objects, representing the composition structure relationship of the module, used to describe the sub - modules or constituent attributes included within the module. If the composition relationship field is an empty set, it indicates that the module is an atomic module or has no sub - modules;

[0019] S30102: Design the reference relationship field as an array of Attribute objects, used to describe the reference relationship of the module to external modules or interfaces;

[0020] S30103: Design the value attribute field as an array of Attribute objects, used to describe the value - type attributes held locally by the module. Each value - type attribute supports both basic data types and reference types. Each value - type attribute optionally configures a default type field and a default value field to support static parameter definition or runtime parameter initialization;

[0021] S30104: Design the abstract attribute field as a boolean - type field, used to identify whether the module is an abstract definition. When the value is true, it indicates that the module cannot be directly instantiated and is only used to provide a general structure or behavior definition;

[0022] S30105: Design the conjugate attribute field as a boolean - type field, used to indicate whether the module is a conjugate module;

[0023] S302: Design the behavioral attributes of the Block:

[0024] Model it with the operation method field. The operation method field is a set of Operation objects, used to describe the functional behavior or service interface of the module. The set of Operation objects can be empty. If the set of Operation objects is empty, it indicates that the module has no active behavior; The operation method field includes @id, @type, name, visibility control field, and a set of method parameters;

[0025] The visibility control field is defined by the enumeration type VisibilityKind and is used to control the access scope of the operation during system modeling;

[0026] Each parameter in the set of method parameters is a Parameter object, used to define the specific characteristics of the input and output required by the operation.

[0027] S4: Enrich the data structure and association mechanism to enhance the model's ability to express complex systems;

[0028] The above - mentioned S4 includes the following steps:

[0029] S401: Introduce the Attribute element as a building unit for system modeling, used to describe the attribute members within the module;

[0030] S402: Introduce the Parameter element as a component unit for system modeling, which is used to enhance the system model's capabilities in parameter expression, value passing, and constraint modeling;

[0031] S403: Introduce the Association element, which is used to represent the general association relationships between model elements, so as to enhance the system model's ability to express complex system structures and relationships between elements;

[0032] S404: Optionally introduce the ownedEnds element from the Attribute element, which represents the endpoint attributes directly owned by this association, supports directly connecting value types, and is used to simplify the definition of association attributes during the modeling process;

[0033] S405: Introduce the AssociationBlock element, which is an extension based on the Association element and is used to express the modeling of association classes with attributes;

[0034] S406: Introduce the ValueType element, which is used to customize reusable data types and supports modeling expressions in the form of structures and enumerations.

[0035] S5: Use JSON Schema to perform legality verification on the graph model tree defined by the system modeling language module based on JSON expression, ensuring the structural compliance, field integrity, and data consistency of the model.

[0036] The said S5 includes the following steps:

[0037] S501: Generate JSON instances according to the defined JSON Schema. Each instance represents a component in the system modeling language model, and each instance conforms to the rules specified in the Schema;

[0038] S502: Use the JSON Schema validation tool to perform legality verification on the generated JSON instances;

[0039] S503: Obtain the verification results.

[0040] Compared with the prior art, the beneficial effects of the present invention are:

[0041] The present invention proposes a lightweight expression method for SysML models oriented to the B / S architecture, with good readability and verifiability. By introducing modular modeling ideas and standardized model structure abstractions, a model tree system that supports the expression of structural and behavioral attributes, has relevance and hierarchy is constructed, and a semantic-level verification mechanism is implemented in combination with JSON Schema, filling the gap in the Web-friendly expression and verification of SysML models, and promoting the technical development of visual modeling, collaborative design, and service-oriented deployment of SysML models on the Web side. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 is the flowchart of the present invention;

[0043] Figure 2 is the content diagram of the top-level JSON Schema of the model tree structure defined by the present invention;

[0044] Figure 3 is the content diagram of the JSON Schema of the Package element;

[0045] Figure 4 is the content diagram of the JSON Schema of the Block element;

[0046] Figure 5 is the content diagram of the JSON Schema for the design of the structural attributes of the Block element;

[0047] Figure 6 is the content diagram of the JSON Schema for the design of the behavioral attributes of the Block element;

[0048] Figure 7 is the content diagram of the JSON Schema for the design of the Attribute element;

[0049] Figure 8 is the content diagram of the JSON Schema for the design of the Parameter element;

[0050] Figure 9 is the content diagram of the JSON Schema for the design of the Association element;

[0051] Figure 10 is the content diagram of the JSON Schema for the design of the AssociationBlock element;

[0052] Figure 11 is the content diagram of the JSON Schema for the design of the ValueType element. DETAILED DESCRIPTION OF THE INVENTION

[0053] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0054] A method for representing a graph model tree of a JSON-based system modeling language module definition, the method comprising the following steps:

[0055] S1: Define the model tree structure. Use a JSON object as the root node of the model, and set packages and blocks as top-level attributes, which respectively represent the set of packages (Package) and the set of modules (Block) in the SysML module definition graph model tree, thereby establishing the organizational relationship and hierarchical structure of the model tree elements;

[0056] As Figure 2 shown, the model tree in S1 adopts a hierarchical organizational form of key-value pairs to construct the basic framework of the model.

[0057] Both packages and blocks of the top-level attributes in S1 are of array type (array). Each array item references the externally defined Package and Block structures through $ref to achieve hierarchical nesting and structured organization of the modules. This design helps to clearly express the subordination relationship and hierarchical structure of each element in the model tree, facilitating subsequent expansion and integration.

[0058] S2: Define two core modeling elements: Package element and Block element. Use the Package element and Block element as basic modeling container units, support nested structures, and are used to carry and organize the SysML model content; each element includes an @id field to ensure the uniqueness of each element (the unique identifier in the entire model), and each element includes an @type field to label the type of each element, which helps with model parsing and verification;

[0059] As Figure 3 shown, the Package element in S2 supports a nested structure and includes fields such as name, packages, blocks, associations, associationBlocks, and valueTypes. This structure allows the Package element to be used as a composite modeling container to recursively nest other packages or modules in the model tree, enhancing the hierarchical and reuse capabilities of the model.

[0060] As Figure 4As shown, the Block element in S2 is the core structure modeling unit. As the most basic structure modeling unit, it supports rich structured expressions. It includes fields such as name, isAbstract, isConjugated, parts, references, values, and operations.

[0061] S3: For the functional modules (Blocks) in the system model, design the structural attributes and behavioral attributes of the Block module to clarify the organizational structure relationship and functional behavior characteristics of each module. The core of this step is to define the structural composition and behavioral interfaces of the module based on the unified JSONSchema format, so as to support the integrity and extensibility of system-level modeling.

[0062] The S3 includes the following steps:

[0063] S301: Design the structural attributes of the Block. The content of its JSON Schema is as Figure 5 shown:

[0064] S30101: Design the parts field as an array of Attribute objects, representing the composite structure relationship of the module, used to describe the sub-modules or component attributes included in the module. If the parts field is an empty set, it means that the module is an atomic module or has no sub-modules;

[0065] S30102: Design the references field as an array of Attribute objects, used to describe the reference relationship of the module to external modules or interfaces, that is, used to model the dependency relationship between modules, support connecting to external interfaces, functional modules or device resources, and can also be empty;

[0066] S30103: Design the values field as an array of Attribute objects, used to describe the value type attributes held locally by the module. Each value type attribute supports basic data types (such as String, Real, Boolean, Integer) and reference types. Each value type attribute selectively configures the defaultType field and defaultValue field to support static parameter definition or runtime parameter initialization;

[0067] S30104: Design the isAbstract field as a boolean type field, used to identify whether the module is an abstract definition. When the value is true, it means that the module cannot be directly instantiated and is only used to provide general structure or behavior definitions;

[0068] S30105: Design the isConjugated field of the conjugate property as a boolean field to indicate whether the module is a conjugate module; conjugacy is usually used in port modeling to represent the connection method of modules with opposite input and output directions.

[0069] Through the combined modeling of the above fields, the structural composition relationship of the module can be completely defined, supporting component-oriented system modeling and hierarchical structure expression.

[0070] S302: Design the behavioral properties of the Block. The JSON Schema content of the behavioral property Operation is as Figure 6 shown:

[0071] Model with the operations field. The operations field is a collection of Operation objects, used to describe the functional behavior or service interface of the module. The collection of Operation objects can be empty. If the collection of Operation objects is empty, it means that the module does not contain active behavior; the operations field includes @id, @type, name, visibility control field (visibility), and a collection of method parameters (parameters);

[0072] The supported values of the visibility control field include public, private, and protected, defined by the enumeration type VisibilityKind, used to control the access scope of the operation during system modeling;

[0073] Each parameter in the collection of method parameters is a Parameter object, used to define the specific characteristics of the input and output required by the operation. The parameter supports defining a name, direction (such as in, out, inout), and data type.

[0074] [[ID=2I]]S4: Enrich the data structure and association mechanism, introduce elements such as Attribute, Parameter, Association, AssociationBlock, and ValueType to enhance the model's ability to express complex systems (complex system structure, parameter passing, association relationship, and custom data type);

[0075] The S4 includes the following steps:

[0076] S401: Introduce the Attribute element as a component unit for system modeling, used to describe the attribute members inside the module. The JSON Schema content is as Figure 7As shown in the figure. The Attribute element includes fields such as @id, name, visibility, hrefId, aggregation, association, lowerValue, and upperValue;

[0077] hrefId is used to target the element reference identifier in the XMI standard, indicating a reference to other model elements;

[0078] aggregation represents the aggregation type of the attribute. The clustering types include:

[0079] none, which means there is no aggregation relationship and represents a normal reference attribute;

[0080] shared, which is a shared aggregation, indicating that multiple modules share the type pointed to by this attribute;

[0081] composite, which is a composition relationship and a strong ownership relationship, indicating that the type pointed to by this attribute is completely included in the current module and has the same lifecycle as the parent module.

[0082] association is a reference field of Identified, indicating the association relationship in which this attribute participates;

[0083] lowerValue and upperValue respectively represent the lower and upper bounds of the multiplicity of the attribute, which are used to limit the quantity range in which this attribute exists and support the modeling of set-like attributes;

[0084] S402: Introduce the Parameter element as a component unit for system modeling, which is used to enhance the capabilities of the system model in terms of parameter expression, value transmission, and constraint modeling. Its JSON Schema content is as Figure 8 shown. The Parameter element includes fields such as @id, @type, defaultType, defaultValue, name, and visibility;

[0085] S403: Introduce the Association element, which is used to express the ordinary association relationship between model elements to enhance the capabilities of the system model in expressing complex system structures and relationships between elements. Its JSON Schema design is as Figure 9 shown. The Association element includes fields such as @id, @type, name, and the memberEnds array. The memberEnds array represents the two endpoints participating in the association relationship (the number of endpoints is strictly 2). Each endpoint references the unique identifier of a module element in the model through the idref field, and the idref field is used to define the participants in the association;

[0086] S404: Selectively introduce the ownedEnds element from the Attribute element, which represents the endpoint attributes directly owned by this association, support direct connection value types, and are used to simplify the definition of association attributes in the modeling process;

[0087] S405: Introduce the AssociationBlock element that extends on the basis of the Association element, which is used to express the relationship of modeling an association class with attributes. That is, when modeling the relationship between two or more elements, it can also attach attribute and operation information to form a structured and semantically clear relationship expression. Its JSON Schema design is as Figure 10 shown. The AssociationBlock element includes fields such as @id, @type, values, operations, and an array of memberEnds;

[0088] The memberEnds array represents the endpoints connected by the association relationship, which are two model elements. Each endpoint points to the corresponding model element through its idref field;

[0089] The values field represents the set of attributes attached to the association relationship itself. Each attribute combination conforms to the definition of Attribute and supports embedding defaultType and defaultValue to refine the type and initial value of the attribute;

[0090] The operations field represents the dynamic behavior logic of the association relationship class;

[0091] S406: Introduce the ValueType element, which is used to customize reusable data types and support modeling expressions in the form of structures and enumerations. Its JSON Schema design is as Figure 11 shown. The ValueType element includes fields such as @id, @type, name, an isEnumeration boolean field, and a literals field / properties field;

[0092] The isEnumeration boolean field is used to distinguish whether the current ValueType element is an enumeration type or a structure type;

[0093] The enumeration type defines enumeration items through the literals field, which is valid when isEnumertion = true, and defines all the enumeration items included in this type. Each enumeration item includes @id and name fields, representing the unique identifier and human-readable name.

[0094] The structure type defines composite attributes through the properties field, which is effective when isEnumeration = false. It defines multiple attribute items included in this type. Each attribute references the Attribute type and supports setting default values, so as to express a composite structure with initial values.

[0095] S5: Use JSON Schema to perform legality verification on the graph model tree defined by the system modeling language module expressed in JSON, ensuring the structural compliance, field integrity, and data consistency of the model.

[0096] The said S5 includes the following steps:

[0097] S501: Generate JSON instances according to the defined JSON Schema. Each instance represents a component in a system modeling language model, and each instance complies with the rules specified in the Schema; the generated JSON instances include data of various SysML components, and the constraints in the Schema are used to ensure the consistency of the data type and structure.

[0098] S502: Use a JSON Schema validation tool to perform legality verification on the generated JSON instances. The core of the verification is to check whether the model instances meet the requirements of the predefined Schema, ensuring that the structure of each component is correct, the fields are not missing, and the data complies with the type constraints; for example, each component in the model must include the necessary fields defined, such as @id, @type, name, and at the same time, the data type of the fields must also meet the requirements, such as string, integer. For some fields with specific data format requirements (such as the defaultValue field), the validation tool checks whether its value conforms to the expected format.

[0099] S503: Obtain the verification result.

[0100] If the JSON instance passes the verification, it can be ensured that the instance is legal and conforms to the expected structure. This means that the generated SysML model data is valid and can be used without obstacles in subsequent model processing, analysis, and operations. If a certain instance fails to pass the verification, the validation tool will return an error message, and then locate and correct the problem to ensure the quality of the model data.

[0101] By adopting the JSON object structure, the present invention can effectively organize model elements, ensure clear model hierarchy, and facilitate management and understanding. The JSON-based representation has good generality, which is convenient for integration with other systems and tools, supports flexible expansion and application of the model. It can better support the webization of SysML tools, enhance the circulation and sharing of models among different platforms, promote cross-domain collaboration, and has broad application prospects.

[0102] For those skilled in the art, it is obvious that the present invention is not limited to the details of the above exemplary embodiments, and the present invention can be implemented in other forms without departing from the spirit or basic characteristics of the present invention. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting. The scope of the present invention is defined by the appended claims rather than the above description. Therefore, all changes falling within the meaning and scope of the equivalent conditions of the claims are intended to be encompassed within the present invention. Any reference signs in the claims should not be construed as limiting the claims involved.

[0103] In addition, it should be understood that although this specification is described according to embodiments, not every embodiment only contains an independent technical solution. This narrative way of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for representing a graph model tree of a JSON-based system modeling language module definition, characterized in that: The method includes the following steps: S1: Define the model tree structure, use a JSON object as the root node of the model, and set packages and blocks as top-level attributes; S2: Define Package elements and Block elements, use Package elements and Block elements as basic modeling container units, support nested structures, ensure the uniqueness of each element, and label the type for each element; S3: Design the structural attributes and behavioral attributes of the Block module; S4: Enrich the data structure and association mechanism to enhance the model's ability to express complex systems; S5: Use JSON Schema to perform legal validation on the graph model tree defined by the system modeling language module expressed in JSON, ensuring the structural compliance, field integrity, and data consistency of the model.

2. A method for representing a graph model tree of a JSON-based system modeling language module definition according to claim 1, characterized in that: The model tree described in S1 adopts a hierarchical organization form of key-value pairs to construct the basic framework of the model.

3. A method for representing a graph model tree of a JSON-based system modeling language module definition according to claim 2, characterized in that: The packages and blocks of the top-level attributes described in S1 are both of array type, and each array item references the externally defined Package and Block structures through $ref to achieve hierarchical nesting and structured organization of the modules.

4. A method for representing a graph model tree of a JSON-based system modeling language module definition according to claim 1, characterized in that: The Package element described in S2 supports a nested structure, including name, sub-packages, modules, association relationships, associated blocks, and value type fields.

5. A method for representing a graph model tree of a JSON-based system modeling language module definition according to claim 4, characterized in that: The Block element described in S2 is the core structure modeling unit, including name, abstract attribute, conjugate attribute, composition relationship, reference relationship, value attribute, and operation method fields.

6. A method for representing a graph model tree of a JSON-based system modeling language module definition according to claim 5, characterized in that: The said S3 includes the following steps: S301: Design the structural attributes of the Block: S30101: Design the composition relationship field as an array of Attribute objects, representing the composition structure relationship of the module, used to describe the sub-modules or component attributes included in the module. If the composition relationship field is an empty set, it means that the module is an atomic module or has no sub-modules; S30102: Design the reference relationship field as an array of Attribute objects, used to describe the reference relationship of the module to external modules or interfaces; S30103: Design the value attribute field as an array of Attribute objects, used to describe the value type attributes held locally by the module. Each value type attribute supports basic data types and reference types, and each value type attribute selectively configures default type fields and default value fields to support static parameter definition or runtime parameter initialization; S30104: Design the abstract attribute field as a boolean type field, used to identify whether the module is an abstract definition. When the value is true, it means that the module cannot be directly instantiated and is only used to provide general structure or behavior definitions; S30105: Design the conjugate attribute field as a boolean type field, used to indicate whether the module is a conjugate module; S302: Design the behavioral attributes of the Block: Modeling is performed with the operation method field. The operation method field is a collection of Operation objects, which is used to describe the functional behavior or service interface of a module. The collection of Operation objects can be empty. If the collection of Operation objects is empty, it means that the module does not contain active behavior. The operation method field includes @id, @type, name, visibility control field, and a collection of method parameters. The visibility control field is defined by the enumeration type VisibilityKind and is used to control the access scope of operations during system modeling. Each parameter in the collection of method parameters is a Parameter object, which is used to define the specific characteristics of the input and output required by the operation.

7. A method for representing a graph model tree of a JSON-based system modeling language module definition according to claim 6, characterized in that: S4 includes the following steps: S401: Introduce the Attribute element as a component unit for system modeling, which is used to describe the attribute members inside the module. S402: Introduce the Parameter element as a component unit for system modeling, which is used to enhance the system model's capabilities in parameter expression, value passing, and constraint modeling. S403: Introduce the Association element, which is used to represent the general association relationship between model elements, so as to enhance the system model's ability to express complex system structures and relationships between elements. S404: Optionally introduce the ownedEnds element from the Attribute element, which represents the end-point attributes directly owned by this association, supports directly connecting value types, and is used to simplify the definition of association attributes during modeling. S405: Introduce the AssociationBlock element, which is an extension based on the Association element and is used to express the relationship of an association class with attributes during modeling. S406: Introduce the ValueType element, which is used to customize reusable data types and supports modeling expressions in the form of structures and enumerations.

8. A method for representing a graph model tree of a JSON-based system modeling language module definition according to claim 7, characterized in that: S5 includes the following steps: S501: Generate JSON instances according to the defined JSON Schema. Each instance represents a component in the system modeling language model, and each instance conforms to the rules specified in the Schema. S502: Use the JSON Schema validation tool to perform a legality check on the generated JSON instances. S503: Obtain the verification result.

Images