A multi-layer software framework, server and system construction method

Abstract

This invention discloses a multi-layered software framework, server, and system construction method. The framework includes a data layer, an element layer, a tag layer, an attribute layer, and a system layer. The data layer stores underlying data, and the element layer encapsulates the underlying data into element objects. Through inheritance, objects derived from the element class are used as instances of derived classes of the tag layer, attribute layer, and system layer, all based on the element class. By utilizing the inclusion relationships between objects in each layer, the complex system is decomposed into independent modules, achieving loose coupling between modules. This invention not only significantly reduces system complexity and maintenance difficulty but also enables the reconstruction of unmaintainable legacy systems into new systems within an advanced framework, achieving maintainability and evolvability.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a multi-layered software framework, server, and system construction method. Background Technology

[0002] In traditional software development practices, regardless of whether mainstream programming languages ​​such as Swift, Java, Go, Rust, Kotlin, C, C++, or Python are used, the core building block is a "class" or "struct". Developers need to pre-design and implement complex and sophisticated classes, and then generate specific application objects through instantiation. The advantages of this pattern are high precision in business model description, high code execution efficiency, and low system redundancy.

[0003] However, as the lifecycle of software systems lengthens, the shortcomings of this traditional model become increasingly apparent: First, there's the challenge of high coupling and operational difficulties: Systems built with complex class structures have extremely high coupling between their internal modules. During long-term operation and maintenance, the development team becomes deeply intertwined with the end users (or business processes). Once the original development team disbands or is replaced, the succeeding team faces a maze of code, with enormous costs to understand and modify. Even adding simple functionalities may become impossible, leading to the software becoming an unmaintainable "system orphan."

[0004] Secondly, there's the issue of technology stack lock-in and legacy systems: the programming language ecosystem is constantly evolving, with new and old languages ​​being replaced. For example, systems built in C++ or Java may face difficulties in maintaining them due to the lack of developers familiar with that language. It's nearly impossible for a Java team to take over a complex C++ project. Therefore, the rapid iteration of technology challenges the sustainability of language-specific systems.

[0005] Thirdly, user participation is low: Ideal software systems, especially those that need to operate continuously for decades or even centuries, should allow and even encourage end-users to participate in the adjustment and expansion of the system. However, in the traditional development model, any modification requires the intervention of professional developers, and users cannot assemble functional modules themselves like building blocks.

[0006] The disclosure of the above background information is only for the purpose of assisting in understanding the concept and technical solution of this application, and does not necessarily provide technical instruction. Summary of the Invention

[0007] The purpose of this invention is to provide a multi-layered software framework that decouples all data and functions of an application into standardized, independently manageable modules.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A multi-layered software framework, comprising: The data layer is configured to define data classes, and the data objects instantiated from the data classes are stored in the corresponding data containers. An element layer is configured to define element classes, wherein an element object instantiated from the element class encapsulates at least one data container object to hold data objects stored in the data container, and the element objects are stored in the corresponding element container. A tag layer is configured to define tag classes that inherit from the element class. Tag objects instantiated from the tag classes are configured to be unidirectionally replaceable element objects, wherein the tag objects are stored in the corresponding tag container. An attribute layer, configured to define attribute classes that inherit from the element class, wherein attribute objects instantiated from the attribute classes are configured to be unidirectionally replaceable element objects, and the attribute objects are stored in corresponding attribute containers; and The system layer is configured to define system classes that inherit from the element classes. System objects instantiated from the system classes are configured as unidirectional replaceable element objects, and the system objects are stored in the corresponding system containers. The system object can be constructed to include one or more of tag objects, attribute objects, and subsystem objects. The attribute object can be constructed to include one or more of tag objects and sub-attribute objects. The tag object can be constructed to include sub-tag objects.

[0009] Furthermore, following any or a combination of the aforementioned technical solutions, the data layer is further configured to define a data container class, wherein the data container is an object instantiated from the data container class; The element layer is also configured to define an element container class, wherein the element container is an object instantiated from the element container class; The tag layer is also configured to define a tag container class, wherein the tag container is an object instantiated from the tag container class; The attribute layer is also configured to define an attribute container class, wherein the attribute container is an object instantiated from the attribute container class; The system layer is also configured to define a system container class, wherein the system container is an object instantiated from the system container class; The tag container class, attribute container class, and system container class all inherit from the element container class.

[0010] Furthermore, based on any or a combination of the aforementioned technical solutions, the attribute layer includes a static attribute sublayer, wherein the attribute classes defined therein are static attribute classes, and the attribute container classes defined therein are static attribute container classes; The attribute layer further includes a dynamic attribute sublayer, which is configured to define a dynamic attribute class and a dynamic attribute container class. The dynamic attribute class inherits from the static attribute class, and the dynamic attribute container class inherits from the static attribute container class. The dynamic attribute object instantiated from the dynamic attribute class is configured to unidirectionally replace the static attribute object, and the dynamic attribute container object instantiated from the dynamic attribute container class is configured to unidirectionally replace the static attribute container object. The dynamic attribute object is stored in the dynamic attribute container instantiated from the dynamic attribute container class.

[0011] Furthermore, based on any or a combination of the aforementioned technical solutions, the tag object can be configured as a time item to record the time version information of the system object, attribute object, or main tag object currently containing the tag object; System objects, attribute objects, or main tag objects from different time versions can coexist. You can filter system objects, attribute objects, or main tag objects of a target version based on the time version information.

[0012] Furthermore, following any one or a combination of the aforementioned technical solutions, the data in the tag object is encrypted ciphertext data, and the key used for decryption is configured to be stored in different tag objects or outside the system where the software framework is located.

[0013] Furthermore, following any one or a combination of the aforementioned technical solutions, the tag layer is configured to define one or more tag classes of the following three types: The tag class of the incentive type, whose instantiated tag objects are configured as structural anchors, is used for the filtering logic of the subtree of derived class objects of the element class to achieve anchor filtering. The derived classes of the element class include tag classes, attribute classes and system classes. The tag class of the suppression type, whose instantiated tag objects are configured as structural anchors, is used for the filtering logic of the subtree of derived class objects of the element class to achieve exclusion filtering. The derived classes of the element class include tag classes, attribute classes and system classes. Neutral tag classes, whose instantiated tag objects are configured as structural anchors, are used for filtering logic of subtrees of derived class objects of element classes, and are not used for anchor filtering or exclusion filtering predefined by the framework.

[0014] Furthermore, based on any or a combination of the aforementioned technical solutions, the system object includes one or more of the following: tag objects, attribute objects, and subsystem objects, through combination, aggregation, or association relationships. The attribute object contains one or more of the following: tag object and sub-attribute object, through composition, aggregation, or association relationships. The tag object contains sub-tag objects through composition, aggregation, or association relationships.

[0015] Furthermore, following any one or a combination of the aforementioned technical solutions, the element object holds a data object stored within the corresponding data container object, including: The element object encapsulates the data container object and is associated with the data object stored within the data container by reference or inclusion.

[0016] Furthermore, based on any one or a combination of the aforementioned technical solutions, each container manages one or more corresponding objects; The tag layer, attribute layer, and / or system layer support empty containers and containers containing multiple objects.

