automated software generation of mutations and artificial selection

Abstract

Techniques for automatically generating target software objects herein include accessing an initial version of a candidate software object that does not satisfy one or more functional requirements, mutating executable binary object code of the initial version of the candidate software object to generate a first intermediate version, testing the first intermediate version by executing the first intermediate version and a set of automated tests to determine whether the first intermediate version satisfies at least one of the one or more functional requirements, and continuing to mutate and test the candidate software object through successive intermediate versions of the candidate software object until a version of the candidate software object satisfies all of the one or more functional requirements, wherein each successive intermediate version of the candidate software satisfies at least one functional requirement that is not satisfied by a previous version of the candidate software object.

Description

Background Technology

[0001] Software development is a complex process that requires significant knowledge of at least one programming language and the computing devices on which the software can be deployed. Complex software may require an entire team of skilled software programmers to implement. There are many important areas for new and approved mechanisms to streamline and automate the software development process. Summary of the Invention

[0002] The computing device according to a first aspect of this disclosure includes a processor and a computer-readable medium. The computer-readable medium stores executable instructions for causing the processor to perform operations including: accessing an initial version of a candidate software object that does not satisfy one or more functional requirements of a target software object; mutating executable binary object code of the initial version of the candidate software object to generate a first intermediate version of the candidate software object; testing the first intermediate version of the candidate software object by executing the first intermediate version of the candidate software object and an automated test set to determine whether the first intermediate version of the candidate software object satisfies at least one of the one or more functional requirements, and determining whether the output of the first intermediate version of the candidate software object corresponds to a predetermined set of outputs, the automated test set providing a predetermined set of inputs to the first intermediate version of the candidate software object; and continuing to mutate and test the candidate software object with successive intermediate versions of the candidate software object until a version of the candidate software object satisfies all of the one or more functional requirements, wherein each successive intermediate version of the candidate software satisfies at least one functional requirement not satisfied by a previous version of the candidate software object.

[0003] The method according to the second aspect of this disclosure is executed by a data processing system for automatically generating a target software object, comprising: accessing an initial version of a candidate software object via a processor that does not meet one or more functional requirements of the target software object; mutating the executable binary object code of the initial version of the candidate software object via the processor to generate a first intermediate version of the candidate software object; testing the first intermediate version of the candidate software object via the processor by executing the first intermediate version of the candidate software object and an automated test set to determine whether the first intermediate version of the candidate software object meets at least one of the one or more functional requirements, and determining whether the output of the first intermediate version of the candidate software object corresponds to a predetermined set of outputs, the automated test set providing a predetermined set of inputs for the first intermediate version of the candidate software object; and continuing to mutate and test the candidate software object with successive intermediate versions of the candidate software object until a version of the candidate software object meets all of the one or more functional requirements, wherein each successive intermediate version of the candidate software object meets at least one functional requirement not met by a previous version of the candidate software object.

[0004] According to the memory device storage instructions of the third aspect of this disclosure, when executed on a processor of a computing device, the computing device automatically generates a target software object by: accessing an initial version of a candidate software object that does not meet one or more functional requirements of the target software object; mutating the executable binary object code of the initial version of the candidate software object to generate a first intermediate version of the candidate software object; testing the first intermediate version of the candidate software object by executing the first intermediate version of the candidate software object and an automated test set to determine whether the first intermediate version of the candidate software object meets at least one of the one or more functional requirements, and determining whether the output of the first intermediate version of the candidate software object corresponds to a predetermined set of outputs, the automated test set providing a predetermined set of inputs for the first intermediate version of the candidate software object; and continuing to mutate and test the candidate software object with successive intermediate versions of the candidate software object until a version of the candidate software object meets all of the one or more functional requirements, wherein each successive intermediate version of the candidate software object meets at least one functional requirement not met by a previous version of the candidate software object.

[0005] This summary is provided to introduce a selection of concepts in a simplified form, which will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that address any or all of the disadvantages pointed out in any part of this disclosure. Attached Figure Description

[0006] The accompanying drawings depict one or more implementations of this teaching by way of example only and not by way of limitation. In the drawings, similar reference numerals refer to the same or similar elements. Furthermore, it should be understood that the drawings are not necessarily drawn to scale.

[0007] Figure 1 A functional diagram of the components of the system used for automatically generating program code is presented;

[0008] Figure 2A and 2B An example of automated program executable code using mutation and human selection is shown;

[0009] Figure 3 A flowchart is presented to illustrate an example process for generating program code using mutation and human selection;

[0010] Figure 4 This is a block diagram illustrating an example software architecture, the various parts of which can be used in conjunction with the various hardware architectures described herein, enabling the implementation of any of the features described herein; and

[0011] Figure 5 This is a block diagram illustrating a component configured to read instructions from a machine-readable medium and execute any of the features described herein. Detailed Implementation

[0012] In the following detailed description, many specific details are illustrated by way of examples to provide a thorough understanding of the teachings. However, it should be apparent that these teachings can be practiced without these details. In other cases, well-known methods, processes, components, and / or circuits have already been described at a relatively high level without detail to avoid unnecessarily obscuring aspects of these teachings.

[0013] Figure 1 The illustration shows an example computing environment 100 that can be implemented on a data processing system. The data processing system may include a single computing device, or... Figure 1 The functionality of the components shown can be distributed across multiple computing devices. Data processing systems can include standalone machines that can be embodied as, for example, server computers, client computers, personal computers (PCs), tablet computers, or laptop computers. Other types of computing devices can also be used to execute the automated software development techniques disclosed herein.

[0014] Example computing environment 100 includes mutation unit 110, manual selection unit 120, test environment 115, functional requirements of target software object 135, functional requirement test 140, basic software object 105, candidate software object 125, and target software object 130. Mutation unit 110, manual selection unit 120, or both, can be implemented as processor-executable program code stored in persistent memory of the data processing system.

