Source code migration, maintenance, refactoring using domain concepts for telecommunications network services

Abstract

A graph representing the source code is computed, 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 domain model of a domain related to the legacy code base is computed, the domain model comprising a plurality of concepts and relationships between the concepts. A node of the graph matching one of the concepts is identified. A functional role of model is assigned to the identified node. The knowledge of the assigned functional role is used to trigger any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

Description

SOURCE CODE MIGRATION, MAINTENANCE, REFACTORING USING DOMAIN CONCEPTS FOR TELECOMMUNICATIONS NETWORK SERVICES

[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; computing, from documentation related to the legacy code base, a domain model in graphical form, of a domain related to the legacy code base, the domain model comprising a plurality of concepts and relationships between the concepts; identifying a node of the graph matching one of the concepts; assigning a functional role of model to the identified node; and using the knowledge of the assigned functional role, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

[0009] Since the concepts and domain model are dynamically computed from the documentation related to the legacy code base, the concepts and domain model are complete and comprehensive. This improves performance of the assignment of functional roles which in turn improves performance of the source code migration, or maintenance or refactoring.

[0010] 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 roles 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.

[0011] In various examples identifying a node of the graph matching one of the concepts comprises making a partial match between the node and the concept and assigning a fuzzy Boolean to the node of the graph indicating a degree of the partial match. This facilitates the use of abductive reasoning to resolve conflicts and find a most likely assignment of functional roles to nodes of the graph.

[0012] In some examples, computing the domain model comprises using a natural language processing analysis function. This gives a methodical and principled, automated way to compute the domain model which is found to work well in practice.

[0013] In some examples the functional role of model is a functional role from a model view controller design pattern. This is found to work well in practice since. Computing the domain model may comprise detecting entities in text about the software application where the entities comprise model elements of the software application. It is then possible to trace how those model elements are operated on to infer other functional roles and what different workflows might be present in the software application.

[0014] In various examples, identifying a node of the graph matching one of the concepts comprises taking into account a relationship between the matched concept and other concepts in the domain model. In an example, this is done by using sub-graph matching. Thus the identification process is tractable and yields good working results even for large legacy code bases.

[0015] In various examples, the source code implements a telecommunications network service. Often telecommunications network services are deployed using a variety of software 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.

[0016] In various examples, the computer implemented method accesses a plurality of functional markers and identifies an occurrence of any of the functional markers in the graph. Functional markers may be used in combination with the domain concepts in the process of assigning functional roles to nodes of the graph. This provides an accurate and principled way of identifying parts of a potentially huge legacy codebase.

[0017] In various examples, assigning the functional roles comprises assigning at least one functional role to a node where the assignment is uncertain.

[0018] 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.

[0019] 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 ina 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.

[0020] 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 controller element 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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 identifycomponents of the source code having a particular functional role and then to carry out migration, maintenance or refactoring of the identified components.

[0025] 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; computing, from documentation related to the legacy code base, a domain model in graphical form, of a domain related to the legacy code base, the domain model comprising a plurality of concepts and relationships between the concepts; identifying a node of the graph matching one of the concepts; assigning a functional role of model to the identified node; and using the knowledge of the assigned functional role, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. Computing the concepts and relations between concepts directly from documentation about the legacy code base promotes accuracy of assignment of functional roles to nodes of the graph. As a result there 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 cloud-native application, maintained or refactored.

[0026] In various examples relating to the apparatus, assigning the functional roles comprises assigning at least one functional role to a node where the assignment is uncertain.

[0027] 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.

[0028] 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.

[0029] 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 thefunctional marker. This provides an accurate and principled way of identifying parts of a potentially huge legacy codebase.

[0030] 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.

[0031] 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.

[0032] 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

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

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

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

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

[0037] FIG. 4 is a schematic diagram of a legacy software system, domain concepts and a role classifier;

[0038] FIG. 5 is a flow diagram of a method performed by a tool for migration, maintenance or refactoring of source code, where the method comprises creating and using a domain model;

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

[0040] 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

[0041] 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 or all 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).

[0042] The present technology augments a role classification stage of a source code migration / maintenance / refactoring process with an artificial intelligence (Al) component that can identify the role of core architectural elements by evaluating them against specific knowledge that covers the application domain, including core concepts and relationships that can be expected to exist. A domain model is derived from existing source code, documentation and artefacts of the software system under study. Optionally domain models are also found from related software systems to identify commonality and recurring patterns.

[0043] Systematic exploration of role classification results based on domain-specific information allows to determine the most logical and consistent picture of the roles filled in the legacy system while significantly reducing the time needed for analysis and understanding. This enables development teams to migrate more systems at greater velocity, thereby securing their value.

