Method and system for identifying and prioritizing refactoring to improve microservice identification

Abstract

The present disclosure relates to methods and systems for identifying and prioritizing refactorings to improve microservice identification. A computer system, computer program product, and computer-implemented method for identifying one or more refactoring operations for microservice identification of source code. A descendant population of refactoring operations is generated from a parent set using a genetic algorithm. The descendant population is evaluated using one or more target measurements. In response to the evaluation, one or more identified refactoring operations are selectively applied to the source code to generate one or more corresponding microservice candidates.

Description

Technical Field

[0001] The present embodiment relates to application modernization, such as decomposing a monolithic application into microservices and migrating to a cloud environment. More specifically, the embodiment relates to identifying and prioritizing a sequence of refactoring operations identified for microservices. Background Art

[0002] Application modernization is the process of refactoring a monolithic application into independent microservices. Many discussions about application modernization focus on monolithic, on-site applications. One aspect of modernization involves moving monolithic applications from on-site infrastructure to remote shared infrastructure (also known as the "cloud"). Another aspect involves modernizing monolithic applications into a microservices architecture. Typically, microservices are an architectural approach that is often cloud-native, in which a single application consists of multiple loosely coupled and independently deployable smaller components or services (referred to as microservices). Microservices typically (but not necessarily) have their own stack (including databases and data models), communicate with each other through a combination of representational state transfer (REST) ​​application programming interfaces (APIs), and are organized by business capabilities.

[0003] Refactoring is defined as the process of changing software so that the changes do not alter the external behavior of the code, but improve the internal code structure. More specifically, refactoring is aimed at improving the code design after the code has been written. Some of these aspects of improving code design include removing duplication, improving communication, simplifying structure, and increasing flexibility. There are challenges associated with refactoring, especially microservice identification. The quality of the identified microservice candidates depends largely on the design of the existing code, e.g., a monolithic application. Thus, qualitative improvements in refactoring and identification of refactoring operations are needed. Summary of the invention

[0004] Embodiments include computer systems, computer program products, and computer-implemented methods for training a machine learning (ML) model and utilizing the ML model to identify compliance requirements corresponding to one or more microservices.

[0005] In one aspect, a computer system is provided with a processor operably coupled to a memory, a tool operably coupled to the processor, the tool comprising a genetic manager, a score manager, and a classifier. The genetic manager is configured to apply a genetic algorithm to one or more parent refactoring operations selected from an initial set of refactoring operations identified in source code. The applied genetic algorithm produces a population of offspring of refactoring operations that are a subset of the parent refactoring operations. The score manager operably coupled to the genetic manager is configured to measure a fitness score for each refactoring operation in the subset. The fitness score measurement includes collecting runtime traces of the source code and applying the collected runtime traces to the subset. The classifier is configured to prioritize the refactoring operations within the subset based on the corresponding measured fitness scores. In response to the prioritization, the processor selectively applies one or more of the refactoring operations from the subset to the source code to generate one or more microservice candidates.

[0006] In another aspect, a computer program product is provided with a computer-readable storage medium having program code implemented therewith. Program code executable by a processor is provided to apply a genetic algorithm to one or more parent refactoring operations selected from an initial set of identified refactoring operations of the source code. The applied genetic algorithm produces a population of offspring of refactoring operations that are a subset of the parent refactoring operations. The program code measures a fitness score for each refactoring operation in the subset. The fitness score measurement includes collecting runtime traces of the source code and applying the collected runtime traces to the subset. The program code prioritizes the refactoring operations within the subset based on the corresponding measured fitness scores. In response to the prioritization, the program code selectively applies one or more of the refactoring operations from the subset to the source code to generate one or more microservice candidates.

[0007] In yet another aspect, a genetic algorithm is applied to one or more parent refactoring operations selected from an initial set of identified refactoring operations of the source code. The applied genetic algorithm produces a population of offspring of refactoring operations that are a subset of the parent refactoring operations. A fitness score is measured for each refactoring operation in the subset. The fitness score measurement includes collecting a runtime trace of the source code and applying the collected runtime trace to the subset. The refactoring operations within the subset are prioritized based on the corresponding measured fitness scores. In response to the prioritization, one or more of the refactoring operations from the subset are selectively applied to the source code to generate one or more microservice candidates.

[0008] These and other aspects, features and advantages will become apparent from the following detailed description of exemplary embodiments with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The drawings cited herein form part of the specification and are incorporated herein. Unless explicitly indicated otherwise, the features shown in the drawings are intended to illustrate only some embodiments and not all embodiments.

[0010] Figure 1 A system diagram illustrating a computer system that generates one or more corresponding microservice candidates of source code is depicted.

[0011] Figure 2 Depicted is a diagram showing Figure 1 A block diagram of the tools and their associated application program interfaces shown and described in .

[0012] Figure 3 Depicted is a flow diagram illustrating a process for source code modernization that includes analyzing source code to identify a prioritized set of refactoring operations prior to identifying microservices.

[0013] Figure 4 Depicted is a diagram showing a method for implementing the above Figure 1-3 A block diagram of an example of a computer system / server of a cloud-based support system that describes the systems and processes.

[0014] Figure 5 A block diagram illustrating a cloud computer environment is depicted.

[0015] Figure 6 Depicted is a block diagram illustrating a set of functional abstraction model layers provided by a cloud computing environment. DETAILED DESCRIPTION