[0015] Example computing environment 100 can be used to automatically generate executable program code through the processes of mutation and artificial selection. Biological systems can evolve new life forms through mutation and natural selection. Mutation alters the biological system into which the life form is introduced. Natural selection occurs when those life forms best adapted to survive environmental stresses continue to exist, while those not adapted to these stresses become extinct. The techniques disclosed herein use these concepts to automatically generate executable program code through the processes of mutation and artificial selection. As used herein, mutation refers to the process of altering a software object to create a new candidate software object. As used herein, artificial selection refers to the process of testing candidate software objects generated through mutation to determine whether the candidate software object is executable and whether it meets one or more functional requirements of the target software object.

[0016] To generate new software using this process, a set of functional requirements can first be developed for the target software object. Functional requirements define the functionality of the target software object to be generated. The functionality of a software object can be defined based on (multiple) inputs and (multiple) outputs. If one or more specific inputs are provided, one or more specific outputs are expected. Defining the functional requirements of the software to be developed is a common practice in software development.

[0017] Functional requirements can be used to develop test cases, which can be used to determine whether candidate software objects can perform specific functional requirements. A set of test inputs and expected outputs can be developed to test specific functional requirements. These tests can be formalized as a set of executable scripts or program code, which can be automatically executed by the manually selected unit 120 to test whether the software under development performs as expected.

[0018] In traditional software development, programmers receive the functional requirements of the software and design and implement its source code. Source code is a human-readable set of instructions that can be compiled or interpreted into executable object code or machine code. Writing source code is very time-consuming and requires extensive knowledge of the computer language in which the software is developed, as well as knowledge of the computing devices used to develop it. Even simple programs can require a large number of lines of code. Complex programs may consist of thousands of lines of code and may require a team of programmers to develop. Once completed, the code may undergo multiple rounds of testing to ensure it performs as expected.

[0019] The techniques disclosed herein eliminate the need for programmers or teams of programmers to write program code. Instead, a set of functional requirements for a "target software object" can be defined, and executable program code for the target software object can be automatically generated through an iterative process of mutation and manual selection, as described in detail in the following examples. The target software object 130 can be a standalone program or a component of a program suite. The mutation unit 110 can perform the mutation aspects of the automated software development techniques disclosed herein, and the manual selection unit 120 can perform the manual selection aspects of these techniques.

[0020] Mutation unit 110 can access base software object 105 and mutation unit configuration information 145. Base software object 105 can be the shell of an executable program object, which can be used as a framework on which mutation can be executed. Base software object 105 can be in Portable Executable (PE) format or other executable formats. Mutation unit configuration information 145 can include information identifying the file format of base software object 105. Mutation unit 110 can be able to operate on a variety of different executable file formats. Base software object 105 can be selected from a library of base software objects, which includes a variety of different file formats suitable for use in various computing environments. Mutation unit configuration information 145 can include the identifier of base software object 105 in the base software object library, and mutation unit 110 can access the base software object library to obtain a copy of base software object 105. The library can be implemented as a database or other data repository in the persistent storage of a data processing system. The library can provide a user interface that allows users to add, modify, and / or delete base software objects from the library. Mutation unit 110 can also provide a user interface that allows users to create, view, modify, or delete mutation unit configuration information 145. The user interface can also allow users to create a version of the mutation unit configuration information 145 for each of the multiple target software objects 130 to be developed.

[0021] The mutation unit configuration information 145 can provide the memory location of the computing environment in which the base software object 105 may reside. The mutation unit configuration information 145 can also provide information about the underlying structure of the base software object 105, such as the size and / or offset of each segment or sub-segment of the base software object 105. For example, the base software object 105 may include a header segment and a code segment, and the mutation unit configuration information 145 can indicate the location where these segments are located. The header segment may include information such as libraries to be used by the base software object 105, import address tables, etc. The mutation unit 110 does not change the information included in the header segment when mutating the base software object 105 or the candidate software object 125.

[0022] Executable software consists of a sequence of bit values ​​representing program code, data, and other components of the software. Mutation unit 110 can mutate the base software object 105 by changing bits in the executable code segment of the base software object 105 to generate a candidate software object 125. In some implementations, the base software object 105 may begin with a blank executable code segment, and mutation unit 110 may generate executable program code for that segment. In other implementations, the base software object 105 may include executable program code that may already satisfy one or more of the functional requirements of the target software object 130 to be developed. In such implementations, mutation unit 110 may protect functional code segments already included in the base software object 105 and begin the mutation process in a second segment of the code segment of the base software object 105. Mutation unit configuration information 145 may specify that the base software object 105 includes a first code segment, which includes functional executable code. Mutation unit configuration information 145 may indicate the offset within the code segment of the base software object 105 from which the mutation process begins. The existing functional code will not be changed by mutation unit 110, while still providing the opportunity to add additional functionality to the base software object 105 using the mutation and artificial selection techniques disclosed herein.

[0023] Mutation unit 110 can mutate base software object 105 to generate candidate software object 125. Candidate software object 125 can be output by mutation unit 110 to test environment 115. Alternatively, mutation unit 110 can output candidate software object 125 to manual selection unit 120, or manual selection unit 120 can access candidate software object 125 and copy it to a memory location in test environment 115. Test environment 115 can be an isolated computing environment where the functionality of candidate software object 125 can be tested without being affected by any other software. In some implementations, test environment 115 can be implemented as a virtual machine that can simulate the properties of the computing device on which the target software object is intended to be used.

[0024] Mutation unit 110 can mutate either the base software object 105 or the candidate software object 125 through a series of positional swaps. As discussed with respect to the foregoing examples, executable code consists only of a specific sequence of bit values ​​one and zero, which defines the instructions, data, and other components of the executable code. Multiple methods may be possible to achieve the same functionality. Therefore, there may be more than one bit value sequence that can perform the desired function.

