A method, system, device and medium for generating front-end code of an axure prototype

Abstract

The application is suitable for the computer technology field, and provides an Axure prototype front-end code generation method, which comprises the following steps: analyzing an Axure prototype, identifying and understanding the layout result and interaction logic of the Axure prototype, and generating a design intermediate representation; based on the design intermediate representation, combining a target project configuration, generating executable front-end source code through a code generation template; establishing an associated mapping between the design intermediate representation and the front-end source code, and synchronizing the changes between the design intermediate representation and the front-end source code. The application performs deep and multi-level semantic analysis on the Axure prototype for code generation, and the design intermediate representation is set to be cooperated with code generation and construction to break the process island, which is beneficial to code generation and synchronization.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method, system, device and medium for generating front-end code for an Axure prototype. Background Technology

[0002] Axure RP, as a mainstream product prototyping tool, can efficiently output HTML prototype files containing visual interfaces and basic interaction logic, playing a crucial role in design reviews and requirements confirmation. However, when it is necessary to convert this prototype file into front-end code that can be directly used in project development and has production-quality requirements, existing technical solutions face fundamental bottlenecks and significant shortcomings, specifically: (1) To achieve accurate visual reproduction, Axure prototypes generally use pixel-based absolute positioning technology to fix the position of each element. However, modern front-end development uses declarative responsive layout models such as Flexbox and CSS Grid to adapt to multiple devices. The two conflict in underlying logic, and developers need to spend a lot of time manually refactoring. (2) Interactive behaviors in Axure prototypes are defined by directly binding discrete, imperative event scripts to graphical elements. However, modern front-end frameworks such as React and Vue follow a state-driven declarative programming paradigm. Existing conversion tools can only perform shallow translation of interactive scripts and cannot automatically complete the paradigm shift and logical refactoring from "event-driven" to "state-driven". Therefore, they cannot generate clear and easy-to-maintain state management code. (3) Existing automated code generation solutions usually produce a large number of redundant, non-semantic HTML tags and hard-coded inline styles. The code structure is messy and violates the design principles of componentization and separation of concerns. It has poor readability, high maintenance costs, and is difficult to integrate directly into the modern front-end engineering development process based on modularization, version control, and continuous integration. (4) Existing code generation output is usually limited to raw HTML, CSS and JavaScript, and cannot dynamically generate component code that matches the syntax, ecosystem and best practices of the specific technology stack chosen by different development teams.

[0003] In conclusion, there is an urgent need for an intelligent method that can deeply understand the design intent of Axure prototypes, transform layout paradigms and refactor interaction logic, and output high-quality front-end code that is compatible with multiple frameworks. Summary of the Invention

[0004] This application provides a method, system, device, and medium for generating front-end code for an Axure prototype, which can solve one of the aforementioned problems in the prior art.

[0005] In a first aspect, embodiments of this application provide a method for generating front-end code for an Axure prototype, including: The Axure prototype is parsed to identify and understand its layout and interaction logic, and an intermediate design representation is generated. Based on the aforementioned intermediate design representation, and combined with the target project configuration, executable front-end source code is generated using a code generation template. Establish an association mapping between the intermediate design representation and the front-end source code, and synchronize changes between the intermediate design representation and the front-end source code.

[0006] Furthermore, the process of parsing the Axure prototype, identifying and understanding its layout and interaction logic, and generating an intermediate design representation includes: From the pixel-level representation of the Axure prototype, the layout information of the visual layer, structural layer, and intent layer is extracted layer by layer. Convert the event-driven interactive scripts in the Axure prototype into state-driven interactive information; Based on the layout information and the interaction information, an intermediate design representation is generated.

[0007] Furthermore, the step of extracting layout information of the visual layer, structural layer, and intent layer layer layer from the pixel-level representation of the Axure prototype includes: The pixel-level features of the Axure prototype are analyzed using computer vision algorithms to extract visual information, including visual grouping, alignment relationships, and spacing patterns. Perform DOM parsing and CSS style analysis on the HTML code of the Axure prototype to extract the structural information of the Axure prototype, including element hierarchy, positioning method and layout role; The designer's layout intent, component types, and interaction purposes can be inferred from the visual and structural information.

[0008] Furthermore, the process of converting event-driven interactive scripts in the Axure prototype into state-driven interactive information includes: The "trigger-condition-action" triples in the Axure interaction panel are parsed into basic interaction primitives, and the basic interaction primitives are deconstructed into a structured sequence of interaction primitives. Identify implicit state variables from the sequence of interaction primitives, and generate an event stream by analyzing the triggering order and triggering conditions of interaction events; Based on the interaction primitive sequence, the implicit state variables, and the event flow, a state change model is generated, and the state change model is converted into an interaction interface description, which includes state definitions, transition conditions, and side effect mappings.

[0009] Furthermore, based on the intermediate design representation and combined with the target project configuration, executable front-end source code is generated using a code generation template, including: Parse the target project configuration, determine the target technology stack of the project, and select the corresponding code generation adapter based on the target technology stack; The visual information of the intermediate design representation is mapped to design tokens, and style specifications are generated based on the target technology stack and the layout constraints of the intermediate design representation. The state change model of the intermediate design is mapped to the state management architecture of the target technology stack; Based on the code generation adapter, the style specification, and the state management architecture, source code is generated.

[0010] Furthermore, the generated source code includes template-driven generation and large model enhancement generation.