[0016] It will be readily understood that the components of the present embodiment as generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the computer systems, methods, and computer program products of the present embodiments as presented in the accompanying drawings is not intended to limit the scope of the embodiments as claimed, but merely represents selected embodiments.

[0017] References throughout this specification to "a selected embodiment," "one embodiment," or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Therefore, the phrases "a selected embodiment," "in one embodiment," or "in an embodiment" appearing in various places throughout this specification do not necessarily refer to the same embodiment. Various embodiments may be combined with each other.

[0018] The illustrated embodiments may be best understood by referring to the drawings, wherein like parts are designated by like numerals throughout. The following description is intended to be exemplary only and simply illustrates certain selected embodiments of devices, systems, and processes consistent with the embodiments claimed herein.

[0019] Embodiments described herein relate to identification and prioritization of refactoring operations, and in exemplary embodiments, to prioritization of sequences of refactoring operations. Prioritization is directed to providing high-quality microservices with low operating costs and high functional cohesion, particularly in conjunction with modernization processes such as the conversion of on-site (or off-site) monolithic applications to cloud environments. It should be understood in the art that a monolithic application is a stand-alone application that is independent of other applications. Microservices or microservice architectures generally refer to a computer environment in which an application is constructed as a set of modular components or services based on a functional definition, each component or service corresponds to a functional definition, and each component or service runs in its own process and communicates by means of a lightweight mechanism. In some microservice architectures, data is stored outside the service, and in this way, the service is stateless. These services or components are generally referred to as "atomic services". Each atomic service is a lightweight component for independently executing a modular service. For example, an atomic service can receive and combine keywords, process algorithms, or make decisions based on the results of algorithmic processing. Each module supports a specific task and uses a defined interface (such as an application programming interface (API)) to communicate with other services. Microservice architectures support and implement scalability in hybrid networks.

[0020] See also Figure 1, depicting a schematic diagram of an artificial intelligence platform computing system (100). As shown, a server (110) is provided to communicate with multiple computing devices (180), (182), (184), (186), (188), and (190) across a network connection (105). The server (110) is configured with a processing unit, such as a processor (112), which communicates with a memory (116) across a bus (114). The server (110) is shown as having a knowledge engine (150), which is configured with one or more tools to identify source code refactoring operations and generate one or more corresponding microservice candidates. As shown, the server (110) can apply one or more generated microservice candidates to one or more of the computing devices (180), (182), (184), (186), (188), and (190) via the network (105). More specifically, computing devices (180), (182), (184), (186), (188), and (190) communicate with each other and other devices or components via one or more wired and / or wireless data communication links, where each communication link may include one or more of wires, routers, crossbars, transmitters, receivers, or the like. In this networked arrangement, server (110) and network connection (105) enable source code communication, prioritization of refactoring operations, and microservice generation. Other embodiments of server (110) may be used with components, systems, subsystems, and / or devices other than those depicted herein.

[0021] The knowledge engine (150) is shown herein as being configured with tools for identifying refactoring operations for source code. The tools include, but are not limited to, a source code manager (152), a genetic manager (154), a score manager (156), and a classifier (158). Although the source code manager (152), the genetic manager (154), the score manager (156), and the classifier (158) are Figure 1 are shown as being embedded in the knowledge engine (150), but in other embodiments, tools (152), (154), (156), and (158) may be separate from or external to the knowledge engine (150).

[0022] The knowledge engine (150) may receive input from the network (105) and / or utilize a data source (160) (also referred to herein as a corpus or knowledge base) to identify potential refactoring operations. Refactoring is the process of changing a software system in a way that does not change the external code behavior but improves its internal structure. In an exemplary embodiment, refactoring involves modifying source code or improving source code structure to make it more efficient, scalable, maintainable, or reusable without changing any functionality of the program. Refactoring as shown and described herein involves application modernization and moving traditional applications from a monolithic structure to microservices. As shown, the data source (160) is configured with one or more libraries, which are shown herein by way of example as library A (162 A ) and library B(162 B ). The number of libraries shown here is for exemplary purposes and should not be considered limiting. Each library is shown as having multiple reconstruction operations. As shown, library A (162 A ) is shown as having a reconstruction operation (164 A，0 )、(164 A，1 )...(164 A，N ), and library B (162 B ) is shown as having a reconstruction operation (164 B，0 )、(164 B，1 )...(164 B，N ). The number of reconstruction operations in each library is for exemplary purposes and should not be considered limiting. The reconstruction operations can be logically grouped into libraries for use as part of the corpus (160) of data by the knowledge engine (150). Thus, the data source (160) serves as a resource of libraries and corresponding reconstruction operations available to the knowledge engine (150) and corresponding tools.

[0023] The refactoring operation is utilized to generate one or more corresponding microservices or microservice candidates of the source code. Different computing devices (180), (182), (184), (186), (188) and (190) communicating with the server (110) across the network (105) may include access points to the knowledge engine (150). Some of the computing devices may include devices for storing the identified (one or more) refactoring operations generated by the support of the knowledge engine (150) to generate a response output (104), and transmitting the response output (104) to a corresponding network device architecture operably coupled to the server (110) or one or more of the computing devices (180), (182), (184), (186), (188) and (190) across the computer network (105).

[0024] In various embodiments, the network (105) may include local network connections and remote connections, so that the knowledge engine (150) can operate in environments of any size, including local and global, such as the Internet. In addition, the knowledge engine (150) acts as a front-end system that can make available various knowledge extracted from one or more data sources represented in network-accessible sources and / or structured data sources. In this way, some processes populate the knowledge engine (150), wherein the knowledge engine (150) also includes an input interface for receiving requests and responding accordingly.