[0025] Mutation unit 110 uses the idea that software can be simplified to a bit pattern to generate candidate software object 125. The code segment of candidate software object 125 can initially be blank, and mutation unit 110 can sequentially and progressively pass through each possible bit sequence of a specific length, and (1) set the segment of the code segment of candidate software object 125 to the binary sequence; (2) place candidate software object 125 into test environment 115 or provide candidate software object 125 to manual selection unit 120; (3) send a signal to manual selection unit 120 to test candidate software object 125; (4) receive the test result from manual selection unit 120. Mutation unit 110 can lock the content of the segment of the code segment being replaced in response to manual selection unit 120 instructing candidate software object 125 to meet one or more additional functional requirements. Otherwise, mutation unit 110 can continue to mutate the segment of the previously mutated code segment by selecting the next bit sequence to be tested and setting the value of the segment of the code segment of candidate binary software object to that value. The mutation process can be used to generate a fully functional target software object 130 that meets one or more functional requirements of the target software object, without requiring the programmer to write any program code.

[0026] The manual selection unit 120 can access the functional requirement tests 140 associated with the target software object 130. The functional requirement tests 140 can be stored in a database or other persistent storage of the computing environment 100. The functional requirement tests 140 can be a collection of executable program code or scripts used to test the candidate software object 125 to determine whether the candidate software object 125 is: (1) executable, and (2) satisfies one or more functional requirements associated with the target software object 130. The functional requirement tests 140 can include a collection of one or more tests for each functional requirement of the target software object 140. The manual selection unit 120 can execute one or more tests associated with each functional requirement to determine whether the candidate software object 125 satisfies that functional requirement. Each test can provide a collection of one or more inputs that can be provided to the candidate software object, and a collection of one or more expected outputs associated with these inputs.

[0027] If candidate software object 125 generates (multiple) expected outputs for each test associated with a functional requirement, then manual selection unit 120 can determine that candidate software object 125 meets the functional requirement. If candidate software object 125 meets all functional requirements associated with the target software object, then manual selection unit 120 can adopt candidate software object 125 as a full-featured software object and output candidate software object 125 as target software object 130.

[0028] If candidate software object 125 satisfies a subset of one or more functional requirements associated with target software object 130, the manual selection unit 120 may send a signal to mutation unit 110 that candidate software object 125 satisfies one or more functional requirements. Mutation unit 110 may continue to mutate candidate software object 125, but may lock the current content of the first segment of the code segment of candidate software object 125 to prevent unintentional corruption of the functional code by further mutation of that code segment. Mutation unit 110 may then begin mutating a second segment of the code segment to attempt to generate executable code that satisfies at least one additional functional requirement.

[0029] If candidate software object 125 does not meet any functional requirements associated with target software object 130, candidate software object 125 may be discarded by manual selection unit 120. Manual selection unit 120 may send a signal to mutation unit 110 that candidate software object 125 should continue to be mutated without locking the segment of the mutated code segment.

[0030] If candidate software object 125 satisfies at least one functional requirement from previous iterations of mutation and manual selection, and candidate software object 125 now satisfies at least one additional functional requirement in the current iteration but not all functional requirements of target software object 130, then manual selection unit 120 can send a signal to mutation unit 110 indicating that the candidate software object has additional functions that should be protected. Mutation unit 110 can protect that segment of the code segment of candidate software object 125 from further mutations, and mutation unit 110 can continue to mutate new segments of the code segment of candidate software object 125. Figure 2A and 2B An example of this process is illustrated in the diagram, which will be discussed in detail below.

[0031] Figure 2A and 2BAn example of automated programmable code using mutation and manual selection is illustrated, illustrating the concepts discussed in the preceding examples. In these examples, a mutation and manual selection process is performed on a base software object 205 to generate a target software object 270. The base software object 205 includes a header segment 210 and a code segment 215. The header segment 210 includes information that may include library file information, an import address table, and / or other information supporting the executable code segment. The header is not modified by the mutation unit 110. The base software object 205 may include other segments besides the header segment or in place of the header segment, depending on the format of the base software object 205, and the mutation unit 110 does not modify these segments. The code segment 215 in the base software object 205 is blank in this example, meaning that there is no working executable program code in the base software object 205, and the base software object 205 serves as an empty frame on which the mutation unit 110 can operate.

[0032] To illustrate these concepts, the examples shown in Figures 2A and 2B demonstrate the automated generation of a simple calculator program object with only three functional requirements: (1) addition; (2) subtraction; and (3) multiplication. The functional requirements of this example are very simple to illustrate the mutation and human selection concepts disclosed herein.

[0033] Tests associated with each of these functional requirements can be defined and added to functional requirement test 140, which can be executed by manual selection unit 120 to determine whether a candidate software object meets any one of the functional requirements of target software object 130. For example, a user can develop a series of test inputs and expected outputs to test each functional requirement of the calculator application. Tests can be developed as scripts or simple executable programs that provide a set of test inputs to the candidate software object and obtain outputs from the candidate software object for each of these test inputs. Manual selection unit 120 can compare the outputs from the candidate software object to determine whether the outputs match the expected outputs for each test. The expected outputs in this example are simple numerical values, but functional requirements can specify more complex outputs. For example, the target software object can receive input data and perform more complex calculations, modifications, or other processing on the input data than the simple mathematical calculations discussed in this example.

[0034] Candidate software object 220a illustrates an example of the output of mutation unit 110. Candidate software object 220a includes a header segment 225a that can be identical to the header segment 210 of the base software object 205, and a code segment 230a that can be identical to the code segment 215 of the base software object 205. Candidate software object 220a includes generated code segments 235a. The generated code segments 235a consist of bit sets generated by mutation unit 110. The generated code segments 235a may have been generated through multiple mutation iterations by mutation unit 110. Candidate software object 220a can be tested by manual selection unit 120 to determine whether candidate software object 220a meets one or more of the functional requirements associated with target software object 130.

