Source code migration, maintenance, refactoring with architectural restructuring

Abstract

A method reduces architectural coupling in source code. 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 functional marker is accessed comprising a plurality of interconnected nodes, each node representing a software component and having a known functional role. A plurality of concepts of a domain of the source code are available. An occurrence of the functional marker is identified in the graph representing the source code. 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 assigned functional roles are matched to the concepts. An architectural coupling of different functional roles within a single node of the graph is identified using the assigned functional roles and matched concepts. The architectural coupling is reduced by transforming the source code.

Description

SOURCE CODE MIGRATION, MAINTENANCE, REFACTORING WITH ARCHITECTURAL RESTRUCTURING

[0001] The present disclosure relates to source code migration or maintenance or refactoring with architectural restructuring 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; accessing a plurality of concepts of a domain of the source code; 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; matching the assigned functional roles to the concepts; identifying architectural coupling of different functional roles within a single node of the graph using the assigned functional roles and matched concepts; reducing the architectural coupling by transforming the source code; and storing the corresponding source code having reduced architectural coupling.

[0009] Being able to detect and reduce architectural coupling in legacy source code in an automated way is extremely beneficial because it enables ongoing tasks such as maintenance, migration and refactoring of the source code to be facilitated.

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

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

[0012] In various examples, the computer implemented method comprises, for the source code with reduced architectural coupling, triggering any of migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring..

[0013] In various examples, reducing the architectural coupling by transforming the source code comprises using a model-driven engineering transformer. Model-driven engineering transformers are effective technology for transforming source code in a way that takes into account concepts of a domain of the source code. .

[0014] In some examples a code generator is used to generate code for connecting software components that result from transforming the source code. The code generator and / or the transformer may have access to the concepts. Using an automated code generator improves accuracy, consistency, and facilitates the decoupling of the legacy source code.

[0015] In some cases the concepts are computed from the source code using a large language model. Using this automated way to find the concepts improves accuracy and enables versatility for different domains of legacy source code.

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

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

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

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

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

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

[0022] 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; accessing a plurality of concepts of a domain of the source code; 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; matching the assigned functional roles to the concepts; identifying architectural coupling of different functional roles within a single node of the graph using the assigned functional roles and matched concepts; reducing the architectural coupling by transforming the source code; and storing the corresponding source code having reduced architectural coupling.

[0023] Identifying the occurrence of functional markers comprising a plurality of nodes with each node having a known functional role within a graph representing the source code from a legacy code base is a particularly effective way to identify the functional roles of nodes and the corresponding source code from the legacy code base. Using functional markers for functional role identification within the source code is an automated, efficient and effective way for legacy code to be migrated, deployed as a microservice, deployed as a containerised service, deployed as a cloud-native application, maintained or refactored.

[0024] In various examples relating to the apparatus, for the source code with reduced architectural coupling, the apparatus triggers any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

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

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

[0027] In various examples relating to the apparatus reducing the architectural coupling by transforming the source code comprises using a model-driven engineering transformer; In some cases the apparatus comprises a code generator having access to the concepts,the code generator generating code for connecting software components that result from transforming the source code.

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

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

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

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

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

[0033] FIG 2. is schematic diagram of a tool for migration, maintenance or refactoring of source code and showing a transformer and code generator for use in architectural restructuring;

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

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

[0036] FIG. 4 is a schematic diagram of a graphical representation of software before and after architectural restructuring to reduce architectural coupling;

[0037] FIG. 5 is a flow diagram of a method performed by a tool for architectural restructuring of legacy source code, and optionally for migration, maintenance or refactoring of the restructured source code;

[0038] FIG. 6 is a schematic diagram of a computer in which a tool for architectural restructuring of legacy source code and optionally for migration, maintenance or refactoring of the restructured source code is deployed in some cases.

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

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

[0041] In various examples there are tools for architectural restructuring of legacy source code, such as to reduce architectural coupling. Architectural coupling occurs where source code performing a first functionality is intermixed with source code performing a second functionality. The inventors have recognized that architectural coupling, also referred to as tangling, is often found in legacy source code and leads to complexity when seeking to maintain, migrate or refactor the source code. The inventors have developed tools for detecting architectural coupling and tools for reduction of architectural coupling whilst retaining functionality. The tools facilitate architectural restructuring whereby a legacy source code component is divided or split into more than one component and those components are then connected appropriately to retain the original functionality.

[0042] When faced with the task of uplifting a legacy software system to reduce a high level of architectural coupling between system components, a core challenge is to understand the constituent parts that make up the original system. Only when it is understood which parts provide specific parts of the system functionality is it possible to restructure and reduce architectural coupling. Once achieved, however, developing the improved system architecture can still be challenging, labour-intensive and error-prone.

[0043] In various examples described herein there is technology for restructuring software architectures to reduce high architectural coupling based on functional role identification combined with transformation and code generation. By analysing the original software system with tools that can identify the constituent parts that make up its architecture, it can be identified where high architectural coupling is present and how the current system design contributes to this, for example by tangling architectural concepts. Based on the understanding of this analysis step in turn a transformer is used to propose restructuringto disentangle elements according to best architectural practice, as well as generate code snippets to ensure the resulting system behaves the same as before.

