CN116301744A - Freely evolving software construction method and system - Google Patents

Abstract

The embodiment of the disclosure provides a freely evolving software construction method and device, which are applied to the technical field of computers. Decomposing minimum tasks and/or functions to be completed respectively to obtain corresponding composition objects; setting association rules and interaction rules of all the component objects, forming independent model relations corresponding to the component objects, and storing the independent model relations into a unified model library; extracting model relations corresponding to the required composition objects from the model library and integrating the model relations to generate an overall software architecture; and generating source codes corresponding to the whole software architecture. In this way, in the continuous iterative process of the software, the number of the component objects is from small to large, the number of independent model relations in the model library is also increased, and the whole software architecture is changed along with the change of the independent model relations and the change of the set of the selected component objects; a dynamic software architecture is formed that evolves freely as the number of constituent objects changes and the combination of constituent objects changes.

Description

Freely evolving software construction method and system

Technical Field

The present disclosure relates to the field of computers, and in particular, to a method and system for freely evolving software.

Background

The most difficult to develop enterprise-level software is not large-scale, multiple functional points, but rather various relationships that are intricate in the software architecture, such as relationships between data objects and data objects, relationships between data objects and business functions, relationships between business functions and business functions, and relationships between business functions and application scenarios, and so on. This is an extremely complex network relationship whose complexity grows exponentially with the size of the software.

Many enterprise-level software is just a department-level accounting system, neither integrated nor linked, and it is basically not ERP-enabled because of the lack of design and flexible changes to the software architecture made up of relationships.

In the design of the enterprise-level software,

first, the difficulty in workload is that analyzing relationships between hundreds or thousands of constituent objects consumes significant effort. It is more difficult to have a team of scarce talents, both software and business, to fully and deeply analyze and define these relationships. Even if the analysis design is completed, a research and development team capable of deeply understanding the relationship analysis design is required to accurately land the design into codes.

What is more refractory than the completion of this set of relational analysis designs is that the management and business activities of the enterprise are constantly changing and are getting faster and faster. The traditional software architecture design method is a static architecture design method for completing solidification, and cannot keep pace with the innovation of enterprises anyway. Not only because of how difficult it is to dynamically maintain the set of designs, but also because tens of millions, even millions, of lines of application code may have been written based on the set of designs, relational changes result in software architecture changes, and the impact of the architecture changes on the application may be subverted.

There is a need for a freely evolving, dynamic, automatically generating software architecture that is constructed by a local, small-scale design, in a fast, sustainable iterative manner, with dynamic assembly methods, and with methods that automatically generate architecture code.

Disclosure of Invention

The disclosure provides a freely evolving software construction method, device, equipment and storage medium.

According to a first aspect of the present disclosure, there is provided a freely evolving software building method, comprising: decomposing the minimum tasks and/or functions to be completed respectively to obtain corresponding composition objects; setting association rules and interaction rules of all the component objects, forming independent model relations corresponding to the component objects, and storing the independent model relations into a unified model library; extracting model relations corresponding to the required composition objects from the model library and integrating the model relations to generate an overall software architecture; and generating source codes corresponding to the whole software architecture.

According to a second aspect of the present disclosure, there is provided a freely evolving software building device comprising: the decomposition module is used for decomposing the minimum tasks and/or functions to be completed respectively to obtain corresponding composition objects; the design module is used for setting association rules and interaction rules of all the component objects, forming independent model relations corresponding to the component objects and storing the independent model relations into a unified model library; the integration module is used for extracting the model relation corresponding to the required composition object from the model library and integrating the model relation to generate an overall software architecture; and the code generation module is used for generating source codes corresponding to the whole software architecture.

According to a third aspect of the present disclosure, an electronic device is provided. The electronic device includes: a memory and a processor, the memory having stored thereon a computer program, the processor implementing the method as described above when executing the program.

According to a fourth aspect of the present disclosure, there is provided a computer readable storage medium having stored thereon a computer program which when executed by a processor implements a method according to the first aspect of the present disclosure.

It should be understood that what is described in this summary is not intended to limit the critical or essential features of the embodiments of the disclosure nor to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The above and other features, advantages and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. For a better understanding of the present disclosure, and without limiting the disclosure thereto, the same or similar reference numerals denote the same or similar elements, wherein:

FIG. 1 illustrates a flow chart of a freely evolving software build method according to an embodiment of the disclosure;