[0035] In this example, the manual selection unit 120 may perform a functional requirement test 140 on the candidate software object 220a to determine whether the candidate software object 220a meets at least one functional requirement of the target software object 130. In this example, the candidate software object 220a meets a first functional requirement, such as the requirement to add a calculator application, and in response, the manual selection unit 120 may send the following instruction to the mutation unit 110: the candidate software object 220a meets the first functional requirement associated with the target software object 270, but there are additional functional requirements to be met.

[0036] Mutation unit 110 can generate new candidate software object 220b based on candidate software object 220a. Mutation unit 110 can mark the generated code segment 235a as a functional code segment 240b to indicate that the program code segment therein meets the functional requirements of target software object 130 and should be retained to prevent further mutations. In this example, the mutation unit can continue to mutate candidate software object 220b because candidate software object 220b still does not meet two of the functional requirements of the calculator application.

[0037] Mutation unit 110 mutates candidate software object 220b to produce candidate software object 220c. Functional code segment 240c includes the contents of functional code segment 240b from previous mutation iterations. Mutation unit 110 protects functional code segment 240c and begins mutating the contents of a second code segment represented by the generated code segment 235c. Since candidate software object 220b was mutated first, the generated code 235c may include one or more mutation iterations of mutation unit 110.

[0038] The manual selection unit 120 can perform a functional requirement test 140 on the candidate software object 220c to determine whether the candidate software object 220c meets at least one additional functional requirement of the target software object 130. In this example, the candidate software object 220c meets a second functional requirement, such as a subtraction requirement for a calculator application. The manual selection unit 120 can send an indication to the mutation unit 110 that the candidate software object 220c meets the second functional requirement.

[0039] Mutation unit 110 can generate candidate software object 220d based on candidate software object 220c. Mutation unit 110 can mark code segment 235c generated from candidate software as second functional code segment 242d. Therefore, the program code associated with the first two functional requirements of target software object 130 has been satisfied, and mutation unit 110 has protected the portion of the code segment containing this code from further mutation.

[0040] Mutation unit 110 can then further mutate candidate software object 220d to generate candidate software object 220e. Candidate software object 220e includes the generated code segment 235e. Manual selection unit 120 can perform a functional requirement test 140 on candidate software object 220e to determine whether candidate software object 220e meets at least one additional functional requirement of target software object 130. In this example, candidate software object 220e meets a third functional requirement, the multiplication requirement for the calculator application. Manual selection unit 120 can send an indication to mutation unit 110 that candidate software object 220e meets both the third and final functional requirements. Mutation unit 110 can generate target software object 270 based on candidate software object 220e. Target software object 270 meets all functional requirements defined for target software object in this example.

[0041] The target software object 270 can be added to a software database or data repository. The target software object 270 can be downloaded or copied from the database or data repository and can be deployed to one or more computing devices. The target software object 270 can be a component of a software suite and can be stored together with other components of the software suite that have been successfully generated using the mutation and artificial selection techniques disclosed herein.

[0042] Figure 3 This is a flowchart illustrating an implementation of an example process 300 executed by a data processing system, used to generate program code using mutation and manual selection. In some examples, some or all of process 300 can be combined. Figure 1 and 2A -2B discusses any of the features to be executed. Process 300 can be implemented by a data processing system, such as the communication platform described in the previous examples or Figure 4The example software architecture 400 and / or shown Figure 5 The example machine 500 shown can be executed by a messaging application running on a data processing system.

[0043] Process 300 may include a first operation 310, wherein an initial version of the candidate software object (also referred to herein as the base software object) does not meet one or more functional requirements of the target software object. As discussed in the preceding examples, a base software object may be selected that has substantially blank or empty code segments that do not contain executable code. In other implementations, the base software object may include some functional executable program code. In implementations where the code segments include some functional executable program code, mutation unit 110 may protect existing functional code when mutating the base software object.

[0044] Process 300 may include a second operation 320, which includes mutating the executable binary object code of an initial version of the candidate software object to generate a first intermediate version of the candidate software object. As discussed in the preceding examples, mutation unit 110 may mutate code segments of the binary object to generate a new version of the candidate software object, which may be tested by manual selection unit 120 to determine whether the new version of the candidate software object meets one or more functional requirements of the target software object.

[0045] Process 300 may include a third operation 330, which includes testing a first intermediate version of the candidate software object to determine whether the first intermediate version of the candidate software object meets at least one of one or more functional requirements. Testing can be performed by executing the first intermediate version of the candidate software object and an automated functional test set, which provides a predetermined set of inputs to the first intermediate version of the candidate software object and determines whether the output of the first intermediate version of the candidate software object corresponds to a predetermined set of outputs. Functional tests can be defined by the user based on the functional requirements of the target software object. The user can define a test set for each functional requirement, where the input set is provided to the intermediate version of the candidate software object. If the output of the intermediate version of the candidate software object corresponds to the expected value of the inputs, the intermediate version of the candidate object meets the test. If all tests related to the functional requirement are met, the first intermediate version of the candidate software object meets the functional requirement. The manual selection unit 120 sends a signal to the mutation unit 110 indicating that the first intermediate version of the candidate software object meets the functional requirements. The mutation unit 110 can protect portions of the code segment including the functional code from further mutation and create a second intermediate version of the candidate software object that can continue to be mutated and tested.

[0046] Process 300 may include a fourth operation 340, which involves continuing to mutate and test the candidate software object through successive intermediate versions until a version of the candidate software object meets all of one or more functional requirements. Each successive intermediate version of the candidate software satisfies at least one functional requirement that was not met by a previous version of the candidate software object. Through this iterative process, complex executable code can be developed without requiring users to write code to perform the functionality of the target software object. The software development process is an iterative process in which additional functionality can be added through mutation and manual selection in each iteration until the desired functionality of the target software object is obtained.

