Source code migration, maintenance, refactoring with abductive reasoning

Abstract

A computer implemented method is described comprising accessing source code from a legacy code base and computing a graph representing the source code with the graph comprising a plurality of nodes connected by edges, each node representing a software component of the source code and each edge representing a relationship between software components. A functional marker is accessed comprising a plurality of interconnected nodes with each node representing a software component and having a known functional role. An occurrence of the functional marker in the graph representing the source code is identified. A functional role is assigned to nodes in the graph which are part of the occurrence by using the known functional roles of the functional marker. The functional role is assigned to the source code from the legacy code base corresponding to the nodes with the assigned functional roles and triggers any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. Abductive role reasoning is used to improve accuracy of functional role assignments. 1 to be published with the abstract

Description

SOURCE CODE MIGRATION, MAINTENANCE, REFACTORING WITH ABDUCTIVE REASONING

[0001] The present disclosure relates to source code migration or maintenance or refactoring suitable for telecommunications network services.BACKGROUND

[0002] Outdated software systems that are still in use comprise legacy source code. These software systems typically become outdated due to a change in external libraries, the execution environment or because there is a need for improvement in the core attributes of the source code such as speed or stability.

[0003] The changing needs of users of software as well as the advance of technology create a need for legacy source code to undergo migration, maintenance and refactoring. Source code migration is a process whereby source code currently deployed in one computing environment is to be moved to another computing environment. The migration process may comprise translating the source code between computing languages. Source code maintenance is a process whereby source code is patched or updated, for example, where legacy software interoperates with an external tool which itself is upgraded and so the legacy source code has to be changed in order to maintain the interoperation with the upgraded external tool. Source code refactoring is where functionality of part of legacy source code is changed, such as to provide additional capabilities or different capabilities.

[0004] Source code migration, maintenance and refactoring typically require an in-depth understanding of design, structure and architecture of the software system, which is typically obtained through the source code of the legacy software system as well as documentation and historical data. A major difficulty in obtaining the understanding required to implement the changes mentioned above, is that when it comes to legacy systems, the source code is typically comprised of hundreds of thousands of lines of code, the language of which can be low-level, defunct and without support or documentation, making it even harder for a human to understand. In the case of telecommunications network services, where functionality is to be available around the clock, these problems are particularly acute.

[0005] The examples described herein are not limited to examples which solve problems mentioned in this background section.SUMMARY

[0006] Examples of preferred aspects and embodiments of the invention are as set out in the accompanying independent and dependent claims.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intendedto identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0008] In an aspect of the technology there is a computer implemented method comprising: accessing source code from a legacy code base; computing a graph representing the source code, the graph comprising a plurality of nodes connected by edges, each node representing a software component of the source code and each edge representing a relationship between software components; accessing a functional marker comprising a plurality of interconnected nodes, each node representing a software component and having a known functional role; identifying an occurrence of the functional marker in the graph representing the source code; assigning a functional role to nodes in the graph which are part of the occurrence by using the known functional roles of the functional marker; determining a confidence of the assigned functional role for each node that is part of the occurrence; determining, using abductive reasoning, a most likely assigned functional role for each node that is part of the occurrence; and for the source code from the legacy code base corresponding to the nodes with the most likely assigned functional roles, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. By using abductive reasoning accuracy of functional role assignment is improved. Identifying the occurrence of a functional marker helps a software engineer or automated process quickly find parts of the source code that perform particular functions. The identification of the functional roles within the source code from the legacy code base has previously been a manual process to be completed by a person and is extremely difficult and complex, especially for legacy codebases comprising hundreds of thousands of lines of source code. Often the source code is uncommented and difficult for a human software engineer to understand, especially since legacy source code is by nature often outdated and not conforming to standards and practices the human software engineer may be used to. Once the parts of the source code have been identified using the functional markers it is possible for downstream tasks such as migration, maintenance or refactoring to be facilitated. In the case of software migration the identified parts of the source code may be replaced by a containerized service or microservice, or may be upgraded or otherwise refactored. Other parts of the legacy source code may remain unchanged.

[0009] In various examples, the source code implements a telecommunications network service. Often telecommunications network services are deployed using a variety ofsoftware which may include legacy codebases. In order to maintain the telecommunications network service, or upgrade or refactor software implementing the telecommunications network service, the present technology is extremely helpful. In some cases the present technology is used to identify occurrences of functional markers in a legacy codebase that implements a telecommunications network service and the occurrences inform an automated migration, maintenance or refactoring of the telecommunications network service.

[0010] In various examples, the computer implemented method uses a plurality of different role classifiers to assign the functional roles to the nodes in the graph. Using several different role classifiers improves accuracy. It also gives efficiency since the role classifiers may operate in parallel in some cases.

[0011] In various examples, the confidence is determined using any of: rules, a type of one of the role classifiers, the role classifiers, the abductive reasoning. This gives an efficient way of determining confidence which is found to work well in practice.