[0017] Furthermore, in accordance with any or a combination of the aforementioned technical solutions, the element class and the data class inherit from the same object base class; And / or, the element container class and the element container class inherit from the same container base class.

[0018] Furthermore, following any one or a combination of the aforementioned technical solutions, the data object includes a name part and a data part, wherein the name part serves as an index of the data object, and the value data of the data part is a number, a string, or an arbitrary byte sequence; Both the name portion and the data portion are in binary data format.

[0019] Furthermore, following any one or a combination of the aforementioned technical solutions, the data layer, element layer, tag layer, attribute layer, and system layer are all configured to have editing permissions.

[0020] According to another aspect of the present invention, a server is provided, comprising the multi-layered software framework as described above, wherein the server manages or executes business logic on the data layer, element layer, tag layer, attribute layer and system layer of the multi-layered software framework.

[0021] Furthermore, based on any or a combination of the aforementioned technical solutions, the server manages the data layer, including: being responsible for the storage, retrieval, and CRUD operations of the underlying binary data objects; The server executes business logic on the element layer, tag layer, attribute layer, and system layer, including: encapsulating the underlying data into element objects, instantiating tag objects, attribute objects, and system objects, and managing the inheritance and inclusion relationships between objects; The server also manages the lifecycle of data containers, element containers, tag containers, attribute containers, system containers, and the inheritance relationships between container classes.

[0022] Furthermore, based on any or a combination of the aforementioned technical solutions, the system containing the multi-layered software framework includes a first subsystem and a second subsystem. The first subsystem includes a tag object configured with a first time item, and the second subsystem includes a tag object configured with a second time item. Based on the user's selection of the first time item and the second time item, the running permissions of the subsystem corresponding to the selected time item are enabled, and the running permissions of the subsystem corresponding to the unselected time item are disabled.

[0023] Furthermore, in accordance with any or a combination of the aforementioned technical solutions, the server is also configured with a security and key management module, which is configured to encrypt data in user-specified sensitive tag objects and store the key in an independent hardware security module or an external key management service, thereby achieving separation of key and data.

[0024] Furthermore, in accordance with any or a combination of the aforementioned technical solutions, the server provided by the present invention further includes an API gateway, which is configured to provide an interface to allow clients to create, read, update, delete various objects in the data layer, element layer, tag layer, attribute layer, and system layer of the multi-layered software framework, and to manipulate containers.

[0025] Furthermore, based on any one or a combination of the aforementioned technical solutions, taking the system object and its contained objects as the whole unit, and / or the attribute object and its contained objects as the whole object, and / or the tag object and its contained sub-tag objects as the whole object, the server supports copying the whole unit.

[0026] According to another aspect of the present invention, a system construction method based on the above-described multi-layered software framework is provided, comprising the following steps: Identify the fixed parameters that the system to be built needs to model and manage, as well as the states that need to be calculated, and plan the labels used for classification and control; A data container class is encapsulated to form an element class and instantiated, forming objects of derived classes derived from the element class as the common base class of the tag layer, attribute layer, and system layer. The derived classes include tag classes, attribute classes, and system classes. Data objects are instantiated for each piece of underlying information that needs to be stored. Each data object includes a name part and a data part and is stored in the data container object. The derived class objects of the element class are placed in the derived class objects of the element container class for management. The attribute layer is constructed as follows: For the fixed parameters, a static attribute class is instantiated to obtain a static attribute object, which is then associated with the corresponding data object, and the static attribute object is stored in a static attribute container; For the states that need to be calculated, calculation logic is configured for a dynamic attribute class, which inherits from the static attribute class, and the dynamic attribute class is instantiated, and the instantiated dynamic attribute object is stored in a dynamic attribute container. The tag layer is constructed as follows: instantiate a tag class for classification to obtain neutral tag objects; instantiate a tag class for control, and obtain incentive-type tag objects or inhibition-type tag objects according to business rules and / or activation logic; establish parent-child relationships between tag objects according to the system's modeling requirements to form a tag tree. The system layer is constructed in the following ways: instantiate a system class to obtain a root system object, and according to the system functional requirements, include the constructed attribute objects and tag objects into the root system object through combination, aggregation or association; and / or, instantiate a system class to obtain a subsystem object, and according to the system functional requirements, include the attribute objects and tag objects into the subsystem object, and include the subsystem object into the root system object.

[0027] Furthermore, any one or a combination of the aforementioned technical solutions is applicable to the reconstruction of existing legacy systems, including the following steps: Data and structure analysis of the old system is performed, including analyzing the table structure, views and stored procedures of the old system database, extracting key business data, configuration parameters and status values, and reversing the process to parse out fixed parameters, the states that need to be calculated and their calculation formulas, classifications, business rules and control points. In the restructured new system, clearly define the attribute objects and tag objects it contains; Construct a mapping table for the fixed parameters and states that need to be calculated in the old system: Based on the relationship between the attribute objects in the new system and the fixed parameters and states that need to be calculated in the old system, establish the mapping relationship between the tables and fields of the database in the old system and the corresponding data parts of the attribute objects in the new system; and based on the relationship between the tag objects in the new system and the classification and control points in the old system, establish the mapping relationship between the business rules of the old system and the type and filtering logic of the tag objects in the new system. For the fixed parameters of the old system, the field names and field values ​​in the database are instantiated as data objects and stored in a data container; the data objects are encapsulated to form derived class objects with the element class as the common base class of the tag layer, attribute layer and system layer, and stored in the element container. For fixed parameters in the mapping table, a static attribute class is instantiated to obtain a static attribute object, which is then associated with the data object corresponding to the fixed parameter and stored in the static attribute container. For states in the mapping table that need to be calculated, a dynamic attribute class is instantiated to obtain a dynamic attribute object, and the calculation logic of the dynamic attribute object is configured according to its calculation formula and stored in the dynamic attribute container. Based on the classification of the old system, instantiate a label class and create a neutral label object for classification; based on the association information of the business rules of the old system in the mapping table, instantiate an incentive-type label class or an inhibition-type label class and configure its filtering logic; store the label objects in the label container. Instantiate a root system object representing the functionality of the old system, and include the corresponding attribute objects and tag objects into the root system object through combination, aggregation or association; and / or, instantiate a subsystem object based on the functionality of the old system, and include the corresponding attribute objects and tag objects into the subsystem object through combination, aggregation or association, and include the subsystem object into the root system object.