[0047] Combination Figure 1-3 Detailed examples of the systems, devices, and technologies described herein are presented to illustrate this disclosure and its benefits. Such examples of use should not be construed as limiting the logical process embodiments of this disclosure, nor should variations of the user interface methods described herein be considered outside the scope of this disclosure. It should be understood that references to displaying or presenting items (such as, but not limited to, presenting images on a display device, presenting audio via one or more speakers, and / or vibrating devices) include issuing instructions, commands, and / or signals that cause or are reasonably expected to cause a device or system to display or present that item. In some embodiments, Figure 1-3 The various features described are implemented in their respective modules, which may also be referred to as and / or include logic, components, units, and / or mechanisms. Modules can constitute software modules (e.g., code embodied on a machine-readable medium) or hardware modules.

[0048] In some examples, hardware modules may be implemented mechanically, electronically, or using any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic configured to perform certain operations. For example, a hardware module may include a dedicated processor, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). A hardware module may also include programmable logic or circuitry temporarily configured by software to perform certain operations, and may include a portion of machine-readable medium data and / or instructions for such configuration. For example, a hardware module may include software encompassed within a programmable processor configured to execute a set of software instructions. It should be understood that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost, time, support, and engineering considerations.

[0049] Therefore, the phrase "hardware module" should be understood to encompass tangible entities capable of performing certain operations and which can be configured or arranged in a physical manner; that is, entities that are physically constructed, permanently configured (e.g., hardwired), and / or temporarily configured (e.g., programmed) to operate or perform certain operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Considering the example of hardware modules being temporarily configured (e.g., programmed), each hardware module does not need to be configured or instantiated at any given time instance. For example, in the case where the hardware module includes a programmable processor configured by software to become a dedicated processor, the programmable processor can be configured as different dedicated processors (e.g., including different hardware modules) at different times. The software can accordingly configure one or more processors, for example, to constitute a particular hardware module in one time instance and different hardware modules in different time instances. A hardware module implemented using one or more processors can be referred to as "processor-implemented" or "computer-implemented."

[0050] Hardware modules can provide information to and receive information from other hardware modules. Therefore, the described hardware modules can be considered communicationally coupled. When multiple hardware modules exist simultaneously, communication can be achieved through signal transmission between two or more hardware modules (e.g., via appropriate circuitry and buses). In embodiments where multiple hardware modules are configured or instantiated at different times, communication between these hardware modules can be achieved, for example, through the storage and retrieval of information in memory devices accessible to the multiple hardware modules. For example, one hardware module can perform an operation and store the output in a storage device, and then another hardware module can access the storage device to retrieve and process the stored output.

[0051] In some examples, at least some of the operations of the method can be performed by one or more processors or modules implemented by processors. Furthermore, one or more processors can also operate to support the performance of the relevant operations in a “cloud computing” environment or as “Software as a Service” (SaaS). For example, at least some operations can be performed by multiple computers (as an example of a machine including processors) and / or across multiple computers, where these operations are accessible via a network (e.g., the Internet) and / or via one or more software interfaces (e.g., application programming interfaces (APIs)). The performance of certain operations can be distributed among processors, residing not only within a single machine but also deployed across multiple machines. Processors or modules implemented by processors can reside in a single geographic location (e.g., in a home or office environment, or within a server farm) or can be distributed across multiple geographic locations.

[0052] Figure 4This is a block diagram 400 illustrating an example software architecture 402, the various parts of which can be used in conjunction with various hardware architectures described herein, which can implement any of the features described above. Figure 4 This is a non-limiting example of a software architecture, and it should be understood that many other architectures can be implemented to facilitate the functionality described herein. Software architecture 402 can be implemented in, for example... Figure 5 The hardware of the machine 500 is executed, which includes a processor 510, a memory 530, and input / output (I / O) components 550, etc. A representative hardware layer 404 is shown and can represent, for example... Figure 5 The machine 500. Hardware layer 404 includes a processing unit 406 and associated executable instructions 408. Executable instructions 408 represent executable instructions of software architecture 402, including implementations of the methods, modules, etc., described herein. Hardware layer 404 also includes a memory / storage device 410, which also includes the executable instructions 408 and accompanying data. Hardware layer 404 may also include other hardware modules 412. Instructions 408 held by processing unit 406 may be part of instructions 408 held by memory / storage device 410.

[0053] Example software architecture 402 can be conceptualized as layers, each providing various functionalities. For example, software architecture 402 may include layers and components such as an operating system (OS) 414, libraries 416, frameworks 418, applications 420, and a presentation layer 444. Operationally, applications 420 and / or other components within a layer can call API calls 424 to other layers and receive corresponding results 426. The layers shown are representative in nature, and other software architectures may include additional or different layers. For example, some mobile or dedicated operating systems may not provide frameworks / middleware 418.

[0054] OS 414 can manage hardware resources and provide public services. OS 414 may include, for example, a kernel 428, services 430, and drivers 432. Kernel 428 can act as an abstraction layer between hardware layer 404 and other software layers. For example, kernel 428 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. Services 430 can provide other public services to other software layers. Drivers 432 can be responsible for controlling the underlying hardware layer 404 or interfacing with the underlying hardware layer 404. For example, depending on the hardware and / or software configuration, drivers 432 may include display drivers, camera drivers, memory / storage device drivers, peripheral device drivers (e.g., via Universal Serial Bus (USB)), network and / or wireless communication drivers, audio drivers, etc.

[0055] Library 416 can provide common infrastructure that can be used by application 420 and / or other components and / or layers. Library 416 typically provides functionality for other software modules to perform tasks, rather than interacting directly with OS 414. Library 416 may include system libraries 434 (e.g., the C standard library) that provide functionality such as memory allocation, string manipulation, and file operations. Furthermore, library 416 may include API libraries 436, such as media libraries (e.g., those supporting the rendering and manipulation of image, sound, and / or video data formats), graphics libraries (e.g., OpenGL libraries for rendering 2D and 3D graphics on a display), database libraries (e.g., SQLite or other relational database functions), and web libraries (e.g., WebKit, which may provide web browsing functionality). Library 416 may also include various other libraries 438 to provide numerous functionalities for application 420 and other software modules.

