Full stack schema-driven development system and method

Abstract

Efficient generation of multi-platform compatible source code and test code with consistency and quality in software development SOLUTION: The schema-driven development system includes a user input unit, a schema generation unit, and a code generation unit, wherein the user input unit acquires data in various formats such as a natural language and a CSV file, the schema generation unit converts the acquired data into a schema, and the code generation unit generates a source code and a test code based on the generated schema.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to software development technology, and to a "full-stack schema-driven development system and method" that uses a schema to consistently generate source code and test code for the entire software that can be compatible with multiple platforms. [Background technology]

[0002] In recent software development, principles and designs such as the SOLID principles, Clean Architecture, and Domain-Driven Design (DDD) have been widely adopted to reduce the effort, burden, and cognitive load on developers.

[0003] Traditional schema-driven approaches ensure consistency in database table definitions and API definitions by using formats such as JSON or XML.

[0004] In recent years, technology for automatically generating source code using natural language processing has been developed.

[0005] Patent Document 1 discloses a technique for generating source code from a model described as specifications for input and output of data.

[0006] Patent Document 2 discloses a technique for automatically generating part of a source code in accordance with a table definition and an API definition. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Publication No. 2020-004036 [Patent Document 2] Japanese Patent Publication No. 2023-031223 Summary of the Invention [Problem to be solved by the invention]

[0008] In software development, which depends on each developer's preferences, knowledge, and experience, it is not easy to consistently apply principles and designs such as SOLID principles, Clean Architecture, Domain-Driven Design (DDD), and Test-Driven Design (TDD) across the entire software.

[0009] In actual development environments, there is a limit to the amount of man-hours that can be spent, and it is often not possible to write test code, which leads to an increase in errors and makes maintenance more complicated.

[0010] Conventional schema-based or model-based automatic source code generation technologies can only generate parts of software development, such as table definitions, API definitions, and data input / output models, and are unable to consistently generate source code for the entire software.

[0011] Existing technologies that generate source code using natural language processing produce inconsistent output, making it difficult to achieve a consistent design throughout the software, and making it impossible to guarantee a consistent user interface or source code quality. [Means for solving the problem]

[0012] The present invention solves the above-mentioned problems by providing a "full-stack schema-driven development system and method" that uses schemas to consistently generate source code and test code for the entire software that can be used on multiple platforms.

[0013] [1] First, input data from the user is obtained in the form of natural language, image files, PDF files, GUI tools, YAML, JSON, XML, etc. The user input parser uses machine learning models and heuristic algorithms to convert input data into schemas as needed.

[0014] This input data may initially be a schema in the form of a UI schema, API schema, DB schema, ETL schema, or the like. In this case, the step of converting to a schema is omitted and the data is passed directly to the code generator.

[0015] [2] Next, the parsed input data is converted into a format such as a UI schema, API schema, DB schema, or ETL schema in the schema generation section. These schemas are the basis for generating source code and test code for the entire software, and not all of these schemas are required.

[0016] [3] The various schemas converted by the schema generation unit are passed to the code generation unit, which uses predefined templates and common modules to generate source code and test code based on each schema. This ensures consistency between source code and test code across platforms, improving development efficiency and maintainability.

[0017] [4] The generated source code and test code are then verified by the code analysis department using static analysis tools such as lint. The code analysis department uses machine learning models and rule-based systems to check the quality and consistency of the generated code. This process prevents bugs from occurring and improves software reliability. [Effects of the Invention]

[0018] [1] Conventional technologies often generate only specific parts (e.g., API or database definitions), making it difficult to maintain consistency across the entire system. This invention integrates the UI, API, DB, and ETL schemas, making it possible to generate consistent code across the entire software. Maintaining consistent designs and principles prevents design errors and bugs. It also makes it easier for new developers to understand the code when joining a project.