[0044] 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 functionality and the value it represents to the organisation. This is also known as software refactoring and involves in-depth analysis, rearchitecting and comprehensive reimplementation of the software system while ensuring functional equivalence upon completion. Related tasks to ensure this include creating comprehensive test harnesses, writing documentation, etc. Between the two, software refactoring requires a substantially more comprehensive understanding of the design and architecture of the legacy system, which can be amplified by the refactoring target when the system is intended to undergo fundamental architectural changes, for example when migrating from a monolithic desktop to a cloud-based webapplication.

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

[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 automated manner. A functional marker is a plurality of interconnected nodes, each node representing a software component and having a known functional role. A store or database of functional markers is available and is used as described below. More detail about functional markers, including examples of functional markers, is given below.

[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 with architectural restructuring. In various examples the tool 100 comprises functionality to detect architectural coupling. In various examples the tool 100 comprises functionality to architecturally restructure the legacy source code to reduce architectural coupling whilst retaining functionality. 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.

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

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

[0056] FIG 2. is schematic diagram of an example of the computer implemented tool 100 for migration, maintenance or refactoring of source code, with architectural restructuring. 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 tool 100 comprises a transformer and code generator 220 for carrying out architectural restructuring in order to reduce architectural coupling whilst retaining functionality. The tool 100 comprises orhas access to a store of concepts 222 which are specific to a domain of the legacy software. In a non-limiting example where the legacy software implements a voicemail service a non-exhaustive list of example concepts is: visual voicemail account, audio voicemail account, account, session. In some examples, the concepts 222 in the store are model-driven engineering concepts used in a domain model of a domain of the legacy software.

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

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

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

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

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

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

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

[0064] The transformer and code generator 200 receives input from the role determining module 210 (and optionally also the concept module 204) comprising functional roles assigned to nodes of a graphical representation of the source code. The tool 100 detects possible architectural coupling by matching the assigned functional roles with concepts of a domain of the legacy source code, retrieved from domain concepts store 222. The domain concepts store 222 stores concepts for a plurality of domains in some examples, and the transformer and code generator 220 is able to access an appropriate one of the domains according to the particular legacy software. In an example, a domain of the legacy software is detected from the legacy software by inspecting comments in the legacy source code, or by input from a software engineer.

[0065] The transformer part of the transformer and code generator 220 detects any functional roles that exhibit significant tangling or architectural coupling by using one or more rules. In an example, the detection is done by finding nodes of the graph which havebeen assigned two or more different functional roles. A single node of the graph which has been assigned two or more different functional roles is detected as comprising architectural coupling or tangling.

[0066] Once an instance of tangling has been detected, the transformer operates to transform the source code corresponding to the node detected as being tangled. The transformation operates to separate the source code according to the assigned functional roles, so there is one source code component per functional role. The separation is achieved according to model-driven engineering which comprises using a domain model of a domain of the legacy software, where the domain model comprises the concepts 222 of the domain and relationships between those concepts. Using model-driven engineering technology a transformation or mapping from the legacy source code component to the new source code components is defined and executed. The separation results in at least one software component being divided into a plurality of software components. The transformer comprises any model-driven engineering tools and a non-exhaustive list of examples is: Rhapsody, Simulink, Eclipse Modelling Framework.

[0067] The code generator part of the transformer and code generator 220 connects the plurality of software components by rewiring and creating glue-code to achieve architectural restructuring. The code generator is any suitable generative language model for generating source code such as GitHub Copilot, OpenAI Codex, ChatGPT. In some cases the code generator is a rule based code generator such as Acceleo.

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

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

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

[0071] FIG. 4 is a schematic diagram of a graphical representation of software before and after architectural restructuring to reduce architectural coupling. A graphical representation of an original software system 404 is illustrated in the upper box. A graphical representation 406 of the software system after it has been transformed to reduce architectural coupling is shown in the lower box. In the example of FIG. 4 the original software system is for the domain of voicemail services. The technology described herein is used to create the graphical representation of the original software system and to identify occurrences of functional markers in the graphical representation. The technology described herein is used to assign functional roles to the nodes of the graphical representation, such as according to functional roles of the occurrences of the functional markers. Concepts 222, from the store of concepts described with reference to FIG. 2, are matched to the assigned functional roles. Thus in the graph of the original software system 404 there is a node that has been mapped to the concept visual voicemail account 410 and a node that has been mapped to the concept of audio voicemail account 412. These nodes 410, 412 inherit from a node mapped to the concept of account 408. A node mapped to the concept of session 414 (such as an internet browsing session) is linked to the node mapped to the concept of account 408. The session 414 concept node aggregates to and from a node matched to the concept of graphical user interface GUI 416. As indicated in FIG. 4 the functional role assignment for the node matched to the concept of GUI 416 is unclear since it comprises two functional roles (view and controller).

[0072] In the graphical representation of the original software system 404 it can be seen that there is high architectural coupling between the GUI 416 and session 414 nodes, which makes it hard to, for example, replace the user interface or parallelise session management. The tool 100 is able to detect the presence of the architectural coupling using rules, such as a rule that indicates architectural coupling is present if a number of functional roles of a single node is greater than one.

[0073] To determine the best way to solve this (i.e reduce architectural coupling), first a Role Classifier 400 that searches for a functional marker which is a Model View Controller (MVC) design pattern is used to determine which nodes of the graphical representation are responsible for the Model, View and Controller aspects of the original software system404. This analysis uncovers that the View and Controller aspects are entangled in the GUI node 416, explaining the high architectural coupling. With this understanding the Transformer I Code Generator 220 acts to separate the View and Controller functional roles into separate system elements and generate the required code. This operation reduces architectural coupling and is achievable where the functional roles of the nodes of the graphical representation are understood. The separation itself is achieved through the use of principles from Model-Driven Engineering which allows for systematic transformation and generation of source code based on understanding of core functional elements inside a software system (i.e. domain model). After the transformation the graphical representation of the transformed software system 406 shows separate nodes for controller 418 and GUI 420 since these are the result of dividing node 416 and give an architectural transformation.

[0074] In the example of FIG. 4 a particular role classifier 400 is used which searches for occurrences of a model view controller design pattern as a functional marker in the graphical representation of the source code. However, the example of FIG. 4 is not intended to be limiting and is adapted to other types of role classifier such as a classier for an observer design pattern or another type of role classifier in some examples. A role classifier is computer implemented functionality to detect the occurrence of a functional marker in a graphical representation of the legacy source code.

[0075] 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 500 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. A store of concepts of a domain of the source code is available or is automatically constructed by giving the source code to a large language model and asking for the concepts. Any large language model capable of dealing with source code may be used such GPT4, Code Llama, Gemini. A large language model is a machine learning model with over a billion parameters and capable of generating sequences of tokens such as for source code, text or other content. 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. The tool 100 accesses 504 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 504 an occurrence of at least one of the functional markers. This may be done by sub-graph matching as described above. The tool 100 uses a role classifier to assign 506 functional roles to nodes of the graph in the occurrence. The assigning may be done according to known functional roles of components or nodes of the functional marker.

[0076] The tool 100 matches 510 the assigned functional roles against the concepts in the store of domain concepts. The tool identifies 512 functional roles that exhibit tangling. In an example this is done by searching for nodes in the graph which have been assigned two or more different functional roles. A transformer, that uses model-driven engineering computes a new architecture that achieves reduced tangling and generates the new architecture. A code generator is used to rewire the resulting components and create glue-code where needed to retain functionality after transformation. In some examples the glue-code also enables transparency after transformation. The resulting source code which has reduced architectural coupling is stored 518.

[0077] The tool 100 optionally triggers 506 migration, or maintenance or refactoring of part but not all of the source code with the reduced architectural coupling, where the part of the source code is selected from the legacy code base 102 using rules and the assigned functional markers.

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

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

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

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

[0082] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. The arrows between boxes in the figures show one example sequence of method steps but are not intended to exclude other sequences or the performance of multiple steps in parallel. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. Where elements of the figures are shown connected 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.

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

Claims

CLAIMS1. A computer implemented method comprising: accessing source code from a legacy code base; computing a graph representing the source code, the graph comprising a plurality of nodes connected by edges, each node representing a software component of the source code and each edge representing a relationship between software components; accessing a functional marker comprising a plurality of interconnected nodes, each node representing a software component and having a known functional role; accessing a plurality of concepts of a domain of the source code; 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; matching the assigned functional roles to the concepts; identifying architectural coupling of different functional roles within a single node of the graph using the assigned functional roles and matched concepts; reducing the architectural coupling by transforming the source code; and storing the corresponding source code having reduced architectural coupling.

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 for the source code with reduced architectural coupling, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

4. The computer implemented method of any preceding claim wherein reducing the architectural coupling by transforming the source code comprises using a model-driven engineering transformer .

5. The computer implemented method of claim 4 comprising using a code generator to generate code for connecting software components that result from transforming the 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 claim 4 or claim 5 wherein the transformer and / or code generator have access to the concepts.

8. The computer implemented method of any preceding claim comprising computing the concepts from the source code using a large language model.

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; accessing a plurality of concepts of a domain of the source code; 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; matching the assigned functional roles to the concepts; identifying architectural coupling of different functional roles within a single node of the graph using the assigned functional roles and matched concepts; reducing the architectural coupling by transforming the source code; and storing the corresponding source code having reduced architectural coupling.11 . The apparatus of claim 10 wherein for the source code with reduced architectural coupling, triggering any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring.

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 reducing the architectural coupling by transforming the source code comprises using a model-driven engineering transformer.

14. The apparatus of any of claims 10 to 13 comprising using a code generator having access to the concepts, to generate code for connecting software components that result from transforming the source code.

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

Images