Software design specification checking system, method, equipment and medium

By designing a software design specification inspection system, the source code is automatically checked by using command parser, file searcher and code inspector, solving the problem of inefficient manual inspection caused by frequent updates of software design specifications, and achieving the effect of quickly discovering code design problems and improving code comprehensibility.

CN119861904APending Publication Date: 2025-04-22TRAVELSKY TECHNOLOGY LIMITED
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411896136.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-20
Publication Date
2025-04-22

AI Technical Summary

Technical Problem

Due to the complex functions of the software and the diverse business scenarios, the software design specifications need to be constantly revised and updated, which requires a lot of human resources to be consumed for manual inspection, which is inefficient.

Method used

Design a software design specification inspection system, including command parser, file searcher and code inspector, to conduct comprehensive inspection of source code through automated means, generate inspection result data and generate reports.

Benefits of technology

Reduce the repetitive work of code review, promptly discover software code design problems, reduce the difficulty of code maintenance, and promote the unification of software code design specifications, and improve the comprehensibility of software code.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119861904A_ABST
    Figure CN119861904A_ABST
Patent Text Reader

Abstract

The invention belongs to the technical field of software development, and provides a software design specification checking system, method and device and a medium, and the system comprises a command parser which is used for responding to an input operation of a user, obtaining an instruction, and extracting a file directory or file information of a source code according to the instruction; the file searcher is used for searching and acquiring a source code file according to the file directory or the file information and generating source code data; the code inspector is used for inspecting the source code data according to a predefined software design specification and generating inspection result data; wherein the check result data comprises first check result data, second check result data, third check result data and reference state data; the source code is comprehensively checked according to the predefined software design specification, so that the repeated work of code review can be reduced, the software code design problem can be found in time, and the code maintenance difficulty is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of software development, and in particular, relates to a software design specification checking system, method, device and medium. Background Art

[0002] Software design specifications are an integral part of the software development process, covering a wide range of aspects, from naming specifications, code style specifications, modular design specifications to performance optimization specifications, security specifications, document design specifications, etc. Following these specifications helps improve the quality, maintainability, and security of the software.

[0003] As software functions become more complex and the amount of software code increases, a series of software design specifications need to be formulated to improve software quality and stability. However, due to the diversity and complexity of business scenarios, programming languages, frameworks, libraries, etc., security specifications need to be constantly revised and updated, resulting in the need to consume a lot of human resources to perform manual inspections. Summary of the invention

[0004] In view of the problems in the background technology, the present disclosure proposes a software design specification checking system, method, device and medium to replace repetitive manual checking.

[0005] In order to achieve the above objectives, the present disclosure adopts the following technical solutions:

[0006] In a first aspect, the present disclosure provides a software design specification checking system, comprising: a command parser, a file searcher, and a code checker;

[0007] A command parser, used to respond to user input operations, obtain instructions, and extract the file directory or file information of the source code according to the instructions;

[0008] A file searcher, used to search and obtain source code files according to the file directory or the file information, and generate source code data;

[0009] The code checker is used to check the source code data according to predefined software design specifications and generate check result data; wherein the check result data includes: first check result data, second check result data, third check result data and reference status data.

[0010] Preferably, the system further comprises: a report generator, configured to generate an inspection result report according to the inspection result data.

[0011] Preferably, the code checker includes: a source code line checker, a reference relationship scanner, a code class checker and a rule matching checker; wherein,

[0012] The source code line checker is used to scan the source code line by line, check whether each line of code complies with the predefined software design specification, and generate first check result data;

[0013] The reference relationship scanner is used to scan the reference relationship of the class in the source code data and generate reference status data;

[0014] The code class checker is used to check the source code according to the class structure and generate second checking result data;

[0015] The rule matching checker is used to perform a rule matching check according to the reference status data, the first check result data and the second check result data, and generate third check result data.

[0016] Preferably, the code checker is also used to delete the source code data and the check result data after the check is completed.

[0017] Preferably, the code class checker includes: a class description parser, a class variable checker and a class function checker;

