A method for automatic layout for SysML multi-diagrams

Abstract

The application discloses a kind of automatic layout methods for SysML multi-diagram, it is related to model-driven engineering, graph layout algorithm, SysML modeling tool and automatic drawing technical field, including obtaining the graph kind identification of chart to be laid out, node list, edge list and layout context;In the layout strategy set containing the layout strategy of multiple graph kind, the corresponding layout strategy is selected;Call general graph layout engine, based on the selected layout strategy, perform initial layout on ordinary graph kind;According to the selected layout strategy, special graph kind is executed graph kind specificity post-processing;The coordinates and size obtained after layout are written back as graph element boundary data, and the layout result containing graph element coordinates and size is returned.The application enables system to automatically select adaptive layout strategy according to chart type, and carries out post-processing to container, lane, port, nested state and other special structures after layout, so as to generate graph element coordinates and size information that can be directly used.

Description

Technical Field

[0001] This invention relates to the fields of model-driven engineering, graphic layout algorithms, SysML modeling tools and automatic drawing technology, and specifically to an automatic layout method for multiple SysML graphics. Background Technology

[0002] In SysML modeling scenarios, even after model elements and relationships have been created, diagrams often require manual dragging and dropping to achieve a readable layout. Different diagram types have significant structural differences. For example, BDD emphasizes hierarchy and inheritance; ACT includes swimlanes, control flow, and start / end nodes; IBD and parametric graphs have edge ports; STM has nested states and regions; and bag graphs contain containers within containers. Using a single layout algorithm for all types of graphics can easily lead to the following problems: (1) Overlapping of primitives A unified algorithm struggles to accommodate the semantic features of different graph types. For example, if an inheritance tree structure is arranged in a regular grid, the parent-child relationship will be unclear; if a swimlane graph is not grouped by swimlanes, nodes will be misaligned across swimlanes.

[0003] (2) Insufficient container size Container elements such as grouped states, wrappers, and swimlanes need to dynamically expand their size based on their internal content. If fixed width and height are still used, the internal elements are prone to overflowing the boundaries.

[0004] (3) The port is detached from the parent node boundary In IBD and parametric graphs, ports should typically be attached to the boundary of their parent node. If a port is directly used as a regular node in the layout, it may float in the center of the canvas, disrupting the graph's semantics.

[0005] (4) The content of the lanes overlaps with the title. In an activity diagram, an ActivityPartition is not only a container but also contains swimlane titles. If no header area is reserved during layout, nodes within the swimlane will overlap with the titles.

[0006] (5) The content of the nested state exceeds the boundary of the parent state. State machine diagrams support internal regions and nested child states. If the child states are not laid out first and the size of the parent state is not adjusted in reverse, the parent state cannot correctly wrap the internal content.

[0007] (6) The workload of manual post-processing is large. Without map-specific post-processing, modelers still need to manually drag elements, adjust container sizes, and arrange port positions, limiting the value of automatic layout.

[0008] Therefore, an automatic layout scheme for multiple SysML map types is needed, which can automatically select a strategy based on the map type and perform differentiated post-processing on special primitives. Summary of the Invention

[0009] To address the aforementioned shortcomings in existing technologies, this invention provides an automatic layout method for multiple SysML graph types. This method enables the system to automatically select an appropriate layout strategy based on the graph type and to perform post-processing on special structures such as containers, swimlanes, ports, and nested states after layout, thereby generating directly usable primitive coordinates and size information.

[0010] To achieve the above-mentioned objectives, the technical solution adopted by this invention is: an automatic layout method for multiple SysML graphs, comprising the following steps: S1: Obtain the chart type identifier, node list, edge list, and layout context of the chart to be laid out; S2: Based on the graphic type identifier, select the corresponding layout strategy from the layout strategy set that includes multiple graphic type layout strategies; S3: Call the general graph layout engine and perform initial layout on ordinary graphs based on the selected layout strategy; S4: Perform type-specific post-processing on special map types according to the selected layout strategy; S5: Write back the coordinates and dimensions obtained after the layout is completed as element boundary data, and return the layout result containing element coordinates and dimensions.

