Source code migration, maintenance, refactoring using design patterns

Abstract

Source code from a legacy code base is represented using a 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 comprising a plurality of interconnected nodes, each node representing a software component and having a known functional role is accessed. An occurrence of the functional marker in the graph representing the source code is found. 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. For the source code from the legacy code base corresponding to the nodes with the assigned functional roles, an automated tool triggers any of: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. The functional marker is a design pattern which makes it possible to assign functional roles associated with the design pattern.

Description

SOURCE CODE MIGRATION, MAINTENANCE, REFACTORING USING DESIGN PATTERNS

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

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

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

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

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

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

[0006] 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 intended to 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.

[0007] In various example, design patterns are used as functional markers whereby a structure of a design pattern is labelled with possible functional roles. The inventors have recognized that using design patterns as functional markers brings significant benefits since design patterns have a consistent structure which map to functional roles. The design patterns can then be used as functional markers to identify parts of legacy source code that perform particular functions in an efficient manner. The identified parts can then be migrated, maintained or refactored.

[0008] In the 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; wherein the functional marker is a design pattern which is a language-agnostic coding structure. 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. Analysis of 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] The present technology uses a detected design pattern as a functional marker. The use of design patterns as functional markers is a particularly effective way of identifying the functionality of components of the source code as design patterns areformalised best practices that software engineers often use to solve common and reoccurring problems, and are thus very likely to be present within the source code. A design pattern has a consistent structure which is used in the present technology to map the components within a design pattern to functional roles. These functional roles can then be used as described herein to quickly find parts of the legacy source code that perform particular functions.

[0010] In various examples the design pattern is stored using a graph-based storage paradigm and identifying the occurrence of the design pattern in the graph comprises using a graph algorithm. This gives a principled, methodical way to automatically identify occurrences of design patterns in a legacy code base.

[0011] In some examples, entities in a design pattern have string names and identifying the occurrence of the design pattern in the graph comprises string matching of any of: class names, method names, variable names, library names. String matching is efficient and gives an automated way to find occurrences of design patterns in the graph.

[0012] Preferably, identifying the occurrence of the design pattern in the graph comprises using subgraph isomorphism. Using subgraph isomorphism is found to be particularly effective for identifying occurrences.

[0013] In some 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, and nodes of the graph are annotated with metadata comprising any of: class names, method names, variable names, library names. Other types of graph representation may be used in place of UML. 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 roles identified within the design pattern are associated with an architecture selected from any of: a model-controller, a model-view- controller, pipes and filters. These examples of architectures are not intended to be limiting but are examples which have been found to work well in practice. This list of examples of architectures with which design patterns can be associated is not exhaustive.

[0015] In various examples the method comprises offering the functional role assignments as candidates to a human via a graphical user interface, receiving input from a human selecting or rejecting the candidates, inputting the selected candidates to acomputing device and storing the input from the human. In this way a human has control over the process and has reduced burden of user input to the computer as compared with manually identifying the candidates.

[0016] In some examples, the stored input from the human is used to influence future assignment of roles to nodes. This is found particularly effective where there are large graphs and uncertainty in assignment of roles. Using the human input to influence future assignment of roles to nodes improves accuracy.

[0017] In various examples the method comprises carrying out any of the: migration, deployment as a microservice, deployment as a containerised service, deployment as a cloud-native application, maintenance, refactoring. 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.

[0018] 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; wherein the functional marker is a design pattern which is a language-agnostic coding structure. 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 effectiveway to identify the functional roles of nodes and the corresponding source code from the legacy code base. Using functional markers for functional role identification within the source code is an automated, efficient and effective way for legacy code to be migrated, deployed as a microservice, deployed as a containerised service, deployed as a cloudnative application, maintained or refactored. The present technology uses a detected design pattern as a functional marker. This brings benefits since a design pattern has a consistent structure that in the present technology is used to map components within a design pattern to functional roles thus enabling automated detection of parts of the legacy source code that perform particular functions.

[0019] In various examples assigning the functional roles comprises assigning at least one functional role to a node where the assignment is uncertain. 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.