[0028] The beneficial effects of the technical solution provided by this invention are as follows: a. The software framework defines the object model and the relationships between object models. Through clear inheritance and inclusion relationships between multi-layer object models, and using the element model as the common base class of the tag layer, attribute layer and system layer, the complex system is decomposed into independent modules, achieving loose coupling between modules and greatly reducing system complexity and maintenance difficulty. b. Tag objects, attribute objects, and system objects (subsystem objects) that are derived class objects of element classes can be easily removed, moved, and copied from the system tree, thereby overcoming the problems of tight coupling, high complexity, and technology dependence in traditional development models; c. It provides a systematic approach to refactoring unmaintainable legacy systems into standardized objects within this framework, offering a feasible path for the modernization and rebirth of "software orphans". Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, 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 recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A schematic diagram illustrating data classes and data objects in a data layer, provided as an exemplary embodiment of the present invention; Figure 2A schematic diagram illustrating the element classes and element objects of an element layer, provided as an exemplary embodiment of the present invention; Figure 3 A schematic diagram illustrating the tag class and tag object of the tag layer provided as an exemplary embodiment of the present invention; Figure 4 A schematic diagram illustrating attribute classes and attribute objects in an attribute layer, provided as an exemplary embodiment of the present invention; Figure 5 A schematic diagram illustrating system classes and system objects in the system layer, provided as an exemplary embodiment of the present invention; Figure 6 A schematic diagram illustrating the inheritance relationship between the element layer, tag layer, attribute layer, and system layer, provided as an exemplary embodiment of the present invention; Figure 7 A schematic diagram illustrating a data layer container class and a data container object is provided as an exemplary embodiment of the present invention. Figure 8 A schematic diagram illustrating an element layer container class and an element container object, provided as an exemplary embodiment of the present invention; Figure 9 A schematic diagram illustrating a container class and a tag container object for a tag layer, provided as an exemplary embodiment of the present invention; Figure 10 A schematic diagram illustrating the container class and attribute container object of the attribute layer provided as an exemplary embodiment of the present invention; Figure 11 A schematic diagram illustrating a system layer container class and a system container object is provided as an exemplary embodiment of the present invention. Figure 12 A schematic diagram illustrating the inheritance relationship between container classes at different layers is provided as an exemplary embodiment of the present invention. Figure 13 To inherit from Figure 4 A diagram illustrating the dynamic attribute class of a static attribute class; Figure 14 To inherit from Figure 10 A diagram illustrating the static property container class and the dynamic property container class; Figure 15 This is a schematic diagram illustrating the transformation of objects in the tag layer, attribute layer, and system layer at the element level, as provided in an exemplary embodiment of the present invention. Figure 16 A schematic diagram illustrating the inclusion relationship of system objects provided in an exemplary embodiment of the present invention; Figure 17 A schematic diagram illustrating the inclusion relationship of attribute objects provided in an exemplary embodiment of the present invention; Figure 18A schematic diagram illustrating the inclusion relationship of tag objects provided as an exemplary embodiment of the present invention; Figure 19 A structure tree diagram of a system built on a multi-layered software framework is provided as an exemplary embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0033] This invention aims to provide a bottom-up five-layer software framework structure, comprising a data layer, element layer, tag layer, attribute layer, and system layer. It defines the object models for each layer and the relationships between object models across different layers. Through clear inheritance and inclusion relationships between multi-layer object models, and using the element model as the common base class for the tag layer, attribute layer, and system layer, complex systems are decomposed into independent modules, achieving loose coupling between modules. Following the data layer, element layer, tag layer, attribute layer, and system layer structure and their relationship rules defined in this invention, regardless of the programming language used for underlying generation (such as existing programming languages ​​like Java, C++, Python, etc., or using a dedicated language like PSDL, i.e., Palados System Description Language), the standardized objects generated can be used by systems compatible with this framework. This means that the framework of this invention achieves decoupling from the implementation language. The software framework will be described below with specific rules and examples.

[0034] In one embodiment of the present invention, a multi-layered software framework is provided, comprising the following five layers: The data layer is configured to define data classes. Data objects instantiated from these classes are stored in corresponding data containers. Each data object contains a name and a data portion. The name serves as an index to the data object, and the data portion contains values ​​that are numbers, strings, or arbitrary byte sequences (e.g., binary data output by a sensor), existing in binary form. For example, name = "temperature", data portion value = "25.5". To clearly illustrate the relationship between the five layers, each layer is represented by a different diagram. The diagram for the classes and objects in the data layer is shown below. Figure 1 As shown, _psdlData (names with an underscore "_" before them can be simplified to Data) represents a data class, and psdlData (names without an underscore before them) represents a data object. This invention does not limit the use of a specific language PSDL. In the following text, data classes are simplified to Data, and data objects are simplified to Data.

[0035] The element layer is configured to define element classes. Element objects instantiated from these class encapsulate at least one data container object to indirectly hold data objects stored within that data container. The element objects are stored within their respective element containers. Each element object encapsulates a data container object and is associated with the data objects stored within it through reference or inclusion. The element class serves as the unified base class for all upper-level objects, which are the objects instantiated in the tag layer, attribute layer, and system layer discussed below. A diagram of the element layer's classes and objects is provided below. Figure 2 As shown, _psdlElement (named with an underscore "_") represents an element class, and psdlElement (named without an underscore) represents an element object. This invention does not limit the use of a specific language PSDL. In the following text, element class is simplified to Element, and element object is simplified to Element.

[0036] The tag layer is configured to define tag classes that inherit from the element class. The core definition of inheritance ensures that anywhere in the program an element object is instantiated using the element class, it can be replaced by an instantiated object of the tag class (i.e., a tag object). This replacement is unidirectional and does not change the correctness of the program. In other words, the tag objects instantiated from the tag class are configured to unidirectionally replace element objects, and these tag objects are stored in their corresponding tag containers. A diagram of the tag layer's classes and objects is shown below. Figure 3As shown, _psdlDimension (with an underscore "_" before the name) represents a tag class, and psdlDimension (without an underscore before the name) represents a tag object. This invention is not limited to using a specific language, PSDL. In the following text, the tag class is simplified to Dimension, and the tag object is simplified to Dimension. Since the tag class inherits from the element class, its instantiation constructor is also inherited. When a tag object is instantiated, just like the element object obtained by instantiating the element class, the tag object will also encapsulate (create) at least one data container object to indirectly hold the data object.

[0037] The attribute layer is configured to define attribute classes that inherit from the element classes. According to the Liskov Substitution Principle (LSP), the core definition of inheritance ensures that anywhere in the program an element object is instantiated from the element class, it can be replaced by an instantiated object of the attribute class (i.e., an attribute object). This replacement is unidirectional and does not change the correctness of the program. In other words, the attribute objects instantiated from the attribute classes are configured to unidirectionally replace element objects, and these attribute objects are stored in the corresponding attribute container. A diagram of the classes and objects in the attribute layer is shown below. Figure 4 As shown, _psdlAttribute (with an underscore "_" before the name) represents an attribute class, and psdlAttribute (without an underscore before the name) represents an attribute object. This invention is not limited to using a specific language, PSDL. In the following text, attribute class is simplified to Attribute, and attribute object is simplified to Attribute. Since the attribute class inherits from the element class, its instantiation constructor is also inherited. When the attribute object is instantiated, just like the element object obtained by instantiating the element class, the attribute object will also encapsulate (create) at least one data container object to indirectly hold the data object.

[0038] The system layer is configured to define system classes that inherit from the element classes. The core definition of inheritance ensures that anywhere in the program an element object is instantiated using the element class, it can be replaced by an instantiated object of the system class (i.e., a system object). This replacement is unidirectional and does not change the correctness of the program. In other words, the system object instantiated from the system class is configured to unidirectionally replace element objects, and the system object is stored in the corresponding system container. A diagram of the classes and objects in the system layer is shown below. Figure 5As shown, _psdlSystem (with an underscore "_" before the name) represents a system class, and psdlSystem (without an underscore before the name) represents a system object. This invention is not limited to using a specific language, PSDL. In the following text, system class is simplified to System, and system object is simplified to System. Since the system class inherits from the element class, its instantiation constructor is also inherited. When a system object is instantiated, just like the element object obtained by instantiating the element class, the system object will also encapsulate (create) at least one data container object to indirectly hold the data object.