[0011] Furthermore, step S2 includes the following sub-steps: S21: Convert the input map type identifiers into standard enumeration values ​​within the system to complete the standardization of map type identifiers; S22: Map the standardized map type identifiers to the corresponding policy class instances through the policy registry; S23: Call the support method of the selected strategy for secondary confirmation. If the current strategy does not support it, it will be downgraded to the default layout strategy. S24: Detect special markers in the node list and enhance the selected strategy based on the detection results; The enhancement of the selected strategy includes: if a node contains proxy ports or constraint parameter type primitives, overlaying port edge processing logic on the basis of the current strategy; if a node contains swimlane primitives, forcibly switching to the active graph layout strategy and enabling swimlane post-processing logic; if a node has a parent-child nesting relationship, enabling container size automatic expansion logic.

[0012] Furthermore, the set of layout strategies in S2 includes BDD layout strategy, ACT layout strategy, IBD layout strategy, STM layout strategy, package graph layout strategy, parameter graph layout strategy, requirement graph layout strategy, and use case graph layout strategy.

[0013] Furthermore, in S4, special post-processing is performed on special graph types. The post-processing includes: performing post-processing to center the parent node above the child node for BDD graphs; performing post-processing to group and translate swimlanes for ACT graphs; performing post-processing to attach ports to the parent node boundary for IBD graphs and parametric graphs; performing post-processing to perform bottom-up nested state layout and parent state container size expansion for STM graphs; and performing bottom-up container size calculation for bag graphs.

[0014] Furthermore, the post-processing of centering the parent node above the child node in the BDD graph includes: Construct a parent-child relationship tree based on the inheritance edges; Assign levels to nodes in the tree; Traverse the parent nodes from the deepest level upwards, aligning the center point of the parent node above the average of the center points of all its child nodes.

[0015] Furthermore, the post-processing of performing lane grouping and translation on the ACT graph includes: Identify the activity graph partition nodes as swimlanes, and assign them to the corresponding swimlanes based on the parent identifiers of the remaining activity nodes; Perform initial layout on all active nodes; Calculate the grouping boundaries of nodes within each lane; The dimensions of each lane container are calculated based on the grouping boundaries and the predefined lane inner margins and title area height. All nodes within each lane are translated as a whole into the corresponding lane container.

[0016] Furthermore, the post-processing of attaching the port to the parent node boundary of the IBD graph and the parametric graph includes: Remove the port nodes from the set of ordinary nodes and perform layout only on the set of main nodes; Based on the parent identifier of the port node, the port node is assigned to its parent node; Align the port node with the parent node's bounding box and attach it to the parent node's bounding box.

[0017] Furthermore, the post-processing of performing nested state bottom-up layout and parent state container size expansion on the STM graph includes: Nested states are identified based on parent-child relationships and region identifiers; For a parent state containing child nodes, recursively lay out its deepest child nodes; Group child nodes by region, calculate the region content boundary, and translate the entire region into the parent state container; The size of the parent state container is expanded in reverse order by adding a predefined header height and inner margin to the boundaries of the child state content.

[0018] Furthermore, the post-processing of performing bottom-up container size calculation on the package map includes: Calculate the size of each leaf node recursively; Perform grid layout estimation on the sub-package content, and calculate the total width and total height of the sub-content; Add the predefined header area height and container inner margins to the total width and height of the child content to obtain the estimated width and estimated height of the parent container.

[0019] An automatic layout system for multiple SysML drawing types includes: The image data acquisition module is used to obtain the image type identifier, node list, edge list and layout context of the image to be laid out; The layout strategy selection module is used to select the corresponding layout strategy from a set of layout strategies that includes multiple layout strategies for different types of graphics based on the graphic type identifier. The general layout engine adaptation module is used to call the general graph layout engine and perform initial layout on ordinary graphs based on the selected layout strategy. The map type-specific post-processing module is used to perform map type-specific post-processing on special map types according to the selected layout strategy. The boundary data write-back and result output module is used to write back the coordinates and dimensions obtained after the layout is completed as element boundary data and return the layout result containing element coordinates and dimensions.

[0020] The beneficial effects of this invention are: (1) Strong map type adaptability: Different strategies are adopted for different map types to avoid “using the same standard to measure all maps”.

[0021] (2) Reduce manual dragging: The system directly generates readable layouts, reducing the cost of manual layout after modeling.

[0022] (3) Container primitives are more stable: Special primitives such as swimlanes, state containers, package containers and ports can be correctly wrapped or attached.

[0023] (4) Supports automatic bounds writing: The layout result can be directly used for front-end rendering.

[0024] (5) Support strategy extension: New map layouts can be added through the unified strategy interface. Attached Figure Description

[0025] Figure 1 This is a flowchart of an automatic layout method for multiple SysML drawing types. Detailed Implementation