[0020] In some examples, the apparatus is arranged so the design pattern comprises a node with an element of observer connected to a node with an element of subject and a node with an element of concrete observer; and where a node with an element of concrete subject is connected between the node with the element of subject and the node with the element of concrete observer. This particular grouping of observer, subject, concrete observer and concrete subject elements represent an observer design pattern, a commonly used design pattern that allows a software engineer or automated process to define a subscription mechanism to notify multiple objects about events that happen to the object they are observing. Hence, the identification of one element of the observer design pattern means the presence of the remaining elements gives rise to the possibility of the presence of the remaining conceptual roles and so the search for the remaining conceptual roles can be narrowed down to a region near the identified one. Further, in an example where the source code implements a telecommunications network service as part of which there is a subscription service to end users regarding service-related information, the subscription service may need to be migrated, deployed as a microservice, deployed as a containerised service, deployed as a cloud-native application, maintained or refactored. Hence, there may be a need to identify the components of the source code contributing to the subscription service, for which the use of an observer design pattern as a functional marker is a particularly effective way of doing so.

[0021] In some cases the apparatus assigns a functional role using static code analysis. Using static code analysis is an effective way to assign a functional role.

[0022] In some cases the apparatus is arranged so that identifying an occurrence of the functional marker comprises using a sub-graph matching algorithm. Using a sub-graphmatching algorithm is a particularly effective way of identifying an occurrence of the functional marker. The bigger the graph becomes the harder it becomes to do sub-graph matching on it without using a heuristic to guide the matching. One such heuristic comprises the use of functional markers to guide the search.

[0023] According to another aspect of the technology there is a computer program having instructions which when executed by a processor implement the method of any of the examples described herein.

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

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

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

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

[0028] FIG 3. is a schematic diagram of an example design pattern, role classifier and legacy software system;

[0029] FIG. 4 is an example of an observer pattern detected within a legacy software system;

[0030] FIG. 5 shows an observer pattern within a model view controller (MVC) architecture;

[0031] FIG. 6 shows the example from FIG. 4 and with functional roles of entities in the legacy software system identified;

[0032] FIG. 7 is a flow diagram of an example method performed by a tool for migration, maintenance or refactoring of source code such as that of FIG. 1 ;

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

[0034] 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 elementsmay be designed as one element. Common reference numerals are used throughout the figures, where appropriate, to indicate similar features.DETAILED DESCRIPTION

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

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

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

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

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

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

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

[0042] The technology uses 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. The inventors have recognized that a design pattern may be used as a functional marker and that a structure of a design pattern is mappable to functional roles. There are twenty three design patterns defined in the book “Design patterns: elements of reusable object-oriented software” 1994 by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Whilst these twenty three design patters are the first and most widely used design patterns, there are many others too. A store or database of design patterns is available and is used as described below. More detail about functional markers and design patterns, including examples of design patterns, is given below.

[0043] 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, input identifiers of design patterns or stores of design patterns to be used as 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.

[0044] 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 more than one programming language. The tool 100 is language agnostic and is operable with legacy code bases 102 of many different programming languages.

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

[0046] The tool 100 has functionality to identify occurrences of functional markers in the legacy code base 102 optionally including to identify design patterns which are being used as functional markers. In some cases the tool 100 receives input from another process detailing design patterns that have already been identified 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 and / or design patterns which are being used as 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 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. By using detected design patterns as functional markers, the consistent structure of design patterns, which are mappable to functional roles is exploited.

[0047] 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 markup language (HTML) and cascading style sheets (CSS). In some cases the programming language is used to help identify certain functional markers, design patterns and roles, e.g. this component is written in this language which is always used for III.

[0048] 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 or design patterns used as functional markers in source code, as well as a concept module 204 for identifying concepts and functional roles.

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

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

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

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