[0011] Furthermore, establishing the association mapping between the intermediate design representation and the front-end source code, and synchronizing changes between the intermediate design representation and the front-end source code, includes: Establish a bidirectional association mapping at the element level and the structure level between the intermediate representation of the design and the structure of the front-end source code; Deploy a change-aware agent in the development environment to monitor changes to the front-end source code in real time and abstract these changes into change descriptions. The change description is merged with the intermediate design representation through the bidirectional association mapping, and the Axure prototype is updated.

[0012] Secondly, embodiments of this application provide a front-end code generation system for Axure prototypes, comprising: The first processing module is used to parse the Axure prototype, identify and understand the layout results and interaction logic of the Axure prototype, and generate an intermediate design representation. The second processing module is used to generate executable front-end source code based on the intermediate design representation and the target project configuration, using a code generation template. The third processing module is used to establish an association mapping between the intermediate design representation and the front-end source code, and to synchronize changes between the intermediate design representation and the front-end source code.

[0013] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned front-end code generation method of the Axure prototype.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium, including a computer program stored in the computer-readable storage medium, which, when executed by a processor, implements the aforementioned front-end code generation method for the Axure prototype.

[0015] The beneficial effects of the embodiments in this application compared with the prior art are: This application discloses a front-end code generation method for Axure prototypes. It parses the Axure prototype to obtain its corresponding layout and interaction semantics, and generates a design intermediate representation independent of the front-end framework. This enables deep, multi-layered semantic analysis of the Axure prototype for code generation. The design intermediate representation is set up to build a collaborative workflow between the Axure prototype and code generation, breaking down process silos. Design changes can be automatically or semi-automatically synchronized to the code, and code changes and optimizations can be fed back to the Axure prototype through comments. Furthermore, the parsing of the Axure prototype's layout semantics allows for the comprehensive extraction of layout information, which is beneficial for generating responsive code. The parsing of the Axure prototype's interaction semantics converts event-driven interaction scripts into state-driven interaction information, thereby dynamically handling complex code logic. By combining the target technology stack with code generation, it enables the dynamic generation of corresponding code based on the specific technology stack. Attached Figure Description

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

[0017] Figure 1 This is a flowchart illustrating a method for generating front-end code for an Axure prototype, provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a front-end code generation system for an Axure prototype provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0019] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0020] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0021] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0022] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0024] Please see Figure 1 As shown, this invention is a method for generating front-end code for an Axure prototype, comprising the following steps: S100. Analyze the Axure prototype, identify and understand the layout results and interaction logic of the Axure prototype, and generate an intermediate design representation; In some embodiments, step S100 above includes: From the pixel-level representation of the Axure prototype, the layout information of the visual layer, structural layer, and intent layer is extracted layer by layer. Convert the event-driven interactive scripts in the Axure prototype into state-driven interactive information; Based on the layout information and the interaction information, an intermediate design representation is generated.

[0025] In this embodiment, the Axure prototype is parsed to obtain its corresponding layout semantics and interaction semantics, and a design intermediate representation independent of the front-end framework is generated. The design intermediate representation serves as an intermediate layer between the Axure prototype and the source code to be generated, and can be used to generate front-end source code that conforms to the project configuration.

[0026] Specifically, layout semantics involves extracting data from the visual layer of the Axure prototype, parsing data from the HTML structure layer, and inferring the designer's layout intent. This allows for a comprehensive extraction of layout information from the Axure prototype, which is beneficial for the reliability of subsequent source code generation. Interaction semantics, on the other hand, involves converting event-driven interaction scripts in the Axure prototype into state-driven interaction information, which can be used to generate corresponding interaction code based on project configurations.

[0027] In some embodiments, the step of extracting layout information of the visual layer, structural layer, and intent layer layer layer by layer from the pixel-level representation of the Axure prototype includes: The pixel-level features of the Axure prototype are analyzed using computer vision algorithms to extract visual information, including visual grouping, alignment relationships, and spacing patterns. Perform DOM parsing and CSS style analysis on the HTML code of the Axure prototype to extract the structural information of the Axure prototype, including element hierarchy, positioning method and layout role; The designer's layout intent, component types, and interaction purposes can be inferred from the visual and structural information.

[0028] In this embodiment, data extraction is performed on the visual layer of the Axure prototype to understand the visual presentation rules of the design from the pixel level of the Axure prototype. Specifically, computer vision algorithms are used to analyze the pixel-level features of the Axure prototype. In the computer vision algorithm, each UI element is encoded with its element feature vector, and then the composite similarity between each UI element is calculated. Then, combined with the clustering threshold parameter, each UI element is clustered to form visual groups.

[0029] Specifically, the element feature vector includes absolute position features, relative position features, size features, boundary features, and area features. The absolute position feature is the center coordinates (x, y) of the UI element; the relative position feature is the normalized coordinates of the UI element relative to its potential container; the size feature represents the width, height, and aspect ratio of the UI element; the boundary feature represents the top, bottom, left, and right boundary coordinates of the UI element; and the area feature represents the pixel area occupied by the UI element.