[0044] The technology allows deriving and leveraging domain-specific information from existing and related software systems, which in turn allows developers to improve understanding of other components subject to the level of detail that can be achieved in the domain model. This is in particular useful in case of legacy systems that share core workflows, functionality and concepts with several other systems and as such have an overlapping application domain, something that is very common in legacy software systems. 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.

[0045] 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 functionalityand 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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 workflow 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.

[0050] 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 automatedmanner. 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.

[0051] 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 using a domain model, which is derived by the tool 100, or is a pre-existing domain model. The tool 100 has a user interface 106 whereby a software engineer is able to define functional markers, specify a location or address of a legacy code base 102, review functional roles assigned to components of the legacy code base 102, specify a location or address of documentation or other materials about a domain 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.

[0052] 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.

[0053] 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.

[0054] The tool 100 is able to access domain materials 108 such as documentation or other materials about a domain of the legacy code base 102 and / or related domains. A non-exhaustive list of examples of domain materials is: user manuals for the legacy software system, trouble shooting guides for the legacy software system, training guides for the legacy software system, customer support logs about the legacy software system.

[0055] The tool 100 has access to a natural language processing analysis function 110 such as a large language model or other language model. In some cases the NLP analysis function 110 is integrated with tool 100.

[0056] The tool 100 uses the natural language processing analysis function 110 to derive a domain model from the domain materials 108. The domain model is in graphical form and comprises nodes representing concepts of the domain linked by edges representing relationships between the concepts. More detail about how the domain model is derived is given later in this document. The domain model is used by the tool to facilitateassignment of functional roles to elements of the legacy code base 102. The identified functional roles facilitate migration or maintenance or refactoring of the legacy code base 102.

[0057] 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. 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 twofold. 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.

[0058] In some examples the legacy code base comprises source code written in more than one programming language, for example, some workflow 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.

[0059] 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 module 204 for identifying concepts and functional roles. The concept module 204, and optionally the role determining module 210 have access to a domain model 216 such as that described with reference to FIG. 1. The domain model is derived by the tool 100 from domain materials about a domain of the legacy source code or from materials about source code from a related domain. The domain model 216 is stored in graphical form andcomprises a plurality of nodes connected by edges. Each node represents a concept in the domain. Each edge represents a relationship between concepts in the domain.

[0060] 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.

[0061] 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.

[0062] 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 workflow logic. The role determining module 210 uses static analysis, rules or other criteria to assign a role to a group of elements. The role determining module 210 may use the domain model 216 to facilitate assignment of roles to elements of the legacy source code.

[0063] 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.

[0064] 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.

[0065] 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 has access to domain model 216 and uses the domain model to facilitate assignment of functional roles to the components.

[0066] The assignments of functional roles to components are sent from the concept module 204 to the role determining module 210. The role determining module 210 may comprise one or more role classifiers. A role classifier classifies a functional role of a component using any of a number of different methods including but not limited to: using information about functional roles of neighbouring components, using information about behaviour of the source code observed in execution traces, using information from design patterns, using information from a history of source code versions of the legacy source code. Each role classifier may operate independently of the other role classifiers. 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.

[0067] 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 304typically aggregates (indicated by the two white diamonds) to the view 300 and model 302 components.

[0068] 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. 3A a clearer picture emerges. When applied, the controller 304 typically aggregates (indicated by the two white diamonds) to the view 300 and model 302 elements.

[0069] 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 identification of further functional markers can help resolve this uncertainty.

[0070] FIG. 4 is a schematic diagram of a legacy software system 400, domain concepts 420 and a role classifier 422. In some examples there is more than one role classifier 422. The legacy software system 400 is represented using a graphical representation comprising nodes interconnected by edges. Each node represents a component of the legacy software system 400 and the edges represent relationships between the components. The graph representing the legacy software system 400 represents both static code information as well as code comments and supplementary information.

[0071] A role classifier 422 is computer implemented and comprises functionality to assign a functional role to a node of the graphical representation of the legacy software system 400. 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 that assigns a functional role to a component by using a functional marker or a design pattern being used as a functional marker. A role classifier may combine one or more of theserole classifier methods. A role classifier 422 takes as input the graphical representation of the legacy software system 400 and produces as output annotations on one or more nodes of the graphical representation indicating possible functional roles of the nodes. The role classifier 422 optionally also outputs confidence data indicating a level of uncertainty in the annotations.