[0025] Source code (170) is selected or identified for modernization. In the exemplary embodiment, the identified source code (170) is transmitted from one of computing devices (180), (182), (184), (186), (188), and (190) to the server (110) via the network (105). The source code manager (152) performs an initial processing of the source code (170) to identify an initial set of refactoring operations (170). A ), which is also referred to herein as a parent reconstruction operation. In an embodiment, the initial set (170 A ) is a randomly selected subset from the pool of refactoring operations. The genetic manager (154) interfaces with the source code manager (152) and uses the genetic algorithm (154) A ) is applied to the initial set of refactoring operations (170) from the source code (170) A ) is selected from one or more parent reconstruction operations. Genetic Algorithm (154 A ) is generated as the parent reconstruction operation (170 A ) of the subset of the reconstruction operation of the descendant population (170 B In one exemplary embodiment, the genetic algorithm (154 A ) reflects the process of natural selection to produce offspring that inherits at least one or more characteristics of the parent generation to be added to the next generation. The genetic manager (154) applies a crossover operation to generate a combination of offspring reconstruction operations, and further applies a mutation operator to introduce variability to the generated combinations. The crossover operation is applied to each pair of parent reconstruction operations. Offspring reconstruction operations are created by exchange until a crossover point is reached, at which time new offspring reconstruction operations are added to the population of reconstruction operations. In the selected set of new offspring reconstruction operations, some of their components may be subjected to mutation. Mutations occur to maintain diversity and introduce variability within the population and prevent premature convergence. Therefore, the genetic manager (154) is used to interface with the set of reconstruction operations to identify and generate an offspring population of reconstruction operations.

[0026] The score manager (156) (which is shown herein as being operatively coupled to the genetic manager (154)) is used to measure the subset (e.g., (170B )) is the fitness score of each refactoring operation in the microservice candidate. The fitness score is the target measurement value of the corresponding microservice candidate. The details of the fitness score are in Figure 3 As shown and described in . With respect to the natural selection process, a fitness score measurement is assigned to each reconstruction operation in the subset. The probability that a reconstruction operation will be selected is based on the corresponding fitness score. Figure 3 As shown and described in , in parallel with the initial identification of the refactoring operations, the source code manager (152) collects a runtime trace of the source code (170). In the exemplary embodiment, the runtime trace identifies dependency information associated with the execution of the source code. The score manager (156) collects the runtime trace and applies the runtime trace to the identified subset, such as (170). B ). Thus, the fitness score measurement combines the functionality of the source code manager (152) regarding runtime tracing and the functionality of the score manager (156) regarding fitness score evaluation.

[0027] The refactoring operation is associated with the corresponding microservice candidate. The score manager (156) is based on the subset (e.g., (170 B )) to modify the collected runtime traces, and then apply the clustering algorithm to the modified runtime traces to identify microservice candidates. As such, the fitness score evaluation is used as a measurement value for the corresponding microservice candidate. In an embodiment, the microservice candidate measurement value corresponds to a quality, which can be a combination of target measurements. The score manager (156) selects the microservice candidate from the subset (e.g., (170 B )) selects one or more reconstruction operations. In an exemplary embodiment, the selection includes operations in a subset having a minimum Euclidean distance to the maximum combination of target measurements. Genetic Algorithm (154 A ) application and fitness score measurement is an iterative process, such as Figure 3 As shown and described in , one or more reconstruction operations and a population of offspring are selected by the score manager (156) as the next parent or set of parent reconstruction operations and subjected to genetic operations.

[0028] The iterative process of prioritizing the reconstruction operations has a stopping point. For example, the stopping point may correspond to an amount of iterations, or in an embodiment, to a quality measure of the fitness score measure. When the stopping point or criterion has been reached, the identified reconstruction operations in the subset (e.g., (170 B)) are subjected to a prioritization protocol by a classifier (158), wherein the prioritization is based on a corresponding fitness score measurement associated with each individual refactoring operation in the subset. In an exemplary embodiment, the prioritization of the refactoring operations enables developers to focus on the most important refactoring operations, given time and resource constraints. In one embodiment, the prioritization performed by the classifier (158) is a multi-objective optimization problem using a non-dominated sorting genetic algorithm (NSGA-II). The output from the classifier (158) is a set of prioritized refactoring operations. Refactoring opportunities are recommended to improve source code quality before identifying microservices. The processor (112) selectively applies the identified and prioritized refactoring operations to the source code, which produces refactoring operations corresponding to the microservice candidates (170 C ). Therefore, the tool and its corresponding functions as described herein prioritize refactoring operations to produce a functionally efficient and enhanced microservice decomposition, and the corresponding microservices have low operating costs and high functional cohesion.