[0018] The class description parser is used to parse the class information in the source code data; wherein the information includes class variable information and class function information;

[0019] The class variable checker is used to check the class variable information according to a predefined software design specification;

[0020] The class function checker is used to check the class function information according to predefined software design specifications.

[0021] Preferably, the code class checker further includes an embedded class checker, and the embedded class checker is used for recursively calling the code checker to check the inner class if the source code data includes the inner class.

[0022] In a second aspect, the present disclosure proposes a software design specification checking method, comprising:

[0023] Responding to the user's input operation, obtaining instructions, and extracting the file directory or file information of the source code according to the instructions;

[0024] According to the file directory or the file information, search and obtain source code files to generate source code data;

[0025] The source code data is checked according to a predefined software design specification to generate check result data; wherein the check result data includes: first check result data, second check result data, third check result data and reference status data.

[0026] Preferably, the method further comprises: generating an inspection result report according to the inspection result data.

[0027] In a third aspect, the present disclosure proposes a device including a memory and a processor, wherein the memory stores computer instructions that can be executed on the processor, and when the processor executes the computer instructions, a software design specification checking method described in the first aspect is executed.

[0028] In a fourth aspect, the present disclosure proposes a computer-readable storage medium having computer instructions stored thereon. When the computer instructions are executed, a software design specification checking method described in the first aspect can be implemented.

[0029] Beneficial effects of the present disclosure:

[0030] The method disclosed in the present invention can reduce the repetitive work of code review, timely discover software code design problems, reduce the difficulty of code maintenance, and promote the gradual unification of software code design specifications to improve the comprehensibility of software code by comprehensively checking the source code according to pre-defined software design specifications.

[0031] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or be understood by implementing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures indicated in the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0033] Figure 1 The framework of the software design specification checking system disclosed in the present invention is shown Figure 1 ;

[0034] Figure 2 A framework diagram of a code checker disclosed in the present invention is shown;

[0035] Figure 3 A structural diagram of the source code of the present disclosure is shown;

[0036] Figure 4 A framework diagram of a code class checker disclosed in the present invention is shown;

[0037] Figure 5 The framework of the software design specification checking system disclosed in the present invention is shown Figure 2 ;

[0038] Figure 6 A schematic diagram of a command parser of the present disclosure is shown;

[0039] Figure 7 The source code of the present disclosure is shown Figure 1 ;

[0040] Figure 8 The source code of the present disclosure is shown Figure 2 ;

[0041] Fig. 9 The source code of the present disclosure is shown Figure 3 ;

[0042] Fig.10 A schematic diagram showing an inspection result report of the present disclosure is shown;

[0043] Fig.11 A flowchart of the software design specification checking system disclosed in the present invention is shown;

[0044] Fig.12 A schematic diagram of the device structure of the present invention is shown. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.

[0046] First, some technical terms involved in the embodiments of the present disclosure are introduced.

[0047] Specification checking refers to the process of checking the standardization of code engineering files. Specification checking is usually performed by batch scanning using specification checking tools.

[0048] refer to Figure 1-Figure 5 As shown, a software design specification checking system specifically comprises:

[0049] The command parser is used to respond to the user's input operation, obtain the instruction, and extract the file directory or file information according to the instruction; for example, refer to Figure 6 As shown, it uses the Windows / Linux command line parameter input method to obtain user operation commands, specify search directories, or check specified code files.

[0050] The file searcher is used to search and obtain source code files according to the file directory or file information, and generate source code data; specifically, when the command parser enters the specified search directory, the file searcher searches for all source code file information under the directory, caches it in the memory, and calls the subsequent code checker in sequence to perform software design specification checks. Source code data is a string array read into the system memory. If the source file has multiple lines, the array has multiple records. According to the sequence number of the array, the line number of the source code and the location of the violation error can be located. Source code data refers to reading the contents of the source file into the system memory and storing it in the form of a string array.