[0030] Specifically, composite similarity includes spatial similarity S_s, visual similarity S_v, and alignment similarity S_a. Spatial similarity S_s = 1 / (1+d)×overlap_ratio, where d is the normalized Euclidean distance of the UI element's center coordinates, and overlap_ratio is the ratio of the overlapping areas of the element's bounding boxes. The element's bounding box is the smallest rectangle that completely encloses the UI element, measured by the UI element's center coordinates, width, and height. If the overlap area of ​​the bounding boxes between two UI elements is 0, it indicates that the spatial similarity between the two UI elements is 0, while closely adjacent or partially overlapping UI elements have high similarity. Visual similarity is measured using color and font features, calculated by... The histogram intersection of the SV color space determines color features, while font features are determined by comparing the similarity of font-family, font-size, and font-weight. For alignment similarity, including horizontal and vertical alignment, specifically, if two elements are left-aligned, center-aligned, or right-aligned horizontally, or top-aligned, center-aligned, or bottom-aligned vertically, a higher alignment similarity is assigned. Specifically, the vertical center-line distance between two UI elements is calculated, and similarly, the horizontal center-line distance between two UI elements is calculated. The center-line distance is normalized to [0,1] to measure the corresponding horizontal and vertical alignment similarity. Thus, the composite similarity S_total(e1,e2)=α×S_s(e1,e2)+β×S_v(e1,e2)+γ×S_a(e1,e2), where α, β, and γ are adaptive weight coefficients, and α+β+γ=1. Therefore, e1 and e2 are two UI elements.

[0031] It is worth noting that in some embodiments, the aforementioned clustering threshold parameters and the adaptive weight coefficients of α, β, and γ are fixed thresholds set based on experience. In other embodiments, suitable α, β, and γ weight coefficients and clustering threshold parameters are determined by analyzing the page features of the Axure prototype. Specifically, the total number of elements, average element area, layout entropy, maximum overlap layer, and number of colors are obtained from the pages designed by the Axure prototype, and encoded into page feature vectors. These vectors are then input into a pre-trained machine learning model to output the most suitable α, β, and γ weight combination and clustering threshold parameters for the current page. For the machine learning model, such as a random forest model, the labeled pages are used as training data and divided into training, validation, and test sets for training. Finally, the trained machine learning model can output the α, β, and γ weight combination and clustering threshold parameters, thereby enabling the final visual grouping to fully understand the page features of the Axure prototype.

[0032] Specifically, during clustering, each UI element is grouped into its own category, and then the two categories with the highest similarity are iteratively merged until the similarity between all categories is below a dynamic threshold. The final category is the visual grouping.

[0033] Furthermore, by using coordinate sequence analysis and projection techniques, the alignment relationships between elements are identified. Specifically, the Y-axis coordinate range of all UI elements is projected onto the vertical axis, and the number of elements' widths covering each vertical pixel position is counted, forming a horizontal projection histogram. The Y-coordinate positions corresponding to the obvious "peaks" in this horizontal projection histogram are the baselines for element alignment in the vertical direction. By analyzing the width and height of the peaks in the horizontal projection histogram, it is possible to distinguish between top alignment, bottom alignment, and horizontal center line alignment. Similarly, the X-axis coordinate range of all elements is projected onto the horizontal axis to form a vertical projection histogram for vertical projection analysis to identify left alignment, right alignment, or vertical center line alignment. It is worth noting that if a series of equally spaced peaks are found in the projection histogram, it indicates the existence of equally spaced columns or rows. By checking whether the spacing of the peak sequence is constant, it is confirmed whether it is distributed alignment.

[0034] Furthermore, sequence pattern mining and least common multiple analysis methods are employed to extract spacing patterns from element arrangements to infer potential design proportions. Specifically, based on the alignment relationship identification results, adjacent spacing sequences of elements in the same row or column are extracted. By calculating the greatest common divisor of all spacing values, the basic spacing unit of the page designed in the Axure prototype is inferred, and the design proportion of the Axure prototype is reconstructed based on this benchmark spacing unit. Specifically, based on the alignment relationship identification results, all element sequences on the same horizontal or vertical line are found, and the pixel distance between corresponding edges of adjacent elements in this element sequence is extracted to form multiple spacing sequences. For example, in a row of three buttons, the spacing from the right edge of the first button to the left edge of the second button, and the spacing from the second to the third button, are extracted. Further, all spacing values ​​are collected and clustered, and the greatest common divisor or least common multiple of each cluster center is taken as the benchmark spacing unit. Further, all spacing values ​​are divided by the benchmark spacing unit to obtain a multiple sequence K = [k1, k2, ...]. Clustering and frequency analysis are performed on K, and high-frequency clusters are selected and classified based on preset frequency values. For example, k=1,2,3,4 are high-frequency clusters, designated as levels xs, sm, md, and lg respectively. The median or mode of the multiples within each level is taken as the nominal multiple of that level. For example, the multiple cluster corresponding to level md is [3,3,3,4,3], then md=3*BSU=24px.

[0035] It is worth noting that the HTML, CSS, JavaScript, and other files exported from the Axure prototype have redundant structures and poor maintainability. Therefore, in this embodiment, it is necessary to perform data parsing on the Axure prototype at the structural level to understand the document object model and style rules of the Axure prototype, thereby filtering out irrelevant style containers or invalid nested tags.

[0036] Specifically, Axure, for precise control over styles, typically generates multiple levels of nested styles. Therefore, it parses the HTML DOM tree exported from the Axure prototype, identifies the visually valid hierarchical structure, and filters out irrelevant style containers. Specifically, by traversing the DOM tree, it determines whether each node is a visually valid node. The judgment principles include: determining whether the node has a visible size, that is, the width and height of the node are both greater than the threshold; determining whether the node or its child nodes have visible content, such as text, images, backgrounds, etc.; and determining whether the node is not a pure style container, such as a nested div used only for background and shadow.