[0029] Source code modernization requests received via network (105) may be processed by server (110) (e.g., IBM As shown herein, the knowledge engine (150) generates a prioritized set of refactoring operations together with embedded tools (152), (154), (156), and (158), and applies the generated set to source code to produce microservice candidates for a microservice-based architecture.

[0030] In some demonstrative embodiments, the server (110) may be an IBM ® 4000 ® available from International Business Machines Corporation in Armonk, New York. A system that is augmented with the mechanisms of the illustrative embodiments described herein. IBM The system may receive or detect a source code modernization request as input (102) and then The system analyzes the source code modernization request to identify a set of prioritized refactoring operations before identifying the microservices.

[0031] Managers (152), (154), (156) and (158) (hereinafter collectively referred to as knowledge engine tools) are shown as being implemented in or integrated within the knowledge engine (150) of the server (110). The tools may be implemented in a separate computing system (e.g., 190), or in one embodiment in one or more systems, and they may be implemented in two or more systems across a network (105) to the server (110). Regardless of the implementation, the tools (152), (154), (156) and (158) are used to utilize runtime traces and genetic algorithms to prioritize refactoring operations to be applied to corresponding source code to generate microservice candidates and effectively and efficiently modernize the source code.

[0032] The types of devices and corresponding systems that can utilize the knowledge engine (150) range from small handheld devices (such as handheld computers / mobile phones (180)) to large mainframe systems (such as mainframe computers (182)). Examples of handheld computers (180) include personal digital assistants (PDAs), personal entertainment devices such as MP4 players, portable televisions, and compact disc players. Other examples of information processing systems include pen or tablet computers (184), laptop or notebook computers (186), personal computer systems (188), and servers (190). As shown, different devices and systems can be networked together using a computer network (105). Types of computer networks (105) that can be used to interconnect different devices and systems include local area networks (LANs), wireless local area networks (WLANs), the Internet, public cross-telephone networks (PSTNs), other wireless networks, and any other network topologies that can be used to interconnect devices and systems. Many devices and systems include non-volatile data storage, such as hard drives and / or non-volatile memory. Some devices and systems may use separate non-volatile data storage (e.g., server (190) utilizes non-volatile data storage (190a), and mainframe computer (182) utilizes non-volatile data storage (182a)). Non-volatile data storage (182a) may be a component external to the different devices and systems, or may be a component internal to one of the devices and systems.

[0033] Devices and systems for supporting the knowledge engine (150) may take many forms, some of which are Figure 1 For example, an information handling system may take the form of a desktop, server, portable, laptop, notebook, or other form factor computer or data processing system. In addition, the device(s) and system(s) may take other form factors such as a personal digital assistant (PDA), a gaming device, an ATM machine, a portable telephone device, a communication device, or other device that includes a processor and memory.

[0034] An application programming interface (API) is understood in the art as middleware between two or more applications. Figure 1 The knowledge engine (150) shown and described in the foregoing may utilize one or more APIs to support one or more of the tools (152), (154), (156), and (158) and their associated functionality. Figure 2 , a block diagram (200) is provided, which shows tools (152), (154), (156) and (158) and their associated APIs. As shown, multiple tools are embedded in the knowledge engine (205), where these tools include Figure 2 252) is shown as a source code manager (152) associated with API0 (262), Figure 2 The genetic manager (154) shown as (254) associated with API1 (264), Figure 2 The score manager (156) shown in FIG. 1 is associated with (256) API2 (266), and Figure 2 , a classifier (158) is shown as (258) associated with API3 (268). Each API can be implemented in one or more languages ​​and interface specifications. API0 (252) provides functional support for initial processing of source code to identify a set of initial refactoring operations (also referred to herein as parent refactoring operations) and provide a runtime trace of the source code; API1 (254) provides functional support for applying a genetic algorithm to the parent refactoring operations, wherein the genetic algorithm produces a descendant population of refactoring operations; API2 (256) provides functional support for evaluating the fitness score of each refactoring operation in the descendant population; and API3 (258) provides functional support for prioritizing refactoring operations within the descendant population, wherein the prioritization corresponds to or involves the fitness score evaluation. As shown, each of APIs (252), (254), (256) and (258) is operably coupled to an API coordinator (260), which is also referred to as a coordination layer, which is understood in the art to be used as an abstraction layer to transparently interweave separate APIs. In an embodiment, the functionality of the separate APIs can be combined or combined. As such, the configuration of the APIs shown herein should not be considered limiting. Thus, as shown here, the functionality of the tools may be embodied or supported by their respective APIs.

[0035] See also Figure 3, a flowchart (300) is provided showing a process for source code modernization, the process including analyzing source code to identify a set of prioritized refactoring operations before identifying microservices. As shown, source code is received or otherwise identified (302). Thereafter, two aspects of the received or identified source code are implemented in parallel, including the application of a genetic algorithm and the collection of runtime traces. The runtime traces of the source code are collected to identify dependency information associated with the source code execution (304). For example, in an embodiment of a class-based object-oriented programming language, the collection of runtime traces employs calls to collect which classes call another class from the source code execution call during runtime execution, where the class is used to define objects and methods. Based on this embodiment, the identification at step (304) identifies dependency information of the class and its corresponding objects and methods. In parallel with the collection at step (304), identifying static dependencies of the source code begins with identifying refactoring operations of the source code (306). In an embodiment, the identification at step (306) utilizes code smell detection rules. Code smells are known in the art as violations of coding design principles. Smells do not necessarily lead to failures, but may lead to other negative consequences that affect the source code. Based on the identification in step (306), a subset of reconstruction operations is randomly selected from the reconstruction operation pool (308). More specifically, given the identified operation set O = {o1, o2, ..., o n}, randomly selecting a subset of operations for K iterations to generate an initial population of size K. Then, applying a genetic algorithm to one or more parent refactoring operations selected from the initial set of refactoring operations of the source code to generate a descendant population of refactoring operations (310).