[0039] The tag layer, attribute layer, and system layer are all derived layers, and their inheritance relationships are as follows: Figure 6 As shown: At least two types of information are presented: First, the instantiation of the label class (Dimension), attribute class (Attribute), and system class (System) to the left of the arrow all inherits from the element class (Element), making the corresponding label object (Dimension), attribute object (Attribute), and system object (System) all derived objects of the element class (_Element) and capable of unidirectionally replacing element objects; Secondly, since an element object encapsulates at least one data container object to indirectly hold the data objects stored in that data container, the data structures of derived objects inheriting from the element class (_Element)—the dimension, attribute, and system objects—are all data objects within their respective data containers. This achieves a unified data structure for all element objects (including element class derived objects) within the framework.

[0040] A container is an abstract data type or object used to store and manage other objects (data elements). It provides a unified way to organize, access, and manipulate a group of objects, offering the ability to add, delete, search, and traverse objects within it. In a specific embodiment of the present invention, the data layer is further configured to define a data container class, where the data container is an object instantiated from the data container class; a diagram of the container class and container objects in the data layer is shown below. Figure 7 As shown, _psdl_dataContainer (with an underscore "_" before the name) represents a data container class, and psdl_dataContainer (without an underscore before the name) represents a data container object. This invention does not limit the use of a specific language PSDL, and the data container object in the following text is simplified as dataContainer.

[0041] The element layer is also configured to define an element container class, wherein the element container is an object instantiated from the element container class; a diagram of the element layer's container class and container object is shown below. Figure 8 As shown, psdl `elementContainer` (with an underscore "_" before the name) represents a tag container class, while `psdl_elementContainer` (without an underscore before the name) represents a tag container object.

[0042] The tag layer is also configured to define a tag container class, wherein the tag container is an object instantiated from the tag container class; a diagram of the tag layer's container class and container object is shown below. Figure 9 As shown, psdl dimensionContainer (with an underscore "_" before the name) represents a tag container class, and psdl_dimensionContainer (without an underscore before the name) represents a tag container object. This invention does not limit the use of a specific language PSDL. In the following text, the tag container object is simplified as dimensionContainer.

[0043] The attribute layer is also configured to define an attribute container class, wherein the attribute container is an object instantiated from the attribute container class; a diagram of the container class and container objects of the attribute layer is shown below. Figure 10 As shown, psdl `attributeContainer` (with an underscore "_" before the name) represents an attribute container class, and `psdl_attributeContainer` (without an underscore before the name) represents an attribute container object. This invention does not limit the use of a specific language, PSDL. In the following text, the attribute container object is simplified to `attributeContainer`.

[0044] The system layer is also configured to define system container classes, where each system container is an object instantiated from the system container class; a diagram of the system layer's container classes and container objects is shown below. Figure 11 As shown, _psdl_systemContainer (with an underscore "_" before the name) represents a system container class, and psdl_systemContainer (without an underscore before the name) represents a system container object. This invention does not limit the use of a specific language PSDL, and the system container object in the following text is simplified as systemContainer.

[0045] Each container in the above layers manages one or more corresponding objects; that is, the system container manages one or more system objects, the property container manages one or more property objects, and so on. The tag layer, attribute layer, and / or system layer support both empty containers and containers containing multiple objects.

[0046] Inheritance relationships between container classes are as follows: Figure 12 As shown: the tag container class, attribute container class, and system container class all inherit from the element container class. Figure 12 It can also be seen that the element class and the data class inherit from the same object base class, and the element container class and the element container class inherit from the same container base class.

[0047] The framework doesn't care which language an object is generated from, only whether it conforms to this inheritance structure. System objects, attribute objects, and tag objects are all derived from element classes. That is, the composition of system objects, attribute objects, and tag objects essentially contains all the components of element objects, automatically giving them the same ability to encapsulate and associate underlying data. The core idea of ​​this design is to enable the possibility of mutual conversion between objects in the system layer, attribute layer, and tag layer. Figure 15 As shown. Under certain conditions, the framework will allow reversible / irreversible conversion between derived objects of element classes (system objects, attribute objects, tag objects).