[0037] In one embodiment, a visual importance score is calculated for each node based on the aforementioned judgment rules. The visual importance score determines whether a node is a valid node. Specifically, the visual importance score is measured by node size characteristics, content characteristics, and style characteristics. Node size characteristics refer to whether the node has a visible size, measured by calculating the percentage of screen area occupied by the node. Content characteristics refer to whether the node or its child nodes have visible content, measured by quantifying the content contained in the node, such as text length and the number of images. Style characteristics refer to whether the node is not a pure style container, measured by calculating the complexity of style attributes such as the node's background, border, and shadow. The visual importance score is obtained by quantifying and weighting the above node size, content, and style characteristics. A dynamic threshold is then set; if the visual importance score is higher than the dynamic threshold, the node is determined to be a valid node. Furthermore, the dynamic threshold is adjusted according to the overall complexity of the page, ensuring that only nodes with high scores are retained in simple pages, while more nodes are retained in complex designs to maintain detail.

[0038] Furthermore, for the filtered invalid nodes, their style attributes are recorded so that they can be integrated into the parent or sibling nodes in subsequent steps. Specifically, this involves identifying the aforementioned continuous nodes that have no text content and are distinguished only by their class. Nested as a style container chain, and merged into a single logical node, this logical node incorporates the style properties of all nodes in the style container chain, thereby significantly simplifying the depth of the DOM tree.

[0039] Furthermore, the visual hierarchy of elements in the Axure prototype is determined by the DOM order, z-index, and stacking context. DOM order refers to the order in which elements are added to the Axure canvas; by default, later added elements cover earlier ones. If z-index or stacking context is not explicitly set, the DOM order directly determines the visual stacking order of elements. z-index controls the vertical position of an element within the stacking context; the larger the value, the more prominent the element. If z-index values ​​are the same, the DOM order determines the order. The stacking context is determined by certain CSS properties, such as opacity < 1. For specific Axure interactions such as `transform`, triggering independent stacking contexts (e.g., dynamic panels), the stacking context is triggered by traversing all elements and marking the elements that trigger it. Examples include dynamic panels with set `z-index` and elements with changing opacity. Each stacking context acts as an independent root node of a subtree. Elements are then assigned to their corresponding stacking contexts: a root context and child contexts. The root context contains all elements that haven't explicitly created new contexts. Child contexts are independent stacking groups formed by elements within dynamic panels, masters, etc. For elements within each stacking context, elements with higher `z-index` are placed first. If `z-index` is the same, the later added element is placed first, and elements with special properties are forced to be placed first, such as forcing elements with `position: fixed` to the top. The stacking contexts themselves are ordered according to DOM order and `z-index`. The stacking order of child contexts is determined by the `z-index` of their root element, independent of the internal elements. Therefore, by applying the above rules recursively, a tree structure representing the visual hierarchy of elements is constructed. Each node represents a stacking context, and the leaf nodes are specific elements. This corrects the visual representation order of the hierarchical structure of the DOM tree in the Axure prototype, accurately reflects the occlusion relationship between elements, and helps to understand the positional relationship of stacked components such as modals and drop-down menus, ensuring that the subsequently generated code can correctly restore the visual hierarchy.

[0040] Furthermore, the inline styles and external CSS are analyzed to extract the style feature vector of each element, and its positioning method and layout behavior are classified and identified. Specifically, the element's position property is analyzed, and combined with the top, left, right, and bottom values, it is determined whether it is absolute positioning, relative positioning, fixed positioning, static positioning, or sticky positioning.

[0041] In some embodiments, the display, float, flex, and grid-related properties of elements are analyzed to infer their layout role, such as block-level container, inline container, Flex container, Grid container, and floating element, and the margin, border, padding, and box-sizing properties of elements are extracted to provide accurate data for layout calculation.

[0042] In this embodiment, by understanding the Axure prototype at both the visual and structural levels, the designer's design intent is inferred, which facilitates subsequent code generation. Specifically, the aforementioned visual and structural information is fused to generate an intent inference feature vector. Based on this feature vector, a multi-level classification model is used to identify the component type of UI elements. Simultaneously, a set of layout-related constraints is extracted from the visual and structural information, and then matched with a layout pattern library to determine the designer's layout intent. Furthermore, element information, association information, and interaction information of UI elements are obtained to perform intent recognition and predict the interaction purpose of the elements.

[0043] Specifically, using UI elements as nodes, and the composite similarity, alignment relationships, spacing patterns, node relationships in the DOM tree, and visual hierarchy relationships of each UI element as determined in the visual grouping process above, a heterogeneous graph is constructed. In this heterogeneous graph, composite similarity and alignment relationships correspond to visual edges, while node relationships and visual hierarchy relationships in the DOM tree are structural edges. Each node is also appended with node features, such as the element feature vector, style feature vector, layout role, and content features like text and images mentioned above. Then, a graph attention network is used to process this heterogeneous graph, learning the weights of the semantic contributions of different neighboring nodes to the central node. Graph pooling is then used to aggregate these features, generating intent inference feature vectors that represent layout intent and component type.

[0044] More specifically, component type identification is performed through a multi-level classification model. This model is divided into three levels, from coarse to fine: primary classification, secondary classification, and tertiary classification. In primary classification, based on the visual and structural information of UI elements, a convolutional neural network is used to identify basic element types, including text labels, images, lines, and shape containers. Secondary classification combines the direct contextual information of elements, i.e., their relationship with neighboring elements, and uses a recurrent neural network to identify composite component types, including buttons, input boxes, dropdown selectors, radio buttons, and checkboxes. Tertiary classification analyzes the context and interaction of elements in the overall layout to identify complex business component types, including navigation bars, data tables, paginators, modal dialog boxes, and cards.