[0012] Assigning at least one functional role to a node where the assignment is uncertain is a greedy heuristic that is found to work well in practice for assigning the functional roles. An uncertain assignment can be corrected at a later stage if necessary once neighbouring nodes have had functional roles assigned.

[0013] Optionally, the output of one role classifier informs one or more others of the role classifiers. The confidence may be represented using a fuzzy Boolean which facilitates using fuzzy logic in the abductive role reasoning. This gives an effective way to assess many combinations of functional role assignments to find a most likely combination in practical time scales.

[0014] In various examples, the graph is a unified modelling language (UML) diagram and the graph is computed from the source code using an automated tool to derive UML classes from source code. The source code for a legacy software system may be comprised of hundreds of thousands of lines of code. Further, the code may be written in a defunct language which is no longer supported and lacks documentation, or a low-level language making it even more difficult for a human or computer to understand and analyse. The use of a UML diagram allows the code to be represented in a graphical format which is concise and easy to visualise. Using a graph representation facilitates analysis of the legacy software through the use of graph-based techniques such as graph searching and graph matching as described in more detail below.

[0015] In various examples, the functional marker comprises a node with a functional role of controller connected to a node with a functional role of view and a node with a functional role of model. The particular grouping of controller, view and model functional roles as a functional marker represent an industry standard model-view-controller (MVC) software architecture. In the application of this architecture to software systems, the controllerelement typically aggregates to the view and model elements. Therefore, identifying one of the three means the presence of the other two is expected and a search for the other two can be narrowed to a region near the identified one. This greatly improves the efficiency of the overall process of identifying functional markers. Further, in the case of uplifting legacy software it is often the case that the user interface is outdated and is completely re-written (i.e. refactored). Hence, there is often a need to identify solely the user interface from the entire legacy software source code, a task further made difficult by the vast amount of code typically present. The use of the MVC functional marker allows for the user interface to be identified and re-written without having to analyse the entirety of the source code, thus making the process significantly more efficient.

[0016] In various examples, assigning a functional role comprises using static code analysis. Using static code analysis is an effective, principled way to assign a functional role.

[0017] In various examples, identifying an occurrence of the functional marker comprises using a sub-graph matching algorithm. Using a sub-graph matching algorithm is an efficient, accurate way of identifying an occurrence of the functional marker. The bigger the graph becomes the harder it becomes to do sub-graph matching on it without using a heuristic to guide the matching. One such heuristic comprises the use of functional markers to guide the search.

[0018] In various examples, the computer implemented method comprises carrying out any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

[0019] Processes such as migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance are tasks that typically require an in-depth understanding of the source code, the functional roles of components of the source code and how these components work together to grant a certain functionality. The present technology enables an automated process to identify components of the source code having a particular functional role and then to carry out migration, maintenance or refactoring of the identified components.

[0020] In another aspect there is an apparatus comprising: a processor; a memory storing instructions which when executed by the processor implement the following method: accessing source code from a legacy code base; computing a graph representing the source code, the graph comprising a plurality of nodes connected by edges, each node representing a software component of the source code and each edge representing a relationship between software components;accessing a functional marker comprising a plurality of interconnected nodes, each node representing a software component and having a known functional role; identifying an occurrence of the functional marker in the graph representing the source code; assigning a functional role to nodes in the graph which are part of the occurrence by using the known functional roles of the functional marker; determining a confidence of the assigned functional role for each node that is part of the occurrence; determining, using abductive reasoning, a most likely assigned functional role for each node that is part of the occurrence; for the source code from the legacy code base corresponding to the nodes with the most likely assigned functional roles, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. Using the abductive reasoning is found to improve accuracy of the functional role assignments. Identifying the occurrence of functional markers comprising a plurality of nodes with each node having a known functional role within a graph representing the source code from a legacy code base is a particularly effective way to identify the functional roles of nodes and the corresponding source code from the legacy code base. Using functional markers for functional role identification within the source code is an automated, efficient and effective way for legacy code to be migrated, deployed as a microservice, deployed as a containerised service, deployed as a cloudnative application, maintained or refactored.

[0021] In various examples relating to the apparatus, the confidence is determined using any of: rules, a type of one of the role classifiers, the role classifiers, the abductive reasoning. .

[0022] In various examples relating to the apparatus, the functional marker comprises a node with a functional role of controller connected to a node with a functional role of view and a node with a functional role of model. The use of the MVC functional marker allows for the user interface to be identified and re-written without having to analyse the entirety of the source code, thus making the process significantly more efficient.

[0023] In various examples relating to the apparatus, assigning a functional role comprises using static code analysis. Using static code analysis is an effective way to assign a functional role.