[0053] 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 and a store of design patterns 200 to be used as functional markers. The design patterns 200 are represented in graphical form or are converted to graphical form by the occurrence module 202. The relationships (edges) between the nodes of a graphical representation of a design pattern and the types of relationships are used to ensure a sound match. The occurrence module 202 uses subgraph matching algorithms from graph theory to identify occurrence of design patterns being used as functional markers in the graphical representation of the legacy code base 102. In an example the subgraph 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. In some cases the subgraph matching comprises subgraph isomorphism. In some cases the occurrence module 202 uses partial matching to assign a role, using fuzzy subgraph matching. In some cases the occurrence module 202 uses string matching or any of: class names, method names, variable names, library names. In some cases the occurrence module 202 uses relationship analysis. Different combinations of ways of identifying occurrences may be used. The technology is not bound to a specific set of analysis techniques. Depending on the architectural analysis in question, different design patterns and thus different analysis techniques have varying usefulness in the identification of occurrences. Rules are used in some examples to select appropriate ones of the analysis techniques to use. 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.

[0054] 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 design pattern that is being used as 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.

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

[0056] As the number of types of information supplied to the tool 100 about the design pattern (which is being used as a functional marker) and its various entities increases, so do the number of potential analysis algorithms and techniques that can be used to detect occurrences of the design pattern structure in the graphical representation of the legacy code. This information includes but is not limited to:

[0057] Common class, method and variable names used within each entity

[0058] Common external libraries used by the entities

[0059] Common parameters and global variables for each entity

[0060] Common call patterns

[0061] The final set of data available to the tool 100 before the system analysis stage is, for each design pattern, a list of likely candidate functional roles of each entity within a design pattern for various common architectures. A library of architectures is available in some cases. A non-exhaustive list of examples of these architectures is:

[0062] Model-Controller (MC)

[0063] Model-View-Controller (MVC)

[0064] Pipes and Filters

[0065] FIG 3. is a schematic diagram of an example design pattern, role classifier and legacy software system. FIG. 3 shows an example of a design pattern 300 which in this case is an observer design pattern illustrated in UML class diagram format, with a possible functional role within a Model View Controller architecture. The observer design pattern comprises an observer component 302, a subject component 304, a concrete subject component 308, and a concrete observer component 306. The concrete subject component 308 inherits from the subject component 304 as indicated by the arrow. The concrete observer 306 component inherits from the observer component 302 as indicated by the arrow. The observer component 302 aggregates the subject component 304 as indicated by the diamond. The concrete subject 308 aggregates from the concrete observer as indicated by the diamond. In the example of FIG. 3 the most likely functional role of the components within a Model View Controller architecture is illustrated.

[0066] FIG. 3 also shows a graphical representation of a legacy software system. This graphical representation comprises an observer component 316, a graphical user interface component 318, a subject component 322, a monitor component 326, a state component 328 and a history component 330. The observer 316, subject 322, monitor 326 and GUI 318 components are found to match the arrangement of the observer design pattern 300; this is because the nodes, the node types, the edges and the associated relationship types for the edges match and therefore an instance of the observer design pattern was present . The monitor component 326 aggregates from state component 328 which is associated with history component 330. In an example, monitor component 326 represents part of the legacy software system that monitors a round trip time of a communications network link, or a packet loss rate on the communications network link. The state is the current data obtained by the monitor and the history 330 is a record of previous values of the state.

[0067] Suppose the tool 100 of FIG. 1 is using the observer design pattern as a functional marker. The tool has been used to identify an occurrence of the observer design pattern 300 in the graphical representation of the legacy software system. The resulting observer pattern detected within the legacy software system is shown in FIG. 4.

[0068] FIG. 4 is an example of an observer design pattern being used as a functional marker and detected within a legacy software system. The detected occurrence of the observer design pattern comprises observer 316 component connected to subject component 322 which is connected to monitor component 326 which is connected to GUI component 318. The dotted boxes 400, 402, 404, 406 indicate elements of the observer design pattern being used as a functional marker.

[0069] Once one or many design patterns have been identified as functional markers within the target legacy system, the tool 100 will then look up the likely functional role of each entity of each design pattern for the architecture in question and assign these functional roles to the entities within the target legacy system. A design pattern may be represented in graphical form where each node is an entity. A non-exhaustive list of examples of entities in an object oriented programming paradigm is: file, class, variable method. In other programming paradigms there are other types of entity. This results in these entities having likely functional roles within the target system, which is demonstrated in FIG. 5.