[0045] More specifically, for decoding the layout intent, soft and hard constraints related to the layout are extracted from visual and structural information to generate a constraint set. Soft constraints specifically include element alignment preferences, uniform spacing preferences, and proportional coordination preferences, while hard constraints specifically include the inclusion relationship, non-overlapping relationship, and order relationship between elements. The extracted constraint set is then matched against a predefined layout pattern library. In one embodiment, the layout pattern library includes layout patterns such as flow layout, single / multi-column layout, grid layout, positioned overlay layout, and sidebar-content layout. Each layout pattern defines a set of typical constraints that must be satisfied. For example, the constraints for matching the "grid layout" pattern include: elements arranged in multiple rows and columns, row height / column width possibly aligned, and regular spacing. Then, the designer's layout intent is determined by calculating the matching similarity between the layout of each element and each layout pattern. In one embodiment, the matching similarity is calculated by calculating the number of constraints satisfying the constraint set in the layout pattern and the weight of the satisfied constraints, and the layout pattern with the highest matching similarity is selected as the designer's layout intent.

[0046] More specifically, predicting the interaction purpose of elements provides direction and context for extracting specific interaction steps. Specifically, this involves obtaining element information, related information, and interaction information of UI elements. Element information refers to the interaction intent inherent in or implied by the element itself, such as the interaction intent inherent in the element type, the jump intent inherent in buttons and links, and the intent implied in text content such as "submit" and "search". Related information refers to the interaction intent implied by the element's position in the layout, such as a button at the bottom of a form that might be "submit" or "reset", an icon button to the right of a list item that might be "delete" or "edit", and a button near the search box that might be intended to "search". Interaction information refers to simple interaction events defined by Axure, such as the click event corresponding to OnClick. In one embodiment, the information obtained from the UI elements is input into a classifier to map the UI elements to predefined interaction intent categories in order to determine the interaction purpose of the elements. The predefined interaction intent categories include navigation intent, submit intent, filter / sort intent, expand / collapse intent, state switching intent, etc. It is worth noting that the classifier is a model trained on labeled data that can learn to associate interaction intent categories with signal combinations, and is used to determine the interaction purpose of the elements.

[0047] In some embodiments, converting the event-driven interaction scripts in the Axure prototype into state-driven interaction information includes: The "trigger-condition-action" triples in the Axure interaction panel are parsed into basic interaction primitives, and the basic interaction primitives are deconstructed into a structured sequence of interaction primitives. Identify implicit state variables from the sequence of interaction primitives, and generate an event stream by analyzing the triggering order and triggering conditions of interaction events; Based on the interaction primitive sequence, the implicit state variables, and the event flow, a state change model is generated, and the state change model is converted into an interaction interface description, which includes state definitions, transition conditions, and side effect mappings.

[0048] Specifically, the interactions in the Axure prototype are event-driven, imperative interaction scripts, and the interaction descriptions are usually in the form of a mixture of natural language and simple scripts, thus transforming them into a declarative, state-driven interaction model.

[0049] In this embodiment, the unstructured interaction descriptions in the Axure interaction panel are deconstructed into a structured sequence of interaction primitives. Specifically, the triplet interaction descriptions related to "trigger-condition-action" in the Axure interaction panel are parsed into structured basic interaction primitives. For example, in one embodiment, the triplet interaction description related to "trigger-condition-action" in the Axure interaction panel is "OnClick of ButtonA, Show PanelB", where OnClick of ButtonA represents the trigger, Show PanelB represents the action, and no condition is set. Then, a parser based on syntax rules and pattern matching is used to parse it, which yields {trigger: "click", target: "ButtonA", condition: null, action:{type: "show", target: "PanelB"}}, which is beneficial for the subsequent parsing of the association between different interactions.

[0050] More specifically, each interaction description in the Axure interactive panel is converted into a basic interaction primitive. Then, the logical relationship between each basic interaction primitive is identified, and they are converted into a continuous, logically related sequence of interaction primitives. The corresponding interaction mode is determined for the sequence of interaction primitives. The interaction modes include, but are not limited to, switch mode, toggle mode, form mode, navigation mode, and data operation mode. For example, two consecutive basic interaction primitives, "Show PanelB" and "Hide PanelC", are combined into "Toggle Display".

[0051] Furthermore, in the series of interaction primitives, all basic interaction primitives are analyzed to construct a causal dependency graph. The nodes of the causal dependency graph are basic interaction primitives, and the edges are the causal dependencies within those nodes. Specifically, if the execution of primitive A changes a UI element when primitive B is executed, a causal edge is established between A and B. In this causal dependency graph, if an attribute of a UI element is modified by multiple primitives, that attribute is determined to be a latent state variable. Then, the interaction primitive features related to this latent state variable are input into the state inference model to infer the type, value range, and initial state of the latent state variable. It is worth noting that the state inference model is a variational autoencoder, including an encoder and a decoder. The encoder takes the interaction primitive features of the basic interaction primitives related to the latent state variable as input, while the decoder reconstructs the basic interaction primitives to obtain an abstract representation of the state variable, inferring its type (e.g., Boolean, enumerated), value range, and initial state.

[0052] In this embodiment, complex interactions typically involve the collaboration and competition of multiple interactive events. Therefore, an event flow is generated by analyzing the triggering order and triggering conditions of interactive events. Specifically, based on the causal dependency graph, the dependencies of temporal dependence, conditional dependence, and data dependence are constructed to generate an event dependency graph. Temporal dependence indicates that primitive A must occur before primitive B, conditional dependence indicates that the occurrence of primitive A affects the triggering condition of primitive B, and data dependence indicates that primitive A generates the data required by primitive B. Then, through a graph clustering algorithm, the event flow generated in the event dependency graph is decomposed into independent interactive modules, that is, closely related events are grouped to form interactive modules. Each module corresponds to a relatively independent functional unit, such as a "form filling and submission module" and an "image carousel control module".