[0024] In various examples relating to the apparatus, identifying an occurrence of the functional marker comprises using a sub-graph matching algorithm. Using a sub-graph matching algorithm is a particularly effective way of identifying an occurrence of the functional marker. This provides an accurate and principled way of identifying parts of a potentially huge legacy codebase.

[0025] In another aspect of the invention there is a computer program with instructions which when executed by a processor implement one or more of the methods described above.

[0026] It will also be apparent to anyone of ordinary skill in the art, that some of the preferred features indicated above as preferable in the context of one of the aspects of the disclosed technology indicated may replace one or more preferred features of other ones of the preferred aspects of the disclosed technology. Such apparent combinations are not explicitly listed above under each such possible additional aspect for the sake of conciseness.

[0027] Other examples will become apparent from the following detailed description, which, when taken in conjunction with the drawings, illustrate by way of example the principles of the disclosed technology.BRIEF DESCRIPTION OF THE DRAWINGS

[0028] FIG 1. is a schematic diagram of a tool for migration, maintenance or refactoring of source code with abductive reasoning, the tool deployed in a communications network and being used on a legacy code base;

[0029] FIG 2. is schematic diagram of a tool for migration, maintenance or refactoring of source code with abductive reasoning;

[0030] FIG 3A. is a schematic diagram of an example functional marker, which in this case is a model-view-controller (MVC) software architecture;

[0031] FIG 3B. is a schematic diagram of a legacy software system such as that of FIG. 1 ;

[0032] FIG. 4 is a schematic diagram of an example role classifier, abductive reasoner and legacy software system;

[0033] FIG. 5 is a flow diagram of a method performed by a tool for migration, maintenance or refactoring of source code with abductive reasoning;

[0034] FIG. 6 is a schematic diagram of a computer in which a tool for migration, maintenance or refactoring is deployed in some cases.

[0035] The accompanying drawings illustrate various examples. The skilled person will appreciate that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the drawings represent one example of the boundaries. It may be that in some examples, one element may be designed as multiple elements or that multiple elements may be designed as one element. Common reference numerals are used throughout the figures, where appropriate, to indicate similar features.DETAILED DESCRIPTION

[0036] The following description is made for the purpose of illustrating the general principles of the present technology and is not meant to limit the inventive concepts claimed herein. As will be apparent to anyone of ordinary skill in the art, one or more orall of the particular features described herein in the context of one embodiment are also present in some other embodiment(s) and / or can be used in combination with other described features in various possible combinations and permutations in some other embodiment(s).

[0037] Dealing with legacy software systems in broad strokes consists of at least two activities, both of which are aimed at maintaining the value of the function provided by such systems. The first activity is concerned with keeping the legacy system working in its current incarnation without an intention of fundamentally changing its design or mode of operation. The bulk of the work performed in this activity falls into the category of software maintenance, i.e. making updates to the software and its deployment to ensure it can continue working as before. This can include fixing bugs or keeping software compatible with external libraries and execution environment, which will change over time and break normal operation if not addressed.

[0038] The second type of activity is concerned with improving core attributes of the legacy software system, such as speed or stability, while retaining its core functionality and the value it represents to the organisation. This is also known as software refactoring and involves in-depth analysis, rearchitecting and comprehensive reimplementation of the software system while ensuring functional equivalence upon completion. Related tasks to ensure this include creating comprehensive test harnesses, writing documentation, etc. Between the two, software refactoring requires a substantially more comprehensive understanding of the design and architecture of the legacy system, which can be amplified by the refactoring target when the system is intended to undergo fundamental architectural changes, for example when migrating from a monolithic desktop to a cloud-based webapplication.

[0039] There is also potentially a third activity that can happen where an engineer is required to add new functionality to a legacy system to support changing requirements. In this case, a deep understanding of the legacy system is needed and the functional markers and functional roles are hugely beneficial.

[0040] A core part of performing maintenance or refactoring on legacy software systems is to have an in-depth understanding of their design, structure and architecture, information that typically is not readily available. As these legacy systems will have been around for some time, documentation tends to be sparse, limited and incomplete, and their original developers likely will have moved on. The challenge therefore lies in trying to understand these systems from this fragmented information and the source code itself.

[0041] One approach is to use tools allowing for projection of source code into UML diagrams, such as class and sequence diagrams. However due to the size of legacy codebases these diagrams alone provide limited insight.

[0042] The inventors have recognized that, when faced with the task of migrating and uplifting a legacy software system to a more modern incarnation, such as a cloud-based architecture, a core challenge is to understand the constituent parts that make up the original system. This is not just limited to understanding individual lines of code, it is also critical to understand the larger components and the functional roles they fulfil, such as components that contain business logic or components that provide a user interface. With the generally large size and high complexity of legacy systems, efficiently identifying and grouping components based on their functional roles is key to successfully completing the migration. Algorithmically determining the functional roles of components (classes, files) in legacy software systems can be particularly challenging as typically only low-level code elements are available that offer little clue as to the bigger functional role they fulfil in the system.