[0026] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0027] like Figure 1 As shown, an automatic layout method for multiple SysML graphs includes the following steps: S1: Obtain the chart type identifier, node list, edge list, and layout context of the chart to be laid out; The node list includes information such as element identifier, element type, parent node identifier, region identifier, estimated width, and estimated height; the edge list includes source node identifier, target node identifier, and edge type; and the layout context includes the default width and height of nodes, horizontal spacing, vertical spacing, and margin parameters.

[0028] S2: Based on the graphic type identifier, select the corresponding layout strategy from the layout strategy set that includes multiple graphic type layout strategies; The set of layout strategies includes at least: BDD layout strategy, ACT layout strategy, IBD layout strategy, STM layout strategy, package diagram layout strategy, parametric diagram layout strategy, requirement diagram layout strategy, and use case diagram layout strategy.

[0029] In some embodiments, the specific implementation logic of the strategy selection is as follows: S21: Convert the input map type identifiers into standard enumeration values ​​within the system to complete the standardization of map type identifiers; The system first converts the input chart type identifier (diagramType) into a unified internal standard enumeration value. For example: SysMLBlockDefinitionDiagram→BDD SysMLActivityDiagram→ACT SysMLInternalBlockDiagram→IBD SysMLStateMachineDiagram→STM SysMLPackageDiagram→PKG SysMLParametricDiagram→PARAM SysMLRequirementDiagram→REQ SysMLUseCaseDiagram→UC S22: Map the standardized map type identifiers to the corresponding policy class instances through the policy registry; The system maintains a strategy registry, mapping each map identifier to a corresponding strategy class instance. The selector determines the target strategy by looking up the table. public ILayoutStrategy selectStrategy(String diagramType) { DiagramType normalized = normalizeDiagramType(diagramType); ILayoutStrategy strategy = registry.get(normalized); if (strategy == null) { / / Unknown map type reverts to default ELK layered layout return new DefaultElkLayoutStrategy(); } return strategy; } S23: Call the support method of the selected strategy for secondary confirmation. If the current strategy does not support it, it will be downgraded to the default layout strategy. After selecting a specific strategy, the system calls the strategy's `supports()` method for secondary confirmation, ensuring that the strategy can handle the node and edge features of the current graph. If the current strategy does not support it (for example, the BDD strategy encounters an exception containing an ActivityPartition node), it will downgrade to the default ELK strategy.

[0030] In one embodiment, the system defines a unified layout strategy interface ILayoutStrategy, which includes at least: supports(String diagramType): Used to determine whether a strategy supports the current diagram type; layout(List <layoutnode>nodes,List <layoutedge>edges, LayoutContextContext): Used to perform layout and return a list of nodes containing the bounds.

[0031] In some embodiments, the unified interface described above serves to: decouple the map type recognition logic from the specific layout algorithm; allow different map types to implement different post-processing logic; and facilitate the subsequent expansion of new map type strategies.

[0032] S24: Detect special markers in the node list and enhance the selected strategy based on the detection results; The enhancement of the selected strategy includes: if a node contains proxy ports or constraint parameter type primitives, overlay port edge processing logic on the basis of the current strategy; if a node contains swimlane primitives, force a switch to the active graph layout strategy and enable swimlane post-processing logic; if a node has a parent-child nesting relationship, enable container size automatic expansion logic.