FIG. 2 illustrates a schematic diagram of a project group A decomposing a "membership management" function to be completed to obtain corresponding constituent objects, setting association rules and interaction rules of the constituent objects, and storing as model relationships in a specific example of a freely evolving software component method according to an embodiment of the disclosure;

FIG. 3 illustrates a schematic diagram of a project group B decomposing an "order management" function to be completed to obtain corresponding constituent objects, setting association rules and interaction rules for each constituent object, and storing as a model relationship in a specific example of a freely evolving software component method according to an embodiment of the present disclosure;

FIG. 4 illustrates a complete relational structure diagram including "Member management" and "order management" applications obtained by integrating model relationships of constituent objects after completion of the work of groups A and B in one specific example of a freely evolving software component method according to an embodiment of the present disclosure;

FIG. 5 illustrates a schematic diagram of a data relationship model fragment integrated in a model library starting with a "transaction client" data object, according to an embodiment of the present disclosure;

FIG. 6 illustrates a block diagram of a freely evolving software build device, in accordance with an embodiment of the present disclosure;

fig. 7 illustrates a block diagram of an exemplary electronic device capable of implementing embodiments of the present disclosure.

Detailed Description

For the purposes of making the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure, and it is apparent that the described embodiments are some embodiments of the present disclosure, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments in this disclosure without inventive faculty, are intended to be within the scope of this disclosure.

In addition, the term "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

FIG. 1 illustrates a flow chart of a freely evolving software build method 100 according to an embodiment of the disclosure.

At block 110, decomposing the minimum tasks and/or functions to be completed, respectively, to obtain corresponding constituent objects;

in some embodiments, decomposing the minimum task and/or function to be completed to obtain a corresponding component object, including: data objects, business functions, application scenarios, etc.

In some embodiments, each item group may decompose the minimum task and/or function to be completed according to the corresponding minimum task and/or function to be completed, so as to obtain each corresponding component object.

The minimum tasks and/or functions to be completed are decomposed, and the software functions are separated from the relationships of the component objects, so that the functions and the relationships can be designed and managed relatively independently.

Wherein, each composition object needs to meet the following rules:

1. sharing the same model library;

2. guaranteeing the uniqueness of the constituent objects and multiplexing it;

3. the relationships between constituent objects are described by the same rule.

The decomposed composition object is stored in a model library, and object definitions in the model library comprise: component object ID, generator of component object, association rule of component object, interaction rule of component object.

If the component object obtained by decomposing the item already exists in the model library, for example, other item groups already store corresponding component objects in the model library, the later item groups can only multiplex the component object and cannot be repeatedly added.

If the association rule or the interaction rule needs to be added to the composition object, authorization is required to be carried out by the generator of the composition object, namely the generator of the composition object is acquired from the model library, the generator of the composition object is informed of the association rule or the interaction rule which needs to be added, and the generator of the composition object carries out the addition of the association rule or the interaction rule; or the generator of the composition object authorizes the subsequent generator, and the subsequent generator carries out the increase of association rules or interaction rules.

In some embodiments, the model library is managed based on a model design tool to manage constituent objects and object relationships therein (association rules for constituent objects, interaction rules for constituent objects).

At block 120, association rules and interaction rules of each component object are set, and independent model relations corresponding to the component objects are formed and stored in a unified model library;

in some embodiments, the association rule between the data objects is an association relationship, which may be 1 to 1 or 1 to n; the aggregate relationship between the data object and the business object can also be a combination relationship, etc.

In some embodiments, each item group sets association rules and interaction rules of each component object in the business domain corresponding to each item, and stores the association rules and interaction rules in a model library.

In some embodiments, association rules and interaction rules are set for each constituent object and other constituent objects with which it directly interacts; forming an independent model relation for each component object, and storing the model relation in a unified model library comprises the following steps:

setting association rules and interaction rules of each component object and other component objects directly interacted with the component object; an independent model relationship is formed for each constituent object and stored in a unified model library.

At block 130, the model relationships corresponding to the required component objects are extracted from the model library and integrated to generate an overall software architecture.

In some embodiments, because each component object satisfies the rule, the same model library is shared, and unique data objects are multiplexed, so that the model relation corresponding to the required component object is extracted from the model library and integrated to generate an overall software architecture, and the uniqueness and consistency of the data are ensured.