[0043] The inventors have developed a way to use functional markers to facilitate automatically identifying components in legacy code bases and assigning functional roles to the identified components. Once identified, parts of the source code with particular assigned functional roles can be migrated, maintained or refactored in an automated manner. A functional marker is a plurality of interconnected nodes, each node representing a software component and having a known functional role. A store or database of functional markers is available and is used as described below. More detail about functional markers, including examples of functional markers, is given below.

[0044] A substantial challenge of legacy software migration, maintenance or refactoring lies in attempting to understand the core components of the original system and the role(s) they play in fulfilling its intended purpose. Several analyses may be undertaken which aim to work out the role the constituent components play to achieve the functionality of the system. The functional role assignment activities on their own often struggle to give conclusive answers, due to limited availability of accurate documentation and knowledge. In practice, this means such analysis generally results in multiple potential functional roles being identified for components with varying levels of certainty, and no clear way to determine which ones are correct.The present application is concerned with augmenting the functional role assignment using an artificial intelligence component, referred to as an abductive reasoner, that can deduce the role of core architectural elements by evaluating and reconciling analysis results of the legacy systems. By using fuzzy sets to represent uncertainty and abductive reasoning to resolve conflicting classifications, the abductive reasoner determines the best assignment of functional roles based on the available information. The assigned functional roles are then usable by downstream systems such as for migration, maintenance or refactoring.

[0045] The benefits of the technology over existing techniques are at least two-fold. First, systematic exploration and interpretation of functional role assignment results is computed to determine a most logical and consistent picture of the functional roles filled in the legacy system. This improves accuracy of functional role assignment and as a consequence improves accuracy of migrating, maintaining and refactoring the legacy source code. Development teams are able to migrate more systems at greater velocity, thereby securing their value for an organisation. A second benefit lies in the fact that the technology enables systematic exploration of various interpretations by assigning different weights to the different interpretations, which in turn allows developers to explore various role assignments to components and how these would impact the functional role assignment of other components. This is useful in case of legacy systems that have multiple functional roles tied up in a single component or that are described by conflicting and potentially faulty information.

[0046] FIG 1. is a schematic diagram of a computer implemented tool 100 for migration or maintenance or refactoring of at least part of a legacy code base 102. The tool comprises an abductive reasoner as explained in more detail below. The tool 100 has a user interface 106 whereby a software engineer is able to define functional markers, review functional markers derived by the tool 100 from another information source or internal logic, specify a location or address of a legacy code base 102, review functional roles assigned to components of the legacy code base 102, and trigger one or more of: migration, maintenance, refactoring of components of the legacy code base 102 identified by their functional roles.

[0047] The legacy code base 102 comprises source code, such as hundreds to hundreds of thousands or more of lines of source code, stored in a source code repository, source safe or other store. The source code in the legacy code base 102 may be written in more than one programming language. The tool 100 is language agnostic and is operable with legacy code bases 102 of many different programming languages.

[0048] The tool 100 is in communication with and able to access the legacy code base 102 via a communications network 104 such as an intranet, the internet or any other communications network. In some cases, the legacy code base 102 comprises source code that provides a service to end users via the communications network 104; however, this is not essential. In some cases, the legacy code base 102 comprises source code that implements a telecommunications network service such as a voicemail service, an on demand video streaming service, an internet access service or other service.

[0049] The tool 100 has functionality to identify occurrences of functional markers in the legacy code base 102. The tool 100 also has functionality to assign functional roles to components of the legacy code base 102 according to functional roles of the identified occurrences of the functional markers. The functionality to assign functional rolescomprises a plurality of role classifiers and also an abductive reasoner. The role classifiers and the abductive reasoner are explained in more detail below. Once a functional role has been assigned to a component of the legacy code base 102, this information may be used by the tool 100 to migrate only that component, or maintain only that component, or to refactor only that component of the legacy code base 102. In some cases a plurality of components are migrated or maintained or refactored in conjunction with one another based on the relationship between their functional roles. The benefits of the tool 100 are at least two-fold. First, because a functional marker is a generic structure, it allows modelling conceptual understanding of software architecture components and interactions uniformly. Alternative legacy system analysis techniques consider such knowledge in isolation which makes it difficult to apply them across a range of systems efficiently. The second benefit lies in the fact that the functional markers work independent of languages or programming paradigms. This allows for uniform usage and analysis tools for legacy systems, reducing learning curves and ease of use. Working across multiple languages also means that it’s easier to translate concepts between languages, as part of a migration process for instance.

[0050] In some examples the legacy code base comprises source code written in more than one programming language, for example, some business logic in Java and a user interface (III) using hyper text mark up language (HTML) and cascading style sheets (CSS). In some cases the programming language is used to help identify certain functional markers and roles, e.g. this component is written in this language which is always used for UI.