[0019] [2] Using reusable common modules makes maintenance and adding new features easier. Furthermore, updates to common modules are reflected in the entire code base, improving the efficiency of maintenance work such as upgrading the languages ​​and frameworks used. The larger the project, the greater the maintainability, and common modules can be easily reused in other projects, dramatically improving development efficiency.

[0020] [3] Combining rule-based generation from schemas with machine learning models and heuristic algorithms increases test coverage for the entire software and enables comprehensive test cases for complex cases, which enables early detection and correction of bugs and improves software quality.

[0021] [4] While natural language processing is used to automatically generate source code, the use of natural language processing to automatically generate schemas in this invention makes it possible to maintain consistent software quality even in large-scale software development. Furthermore, by combining optical character recognition (OCR) technology, it is possible to support a variety of input formats, such as PDFs and image files, making it possible to easily generate schemas from various data sources while maintaining the quality of the source code. [Brief explanation of the drawings]

[0022] [Figure 1] Block diagram showing a full-stack schema-driven development system. [Figure 2] 1 is a block diagram illustrating a system for generating a schema from user input. [Figure 3] 1 is a block diagram illustrating a system for generating code from a schema. [Figure 4] FIG. 1 is a diagram showing an example of a UI schema. [Figure 5] FIG. 1 is a diagram showing an example of an API schema. [Figure 6] FIG. 1 is a diagram showing an example of a DB schema. [Figure 7] FIG. 1 is a diagram showing an example of an ETL schema. [Figure 8] 10 is a flowchart showing a schema generation process of the system according to the present embodiment. [Figure 9] FIG. 10 is a diagram showing an example of a schema generated from a schema input. [Figure 10] A diagram showing an example of a schema generated from input of a PDF file. [Figure 11] FIG. 1 is a diagram showing an example of a schema generated from natural language input. [Figure 12] 10 is a flowchart of a code generation process of the system according to the present embodiment. [Figure 13] A diagram showing an example of code generated from a UI schema. [Figure 14] FIG. 10 is a diagram showing an example of code generated from an API schema. [Figure 15] FIG. 10 is a diagram showing an example of code generated from a DB schema. [Figure 16] FIG. 10 is a diagram showing an example of code generated from an ETL schema. [Figure 17] A diagram showing that a schema can be expressed in various forms. DETAILED DESCRIPTION OF THE INVENTION

[0023] <1. Overview of the embodiment> The present invention relates to a full-stack schema-driven development system and method, Using a schema defined in any known or future-developed format (e.g., YAML, JSON, XML, Protobuf, Avro, and other suitable formats), By defining schemas, including but not limited to UI schemas, API schemas, DB schemas, ETL schemas, and using predefined templates and reusable common modules that contain business logic and components, Based on any known or future-developed design methodology (e.g., Clean Architecture, Onion Architecture, Layered Architecture, MVC, MVVM, VIPER, TCA, Redux, Atomic Design, and other suitable design methodologies), A system is provided that consistently generates source code and test code for the entire software that corresponds to any computing platform (e.g., web, mobile, desktop application, and other platforms) now known or developed in the future.

[0024] Additionally, inputs for generating a schema in the present invention include natural language, schema files, GUI tools, Excel files, text files, CSV files, databases, REST APIs, GraphQL, cloud storage, IoT devices, user form inputs, spreadsheets, image files, PDF files, and other suitable methods.

[0025] In this invention, schema generation from image files and PDF files is performed using optical character recognition (OCR) technology, which extracts text data from these files and analyzes it to convert it into a schema.

[0026] In addition, in the present invention, when the input for generating a schema is natural language, natural language processing (NLP) techniques are used to analyze the text data and convert it into a schema. In this case, machine learning models and heuristic algorithms are used to analyze the intent of the input data and convert it into an appropriate schema format. Specifically, it utilizes the latest deep learning models such as BERT (Bidirectional Encoder Representations from Transformers) and GPT (Generative Pre-trained Transformer), which enable highly accurate analysis of user input intent and improve the accuracy and efficiency of schema generation.