In some embodiments, extracting model relations corresponding to the required constituent objects from the model library; the model relation corresponding to all the component objects can be selected according to the requirements; and integrating the model relation corresponding to the required component object based on the model processing tool.

In some embodiments, as the minimum tasks and/or functions completed by each item group are continuously increased, the number of the constituent objects is reduced to a plurality, the number of independent model relations in the model library is increased, the generated software architecture is also increased, and the whole software architecture is completed after each item group respectively completes the corresponding minimum tasks and/or functions. Meanwhile, different composition object combinations can be selected to form different software architectures according to requirements, so that the software architecture is changed into a dynamic architecture which freely evolves along with the change of the number of the composition objects and the change of the composition object combinations.

In some embodiments, the method further comprises the steps of:

and testing the whole software architecture.

In some embodiments, each component object is tested respectively, and if the component object cannot work accurately, the association rule and the interaction rule corresponding to the component object are modified until the component object can work accurately; and integrating the model relations corresponding to the constituent objects to generate the whole software structure. The overall structure must be correct as long as the minimum tasks and/or functions each of the project groups performs can work accurately. If the task and/or function corresponding to the minimum task and/or function which cannot work accurately cannot be corrected, the software architecture is regenerated, and the test is repeated until the task and/or function corresponding to the minimum task and/or function which cannot work accurately can be performed accurately. If each minimum task and/or function can work accurately, the whole software architecture is necessarily correct, and after the modification of an independent individual (the component object corresponding to the minimum task and/or function which cannot work accurately) is finished, the model relation corresponding to the required component object is extracted again and integrated, so that the correct whole software architecture can be obtained.

In some embodiments, the method further comprises the steps of:

at block 140, source code corresponding to the overall software architecture is generated.

In some embodiments, the overall software architecture is parsed with a low code tool to generate all source code based on the overall software architecture. For example, the database DDL and the data access layer code, the code of the data object aggregate/combine into a service object, the framework structure of the micro-service and the API code, the code of the micro-service processing service object, the code of the service object split into data objects, the integrated code between the micro-services, the flow code of the interaction between the micro-services, the binding code of the micro-service assembly into the service scene, the route integrated code of the front-end page forming the service scene, the integrated code of the service scene assembly into the application system, etc.

In some embodiments, generating all code based on the overall software architecture includes three cases of synchronous generation, runtime generation, and delayed generation, wherein,

1) And synchronously generating, namely forming a corresponding model relation for each independent component object, storing the model relation into a unified model library, and immediately and synchronously integrating and generating executable codes of the whole architecture. However, in the process of agile development of small steps and fast walking, design and development work is not completed at one time, but is stepwise and staged. This means that the overall software architecture is always in the process of dynamic changes. Each change generates code directly, meaning that each new change is to re-refresh all the software architecture code that has been generated. Obviously too time consuming and complex, and the software architecture code is not manageable in the dynamic state at any time.

2) Runtime generation, i.e., the dynamic parsing of the overall software architecture and the generation of executable software architecture code until runtime. The flexibility of the selection is highest, but a lot of performance in operation is consumed, and performance bottlenecks such as blocking easily occur in operation of a service system.

3) Delay generation. I.e. at a specific point in time after the design is analyzed, e.g. at a point in time when compiling, publishing, deploying, the whole software architecture is converted into executable code.

Taking the implementation of the MTSP development modeling platform as an example, the whole software architecture obtained by integrating all model relations related to the micro-service at the time point of the micro-service release is selected to be converted into executable codes and is injected into the micro-service, so that the released micro-service contains complete functions and relations, and the design requirement of the micro-service self-contained is met. This is a reasonable choice. Since the model relationships are in the dynamic process prior to release, which means the end of a small iteration, it is appropriate to convert the model relationships of the current state into source code, both of which are generated and recorded as a baseline, they can be managed versively.

In some embodiments, the enterprise business management requirements are constantly changing, and the software architecture must be able to accommodate such changes, known as the flexibility of the software. When a change in demand results in a change in the relationship between the component objects, the model processing tool is able to perceive the change and re-integrate the overall software architecture. This allows for flexibility of the software. If the service of the constructed software is changed, decomposing the changed service to obtain changed component objects, corresponding association rules and interaction rules; updating the independent model relation corresponding to the corresponding composition object; and arranging the model relation of each unchanged component object and each changed component object to generate an overall software structure after service change.