[0051] As mentioned above the tool 100 comprises a plurality of role classifiers. Each role classifier uses a different methodology to assign a functional role and associated confidence values to components in the system based on the functional marker. The role classifiers may be independent and may operate in parallel. In some cases the output of one role classifier may inform one or more others of the role classifiers, such as where the role classifiers are repeatedly operated to assign functional roles and associated confidence values to the same identified occurrence of a functional marker.

[0052] The tool 100 comprises an abductive reasoner comprising a plurality of rules for making inferences about assignments of functional roles. The rules operate to find a most likely assignment of functional roles but without verifying the assignment as being correct.

[0053] FIG 2. is schematic diagram of an example of the computer implemented tool 100 for migration, maintenance or refactoring of source code. The tool 100 comprises a projection module 206, an identification module 208, a role determining module 210, and a performing module 212 which are connected together in series as indicated schematically in FIG. 2. The tool 100 also comprises an occurrence module 202 for identifying occurrences of functional markers in source code, as well as a concept module204 for identifying concepts and functional roles. The plurality of role classifiers are in the concept module 204 or are accessible to the concept module 204. The abductive reasoner is part of the concept module 204.

[0054] The projection module 206 accesses or receives legacy code from legacy code base 102 of FIG. 1. The projection module 206 automatically derives a graph representation such as one or more UML diagrams from the legacy source code, such as class diagrams, sequence diagrams or other UML diagrams. The technology isn’t limited to UML. UML is a non-limiting example of one graph based format but other graph representations such as neo4j and janusgraph are used in other examples. The projection module 206 may comprise a UML modelling tool that supports reverse engineering. A non-exhaustive list of example UML modelling tools that may be used is: ArgoUML, Enterprise Architect, BOUML, JetUML. In an example, the output of the projection module 206 is a representation of the legacy code as a graph, where nodes of the graph represent concepts and the nodes are annotated with metadata so as to represent all elements of the legacy code base 102.

[0055] The identification module 208 identifies architecture and components of the legacy code base 102 within the UML representation of the legacy source code. The identification module 208 comprises a search for elements (classes or files for example) that belong together as they provide part of a solution to the same problem. An output of the identification module 208 comprises one or more groups of elements.

[0056] The role determining module 210 comprises an in-depth analysis of the outputs of the identification module 208 to determine functionality in the legacy system, for example determining a group of elements is part of a user interface or core business logic. The role determining module 210 uses static analysis, rules or other criteria to assign a role to a group of elements.

[0057] The performing module 212 has functionality for taking the output of the previous modules and transforming or migrating or maintaining the legacy code base 102 towards its new target. The performing module 212 may use code generators such as GPT-Code- Clippy or transformation models. The performing module 212 computes output 214 comprising refactored or migrated or maintained source code.

[0058] The present technology improves or augments the modules 208, 210 by adding the occurrence module 202 and the concept module 204. The occurrence module 202 has access to a store of functional markers 200. The functional markers 200 are represented in graphical form or are converted to graphical form by the occurrence module 202. The occurrence module 202 uses sub-graph matching algorithms from graph theory to identify occurrence of functional markers in the graphical representation of the legacy code base 102. In an example the sub-graph matching is performed using a graph processing software package such as, but not limited to, vWorks (trade mark) or Graculus(trade mark) or a stand alone library. Occurrences identified by occurrence module 202 are sent to the identification module 208 to inform the search done by the identification module 208. Groups of elements identified by the identification module 208 are sent to the occurrence module 202 to inform the sub-graph matching process of identifying occurrences. In this way the performance of the identification module 208 is improved and the performance of the occurrence module 202 is improved, as compared to using either of these modules alone. Thus there is synergy between the occurrence module 202 and the identification module 208.

[0059] The concept module 204 receives output of the occurrence module 202. Thus the concept module 204 receives identifiers of components in the graphical representation of the legacy source code which are in an occurrence of a functional marker. The concept module assigns functional roles to the components in the occurrence. The functional roles are assigned according to the known functional roles of the functional marker components. The concept module 204 comprises, or has access to one or more role classifiers. The role classifiers may use the known functional roles of the functional marker components and assign those to the components of the identified occurrence. Each role classifier uses a different method or principle to assign the functional roles. A non-exhaustive list of example role classifier methods is: a role classifier that assigns a role to a component by examining neighbouring components; a role classifier that assigns a role to a component by examining use of the component in test or run-time code path executions of the legacy source code; a role classifier that assigns a role to a component by querying a history of the legacy source code in a source safe or source code repository; a role classifier that assigns a role to a component by using information from a software specification of the legacy source code. A role classifier may combine one or more of these role classifier methods.