[0027] The present invention will now be described in more detail with reference to the accompanying drawings, in which preferred embodiments are shown, but which may be embodied in many different forms and are not limited to the embodiments set forth herein.

[0028] For example, in this embodiment, the configuration, operation, etc. of a full-stack schema-driven development system will be described, but similar effects can be achieved by a device having similar functions, a method executed by the device, a computer program that causes a computer device to execute the method, etc. The program may be provided as a non-transitory computer-readable recording medium, or may be provided so as to be downloadable from an external server.

[0029] Furthermore, in this embodiment, an example of generating source code and test code for software designed with onion architecture, DDD, VIPER, and atomic design, which is generated using Swift and Typescript using a UI schema, API schema, DB schema, and ETL schema in YAML format, is described. However, similar effects can also be achieved using schemas with similar functions, other programming languages, frameworks and design methods, methods executed by devices, computer programs that cause computer devices to execute methods, etc. The program may be provided as a computer-readable non-transitory recording medium, or may be provided so as to be downloadable from an external server.

[0030] In addition, in this embodiment, we also explain user input using a different format of schema, a PDF file, or natural language as means for generating a schema in the present invention, but similar effects can also be achieved by a method executed by a device with similar functions, a computer program that causes a computer device to execute a method, etc. The program may be provided as a computer-readable non-transitory recording medium, or may be provided so as to be downloadable from an external server.

[0031] In the following embodiments, the term "unit" may include, for example, a combination of hardware resources implemented by a broadly defined circuit and software information processing that can be specifically realized by these hardware resources. In this embodiment, "information" is represented by, for example, the physical value of a signal value representing voltage or current, the high or low value of a signal value as a binary bit set consisting of 0 or 1, or quantum superposition (so-called quantum bits), and communication and calculation can be performed on a broadly defined circuit.

[0032] A circuit in the broad sense is a circuit realized by appropriately combining a circuit, a processor, a memory, etc. For example, it is a circuit including any of a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), etc.

[0033] <2.Definition> In the present invention, a schema is a formalized structure for defining a data structure or software component, and is expressed in a format such as YAML, JSON, XML, Protocol Buffers, or Avro. For example, it is a guideline for describing each element of software, such as database structure, API endpoints, user interface, and mapping to external data sources. In normal schema-driven development, a schema is often used only for the purpose of defining an interface, but in the present invention, implementation details are also defined and used in addition to the interface. FIG. 17 shows that the schema of the present invention can be defined in a number of formats.

[0034] In this invention, full-stack schema-driven development is an approach that consistently generates source code and test code throughout the entire software development process, regardless of multiple platforms or layers (e.g., front-end and back-end), based on a predefined schema notation. By using templates and common modules, development efficiency is improved and consistency is achieved across the entire software, reducing the burden on developers.

[0035] In the present invention, a UI schema is a schema that defines a user interface. Figure 4 shows an example of a schema that defines the items to be displayed on the screen, the information and status that the screen holds, and the APIs to be used. By specifying a screen template, it is possible to use layouts and designs that have already been built, and by specifying components in common modules or components created in templates, it is possible to simply write the definition of any screen.

[0036] In the present invention, an API schema is a schema that defines an application programming interface. Figure 5 shows an example of a schema that defines the items that the user interface retrieves from the database, as well as authorization checks and business logic that cannot be performed by the user interface. It is basically similar to the format used in traditional schema-driven development, but it is also possible to call functions for general-purpose business logic created in common modules and templates by writing their names in the schema, and transaction management, state transitions, and error handling are also simply written. This schema is not essential, as there is software that does not need to use this schema, such as software that does not communicate with the outside world through a network.

[0037] In the present invention, a DB schema is a schema that defines a database structure. Using Figure 6 as an example, define the table name in the database, the name, type, and number of digits of each column, etc. This schema is not essential because there is software that does not need to use this schema, such as software that does not use a database.