In this way, in the continuous iterative process of the software, the number of the component objects is from small to large, the number of independent model relations in the model library is also increased, and the whole software architecture is changed along with the change of the independent model relations and the change of the set of the selected component objects; a dynamic software architecture is formed that evolves freely as the number of constituent objects changes and the combination of constituent objects changes.

Next, a software construction method of free evolution of the embodiment of the present disclosure will be described in detail with reference to practical cases:

in some embodiments, the respective minimum tasks and/or functions are accomplished in units of item groups or programmers, respectively. For example, the number of the cells to be processed,

assume that there are two project groups A and B that respectively assume analysis and design of the projects of "Member management" and "order management". In the traditional software component method, A and B are required to be closely matched, the two design teams are constantly crossed, know each other and have the overall design, so that various service integration and dependency between the two modules can be ensured, otherwise, the two modules are required to be two chimneys. With the expansion of research and development scale, the team increases, and the discussion of the cross-over ring and the whole design is more and more complex and frequent, so that the cross-over ring and the whole design are missed, and understanding deviation is even completely out of control. The software construction method based on the free evolution of the embodiment of the disclosure can perfectly solve the contradictions, and the specific analysis design process is as follows:

as shown in figure 2 of the drawings, group A works in the membership management data model design domain, and four data objects of 'users', 'membership cards', 'points', 'coupons' are added to the model base in the analysis process. And establishes the relationship that 1 user has 1 membership card, 1 score pool and n coupons for the user object. Note that group a does not know what group B is doing at this time.

As shown in figure 3 of the drawings, the B group works in the design domain of the order management data model, three objects of an order, a commodity and a price are added into the model library in the analysis process, and at the moment, the B group finds that the objects of a user and a coupon exist in the model library, and can only be reused according to the rule B group and can not be repeatedly added. If group B finds that the information of "user" and "coupon" is not sufficient for group B to use, then group B can learn the creator of the object through the object creator information, he should inform group A, let group A enhance or be authorized by group A for group B enhancement. Group B establishes accordingly that 1 order is placed by 1 customer, 1 order can purchase n goods, each goods can have 1 price, and 1 order can use a coupon relationship. And also stored in a unified model library.

In operation, both groups a and B simply stand in their respective business fields to analyze their own constituent objects and the relationships between the constituent objects, irrespective of each other's business. Both groups a and B obey the above-described rules that each constituent object needs to satisfy:

1. sharing the same model library;

2. guaranteeing the uniqueness of the constituent objects and multiplexing it;

3. the relationships between constituent objects are described by the same rule.

Forming independent model relations corresponding to all the component objects based on all the component objects in the model library, and storing the independent model relations into the unified model library;

as shown in figure 4 of the drawings, after the work of the A group and the B group is completed, the work results of the A group and the B group are integrated into a whole by using a model processing tool, namely, the model relations of all the component objects are integrated to generate a software architecture, and then a complete data object relation structure comprising 'member management' and 'order management' application is obtained. And because the A group and the B group share the same model library, unique data objects are multiplexed, and naturally, the integrated data architecture ensures the uniqueness and consistency of data from the source, and the problem of inconsistent data is fundamentally avoided because the A group and the B group are separated by two independent teams.

Further, the method is popularized to the collaboration process of designing N small scenes by the components of N projects. Each project group only needs to care about individual designs within the scope of the project group, so that the complexity of the designs and the requirements on team capacity are greatly reduced, and small steps are possible to walk quickly; the whole software architecture is dynamically integrated by a model processing tool without artificial design, so that the influence of the size of the software is not considered, namely, the size is larger, only the individual analysis design is needed, and the size only influences the amount of model integration operation; when the business is changed, only the own composition objects and relations of each small item group are needed to be respectively reconstructed, and the whole framework is only needed to be re-integrated once. The influence of the demand change on the software architecture is not considered, namely, only the affected individual is modified, and the whole architecture is operated again.