[0060] Where more than one role classifier is used, there is a plurality of assignments of functional roles to each component of the identified occurrence of the functional marker. In order to make sense of these multiple, potentially conflicting assignments of functional roles, the abductive reasoner is used. Even where only one role classifier is used, there is often uncertainty and possible error in the assignments of the functional roles to components. The abductive reasoner computes a most likely assignment of the functional roles taking into account all the available information.

[0061] The abductive reasoner receives as input the results from the role classifiers. In some cases the results from the role classifiers have associated certainty or confidence values. There are confidence values of the role classifiers, and also in the actual role values that have been assigned by these role classifiers. The abductive reasoner is able to take both of these types of confidence values into account. When a role classifier assigns functional roles, it may assign a confidence value to that classification based onthe information that is considered within the bounds of the algorithm used by that role classifier. This confidence value may be fine tuned within the role classifier. There is also a confidence value associated with the ‘trustworthiness’ of the role classifier itself. This can be determined through fine tuning within the abductive reasoner and can take into account the factors listed below but also the percentage of correct classifications, i.e. the percentage of times that the classification provided was the classification that was determined by the abductive reasoner.

[0062] In an example, a role classifier that uses information from a history of the source code in a source safe may be given a low confidence when the number of versions of the source code in the source safe is below a threshold. In another example, a role classifier that uses information from execution traces may be given a high confidence when the execution trace is from a run time execution and a lower confidence when the execution trace is from a test time execution.

[0063] In an example, a role classifier that assigns a role to a component by examining neighbouring components may assign a higher confidence value to its classification if there are more neighbouring components that provide evidence to and agree to the classification.

[0064] In another example, a role classifier that assigns a role to a component by examining the names of entities within the component may assign a higher classification if the detected common language is present across class names, method names and variable names.

[0065] The abductive reasoner receives the results from the role classifiers annotated on a graph based representation of the legacy source code. The confidence values are represented using fuzzy Booleans annotated to the nodes of the graph. Suppose a first role classifier assigns role A to a node and that a second role classifier assigns role B to the same node. The first role classifier is trusted more than the second role classifier. In this case the node is annotated with two fuzzy Booleans, one for role A with the fuzziness being determined by the product of the confidence value specified by the first role classifier and a high confidence value determined by the trustworthiness of the first role classifier, and one for role B that follows a similar calculation but with a low confidence value determined by the trustworthiness. In this way there can be multiple possible assignments of functional roles to the nodes of the graph.

[0066] The abductive reasoner assesses each possible assignment of functional roles to the nodes of the graph. Using rules it evaluates the contradictions caused and strength of assumptions required to determine a best set of conclusions regarding functional role assignments. The abductive reasoner resolves conflicts by considering the whole of the graph to make the choice that fits best. In contrast, an optimiser would typically choose, for example, for the functional role that has the highest confidence without considering theroles assigned to its surroundings. The abductive reasoner finds the assignment of roles that best fit the context even if that means choosing a lower confidence option. This is achieved through systematically removing uncertain information when it is deemed unreliable or misunderstanding the context it has analysed.

[0067] The output of the abductive reasoner is a most likely assignment of functional roles to components of the occurrence of the functional marker. In the case that more than one occurrence of a functional marker is found the abductive reasoner also takes that into account. The abductive reasoner is implemented using any well known stand-alone abductive reasoning and fuzzy logic tools such as Atlas. ti, Matlab libraries, Python libraries or others.

[0068] The most likely assignment of functional roles to components is sent from the concept module 204 to the role determining module 210. The assignments inform the process in the role determining module 210 and so improve its performance. The results of the role determining module 210 are sent to the concept module 204 and are used by the concept module 204 to improve the assignment of functional roles to the components in occurrences. In an example, where there are two possible functional roles to assign to a component, information from the role determining module 210 may be used to select between the two possibilities rather than making a random choice. Thus there is synergy between the concept module 204 and the role determining module 210.

[0069] FIG 3A. is a schematic diagram of an example functional marker, which in this case is a model-view-controller (MVC) software architecture. FIG. 3A shows a view component 300, a model component 302 and a controller component 304. This functional marker captures the way in which an industry-standard model-view-controller software architecture is structured, with a coordinator (controller 304), a user interface (view 300) and an in-memory representation of state (model 302). When applied, the controller 304 typically aggregates (indicated by the two white diamonds) to the view 300 and model 302 components.

[0070] FIG 3B. is a schematic diagram of part of a legacy software system represented in graphical form. In this example the legacy software system comprises a monitor 308 in a telecommunications network 104 monitoring round trip time over a specified communications link. A current value of the round trip time is published to a graphical user interface (GUI) 306 and continually updated. In FIG. 3B five elements are illustrated that perform specific tasks, such as graphical user interface 306 for displaying current round trip time, RTT monitor for monitoring round trip time, state 310 storing the current value of round trip time, history 312 and keeping track of the history 312 of round trip times. When examining the source code of these elements or components the functional role of each element is not trivially clear. However, using the functional marker in FIG. 3Aa clearer picture emerges. When applied, the controller 304 typically aggregates (indicated by the two white diamonds) to the view 300 and model 302 elements.