[0051] The code checker is used to check source code data according to predefined software design specifications and generate inspection result data; wherein the inspection result data includes: first inspection result data, second inspection result data, third inspection result data and reference status data; when the file searcher calls the code checker in a loop, it reads the content of a source code file each time and passes it to the code checker in the form of a multi-line string array, which also contains necessary information of the source code file, such as: file path, file name, project name, etc.

[0052] The reference status data is a fixed structure object that records the source code header and various reference information. For example, in JAVA source code, the information comes from multiple lines of import code; if it is C / C++ code, it comes from #include code.

[0053] For example, in JAVA, "import org.apache.commons.lang3.StringUtils" records the file code class and references the third-party StringUtils tool class. If the software design specification defines a rule "Only Apache's StringUtils are allowed, and other StringUtils are not allowed", then this application status data will trigger the checker to check the rule and determine whether the import line code contains the "apache" keyword.

[0054] The inspection result data is used to save the necessary information of the source code before each checker processes it, such as "software name", "module name", "package name", etc. During the inspection process, some temporary data for subsequent rule verification can be saved, such as "number of error logs", "number of variables", "number of certain feature variables", etc. After completing the entire class inspection, the inspection result information will be saved, for example, including descriptions of violation information, location information of violations, and other data used to generate inspection result reports.

[0055] Software design specifications are important guiding principles in the software development process, covering a wide range of aspects, from naming specifications, code style specifications, modular design specifications to performance optimization specifications, security specifications, document design specifications, etc. Following these specifications helps improve the quality, maintainability and security of the software.

[0056] The naming conventions mainly include the following aspects:

[0057] Function naming: The function name should accurately describe the function's function and avoid using meaningless or unclear verbs.

[0058] Variable naming: Variable names should clearly reflect the meaning of the data they represent. Avoid using names that are too short or vague.

[0059] Constant naming: Constant names usually use uppercase letters and can use underscores to separate words.

[0060] Macro naming: Macro naming should also follow certain rules to distinguish it from other identifiers.

[0061] File naming: File naming should reflect its content or function to facilitate finding and referencing.

[0062] The coding style specifications mainly include the following aspects:

[0063] Indentation and spaces: Specifies the indentation style of the code (such as whether to use spaces or tabs) and the rules for using spaces (such as between function parameters, on both sides of operators, etc.).

[0064] Line Breaking and Statement Length: Specifies line breaking rules for long statements and expressions, and the maximum length of each line of code.

[0065] Notes: Specify the format, location, and content requirements for notes to ensure that they are clear, accurate, and useful.

[0066] Code readability: Improve code readability through reasonable naming, indentation, spaces, and comments.

[0067] Modular design specifications mainly include the following aspects:

[0068] Module division: Divide the system into multiple independent modules according to the functional requirements of the software system, and each module assumes specific functions and responsibilities.

[0069] Module interface: defines the interfaces and dependencies between modules to ensure loose coupling between modules.

[0070] Module independence: Try to improve the independence of modules and reduce the interdependence and mutual influence between modules.

[0071] Performance optimization specifications mainly include the following aspects:

[0072] Performance indicators: Define the key performance indicators of the software system (such as response time, throughput, concurrency, etc.).

[0073] Performance analysis: Use performance analysis tools to analyze the software system and identify performance bottlenecks.

[0074] Optimization strategy: formulate corresponding optimization strategies for performance bottlenecks (such as algorithm optimization, data structure optimization, concurrency control, etc.)

[0075] Security specifications mainly include the following aspects:

[0076] Security requirements analysis: Conduct security requirements analysis in the early stages of software development to clarify the system's security requirements and threat model.

[0077] Security design: Consider security factors during the software design phase and design secure data transmission, storage, and access mechanisms.

[0078] Secure coding: Follow secure coding standards to avoid common security vulnerabilities (such as SQL injection, cross-site scripting, etc.).

[0079] Code review and testing: Ensure code quality and system security through code review and security testing.

[0080] Document design specifications mainly include the following aspects:

[0081] Design documents: including system overall design, module design, interface design and other documents, which are used to describe the overall architecture of the system and the functions of each module.