[0033] In some embodiments, after policy selection, the system also detects special markers in the node list to determine whether to enhance the basic policy: If the node contains elementType=="ProxyPort" or elementType=="ConstraintParameter", then port edge-fitting processing will be added on top of the selected strategy. If a node contains elementType == "ActivityPartition", then the ACT strategy will be forced and swimlane post-processing will be enabled. If nested relationships exist among nodes (i.e., a node's parentId points to another node), then the automatic container size expansion logic is enabled.

[0034] S3: Call the general graph layout engine to perform initial layout on ordinary graphs based on the selected layout strategy; The general graph layout engine is invoked to perform the initial layout for ordinary graph types. The general graph layout engine preferably adopts the ELK layered layout engine, which can be configured to use the org.eclipse.elk.layered algorithm, and the layout direction is from top to bottom.

[0035] In one embodiment, the system uses an ELK adapter layer as a general layout engine. The adapter layer converts nodes and edges into an ELK graph model, configures the hierarchical layout algorithm, orientation, node spacing, hierarchy spacing, and edge spacing, and writes back the node coordinates and dimensions after the layout is completed.

[0036] In one embodiment, the ELK adapter layer defines the complete field mapping from the internal data structure to the ELK graph model. The mapping rules are as follows: (1) The mapping rules of LayoutNode→ElkNode are shown in Table 1.

[0037] Table 1 Mapping Rules for LayoutNode→ElkNode

[0038] (2) The mapping rules of LayoutEdge→ElkEdge are shown in Table 2.

[0039] Table 2 LayoutEdge→ElkEdge Mapping Rules

[0040] (3) LayoutContext→ELK global configuration mapping rules, as shown in Table 3.

[0041] Table 3 LayoutContext→ELK Global Configuration Mapping Rules

[0042] (4) ELK processing rules for special primitives: ActivityPartition (swimlane): In ELK, it participates in the initial layout as a regular node to obtain global position information, but it does not serve as the parent container for other nodes. The bounds of the swimlane container are recalculated in the post-processing stage based on the positions of its internal nodes; ProxyPort / ConstraintParameter (Port): Excluded during the ELK mapping phase (no corresponding ElkNode is created) to avoid interfering with the main node layout result. The port coordinates are calculated independently and attached to the parent node boundary during post-processing. Nested State (Composite State): In ELK, only the outermost state's ElkNode is created, and the layout of inner child states and regions is handled separately by bottom-up logic.

[0043] In some embodiments, the ELK adapter layer performs the following steps: Step 1: Create the root node Create an ELK root node to hold all nodes to be laid out.

[0044] Step 2: Configure layout algorithm and global parameters According to the LayoutContext→ELK global configuration mapping rules described above, set parameters such as algorithm type, direction, and spacing.

[0045] Step 3: Create ELK nodes and edges according to the mapping rules Traverse the input list of nodes and edge lists, and create ElkNode and ElkEdge one by one according to the above field mapping rules to build a complete ELK graph model.

[0046] Step 4: Execute the layout Call RecursiveGraphLayoutEngine.layout() to perform the layout.

[0047] Step 5: Write back coordinates and dimensions Write back the x, y, width, and height of the ElkNode to the bounds of the LayoutNode according to the reverse mapping rules.

[0048] S4: Perform type-specific post-processing on special map types according to the selected layout strategy; For special graph types, perform graph-specific post-processing, including: performing post-processing to center the parent node above the child node for BDD graphs, performing swimlane grouping and translation for ACT graphs, performing post-processing to attach the port to the parent node boundary for IBD graphs and parametric graphs, performing post-processing to perform nested state bottom-up layout and parent state container size expansion for STM graphs, and performing bottom-up container size calculation for bag graphs.

[0049] The post-processing of centering the parent node above the child node in the BDD graph includes: Construct a parent-child relationship tree based on the inheritance edges; Assign levels to nodes in the tree; Traverse the parent nodes from the deepest level upwards, aligning the center point of the parent node above the average of the center points of all its child nodes.

[0050] In one embodiment, the BDD (Block Definition Diagram) layout strategy prioritizes ELK hierarchical layout while retaining the traditional backoff algorithm.

[0051] In some embodiments, when ELK is enabled, the system directly calls the general layout engine, placing the parent class at the top and the child class at the bottom.

[0052] In some embodiments, when falling back to the traditional algorithm, the layout process includes: Step 1: Distinguish between Requirement and Block areas Nodes are divided into Requirement type nodes and non-Requirement type nodes. The Requirement area is placed on the right, and the Block area is placed on the left.

[0053] Step 2: Construct parent-child relationships based on generalization edges Iterate through the edge list. If the edge type is Generalization, treat sourceId as a child node and targetId as a parent node, and create childToParentMap and parentToChildrenMap.

[0054] Step 3: Identify the root node and independent nodes Find the root node within the region that is not a child node, and separate nodes with inheritance relationships from independent nodes.

[0055] Step 4: Perform tree layout on nodes with inheritance relationships. Assign levels to nodes in the tree. Level 0 is the root node, level 1 is its child nodes, and so on. Each level is arranged with a fixed horizontal spacing.

[0056] Step 5: Perform mesh layout on individual nodes For independent nodes without inheritance relationships, arrange them in a grid with a column count of ceil(sqrt(n)).

[0057] Step 6: Perform parent node centering optimization Traverse the parent nodes from the deepest level upwards, aligning the center of the parent node above the average of the center points of all its child nodes.

[0058] This post-processing significantly improves the readability of the inheritance tree, making the parent class naturally positioned above the child class center.

[0059] The post-processing of performing lane grouping and translation on the ACT graph includes: Identify the activity graph partition nodes as swimlanes, and assign them to the corresponding swimlanes based on the parent identifiers of the remaining activity nodes; Perform initial layout on all active nodes; Calculate the grouping boundaries of nodes within each lane; The dimensions of each lane container are calculated based on the grouping boundaries and the predefined lane inner margins and title area height. All nodes within each lane are translated as a whole into the corresponding lane container.

[0060] In one embodiment, the ACT (Activity Diagram) layout strategy adopts a two-stage approach of "first global layout, then swimlane wrapping".

[0061] In some embodiments, the system first identifies ActivityPartition as a swimlane node, and the remaining nodes as active nodes.

[0062] In some embodiments, the layout process includes: Step 1: Group activities by lane Nodes are assigned to their corresponding swimlanes based on their parentId. If a node does not belong to any swimlane, it is assigned to the "no swimlane node set".

[0063] Step 2: Perform ELK global layout on all active nodes. First, involve all active nodes in the ELK layout to obtain the global hierarchical relationship and relative position.

[0064] Step 3: Handling swimlane-less nodes Align all swimlane-less nodes to the left and move them down below the uniform top margin TOP_PADDING.

[0065] Step 4: Calculate the dimensions of the lane containers Calculate groupBounds for each node within a lane, and then calculate the lane container size using the following parameters: PARTITION_PADDING=30; PARTITION_HEADER_HEIGHT=25; TOP_PADDING = 60 - GROUP_GAP= NODE_SPACING * 3.

[0066] The width of a swimlane should be at least the width of the internal node plus the left and right padding, and the height of a swimlane should be at least the height of the internal node plus the top title area and the top and bottom padding.

[0067] Step 5: Move the entire node inside the lane into the container. Based on the difference between the top left corner of the swimlane container and the groupBounds position, perform a translation on all nodes within the swimlane.

[0068] This method avoids the misalignment problem caused by "layout and wrapping" and ensures that the swimlane title area does not overlap with the internal nodes.

[0069] The post-processing of attaching the port to the parent node boundary of the IBD graph and parametric graph includes: Remove the port nodes from the set of ordinary nodes and perform layout only on the set of main nodes; Based on the parent identifier of the port node, the port node is assigned to its parent node; Align the port node with the parent node's bounding box and attach it to the parent node's bounding box.

[0070] In one embodiment, both the IBD (Internal Block Diagram) and the parameter graph adopt a two-stage method of "laying out the main node first and then attaching the port to the edge".

[0071] In some embodiments, the system first identifies port-type nodes, such as ProxyPort or ConstraintParameter, and separates them from the set of ordinary nodes.

[0072] In some embodiments, the layout process includes: Step 1: Separate the master node and the port node Treat non-port nodes as the set of master nodes, and perform ELK layout only on the master nodes and the edges between them.

[0073] Step 2: Execute the master node layout The ELK hierarchical layout engine is invoked to perform automatic layout on the main node.

[0074] Step 3: Group ports by parent node Based on the parentId of the port node, the port node is assigned to its parent node.

[0075] Step 4: Attach the port to the parent node boundary Based on the parent node's bounds, align the port to the left or right or top and bottom boundaries of the parent node. For ROOT ports, they can be attached to the canvas boundaries.

[0076] Port nodes do not participate in the main layout, which can prevent ports from scattering the layout of the main nodes, while ensuring that ports still meet the requirements of graph semantics.

[0077] In some embodiments, the coordinates of the port attached to the parent node boundary are calculated as follows: Let the parent node's bounds be... This parent node has a total of One port, port size is Then the first Ports ( coordinates for:

[0078] In some embodiments, for the ROOT port (attached to the canvas boundary), coordinates The calculation method is as follows:

[0079] in, This represents a constant canvas margin. Indicates the first The Y-coordinate and height of each master node.

[0080] In some embodiments, the port edge-fitting strategy ensures that ports are evenly distributed on the right boundary of the parent node and do not overlap with other ports.

[0081] The post-processing of performing nested state bottom-up layout and parent state container size expansion on the STM graph includes: Nested states are identified based on parent-child relationships and region identifiers; For a parent state containing child nodes, recursively lay out its deepest child nodes; Group child nodes by region, calculate the region content boundary, and translate the entire region into the parent state container; The size of the parent state container is expanded in reverse order by adding a predefined header height and inner margin to the boundaries of the child state content.

[0082] In one embodiment, the STM (State Machine Diagram) layout employs a bottom-up layout with nested states.

[0083] In some embodiments, the system first identifies the parent-child relationship based on parentId and identifies the Region group based on regionId.

[0084] In some embodiments, the layout process includes: Step 1: Identify top-level nodes and nested nodes If a node's parentId is empty or its parent node does not exist, it is considered a top-level node; otherwise, it is considered a nested node.

[0085] Step 2: Recursively lay out the deepest child nodes For each parent state containing child nodes, first recursively lay out its deepest child nodes.

[0086] Step 3: Group and lay out child nodes by Region Group the child nodes by regionId, and call ELK to perform local layout for each group.

[0087] Step 4: Calculate the content boundaries of the Region and translate it entirely. Calculate the bounds for each Region, and translate all nodes within that Region into the parent state container, reserving: COMPOSITE_STATE_HEADER_HEIGHT = 25; COMPOSITE_STATE_PADDING = 30; and REGION_GAP = 20.

[0088] Step 5: Expand the parent state size in reverse order based on the child state content. The new width and height of the parent state are at least equal to the width and height of the internal content plus the space occupied by padding and header.

[0089] Step 6: Finally, arrange the top-level nodes. Once all nested states are complete, perform ELK layout on the top-level node.

[0090] This bottom-up approach ensures that the parent state container completely encloses the internal Region and child state contents.

[0091] In some embodiments, the size of the STM combination state is calculated in reverse based on the internal Region content: Suppose that in a certain combination state there is There are *n* Regions, and the bounds of each Region after layout are... , :

[0092] in, This represents the maximum width of the content margins after layout for each Region. The total height of the content is the sum of the heights of all Region contents and the spacing between Regions. The width after the combined state is updated. The height after the combined state is updated. The original estimated width for the combined state. The original estimated height for the combined state, Indicates the inner margin of the combined state. Indicates the height of the combined state title area. Indicates the region spacing.

[0093] The post-processing for performing bottom-up container size calculations on the package map includes: Calculate the size of each leaf node recursively; Perform grid layout estimation on the sub-package content, and calculate the total width and total height of the sub-content; Add the predefined header area height and container inner margins to the total width and height of the child content to obtain the estimated width and estimated height of the parent container.

[0094] In one embodiment, the package graph layout does not rely on ELK, but instead uses a container tree that expands from bottom to top.

[0095] In some embodiments, the layout process includes: Step 1: Recursively calculate the size of each leaf node Leaf nodes use either estimated or default sizes.

[0096] Step 2: Perform grid layout estimation on the contents of the sub-packages. Calculate the number of grid columns and rows based on the number of child nodes, and accumulate the width and height of each row.

[0097] Step 3: Combine header and padding to obtain the size of the parent container. Add the title area and container margins to the total width and height of the child content to obtain the estimatedWidth and estimatedHeight of the parent container.

[0098] Step 4: Sort the top-level packages by name and arrange them as a whole. The top-level packages are sorted by name and then laid out from left to right or in a grid pattern.

[0099] This method is suitable for nested package scenarios and can ensure that the size of the package container automatically grows with the internal content.

[0100] In some embodiments, the size of the package diagram container is calculated from bottom to top as follows: Suppose a certain container has Number of child nodes, number of grid columns The child nodes are sorted by name and then placed row by row. For each row... ( ),in Total number of rows:

[0101] in, The line width is the sum of the widths of all child nodes in the r-th row and their horizontal spacing. Let r be the maximum height of the child nodes in the r-th row. For the first The number of nodes in a row and The first row of the line is respectively The width and height of each child node, This is a constant for the horizontal spacing.

[0102] The total dimensions of the content and the final dimensions of the container are:

[0103] in, This represents the width of the content area inside the container. The height of the content area inside the container. Estimate the width of the container. Estimate the height of the container. This is the default width for the package node. This is the default height for the package node. , , , These represent the title area height, inner margin, horizontal spacing, and vertical spacing, respectively.

[0104] In some embodiments, the key parameters used in the layout strategies of each drawing type are shown in Table 4 below: Table 4 Key parameters used in layout strategies for each type of drawing

[0105] S5: Write back the coordinates and dimensions obtained after the layout is completed as element boundary data, and return the layout result containing element coordinates and dimensions.

[0106] Write back the coordinates and dimensions obtained from the layout as bounds for front-end rendering; return the layout result containing the coordinates and dimensions of the bounds for the chart generation module.

[0107] In one embodiment of the present invention, in order to illustrate the technical solution of this specification more specifically, a complete BDD layout embodiment is given below.

[0108] Input data: In some embodiments, the BDD graph to be laid out includes the following nodes and edges: The list of nodes (5 blocks) is shown in Table 5: Table 5 Node List

[0109] The edge list (4 Generalizations) is shown in Table 6: Table 6 Edge List

[0110] Layout context: nodeWidth=160, nodeHeight=100, horizontalGap=40, verticalGap=60, padding=20.

[0111] Execution process Step 1: Strategy Selection The diagram type is identified as SysMLBlockDefinitionDiagram, and the system selects BddLayoutStrategy.

[0112] Step 2: ELK Layout The system calls the ELK adaptation layer, configuring the org.eclipse.elk.layered algorithm, Direction.DOWN, node spacing of 80 (horizontalGap*2), and layer spacing of 60.

[0113] The ELK engine infers hierarchical relationships based on generalization edges: Layer 0: blk_001 (Vehicle System) Layer 1: blk_002 (Powertrain System), blk_003 (Chassis System) Layer 2: blk_004 (engine), blk_005 (transmission) Step 3: Output coordinates using ELK After ELK calculation, the coordinates of each node are output (illustrated), as shown in Table 7: Table 7 Outputs the coordinates of each node after ELK calculation

[0114] Step 4: Write back bounds The above coordinates, after adding padding offset, are written back to the bounds property of each node.

[0115] Output result: Once the layout is complete, the front end can directly use bounds to render the chart. The parent class (vehicle system) is located at the top center, the child classes (power system, chassis system) are located at the second level, and the grandchild classes (engine, transmission) are located at the third level, forming a clear inheritance tree structure.

[0116] This embodiment also provides a complete IBD diagram port edge-fitting process.

[0117] Input data: In some embodiments, the IBD diagram to be laid out includes the following nodes, as shown in Table 8: Table 8 IBD diagram contains nodes

[0118] Execution process: Step 1: Separation Master nodes: part_001, part_002. Port nodes: port_001, port_002, port_003.

[0119] Step 2: Master Node ELK Layout Perform ELK layout only on part_001 and part_002. Assume the result is: part_001: (50, 50, 200, 150); part_002: (350, 50, 200, 150).

[0120] Step 3: Port edge bonding port_001 is mounted under part_001, and part_001 has only one port: Spacing = 150 / (1 + 1) = 75 port_x = 50 + 200 - 20 / 2 = 240 port_y = 50 + 75 * 1 - 20 / 2 = 115 port_001 bounds = (240, 115, 20, 20) port_002 is mounted under part_002. Similarly, port_002 bounds = (540, 115, 20, 20). port_003 is the ROOT port, and it is attached to the left edge of the canvas: port_003 bounds = (0, 290, 20, 20).

[0121] Output result: The ports are correctly attached to the right boundary of their respective parent nodes, and the ROOT port is attached to the left boundary of the canvas, satisfying the semantics of the IBD graph.

[0122] An automatic layout system for multiple SysML drawing types includes: The image data acquisition module is used to obtain the image type identifier, node list, edge list and layout context of the image to be laid out; The layout strategy selection module is used to select the corresponding layout strategy from a set of layout strategies that includes multiple layout strategies for different types of graphics based on the graphic type identifier. The general layout engine adaptation module is used to call the general graph layout engine and perform initial layout on ordinary graphs based on the selected layout strategy. The map type-specific post-processing module is used to perform map type-specific post-processing on special map types according to the selected layout strategy. The boundary data write-back and result output module is used to write back the coordinates and dimensions obtained after the layout is completed as element boundary data and return the layout result containing element coordinates and dimensions.

[0123] Those skilled in the art will recognize that the embodiments described herein are intended to help the reader understand the principles of the invention, and should be understood that the scope of protection of the invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical teachings disclosed in this invention without departing from the spirit of the invention, and these modifications and combinations are still within the scope of protection of the invention.< / layoutedge> < / layoutnode>

Claims

1. An automatic layout method for multiple SysML drawing types, characterized in that, Includes the following steps: S1: Obtain the chart type identifier, node list, edge list, and layout context of the chart to be laid out; S2: Based on the graphic type identifier, select the corresponding layout strategy from the layout strategy set that includes multiple graphic type layout strategies; S3: Call the general graph layout engine and perform initial layout on ordinary graphs based on the selected layout strategy; S4: Perform type-specific post-processing on special map types according to the selected layout strategy; S5: Write back the coordinates and dimensions obtained after the layout is completed as element boundary data, and return the layout result containing element coordinates and dimensions.

2. The automatic layout method for multiple SysML maps according to claim 1, characterized in that, S2 includes the following steps: S21: Convert the input map type identifiers into standard enumeration values ​​within the system to complete the standardization of map type identifiers; S22: Map the standardized map type identifiers to the corresponding policy class instances through the policy registry; S23: Call the support method of the selected strategy for secondary confirmation. If the current strategy does not support it, it will be downgraded to the default layout strategy. S24: Detect special markers in the node list and enhance the selected strategy based on the detection results; The enhancement of the selected strategy includes: if a node contains a proxy port or a constraint parameter type primitive, overlaying port edge-fitting processing logic on the basis of the current strategy; If a node contains swimlane primitives, force a switch to the active graph layout strategy and enable swimlane post-processing logic; if nodes have parent-child nesting relationships, enable automatic container size expansion logic.

3. The automatic layout method for multiple SysML maps according to claim 1, characterized in that, The layout strategy set in S2 includes BDD layout strategy, ACT layout strategy, IBD layout strategy, STM layout strategy, package graph layout strategy, parametric graph layout strategy, requirement graph layout strategy, and use case graph layout strategy.

4. The automatic layout method for multiple SysML maps according to claim 1, characterized in that, In S4, special post-processing is performed on special graph types. The post-processing includes: centering the parent node above the child node for BDD graphs; performing swimlane grouping and translation for ACT graphs; attaching ports to the parent node boundary for IBD graphs and parametric graphs; performing bottom-up nested state layout and parent state container size expansion for STM graphs; and performing bottom-up container size calculation for bag graphs.

5. The automatic layout method for multiple SysML maps according to claim 4, characterized in that, The post-processing of centering the parent node above the child node in the BDD graph includes: Construct a parent-child relationship tree based on the inheritance edges; Assign levels to nodes in the tree; Traverse the parent nodes from the deepest level upwards, aligning the center point of the parent node above the average of the center points of all its child nodes.

6. The automatic layout method for multiple SysML maps according to claim 4, characterized in that, The post-processing of performing lane grouping and translation on the ACT graph includes: Identify the activity graph partition nodes as swimlanes, and assign them to the corresponding swimlanes based on the parent identifiers of the remaining activity nodes; Perform initial layout on all active nodes; Calculate the grouping boundaries of nodes within each lane; The dimensions of each lane container are calculated based on the grouping boundaries and the predefined lane inner margins and title area height. All nodes within each lane are translated as a whole into the corresponding lane container.

7. The automatic layout method for multiple SysML maps according to claim 4, characterized in that, The post-processing of attaching the port to the parent node boundary of the IBD graph and parametric graph includes: Remove the port nodes from the set of ordinary nodes and perform layout only on the set of main nodes; Based on the parent identifier of the port node, the port node is assigned to its parent node; Align the port node with the parent node's bounding box and attach it to the parent node's bounding box.

8. The automatic layout method for multiple SysML maps according to claim 4, characterized in that, The post-processing of performing nested state bottom-up layout and parent state container size expansion on the STM graph includes: Nested states are identified based on parent-child relationships and region identifiers; For a parent state containing child nodes, recursively lay out its deepest child nodes; Group child nodes by region, calculate the region content boundary, and translate the entire region into the parent state container; The size of the parent state container is expanded in reverse order by adding a predefined header height and inner margin to the boundaries of the child state content.

9. The automatic layout method for multiple SysML maps according to claim 4, characterized in that, The post-processing for performing bottom-up container size calculations on the package map includes: Calculate the size of each leaf node recursively; Perform grid layout estimation on the sub-package content, and calculate the total width and total height of the sub-content; Add the predefined header area height and container inner margins to the total width and height of the child content to obtain the estimated width and estimated height of the parent container.

10. A system for an automatic layout method for SysML multi-graph types as described in any one of claims 1-9, characterized in that, include: The image data acquisition module is used to obtain the image type identifier, node list, edge list and layout context of the image to be laid out; The layout strategy selection module is used to select the corresponding layout strategy from a set of layout strategies that includes multiple layout strategies for different types of graphics based on the graphic type identifier. The general layout engine adaptation module is used to call the general graph layout engine and perform initial layout on ordinary graphs based on the selected layout strategy. The map type-specific post-processing module is used to perform map type-specific post-processing on special map types according to the selected layout strategy. The boundary data write-back and result output module is used to write back the coordinates and dimensions obtained after the layout is completed as element boundary data and return the layout result containing element coordinates and dimensions.

Images