[0071] By attempting to identify occurrence of the functional marker in the graphical representation of the legacy code, for example using subgraph matching, an algorithm can establish that the RTT monitor element 308 likely takes the Controller 304 functional role, the GUI 306 the View 300 role and the State 310 the Model 302 role. At this point the GUI 306 and State 310 cannot be assigned a functional role with certainty but the use of the role classifiers, abductive reasoner and identification of further functional markers can help resolve this uncertainty.

[0072] FIG. 4 is a schematic diagram of a plurality of example role classifiers 406, an example abductive reasoner 400 and an example legacy software system. FIG. 4 shows a graphical representation of an example legacy software system on which the plurality of example role classifiers have been used and functional roles have been assigned to various components of the legacy software system.

[0073] In the example of FIG. 4, the graphical representation of the legacy source code comprises an observer component 404, a graphical user interface component 306, a subject component 402, a monitor component 308, a state component 310 and a history component 312. The monitor component 308 aggregates from state component 310 which is associated with history component 312. In an example, the monitor component 308 aggregates state such as a value of a packet loss rate of a communications network link. The graphical user interface component 306 has been assigned (by one of the role classifiers 406) a functional role of view. The monitor component 308 has been assigned (by one of the role classifiers 406) a functional role of view and a plurality of instances of the functional role of model. The state component 310 has been assigned a functional role of model by one of the role classifiers 406. The history component 312 has been assigned a functional role of view and a functional role of model by one or more of the role classifiers 406.

[0074] In this example a consensus has been reached for the functional roles of the graphical user interface 306 and state 310 components whereas conflicts of assignment exist for the monitor 308 and history 312 components.

[0075] In an example, monitor component 308 represents part of the legacy software system that monitors a round trip time of a communications network link, or a packet loss rate on the communications network link. The state is the current data obtained by the monitor and the history 330 is a record of previous values of the state.

[0076] The abductive reasoner 400 takes the graph representation annotated with the functional role assignments and the associated confidence values as input. The functional role assignments have associated confidences as mentioned above. The confidences are a product of the confidence values assigned by the role classifiers 406 and theconfidence values determined by the abductive reasoner 400 using rules. The abductive reasoner 400 represents the confidences using fuzzy Booleans. Thus in the example of FIG. 4 the monitor component 308 is given four fuzzy Booleans, one related to confidence of the functional role of view and three related to each of the instances of the functional role of model which have been assigned to the node by the role classifiers 406. The abductive reasoner 400 considers all possible combinations of the assigned functional roles and ranks them in terms of degree of consistency and confidence of classification. The highest ranking combination is selected as the most likely and is output by the abductive reasoner. FIG. 4 shows dotted lines indicating hypotheses that the abductive reasoner considers. The dotted line from the abductive reasoner 400 to the history component 312 labelled Model! Indicates a hypothesis that the history component 312 is not assigned a functional role of model.

[0077] FIG. 5 is a flow diagram of a method performed by a tool 100 for migration, maintenance or refactoring of source code. The tool 100 accesses 400 source code from a legacy code base 102 or other code base. Optionally other information is also accessed such as manuals or other documentation about the source code. The tool 100 computes 402 a graph which is a graphical representation of the source code. In an example this is done using an automated UML tool and optionally taking into account the documentation. The tool 100 accesses 404 a store of functional markers 200. The functional markers may have been manually defined or may be obtained by automated analysis of source code. The tool 100 identifies 404 an occurrence of at least one of the functional markers. This may be done by sub-graph matching as described above. The tool 100 assigns 406 functional roles to nodes of the graph in the occurrence. The assigning is done according to known functional roles of components or nodes of the functional marker. The assigning is also done using one or more role classifiers as described above with reference to FIG. 2 and FIG. 4. The assigned functional roles and confidences of those assignments are input to an abductive reasoner which carries out abductive role reasoning 508. The operations of assigning the functional roles and computing the abductive role reasoning 508 may iterate in some examples until there is little change in the output of the abductive reasoner. The tool 100 then triggers 510 migration, or maintenance or refactoring of part but not all of the source code, where the part of the source code is selected from the legacy code base 102 using rules and the assigned functional markers.

[0078] FIG. 6 illustrates various components of an example computing device 600 in which embodiments of a migration / maintenance / refactoring tool are implemented in some examples. The computing device is of any suitable form such as a desktop computer, a server, a compute node in a data centre.