[0056] Framework 418 (sometimes also called middleware) provides a higher level of common infrastructure that can be used by Application 420 and / or other software modules. For example, Framework 418 can provide various graphical user interface (GUI) functions, advanced resource management, or advanced location services. Framework 418 can provide a wide range of other APIs for Application 420 and / or other software modules.

[0057] Application 420 includes built-in application 440 and / or third-party application 442. Examples of built-in application 440 may include, but are not limited to, contact applications, browser applications, location applications, media applications, messaging applications, and / or game applications. Third-party application 442 may include any application developed by an entity other than a platform-specific vendor. Application 420 may use the functionality available via OS 414, library 416, framework 418, and presentation layer 444 to create a user interface for user interaction.

[0058] Some software architectures use virtual machines, such as virtual machine 448. Virtual machine 448 provides an execution environment where applications / modules can run as if on a hardware machine (such as...). Figure 5 The virtual machine 448 executes in the same way as on the host OS (e.g., OS 414) or hypervisor, and may have a virtual machine monitor 446 that manages the operation of the virtual machine 448 and interoperates with the host operating system. Software architectures that may differ from the software architecture 402 outside the virtual machine execute within the virtual machine 448, such as OS 414, libraries 452, frameworks 454, applications 456, and / or presentation layers 458.

[0059] Figure 5This is a block diagram illustrating components of an example machine 500 configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any of the features described herein. The example machine 500 is in the form of a computer system in which instructions 516 (e.g., in the form of a software component) can be executed to cause the machine 500 to perform any of the features described herein. Therefore, instructions 516 can be used to implement the modules or components described herein. Instructions 516 cause the unprogrammed and / or unconfigured machine 500 to operate as a specific machine configured to perform the described features. The machine 500 can be configured to operate as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, the machine 500 can operate as a server machine or client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. The machine 500 can be embodied as, for example, a server computer, client computer, personal computer (PC), tablet computer, laptop computer, netbook, set-top box (STB), gaming and / or entertainment system, smartphone, mobile device, wearable device (e.g., smartwatch), and Internet of Things (IoT) device. Furthermore, although only a single machine 500 is illustrated, the term "machine" includes a collection of machines that execute instructions 516 individually or in combination.

[0060] Machine 500 may include processor 510, memory 530, and I / O components 550, which may be communicatively coupled via, for example, bus 502. Bus 502 may include multiple buses that couple various components of machine 500 via various bus technologies and protocols. In examples, processor 510 (including, for example, a central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), ASIC, or suitable combinations thereof) may include one or more processors 512a to 512n capable of executing instructions 516 and processing data. In some examples, one or more processors 510 may execute instructions provided or recognized by one or more other processors 510. The term "processor" includes a multi-core processor, which includes cores capable of executing instructions simultaneously. Although Figure 5 shows multiple processors, machine 500 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors each with a single core, multiple processor cores each with multiple cores, or any combination thereof. In some examples, machine 500 may include multiple processors distributed across multiple machines.

[0061] Memory / storage device 530 may include main memory 532, static memory 534 or other memory, and memory cell 536, all of which may be accessed by processor 510, such as via bus 502. Memory cell 536 and memories 532, 534 store instructions 516 embodying any one or more of the functions described herein. Memory / storage 530 may also store temporary, intermediate, and / or long-term data for processor 510. Instructions 516 may also reside wholly or partially within memories 532, 534, memory cell 536, at least one of processor 510 (e.g., within a command buffer or cache memory), at least one of I / O components 550, or any suitable combination thereof, during their execution. Thus, memories 532, 534, memory cell 536, memory in processor 510, and memory in I / O components 550 are examples of machine-readable media.

[0062] As used herein, "machine-readable medium" means a device capable of temporarily or permanently storing instructions and data that cause machine 500 to operate in a particular manner, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical storage media, magnetic storage media and devices, cache, network-accessible or cloud storage, other types of storage, and / or any suitable combination thereof. The term "machine-readable medium" applies to a single medium or a combination of media for storing instructions (e.g., instruction 516) for execution by machine 500, such that when executed by one or more processors 510 of machine 500, the instructions cause machine 500 to perform one or more of the features described herein. Therefore, "machine-readable medium" can refer to a single storage device, as well as a "cloud-based" storage system or storage network comprising multiple storage devices or equipment. The term "machine-readable medium" does not include the signal itself.

[0063] I / O component 550 may include a variety of hardware components suitable for receiving input, providing output, generating output, sending information, exchanging information, capturing measurements, etc. The specific I / O component 550 included in a particular machine will depend on the type and / or function of the machine. Mobile devices such as mobile phones may include touch input devices, while headless servers or IoT devices may not. The specific examples of I / O components shown in Figure 5 are by no means limiting, and other types of components may be included in machine 500. The grouping of I / O components 550 is merely for the simplicity of this discussion and is by no means limiting. In various examples, I / O component 550 may include user output component 552 and user input component 554. User output component 552 may include, for example, display components (e.g., liquid crystal display (LCD) or projector) for displaying information, acoustic components (e.g., speakers), haptic components (e.g., vibration motors or force feedback devices), and / or other signal generators. User input component 554 may include, for example, alphanumeric input components (such as a keyboard or touchscreen), pointing components (such as a mouse device, touchpad or other pointing tool), and / or haptic input components (such as physical buttons or touchscreens that provide position and / or tactile force or touch gestures) configured to receive various user inputs, such as user commands and / or selections.