[0038] In the present invention, an ETL schema is a schema that defines collaboration with an external data source. Using Figure 7 as an example, we define the link destination and item mapping to external data sources. In the corporate software development market, where collaboration with other companies' services is required, it is necessary to connect large amounts of data items using various means (e.g., API, CSV, email, etc.). By using the ETL schema, there is no need to implement each item for integration one by one, and it is also possible to generate test code according to patterns. This schema is not mandatory because there is software that does not need to use this schema, for example, software that does not link with external data sources.

[0039] In this invention, onion architecture is a type of software design that emphasizes an inward orientation of source code dependencies, centered around the domain layer, application layer, infrastructure layer, and presentation layer. Because each layer is independent, it facilitates unit testing and is a design method that realizes flexible and maintainable software development. In this embodiment, the onion architecture is adopted, but in reality, it is not essential because other designs such as clean architecture or layered architecture may be used depending on the requirements and scale of the project.

[0040] In this invention, Domain Driven Design (DDD) is an approach that focuses on the business domain (area) for design and development. It is introduced to further subdivide the domain layer, which is the core of the onion architecture mentioned above, and improve the readability and maintainability of the source code. Entity: An object with a unique identifier (ID) and a life cycle. ValueObject: An immutable object that does not have a unique identifier (ID). Factory: An object responsible for generating objects of complex structures. Repository: Repository interface Service: Service interface Policy: Policy interface

[0041] In this invention, VIPER is a method for implementing screens by separating them into different responsibilities, and is composed of the following five elements: View: displays the user interface and receives user input Interactor: Processes business logic, retrieves data, and stores it Presenter: Manages data exchange and provides UI logic Entity: Defines the structure and attributes of the data Router: Manages screen transitions and navigation Since the screen display, processing, and status are defined in the UI schema, it is possible to generate source code and test code even with other development methods such as MVC, MVVM, and Redux, so this design is not required.

[0042] In this invention, atomic design is a method for building a design system, and is composed of the following five layers: Atoms: Basic UI elements such as buttons and input fields Molecules: Small UI elements that combine multiple Atoms Organisms: More complex UI elements that combine multiple Molecules Templates: Place Organisms and layout the page · Pages: Enter specific data into Templates to create actual pages In this embodiment, Atoms and Molecules are defined in a common module, and are called by defining them in a UI schema. In addition, Templates for screens defined in the UI schema as Pages are also called, assuming they are defined in templates or common modules. In other words, the Page defined in the UI schema uses the specified Template, so all that remains is to define the contents of the specified Organisms and the values ​​to be passed to the common components Atoms and Molecules in the UI schema. In this embodiment, atomic design is introduced to simply describe the UI schema, but this is not an essential design method for the present invention.

[0043] In this invention, a template is a file that serves as the basis for the source code and test code to be generated. A file is generated for each language and library, and the actual source code and test code are generated by embedding code corresponding to the items defined in the schema into each template. There are also templates for general-purpose screen components and more detailed templates such as test code for each pattern, and depending on the schema definition, there are also patterns where values ​​are embedded in these and then embedded in the template for the entire file.

[0044] In the present invention, a common module is a group of source code that compiles screens, business logic, etc., outside the scope of the software to be generated. Depending on the schema definition, it is possible to call some of the subdivided common modules, which allows for reuse and allows for the definition of a simple schema. Initially, there will be some screens and business logic that are not fully covered, but by adding generic implementation to the common module, the common module can be reused on other screens or in other software.

[0045] In the present invention, a declarative UI is one of the methods for designing and implementing a user interface, and recent examples include React, Vue.js, SwiftUI, and JetpackCompose. In this embodiment, it is used because it is compatible with the schema definition, but it is not essential.

[0046] <3. Functional configuration> Next, the functional configuration of this embodiment will be described. FIG. 1 is a block diagram showing the configuration of a full-stack schema-driven development system according to this embodiment. If the user input 100 is not a schema in this embodiment, a schema generating unit 101 generates a schema 102 . By using the schema in the user input 100 or the schema 101 generated above, a code generation unit 103 generates source code 104 and test code 105 .