[0048] Figure 4 The attribute class represented by _psdlAttribute shown is a static attribute class defined in the static attribute sub-layer, and its defined attribute container class ( Figure 10 This is a static property container class; In one specific embodiment, the attribute layer further includes a dynamic attribute sublayer, which is configured to define dynamic attribute classes and dynamic attribute container classes. A diagram of the dynamic attribute classes and objects is provided. Figure 13 As shown, `_psdlProperty` (with an underscore "_" before the name) represents a dynamic property class, and `psdlProperty` (without an underscore before the name) represents a dynamic property object. This invention is not limited to using a specific language, PSDL. In the following text, dynamic property classes are simplified to `Property`, and property objects are simplified to `Property`. The diagrams for dynamic property container classes and dynamic container objects are shown below. Figure 14 As shown, psdl `propertyContainer` (with an underscore "_" before the name) represents a dynamic property container class, while `psdl_propertyContainer` (without an underscore before the name) represents a dynamic property container object.

[0049] like Figure 6 As shown, the dynamic property class (_Property) inherits from the static property class (_Attribute); for example... Figure 12As shown, the dynamic attribute container class (_psdl_propertyContainer) inherits from the static attribute container class (_psdl_attributeContainer). The dynamic attribute object (Property) instantiated from the dynamic attribute class is derived from the static attribute class (_Attribute), meaning the dynamic attribute object is configured to unidirectionally replace the static attribute object. The dynamic attribute container object instantiated from the dynamic attribute container class is also configured to unidirectionally replace the static attribute container object. The dynamic attribute object (Property) is stored within the dynamic attribute container (psdl_propertyContainer) instantiated from the dynamic attribute container class. For example, the "order" attribute has a corresponding static attribute of "domestic order" or "international order," and a corresponding dynamic attribute of "total order price." Its calculation logic can be bound to the "unit price" and "quantity" attribute objects. When the "unit price" or "quantity" changes, the dynamic attribute "total order price" is automatically recalculated. The separation of static and dynamic attributes at the attribute layer allows developers, maintainers, and even end users to clearly understand which values ​​are inputs (static) and which are calculated (dynamic), greatly improving the readability and maintainability of the code and model. Meanwhile, static attributes represent only configurations, constants, or basic facts, while dynamic attributes encapsulate calculation logic. With clear separation of responsibilities, calculation logic is no longer scattered throughout the code but is tightly bound to the business attributes it describes. This calculation logic can be shared or referenced by dynamic attribute objects contained in multiple different business objects. This avoids code duplication, achieving "define once, use everywhere." When modifying calculation rules, only the logic definition within the dynamic attribute needs to be modified, and all places using the attribute will automatically update, ensuring data consistency.

[0050] In summary, both dynamic and static property sub-layers belong to the property layer. The property layer is static property by default because dynamic property objects can be used as static property objects (but not vice versa), and dynamic property container objects can also be used as static property container objects (but not vice versa).

[0051] Apart from Figure 12 The inheritance relationship shown indicates that the tag layer, attribute layer, and system layer also have an irreversible containment relationship: like Figure 16 As shown, the system object can be constructed to include one or more of the following: label objects, attribute objects, and subsystem objects (i.e., other system objects). Figure 16The diagram shows the case containing the most types of objects. In reality, apart from the data container object (dataContainer), which is automatically created when the system object is derived from the element class and is always present (it can be empty or contain multiple data objects), the tag objects, attribute objects, and subsystem objects are optional to be included in the system object according to functional requirements or design requirements. In other words, if there is no such functional requirement or design requirement, the system object may not contain these tag objects, attribute objects, and subsystem objects.

[0052] like Figure 17 As shown, the attribute object can be constructed to contain one or more of the following: tag objects and sub-attribute objects (i.e., other attribute objects). Similarly, the data container object (dataContainer) is automatically created when the system object is derived from the element class and is therefore guaranteed to exist (it can be empty or contain multiple data objects). Tag objects and sub-attribute objects are optional to be included in the attribute object according to functional requirements or design requirements. In other words, if there are no functional requirements or design requirements, the attribute object may not contain these tag objects and sub-attribute objects.

[0053] like Figure 18 As shown, the tag object can be constructed to contain child tag objects (i.e., other tag objects). Similarly, the data container object (dataContainer) is automatically created when the system object is derived from the element class and must exist (it can be empty or contain multiple data objects). The child tag objects are optionally included in the attribute object according to functional requirements or design requirements. In other words, if there is no such functional requirement or design requirement, the tag object may not contain the subsystem object.

[0054] The inclusion here can be manifested as a composition relationship, aggregation relationship, or association relationship: a system object includes one or more of a tag object, attribute object, or subsystem object through a composition relationship, aggregation relationship, or association relationship; an attribute object includes one or more of a tag object and sub-attribute object through a composition relationship, aggregation relationship, or association relationship; a tag object includes a sub-tag object through a composition relationship, aggregation relationship, or association relationship.

[0055] Composition, aggregation, and association represent three types of association relationships, from highest to lowest degree of correlation: The composition relationship is defined as follows: Object A contains object B through the composition relationship, that is, object B is a member object of object A to achieve the "containment" here. In this way, object A completely manages the life cycle of object B. The aggregation relationship is defined as follows: Object A contains object B through the aggregation relationship, that is, object A holds a reference to object B to achieve the "containment" here. In this way, object B exists independently of object A. Association is defined as follows: Object A contains object B through an association, that is, object A is associated with object B through method parameters, local variables or weak pointers. This "containment" is a temporary relationship used temporarily, and there is no lifecycle association between the two objects.

[0056] Unlike the tightly coupled class relationships in traditional object-oriented design, the objects in this software framework are organized through configurable "inclusion" relationships. These relationships are loosely coupled and can be dynamically adjusted: any object (such as an attribute object) can be easily removed from its current parent object (such as a system object) (i.e., the inclusion relationship is broken) and then attached to another parent object. It can even be transformed at the element level and then attached to a new location, achieving flexible assembly and reconstruction similar to Lego bricks. System functions are composed of standardized attributes, tags, and system objects. Users can adjust system functions in a "building block" manner through a graphical interface or configuration tools, lowering the technical threshold for function expansion and modification.

[0057] In addition to flexibility in coupling and decoupling, it also enables flexibility in replication: taking a system object and its contained objects as a whole unit, and / or an attribute object and its contained objects as a whole object, and / or a tag object and its contained sub-tag objects as a whole object, the server supports the replication of the whole unit.

[0058] In one specific embodiment, the tag layer is configured to define as follows: Figure 3 One or more of the three types of tag classes shown: The tag class of incentive type, whose instantiated tag objects can be used as structural anchors for the filtering logic of the subtree of derived class (tag class, attribute class, system class) objects of element class, so as to achieve fast anchor filtering; The tag class of the suppression type, whose instantiated tag objects can be used as structural anchors for the filtering logic of the subtree of derived class (tag class, attribute class, system class) objects of the element class, so as to achieve fast exclusion filtering; Neutral tag classes instantiate ordinary tag objects, which can be used as structural anchors for filtering logic of subtrees of derived classes (tag classes, attribute classes, system classes) of element classes, but are not used for the framework's predefined fast filtering (neither anchor filtering nor exclusion filtering is implemented).

[0059] Tag objects can serve as anchors. Since tag objects themselves can be structured (tree-like), they act as structural anchors. Filtering is like selecting N subtrees from a large tree; that is, since nodes are selected, their child nodes are also included. In anchored filtering, all nodes (tag objects, attribute objects, system objects) with this structural tag object will be filtered and added to the filter result set. In exclusion filtering, all nodes (tag objects, attribute objects, system objects) holding this structural tag object will be removed from the result set. The filtering logic for ordinary tag objects can be customized by the user later; the first two quick filtering methods are predefined by the framework.

[0060] Anchoring and exclusion, these two filtering logics, can be combined to achieve most common "existence" filtering. Therefore, it is necessary to predefine the filtering logic (anchoring and exclusion) represented by each of the first two tag objects to improve filtering speed. For example, in a project funding approval system, "Approved by department manager or above" can be defined as an incentive-type tag object, meaning that any leader at the department manager level or above can see the project funding approval process in the system workflow. "Approval blacklist" can be defined as a suppression-type tag object, meaning that individuals on the blacklist will not see the project funding approval process in the system workflow at all. Neutral tags are only used for classification, such as "Project Type: R&D".

[0061] This invention also provides a server, including the multi-layered software framework described above, wherein the server manages or executes business logic on the data layer, element layer, tag layer, attribute layer, and system layer of the multi-layered software framework.

[0062] Specifically, the server manages the data layer, including being responsible for the storage, retrieval, and CRUD operations of the underlying binary data objects; The server executes business logic on the element layer, tag layer, attribute layer, and system layer, including: encapsulating the underlying data into data objects, instantiating tag objects, attribute objects, and system objects, and managing the inheritance and inclusion relationships between objects; The server also manages the lifecycle of data containers, element containers, tag containers, attribute containers, system containers, and the inheritance relationships between container classes.

[0063] This invention also provides a software framework / server that supports version control and rollback. Version control and rollback are achieved by configuring time-based tags on tag objects. For example, if a first system object (or attribute object or main tag object) needs to be upgraded, it can be backed up (referred to as the first subsystem). A tag object containing time-based version information (e.g., the December 2025 version) is added to the backed-up object (the first subsystem). Then, the upgraded system object, referred to as the second subsystem (or attribute object or main tag object), is also added with a tag object containing time-based version information (e.g., the May 2026 version). System objects, attribute objects, or main tag objects with different time versions can coexist. The target version of the system object, attribute object, or main tag object can be filtered based on the time-based version information. For example, to roll back to the December 2025 version, the server clears runtime data and reloads the element-class derived object node with the December 2026 version tag (usually located at the root node of the subsystem tree or the subsystem's attribute tree).

[0064] This invention also provides a software framework / server for achieving data security, which improves system reliability and security through tag data encryption and key separation. The server is also equipped with a security and key management module, configured to encrypt data in user-specified sensitive tag objects. The data in the tag objects is encrypted ciphertext data. The decryption key is configured to be stored in different tag objects or external to the system where the software framework resides. For example, the security and key management module stores the key in a separate hardware security module or an external key management service, achieving key-data separation. The key separated from the data can be used as the unlocking password for digital assets and given to the inheriting user of the digital assets.

[0065] The framework natively supports version control and rollback (via time item tags), data security (tag data encryption, key separation), dynamic behavior (dynamic attributes), and fine-grained permission management, improving the system's reliability, security, and flexibility.

[0066] In this embodiment, the server also includes an API gateway, configured to provide interfaces that allow clients to create, read, update, and delete various objects in the data layer, element layer, tag layer, attribute layer, and system layer of the multi-layered software framework, and to manipulate containers. The data layer, element layer, tag layer, attribute layer, and system layer are all configured to have edit permissions, enabling system maintainers and even end users to participate in system adjustments and expansions without developer intervention. Having edit permissions here means that the framework provides standardized interfaces and management interfaces for the objects in these five layers that can be accessed and manipulated externally, rather than hard-coding modification logic into the program. Edit permissions in this embodiment include at least: allowing users to instantiate a new data object, tag object, attribute object, or system object; allowing users to browse the structure, values, and relationships of existing objects; allowing users to modify the type, classification information, or encryption status of tag objects; allowing users to modify the fixed values ​​of static attribute objects; allowing users to modify the calculation logic associated with dynamic attribute objects; allowing users to modify the containment relationships of system objects (e.g., removing a tag from an attribute object or adding a subsystem object to a system object); allowing users to remove an object from a container; and allowing administrator users to configure different layer operation permission ranges for different user roles. These permissions are typically implemented by manipulating the underlying object model of the framework through a graphical configuration management console or a rich set of management APIs.

[0067] Example of modifying business rules: Suppose we want to change the rule "Automatically upgrade when customer points reach 1000" to "Automatically upgrade when customer points reach 1200". The maintainer only needs to find the corresponding static attribute object in the static attribute subtree of the rule class in the information tree (the nodes are usually system objects or attribute objects) according to the specific tag holding path (e.g., "rule" - "upgrade" - "points" - "threshold" - "greater than or equal to"). That is, first find the attribute object holding the "rule" tag, then find its sub-attribute objects with the "upgrade" tag, and so on, until finally locating the attribute object holding the "greater than or equal to" tag. In the console, change the value of the "threshold" data object held by the static attribute object from 1000 to 1200, save and it will take effect, without having to find and modify the if statements scattered in the code.

[0068] Example of modifying the calculation formula: If the calculation formula for the total order price needs to include a "discount", the maintainer only needs to edit the corresponding dynamic attribute object and update its corresponding calculation formula to unit price × quantity × (1 - discount rate). Example of reorganizing system functions: If a sub-department B (subsystem object) under department A (system object) needs to be moved to department C (system object), the maintainer only needs to change the parent inclusion relationship of sub-department B (subsystem object) in the console, remove it from the original parent system (department A system object), and mount it under the new parent system (department C system object) as a subsystem object contained in the new parent system.

[0069] Example of adding new attributes: If a user needs to monitor a new metric, such as the expected value of customer satisfaction, they can create a new static attribute object in the console, define its name and initial value, and include it in the relevant system object or attribute object tree.

[0070] Example of adding a new business rule: If a user needs to add a rule to "automatically send an email when inventory is below the safety value", the user can find and locate the root node of the rule-related attribute object subtree (i.e., the attribute object with the "rule" tag, usually the root node of a certain object subtree) in the information tree (nodes are usually system objects or attribute objects). Then, the user can find the sub-attribute object with the "inventory" tag (usually a static attribute object). If it does not exist, the user can create it. Finally, the user can establish a rule attribute object path such as "rule" - "inventory" - "quantity" - "threshold" - "less than or equal to". Then, the user can find and locate the behavior-related attribute object subtree in the information tree, locate the attribute object with the "EMAIL" tag, and use it as the "attribute tree describing the behavior" to browse and understand the various attribute object subtrees under it (corresponding to the behavior under various triggering methods). Finally, the user can refer to these existing attribute object subtrees to create a new sub-attribute object that triggers the EMAIL behavior (i.e., creates a new attribute object subtree based on the EMAIL attribute object). The user can then associate the previously created "less than or equal to" rule with the newly created sub-attribute object.

[0071] In this way, domain experts familiar with the business but lacking technical expertise (such as finance and operations personnel) can directly modify relevant parameters, rules, and category tags through a user-friendly interface, making the system more aligned with actual business changes. This significantly reduces reliance on the development team: routine system optimization, rule fine-tuning, and simple feature expansion no longer require waiting for development schedules; these can be completed by the operations team or super users, greatly improving response speed. During modification, users can choose to attach creation time / version tags when creating objects. If a new modification results in an error that cannot be reversed, the server can easily switch back (restore) to the state before the modification by filtering out the time-stamped nodes.

[0072] In one embodiment of the present invention, a system construction method based on the above-described multi-layered software framework is provided, comprising the following steps to build a system from scratch: Identify the fixed parameters that the system to be built needs to model and manage, as well as the states that need to be calculated, and plan the labels used for classification and control; The process involves encapsulating a data container class to form an element class and instantiating it (this process includes the automatic instantiation of the data container class, since each element object encapsulates at least one data container object, meaning the element class carries a data container class; the creation of the data container instance is automatic when the element instance is created, so it must precede the creation of the data instance, i.e., the container is created first, and then its content, i.e., the data objects, can be placed into the container), forming objects of derived classes (tag class, attribute class, system class) derived from the element class as the common base class of the tag layer, attribute layer, and system layer; instantiating data objects for each piece of underlying information that needs to be stored, each data object including a name part and a data part, and storing them within the data container object; the derived class objects of the element class are placed in the derived class objects of the element container class for management; The attribute layer is constructed as follows: For the fixed parameters, a static attribute class is instantiated to obtain a static attribute object, which is then associated with the corresponding data object, and the static attribute object is stored in a static attribute container; For the states that need to be calculated, calculation logic is configured for a dynamic attribute class, which inherits from the static attribute class, and the dynamic attribute class is instantiated, and the instantiated dynamic attribute object is stored in a dynamic attribute container. The tag layer is constructed as follows: instantiate a tag class for classification to obtain neutral tag objects; instantiate a tag class for control, and obtain incentive-type tag objects or inhibition-type tag objects according to business rules and / or activation logic; establish parent-child relationships between tag objects according to the system's modeling requirements to form a tag tree. The system layer is constructed in the following ways: instantiate a system class to obtain a root system object, and according to the system functional requirements, include the constructed attribute objects and tag objects into the root system object through combination, aggregation or association; and / or, instantiate a system class to obtain a subsystem object, and according to the system functional requirements, include the attribute objects and tag objects into the subsystem object, and include the subsystem object into the root system object.

[0073] The system constructed using the above methods is as follows: Figure 19 As shown, this serves as an example. Figure 19 The diagram shows a root system containing several subsystems. The System at the bottom of the diagram is the root system, which contains several independent first-level subsystems. Some of these first-level subsystems also contain multiple subsystem objects, and some first-level subsystems also contain second-level subsystems. Second-level subsystems, in turn, contain label objects, attribute objects, and third-level subsystem objects. These containment relationships are determined based on the system's functional requirements.

[0074] To enable the reconstruction of the aforementioned "system orphans" / "software orphans," the system construction method provided by this invention is applicable to the reconstruction of existing legacy systems, and includes the following steps: Data and structure analysis of the old system is performed, including analyzing the table structure, views and stored procedures of the old system database, extracting key business data, configuration parameters and status values, and reversing the process to parse out fixed parameters, the states that need to be calculated and their calculation formulas, classifications, business rules and control points. In the restructured new system, clearly define the attribute objects and tag objects it contains; Construct a mapping table for the fixed parameters and states that need to be calculated in the old system: Based on the relationship between the attribute objects in the new system and the fixed parameters and states that need to be calculated in the old system, establish the mapping relationship between the tables and fields of the database in the old system and the corresponding data parts of the attribute objects in the new system; and based on the relationship between the tag objects in the new system and the classification and control points in the old system, establish the mapping relationship between the business rules of the old system and the type and filtering logic of the tag objects in the new system. For the fixed parameters of the old system, the field names and field values ​​in the database are instantiated as data objects and stored in a data container; the data objects are encapsulated to form element class derived objects and stored in the element container. The element class derived objects are instances of derived classes of the tag layer, attribute layer and system layer with the element class as the common base class. For fixed parameters in the mapping table, a static attribute class is instantiated to obtain a static attribute object, which is then associated with the data object corresponding to the fixed parameter and stored in the static attribute container. For states in the mapping table that need to be calculated, a dynamic attribute class is instantiated to obtain a dynamic attribute object, and the calculation logic of the dynamic attribute object is configured according to its calculation formula and stored in the dynamic attribute container. Based on the classification of the old system, instantiate a label class and create a neutral label object for classification; based on the association information of the business rules of the old system in the mapping table, instantiate an incentive-type label class or an inverse-type label class and configure its activation logic; store the label objects in the label container. Based on the classification of the old system, instantiate a label class and create a neutral label object for classification; based on the association information of the business rules of the old system in the mapping table, instantiate an incentive-type label class or an inhibition-type label class and configure its filtering logic; store the label objects in the label container. Instantiate a root system object representing the functionality of the old system, and include the corresponding attribute objects and tag objects into the root system object through combination, aggregation or association; and / or, instantiate a subsystem object based on the functionality of the old system, and include the corresponding attribute objects and tag objects into the subsystem object through combination, aggregation or association, and include the subsystem object into the root system object.

[0075] Compared to the aforementioned method of building a system from scratch, the method for reconstructing an existing old system provided in this embodiment differs in that it uses the old system as a data source, parses and extracts the necessary underlying data to encapsulate the data objects in the software framework of this invention, and further encapsulates the data classes with element classes, which serve as the base classes for tag classes, attribute classes, and system classes. This reconstructs the old system, which is difficult to maintain and whose logic is mixed in the code and database, into a clear model composed of standardized defined objects (data, elements, attributes, tags, and systems) and clear relationships (inheritance and inclusion). This upgrades the "software orphan" to an advanced framework with long-term maintainability and scalability, achieving maintainability and evolvability. Here, maintainability means that even if the original development team disappears, the new team can understand and maintain the system based on this structured object model, because all business elements (parameters, states, and rules) have become viewable and editable objects within the framework. Here, evolvability means that the new system after migration immediately possesses the dynamic attributes, version management, security encryption, rule tags, and editing functions provided by the framework, laying a solid foundation for subsequent functional expansion.

[0076] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0077] The above description is only a specific embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A multi-layered software framework, characterized in that, include: The data layer is configured to define data classes, and the data objects instantiated from the data classes are stored in the corresponding data containers. An element layer is configured to define element classes, wherein an element object instantiated from the element class encapsulates at least one data container object to hold data objects stored in the data container, and the element objects are stored in the corresponding element container. A tag layer is configured to define tag classes that inherit from the element class. Tag objects instantiated from the tag classes are configured to be unidirectionally replaceable element objects, wherein the tag objects are stored in the corresponding tag container. An attribute layer, configured to define attribute classes that inherit from the element class, wherein attribute objects instantiated from the attribute classes are configured to be unidirectionally replaceable element objects, and the attribute objects are stored in corresponding attribute containers; and The system layer is configured to define system classes that inherit from the element classes. System objects instantiated from the system classes are configured as unidirectional replaceable element objects, and the system objects are stored in the corresponding system containers. The system object can be constructed to include one or more of tag objects, attribute objects, and subsystem objects. The attribute object can be constructed to include one or more of tag objects and sub-attribute objects. The tag object can be constructed to include sub-tag objects.

2. The multi-layered software framework according to claim 1, characterized in that, The data layer is also configured to define a data container class, wherein the data container is an object instantiated from the data container class; The element layer is also configured to define an element container class, wherein the element container is an object instantiated from the element container class; The tag layer is also configured to define a tag container class, wherein the tag container is an object instantiated from the tag container class; The attribute layer is also configured to define an attribute container class, wherein the attribute container is an object instantiated from the attribute container class; The system layer is also configured to define a system container class, wherein the system container is an object instantiated from the system container class; The tag container class, attribute container class, and system container class all inherit from the element container class.

3. The multi-layered software framework according to claim 1, characterized in that, The attribute layer includes a static attribute sublayer, whose defined attribute classes are static attribute classes, and whose defined attribute container classes are static attribute container classes; The attribute layer further includes a dynamic attribute sublayer, which is configured to define a dynamic attribute class and a dynamic attribute container class. The dynamic attribute class inherits from the static attribute class, and the dynamic attribute container class inherits from the static attribute container class. The dynamic attribute object instantiated from the dynamic attribute class is configured to unidirectionally replace the static attribute object, and the dynamic attribute container object instantiated from the dynamic attribute container class is configured to unidirectionally replace the static attribute container object. The dynamic attribute object is stored in the dynamic attribute container instantiated from the dynamic attribute container class.

4. The multi-layered software framework according to claim 1, characterized in that, The tag object can be configured as a time item to record the time version information of the system object, attribute object or main tag object that currently contains the tag object; System objects, attribute objects, or main tag objects from different time versions can coexist. You can filter system objects, attribute objects, or main tag objects of a target version based on the time version information.

5. The multi-layered software framework according to claim 1, characterized in that, The data in the tag object is encrypted ciphertext data, and the key used for decryption is configured to be stored in different tag objects or outside the system where the software framework is located.

6. The multi-layered software framework according to claim 1, characterized in that, The tag layer is configured to define one or more tag classes of the following three types: The tag class of the incentive type, whose instantiated tag objects are configured as structural anchors, is used for the filtering logic of the subtree of derived class objects of the element class to achieve anchor filtering. The derived classes of the element class include tag classes, attribute classes and system classes. The tag class of the suppression type, whose instantiated tag objects are configured as structural anchors, is used for the filtering logic of the subtree of derived class objects of the element class to achieve exclusion filtering. The derived classes of the element class include tag classes, attribute classes and system classes. Neutral tag classes, whose instantiated tag objects are configured as structural anchors, are used for filtering logic of subtrees of derived class objects of element classes, and are not used for anchor filtering or exclusion filtering predefined by the framework.

7. The multi-layered software framework according to claim 1, characterized in that, The system object contains one or more of the following: tag objects, attribute objects, and subsystem objects, through composition, aggregation, or association relationships. The attribute object contains one or more of the following: tag object and sub-attribute object, through composition, aggregation, or association relationships. The tag object contains sub-tag objects through composition, aggregation, or association relationships.

8. The multi-layered software framework according to claim 1, characterized in that, The element object holds data objects stored within the corresponding data container object, including: The element object encapsulates the data container object and is associated with the data object stored within the data container by reference or inclusion.

9. The multi-layered software framework according to claim 1, characterized in that, Each container manages one or more corresponding objects; The tag layer, attribute layer, and / or system layer support empty containers and containers containing multiple objects.

10. The multi-layered software framework according to claim 1, characterized in that, The element class and the data class inherit from the same object base class; And / or, the element container class and the element container class inherit from the same container base class.

11. The multi-layered software framework according to any one of claims 1 to 10, characterized in that, The data object includes a name part and a data part. The name part serves as the index of the data object, and the value data of the data part can be a number, a string, or an arbitrary byte sequence. Both the name portion and the data portion are in binary data format.

12. The multi-layered software framework according to any one of claims 1 to 10, characterized in that, The data layer, element layer, tag layer, attribute layer, and system layer are all configured to have editing permissions.

13. A server, characterized in that, The system includes a multi-layered software framework as described in any one of claims 1 to 12, wherein the server manages or executes business logic for the data layer, element layer, tag layer, attribute layer, and system layer in the multi-layered software framework.

14. The server according to claim 13, characterized in that, The server manages the data layer, including: being responsible for the storage, retrieval, and CRUD operations of the underlying binary data objects; The server executes business logic on the element layer, tag layer, attribute layer, and system layer, including: encapsulating the underlying data into element objects, instantiating tag objects, attribute objects, and system objects, and managing the inheritance and inclusion relationships between objects; The server also manages the lifecycle of data containers, element containers, tag containers, attribute containers, system containers, and the inheritance relationships between container classes.

15. The server according to claim 13, characterized in that, The system containing the multi-layered software framework includes a first subsystem and a second subsystem. The first subsystem includes a tag object configured with a first time item, and the second subsystem includes a tag object configured with a second time item. Based on the user's selection of the first time item and the second time item, the running permissions of the subsystem corresponding to the selected time item are enabled, and the running permissions of the subsystem corresponding to the unselected time item are disabled.

16. The server according to claim 13, characterized in that, The server is also equipped with a security and key management module, which is configured to encrypt data in user-specified sensitive tag objects and store the key in a separate hardware security module or an external key management service to achieve key and data separation.

17. The server according to claim 13, characterized in that, It also includes an API gateway, which is configured to provide interfaces that allow clients to create, read, update, delete various objects in the data layer, element layer, tag layer, attribute layer, and system layer of the multi-layered software framework, and to manipulate containers.

18. The server according to any one of claims 13 to 17, characterized in that, The server supports copying the system object and its contained objects as a whole unit, and / or the attribute object and its contained objects as a whole object, and / or the tag object and its contained sub-tag objects as a whole object.

19. A system construction method based on a multi-layered software framework according to any one of claims 1 to 12, characterized in that, Includes the following steps: Identify the fixed parameters that the system to be built needs to model and manage, as well as the states that need to be calculated, and plan the labels used for classification and control; A data container class is encapsulated to form an element class and instantiated, forming objects of derived classes derived from the element class as the common base class of the tag layer, attribute layer, and system layer. These derived classes include tag classes, attribute classes, and system classes. Data objects are instantiated for each piece of underlying information that needs to be stored. Each data object includes a name part and a data part and is stored within the data container object. The derived class objects of the element class are managed within the derived class objects of the element container class. The attribute layer is constructed as follows: For the fixed parameters, a static attribute class is instantiated to obtain a static attribute object, which is then associated with the corresponding data object, and the static attribute object is stored in a static attribute container; For the states that need to be calculated, calculation logic is configured for a dynamic attribute class, which inherits from the static attribute class, and the dynamic attribute class is instantiated, and the instantiated dynamic attribute object is stored in a dynamic attribute container. The tag layer is constructed as follows: instantiate a tag class for classification to obtain neutral tag objects; instantiate a tag class for control, and obtain incentive-type tag objects or inhibition-type tag objects according to business rules and / or activation logic; establish parent-child relationships between tag objects according to the system's modeling requirements to form a tag tree. The system layer is constructed in the following ways: instantiate a system class to obtain a root system object, and according to the system functional requirements, include the constructed attribute objects and tag objects into the root system object through combination, aggregation or association; and / or, instantiate a system class to obtain a subsystem object, and according to the system functional requirements, include the attribute objects and tag objects into the subsystem object, and include the subsystem object into the root system object.

20. The system construction method according to claim 19, characterized in that, This is applicable to refactoring existing legacy systems and includes the following steps: Data and structure analysis of the old system is performed, including analyzing the table structure, views and stored procedures of the old system database, extracting key business data, configuration parameters and status values, and reversing the process to parse out fixed parameters, the states that need to be calculated and their calculation formulas, classifications, business rules and control points. In the restructured new system, clearly define the attribute objects and tag objects it contains; Construct a mapping table for the fixed parameters and states that need to be calculated in the old system: Based on the relationship between the attribute objects in the new system and the fixed parameters and states that need to be calculated in the old system, establish the mapping relationship between the tables and fields of the database in the old system and the corresponding data parts of the attribute objects in the new system; and based on the relationship between the tag objects in the new system and the classification and control points in the old system, establish the mapping relationship between the business rules of the old system and the type and filtering logic of the tag objects in the new system. For the fixed parameters of the old system, the field names and field values ​​in the database are instantiated as data objects and stored in a data container; the data objects are encapsulated to form derived class objects with the element class as the common base class of the tag layer, attribute layer and system layer, and stored in the element container. For fixed parameters in the mapping table, a static attribute class is instantiated to obtain a static attribute object, which is then associated with the data object corresponding to the fixed parameter and stored in the static attribute container. For states in the mapping table that need to be calculated, a dynamic attribute class is instantiated to obtain a dynamic attribute object, and the calculation logic of the dynamic attribute object is configured according to its calculation formula and stored in the dynamic attribute container. Based on the classification of the old system, instantiate a label class and create a neutral label object for classification; based on the association information of the business rules of the old system in the mapping table, instantiate an incentive-type label class or an inhibition-type label class and configure its filtering logic; store the label objects in the label container. Instantiate a root system object representing the functionality of the old system, and include the corresponding attribute objects and tag objects into the root system object through combination, aggregation or association; and / or, instantiate a subsystem object based on the functionality of the old system, and include the corresponding attribute objects and tag objects into the subsystem object through combination, aggregation or association, and include the subsystem object into the root system object.

Images