[0036] Aspects of applying a genetic algorithm to a parent population in step (310) include applying crossover and mutation to create different combinations of reconstruction operations. In an exemplary embodiment, the genetic algorithm reflects the process of natural selection to produce offspring that inherit one or more characteristics of the parent to be added to the next generation. Reconstruction operations are shown herein as method level and class level, and method level techniques are directed to code changes at the method level. A method is a set of statements grouped together to perform an operation. Examples of method level techniques include, but are not limited to, extracting methods, inlining mobile method calls, or turning long methods into classes. In an embodiment, there may be additional or alternative method level techniques, and therefore these examples should not be considered restrictive. The reconstruction techniques in this group (i.e., method level techniques) reorganize these methods between these classes, such as moving methods from one class to another. Class level techniques involve changing the behavior of how classes interact with each other, where classes are user-defined blueprints or prototypes from which objects are created. Examples of class level techniques include, but are not limited to, splitting a class into two or more classes, or removing classes. In an embodiment, there may be additional or alternative class level techniques, and therefore these examples should not be considered restrictive. As shown here by way of example, parent crossover is used to generate offspring. Parents of two solutions are randomly selected from an initial population. In an exemplary embodiment, for each parent, the offspring inherits one or more reconstruction operations. The following is an example of parent crossover:

[0037] Example 1, parent crossover:

[0038] Parent 1: move fields(class A, class B, field a) and move methods(class B, class C, method a)

[0039] This is interpreted as moving function a from class A to class B and moving method a from class B to class C.

[0040] Example 2, parent crossover:

[0041] Parent 2: Move fields(class C, class D, field b) and pull fields up(class E, class F, field c)

[0042] This is interpreted as moving function b from class C to class D, and if class E is a subclass from class F, moving function c from class E to class F.

[0043] In addition, you can also take advantage of offspring crossover from the offspring generated by the parents. The following is an example of offspring crossover.

[0044] Example 3, offspring crossover:

[0045] Child 1: Move fields (class A, class B, field a) and pull fields up (class E, class F, field c)

[0046] Example 4, child fork:

[0047] Child 2: Move fields (class C, class D, field b) and move methods (class B, class C, method a)

[0048] Using mutation probability, offspring (e.g., offspring 1 or offspring 2) are randomly selected after crossover to introduce variability in the solution. After the random selection of offspring, one or more reconstruction operations are randomly selected to be replaced by another reconstruction operation. The following is an example of mutation:

[0049] Child 1 before mutation: Move fields (class A, class B, field a) and pull fields up (class E, class F, field c)

[0050] Child 2 after mutation: inline classes (class G, class H) and pull-up fields (class E, class F, field c)

[0051] As shown in this mutation example, a different refactoring operation "Inline Class" is introduced.

[0052] A population of offspring of reconstruction operations is generated by a genetic algorithm, where the offspring population is a subset of the parent reconstruction operation (312). As shown, information is extracted from the collected runtime traces to calculate a fitness score measurement, such as. The number of runtime calls between two classes. Then, for each reconstruction operation in the subset of reconstruction operations, a fitness score measurement is performed on the offspring population (e.g., subset) (314). The fitness score measurement is a vector of objective functions f1–f6 as defined below. Each candidate offspring reconstruction operation provides a list of candidate microservices. The fitness score is a measure of the quality of each reconstruction operation in the subset. The probability of selecting a reconstruction operation is based on the corresponding fitness score. The fitness score evaluation at step (314) includes several sub-processes, including modifying the original runtime trace according to the reconstruction operation (316), and applying clustering to the modified runtime trace to identify microservice candidates (318). For example, clustering is applied based on a similarity measurement value, which is calculated based on the number of runtime calls between two classes. More specifically, two classes with a high number of runtime calls have high similarity. The clustering method provides a grouping of classes, where each group (e.g., cluster) identifies a microservice candidate. After step (318), the quality of the microservice candidates from the cluster is measured (320). The quality of the microservice candidates is subjected to measurement based on fitness functions f1-f6, as described below, to evaluate the quality of the formed cluster. In an exemplary embodiment, the fitness score measurement utilizes a function of a vector as an objective function of the microservice quality. The following is an example of an objective function (e.g., a target measurement value) as an evaluation model of microservice quality and fitness function to search for a near-optimal solution:

[0053] f1: Intra-structural connectivity within two clusters, e.g., C0 and C1, where:

[0054]

[0055] Where k is the number of partitions; N i is the number of classes in partition i; and u i is the total number of method calls within partition i.

[0056] f2: Structural interconnectivity between two clusters, e.g., C0 and C1, where:

[0057]

[0058] Where k is the number of partitions; N i is the number of classes in partition i; and σ j is the total number of method calls between partition i and partition j.

[0059] f3: intra-data dependencies within each cluster, where:

[0060]

[0061] Where k is the number of partitions; N i is the number of classes in partition i; and w i is the number of data dependencies within partition i.

[0062] f4: Data interconnection between different clusters, including:

[0063]

[0064] Where k is the number of partitions; N i is the number of categories in partition i; n i，j is the number of data dependencies between partition i and partition j.

[0065] f5: The intersection of transaction elements, where:

[0066] where s i，j =|bc i ∪bc j |-|bc i ∩bc j |

[0067] Where k is the number of partitions; N i is the number of categories in partition i; and bc i is the set of business usage of partition i.

[0068] f6: Percentage of interfaces per cluster, where interface is the number of functions belonging to another cluster, where:

[0069]

[0070] Where k is the number of partitions; N i is the number of categories in partition i; I i is the number of interfaces of partition i, where an interface is a method that a class can call and belongs to other partitions.