[0047] FIG. 2 is a block diagram illustrating a system for generating a schema from user input. This is a detailed configuration of the schema generation unit 101 in FIG. 1, which is the same as the schema generation unit 210 in FIG.

[0048] When a user input 200 occurs, a user input analysis unit 211 analyzes the content. It analyzes whether the input is a schema that can be used as is, a CSV file with a well-defined format, natural language, or a file such as an image or PDF. If necessary, OCR technology and natural language processing will be used, and then the optimal conversion method for generating a schema from the acquired data will be determined.

[0049] The method for determining the optimal conversion method for the data obtained from the user input 200 may be designed arbitrarily, but for example, a classification model that takes various attributes such as file format, length, and data content as input and outputs corresponding conversion method segments may be created using machine learning and stored in a database DB, and attribute information of the data obtained from the user input 200 may be input into this model to perform classification.

[0050] Such a classification model can be created by training a known model with multiple datasets consisting of combinations of various input attributes and corresponding conversion method segments. The model configuration can be determined arbitrarily, and for example, a support vector machine, a multilayer perceptron, a neural network model, or the like can be used. Alternatively, classification may be performed based on rules determined in advance according to the acquired data, or by clustering. Once the optimal conversion method for the user input 200 has been determined, the schema conversion unit 212 executes the determined conversion process.

[0051] For example, if the data acquired from user input 200 is a CSV data table, if there is no similar DB schema, DB schema 222 is generated as a possibility of creating a new database, and if there is already a similar DB schema, ETL schema 223 is generated, predicting that it will be linked to an external data source.

[0052] For example, if the data obtained from the user input 200 is in natural language, natural language processing can be used to create keywords, and the corresponding schema can be output from items that match the title or other values ​​defined in a previously created schema. Further adjustments in natural language or direct editing of the schema can be made to meet the software requirements desired by the user.

[0053] Existing technologies for generating source code from natural language do not guarantee the quality or consistency of the output source code, and there are limitations to their use. By inserting instructions called schemas between natural language and source code, it is possible to develop software in natural language while maintaining the quality of design, security, layout, etc.

[0054] FIG. 3 is a block diagram illustrating a system for generating code from a schema. This is a detailed configuration of the code generation unit 103 in FIG. 1, and is the same as the code generation unit 310 in FIG.

[0055] In this embodiment, a generation procedure will be described for the case where the code generation unit 310 is called when the UI schema 300, API schema 301, DB schema 302, and ETL schema 303 all exist. The schema analysis unit 311 determines the type of schema the schema is, and then checks the schema definition to see if the schema is written according to predetermined rules, and if there are any invalid characters or validation problems in the key or value parts. Then, select the template file to generate code using that schema, select the common modules to import, and confirm the directory structure of the output destination. If any problem occurs during the process, an error message is displayed to the user and the process is terminated.

[0056] The file generation unit 312 copies the selected template file and generates it by embedding file names, class names, etc. based on the table names and page names described in the schema. Embed import statements for common modules and between files into the generated files as needed.

[0057] The code conversion unit 313 embeds more detailed source code based on the schema definition. Embed a list of variables and functions in the source code according to the schema definition. If necessary, embed the processing and screen of the common module in the code and pass the values ​​described in the schema. Once the source code is generated, the associated test code is generated. Basically, source code and test code are embedded based on rules, but it is also possible to embed source code and test code using machine learning. For example, by using natural language processing to analyze the source code and schema for test cases selected based on rules, it is possible to output more optimal test code. If necessary, it is also possible to automatically register it as a new test case.

[0058] The code analysis unit 314 checks all generated source code for problems using static analysis tools such as lint, and makes full use of code formatting technology to rearrange the order of import statements and automatically format the source code to make it more readable.