[0053] Furthermore, all implicit state variables and their initial states are defined as S0. Simultaneously, each interaction primitive in the event dependency graph is traversed. For each interaction primitive, all states S satisfying its conditions are searched among all currently defined states, and a transition edge from S to S' is added, where S' is the new state obtained after applying the action in the interaction primitive. The corresponding triggering event is labeled on the transition edge. State merging rules are applied to merge semantically equivalent states, such as "merge states if they differ only in internal timer values ​​not visible to the user." Transition simplification rules are also applied to eliminate redundant state transition paths. For example, if there is a direct path from state A to state C and an indirect path through state B, and the conditions of the direct path are a superset of the conditions of the indirect path, then the indirect path is retained, and the direct path is deleted. Finally, a state change model is generated to describe the state variable changes during event transitions.

[0054] It is worth noting that the state transition model supports state features such as hierarchical states, parallel states, historical states, guard conditions, and entry / exit actions. Specifically, hierarchical states support nested states to form a state hierarchy. For example, the "player" state can contain sub-states such as "play", "pause", and "buffer". Parallel states support the parallel operation of multiple independent state transition models, that is, support multiple independent event streams in parallel. Historical states support remembering and restoring previous state configurations. Guard conditions indicate that state transitions can be accompanied by complex Boolean condition expressions. Entry / exit actions indicate that specific actions can be executed when a state enters or exits.

[0055] Furthermore, the state change model is converted into a declarative interaction interface description, which includes state definitions, transition conditions, and side effect mappings. In some embodiments, it also includes event definitions. Specifically, the state definition declares all state variables and their types, as well as the initial state; the transition conditions describe the state transition rules in a declarative syntax; the side effect mapping describes the UI element update operations corresponding to state changes; and the event definition declares all interaction events and their parameters, providing a clear specification for subsequent code generation.

[0056] Furthermore, based on the layout semantics and interaction semantics obtained from the above analysis of the Axure prototype, an intermediate representation is generated to generate code. The intermediate representation is designed using a hierarchical structured format, specifically including a layout layer, a logic layer, and a metadata layer. The layout layer describes the static structure of each UI element in the Axure prototype, corresponding to layout semantics, and specifically includes the DOM tree, component types, layout constraint sets, layout modes, style mappings, etc. The logic layer describes the dynamic behavior of each UI element in the Axure prototype, corresponding to interaction semantics, and specifically includes the definition of the state change model, event handling, and data flow, etc.

[0057] Therefore, this application generates an intermediate design representation rich in layout and interaction information by performing deep, multi-level semantic analysis on the Axure prototype, and uses it as an intermediate layer, which is beneficial for subsequent code generation.

[0058] S200. Based on the aforementioned intermediate design representation and combined with the target project configuration, generate executable front-end source code using a code generation template; In some embodiments, step S200 above includes: Parse the target project configuration, determine the target technology stack of the project, and select the corresponding code generation adapter based on the target technology stack; The visual information of the intermediate design representation is mapped to design tokens, and style specifications are generated based on the target technology stack and the layout constraints of the intermediate design representation. The state change model of the intermediate design is mapped to the state management architecture of the target technology stack; Based on the code generation adapter, the style specification, and the state management architecture, source code is generated.

[0059] In this embodiment, the target project configuration is parsed to obtain the project's target technology stack, specifically including the target framework, component library, state management library, build tools, and code style guidelines. The target technology stack refers to the target framework and its corresponding version specified by the project, such as React, Vue, Angular, or native frameworks. The component library refers to the UI component library and its corresponding version specified by the project. The state management library stores the state management architecture and its configuration based on the target technology stack, such as Redux / Vuex / MobX / Pinia. The build tools are the build tools and their configurations specified by the project, such as Webpack / Vite. The code style guidelines are the code style and rules specified by the project, such as ESLint / Prettier. The target configuration of the project is stored using a layered configuration model, and the corresponding project configuration information can be obtained by parsing the layered configuration model.

[0060] Furthermore, a corresponding code generation adapter is provided for each target technology stack. This code generation adapter includes a semantic mapper, a template engine, a transformation rule library, and a validator. Specifically, the semantic mapper defines a mapping table from the intermediate design representation to the corresponding concepts in the target framework, used to map the intermediate design representation to the target technology stack. The template engine defines code templates corresponding to the target technology stack, such as Jinja2 or Handlebars templates, used to generate code based on the code templates of the target technology stack. The transformation rule library stores code transformation rules specific to the target technology stack, such as "convert inline styles to CSS classes" and "change the event handler function binding method from inline to class method". The validator is used to verify whether the generated code conforms to the syntax and specifications of the target technology stack, and is usually run after code generation.

[0061] Furthermore, visual attributes in the intermediate design representation, such as color, spacing, and font, are mapped to design tokens. Then, based on the target technology stack, the style generation method is determined. On this basis, style specifications are generated based on the layout constraints in the intermediate design representation and the layout mode determined therein, for use in the generation of subsequent responsive code.