[0082] Development documentation: includes programming specifications, code comments, and other documents to guide developers in programming and code maintenance.

[0083] User documentation: includes user manuals, operation guides and other documents to help users understand and use the software system.

[0084] The report generator is used to generate an inspection result report based on the inspection result data. Fig.10 As shown, the inspection result report output in plain text contains information such as source code file information, violation information of the file, and code line number corresponding to the violation, which is derived from the inspection result data. It is understandable that the inspection result report can also be output in multiple forms such as JSON, XML, XLS, and even charts to display the report results.

[0085] As a preferred embodiment of the present disclosure, the code checker is also used to delete the source code data and the check result data after the check is completed. Specifically, the source code data and the check result data are temporary data generated in the entire process, and are destroyed and no longer saved after the check is completed. Among them, the check result data includes reference status data, that is, the reference status data will also be destroyed and no longer saved after the check is completed.

[0086] When the code checker is called, it triggers subsequent sub-checkers to complete different types of software design specification checks. Specifically, the code checker includes: source code line checker, reference relationship scanner, code class checker, and rule matching checker;

[0087] The source code line checker is used to scan the source code line by line, check whether each line of code complies with the predefined software design specification, and generate first check result data;

[0088] For example, define a design specification "Error log outputs brief information, and does not allow output of exception objects". Then, the checker scans the code line by line, finds the "LOGGER.error" keyword, locates the exception output statement, and then determines whether there is an exception object in the statement, so as to determine whether the line of code is in violation.

[0089] For example, if the design specification is defined as "not allowing too many debug logs to be output", then the checker scans the code line by line, finds the "LOGGER.debug" keyword, locates a debug statement output, and can add one to a counter in the "check result data". After the entire code scan is completed, it is determined whether the counter exceeds the specified limit and whether the file code violates the design specification. All violation records are first recorded in the "check result data" during the execution of the checker, waiting for the generation of the subsequent check result report.

[0090] The reference relationship scanner is used to scan the reference relationship of the class in the source code data and generate reference status data; the reference status data is used by the subsequent specification matching checker. Specifically, the reference relationship scanner is used to completely scan the corresponding code from the source code header until a class definition is found, triggering the subsequent device. During the scanning process, the reference relationship of the file class is recorded and stored in the reference status data. Figure 7As shown in the figure, the reference relationship scanner starts from the first line, scans to line 13, and finds that the external StringUtils tool is referenced; in line 15, it finds that the Date object is referenced; in line 16, it references the Pattern object... until it stops scanning at line 29, because the "class" keyword is found, the ValidUtils class is located, and the scanning ends. These scanned external reference relationship information indicate the external dependencies of the class, which can be used to determine whether the class meets the pre-defined software design specifications.

[0091] A code class checker, used for checking source code according to the class structure and generating second checking result data;

[0092] The rule matching checker is used to perform a rule matching check according to the reference status data, the first check result data and the second check result data, and generate third check result data.

[0093] For example, define the design rule "internal entity classes must not reference TAP interface objects", then obtain the "whether to reference TAP interface objects" attribute through the "reference status data", and then obtain whether the class belongs to the Entity internal entity class through the "check result data", and then determine whether the design rule is violated.

[0094] For example, if the design rule "the application layer is not allowed to directly access the database interface" is defined, the "whether the Dao interface class is referenced" attribute is obtained through the "reference status data", and then the "check result data" is used to obtain whether the class belongs to the Application layer class, and then determine whether the design rule is violated.

[0095] It is understandable that the source code line checker is generally used as the first check step, and the rule matching checker will complete the check at the end, but this does not strictly limit the startup order of each checker. In fact, the execution order between the various checkers can be flexibly arranged as needed. For example, the source code line checker can also be arranged to be executed last according to specific needs. Through a flexible execution order, it can more efficiently adapt to different inspection needs and scenarios, ensuring code quality while improving inspection efficiency.

[0096] In order to ensure that the code complies with the software design specifications, the code class checker performs a comprehensive check on the Java class through multiple subcomponents. Specifically, the code class checker includes: class description parser, class variable checker and class function checker;