[0070] FIG. 5 shows an observer design pattern within a model view controller (MVC) architecture. FIG. 5 demonstrates that if an observer pattern in used in a system that follows the MVC architecture, a concrete observer usually assumes the functional role of a View and a concrete subject usually assumes the functional role of a Model.

[0071] FIG. 6 shows the example from FIG. 4 and with functional roles of entities in the legacy software system identified. The functional role of the GUI component 318 isidentified as View 502. The functional role of the monitor component 320 is identified as model 500. Fig 5 demonstrates that because GUI and Monitor had been assigned the functional roles of concrete observer and concrete subject respectively, it can be inferred that if the tool is trying to estimate whether the system uses MVC, they are a View and Model.

[0072] FIG. 7 is a flow diagram of a method performed by a tool 100 for migration, maintenance or refactoring of source code. The tool 100 accesses 700 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 702 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. However, other types of graph representation may be used. The tool 100 accesses 704 a store of design patterns 200 being used as functional markers. The design patterns may be the 23 from the book mentioned above, or any other design patterns.. Because the design patterns are being used as functional markers they have possible functional roles annotated The tool 100 identifies 704 an occurrence of at least one of the design patterns in a graphical representation of the legacy code base. This may be done by one or more of: string matching, subgraph matching, subgraph isomorphism, relationship identification, searching for source code in particular languages, or other methods. Preferably more than one method for identifying the occurrence is used both simultaneously and in sequence, so that results from one method may inform other ones of the methods. The tool 100 assigns 706 functional roles to nodes of the graph in the occurrence. The assigning is done according to known possible functional roles of components or nodes of the design pattern used as a functional marker. The tool 100 triggers 706 migration, or maintenance or refactoring of part but not all of the source code, where the part of the source code is selected from the legacy code base 102 using rules and the assigned functional roles.

[0073] FIG. 8 illustrates various components of an example computing device 800 in which embodiments of the tool for software migration, maintenance or refactoring are implemented in some examples. The computing device is of any suitable form such as a server or a compute node of a data centre.

[0074] The computing device 800 comprises one or more processors 802 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 7. In some examples, for example where a system on a chip architecture is used, the processors 802 include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of figures 2 to 7 in hardware (rather than software or firmware). That is, the methods described herein areimplemented in any one or more of software, firmware, hardware. The computing device has a data store holding design patterns. The computing device has the tool for migration, maintenance or refactoring of source code 100 within the memory 814. Platform software comprising an operating system 816 or any other suitable platform software is provided at the computing-based device to enable application software 818 to be executed on the device. Although the computer storage media (memory 814) is shown within the computing-based device 800 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 804).

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

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

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

[0078] 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 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; wherein the functional marker is a design pattern which is a language-agnostic coding structure.

2. The computer implemented method of claim 1 wherein the design pattern is stored using a graph-based storage paradigm and wherein identifying the occurrence of the design pattern in the graph comprises using a graph theory algorithm.

3. The computer implemented method of claim 1 or claim 2 wherein entities in a design pattern have string names and wherein identifying the occurrence of the design pattern in the graph comprises string matching of any of: class names, method names, variable names, library names .

4. The computer implemented method claims 2 or 3 wherein identifying the occurrence of the design pattern in the graph comprises using subgraph isomorphism.

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, and nodes of the graph are annotated with metadata comprising any of: class names, method names, variable names, library names.

6. The computer implemented method of any preceding claim wherein the design pattern is associated with an architecture selected from any of: a model-controller, a model-view-controller, pipes and filters.

7. The computer implemented method of any preceding claim comprising offering the functional role assignments as candidates to a human via a graphical user interface, receiving input from a human selecting or rejecting the candidates, inputting the selected candidates to a computing device and storing the input from the human.

8. The computer implemented method of claim 7 comprising using the stored input from the human to influence future assignment of roles to nodes.

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; wherein the functional marker is a design pattern which is a language-agnostic coding structure.

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 design pattern comprises a node with a functional role of observer connected to a node with a functional role of subject and a node with a functional role of concrete observer; and where a node with a functional role of concrete subject is connected between the node with the functional role of subject and the node with the functional role of concrete observer.

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 design pattern 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