[0072] FIG. 4 also shows domain concepts 420 stored in a memory accessible to the role classifier(s) 422. Relationships between the domain concepts may also be stored. The domain concepts and relationships between the domain concepts together form a domain model. The domain is a domain of the legacy software system 400. A non-limiting example of a domain is a telecommunications voicemail service. FIG. 4 shows domain concepts of visual voicemail 418 and audio voicemail 416 from the domain of a telecommunications voicemail service although this is a non-limiting example given to aid understanding of the technology. The relationships between the concepts in FIG. 4 is not illustrated.

[0073] FIG. 4 also shows a natural language processing (NLP) analysis function 110. In some cases the NLP analysis function 110 is a large language model that is capable of analysing text documents such as source code documentation, bug ticket history logs, source code, user manuals, meeting notes, whiteboard diagrams. A large language model is a machine learning model which generates text and which may have around one billion parameters or more. A non-exhaustive list of examples of large language models which may be used is: ChatGPT, LlaMa, Bloom, Mistral Large. The NLP analysis function 110 computes as output the domain concepts 420 and relationships between the domain concepts. The NLP analysis function 100 takes as input documentation 402.

[0074] Documentation 402 is any information about the domain of the legacy software system 400 or about a domain related to a domain of the legacy software system. The documentation may comprise, but is not limited to, any of: source code documentation, bug ticket history logs, source code, user manuals, meeting notes, whiteboard diagrams, information about software patch releases.

[0075] The role classifier 422 is able to use the domain concepts 420 and relationships between the domain concepts to inform its role classification behaviour so as to improve accuracy. More accurate role classification leads to improved downstream processing such as migration or maintenance or refactoring of the legacy software system 400.

[0076] The domain concepts 420 and relationships between the domain concepts are automatically computed from the documentation 402 using the NLP analysis function 110. This means that the domain concepts and relationships between the domain concepts are complete and comprehensive.

[0077] Consider the conceptual representation of a telecommunications voicemail service in FIG. 4. Documentation 402 about the voicemail service is analysed by NLP analysisfunction 110 which finds domain concepts of: account 424, visual voicemail 418, audio voicemail 416. The NLP analysis function 110 also finds that there is an inheritance relationship between the concept account 420 and the concepts of visual voicemail 418 and audio voicemail 416. The domain concepts 418, 416, 424 are examples and in practice there may be many more domain concepts. Together the domain concepts 418, 416, 424 and the relationships between them are a domain model.

[0078] The role classifier 422 uses the domain model to inform how it assigns functional roles to the nodes of the graphical representation of the legacy software system 400. In the example of FIG. 4 the results of the role classification are shown i.e. the nodes in the graphical representation of the legacy software system 400 have already been annotated with functional roles by the role classifier 422.

[0079] The role classifier 422 matches the domain concepts 420 to the nodes of the graphical representation of the legacy software system 400. When examining the source code corresponding to the nodes of the graphical representation, the functional role of each node is not trivially clear. However, by matching the domain concepts of account 424, visual voicemail 418 and audio voicemail 416, and taking into account the relationships between the domain concepts, the role classifier is able to assign the functional role of visual voicemail account to node 404, audio voicemail account to node 406, and account to parent node 408. In some examples the role classifier 422 generates an output to the graphical user interface 106 with an indication of what functional roles are assigned to each node and an explanation of the rationale for the assignment, where the explanation is generated using rules, the domain concepts and relationships between the domain concepts that led to the assignment of the functional role.

[0080] For each of the nodes of the graph the role classifier 422 has matched to a domain concept, the role classifier assigns a role of Model. As these matches may be partial these functional roles cannot be applied with certainty; further analysis may be done by the tool 100 to resolve this uncertainty.

[0081] The example of FIG. 4 demonstrates how the present technology augments the functional role identification capabilities of legacy source code analysis tools with the capability to identify domain concepts from existing system documentation and recognise their occurrence as components in the legacy system. This information in turn is then used by the role classifier for assigning the most likely functional roles for each element used to understand the architecture of the legacy software system, and use the various concept labels to explain the reasoning behind this algorithm-based decision.

[0082] More detail about the process performed by the tool 100 and the role classifier 422 (which is part of tool 100) is now given with reference to FIG. 5.

[0083] 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 froma 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 502 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.

[0084] The tool 100 creates 504 a domain model in graph form. To create the domain model the tool uses an NLP analysis function 110 such as that of FIG. 1. A non-exhaustive list of NLP analysis functions that may be used is: large language models, sentiment analysis, latent semantic analysis, wordnet analysis. In an example, the tool 100 accesses documentation and materials about a domain of the source code and prompts a large language model to analyse the documentation and materials and determine a plurality of domain concepts and relationships between the domain concepts.

[0085] In another example, the tool 100 converts a known domain model into graph form. The known domain model may be provided as input to the tool 100, or the tool 100 may access a library of known domains models.