[0071] The measurement of the quality of the microservice candidates from the cluster at step (320) defines the fitness function as a vector of fitness functions F, where F = (f1; f2; f3; f4; f5; f6). In an exemplary embodiment, the near-optimal solution is referred to herein as an inflection point, which is further defined as the minimum Euclidean distance to the combination of the target measurement value and the ideal fitness score, and where the ideal fitness score F ideal is defined as follows:

[0072] F ideal =(max(f1); min(f2); max(f3); min(f4); min(f5); max(f6))

[0073] The remaining or remaining set of offspring reconstruction operations are subjected to a sorting process (322) based on their corresponding dominance levels. In an exemplary embodiment, the dominance level corresponds to a fitness score evaluation. The child reconstruction operation that is closest to the ideal fitness score is selected as the next parent reconstruction operation (324). The fitness score evaluation shown and described in steps (314)-(320) and the subsequent sorting and selection in steps (322)-(324) are an iterative process in which one or more reconstruction operations are selected as the next parent or a group of parent reconstruction operations and offspring populations to be subjected to genetic operations. The iterative process of prioritizing reconstruction operations has a stopping point. For example, the stopping point may correspond to the amount of iterations, or in an embodiment, to the ideal fitness score F. ideal As shown here, after step (324), an evaluation is performed to determine whether the stopping point criteria have been reached (326). A negative response to the evaluation is followed by a return to step (310), and a positive response to the evaluation is followed by applying the identified and prioritized refactoring operations from the subset to the source code (328). One or more microservice candidates generated in step (328) are output from the application (330).

[0074] The prioritization shown and described herein is a multi-objective optimization problem that uses a non-dominated sorting genetic algorithm, e.g., NSGA-II, in an exemplary embodiment. This prioritization of refactoring operations enables developers to prioritize in response to time and resource constraints. Thus, the prioritization shown and described herein identifies and prioritizes a sequence of refactoring operations to improve downstream microservice identification, resulting in high-quality microservices with low operating costs and high functional aggregation.

[0075] The embodiments shown and described herein may be in the form of a computer system for use with a knowledge engine (150) to identify and prioritize sequences of refactoring operations to improve downstream microservice identification for selecting source code. Various aspects of the tool and manager (e.g., (152), (154), (156), (158)) and their associated functionality may be implemented in a computer system / server in a single location or, in one embodiment, may be configured in a cloud-based system that shares computing resources. See Figure 4 , a block diagram (400) is provided, showing the method for implementing the above Figure 3 An example of a computer system / server (402) (hereinafter referred to as a host (402) in communication with a cloud-based support system) for the described process. The host (402) can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that can be suitable for the host (402) include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and file systems including any of the above systems (e.g., distributed storage environments and distributed cloud computing environments), devices, and their equivalents.

[0076] The host (402) may be described in the general context of computer system executable instructions, such as program modules, that are executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. The host (402) may be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices that are linked through a communication network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0077] like Figure 4As shown, the host (402) is shown in the form of a general-purpose computing device. The components of the host (402) may include, but are not limited to, one or more processors or processing units (404), such as a hardware processor, a system memory (406), and a bus (408) that couples different system components including the system memory (406) to the processor (404). The bus (408) represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of various bus architectures. As an example and not limitation, such architectures include an industry standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus. The host (402) typically includes various computer system readable media. Such media can be any available media accessible to the host (402), and it includes both volatile and non-volatile media, removable and non-removable media.

[0078] The memory (406) may include computer system readable media in the form of volatile memory, such as random access memory (RAM) (430) and / or cache memory (432). By way of example only, a storage system (434) may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, and commonly referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media) may be provided. In such instances, each may be connected to the bus (408) via one or more data media interfaces.

[0079] A program / utility (440) having a set (at least one) of program modules (442), as well as an operating system, one or more application programs, other program modules, and program data, may be stored in memory (406) by way of example and not limitation. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an embodiment of a networked environment. The program modules (442) generally perform the functions and / or methods of the embodiments to identify one or more refactoring operations of source code that, when applied to the source code, produce one or more microservice candidates. For example, the set of program modules (442) may include, for example, Figure 1 Tools (152), (154), (156) and (158) described in.

[0080] The host (402) may also communicate with one or more external devices (414) such as a keyboard, a pointing device, etc.; a display (424); one or more devices that enable a user to interact with the host (402); and / or any device that enables the host (402) to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via an input / output (I / O) interface (422). In addition, the host (402) may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter (420). As depicted, the network adapter (420) communicates with other components of the host (402) via a bus (408). In an embodiment, multiple nodes of a distributed file system (not shown) communicate with the host (402) via an I / O interface (422) or via a network adapter (420). It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the host (402). Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems.

[0081] In this document, the terms "computer program medium," "computer usable medium," and "computer-readable medium" are used to broadly refer to media such as main memory (406) (including RAM (430)), cache (432), and storage systems (434) (such as removable storage drives and hard disks installed in hard drives).

[0082] A computer program (also referred to as computer control logic) is stored in the memory (406). The computer program may also be received via a communication interface, such as a network adapter (420). Such a computer program, when executed, enables the computer system to perform the features of the present embodiment as discussed herein. Specifically, the computer program, when executed, enables the processing unit (404) to perform the features of the computer system. Thus, such a computer program represents a controller of the computer system.

[0083] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a dynamic or static random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a magnetic storage device, a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device (such as a punch card) or a raised structure in a groove with instructions recorded thereon), and any suitable combination of the above. As used herein, a computer-readable storage medium should not be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by a fiber optic cable), or an electrical signal transmitted by a wire.