[0059] The generation results and a list of the generated source code 320 and test code 321 are displayed to the user. If any problem occurs during the process, an error message is displayed to the user and the process is terminated. By using a source code version control tool, it is also possible to return the directory to the state it was in before execution began. If necessary, it is also possible to run test code, upload differences using a source code version control tool, and proceed with the deployment process using CI / CD.

[0060] In this embodiment, we describe a process for generating all directories, files, etc. based on a given schema, but in reality, it is also possible to check the differences in schema files that have been changed and generate or delete source code and test code that correspond to those differences. Therefore, the embodiment is not limited to a specific one, and the code generation process may be performed in a batch, partially, or in real time.

[0061] These are specific implementations of software-based information processing using hardware. Note that each component may be distributed across multiple computers, and a full-stack schema-driven development system may be configured using multiple computers. While this embodiment presents an example in which this development system is implemented on the developer's hardware, in practice both the code generation component and the schema generation component may be configured on a network.

[0062] <4. Schema generation procedure> First, the overall procedure for generating a schema from a schema input will be described as shown in FIG.

[0063] First, in step S11, the user input acquisition unit acquires input data from the user terminal. The input data can be provided in various formats, such as natural language, schema files, image files, PDF files, CSV files, text files, Excel files, databases, REST APIs, GraphQL, cloud storage, IoT devices, user form input, and spreadsheets.

[0064] In step S12, the acquired data is analyzed to determine the schema to be generated, using a machine learning model, heuristic algorithm, rule-based system, or the like. For example, natural language processing technology can be used to analyze text data. OCR technology can also be used to analyze text data from images and PDF files. Specific analysis methods are shown below.

[0065] In step S13, a template to be used for generation is selected based on the analyzed user input. Specifically, the optimal template is selected based on the analysis results from templates corresponding to each schema format (UI schema, API schema, DB schema, ETL schema, etc.). For example, for a UI schema, you select a template that defines the screen layout and UI components, and for an API schema, you select a template that defines the endpoints and HTTP methods.

[0066] In step S14, the parsed user input is converted into a schema for the selected template. Specifically, the user input data is appropriately mapped and converted into a schema format according to the structure of the selected template. For example, in the case of an API schema, user-entered data is embedded into the endpoints and parameters defined in the template.

[0067] In addition, by training a machine learning model on datasets containing schema files containing metadata such as title, description, and keyword, natural language collected from actual development projects, various user input data such as CSV files, Excel files, and PDF files, and manually created and labeled schemas corresponding to each input data, it is possible to analyze the natural language input by users and, based on that, map the optimal items for each schema type (UI schema, API schema, DB schema, ETL schema).

[0068] Specifically, it uses decision trees, random forests, SVMs (Support Vector Machines), etc. to select the optimal schema conversion method based on the attributes of user input. Use linear and non-linear regression models to optimize the schema generation process.

[0069] This process makes it possible to automatically generate the optimal schema for the requirements and specifications entered by the user. For example, if a user enters "I want to create a product detail page," the trained model analyzes that intent and generates a UI schema that includes items such as product images, product names, prices, and stock status. Similarly, the API schema automatically defines the endpoints and required parameters of the product details API, and the DB schema automatically sets the structure of the product database table. This saves developers the trouble of manually writing schemas.

[0070] As shown in Figure 9, a specific method for analyzing input schema files is to check the file format if the input data is a schema file (e.g., YAML, JSON, XML). For example, if the schema file is in YAML format, use a syntax analysis tool to verify the validity of the file. Next, select the appropriate template, which corresponds to the schema format (UI schema, API schema, DB schema, ETL schema, etc.) and apply the template based on the contents of the schema file. Generate a schema based on a selected template. For example, use the API Schema template to generate an API schema including endpoints, HTTP methods, parameters, response formats, etc.

[0071] As shown in Figure 10, a specific method for analyzing input PDF files or image files is to use OCR technology to extract text data when the input data is a PDF file or image file. OCR technology is a technology that reads character information from images and is used to extract text data from PDF files and image files. The extracted text data is then analyzed. For example, if the extracted text contains a database table definition, the content is analyzed to select an appropriate template. Generate a schema based on an appropriate template. For example, use a DB schema template to generate a DB schema including items such as table names, column names, data types, and constraints.