[0086] The role classifier 422 compares 506 domain concepts 420 in the domain model in graph form to nodes of the graphical representation of the legacy software system 400. The role classifier 422 takes into account descriptions of the domain concepts 420 and the relationships between domain concepts 420 within the domain model to compare to elements represented by the nodes of the graphical representation of the legacy software system 400. Sub-graph matching is used to carry out the comparison 506 in some cases.

[0087] For each of the nodes of the graphical representation of the legacy software system 400 that the role classifier 422 has matched to a domain concept, the role classifier 422 assigns a role of Model. Thus the tool 100 provisionally identifies 508 model elements. As domain concepts typically represent data that is used as part of a workflow, any identified domain concepts in the legacy system are provisionally identified as model elements.

[0088] The tool 100 assigns 510 fuzzy Booleans to the assigned functional roles. The confidence and doubt of each conclusion is represented by means of fuzzy Booleans to quantify the degree to which the matching with the domain model was achieved. The level of confidence and doubt may be expressed as a numerical value output by the role classifier. One or more of the role classifiers may have mechanisms to determine a goodness of fit (i.e. how well a matched element in the legacy system fits the domain concept it is matched against). In an example the mechanism is a distance measure (such as a Levenshtein distance or other distance metric), or an aggregation of the results of multiple classifiers (e.g. 3 are certain, 2 are uncertain, so 60% confidence of positive, 40% of negative)

[0089] The measure of confidence is represented using a fuzzy Boolean which may be annotated to the nodes of the graph of the legacy software system 400. In an example, anode representing a component of the matched domain concepts 420 is annotated with a fuzzy Boolean indicating low confidence in the match between the domain concept 420 and the elements represented by the nodes in the graphical representation of the legacy software system; in other words, the use of fuzzy Booleans quantifies the degree to which the matching with the domain model could be achieved.

[0090] In some examples, the tool 100 accesses a store of functional markers 200 and uses these to assign functional roles to nodes of the graphical representation of the source code; that is, the tool 100 is able to use functional markers as well as the domain concepts. The functional markers may have been manually defined or may be obtained by automated analysis of source code. The tool 100 may identify 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 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 and optionally also using the domain concepts.

[0091] Once the functional roles have been assigned the tool 100 is able to derive 512 an architecture of the legacy software system.

[0092] The tool 100 triggers 514 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 roles.

[0093] 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.

[0094] The computing device 600 comprises one or more processors 602 which are microprocessors, controllers or any other suitable type of processors for processing computer 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 tool 606 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).

[0095] 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.

[0096] 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.

[0097] 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 by arrows, 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.

[0098] 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; computing, from documentation related to the legacy code base, a domain model in graphical form, of a domain related to the legacy code base, the domain model comprising a plurality of concepts and relationships between the concepts; identifying a node of the graph matching one of the concepts; assigning a functional role of model to the identified node; and using the knowledge of the assigned functional role, 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 identifying a node of the graph matching one of the concepts comprises making a partial match between the node and the concept and assigning a fuzzy Boolean to the node of the graph indicating a degree of the partial match.

3. The computer implemented method of claim 1 or claim 2 wherein computing the domain model comprises using a natural language processing analysis function.

4. The computer implemented method of any preceding claim wherein the functional role of model is a functional role from a model view controller design pattern.

5. The computer implemented method of any preceding claim wherein identifying a node of the graph matching one of the concepts comprises taking into account a relationship between the matched one of the concepts and other concepts in the domain model.

6. The computer implemented method any preceding claim wherein the source code implements a telecommunications network service.

7. The computer implemented method of any preceding claim comprising accessing a plurality of functional markers, identifying an occurrence of any of the functional markers in the graph, and assigning functional roles to other nodes of the graph using the identified occurrence.

8. The computer implemented method of any preceding claim wherein the graph represents static code information and code comments.

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; computing, from documentation related to the legacy code base, a domain model in graphical form, of a domain related to the legacy code base, the domain model comprising a plurality of concepts and relationships between the concepts; identifying a node of the graph matching one of the concepts; assigning a functional role of model to the identified node; and using the knowledge of the assigned functional role, 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 functional role of model is a functional role from a model view controller design pattern.

12. The apparatus of any of claims 10 to 11 wherein identifying a node of the graph matching one of the concepts comprises taking into account a relationship between the matched one of the concepts and other concepts in the domain model.

13. The apparatus of any of claims 10 to 12 wherein the apparatus comprises or interoperates with a natural language processing analysis function for computing the domain model from the documentation relating to the legacy code base.

14. The apparatus of any of claims 10 to 13 wherein identifying the node of the graph matching one of the concepts 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