[0084] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, crossover machines, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0085] The computer-readable program instructions for performing the operation of the present embodiment can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" programming language or similar programming languages. The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on the remote computer, or executed completely on the remote computer or server or server cluster. In the latter case, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, electronic circuits (including for example programmable logic circuits, field programmable gate arrays (FPGA) or programmable logic arrays (PLA)) can be executed by utilizing the state information of computer-readable program instructions to personalize the electronic circuit, so as to perform the various aspects of the embodiment.

[0086] In an embodiment, the host (402) is a node of a cloud computing environment. As is known in the art, cloud computing is a model for enabling convenient service delivery, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly configured and released with minimal management effort or interaction with service providers. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models. Examples of such characteristics are as follows:

[0087] On-demand self-service: Cloud consumers can unilaterally provision computing capabilities, such as server time and network storage, automatically on demand without requiring human interaction with the provider of the service.

[0088] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0089] Resource pooling: The computing resources of a provider are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence, as consumers generally have no control or knowledge of the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0090] Rapid elasticity: Capacity can be quickly and elastically provided (in some cases, automatically) to quickly scale down and quickly released to quickly scale up. To the consumer, the capacity available for provisioning generally appears unlimited and can be purchased in any quantity at any time.

[0091] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some abstraction level appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the utilized services.

[0092] The business model is as follows:

[0093] Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on the cloud infrastructure. The applications are accessible from different client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0094] Platform as a Service (PaaS): The capability provided to consumers is to deploy consumer-created or acquired applications on the cloud infrastructure, which are created using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but have control over the deployed applications and possibly the configuration of the application hosting environment.

[0095] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0096] The deployment model is as follows:

[0097] Private Cloud: Cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0098] Community Cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0099] Public cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by an organization that sells cloud services.

[0100] Hybrid cloud: Cloud infrastructure is the composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0101] Cloud computing environments are service-oriented, focusing on state, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that consists of a network of interconnected nodes.

[0102] See now Figure 5 , illustrative cloud computing network (500). As shown, the cloud computing network (500) includes a cloud computing environment (550) having one or more cloud computing nodes (510), with which local computing devices used by cloud consumers can communicate. Examples of these local computing devices include, but are not limited to, personal digital assistants (PDAs) or cellular phones (554A), desktop computers (554B), laptop computers (554C), and / or automotive computer systems (554N). Individual nodes within a node (510) may further communicate with each other. They may be physically or virtually grouped (not shown) in one or more networks, such as the private clouds, community clouds, public clouds, or hybrid clouds described above, or a combination thereof. This allows the cloud computing environment (500) to provide infrastructure, platforms, and / or software as services without the cloud consumer having to maintain resources on local computing devices. It should be understood that Figure 5 The types of computing devices (554A-N) shown in are intended to be illustrative only, and the cloud computing environment (550) may communicate with any type of computerized device over any type of network and / or network addressable connection (eg, using a web browser).

[0103] See now Figure 6 , showing that Figure 5 A set of functional abstraction layers (600) provided by the cloud computing network. It should be understood in advance that Figure 6 The components, layers, and functions shown in are intended to be illustrative only, and embodiments are not limited thereto. As depicted, the following layers and corresponding functions are provided: hardware and software layer (610), virtualization layer (620), management layer (630), and workload layer (640).

[0104] The hardware and software layer (610) includes hardware and software components. Examples of hardware components include mainframes, in one example, System; a server based on RISC (Reduced Instruction Set Computer) architecture, in one example IBM System; IBM System; IBM systems; storage devices; network and networking components. Examples of software components include network application server software, in one example, IBM application server software; and database software, in one example, IBM Database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.)

[0105] The virtualization layer (620) provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients.

[0106] In one example, the management layer (630) may provide the following functionality: resource provisioning, metering and pricing, a user portal, service tier management, and SLA planning and fulfillment. Resource provisioning provides dynamic acquisition of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing provide cost tracking when resources are utilized within a cloud computing environment, and billing or invoicing for consumption of these resources. In an example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection of data and other resources. The user portal provides access to the cloud computing environment for consumers and system administrators. Service tier management provides cloud computing resource allocation and management so that the required service tier is met. Service tier agreement (SLA) planning and fulfillment provides pre-scheduling and procurement of cloud computing resources in anticipation of future requirements according to the SLA.

[0107] The workload layer (640) provides examples of functions that can utilize the cloud computing environment. Examples of workloads and functions that can be provided from this layer include, but are not limited to: mapping and navigation; software development and lifecycle management; virtual classroom education delivery; data analysis processing; transaction processing; and refactoring operation identification and prioritization.

[0108] Although specific embodiments of the present embodiment have been shown and described, it is obvious to those skilled in the art that, based on the teachings herein, changes and modifications can be made without departing from the embodiments and their broader aspects. Therefore, the appended claims will cover all such changes and modifications as in the true spirit and scope of the embodiments within their scope. In addition, it should be understood that these embodiments are limited only by the appended claims. It will be understood by those skilled in the art that if a specific number of introduced claim elements is intended, such intention will be explicitly stated in the claims, and in the absence of such a statement, there is no such limitation. For non-limiting examples, in order to help understand, the following appended claims contain the use of introductory phrases "at least one" and "one or more" to introduce claim elements. However, the use of such phrases should not be interpreted as implying that the claim elements introduced by the indefinite article "one" or "a kind" will limit any specific claim containing such introduced claim elements to an embodiment containing only one such element, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "one" or "a kind"; this also applies to the use of definite articles in the claims.