As shown in fig. 5, starting from the "transaction client" object, in the data relationship model segment integrated in the model library, the "transaction client" data object is taken as the origin, and the data relationship spans multiple business fields including orders, contracts, sales organizations, clients, organization structures, cost centers … …, and the like, which describe a complex, unique, consistent and integrated data structure of an enterprise business. In practice, however, such comprehensive and complex analysis is not performed at all at the time of design. Each box in fig. 5 is an independent small design field. In practice, system analysts only face limited object-to-object relationships in separate small design domains to analyze and design. The micro-to-micro, and ultimately comprehensive and complex constituent objects and their relational architecture, i.e., the overall software architecture, e.g., the complete data structure with transaction client data objects as the origin, is integrated by the model processing tool, which "evolves naturally" rather than "artificially" with the progress of each small design domain.

The criteria for verifying that the software architecture is correct is not an understanding of the business, but rather whether each minimum task and/or function to be completed works accurately. If not, the component object and its relationship corresponding to each minimum task and/or function to be completed are modified until it can work accurately. If each independent individual can work accurately, the whole structure is necessarily correct, and the correct whole structure can be obtained by regenerating once after the modification of the independent individual is completed.

In addition to data objects, micro services may of course also generate complete integrated structures according to the above-described methods. As long as each micro-service is operating accurately in this integrated structure, the integrated structure is also operating accurately.

The same logic and method as the above examples can be generalized to how individual data objects are aggregated/combined into service objects, how individual service objects are combined with service operations into service functions, how individual service functions are integrated and linked with service functions, how individual service functions are bound with UIs to form application scenarios, how individual application scenarios are combined with application scenarios to form the final system … … until all component objects and object relationships in software are covered. All individual analytical designs can be integrated to form an integral software architecture model as well. Besides visualizing the original invisible relationship, the low-code tool can be used for analyzing the software architecture model to dynamically generate all source codes based on the whole software architecture. For example, the database DDL and the data access layer code, the code of the data object aggregate/combine into a service object, the framework structure of the micro-service and the API code, the code of the micro-service processing service object, the code of the service object split into data objects, the integrated code between the micro-services, the flow code of the interaction between the micro-services, the binding code of the micro-service assembly into the service scene, the route integrated code of the front-end page forming the service scene, the integrated code of the service scene assembly into the application system, etc. Thus, no matter how complex an enterprise software is, the enterprise software can only work simply and clearly in countless small design domains, a model processing tool is used for integrating a plurality of design domains to form an integral complex software composition object and a relation model thereof, and a low code generating tool is used for generating an integral architecture code to dynamically obtain a final executable whole software architecture.

The method relies on rapid iteration of countless small design domains, the dynamically generated whole software architecture can be independent of the scale and complexity of the software, analysis design work is always simple and clear, unique and consistent data is guaranteed from the source, the integration is naturally realized, the influence of frequent change on the architecture is not considered, and the consistency of design and realization codes is always maintained.

According to the embodiment of the disclosure, the following technical effects are achieved:

1. the whole software architecture generated dynamically depends on the rapid iteration of countless small design domains, so that the scale and the whole complexity of the software can be disregarded.

2. The analysis design work is always simple and clear, and the software design team only needs to pay attention to the individual components and the peripheral relations thereof, but does not need to pay attention to the whole software architecture, so that the capability requirement on the design team is greatly reduced.

3. The whole software architecture and the source code thereof are dynamically generated by the individual analysis of the component objects and the relation model of other component objects directly interacted with the component objects, so that the design and the realization code can be always kept consistent regardless of the influence of frequent change of requirements on the architecture.

It should be noted that, for simplicity of description, the foregoing method embodiments are all described as a series of acts, but it should be understood by those skilled in the art that the present disclosure is not limited by the order of acts described, as some steps may be performed in other orders or concurrently in accordance with the present disclosure. Further, those skilled in the art will also appreciate that the embodiments described in the specification are all alternative embodiments, and that the acts and modules referred to are not necessarily required by the present disclosure.

The foregoing is a description of embodiments of the method, and the following further describes embodiments of the present disclosure through examples of apparatus.

Fig. 6 shows a block diagram of a freely evolving software build device 200 according to an embodiment of the disclosure. As shown in fig. 6, the apparatus 600 includes:

the decomposition module 602 is configured to decompose the minimum tasks and/or functions to be completed respectively, so as to obtain corresponding component objects;

the design module 604 is configured to set association rules and interaction rules of each component object, form an independent model relationship corresponding to the component object, and store the independent model relationship in a unified model library;

the integration module 606 is configured to extract a model relationship corresponding to the required component object from the model library and integrate the model relationship to generate an overall software architecture;

