Source code migration, maintenance, refactoring for telecommunications network services

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 rose 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.

Description

SOURCE CODE MIGRATION, MAINTENANCE, REFACTORING 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; 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; and for the source code from the legacy code base corresponding to the nodes with the assigned functional roles, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. 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 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 theoccurrences inform an automated migration, maintenance or refactoring of the telecommunications network service.

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

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

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

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

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

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

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

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

[0019] 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; and for the source code from the legacy code base corresponding to the nodes with the assigned functional roles, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. Identifying the occurrence of functional markers comprising a plurality of nodes with each node having a known functional role within a graphrepresenting 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 cloud-native application, maintained or refactored.

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

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

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

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

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

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

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

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

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

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

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

[0031] FIG. 4 is a flow diagram of a method performed by a tool for migration, maintenance or refactoring of source code;

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

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

[0034] 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).

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

[0036] 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 toensure 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.

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

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

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

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

[0041] 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 ordatabase of functional markers is available and is used as described below. More detail about functional markers, including examples of functional markers, is given below.

[0042] 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 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, and trigger one or more of: migration, maintenance, refactoring of components of the legacy code base 102 identified by their functional roles.

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

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

[0045] 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’seasier to translate concepts between languages, as part of a migration process for instance.

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

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

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

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

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

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

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

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

[0054] The assignments of functional roles to components are 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.

[0055] 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 functionalmarker 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.

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

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

[0058] FIG. 4 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 UM L 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 406 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 408 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 tool 100 triggers 410 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.

[0059] FIG. 5 illustrates various components of an example computing device 500 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.

[0060] The computing device 500 comprises one or more processors 502 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 4. In some examples, for example where a system on a chip architecture is used, the processors 502 include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of figures 2 to 4 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 506 within the memory 514. Platform software comprising an operating system 516 or any other suitable platform software is provided at the computing-based device to enable application software 518 to be executed on the device. Although the computer storage media (memory 514) is shown within the computing-based device 500 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 504).

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

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

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

[0064] 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; and for the source code from the legacy code base corresponding to the nodes with the 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 accessing a plurality of functional markers and identifying an occurrence of any of the functional markers in the graph.

4. The computer implemented method of any preceding claim wherein assigning the functional roles comprises assigning at least one functional role to a node where the assignment is uncertain.

5. The computer implemented method of any preceding claim wherein 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.

6. The computer implemented method of any preceding claim 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.

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; and for the source code from the legacy code base corresponding to the nodes with the 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 assigning the functional roles comprises assigning at least one functional role to a node where the assignment is uncertain.

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 assigning a functional role comprises using static code analysis.

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