[0072] As shown in FIG. 11, as a specific method for analyzing input in natural language, when the input data is in natural language, the input data is analyzed using natural language processing. Next, select the appropriate template. For example, if the user enters "I want to create a user details screen," select the UI schema template. Generate a schema based on the analysis results. For example, use a UI schema template to generate a UI schema including screen layout, UI components, data bindings, etc.

[0073] Furthermore, to parse Excel or CSV files, data frame techniques (e.g., the Pandas library) can be used to read the data and generate a schema by selecting an appropriate template. For example, read data from a CSV file, extract column names, and apply them to a DB schema or ETL schema template.

[0074] For input data from a REST API or GraphQL, it parses the API specification (e.g., Swagger or GraphQL schema) and generates an API schema. This involves extracting the endpoint, request parameters, response format, etc. and applying them to the appropriate template.

[0075] For data from cloud storage or IoT devices, it parses the storage API or device data format and generates an appropriate schema. For example, it retrieves JSON data from cloud storage, analyzes the data structure, and generates a schema.

[0076] For data from user form inputs or spreadsheets, it parses the input data and generates a schema based on the appropriate template. Specifically, the contents of input fields and cells are extracted and converted into a schema. This allows you to not only generate DB schemas and ETL schemas, but also UI schemas and API schemas to be used as input forms as needed.

[0077] <5. Code generation procedure> Next, the overall procedure for generating code from schema input will be described, as shown in FIG.

[0078] In step S21, schema data input by the user is received. The schema data is provided in the form of a UI schema, an API schema, a DB schema, an ETL schema, or the like.

[0079] In step S22, the schema analysis unit analyzes the received schema. Specifically, it determines the type of schema (UI, API, DB, ETL), selects a template file, selects a common module, and confirms the directory structure of the output destination. It also checks for invalid characters and validation issues. For example, in the case of an API schema, it checks whether the endpoints, request parameters, and response formats are correctly defined.

[0080] In step S23, an appropriate template is selected based on the analysis results. The template corresponds to each schema format (UI schema, API schema, DB schema, ETL schema), and the template is applied based on the schema content. For example, for an API schema, you select a template that defines the endpoints and HTTP methods, and then map the schema information to the template.

[0081] In step S24, the file generation unit copies the selected template file and embeds the information described in the schema to generate source code and test code. Specifically, it maps the data described in the schema appropriately according to the structure of the template file, and generates file names, class names, import statements, etc. For example, in the case of an API schema, user-entered data is embedded into the endpoints and parameters defined in the template, and API source code including the endpoints, request parameters, and response format is generated. It also generates appropriate import statements for common modules and creates directories as needed.

[0082] In step S25, the code conversion unit embeds more detailed source code and test code based on the schema definition. Specifically, a list of variables and functions is embedded in the source code according to the schema definition, and common module processing and screens are embedded in the code as needed, passing the values ​​described in the schema.

[0083] The selected template is based on software development principles and design, with clear division of responsibilities for each file, making it easy to select test code for rule-based unit and integration tests that apply to variables, functions, and components. Furthermore, because the source code complies with the design, the machine learning model can learn the test code subdivided by responsibility and the corresponding schema, which can be combined with automatic generation of test code, making it possible to create more robust software. By using a heuristic algorithm to define the flow that needs to be tested for each pattern, E2E test code can also be generated from the schema.

[0084] In step S26, the code analysis unit performs a quality check on all the generated source codes using a static analysis tool (such as lint). Specifically, it detects and corrects code syntax errors, style guide violations, invalid import statements, and more. In addition, it makes full use of code formatting technology to automatically rearrange the order of import statements and format source code for greater readability. For example, the generated API source code is checked for syntax errors using ESLint and the code style is unified using an automatic formatting tool.