[0097] For example, taking Java as an example: the components of a Java class mainly include the following aspects:

[0098] Package Declaration (optional): Use the package keyword to declare the package that the class is in. Packages are used to organize classes, prevent naming conflicts, and provide access control.

[0099] Import Statements (optional): Use the import keyword to import classes from other packages. This enables the current class to use these classes directly without using fully qualified class names.

[0100] Class Declaration: Use the class keyword followed by the class name to declare a class. The class name should start with a capital letter and follow the camel case naming convention.

[0101] Class modifiers (optional): Before the class declaration, you can add modifiers such as public, protected, private (but usually not used for class declarations, because private classes cannot be accessed by other classes, and protected classes have no meaning outside the package), final (indicating that the class cannot be inherited), abstract (indicating that the class is an abstract class), etc.

[0102] Class Body: The curly braces {} after the class declaration contain the class body, which contains all members of the class.

[0103] Member Variables (optional): Variables defined in a class, also called fields or properties. They can be of any type, including primitive data types and reference types. Member variables can be static (using the static keyword), indicating that they belong to the class itself rather than any specific object of the class.

[0104] Constructor (optional, but recommended to have at least one):

[0105] A special method used to initialize an object when it is created. The name of the constructor must be exactly the same as the class name and has no return type (not even void).

[0106] Methods (optional): Functions defined in a class that perform specific operations. Methods can access and modify member variables of a class. They can receive parameters and return results.

[0107] Initialization Blocks (optional): including instance initialization blocks (non-static) and static initialization blocks. These blocks are executed when an object is created (for instance initialization blocks) or a class is loaded (for static initialization blocks) to initialize class variables or perform necessary settings.

[0108] Inner Classes (optional): Classes defined inside another class. They can be static or non-static and can access members of the outer class (depending on the access modifier).

[0109] Interface implementation (if the class implements interfaces): If a class declares that it implements one or more interfaces, then it must provide implementations for all methods in the interfaces (unless the class is abstract).

[0110] Enumeration Types (special type of class, not all classes have):

[0111] In Java, enumeration is a special class used to represent a set of constants. Enumeration class implicitly inherits from java.lang.Enum class.

[0112] These components together define the structure and functionality of a Java class. Different classes may contain different components, depending on the purpose and design requirements of the class.

[0113] Reference Figure 3 As shown, the "file and reference relationship code" includes the "package declaration" and the "import declaration", the "class description code" includes the "class declaration" and the "class modifier", the "class variable code" is the "member variable" part, the "class function code" includes the "constructor" and the "method", and the "embedded class code" is the "inner class", which is a recursively nested structure and may contain one or more of the above-mentioned "class description code", "class variable code", "class function code" and "embedded class code".

[0114] The class description parser is used to parse the class information in the source code data; the information includes class variable information and class function information; for example, "public class PassengerEnum" can identify that the class is an Enum enumeration class; "public final class ValidUtil" can identify that the class is a Util tool class; "public class StatisticInfo implements ITable <statisticinfo>" indicates that the class implements the ITable interface. The key description information of these identified classes can be used to verify the software design specifications. For example, if the software design specification "the tool class must be placed in the util package" is defined, then when the subsequent "rule matching checker" finds that the class has the Util tool class attribute, it will determine whether the class is in the util directory, thereby finding out whether it is in violation.

[0115] A class variable checker is used to check class variable information according to predefined software design specifications; for example, refer to Figure 8 As shown in the figure, the software design specification is defined as "Log variable names are uniformly LOGGER". If it is found that the variable name declared in the Logger log class is not LOGGER, it is a violation.

[0116] A class function checker is used to check class function information according to predefined software design specifications; illustratively, refer to Fig. 9 As shown, the software design specification "Tool class functions must be modified with static" is defined. Then the checker obtains the attribute of the class from the "check result data" as a tool class, and then determines whether the current function has the "static" keyword, thereby determining whether the function violates the rules.