[0062] Specifically, style generation methods include CSS Modules, Styled-components, Tailwind CSS, or native CSS. CSS Modules generates .module.css files and uses local scope class names. Styled-components generates styled components that tightly integrate styles with component logic. Tailwind CSS generates HTML / JSX using utility classes. Native CSS generates traditional CSS files and supports SASS / LESS preprocessing.

[0063] Furthermore, the state change model of the intermediate representation is mapped to the state management architecture determined by the target technology stack. Specifically, the state variables defined in the state change model are mapped to the state definitions of the state management framework; the transition conditions defined in the state change model are mapped to event handling functions; and the side effects defined in the state change model are mapped to UI update logic.

[0064] In some embodiments, the generated source code includes template-driven generation and large model enhancement generation.

[0065] Specifically, based on the target technology stack determined in the code generation adapter, and based on the state management architecture determined by the state change model represented by the intermediate design according to the target technology stack, state and logic are injected during the code generation process.

[0066] In this embodiment, the source code generation includes two methods: template-driven generation and large model enhancement generation. For Axure prototypes that can obtain standard components from intermediate design representations, the template-driven generation method is used, while for custom, complex composite components or business logic, the large model enhancement generation method is used, which generates the source code by constructing structured prompts.

[0067] Specifically, for the template-driven generation method, the component type corresponding to the UI element is obtained from the intermediate design representation. Based on the target technology stack, the corresponding code template is selected, the structure is mapped, and a code skeleton is generated. Then, the style specification is injected into the code skeleton to generate style code. The state definition, event handling function, and UI update logic determined in the state management architecture are then injected into the style code and event binding is performed. Finally, responsive source code is generated.

[0068] Specifically, taking an Axure prototype of a user login form as an example, the target technology stack obtained after parsing the target project configuration is React + TypeScript + Ant Design. A Form container is identified from the intermediate design representation, containing two Input fields: username and password, and a Button. Then, the Ant Design component library selects the Antd Form template, Antd Input template, and Antd Button template, and performs structural mapping to generate the following code skeleton: <form> <Form.Item name="username">...< / Form.Item> <Form.Item name="password">...< / Form.Item> <button type="primary"> Log in< / button> < / form> Furthermore, the design tokens mapped by the visual attributes of the intermediate design and the corresponding style specifications are injected into the code skeleton above. For example, the 16px spacing is mapped to the design token `@spacing-md`, and an inline style of style={{ marginBottom: 'var(--spacing-md)'}} is added to Form.Item. Further still, the state {loading: boolean, formData: object} and the events submitForm and inputChange are injected into the code template generation. ```typescript const [form] = Form.useForm(); const [loading, setLoading] = useState(false); const handleSubmit = async (values) => { setLoading(true); try { await loginApi(values); / / Redirect successful } catch (error) { / / Error handling finally { setLoading(false); } }; ``` Then, handleSubmit is bound to the form's onFinish event, and finally validated in the validator in the code generation adapter to determine whether the generated code conforms to React rules.

[0069] Specifically, for the large model enhancement generation method, the target framework, component library, state management architecture and code style in the target technology stack are used as the technology stack configuration for code generation. Combined with the design intermediate representation as the source data for code generation, structured prompt words are finally generated, and the source code is finally generated through the large language model.

[0070] S300. Establish an association mapping between the design intermediate representation and the front-end source code, and synchronize changes between the design intermediate representation and the front-end source code.

[0071] In some embodiments, step S300 above includes: Establish a bidirectional association mapping at the element level and the structure level between the intermediate representation of the design and the structure of the front-end source code; Deploy a change-aware agent in the development environment to monitor changes to the front-end source code in real time and abstract these changes into change descriptions. The change description is merged with the intermediate design representation through the bidirectional association mapping, and the Axure prototype is updated.

[0072] In this embodiment, an association mapping is established between the intermediate design representation and the generated source code, code changes during the development process are monitored, and the changes are abstracted and selectively reverse-synchronized to the intermediate design representation, thereby providing visual guidance for updating the Axure prototype.

[0073] Specifically, for element-level mapping, UI elements in the intermediate design representation are mapped to component instances in the code. For example, the button element "btn-submit-001" in the intermediate design representation is mapped to the SubmitButton component instance in the code. For structure-level mapping, the DOM tree in the intermediate design representation is mapped to the nested structure in the code. For example, the tree structure of the form container and its child elements in the intermediate design representation is mapped to the nested structure of the Form component in the code.

[0074] Furthermore, a change-aware agent is deployed in the development environment to detect changes in the front-end source code. Specifically, abstract syntax tree analysis is performed on the code before and after the change to calculate the AST difference. Then, the AST difference is mapped to semantic operations, such as component addition, deletion, modification, attribute changes, state logic changes, and style changes, thereby achieving the abstraction of changes. At the same time, the semantic operations are associated with the association mapping established by the intermediate design representation, so that the changes in the front-end source code are associated with the intermediate design representation, thereby synchronizing the updates of the Axure prototype.

[0075] More specifically, for the mapping of semantic operations, based on captured code changes, the developer's operational intent sequence is reconstructed. This sequence is then matched with a predefined development pattern library to identify common development operation patterns. The impact of these changes on UI elements, interaction logic, data flow, performance, and other aspects is analyzed, thereby adding semantic tags to the changes, such as "performance optimization," "feature enhancement," "bug fix," "style adjustment," "attribute change," and "state logic change." It's worth noting that the development pattern library includes pattern definitions for various development scenarios. Each pattern includes a pattern name, typical code change characteristics, and expected design impact. Specifically, the pattern name represents the effect the pattern can achieve, such as "add form validation" or "optimize list rendering." Typical code change characteristics are the features exhibited by the pattern at the code level, and the expected design impact refers to the potential effects on UI elements, interaction logic, data flow, and performance under this pattern.