[0085] Figure 13 is an example of the source code generated from the UI schema of Figure 4 through this procedure. This shows the front-end source code that is placed in the presentation layer of the onion architecture and generated as a view in VIPER. In addition, if the design is done in VIPER, the UI schema also generates source code for the Interactor, Presenter, Entity, and Router, as well as the associated test code. In the case of MVC, code corresponding to the View and Controller is generated, and in the case of MVVM, code corresponding to the View and ViewModel is generated. The UI schema also generates source code for use cases in the application layer, repository interfaces in the domain layer, and repositories in the infrastructure layer.

[0086] FIG. 14 is an example of source code generated from the API schema of FIG. 5 through this procedure. Of the front-end source code, it is placed in the domain layer of the onion architecture and generates entities, value objects, factories, etc. Of the backend source code, Controllers and Routes are generated in the presentation layer of the onion architecture, and source code corresponding to use cases in the application layer, repository interfaces in the domain layer, and repositories in the infrastructure layer is also generated.

[0087] FIG. 15 is an example of source code generated from the DB schema of FIG. 6 through this procedure. This shows the back-end source code placed in the domain layer of the onion architecture and generated as an Entity in DDD. It also shows the infrastructure layer generated as a schema definition in Prisma.

[0088] FIG. 16 is an example of the source code generated from the ETL schema of FIG. 7 through this procedure. This shows the backend source code that is placed in the infrastructure layer of the onion architecture and generated as entities and mappers for external data sources. [Explanation of symbols]

[0089] 100: User input 101: Schema generation section 102: Schema 103: Code generation unit 104: Source code 105: Test code 200: User input 210: Schema generation section 211: User Analysis Department 212: Schema conversion section 220: UI Schema 221: API Schema 222:DB Schema 223: ETL Schema 300: UI Schema 301: API Schema 302:DB Schema 303 : ETL Schema 310: Code generation unit 311: Schema Analysis Unit 312: File generation unit 313: Code conversion section 314: Code analysis section 320: Source code 321: Test code

Claims

1. Using a schema defined in any known or future-developed format (e.g., YAML, JSON, XML, Protobuf, Avro, and other suitable formats); By defining schemas including but not limited to the following categories and using predefined templates and common reusable modules containing business logic and components, Based on any known or future-developed design methodology (e.g., Clean Architecture, Onion Architecture, Layered Architecture, MVC, MVVM, VIPER, TCA, Redux, Atomic Design, and other suitable design methodologies); A method for consistently generating source code and test code for an entire piece of software for any computing platform (e.g., web, mobile, desktop application, and other platforms) now known or developed in the future: UI Schema: Defines the user interface ・API schema: defines the application programming interface ・DB schema: defines the database structure ・ETL schema: defines the connection with external data sources This includes, but is not limited to, any other schema.

2. 2. The method according to claim 1, wherein the source code and test code of the entire software can be generated regardless of whether the schema format is YAML, JSON, or XML.

3. In the method of claim 1, the algorithm for generating test code in response to source code generated using a schema includes, but is not limited to, machine learning models, heuristic algorithms, rule-based systems, and other suitable methods. The schema may include cases where multiple schemas are integrated or where the schema is subdivided.

4. 10. The method of claim 1, wherein source code and test code are generated based on individually defined schemas without using common modules.

5. 2. The method according to claim 1, wherein the source code for the entire software can be generated even if the UI schema, the API schema, the DB schema, and the ETL schema are not all available.

6. In the method of claim 1, inputs for generating a schema include, but are not limited to, natural language, a schema file, a GUI tool, an Excel file, a text file, a CSV file, a database, a REST API, GraphQL, cloud storage, an IoT device, a user form input, a spreadsheet, an image file, a PDF file, and other suitable methods.

7. In the method of claim 6, the natural language processing algorithm for analyzing the natural language input includes, but is not limited to, machine learning models, heuristic algorithms, rule-based systems, and other suitable methods.

Images