[0064] In some examples, I / O component 550 may include biometric component 556, motion component 558, environmental component 560, and / or location component 562, as well as a wide range of other physical sensor components. Biometric component 556 may include, for example, detecting body expressions (e.g., facial expressions, vocalizations, hand or body gestures, or eye tracking), measuring biosignals (e.g., heart rate or brainwaves), and identifying a person (e.g., via voice, retina, fingerprint, and / or face-based recognition). Motion component 558 may include, for example, an accelerometer (e.g., an accelerometer) and a rotation sensor (e.g., a gyroscope). Environmental component 560 may include, for example, a lighting sensor, a temperature sensor, a humidity sensor, a pressure sensor (e.g., a barometer), an acoustic sensor (e.g., a microphone for detecting ambient noise), a proximity sensor (e.g., infrared sensing of nearby objects), and / or other components that provide indications, measurements, or signals corresponding to the surrounding physical environment. Location component 562 may include, for example, a location sensor (e.g., a Global Positioning System (GPS) receiver), an altitude sensor (e.g., a barometer from which altitude can be derived), and / or a direction sensor (e.g., a magnetometer).

[0065] I / O component 550 may include communication component 564, implementing various technologies operable to couple machine 500 to network(s) 570 and / or device(s) 580 via corresponding communication couplers 572 and 582. Communication component 564 may include one or more network interface components or other suitable devices that interface with network(s) 570. Communication component 564 may include, for example, devices adapted to provide wired communication, wireless communication, cellular communication, near-field communication (NFC), Bluetooth communication, Wi-Fi, and / or communication via other means. Device(s) 580 may include other machines or various peripheral devices (e.g., coupled via USB).

[0066] In some examples, communication component 564 may detect identifiers or include components suitable for detecting identifiers. For example, communication component 564 may include a radio frequency identification (RFID) tag reader, an NFC detector, an optical sensor (e.g., a one-dimensional or multi-dimensional barcode or other optical code), and / or an acoustic detector (e.g., a microphone for identifying audio signals of the tag). In some examples, location information may be determined based on information from communication component 562, such as, but not limited to, geographic location via Internet Protocol (IP) address, location identified via Wi-Fi, cellular, NFC, Bluetooth, or other wireless stations, and / or signal triangulation.

[0067] While various embodiments have been described, this description is intended to be exemplary and not restrictive, and it should be understood that further embodiments and implementations within the scope of these embodiments are possible. Although many possible combinations of features are shown in the drawings and discussed in this detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature of any embodiment may be used in combination with or in lieu of any other feature or element in any other embodiment. Therefore, it should be understood that any feature shown and / or discussed in this disclosure may be implemented together in any suitable combination. Thus, the embodiments are not limited except as provided in the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.

[0068] While the content and / or other examples considered to be the best models have been described above, it should be understood that various modifications can be made therein, and the subject matter disclosed herein can be implemented in various forms and examples, and these teachings can be applied in many applications, some of which are described herein. The appended claims are intended to assert any and all applications, modifications, and variations that fall within the true scope of these teachings.

[0069] Unless otherwise stated, all measurements, values, ratings, locations, sizes, dimensions, and other specifications set forth in this specification, including in the following claims, are approximate and not precise. They are intended to have a reasonable range consistent with the functions they relate to and the conventions in the fields to which they relate.

[0070] The scope of protection is limited only by the following claims. When interpreted in accordance with this specification and the subsequent examination history, this scope is intended and should be interpreted as consistent with the ordinary meaning of the language used in the claims and covers all structural and functional equivalents. Nevertheless, none of the claims is intended to cover subject matter that fails to meet the requirements of Sections 101, 102, or 103 of the Patent Act, nor should they be interpreted in this manner. Any accidental coverage of such subject matter is hereby denied.

[0071] Except as stated above, nothing stated or described is intended or should be construed as offering any component, step, feature, object, benefit, advantage, or equivalent to the public, whether or not it is mentioned in the claims.

[0072] It should be understood that the terms and expressions used herein have the general meanings assigned to them by the corresponding fields of investigation and research, unless otherwise specified herein. Relational terms such as "first" and "second" may be used merely to distinguish one entity or action from another, without necessarily requiring or implying any actual such relationship or order between such entities or actions. 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 includes a list of elements includes not only those elements but may also include other elements not expressly listed or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element beginning with "a" or "an" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0073] A public abstract is provided to allow the reader to quickly determine the nature of the technical disclosure. It is understood that this abstract is not intended to interpret or limit the scope or meaning of the claims. Furthermore, in the detailed description above, it can be seen that various features are combined in various examples to simplify the disclosure. This method of disclosure should not be construed as reflecting an intention that the claims require more features than expressly listed in each claim. Rather, as reflected in the following claims, the inventive subject matter does not lie in all features of a single disclosed example. Therefore, the following claims are incorporated herein by reference, each claim existing independently as a separately claimed subject matter.

Claims

1. A computing device, comprising: processor; as well as A computer-readable medium storing executable instructions for causing the processor to perform operations including the following: Access the initial version of a candidate software object that does not meet multiple functional requirements of the target software object; A first intermediate version of the candidate software object is generated by mutating the executable binary object code of the initial version of the candidate software object. The first intermediate version of the candidate software object is tested using the following steps to determine whether the first intermediate version of the candidate software object meets at least one of the plurality of functional requirements: Execute the first intermediate version of the candidate software object; as well as Execute an automated test set, which provides a predetermined set of inputs for the first intermediate version of the candidate software object, and determine whether the output of the first intermediate version of the candidate software object corresponds to a predetermined set of outputs; In response to determining that the first intermediate version of the candidate software object satisfies at least one of the plurality of functional requirements, a first segment of the executable binary object code is locked to prevent the first segment from being unintentionally corrupted by further mutations; and The candidate software object continues to be mutated and tested through successive intermediate versions until a version of the candidate software object meets all of the multiple functional requirements, wherein each successive intermediate version of the candidate software object meets at least one functional requirement that was not met by a previous version of the candidate software object.

2. The computing device of claim 1, wherein the computer-readable medium further comprises instructions configured to cause the processor to perform operations including: In response to the first intermediate version of the candidate software object not meeting at least one of the plurality of functional requirements, the first intermediate version of the candidate software object is iteratively mutated and tested in the following manner: Further mutation is performed on the first intermediate version of the candidate software object; and The first intermediate version of the candidate software object with further mutations is tested to determine whether the first intermediate version of the candidate software object with further mutations meets at least one of the plurality of functional requirements.