[0079] The computing device 600 comprises one or more processors 602 which are microprocessors, controllers or any other suitable type of processors for processingcomputer executable instructions to control the operation of the device in order to perform the methods of figures 2 to 5. In some examples, for example where a system on a chip architecture is used, the processors 602 include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of figures 2 to 5 in hardware (rather than software or firmware). That is, the methods described herein are implemented in any one or more of software, firmware, hardware. The computing device has a data store holding functional markers. The computing device has the migration / maintenance / refactoring with abductive reasoning tool 100 within the memory 614. Platform software comprising an operating system 616 or any other suitable platform software is provided at the computing-based device to enable application software 618 to be executed on the device. Although the computer storage media (memory 614) is shown within the computing-based device 600 it will be appreciated that the storage is, in some examples, distributed or located remotely and accessed via a network or other communication link (e.g. using communication interface 604).

[0080] The computing-based device 600 also comprises an input / output controller 608 arranged to output display information to a display device 610 which may be separate from or integral to the computing-based device 600. The display information may provide a graphical user interface. The input / output controller 608 is also arranged to receive and process input from one or more devices, such as a user input device 612 (e.g. a mouse, keyboard, camera, microphone or other sensor). In some examples the user input device 612 detects voice input, user gestures or other user actions. In an embodiment the display device 610 also acts as the user input device 612 if it is a touch sensitive display device. The input / output controller 608 outputs data to devices other than the display device in some examples.

[0081] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and an apparatus may contain additional blocks or elements and a method may contain additional operations or elements. Furthermore, the blocks, elements and operations are themselves not impliedly closed.

[0082] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. The arrows between boxes in the figures show one example sequence of method steps but are not intended to exclude other sequences or the performance of multiple steps in parallel. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. Where elements of the figures are shown connected byarrows, it will be appreciated that these arrows show just one example flow of communications (including data and control messages) between elements. The flow between elements may be in either direction or in both directions.

[0083] Where the description has explicitly disclosed in isolation some individual features, any apparent combination of two or more such features is considered also to be disclosed, to the extent that such features or combinations are apparent and capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

CLAIMS1. A computer implemented method comprising: accessing source code from a legacy code base; computing a graph representing the source code, the graph comprising a plurality of nodes connected by edges, each node representing a software component of the source code and each edge representing a relationship between software components; accessing a functional marker comprising a plurality of interconnected nodes, each node representing a software component and having a known functional role; identifying an occurrence of the functional marker in the graph representing the source code; assigning a functional role to nodes in the graph which are part of the occurrence according to the known functional roles of the functional marker; determining a confidence of the assigned functional role for each node that is part of the occurrence; determining, using abductive reasoning, a most likely assigned functional role for each node that is part of the occurrence; and for the source code from the legacy code base corresponding to the nodes with the most likely assigned functional roles, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

2. The computer implemented method of claim 1 wherein the source code implements a telecommunications network service.

3. The computer implemented method of claim 1 or claim 2 comprising using a plurality of different role classifiers to assign the functional roles to the nodes in the graph.

4. The computer implemented method of claim 3 wherein the confidence is determined using any of: rules, a type of one of the role classifiers, the role classifiers, the abductive reasoning.

5. The computer implemented method of claim 3 or claim 4 wherein the output of one role classifier informs one or more others of the role classifiers.

6. The computer implemented method of any preceding claim comprising representing the confidence using a fuzzy Boolean.

7. The computer implemented method of any preceding claim wherein assigning a functional role comprises using static code analysis.

8. The computer implemented method of any preceding claim wherein identifying an occurrence of the functional marker comprises using a sub-graph matching algorithm.

9. The computer implemented method of any preceding claim comprising carrying out any of the: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

10. An apparatus comprising: a processor; a memory storing instructions which when executed by the processor implement the following method: accessing source code from a legacy code base; computing a graph representing the source code, the graph comprising a plurality of nodes connected by edges, each node representing a software component of the source code and each edge representing a relationship between software components; accessing a functional marker comprising a plurality of interconnected nodes, each node representing a software component and having a known functional role; identifying an occurrence of the functional marker in the graph representing the source code; assigning a functional role to nodes in the graph which are part of the occurrence by using the known functional roles of the functional marker; determining a confidence of the assigned functional role for each node that is part of the occurrence; determining, using abductive reasoning, a most likely assigned functional role for each node that is part of the occurrence; for the source code from the legacy code base corresponding to the nodes with the most likely assigned functional roles, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

11. The apparatus of claim 10 wherein the confidence is determined using any of: rules, a type of one of the role classifiers, the role classifiers, the abductive reasoning.

12. The apparatus of any of claims 10 to 11 wherein the functional marker comprises a node with a functional role of controller connected to a node with a functional role of view and a node with a functional role of model.

13. The apparatus of any of claims 10 to 12 wherein the confidence is represented using a fuzzy Boolean.

14. The apparatus of any of claims 10 to 13 wherein identifying an occurrence of the functional marker comprises using a sub-graph matching algorithm.

15. A computer program having instructions which when executed by a processor implement the method of any of claims 1 to 9.

Images