[0076] Specifically, a hierarchical synchronization strategy is adopted for the synchronous updates of Axure prototypes. For simple, conflict-free attribute changes, such as minor adjustments to color, text, or position, a first-level synchronization method is used, automatically updating the corresponding UI elements in the Axure prototype. For complex logic changes or new features, a second-level synchronization method is used, adding comments to the Axure prototype to describe the changes and providing code snippet previews. For major architectural changes or changes requiring a complete redesign, a third-level synchronization method is used, creating design work items in the project management tool.

[0077] Please see Figure 2 As shown, the present invention also provides a front-end code generation system for Axure prototypes, the system comprising: First processing module 201: used to parse the Axure prototype, identify and understand the layout results and interaction logic of the Axure prototype, and generate intermediate design representation; The second processing module 202 is used to generate executable front-end source code based on the design intermediate representation and the target project configuration, using a code generation template. The third processing module 203 is used to establish an association mapping between the intermediate design representation and the front-end source code, and to synchronize changes between the intermediate design representation and the front-end source code.

[0078] It is understandable that, such as Figure 1 The content of the Axure prototype front-end code generation method embodiment shown is applicable to the front-end code generation system embodiment of this Axure prototype. The specific functions implemented by the front-end code generation system embodiment of this Axure prototype are the same as those shown below. Figure 1 The front-end code generation method of the Axure prototype shown is the same as that implemented in this example, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the front-end code generation method embodiment of the Axure prototype shown are also the same.

[0079] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0080] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0081] Please see Figure 3 As shown, this embodiment of the invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the front-end code generation method of the Axure prototype as described in any of the above methods.

[0082] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0083] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0084] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0085] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the Axure prototype front-end code generation method as described in any of the above methods.

[0086] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / computer device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0087] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for generating front-end code for Axure prototypes, characterized in that, include: The Axure prototype is parsed to identify and understand its layout and interaction logic, and an intermediate design representation is generated. Based on the aforementioned intermediate design representation, and combined with the target project configuration, executable front-end source code is generated using a code generation template. Establish an association mapping between the intermediate design representation and the front-end source code, and synchronize changes between the intermediate design representation and the front-end source code.

2. The method as described in claim 1, characterized in that, The process of parsing the Axure prototype, identifying and understanding its layout and interaction logic, and generating an intermediate design representation includes: From the pixel-level representation of the Axure prototype, the layout information of the visual layer, structural layer, and intent layer is extracted layer by layer. Convert the event-driven interactive scripts in the Axure prototype into state-driven interactive information; Based on the layout information and the interaction information, an intermediate design representation is generated.

3. The method as described in claim 2, characterized in that, The step of extracting layout information for the visual layer, structural layer, and intent layer layer layer from the pixel-level representation of the Axure prototype includes: The pixel-level features of the Axure prototype are analyzed using computer vision algorithms to extract visual information, including visual grouping, alignment relationships, and spacing patterns. Perform DOM parsing and CSS style analysis on the HTML code of the Axure prototype to extract the structural information of the Axure prototype, including element hierarchy, positioning method and layout role; The designer's layout intent, component types, and interaction purposes can be inferred from the visual and structural information.

4. The method as described in claim 2, characterized in that, The process of converting event-driven interactive scripts in the Axure prototype into state-driven interactive information includes: The "trigger-condition-action" triples in the Axure interaction panel are parsed into basic interaction primitives, and the basic interaction primitives are deconstructed into a structured sequence of interaction primitives. Identify implicit state variables from the sequence of interaction primitives, and generate an event stream by analyzing the triggering order and triggering conditions of interaction events; Based on the interaction primitive sequence, the implicit state variables, and the event flow, a state change model is generated, and the state change model is converted into an interaction interface description, which includes state definitions, transition conditions, and side effect mappings.

5. The method as described in claim 1, characterized in that, Based on the intermediate design representation and combined with the target project configuration, executable front-end source code is generated using a code generation template, including: Parse the target project configuration, determine the target technology stack of the project, and select the corresponding code generation adapter based on the target technology stack; The visual information of the intermediate design representation is mapped to design tokens, and style specifications are generated based on the target technology stack and the layout constraints of the intermediate design representation. The state change model of the intermediate design is mapped to the state management architecture of the target technology stack; Based on the code generation adapter, the style specification, and the state management architecture, source code is generated.

6. The method as described in claim 1, characterized in that, The generated source code includes template-driven generation and large model enhancement generation.

7. The method as described in claim 1, characterized in that, The process of establishing the association mapping between the intermediate design representation and the front-end source code, and synchronizing changes between the intermediate design representation and the front-end source code, includes: Establish a bidirectional association mapping at the element level and the structure level between the intermediate representation of the design and the structure of the front-end source code; Deploy a change-aware agent in the development environment to monitor changes to the front-end source code in real time and abstract these changes into change descriptions. The change description is merged with the intermediate design representation through the bidirectional association mapping, and the Axure prototype is updated.

8. A front-end code generation system for Axure prototypes, characterized in that, include: The first processing module is used to parse the Axure prototype, identify and understand the layout results and interaction logic of the Axure prototype, and generate an intermediate design representation. The second processing module is used to generate executable front-end source code based on the intermediate design representation and the target project configuration, using a code generation template. The third processing module is used to establish an association mapping between the intermediate design representation and the front-end source code, and to synchronize changes between the intermediate design representation and the front-end source code.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images