3. The computing device of claim 2, wherein the instructions for mutating the first intermediate version of the candidate software object further include instructions for causing the processor to perform an operation comprising: Add at least one bit to the first intermediate version of the candidate software object.

4. The computing device of claim 3, wherein the instructions for adding the at least one bit to the first intermediate version of the candidate software object further include instructions for causing the processor to perform an operation comprising: Add the at least one bit to the code segment of the first intermediate version of the candidate software object.

5. The computing device of claim 4, wherein the instructions for continuing to mutate the first intermediate version of the candidate software object further include instructions configured to cause the processor to perform operations including: A second intermediate version of the candidate software object is generated by adding one or more bits to a second portion of the code segment of the first intermediate version of the candidate software object.

6. The computing device of claim 1, wherein the instructions for testing the first intermediate version of the candidate software object further include instructions for causing the processor to perform operations including: Perform one or more tests associated with the first functional requirement among the plurality of functional requirements; and In response to the first intermediate version of the candidate software object passing all or all of the tests associated with the first functional requirement, it is determined that the first intermediate version of the candidate software object meets the first functional requirement.

7. The computing device of claim 1, wherein further mutation and testing of the first intermediate version of the candidate software object comprises: In response to the first intermediate version satisfying at least one additional feature requirement, the corresponding portion of the executable binary object code associated with said at least one additional feature requirement is locked.

8. A method for automatically generating target software objects, executed by a data processing system, comprising: Access the initial version of the candidate software object that does not meet multiple functional requirements of the target software object via the processor; A first intermediate version of the candidate software object is generated by mutating the executable binary object code of the initial version of the candidate software object via the processor. The processor is used to test the first intermediate version of the candidate software object to determine whether the first intermediate version of the candidate software object meets at least one of the plurality of functional requirements: Execute the first intermediate version of the candidate software object; An automated test suite is executed, which provides a predetermined set of inputs to the first intermediate version of the candidate software object, and it is determined whether the output of the first intermediate version of the candidate software object corresponds to a predetermined set of outputs. In response to determining that the first intermediate version of the candidate software object satisfies at least one of the plurality of functional requirements, a first segment of the executable binary object code is locked to prevent the first segment from being unintentionally corrupted by further mutations; and The candidate software object continues to be mutated and tested through successive intermediate versions until a version of the candidate software object meets all of the multiple functional requirements, wherein each successive intermediate version of the candidate software object meets at least one functional requirement that was not met by a previous version of the candidate software object.

9. The method of claim 8, wherein in response to the first intermediate version of the candidate software object not satisfying at least one of the plurality of functional requirements, the candidate software object is iteratively mutated and tested in the following manner: Further mutation is performed on the first intermediate version of the candidate software object; and The first intermediate version of the candidate software object with further mutations is tested to determine whether the first intermediate version of the candidate software object with further mutations meets at least one of the plurality of functional requirements.

10. The method of claim 9, wherein mutating the first intermediate version of the candidate software object comprises adding at least one bit to the first intermediate version of the candidate software object.

11. The method of claim 10, wherein adding the at least one bit to the first intermediate version of the candidate software object comprises adding the at least one bit to a code segment of the first intermediate version of the candidate software object.

12. The method of claim 11, wherein continuing to mutate the first intermediate version of the candidate software object further comprises: A second intermediate version of the candidate software object is generated by adding one or more bits to a second portion of the code segment of the first intermediate version of the candidate software object.

13. The method of claim 8, wherein testing the first intermediate version of the candidate software object comprises: One or more tests are performed via the processor to determine whether the first intermediate version of the candidate software object meets the corresponding software requirements of the one or more functional requirements; as well as The processor determines that the corresponding software requirement has been met by responding to the first intermediate version of the candidate software object passing one or more tests.

14. A memory device for storing instructions, which, when executed on a processor of a computing device, cause the computing device to automatically generate a target software object by: Access the initial version of a candidate software object that does not meet multiple functional requirements of the target software object; A first intermediate version of the candidate software object is generated by mutating the executable binary object code of the initial version of the candidate software object. The first intermediate version of the candidate software object is tested using the following steps to determine whether the first intermediate version of the candidate software object meets at least one of the plurality of functional requirements: Execute the first intermediate version of the candidate software object; Execute an automated test set, which provides a predetermined set of inputs for the first intermediate version of the candidate software object, and determine whether the output of the first intermediate version of the candidate software object corresponds to a predetermined set of outputs; In response to determining that the first intermediate version of the candidate software object satisfies at least one of the plurality of functional requirements, a first segment of the executable binary object code is locked to prevent the first segment from being unintentionally corrupted by further mutations; and The candidate software object continues to be mutated and tested through successive intermediate versions until a version of the candidate software object meets all of the multiple functional requirements, wherein each successive intermediate version of the candidate software object meets at least one functional requirement that was not met by a previous version of the candidate software object.

15. The memory device of claim 14, wherein in response to a first intermediate version of the candidate software object not satisfying at least one of the plurality of functional requirements, the first intermediate version of the candidate software object is iteratively mutated and tested in the following manner: Further mutation is performed on the first intermediate version of the candidate software object; and The first intermediate version of the candidate software object with further mutations is tested to determine whether the first intermediate version of the candidate software object with further mutations meets at least one of the plurality of functional requirements.

16. The memory device of claim 15, wherein mutating the first intermediate version of the candidate software object comprises: Add at least one bit to the first intermediate version of the candidate software object.

17. The memory device of claim 16, wherein adding the at least one bit to the first intermediate version of the candidate software object comprises: Add the at least one bit to the code segment of the first intermediate version of the candidate software object.

18. The memory device of claim 17, wherein continuing to mutate the first intermediate version of the candidate software object further comprises: A second intermediate version of the candidate software object is generated by adding one or more bits to a second portion of the code segment of the first intermediate version of the candidate software object.

Images