[0117] As a preferred embodiment of the present disclosure, JAVA source code supports inner classes. A class can nest an inner class, and an inner class can further nest inner classes. Therefore, the code class checker also includes an embedded class checker, which is used to recursively call the code checker to check the inner class if the source code data includes an inner class.

[0118] Based on the same inventive concept, Fig.11 As shown, a software design specification checking method specifically includes the following steps:

[0119] S1. Respond to the user's input operation, obtain instructions, and extract the file directory or file information of the source code according to the instructions;

[0120] S2. Search and obtain source code files according to the file directory or file information, and generate source code data;

[0121] S3, checking the source code data according to the predefined software design specification, and generating the checking result data; wherein the checking result data includes: first checking result data, second checking result data, third checking result data and reference status data;

[0122] S4. Generate an inspection result report based on the inspection result data.

[0123] Based on the same inventive concept, Fig.12 As shown, the present disclosure also proposes a device, including a memory and a processor, wherein the memory stores computer instructions that can be executed on the processor, and the processor executes the above-mentioned software design specification checking method when executing the computer instructions.

[0124] Based on the same inventive concept, the present disclosure also proposes a computer-readable storage medium on which computer instructions are stored. When the computer instructions are executed, the above-mentioned software design specification checking method can be implemented.

[0125] Among them, any reference to memory, storage, database or other media used in the embodiments provided by the present disclosure may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory.

[0126] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "includes a..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0127] Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.< / statisticinfo>

Claims

1. A software design specification checking system, characterized in that: include: command parser, file searcher, and code checker; A command parser, used to respond to user input operations, obtain instructions, and extract the file directory or file information of the source code according to the instructions; A file searcher, used to search and obtain source code files according to the file directory or the file information, and generate source code data; The code checker is used to check the source code data according to predefined software design specifications and generate check result data; wherein the check result data includes: first check result data, second check result data, third check result data and reference status data.

2. A software design specification checking system according to claim 1, characterized in that: The system further comprises: a report generator, configured to generate an inspection result report according to the inspection result data.

3. A software design specification checking system according to claim 1, characterized in that: The code checker includes: a source code line checker, a reference relationship scanner, a code class checker and a rule matching checker; wherein, The source code line checker is used to scan the source code line by line, check whether each line of code complies with the predefined software design specification, and generate first check result data; The reference relationship scanner is used to scan the reference relationship of the class in the source code data and generate reference status data; The code class checker is used to check the source code according to the class structure and generate second checking result data; The rule matching checker is used to perform a rule matching check according to the reference status data, the first check result data and the second check result data, and generate third check result data.

4. A software design specification checking system according to claim 3, characterized in that: The code checker is also used to delete the source code data and the check result data after the check is completed.

5. A software design specification checking system according to claim 3, characterized in that: The code class checker includes: a class description parser, a class variable checker and a class function checker; The class description parser is used to parse the class information in the source code data; wherein the information includes class variable information and class function information; The class variable checker is used to check the class variable information according to a predefined software design specification; The class function checker is used to check the class function information according to predefined software design specifications.

6. A software design specification checking system according to claim 5, characterized in that: The code class checker further includes an embedded class checker, and the embedded class checker is used to recursively call the code checker to check the inner class if the source code data includes the inner class.

7. A software design specification checking method, characterized in that: include: Responding to the user's input operation, obtaining instructions, and extracting the file directory or file information of the source code according to the instructions; According to the file directory or the file information, search and obtain source code files to generate source code data; The source code data is checked according to a predefined software design specification to generate check result data; wherein the check result data includes: first check result data, second check result data, third check result data and reference status data.

8. A software design specification checking method according to claim 7, characterized in that: The method further includes: generating an inspection result report according to the inspection result data.

9. A device comprising a memory and a processor, wherein the memory stores computer instructions that can be executed on the processor, characterized in that: When the processor runs the computer instructions, the software design specification checking method according to any one of claims 7 to 8 is executed.

10. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the computer instructions are executed, a method for checking software design specifications as described in any one of claims 7 to 8 can be implemented.