and the code generating module 608 is configured to generate source code corresponding to the overall software architecture.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the described modules may refer to corresponding procedures in the foregoing method embodiments, which are not described herein again.

According to embodiments of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium and a computer program product.

Fig. 7 shows a schematic block diagram of an electronic device 700 that may be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

The electronic device 700 includes a computing unit 701 that can perform various appropriate actions and processes according to a computer program stored in a ROM702 or a computer program loaded from a storage unit 708 into a RAM 703. In the RAM703, various programs and data required for the operation of the electronic device 700 may also be stored. The computing unit 701, the ROM702, and the RAM703 are connected to each other through a bus 704. I/O interface 705 is also connected to bus 704.

Various components in the electronic device 700 are connected to the I/O interface 705, including: an input unit 706 such as a keyboard, a mouse, etc.; an output unit 707 such as various types of displays, speakers, and the like; a storage unit 708 such as a magnetic disk, an optical disk, or the like; and a communication unit 709 such as a network card, modem, wireless communication transceiver, etc. The communication unit 709 allows the electronic device 700 to exchange information/data with other devices through a computer network, such as the internet, and/or various telecommunication networks.

The computing unit 701 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of computing unit 701 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as method 100. For example, in some embodiments, the method 100 may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as the storage unit 708. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 700 via the ROM702 and/or the communication unit 709. When the computer program is loaded into RAM703 and executed by computing unit 701, one or more steps of method 100 described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform the method 100 by any other suitable means (e.g., by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems-on-chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: display means for displaying information to a user; and a keyboard and pointing device (e.g., a mouse or trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the internet.

The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server incorporating a blockchain.

It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps recited in the present disclosure may be performed in parallel, sequentially, or in a different order, provided that the desired results of the disclosed aspects are achieved, and are not limited herein.

The above detailed description should not be taken as limiting the scope of the present disclosure. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present disclosure are intended to be included within the scope of the present disclosure.

Claims (10)

1. A method of freely evolving software build comprising:

decomposing the minimum tasks and/or functions to be completed respectively to obtain corresponding composition objects;

setting association rules and interaction rules of all the component objects, forming independent model relations corresponding to the component objects, and storing the independent model relations into a unified model library;

extracting model relations corresponding to the required composition objects from the model library and integrating the model relations to generate an overall software architecture;

and generating source codes corresponding to the whole software architecture.

2. The method of claim 1, wherein the constituent objects satisfy the following rules:

sharing the same model library; guaranteeing the uniqueness of the constituent objects and multiplexing it; the relationships between constituent objects are described by the same rule.

3. The method of claim 2, wherein the deriving the corresponding constituent object further comprises:

storing the decomposed component objects into a unified model library, wherein object definitions in the model library comprise: component object ID, generator of component object, association rule of component object, interaction rule of component object.

4. The method of claim 1, wherein setting association rules and interaction rules for each constituent object, forming independent model relationships, and storing in a unified model library comprises:

setting association rules and interaction rules of each component object and other component objects directly interacted with the component object; an independent model relationship is formed for each constituent object and stored in a unified model library.

5. The method of claim 1, wherein the generating an overall software architecture comprises:

and integrating the independent model relation corresponding to each required object into an integral relation structure formed by each required component object.

6. The method of claim 1, wherein the overall software architecture is used to implement the decomposed minimum tasks and/or functions; or, a minimum function and/or combination of functions that have been decomposed.

7. The method of claim 1, wherein the method further comprises:

if the completed minimum task and/or function is changed, decomposing the changed minimum task and/or function to obtain a corresponding composition object and a corresponding association rule and interaction rule; updating the independent model relation corresponding to the corresponding composition object; and extracting the model relation corresponding to the required composition object from the model library, and integrating to generate the whole software architecture.

8. A free-evolving software building device, comprising:

the decomposition module is used for decomposing the minimum tasks and/or functions to be completed respectively to obtain corresponding composition objects;

the design module is used for setting association rules and interaction rules of all the component objects, forming independent model relations corresponding to the component objects and storing the independent model relations into a unified model library;

the integration module is used for extracting the model relation corresponding to the required composition object from the model library and integrating the model relation to generate an overall software architecture;

and the code generation module is used for generating source codes corresponding to the whole software architecture.

9. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein, the liquid crystal display device comprises a liquid crystal display device,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

10. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-8.

Images