[0109] The present embodiment may be a system, method, and / or computer program product. In addition, selected aspects of the present embodiment may take the form of a fully hardware embodiment, a fully software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and / or hardware aspects, which embodiments may all be collectively referred to herein as a "circuit," "module," or "system." In addition, various aspects of the present embodiment may take the form of a computer program product embodied in a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to perform various aspects of the present embodiment. As so embodied, the disclosed systems, methods, and / or computer program products operate to improve the functionality and operation of an artificial intelligence platform to train ML models and utilize the trained models to classify microservices with respect to compliance requirements.

[0110] Various aspects of the present embodiment are described herein with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to the embodiments. It should be understood that each box in the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0111] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine that, when executed by a processor of the computer or other programmable data processing apparatus, creates a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein includes an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0112] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other apparatus that causes a series of operating steps to be performed on a computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0113] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to the different embodiments of the present embodiment.To this end, each box in the flow chart or block diagram can represent a part of a module, segment or instruction, which includes one or more executable instructions for realizing the logical function of the specification.In some alternative implementations, the function marked in the box may not occur in the order marked in the figure.For example, depending on the function involved, the two boxes shown in succession can actually be performed substantially at the same time, or these boxes can sometimes be performed in the opposite order.It will also be noted that each box in the block diagram and / or flow chart and the combination of the boxes in the block diagram and / or flow chart can be realized by a system based on special-purpose hardware, and the system based on special-purpose hardware performs a specified function or action or performs a combination of special-purpose hardware and computer instructions.

[0114] It will be understood that although specific embodiments are described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the embodiments. Therefore, the scope of protection of the embodiments is limited only by the appended claims and their equivalents.

Claims

1. A computer system comprising: a processor operatively coupled to the memory; One or more tools operably coupled to the processor, the one or more tools comprising: a genetic manager for applying a genetic algorithm to one or more parent refactoring operations selected from an initial set of identified refactoring operations of the source code, the applied genetic algorithm for generating a population of offspring of the refactoring operations as a subset of the one or more parent refactoring operations; a score manager operatively coupled to the genetic manager, the score manager for measuring a fitness score of each refactoring operation in the subset, including collecting runtime traces of the source code and applying the collected runtime traces to the subset; and a classifier for prioritizing reconstruction operations within the subset based on corresponding measured fitness scores; and In response to the refactoring operation prioritization, the processor selectively applies one or more of the refactoring operations from the subset to the source code and generates one or more microservice candidates.

2. The computer system of claim 1 , wherein the measuring of the fitness score for each refactoring operation in the subset comprises the score manager modifying the collected runtime traces according to the refactoring operation and applying a clustering algorithm to the modified runtime traces, the applied clustering algorithm identifying microservice candidates. 3 . The computer system of claim 2 , wherein the measuring of the fitness score of each refactoring operation in the subset further comprises the score manager measuring a quality of the identified microservice candidates.

4. The computer system according to claim 3, further comprising: The score manager selects one or more reconstruction operations in the subset that have a minimum Euclidean distance to the largest combination of target measurements.

5. The computer system of claim 1, further comprising the genetic manager applying a crossover operator to generate combinations of offspring reconstruction operations, and applying a mutation operator to introduce variability into the generated combinations.

6. The computer system of claim 1 , wherein the application of the genetic algorithm and the measurement of the fitness score are an iterative process, and further comprising the score manager selecting a reconstruction operation from the subset as a next parent reconstruction operation for a target factor, and iteratively applying the selected reconstruction operation to the iterative process.

7. A method for processing a reconstruction operation, comprising: identifying an initial set of refactoring operations for the source code; applying a genetic algorithm to one or more parent refactoring operations selected from an initial set of identified refactoring operations of the source code, the applied genetic algorithm producing a population of offspring of the refactoring operations as a subset of the one or more parent refactoring operations; measuring a fitness score of each refactoring operation in the subset, including collecting runtime traces of the source code and applying the collected runtime traces to the subset; prioritizing the reconstruction operations within the subset based on corresponding measured fitness scores; and In response to the refactoring operation prioritization, one or more of the refactoring operations from the subset are selectively applied to the source code, and one or more microservice candidates are generated.

8. The method of claim 7, wherein measuring the fitness score of each refactoring operation in the subset comprises modifying the collected runtime traces according to the refactoring operation, and applying a clustering algorithm to the modified runtime traces, the applied clustering algorithm identifying microservice candidates. 9 . The method of claim 8 , wherein measuring the fitness score of each refactoring operation in the subset further comprises measuring a quality of the identified microservice candidates.

10. The method of claim 9, further comprising selecting one or more reconstruction operations in the subset having a maximum combination of target measurements with a minimum Euclidean distance.

11. The method of claim 7, wherein applying a genetic algorithm to the identified reconstruction operations comprises applying a crossover operator to generate combinations of offspring reconstruction operations, and applying a mutation operator to introduce variability into the generated combinations.

12. The method of claim 7, wherein applying the genetic algorithm and measuring the fitness score is an iterative process, and further comprising selecting a reconstruction operation from the subset as a next parent reconstruction operation for the target factor, and iteratively applying the selected reconstruction operation to the iterative process.

13. A computer program product comprising a computer-readable storage medium having program code embodied therewith, the program code being executable by a processor to implement the steps of any one of claims 7 to 12.

Images